> ## Documentation Index
> Fetch the complete documentation index at: https://docs.comet.rpamis.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 验证证据与自主修复

> 理解 Native 如何形成 implementation scope、验收证据、证据失效与有界修复。

Native 不规定固定的 TDD 或审查方法，但对验证结果有确定性要求：结论必须对应当前需求、规格和真实实现范围，未运行的检查不能写成通过。

## Implementation scope

Build 完成时，模型提交真实项目相对路径。Runtime 将这些产物、当前 change contract、创建时 baseline 与当前项目 snapshot 一起做内容寻址，形成 implementation scope，并派生稳定的 Acceptance ID。

Git 项目的 snapshot 只包含 tracked 与未被 ignore 的 untracked 文件，并把 submodule/gitlink 作为原子条目；非 Git 项目使用有界物理树 provider。当前 snapshot 不完整时，Runtime 不会把缺失路径猜成删除。变化明细超过预算时只展开有界项，其余由带计数与内容 hash 的 `scope-detail-overflow` 表示。

若 Runtime 无法证明范围完整，它会停在 Build 并返回 partial scope hash 与未归属项。优先补充 artifact 或消除未归属变化；只有用户明确接受 Runtime 允许授权的具体缺口时，才能用同一个 hash、理由和 `--confirmed` 推进。`git-selection-changed` 必须等 Git index 稳定后重试，绝不可授权。`git-enumeration-limit` 应先通过缩小或清理项目所有范围、或后续产品预算调整来恢复；仅当恢复不可行、Runtime 返回带计数与内容 hash 的可授权 scope，且用户理解未知尾部风险时，才可使用普通 partial 协议。非 Git 项目的 `physical-selection-changed` 与 `physical-enumeration-limit` 分别要求等待项目树稳定或缩小项目树；两者都无法绑定未知尾部，不能授权。任何完整性失败都不能靠手改 evidence 绕过。

## 验证报告

`verification.md` 至少记录：

* 实际运行的命令与结果；
* 跳过项和原因；
* 已知限制与总体结论；
* 每个 Runtime Acceptance ID 对应的项目内证据引用，或诚实的 `skipped_reason`。

可选的 `comet native check` 只执行有界、只读的文本卫生扫描。它不调用 Git、shell、测试脚本或外部 Skill，也不替代项目测试。结果保存为内容寻址 receipt。

## 证据失效

验证结论会绑定 brief、完整目标规格、implementation scope、revision、报告快照和可选 receipt。任一输入发生变化，旧证据都会变成 stale。

若在 Verify 中发现 contract 或项目 snapshot 已变化，status 会返回只含摘要的 `next`。运行该命令受控退回 Build，并封印新 scope；只有 brief/spec contract hash 也变化时才重新确认。仅项目 snapshot 或 implementation 变化时保留原 approval，不制造额外确认。不要在旧 scope 上提交结论；进入 Archive 后报告、receipt 或其他绑定事实变化时使用同一回退协议，不能复用旧 pass。

<p align="center">
  <img src="https://mintcdn.com/comet-bb5f5294/7jNUkQ90KjmwXcBK/assets/native-illustrations/07-verification-evidence.png?fit=max&auto=format&n=7jNUkQ90KjmwXcBK&q=85&s=cb4c50283ca17c2ce5f13bf6147682a9" alt="小鱼从照片板取下已经褪色的验证凭据，准备在工作台上重新验证，表示输入变化后旧证据失效" width="1672" height="941" data-path="assets/native-illustrations/07-verification-evidence.png" />
</p>

## 修复为什么有上限

Verify fail 会回到 Build。Runtime 用 failure category、failed check、contract 和 scope 形成失败签名：

* 同一 scope 下第二次相同失败会告警；
* 第三次相同失败且没有真实 scope 进展时进入 manual stop；
* scope 真正变化会开启新的 repair episode；
* scope 未变化但出现一个明确新假设时，同一签名最多 override 一次；
* 单个 episode 最多记录 12 次 failure。

这使强模型可以自主修复，同时避免把重复尝试误当成进展。达到停止条件后，应让用户决定范围、约束或是否终止，而不是弱化检查或伪造 pass。

继续阅读：[Native 工作流](/zh/concepts/native-workflow#四阶段工作流)、[安全与恢复](/zh/native/safety-and-recovery) 和 [多 Change 与规格冲突](/zh/native/multi-change-and-conflicts)。