TomorrowLM 完成前验证
概述
在没有新鲜证据的情况下宣称完成、修复或通过检查，会把假设误报为事实。
核心原则： 结论必须由与其范围匹配的验证证据支撑。
铁律
没有新鲜的验证证据，不许宣称完成
验证门控
在作出任何完成性结论或表达满意之前：
- 定义结论：明确要声称什么，以及结论覆盖哪些文件、测试、环境或需求。
- 选择证据：确定能直接证明该结论的命令、检查或实际操作；文档、旧日志和主观判断不能替代新鲜证据。
- 执行验证：重新运行适用的完整检查，不把上一次运行结果当作当前代码的证据。
- 检查结果：确认退出码、关键输出、失败数量和验证范围；日志很长时可聚焦摘要和错误，但不得跳过结果核对。
- 匹配结论：只有证据覆盖结论范围时才能宣称成功；否则明确说明已验证、未验证和失败的部分。
跳过其中任何一步，都不能作出对应的完成性声明。
按结论选择证据
| 结论 | 足够的证据 | 不足的证据 |
|---|---|---|
| 测试通过 | 目标范围内的测试命令成功，且确认失败数为 0 | 之前的运行结果、只运行部分测试、"应该能通过" |
| Linter 无报错 | 覆盖声明范围的 linter 成功，且确认错误数为 0 | 格式化成功、部分文件检查、代码阅读推断 |
| 类型检查通过 | 目标项目的类型检查成功并退出 0 | linter 通过、编辑器没有显示错误 |
| 构建成功 | 实际构建命令成功并退出 0 | 测试或 linter 通过、日志看起来正常 |
| Bug 已修复 | 原始失败场景或对应回归测试在最新代码上通过 | 代码已修改、测试未覆盖原始症状 |
| 回归测试有效 | 必要时验证红—绿过程：修改前失败、修复后通过 | 只新增测试并运行一次 |
| 代理任务已完成 | 检查实际 diff、变更文件、需求清单和相关验证证据 | 代理报告成功、只看到有 VCS diff |
| 需求已满足 | 逐项核对需求和验收标准，并为关键项提供证据 | 仅测试通过、仅代码审查通过 |
| MCP 调用结果正确 | 实际调用成功，并核对返回结构、关键字段和预期语义 | 只看到调用日志或无错误返回 |
| API 接口可用 | 在允许的验证环境中实际调用，并核对状态码、响应结构和关键业务结果 | 只看 Swagger、类型定义或 mock 结果 |
验证范围规则
- 验证范围必须覆盖结论范围；单文件、单包或单场景检查不能证明整个项目完成。
- 只验证了部分内容时，使用范围准确的表述，例如“目标测试通过，类型检查尚未执行”。
- 外部服务、API 和 MCP 验证必须考虑环境、权限、数据副作用和安全边界；无法安全实际调用时，应明确标记为未验证。
- 代码审查、VCS diff 和代理报告可以作为辅助证据，但不能单独替代运行验证或需求验收。
- 提交、创建 PR、标记任务完成或进入下一任务前，必须重新确认最新代码的相关验证证据。
验收标准
当完成结论包含“需求已满足”“验收通过”或“功能完成”时：
- 使用已确认的需求、验收标准或测试用例作为验收依据。
- 将验收依据拆分为可独立判断的验收项，逐项核对，不能用整体印象替代。
- 每项验收记录结果和证据，至少区分通过、失败、未验证和不适用。
- 验证范围不足时，只能声明已验证范围，不得扩大为整体完成。
- 发现需求缺失、标准冲突或范围变更时，先返回方案阶段确认，不得在验收阶段自行补充。
- 测试通过、代码审查通过或代理报告成功，均不能单独证明需求已满足。
红线
- 使用“应该”“大概”“似乎”等推测性结论替代验证。
- 验证前表达“太好了”“完美”“搞定”等暗示成功的措辞。
- 因为代码改动很小、代理声称成功或之前检查通过而跳过最新验证。
- 用较窄范围的检查支撑较宽范围的完成声明。
- 验证失败或未执行时，隐瞒实际状态或继续声称成功。
何时使用
任何传达完成、正确、已修复、已通过或可合并含义的沟通之前，包括提交、PR、任务收口和阶段切换。
References 读取条件
| 文件 | 什么时候读 |
|---|---|
references/anti-rationalization.md |
感到时间紧迫、疲惫，或开始寻找跳过验证的理由时 |
底线
验证没有捷径。 运行适用检查，核对新鲜输出，再根据证据准确陈述结果。