verify

验证

当工作看起来已经完成，但还需要证据时，使用此技能。

这项工作的目的不是庆祝完成，而是依据证据判断是否可以验收。

此技能是判断工作是否完成的唯一事实来源，有两种使用方式：

• 作为 implement 的完成门槛：implement 完成构建后，会启动独立验证器，按照此技能评判验收标准。
• 作为 implement 之后单独执行的检查：当用户希望进一步确认、进行运行时 QA，或对任何差异进行独立完成情况审核时使用。

无论哪种方式，工作内容和规则都相同：依据证据进行判断，不要修复问题。

此技能的作用

verify 回答四个问题：

1. 有哪些改动？
2. 可能有哪些问题？
3. 实际检查了什么？
4. 还存在哪些风险？

使用此技能时，不要修改代码、内容或配置。verify 只读：它会报告证据并给出结论，不会修复发现的问题。如果验证发现了 bug，请准确描述（文件、行号、失败情形），并交由 implement 或用户修复。

验证级别

选择能覆盖实际风险的最低级别，仅在必要时扩大范围。

级别 1：静态检查

当改动可能影响语法、类型、lint 规则、内容解析或构建时使用。

示例：

• npm run lint
• npm run typecheck
• npm test
• npm run build
• 项目专用验证器，例如 verify:content

级别 2：行为检查

当预期行为可以通过测试或检查来验证，而不必仅依赖主观判断时使用。

示例：

• 纯逻辑的单元测试
• 数据加载或 API 行为的集成测试
• 冒烟脚本
• 迁移或种子数据验证
• 检查生成的输出文件

级别 3：运行时 QA

当结果取决于真实应用、浏览器、API、数据库、日志或外部服务配置时使用。

示例：

• 打开本地或已部署的路由
• 点击改动涉及的流程
• 检查可见文本和状态
• 检查控制台或网络错误
• 调用 API 端点
• 验证数据库行数或记录数
• 获取截图、DOM、日志或命令证据

使用 playwright-cli 进行浏览器 QA。如果尚未安装，请先安装（参见 https://github.com/microsoft/playwright-cli），或改用项目已配置的浏览器工具。

Level 4. 对抗式子 Agent 评审

当产生更改的上下文不适合评判这项更改时使用，因为更改规模较大，或自信却错误地给出“通过”的风险较高。目标是避免自我验证偏差：由一个没有编写这项更改、也不认同其假设的新 Agent 进行评审，更难被误导。

仅在至少满足以下一项时触发 Level 4：

• diff 很大或涉及许多文件（粗略标准：5 个或更多文件，或 200 行或更多更改）
• 更改涉及安全、身份验证、资金、数据迁移或破坏性操作
• Level 1-3 检查均通过，但结果仍显得脆弱，或某一项判断的影响很大
• 用户明确要求深入、独立或对抗式评审

不要对小型、低风险的更改触发 Level 4（一行修复、文案微调、清理 lint）。让一群怀疑论者评审无关紧要的 diff 是浪费。

执行方法：

1. 将每项即将判定为“通过”的内容表述为明确的声明，例如“新增的身份验证防护会拒绝已过期的令牌”或“迁移可以回滚”。
2. 对每项高风险声明，使用 Task 工具启动独立的怀疑论者子 Agent。向每个子 Agent 提供声明、相关文件或 diff，以及你已收集的证据，并要求它尝试推翻该声明，而非确认它。对不同声明的怀疑论者可并行运行（在一条消息中调用多次 Task）。
3. 每个怀疑论者返回：refuted 或 not_refuted，并附具体理由。只有指出具体失败案例、文件、行号或复现步骤的反驳才算数。仅说“可能有风险”而没有具体案例，不算反驳。
4. 按多数结果决定。对于一项声明，使用奇数个怀疑论者（1、3），仅当多数人返回 not_refuted 且没有出现具体反例时，才认定该声明成立。任何具体且可复现的反驳，无论投票结果如何，都会将该声明判定为失败。

子 Agent 继承以下证据规则。告知每位怀疑论者：只能报告实际验证过的反驳（运行过相关案例、读过相关代码行），不能报告想象出来的反驳。子 Agent 未验证的说法不算证据，正如你未验证的说法也不算。

防止陷入无休止的怀疑：告知怀疑论者，若没有具体反例，默认结论为 not_refuted。目标是找出真实问题，而不是因模糊的疑虑而拒绝批准。

工作流

1. 运行 git status --short 并确定已更改的文件。
2. 阅读相关 diff 或文件。不要依赖记忆。
3. 用一两句话说明预期行为。
4. 列出此次更改引入的主要风险。
5. 选择能够覆盖这些风险的 Level 1、2 和／或 3 检查。
6. 运行检查。优先运行有针对性的检查。
7. 如果检查失败，判断原因是此次更改、已有问题还是无关因素。
8. 如果 UI 或运行时发生变化，检查真实路由或运行时目标。
9. 如果更改规模较大或风险较高（参见 Level 4 触发条件），在确定结论之前，针对关键声明启动对抗式怀疑论者子 Agent。
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

(Include only when Level 4 ran. Omit otherwise.)

- Claim:
- Skeptics: N run, M refuted
- Outcome: held | broken (with the concrete counterexample)

## Failed Or Blocked

- ...

## Not Checked

- ...

## Remaining Risk

- ...