模型能够写出代码，不等于结果已经满足需求。它可能漏掉一条验收项，也可能把“测试命令运行过”误当成“功能已经通过”。
Native Loop 要解决的，就是从写完代码到确认满足需求之间的这一步：Builder 负责实现，Runtime 负责控制流程和保存证据，全新的只读 Verifier Subagent 则根据
brief.md、Specs 和验收项独立判断。只有必要检查和最终全量验收都通过，当前变更（change）才能归档。
每一轮实现都有明确约束：输入是什么、已有哪些证据、还允许失败或重试多少次、满足什么条件就停止，模型不会无限地自我反思下去。
实现与验收的循环
Agent 与 Runtime 的职责划分
Builder 提交的是候选实现，不是“已经通过”的证明。进入 Verify 前，Builder 必须逐项自查全部已确认验收要求的实现位置、证据和限制；遗漏或未完成时继续 Build。Runtime 再执行必要检查，独立的只读 Verifier 判断实现是否真正满足需求。自查不能代替独立验收。
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 重点修复 A3、A7，并核对本次修改影响的其他项目。新的 Verifier 仍会检查 A1–A8。- 检查输入变化时，Runtime 重新执行检查；输入、命令、环境和证据仍然有效时才复用。
- 验收未通过时，Runtime 把失败原因返回 Build。
- 完整验收通过后，进入接受结果或归档的下一步，不再追加一轮相同的完整验收。
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 不会因为“这次改了很多代码”就认定取得了进展。它会比较连续两轮仍未解决的验收项：只有未解决项确实减少，而且没有新增未解决项时，才算取得可靠进展。在集合关系上，当前未解决项必须是上一轮的严格子集。 Runtime 会记录以下计数：no_progress_count：未解决验收没有严格减少的次数；failed_iteration_count：实现未通过验收的轮次；execution_failure_count：Verifier 任务本身执行失败的次数。
native.max_verify_failures 限制，默认最多为 5 轮。
“验收未通过”和“Verifier 任务执行出错”是两类不同的问题。前者说明实现仍不符合需求，或需求本身有问题，后者表示 Verifier 没有正常完成任务。最多允许连续出现 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 的自述。
- 独立验收：Builder 自查实现与证据，Runtime 执行检查，Verifier 独立判断需求是否满足。
- 修复成本可控：失败后聚焦未解决项，保留有效检查，再对完整范围独立验收。
- 执行轮次有上限：停滞、失败、执行错误和额外检查都有明确的次数限制。
- 能够安全恢复：状态已持久化落盘，历史响应受版本约束，中断后无需依赖模型的对话记忆即可继续推进。
- 边界对用户透明：需求变化、外部阻塞或独立性不足时，流程会停下来说明原因。