verify

验证

铁律

NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE

如果证明该结论的命令没有刚刚在本次会话中运行，那么你就不能提出这个结论。未经验证的结论不是乐观，而是虚假陈述。

把关流程

在声称任何状态或表达满意之前：

1. 识别——哪个命令能证明这一确切结论？（命令见 docs/agents/project.md。如果缺少该文件，就说明情况，建议使用 setup-repo，并手动确定命令。）
2. 运行——重新完整执行该命令。不能使用缓存结果，不能只检查部分范围，也不能说“之前通过了”。
3. 阅读——阅读完整输出：退出代码、失败数、警告。不能只看最后一行。
4. 确认——输出是否确实支持该结论？如果不支持：根据证据报告真实状态。如果支持：提供证据并作出结论。

跳过任何一步，你就是在撒谎，而不是在验证。

结论 → 证据

结论	所需证据	永远不足以证明
“测试通过”	完整运行一次，失败数为零，并阅读输出	之前运行过；只运行了部分测试；“应该能通过”
“构建／lint／类型检查干净”	运行对应命令，退出代码为 0，警告数为零	其他工具运行通过
“功能正常”	在运行中的系统上驱动受影响的流程并观察结果（必需子技能：使用 acceptance-check，或通过 dogfood 手动检查）	单元测试全部通过
“Bug 已修复”	重新测试原始症状，确认症状已消失	代码已修改
“Agent／子 Agent 完成了 X”	你亲自检查了差异	Agent 自己报告成功
“已满足要求”	trace 检查无误（必需子技能：使用 trace），并根据观察到的行为逐项核对每个验收标准	测试全部通过

回归测试验证模式

只有在明确证明回归测试确实能捕获 Bug 后，该测试才算有效：

write test → passes → revert the fix → test MUST fail → restore fix → passes

撤销更改后测试仍然通过，说明它没有测试任何东西。

危险信号——停下来并执行把关流程

• “应该能用”“大概”“似乎可以”“我有信心”
• 没有证据就表示满意（“太好了，搞定了！”）
• 根据对之前运行的记忆作出结论
• 准备提交、推送或创建 PR，却没有刚刚重新运行检查
• 感到疲惫，想尽快结束任务——疲惫不是证据

想法	事实
“现在应该能通过了”	运行它
“我十分钟前刚运行过”	代码之后有改动；再运行一次
“Agent 说成功了”	阅读差异
“部分检查就够了”	部分检查无法证明其余部分
“我会在最后一次性验证所有内容”	每个结论都应在作出时验证；最后才批量验证，会让之前的错误结论暂时被当作事实
“CI 会在合并后发现问题”	CI 运行时结论已经发布；把关应在你作出结论之前，而不是等别人承担代价之后
“只是换了种说法，所以规则不适用”	规则同样涵盖释义和暗示

运行命令。阅读输出。然后——也只有这时——再作出结论。