插件审计
我们如何审计每一个插件
已验证表示在 dsh 0.1.0-rc.8 上过了 L1 安装 + L2 加载 + L3 headless；若 L3 为 web-only，则必须再过 L4 Web CDP。不是 topic 计数，也不是「清单能解析」。
7,797 插件
15 分类
7,788 仓库
7,797 已验证
7,059 L3 已验证
738 Web L4 已验证
0 待验证
1,409 MIT 协议
Web L4 验证进度
Web-only（GUI / 依赖浏览器）插件：共 738 个 · 已验证（过 L4 CDP）738 · 待 L4 / 未过 0。web-only 必须过 L4（web CDP）才标已验证。
数据截至 2026-09-29 · 每次构建从插件数据集重算。
「已验证」是什么意思
上架回答「该不该出现在这里？」；验证回答「能不能真跑起来？」有的目录把「可安装」也标成已验证。我们这里：
- L1 · 安装 — 插件在干净 profile 里，与固定版本的 DSH 运行时一起安装。
- L2 · 加载 — profile 成功启动并导出配置。
- L3 · Headless — 载入插件后跑 headless 问答。若判定为仅 Web（web-only），L3 不算通过。
- L4 · Web CDP — L3 为 web-only 时必经：启动 Web profile + 浏览器 CDP 问答。只有 L4 ok 才升为已验证。
verified— L3 headless 通过，或 L3 为 web-only 且 L4 CDP 通过。pending— 已收录但未通过（含 web-only 待 L4，或先前失败——见备注）。- 信任等级只是辅助；star 只表示热度。
上架前的三道审计
出现在目录之前，每条都过这三关。
1 · 来源审计
必须对应真实可达的 GitHub 仓库；改名、删除、不可达的条目会下架。
2 · 生态审计
DSH 清单（cordis.patch.yml、dsh.bundle 等）与 DSH 依赖——不只是仓库名或 topic。
3 · 元数据审计
协议、star、fork、issue、更新时间、语言、是否 archived，直接展示在卡片上。
待验证与失败浏览
当前 pending 0 条。按备注解析出的失败类型筛选（实时数据，不是下方八月批次快照）。待 L4 CDP 表示 L3 判为 web-only、尚未过 CDP；L4 未通过 表示已跑过 CDP 且失败。旧备注「web L3 … CDP E2E」属于普通安装/加载/运行失败，不是 L4 队列。
| 插件 | 类型 | 最近测试 | 备注 |
|---|
全量验证批次 — 2026 年 8 月
对当时 pending 条目的首轮三关快照。
结果
551 通过
198 运行失败
164 安装失败
10 加载失败
未通过原因（批次）
安装失败（159）
- 68 — 声明的依赖版本在 registry 上不存在
- 63 — 构建 / prepare 脚本失败（常因依赖了未发布的 @deepseek-ai/* 包）
- 15 — 依赖包或仓库返回 404
- 13 — 不支持的依赖结构（workspace / linked / exotic）
运行失败（182）
- 107 — 插件 entry 启动时激活失败
- 70 — loader entry 应用失败（schema DSL 不支持、缺配置、版本不匹配）
- 5 — 其他
加载失败（10）
- 10 — overlay 文件缺失（ENOENT）
我们对可靠性的立场
- 上架不等于背书。
- 持续审计——收录时验证，并定期复测。
- 可复核——清单、仓库状态与实测结果。