verification-before-completion

name	verification-before-completion
description	在声称工作完成、已修复或通过之前使用，在提交或创建 PR 之前——要求运行验证命令并确认输出后才能做出任何成功声明；始终证据先于断言

完成前验证

概述

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

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

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

铁律

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

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

关卡函数

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

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

跳过任何步骤 = 说谎，而非验证

常见失败

声明	需要	不充分
测试通过	测试命令输出：0 个失败	之前的运行、"应该会通过"
检查器无错	检查器输出：0 个错误	部分检查、推断
构建成功	构建命令：exit 0	检查器通过、日志看起来不错
Bug 已修复	测试原始症状：通过	代码改了、假定修复了
回归测试有效	红-绿循环已验证	测试通过了一次
代理完成了	VCS diff 显示变更	代理报告"成功"
需求满足	逐条清单核对	测试通过

红旗 — 停下来

• 使用"应该"、"可能"、"看起来"
• 验证之前表达满意（"太好了！"、"完美！"、"搞定！"等）
• 没有验证就要提交/推送/创建 PR
• 信任代理的成功报告
• 依赖部分验证
• 想着"就这一次"
• 累了想结束工作
• 任何暗示成功但没有运行验证的措辞

防止合理化

借口	现实
"现在应该可以了"	运行验证
"我有信心"	信心 ≠ 证据
"就这一次"	没有例外
"检查器通过了"	检查器 ≠ 编译器
"代理说成功了"	独立验证
"我累了"	疲惫 ≠ 借口
"部分检查就够了"	部分什么都不证明
"换个说法所以规则不适用"	精神重于字面

关键模式

测试：

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

回归测试（TDD 红-绿）：

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

构建：

✅ [运行构建] [看到：exit 0] "构建通过"
❌ "检查器通过了"（检查器不检查编译）

需求：

✅ 重新阅读计划 → 创建清单 → 逐项验证 → 报告缺口或完成
❌ "测试通过了，阶段完成"

代理委派：

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

为什么重要

来自 24 次失败记忆：

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

何时应用

始终在以下之前：

• 任何形式的成功/完成声明
• 任何满意表达
• 任何关于工作状态的正面陈述
• 提交、创建 PR、标记任务完成
• 进入下一个任务
• 委派给代理

规则适用于：

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

底线

验证没有捷径。

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

这不可协商。