verification-before-completionlisted

# 完成前验证 ## 概述 在没有验证的情况下宣称工作完成，这不是高效，而是不诚实。 **核心原则：** 始终用证据支撑结论。 **对这条规则敷衍了事，就等于违背了它的精神。** ## 铁律 ``` 没有新鲜的验证证据，不许宣称完成 ``` 如果你在这条消息中没有运行验证命令，就不能声称测试通过。 ## 门控函数 ``` 在宣称任何状态或表达满意之前： 1. 确定：什么命令能证明这个结论？ 2. 运行：执行完整命令（重新运行，完整执行） 3. 阅读：完整输出，检查退出码，统计失败数 4. 验证：输出是否支持这个结论？ - 如果否：用证据说明实际状态 - 如果是：带证据陈述结论 5. 只有这时：才能做出结论 跳过任何一步 = 说谎，不是验证 ``` ## 常见失败模式 | 结论 | 需要 | 不够格 | |------|------|--------| | 测试通过 | 测试命令输出：0 failures | 之前的运行结果、"应该会通过" | | Linter 无报错 | Linter 输出：0 errors | 部分检查、推断 | | 构建成功 | 构建命令：exit 0 | linter 通过、日志看起来没问题 | | Bug 已修复 | 测试原始症状：通过 | 代码改了，假设已修复 | | 回归测试有效 | 红-绿循环已验证 | 测试只通过了一次 | | 代理已完成 | VCS diff 显示变更 | 代理报告"成功" | | 需求已满足 | 逐项核对清单 | 测试通过 | ## 红线——停下来 - 使用"应该"、"大概"、"似乎" - 验证前就表达满意（"太好了！"、"完美！"、"搞定！"等） - 即将提交/推送/创建 PR 却没有验证 - 信任代理的成功报告 - 依赖部分验证 - 想着"就这一次" - 累了想赶紧收工 - **任何暗示成功但实际未运行验证的措辞** ## 防止合理化 | 借口 | 现实 | |------|------| | "应该能行了" | 运行验证命令 | | "我有信心" | 信心 ≠ 证据 | | "就这一次" | 没有例外 | | "Linter 通过了" | Linter ≠ 编译器 | | "代理说成功了" | 独立验证 | | "我累了" | 疲劳 ≠ 借口 | | "部分检查就够了" | 部分检查什么也证明不了 | | "换个说法这条规则就不适用了" | 精神大于字面 | ## 关键模式 **测试：** ``` ✅ [运行测试命令] [看到：34/34 pass] "全部测试通过" ❌ "应该能通过了" / "看起来对了" ``` **回归测试（TDD 红-绿）：** ``` ✅ 编写 → 运行（通过）→ 回退修复 → 运行（必须失败）→ 恢复 → 运行（通过） ❌ "我写了回归测试"（没有经过红-绿验证） ``` **构建：** ``` ✅ [运行构建] [看到：exit 0] "构建通过" ❌ "Linter 通过了"（linter 不检查编译） ``` **需求：** ``` ✅ 重读计划 → 创建核对清单 → 逐项验证 → 报告缺口或完成 ❌ "测试通过了，阶段完成" ``` **代理委派：** ``` ✅ 代理报告成功 → 检�� VCS diff → 验证变更 → 报告实际状态 ❌ 信任代理报告 ``` ## 为什么这很重要 来自 24 次失败记录： - 搭档说"我不信你"——信任被破坏 - 未定义的函数被交付——会直接崩溃 -