prove-claim

证明声明

铁律

NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE

如果证明命令刚才没有在本次会话中运行，那么你就无法使用该声明。未经验证的声明不是乐观，而是虚假陈述。

门控函数

在提出任何状态声明或表达满意之前：

1. 识别 — 哪条命令能证明这个确切的声明？（命令见 docs/agents/project.md。如果没有？请说明，并建议使用 configure-repo，然后手动确定命令。）如果声明是某条记录现在保存了一项变更——例如工单、远程端或已存储的行——那么证明命令必须是读取命令，而不是执行写入的命令。因此，识别结果是一对命令，单独执行写入命令永远无法通过此门控。
2. 运行 — 全新且完整地执行：运行项目的完整套件命令，而不是限定路径或模式的子集。不能使用缓存结果，也不能说“之前通过了”。限定范围的运行结果只属于该范围，绝不能算作整个套件的结果——如果把它们说成是整个套件的结果，即使确实运行了命令，该声明仍然是假的。
3. 读取 — 阅读完整输出：退出代码、失败数量、警告。不能只看最后一行。
4. 确认 — 输出是否确实支持该声明？如果不支持：提供证据，报告实际状态。如果支持：提供证据，作出声明。

跳过任何一步都不是验证，而是在撒谎。

声明 → 证据

声明	要求	永远不够
“测试通过”	全新运行完整套件，失败数为零，并已阅读输出	之前的运行；子集；“应该能通过”
“任务门控通过”	在最终提交上运行该门控，并说明其范围：变更单元、它们的依赖项、针对基线的 lint；或者说明升级原因后运行整个套件	把它说成“测试通过”；范围遗漏了变更单元或依赖项
“构建/lint/类型检查干净”	运行对应命令，退出代码为 0，警告数为零	其他工具通过
“功能正常”	通过运行中的系统驱动受影响的流程并观察结果（必需子技能：使用 validate-feature；产品体验走查时，必须实际执行指南——使用 run-dogfood 的运行文件，或记录人工核对项）	仅有单元测试通过；存在 write-dogfood 指南，但从未实际走查
“错误已修复”	重新测试原始症状，确认其已消失	代码已更改
“Agent/子 Agent 已完成 X”	你亲自检查了差异	Agent 自己报告成功
“工单已更新/移至新状态/已评论”	写入后重新读取记录——通过跟踪器自带的读取命令重新读取问题，并确认其中包含确切变更	写入命令的成功提示；退出代码为 0；你运行过该命令
“满足要求”	仅文档的审计追踪检查干净（必需子技能：使用 audit-trace——检查任务/定义完整性，而不是在测试中搜索 ID），并且根据观察到的行为逐项核对每个验收标准	仅有测试通过；测试文件中存在 CODE-N.M 字符串
在账本或检查点上写“已验证”	该行写明证明命令以及该次运行覆盖的范围	仅有 ID（Verified: BILL-1.4）；“整个套件通过了”

防回归模式

回归测试只有在明确捕获到错误后才算数：

write test → passes → revert the fix → test MUST fail → restore fix → passes

还原后仍能通过的测试，什么也没有测试。

危险信号——停止并运行检查门禁

• “应该能行”、“大概”、“看起来能行”、“我有信心”
• 尚无证据就表示满意（“太好了，完成了！”）
• 根据之前某次运行的记忆作出断言
• 账本中的 Verified: 行只有一个 ID，没有命令和覆盖范围
• 写入命令打印了成功信息，但你没有重新读取它声称已更改的记录
• 准备提交、推送或创建 PR，却没有重新运行检查
• 感到疲惫，想尽快结束任务——筋疲力尽不是证据

想法	事实
“现在应该能通过了”	运行检查
“我十分钟前刚运行过”	代码之后有改动；再运行一次
“Agent 说成功了”	查看差异
“部分检查就够了”	部分检查无法证明其余部分
“我运行了所改文件的测试”	你只运行了一个子集，却把它的数量说成整个测试套件的数量。回归问题存在于你没选的文件中
“Verified: BILL-1.4 就够了——我刚运行过整个测试套件”	ID 不代表覆盖范围。这一行要写明命令及其覆盖内容
“我最后会把所有内容一起验证”	每项断言都应在提出时验证；最后才一起验证，会让之前不实的断言暂时被当成事实
“合并后 CI 会发现问题”	CI 在断言发布后才运行；检查门禁应在你作出断言之前，而不是等别人承担后果
“只是换了种说法，所以这条规则不适用”	这条规则也适用于转述和暗示

运行命令。阅读输出。然后——只有到那时——再说。