Verification Before Completion

完成前验证

概述

在没有验证的情况下声称工作完成是不诚实，而非高效。

核心原则： 证据先于声明，始终如此。

违反规则的字面意思就是违反规则的精神。

铁律

没有新鲜的验证证据，不得声称完成

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

关卡函数

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

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

跳过任何步骤 = 撒谎，不是验证

常见失败

危险信号 - 停止

• 使用"应该"、"可能"、"看起来"
• 在验证之前表达满意（"太好了！"、"完美！"、"完成！"等）
• 在没有验证的情况下即将提交/推送/PR
• 信任代理成功报告
• 依赖部分验证
• 认为"就这一次"
• 疲惫并想结束工作
• 任何暗示成功但未运行验证的措辞

借口预防

关键模式

测试：

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

回归测试（TDD 红-绿）：

✅ 编写 → 运行（通过）→ 还原修复 → 运行（必须失败）→ 恢复 → 运行（通过）
❌ "我写了一个回归测试"（没有红-绿验证）

构建：

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

需求：

✅ 重读计划 → 创建检查清单 → 验证每一项 → 报告差距或完成
❌ "测试通过，阶段完成"

代理委托：

✅ 代理报告成功 → 检查 VCS diff → 验证更改 → 报告实际状态
❌ 信任代理报告

为什么这很重要

来自 24 个失败记忆：

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

何时应用

始终在之前：

• 任何成功/完成声明的变体
• 任何满意的表达
• 任何关于工作状态的积极陈述
• 提交、PR 创建、任务完成
• 转移到下一个任务
• 委托给代理

规则适用于：

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

底线

验证没有捷径。

运行命令。阅读输出。然后声称结果。

这是不可协商的。