brief.md、Specs 和验收项独立判断。只有必要检查和最终全量验收都通过，当前变更（change）才能归档。
本文以 Comet 0.4.0-rc 系列（rc.1 起的实现，下文简称 RC）的实现为准。每一轮实现都有明确约束：输入是什么、已有哪些证据、还允许失败或重试多少次、满足什么条件就停止，模型不会无限地自我反思下去。
实现与验收的循环
Agent 与 Runtime 的职责划分
Builder 提交的是候选实现，不是“已经通过”的证明。每个新候选实现进入 Verify 前，都要先交给一个新的只读 Reviewer Subagent 审查代码。随后，Runtime 才会运行必要检查，并启动另一个全新的只读 Verifier Subagent，判断实现是否真正满足需求。Reviewer 和 Verifier 都不是 Builder 本身，两者也不是同一个任务。
Verifier 会先阅读验收项、
brief.md、Specs、实际实现和检查结果，最后才把 Builder 的总结作为辅助线索。这种阅读顺序可以降低 Builder 自述对验收判断的影响，让实现与验收真正分离。
Runtime 主导的验收流程
- 锁定候选实现。 Runtime 记录候选 ID、当前实现轮次和本次验收范围，确保后续结果对应正确的代码版本。
- 运行必要检查。 Runtime 执行测试、构建或其他项目命令。Builder 提供的检查结果只作为参考，不能替代 Runtime 的实际执行结果。
- 启动新的 Verifier Subagent。 Verifier 以只读方式检查代码，并为当前范围内的每个验收 ID 给出且只给出一次结论。
- 校验返回结果。 如果结果存在漏项、重复项、未知验收 ID、过期响应或身份不匹配，Runtime 会直接拒绝，不会误记为通过。
- 决定下一步。 全量验收通过后可以归档；有验收项未通过时返回 Build；需要产品决定或外部信息时暂停，并把决定权交还用户。
局部修复与最终全量验收
假设完整验收范围是 A1–A8，第一次 Verify 发现 A3 和 A7 未通过。Builder 完成修复后，Runtime 会把 A3、A7 和 Builder 声明可能受此次修改影响的其他验收项，一起交给下一次 Verifier。- 如果局部范围仍未通过，Runtime 会把失败原因返回 Build。
- 如果局部范围通过，Runtime 不会直接归档，而是把 A1–A8 全部恢复为待验收状态。
- 新的 Verifier 完成最终全量验收后，当前变更才具备归档条件。
request-checks 向 Runtime 发出请求，说明还需要运行哪些项目命令；命令仍由 Runtime 执行并记录，Verifier 自己不能运行。对这类请求，Runtime 会限制轮数并过滤重复项目。
完整日志会保存在本机，用户可读的报告只呈现结论和必要摘要。这样既保留了排查问题所需的细节，也不会让大量 stdout 和 stderr 淹没真正重要的验收结果。
进度计数：iteration 与 attempt
Native Loop 使用两个维度定位当前进度：
例如，Runtime 为同一个候选实现启动新的 Verifier 验收尝试时，
attempt 会增加，但 iteration 不变。Verifier 在当前尝试中请求补充检查，不会单独增加 attempt。只有 Builder 修改代码并提交新的候选实现后，iteration 才会进入下一轮。
验收结果只属于它对应的那一次执行：Runtime 记录结果时，会连同候选 ID、执行验收的是哪个 Verifier、当时的 iteration 和 attempt、验收范围一起保存。因此，一个执行较慢的旧任务很晚才返回结果时，如果对不上当前状态，Runtime 不会采用它。长时间运行、中断恢复和多个任务并行时，都靠这条规则保证状态不被旧结果覆盖。
基于未解决验收项的进展判断
Runtime 不会因为“这次改了很多代码”就认定取得了进展。它会比较连续两轮仍未解决的验收项：只有未解决项确实减少，而且没有新增未解决项时，才算取得可靠进展。在集合关系上，这意味着当前未解决项必须是上一轮的严格子集。 RC 会记录以下计数：no_progress_count：未解决验收没有严格减少的次数；failed_iteration_count：实现未通过验收的轮次；execution_failure_count：Verifier 任务本身执行失败的次数。
native.max_verify_failures 限制，默认最多为 5 轮。
“验收未通过”和“Verifier 任务执行出错”是两类不同的问题。前者说明实现仍不符合需求，或需求本身有问题，后者表示 Verifier 没有正常完成任务。RC 最多允许连续出现 3 次执行错误，每次验收尝试最多接受 2 轮额外检查请求。达到上限后，Runtime 会明确暂停，不会无限重试，更不会把异常当作通过。
按问题类型精准回退
Verify 暴露的问题不一定都是代码错误。Runtime 会根据问题类型返回对应阶段：- 实现遗漏或代码缺陷：回到 Build，修复现有实现；
- 用户可见行为或验收标准发生变化：回到 Shape，更新需求并请用户重新确认；
- 出现与当前变更无关的新需求：另建一个 change，避免扩大当前验收范围；
- 缺少用户决定或外部条件：进入
await-user，并说明需要补充什么信息。
可跨任务恢复的持久化状态
Native Loop 不依赖某个模型始终记住全部上下文。Runtime 会把不同用途的状态分别保存：comet-state.yaml保存可同步、可恢复的稳定状态和下一步；verification.md保存用户可读的验收报告；.comet/runtime/native/保存本机运行状态、日志、锁和事务信息。
有明确边界的自动推进
Runtime 会在以下情况停止自动推进，并返回明确动作：- 仍有产品决定、外部条件或
blocked验收项需要用户处理； - 当前代码、分支、worktree 或 artifact root 与 Runtime 记录不一致；
- 没有可靠进展、失败轮次或执行错误达到预算；
- Verifier 不可用，或当前平台无法证明它与 Builder 相互独立；
- 多个并行 change 修改同一项能力（capability），需要先决定归档顺序。
Native Loop 提供的保障
- 完成标准可信：是否允许归档，取决于 Runtime 检查和逐项验收，而不是 Builder 的自述。
- 职责相互制衡：实现、代码审查、检查执行和需求验收由不同角色承担。
- 修复成本可控：失败后聚焦未解决项，最终再做全量确认。
- 执行轮次有上限：停滞、失败、执行错误和额外检查都有明确的次数限制。
- 能够安全恢复：状态落盘，旧响应受版本约束，中断后不依赖模型记忆继续。
- 边界对用户透明：需求变化、外部阻塞或独立性不足时，流程会停下来说明原因。