verification-before-completion

name	verification-before-completion
description	在声称完成、修复通过或提交/创建 PR 之前强制执行验证。要求在做出任何成功声明之前运行验证命令并确认输出。证据先于断言，始终如一。

完成前验证 (Verification Before Completion)

核心理念

证据先于断言，始终如一。

违反此规则的字面即是违反其精神。

铁律

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

如果没有在当前消息中运行验证命令，就不得声称它通过。

验证守门流程

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

1. 识别：什么命令能证明此声明？
2. 运行：执行完整的验证命令（全新、完整）
3. 读取：完整输出，检查退出码，数清失败数
4. 验证：输出是否确认了声明？
   - 如否：用实际状态 + 证据说明
   - 如是：带证据说明声明
5. 只有此时：做出声明

跳过任一步骤 = 造假，不是验证

常见失败模式

声明	需要	不算数
测试通过	测试命令输出：0 失败	上次运行的、推测的
Lint 干净	Linter 输出：0 错误	局部检查、推断
构建成功	构建命令：exit 0	Linter 通过、日志看起来不错
Bug 已修复	测试原始症状：通过	代码改了、推测好了
需求已满足	逐项清单检查	测试全通过了

危险信号——立即停止

以下任一信号出现，立即停止，先验证：

• 使用了"应该"、"大概"、"似乎"
• 在验证前表达了满意（"好了！"、"搞定了！"等）
• 即将提交 / push / 创建 PR 而不做验证
• 直接信任代理上报的"成功"
• 依赖局部验证
• 想"就这一次例外"
• 任何暗示成功但未运行过验证的措辞

防止自我合理化

借口	真相
"应该没问题了"	运行验证
"我很有信心"	信心 ≠ 证据
"就这一次"	没有例外
"Linter 过了"	Linter ≠ 编译器
"代理说成功"	独立验证
"局部检查够了"	局部证明不了任何事

关键模式

测试：

✅ [运行测试命令] [看到：34/34 pass] → "全部测试通过"
❌ "应该通过了" / "看起来没问题"

构建：

✅ [运行构建命令] [看到：exit 0] → "构建成功"
❌ "Linter 过了" （linter 不检查编译）

需求清单：

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

何时应用

总是在之前验证：

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

适用于：

• 精确措辞
• 同义改写
• 暗示性成功
• 任何暗示完成/正确的沟通

验证清单（不改代码的审查场景适用）

对于审查类任务（不改代码），验证手段为：

1. 重读每个修改文件——确认改动完整、无遗漏
2. grep 检查调用方——确认修改的函数/类型没有破坏性变更
3. 检查未用导入/变量——扫描 diff 中的新引入符号是否有调用方
4. 断言变更范围——实际改了的文件与预期是否一致
5. 对照需求清单——逐项确认任务要求是否都满足

每次都至少完成上述 3 项，并在汇报时明确列出已执行的验证步骤及其结果。