方法论

四种断言状态

VERIFIED（已通过）

在这一轮探测中，我们独立观测到这项检查通过，针对的正是这个 endpoint。

FAILED（未通过）

我们独立观测到这项检查未通过。我们如实展示——未通过的检查不会被隐藏或改写措辞。

OBSERVED_RISK（观察到风险）

我们观测到一个值得标注的情况，但它本身不是通过/不通过的结论——例如工具描述中包含面向 AI 读者而非人类读者的内容。这是一个信号，不是判决。

UNVERIFIED（未检查）

这一轮探测中我们没能对这项检查得出结论，并且会说明原因（见每条 UNVERIFIED 断言附带的理由）。UNVERIFIED 绝不会被当作通过处理。

执行状态（完成 / 出错 / 跳过 / 阻塞）与上面四种状态分开记录，绝不会被合并成一个通过/不通过的计数。

「已观测，未签名」

部分 target 页面只展示原始观测结果，不使用上述四态中的任何一种，也没有密码学签名。这发生在未认领的 target，或因某个已注明原因被取消发布资格的 target 上。这些页面如实报告我们看到的内容——绝不渲染通过/不通过的结论、分数或状态徽章，因为没有人认领这个 endpoint 的责任，观测结果也从未被签名。

关于证据格式的说明

在这条说明之前签发的签名证明，理由与细节文本以自由文本形式直接写在签名载荷内。此后签发的证明改为携带一个理由 key 与结构化参数——由本网站在请求时渲染成读者所用语言。两种形式都是同等有效、可验证的证据，变化的只是说明文字的编码方式。

是什么标识了跑这些检查的代码

每一份签名证明都写明了产出它的检查套件代码。从 payload 0.3 起，它同时携带 suite_commit（仓库的一个 commit）与 suite_digest——后者取自该 commit 下 packages/checks 的 git 树清单。精确配方这里刻意不复述：它最显然的那种改述指向的是另一个值，所以权威表述是每个证据页上印出的那一条命令。0.3 之前签发的证明只带 suite_digest，用的是更早的定义——指向一个从未发布过的 npm 包；这些值按原样展示，无法复现。仓库目前尚未公开，所以这个摘要今天在原理上可复现，而对项目之外的任何人在实践上还核不了。如果某个 envelope 声明的 payload 版本本站没有对应的 schema，页面就照实这么说，而不去猜。这一整节都不涉及检查得出了什么结论——它只标识是哪份代码得出的这些结论。

这个产品不做什么

我们只检查能够从外部独立观测到的内容，按固定周期，针对一个存活的 endpoint。我们不审计源代码，不保证 endpoint 在两次探测之间的行为，一份干净的报告也不是保证——它只是当时检查了什么、看到了什么的记录。每个报告页自己的覆盖率摘要会准确说明那一轮到底跑了什么、没跑什么。

检测频率

未认领的服务器每 12 小时探测一次；认领后，Free 档每 8 小时一次，Indie 档每 15 分钟一次。每个目标当前所处的检测周期，见其报告页。

检索排序

检索结果按词法文本相关度排序——即查询中每个词与服务器实际观测到的工具名和描述的匹配程度——相同相关度时按最近观测时间排列。付费层级永不影响排序。每个查询词按原形或英文词干形匹配；以「-」开头的词会排除当前工具集命中该词（任一形态）的服务器。不支持引号短语邻接与 OR 操作符。