dsh.so 如何验证插件

dsh.so 是面向 DeepSeek Harness 插件的独立信任与发现注册表。本页说明一个对象从被发现到被验证的完整路径、我们的自动化能告诉你什么、不能告诉你什么，以及当前管线止步于何处。

六阶段管线

信任模型：三个不等式

这三句话是承重墙。本页其余内容都应在它们的背景下阅读。

我们验证什么

• 一个对象能解析到唯一可达的 GitHub 仓库。
• 用户安装前需要的元数据存在且自洽。
• 插件代码与依赖中的可观察模式，经由沙盒扫描获得。
• 维护新鲜度，以绝对快照表达——绝不以增长表述。

我们不验证什么

• 不存在恶意行为。自动化验证无法担保插件当下或未来任何一次更新后不含恶意逻辑。
• 作者意图。安全发现描述的是一个可观察模式，不是作者的心理状态。
• 每条运行路径的运行时安全。沙盒扫描是对行为的抽样，无法穷举插件在你机器上可能做的一切。
• 背书。dsh.so 上的任何内容都不是推荐。Verified 意味着测过，不意味着可信。

局限

自动化验证无法担保不存在恶意行为。扫描是时间点快照：今天通过的插件明天就可能变化，注册表按自己的节奏重扫而非持续盯防。启发式扫描器会产生误报——critical 档是「去看一眼」的指令，不是判决书；而对我们而言全新的模式也可能漏报（假阴性）。最后，索引本身有边界：不在我们发现面之内的插件在这里不可见，这就是站内每个数字都要标注口径的原因。

误报与更正

如果你的插件带着一条你认为错误的发现，请携带发现标识符到注册表仓库提 issue。确认的误报会在下一轮扫描周期修正，每日快照会记录更正历史而不是覆盖它。

更新频率

注册表数据按小时级流水线刷新（发现、投稿、安全报告）。每天 03:17 UTC 的快照把六个口径指标冻结进追加式历史文件；本站发布的每个数字都注明它来自哪一天的快照。

数据来源

• GitHub API——仓库元数据、topic、star、提交活动。
• npm registry——包存在性、周下载量、仓库交叉核对。
• L4 沙盒扫描——逐插件发现分档。
• 手动投稿——进入索引前经人工审核。