name: 完成前验证 description: 在声称工作完成、修复或通过之前使用 - 要求在提交或创建PR之前运行验证命令并确认输出；始终证据先于断言

完成前验证

概述

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

核心原则： 始终以证据为先，再声称。

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

铁律

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

如果您没有运行此消息中的验证命令，就不能声称它通过。

门控函数

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

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

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

常见失败

声称	要求	不足够
测试通过	测试命令输出：0失败	之前运行过，“应该通过”
代码检查器干净	代码检查器输出：0错误	部分检查，推断
构建成功	构建命令：退出代码0	代码检查器通过，日志看起来好
缺陷已修复	测试原始症状：通过	代码已更改，假定修复
回归测试有效	红绿循环已验证	测试通过一次
代理已完成	版本控制系统差异显示更改	代理报告“成功”
需求满足	逐项核对清单	测试通过

危险信号 - 停止

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

合理化预防

借口	现实
“现在应该工作了”	运行验证
“我有信心”	信心 ≠ 证据
“就这一次”	无例外
“代码检查器通过了”	代码检查器 ≠ 编译器
“代理说成功了”	独立验证
“我累了”	疲惫 ≠ 借口
“部分检查就够了”	部分证明不了什么
“措辞不同所以规则不适用”	精神高于字面

关键模式

测试：

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

回归测试（TDD红绿）：

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

构建：

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

需求：

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

代理委托：

✅ 代理报告成功 → 检查版本控制系统差异 → 验证更改 → 报告实际状态
❌ 信任代理报告

为什么这很重要

来自24个失败记忆：

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

何时应用

总是在之前：

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

规则适用于：

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

底线

验证没有捷径。

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

这是不可协商的。