verification-before-completion

Verification Before Completion - 验证后再完成

技能概述

在声明工作完成、修复成功或测试通过之前，必须执行验证命令并确认输出结果——证据永远优先于断言。

适用场景

1. 代码提交与 PR 创建前

在执行 git commit 或创建 Pull Request 之前，运行完整的测试套件、构建命令和代码检查工具，确保所有验证通过且有实际输出证据。这能防止将未完成的代码推送到共享仓库。

2. 功能开发与 Bug 修复后

完成功能开发或修复 bug 后，通过实际运行的测试命令验证修复效果。对于回归测试，必须执行完整的红绿重构循环：编写测试→运行通过→回滚修复→验证失败→恢复修复→再次通过。

3. 代理任务委托完成后

当将任务委托给 AI 代理或子代理处理时，不能仅凭代理的"成功"报告就认为任务完成。必须检查 VCS diff、运行独立验证命令、确认实际变更内容符合预期。

核心功能

证据驱动验证

强制要求在声明任何成功状态之前，必须先运行验证命令并获取实际输出。规则的核心是：没有新鲜验证证据，就不能声称完成。这包括测试通过、构建成功、bug 修复、需求满足等所有场景。

防御性验证流程

通过五步验证流程防止虚假完成：(1) 识别证明声明的命令 (2) 完整执行该命令 (3) 读取完整输出和退出码 (4) 确认输出是否支持声明 (5) 只有这时才能做出声明。跳过任何步骤都属于不诚实。

红绿重构循环

对于回归测试和 TDD，必须执行完整的验证循环：编写测试→运行（通过）→回滚修复→运行（必须失败）→恢复修复→运行（通过）。仅运行一次通过不足以证明测试有效。

常见问题

"应该能通过了"为什么不是有效验证？

因为"应该"表达的是猜测而非证据。验证的核心是获取实际运行结果。即使你对代码有 100% 的信心，也必须运行命令获取真实输出。历史上大量失败的案例都源于过度自信而跳过验证。

代理报告成功了，为什么还需要独立验证？

代理的成功报告可能基于不完整的检查、错误的假设或部分测试。作为委托方，你需要独立运行验证命令来确认实际状态。这类似于代码审查——作者的声明不能替代审查者的验证。

回归测试为什么要验证失败步骤？

如果你编写的测试在回滚修复后仍然通过，说明测试没有真正验证修复逻辑，可能测试本身有问题或者是误报。红绿重构循环确保测试确实在验证它应该验证的内容。这是 TDD 的基本纪律。