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。
修复为什么有上限
Verify fail 会回到 Build。Runtime 用 failure category、failed check、contract 和 scope 形成失败签名：- 同一 scope 下第二次相同失败会告警；
- 第三次相同失败且没有真实 scope 进展时进入 manual stop；
- scope 真正变化会开启新的 repair episode；
- scope 未变化但出现一个明确新假设时，同一签名最多 override 一次；
- 单个 episode 最多记录 12 次 failure。