在宣称工作完成、已修复或测试通过之前使用，在提交或创建 PR 之前——必须运行验证命令并确认输出后才能声称成功；始终用证据支撑断言

完成前验证概述核心原则：始终用证据支撑结论。对这条规则敷衍了事，就等于违背了它的精神。铁律如果你在这条消息中没有运行验证命令，就不能声称测试通过。门控函数常见失败模式结论需要不够格测试通过测试命令输出：0 failures 之前的运行结果、"应该会通过" Linter 无报错 Linter 输出：0 errors 部分检查、推断构建成功构建命令：exit 0 linter 通过、日志看起来没问题 Bug 已修复测试原始症状：通过代码改了，假设已修复回归测试有效红绿循环已验证测试只通过了一次代理已完成 VCS diff 显示变更代理报告"成功" 需求已满足逐项核对清单测试通过红线——停下来使用"应该"、"大概"、"似乎" 验证前就表达满意（"太好了！"、"完美！"、"搞定！"等）即将提交/推送/创建 PR 却没有验证信任代理的成功报告依赖部分验证想着"就这一次" 累了想赶紧收工任何暗示成功但实际未运行验证的措辞防止合理化借口现实 "应该能行了" 运行验证命令 "我有信心" 信心 ≠ 证据 "就这一次" 没有例外 "Linter 通过了" Linter ≠ 编译器 "代理说成功了" 独立验证 "我累了" 疲劳 ≠ 借口 "部分检查就够了" 部分检查什么也证明不了 "换个说法这条规则就不适用了" 精神大于字面关键模式测试：回归测试（TDD 红绿）：构建：需求：代理委派：何时使用以下情况之前必须使用：任何形式的成功/完成声明任何满意的表达任何关于工作状态的正面陈述提交、创建 PR、标记任务完成进入下一个任务委派给代理本规则适用于：准确措辞同义词和换一种说法暗示成功任何传达完成/正确性的沟通

verification-before-completion