| name | verification-before-completion |
| description | 在声称完成、修复通过或提交/创建 PR 之前强制执行验证。要求在做出任何成功声明之前运行验证命令并确认输出。证据先于断言，始终如一。 |
完成前验证 (Verification Before Completion)
核心理念
证据先于断言，始终如一。
违反此规则的字面即是违反其精神。
铁律
没有最新验证证据 = 不得声称完成
如果没有在当前消息中运行验证命令，就不得声称它通过。
验证守门流程
在声称任何状态或表达满意之前：
1. 识别：什么命令能证明此声明？
2. 运行：执行完整的验证命令（全新、完整）
3. 读取：完整输出，检查退出码，数清失败数
4. 验证：输出是否确认了声明？
- 如否：用实际状态 + 证据说明
- 如是：带证据说明声明
5. 只有此时：做出声明
跳过任一步骤 = 造假，不是验证
常见失败模式
| 声明 | 需要 | 不算数 |
|---|
| 测试通过 | 测试命令输出：0 失败 | 上次运行的、推测的 |
| Lint 干净 | Linter 输出：0 错误 | 局部检查、推断 |
| 构建成功 | 构建命令：exit 0 | Linter 通过、日志看起来不错 |
| Bug 已修复 | 测试原始症状：通过 | 代码改了、推测好了 |
| 需求已满足 | 逐项清单检查 | 测试全通过了 |
危险信号——立即停止
以下任一信号出现，立即停止，先验证：
- 使用了"应该"、"大概"、"似乎"
- 在验证前表达了满意（"好了！"、"搞定了！"等）
- 即将提交 / push / 创建 PR 而不做验证
- 直接信任代理上报的"成功"
- 依赖局部验证
- 想"就这一次例外"
- 任何暗示成功但未运行过验证的措辞
防止自我合理化
| 借口 | 真相 |
|---|
| "应该没问题了" | 运行验证 |
| "我很有信心" | 信心 ≠ 证据 |
| "就这一次" | 没有例外 |
| "Linter 过了" | Linter ≠ 编译器 |
| "代理说成功" | 独立验证 |
| "局部检查够了" | 局部证明不了任何事 |
关键模式
测试：
✅ [运行测试命令] [看到：34/34 pass] → "全部测试通过"
❌ "应该通过了" / "看起来没问题"
构建：
✅ [运行构建命令] [看到：exit 0] → "构建成功"
❌ "Linter 过了" （linter 不检查编译）
需求清单：
✅ 重读计划 → 创建清单 → 逐项验证 → 报告差距或完成
❌ "测试通过了，阶段完成"
何时应用
总是在之前验证：
- 任何形式的成功/完成声明
- 任何形式的满意表达
- 任何关于工作状态的正面陈述
- 提交、创建 PR、标记任务完成
- 进入下一个任务
适用于：
- 精确措辞
- 同义改写
- 暗示性成功
- 任何暗示完成/正确的沟通
验证清单（不改代码的审查场景适用）
对于审查类任务（不改代码），验证手段为：
- 重读每个修改文件——确认改动完整、无遗漏
- grep 检查调用方——确认修改的函数/类型没有破坏性变更
- 检查未用导入/变量——扫描 diff 中的新引入符号是否有调用方
- 断言变更范围——实际改了的文件与预期是否一致
- 对照需求清单——逐项确认任务要求是否都满足
每次都至少完成上述 3 项，并在汇报时明确列出已执行的验证步骤及其结果。
