verification-before-completion

完成前验证

概述

未经验证就声称工作完成，这不是高效，而是不诚实。

核心原则： 先有证据，再下结论。

违反本规则的文字即违反本规则的精神。

铁律

未经最新验证证据，不得声称完成

如果你没有在本消息中运行验证命令，就不能声称它通过了。

门控函数

在声称任何状态或表达满意之前：

1. 识别：什么命令能证明这个声明？
2. 运行：执行完整的命令（全新、完整）
3. 读取：完整输出，检查退出码，统计失败数
4. 验证：输出是否确认了声明？
   - 如果否：陈述实际状态并附上证据
   - 如果是：陈述声明并附上证据
5. 然后：做出声明

跳过任何一步 = 撒谎，而非验证

常见失败

声明	需要	不充分
测试通过	测试命令输出：0个失败	之前的运行，“应该通过”
Linter干净	Linter输出：0个错误	部分检查，推断
构建成功	构建命令：退出码0	Linter通过，日志看起来不错
Bug已修复	测试原始症状：通过	代码已更改，假设已修复
回归测试有效	红绿循环已验证	测试通过一次
Agent完成	VCS差异显示更改	Agent报告“成功”
需求满足	逐行检查清单	测试通过

红旗——立即停止

• 使用“应该”、“可能”、“似乎”
• 在验证前表达满意（“太棒了！”、“完美！”、“完成了！”等）
• 即将提交/推送/创建PR而未验证
• 相信Agent的成功报告
• 依赖部分验证
• 认为“就这一次”
• 累了，想结束工作
• 任何暗示成功但未运行验证的措辞

合理化预防

借口	现实
“现在应该能用了”	运行验证
“我很确信”	确信不等于证据
“就这一次”	没有例外
“Linter通过了”	Linter不等于编译器
“Agent说成功了”	独立验证
“我累了”	疲劳不是借口
“部分检查就够了”	部分证明不了什么
“用词不同所以规则不适用”	精神重于文字

关键模式

测试：

✅ [运行测试命令] [看到：34/34通过] “所有测试通过”
❌ “现在应该能通过” / “看起来正确”

回归测试（TDD红绿）：

✅ 编写 → 运行（通过）→ 还原修复 → 运行（必须失败）→ 恢复 → 运行（通过）
❌ “我已经编写了回归测试”（未经红绿验证）

构建：

✅ [运行构建] [看到：退出码0] “构建通过”
❌ “Linter通过了”（Linter不检查编译）

需求：

✅ 重新阅读计划 → 创建检查清单 → 逐项验证 → 报告差距或完成
❌ “测试通过，阶段完成”

Agent委托：

✅ Agent报告成功 → 检查VCS差异 → 验证更改 → 报告实际状态
❌ 相信Agent报告

为什么这很重要

来自24次失败记忆：

• 你的人类伙伴说“我不相信你”——信任破裂
• 未定义的函数被发布——会崩溃
• 缺失的需求被发布——功能不完整
• 时间浪费在虚假完成上 → 重定向 → 返工
• 违反：“诚实是核心价值观。如果你撒谎，你将被替换。”

何时应用

始终在以下情况之前：

• 任何形式的成功/完成声明
• 任何满意表达
• 任何关于工作状态的肯定陈述
• 提交、创建PR、任务完成
• 进入下一个任务
• 委托给Agent

规则适用于：

• 确切的短语
• 释义和同义词
• 暗示成功
• 任何暗示完成/正确的沟通

底线

验证没有捷径。

运行命令。读取输出。然后声明结果。

这是不可协商的。