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

验证前完成

概述

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

核心原则： 始终证据先于声称。

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

铁律

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

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

关卡功能

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

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

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

常见失败

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

红旗 - 停止

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

合理化预防

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

关键模式

测试：

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

回归测试（TDD 红绿循环）：

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

构建：

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

要求：

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

代理委托：

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

为什么这很重要

从 24 个失败记忆：

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

何时应用

始终在以下情况之前：

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

规则适用于：

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

底线

验证无捷径。

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

这是不可谈判的。