verification-before-completion

改编自 obra/superpowers，对应提交 b36e0829c6d0140e93cfef2ca599b1b07d4a7797（MIT）。

同一表面验证原则改编自 Cursor 的 poteto-mode，对应提交 93b00b89ef425a9c1bac0d0b317dfc49c930ac99（MIT，Copyright (c) 2026 Cursor）。

完成前验证

NO COMPLETION CLAIMS WITHOUT VERIFICATION EVIDENCE MATCHING THE CLAIM

在宣称成功、提交或创建 PR 之前：

1. 确定能证明每项声明的命令或观察结果，并在声明所指的同一表面上进行验证。
2. 根据适用证据作出声明：现在运行针对性检查，或复用已验证的证据，前提是相关代码、测试、输入和环境仍然匹配——完全相同的代码树是充分条件之一，但不是唯一条件。不要添加没有明确可达场景的测试或命令；覆盖率百分比和重复证据都不是目标。仍须执行项目要求的检查。关于当前状态的声明（例如某项服务现在正在运行、某个构件现在存在）需要当前观察结果；过去的结果不能证明当前状态。
3. 阅读完整的相关输出，并检查退出状态和失败数。
4. 检查由他人委派的工作或更改文件的工作所产生的 VCS 差异。
5. 用一句话重述已批准的任务，将结果与其要求及书面约定进行比较，并选择 accept / fix / hand back / ask。额外想法只写一行，不要写代码。修复之前先处理审查意见：驳回未通过的门槛，修复范围内的小问题，将较大或超出范围的工作交还给人工处理。只进行一轮修复和一轮差异复查；未解决的问题应交由人工处理，而不是再来一轮。
6. 根据证据报告实际结果。如果检查失败或未运行，请如实说明，并指出尚未验证的内容。交接、提交和内容完全相同的合并不会使仍然适用的证据失效；需要重新运行检查时，必须有相关差异或具体假设，而不能仅仅因为加上了“最终”标签。

证据必须与声明所指的表面相符：编译只能证明编译通过，单元测试只能证明其实际测试的行为。示例必须与所声明的内容相匹配——UI 声明要提供渲染后的 UI，CLI 声明要提供已构建或已安装的 CLI，持久化声明要提供重启后读取的结果，迁移声明要提供转换后的数据及过时路径检查。测试不能证明构建通过，lint 不能证明类型正确，代码变更不能证明 bug 已修复，Agent 的报告也不能证明其工作确已完成。只有在实际可行时观察到预期的红／绿行为后，回归测试才可信。

绝不要弱化断言、跳过失败的检查、将过时或从未运行的检查当作证明，也不要用“应该”“大概”或“似乎”代替证据。检查失败不代表可以扩大测试范围、放宽预期或反复运行直到通过：调查所指出的失败，然后停止或升级处理。