By name: verification-before-completion description: 在声称工作完成、修好或通过之前使用，在提交或创建 PR 之前必须运行验证命令并确认输出；永远是证据先于断言
完成前验证
概述
没有验证就声称完成，是不诚实，不是高效。
核心原则： 永远是证据先于声明。
违反这条规则的字面意思，就是违反这条规则的精神。
铁律
没有新鲜的验证证据，不许声称完成
如果你在这条消息里没有运行验证命令，就不能声称它通过了。
门控函数
在声称任何状态或表达满意之前：
1. 识别：什么命令能证明这个声明？
2. 运行：执行完整命令（新鲜的，完整的）
3. 阅读：完整输出，检查退出码，统计失败数
4. 验证：输出确认了声明吗？
- 如果否：用证据陈述实际状态
- 如果是：用证据陈述声明
5. 只有到这一步：才能做出声明
跳过任何步骤 = 说谎，不是验证
常见失败
| 声明 | 需要 | 不充分 |
|---|---|---|
| 测试通过 | 测试命令输出：0 失败 | 之前的运行，"应该通过" |
| Linter 干净 | Linter 输出：0 错误 | 部分检查，推断 |
| 构建成功 | 构建命令：退出码 0 | Linter 通过，日志看起来不错 |
| Bug 修好了 | 测试原始症状：通过 | 代码改了，假设修好了 |
| 回归测试有效 | 红-绿循环验证 | 测试通过一次 |
| Agent 完成了 | VCS diff 显示改动 | Agent 报告"成功" |
| 需求满足 | 逐行检查清单 | 测试通过 |
红旗 - 停下
- 使用"应该"、"可能"、"看起来"
- 验证前表达满意（"太好了！"、"完美！"、"搞定！"等）
- 没验证就准备提交/推送/PR
- 信任 agent 的成功报告
- 依赖部分验证
- 想着"就这一次"
- 累了想赶紧结束
- 任何暗示成功但没有运行验证的措辞
防止借口
| 借口 | 现实 |
|---|---|
| "现在应该能用了" | 运行验证 |
| "我很有信心" | 信心 ≠ 证据 |
| "就这一次" | 没有例外 |
| "Linter 通过了" | Linter ≠ 编译器 |
| "Agent 说成功了" | 独立验证 |
| "我累了" | 疲惫 ≠ 借口 |
| "部分检查够了" | 部分什么都证明不了 |
| "换个说法所以规则不适用" | 精神重于字面 |
关键模式
测试：
✅ [运行测试命令] [看到：34/34 通过] "所有测试通过"
❌ "现在应该通过" / "看起来对"
回归测试（TDD 红-绿）：
✅ 写 → 运行（通过） → 撤销修复 → 运行（必须失败） → 恢复 → 运行（通过）
❌ "我写了一个回归测试"（没有红-绿验证）
构建：
✅ [运行构建] [看到：退出码 0] "构建通过"
❌ "Linter 通过了"（linter 不检查编译）
需求：
✅ 重新阅读计划 → 创建检查清单 → 验证每一项 → 报告缺口或完成
❌ "测试通过，阶段完成"
Agent 委托：
✅ Agent 报告成功 → 检查 VCS diff → 验证改动 → 报告实际状态
❌ 信任 agent 报告
为什么这很重要
来自 24 个失败记忆：
- 你的搭档说"我不信你"——信任破裂
- 未定义的函数被发布——会崩溃
- 缺失的需求被发布——功能不完整
- 时间浪费在假完成 → 重定向 → 返工
- 违反："诚实是核心价值。如果你说谎，你会被替换。"
何时应用
永远在以下之前：
- 任何成功/完成声明的变体
- 任何满意的表达
- 任何关于工作状态的积极陈述
- 提交、PR 创建、任务完成
- 进入下一个任务
- 委托给 agent
规则适用于：
- 确切的措辞
- 释义和同义词
- 成功的暗示
- 任何暗示完成/正确的沟通
底线
验证没有捷径。
运行命令。阅读输出。然后才能声称结果。
这不可商量。