| name | verification-before-completion |
| description | 完工前强制验证:拒绝“应该可以”,只信证据。在声称成功或合并 PR 前执行。 |
✅ Verification Before Completion (完工验证)
Overview (总则)
在没有验证的情况下声称工作已完成是欺骗。
核心原则:证据先于声明。
🚫 铁律
没有新鲜的验证证据,严禁做出任何“已完成”或“已修复”的断言。
门禁流程 (The Gate Function)
在表达任何满意或完成状态(如 "Done!", "Perfect!", "Fixed!")之前:
- 确定手段:什么样的命令能证明这个声明是真的?
- 完整运行:执行完整且新鲜的验证命令(不要看几分钟前的记录)。
- 仔细研读:查看退出码、报错计数。
- 比对证据:输出是否真的确认了你的声明?
- 若否:如实汇报现状和报错证据。
- 若是:带着证据(终端截取或结论)做出声明。
常见失败场景 (Common Failures)
| 声明 | 真实要求 (证据) | 错误做法 (非证据) |
|---|
| 测试通过 | 运行全量/相关测试,0 Failures | “应该能过”、“刚才跑过” |
| Lint 洁净 | 运行 Linter,0 Errors | 只检查了局部文件 |
| Bug 已修复 | 运行原本必挂的测试,结果为 Green | 只是改了代码,猜测修复 |
| 需求已达成 | 逐行核对 REQ/DES 检查清单 | “代码写完了,由于测试过了所以算完成” |
🚩 绝禁语句 (Red Flags)
- 使用 "应该" (should), "大概" (probably), "看起来" (seems to)。
- 在验证前表达满意感。
- 信任 AI 自体的“已成功”报告而不进行独立验证。
- 觉得“就这一次,不验证也行”。
💡 验证案例
- TDD 回旋镖:写完修复 -> 运行 (Pass) -> 还原修复 -> 运行 (必须 FAIL) -> 重新修复 -> 运行 (Pass)。这证明了你的测试确实测到了点子上。
- 全局扫描:大规模重构后,不仅要跑受灾点的单元测试,必须跑集成测试
./.agent/checks/run_checks.ps1。