verify

verify

当工作看起来已完成但需要证据时使用此技能。它的职责不是庆祝完成，而是基于证据判断变更能否被接受。该技能是判定“完成”的唯一依据，有两种使用方式：一是作为 implement 的完成关卡，implement 构建结束后会启动一个独立验证器按此技能判定验收标准；二是在 implement 之后作为独立的一轮，用于额外置信度、运行时 QA，或对任意 diff 做独立完成度审计。两种方式的任务与规则相同：依据证据判定，不做修复。

该技能做什么

verify 回答四个问题：改了什么？可能破坏了什么？实际检查了什么？还剩什么风险？

使用该技能期间不要修改代码、内容或配置。verify 是只读的：它报告证据和结论，不修复发现的问题。如果验证暴露出缺陷，精确描述它（文件、行、失败用例），然后交回 implement 或用户修复。

验证层级

使用能覆盖真实风险的最小层级，仅在需要时扩大范围。

第 1 级：静态检查。 当变更可能破坏语法、类型、lint 规则、内容解析或构建时使用。示例：npm run lint、npm run typecheck、npm test、npm run build，以及项目专用校验器如 verify:content。

第 2 级：行为检查。 当变更具有可在不完全依赖人工口味的情况下测试或检查的预期行为时使用。示例：纯逻辑的单元测试、数据加载或 API 行为的集成测试、冒烟脚本、迁移或 seed 验证、检查生成输出文件。

第 3 级：运行时 QA。 当结果依赖真实应用、浏览器、API、数据库、日志或外部服务配置时使用。示例：打开本地或已部署路由、点击变更流程、检查可见文本与状态、查看控制台或网络错误、调用 API 端点、验证数据库行或计数、采集截图/DOM/日志/命令证据。浏览器 QA 使用 playwright-cli；若未安装，先安装（见 https://github.com/microsoft/playwright-cli），或回退到项目已配置的浏览器工具。

第 4 级：对抗式子代理评审。 当产生变更的同一上下文不足以信任其判断时使用，因为变更很大，或出现“自信但错误”的通过结论风险很高。目标是击败自验证偏差：一个没写过该变更、也不共享其假设的新代理更难被糊弄。

仅在满足至少一项时触发第 4 级：diff 很大或横跨多个文件（粗略规则：5 个以上文件或 200 行以上改动）；变更触及安全、认证、资金、数据迁移或破坏性操作；第 1-3 级通过但结果仍显脆弱，或单个判断权重很大；用户明确要求深度、独立或对抗式评审。不要为小型、低风险变更触发第 4 级（一行修复、文案微调、lint 清理）。对琐碎 diff 召集一群怀疑者是浪费。

运行方式：把每个你即将称为“通过”的点框定为明确主张，例如“新的认证守卫会拒绝过期令牌”或“该迁移可逆”。对每个高风险主张，用 Task 工具启动独立的怀疑者子代理。给每个子代理该主张、相关文件/diff 以及你已收集的证据，然后指示它去反驳该主张，而非确认它。对彼此独立的主张并行运行怀疑者（一条消息内多次 Task 调用）。每个怀疑者返回：refuted 或 not_refuted，外加具体理由。只有指出具体失败用例、文件、行或复现步骤的反驳才算数。没有具体案例的“可能有风险”不算反驳。按多数决定。对一个主张运行奇数个怀疑者（1、3），只有当多数返回 not_refuted 且未浮现具体反例时，才认定该主张成立。任何具体、可复现的反驳都使该主张翻为 Fail，无论票数多少。子代理继承下方的证据规则。告知每个怀疑者只能报告它实际演示过的反驳（运行过该用例、读过该行），绝不报告它想象出的。子代理未经证实的说法不是证据，正如你自己的也不是。防止无尽怀疑：指示怀疑者在没有具体反例时默认结论为 not_refuted。任务是找到真实故障，而不是凭模糊疑虑拒绝批准。

工作流

1. 运行 git status --short 并识别变更文件。
2. 阅读相关 diff 或文件。不要依赖记忆。
3. 用一两句话陈述预期行为。
4. 列出该变更引入的主要风险。
5. 选择覆盖这些风险的第 1、2 和/或 3 级检查。
6. 运行检查。优先聚焦检查。
7. 如果检查失败，判断它是由本次变更引起、本就存在，还是无关。
8. 如果 UI/运行时变了，检查真实路由或运行时目标。
9. 如果变更大或高风险（见第 4 级触发条件），在定论前对关键主张启动对抗式怀疑者子代理。
10. 只报告你实际收集到的证据。
11. 说明还有什么未检查。

证据规则

命令只有实际运行过才算证据。浏览器检查只有点名了路由、状态和观察结果才算证据。数据库检查只有点名了目标环境和查询/结果才算证据。截图只有点名了路径或捕获视图才算证据。“看起来不错”本身不是证据。不要隐藏被跳过的检查，说明为何未运行。

失败处理

当检查失败时：引用或概括重要错误行；说明它是否看起来与当前变更相关；若无关，点名证明其超出范围的文件/命令；若相关，作为 Fail 报告，附上失败的文件/行/用例，供 implement 或用户修复，不要在此处修复；若被阻塞，停止并清晰报告阻塞点。当更窄的失败已解释问题时，不要反复运行宽泛检查。

结论规则

结论必须反映实际检查了什么，而非什么看起来完成了。只有当每个验收标准都拥有其风险所要求层级的真实证据时才 Pass。依赖运行时、浏览器、API 或数据库行为的标准，只有该行为确实被执行过才算满足——而不是代码看起来正确。若任何标准仍未检查或只能通过阅读代码确认，结论至多为 Partial——若真实前置条件（如已认证会话、缺失凭证）阻止你运行，则为 Blocked。绝不把未检查的标准折进 Pass。Not Checked 中的条目或你跳过的运行时标准会将结论上限压到 Pass 以下。公开报告它，而不是向上取整。

输出格式

Verdict

Pass | Partial | Fail | Blocked

Checked

• ...

Evidence

• Command:
• Result:
• Runtime:
• Result:

Adversarial Review

（仅当运行了第 4 级时包含，否则省略。）

• Claim:
• Skeptics: N run, M refuted
• Outcome: held | broken（附具体反例）

Failed Or Blocked

• ...

Not Checked

• ...

Remaining Risk

• ...