brief.md、Specs 和验收项独立判断。完整自查和通过的检查都不能代替独立验收；代码修改只发生在 Build 阶段，Verifier 全程只读。
不同结果的处理方式
每次 Verify 结束，Runtime 会把结果归到下表几种情况之一。多数情况自动推进；少数情况会暂停等待你处理。先对上结果类型，再看你要做什么、流程去向哪里。
“验收未通过”和“Verifier 执行出错”不是一回事。前者说明实现仍不符合需求，或需求本身有问题，后者说明验收任务本身没有正常完成。Runtime 会分别记录，避免把基础设施故障误判为产品失败。
需要你从命令里做明确选择的暂停只有表里的两行，每个选项的语义和命令在下一节说明。
用户决定是否接受结果或调整目标
当 Skill 启动的最终 Verifier 已判断全部通过，但平台无法向 Runtime 证明它与 Builder 是独立执行时，Runtime 会暂停并提供三个互斥选项：
三个选项都通过
comet native next 提交：
--accept-result --finish keep。Comet 会先展示实际工作区和各选项的影响，再按你的选择继续；完整选项见 归档与交付。
如果平台根本无法启动语义 Verifier，即使所有 Runtime 检查都通过，也只能得到降级结果。此时 Runtime 会暂停并给出两个选项：重试验收（comet native next <change> --retry-verifier，保留当前候选和已完成的检查，只发起新的验收尝试）或接受降级结果（在明确确认后用 continuation 返回的 --confirmed 动作接受）。确认接受后，报告仍会保留降级标记，注明这不是一次独立验证。
两条路对应的命令：
--expected-state-version 和 --expected-action。如果状态已经变化、操作来自旧页面或旧任务，Runtime 会拒绝执行，避免迟到决定覆盖当前结果。
局部修复后必须再次全量验收
选择--revise-implementation 或让 failed 项返回 Build 之后，Runtime 按下面的规则安排修复与再验收。
出现失败检查或 failed 项时，Runtime 会把各项失败原因写入最新 continuation，并把当前变更送回 Build。Builder 根据失败原因修改实现，补齐受影响验收项的自查，再提交新的候选实现。遇到 blocked 项时，Runtime 会先等待用户或外部条件补齐，不会把缺少信息误当成代码缺陷直接修改。
Builder 重点处理两部分内容：
- 上一轮仍未解决的验收项；
- Builder 声明可能受本轮修改影响的验收项。
Supervisor Change 在集成工作区完成最终验收
Supervisor Change 的子任务必须依次达到active、verified 和 integrated。子任务通过自己的验收，不代表整个 Supervisor Change 已经完成。
所有子任务集成后，Runtime 会在 Supervisor 的集成 worktree 中运行至少一项集成检查，并对完整验收范围执行最终 Verify。集成后的结果失败时，Runtime 会保留现场，根据实际失败项补充修复子任务，并重新确认 Shape；已集成的子任务保持原状。
验证报告缺失时可重建
verification.md 是面向用户的验收报告，包含 Runtime 检查、逐项结果、风险、限制和最终结论。验收结论同时记录在 comet-state.yaml，因此报告缺失、写入中断或版本落后时，可以根据记录的结论重新生成。
换到另一台设备后，旧设备上的本机执行不能直接沿用。处于 verify-ready 的候选会重新运行必要检查并启动新的 Verifier；处于 archive-ready 的候选也会先返回 Verify，重新确认同步后的实现。恢复过程不计入失败轮次或停滞计数。
无法自动确认的内容交还用户
Runtime 可以确认命令是否真正执行、退出码是否正常、验收项是否完整，以及返回结果是否属于当前候选和当前attempt。正常 Archive 直接使用已经接受的验证结果，无需重复运行同一批检查。
如果一项结论依赖测试本身是否合理，或依赖平台没有提供的后台进程、IDE 写入和外部系统状态，Runtime 就不能独自确认。平台无法提供独立 Verifier 或无法完成语义验收时，Dashboard 和报告会直接说明缺少什么，并把是否接受当前结果的决定交还用户。
Verifier 协议参考
前面的选择建立在下面的机制上。日常做选择不需要先读完这些细节；当你想知道结果如何产生、边界如何判定、上限如何执行时，再读本参考。三层验证
Builder 提供实现与证据线索，Runtime 证明检查确实执行，Verifier 判断功能是否符合需求。最终验收结论由 Verifier 独立给出。
候选实现带着完整自查进入 Verify
Builder 完成一轮实现后，逐项核对全部已确认验收要求：实现是否完成、位置在哪里、哪些检查或其他证据能够支持、还有什么限制。发现遗漏时继续在 Build 修复。普通候选和 Supervisor 父候选不强制再派一个预审 Reviewer；独立 Verifier 仍然必需。 自查完成后，Builder 向 Runtime 提交一份精简的handoff，其中包括：
- 本轮完成了什么；
- 处理了哪些验收 ID；
- 实际运行或没有运行哪些开发期检查；
- 当前已知限制；
- 每个已确认验收项的实现与证据自查。
handoff 保存到 comet-state.yaml，并绑定候选 ID、iteration 和 Builder 身份。handoff 是待验收候选的状态记录；是否通过，由后续验收决定。
Runtime 先执行检查，Verifier 再逐项验收
候选实现进入 Verify 后，流程按以下顺序推进：- 确定验收范围。 正式 Verifier 覆盖当前候选的全部验收项，修复摘要指出上一轮未解决项和本次修改可能影响的项目。
- 执行必要检查。 Runtime 运行测试、构建或其他项目命令，并记录状态、退出码、耗时和摘要。项目策略携带的验证命令（见项目知识）也会作为必要检查在这里执行，只有真实通过才能把对应策略升级为 enforced。
- 准备验收上下文。 Builder 检查成功的同一响应直接返回
verifierDispatch，包含实际工作区、需求和证据位置、当前验收范围、启动回执输入以及 Runtime 检查结果，无需额外查询或重复派发。 - 启动新的 Verifier Subagent。 Verifier 保持只读，对当前范围内的每个验收 ID 给出一次结论。
- 校验并接受结果。 Runtime 检查候选、身份、轮次、
attempt和验收范围是否匹配，再决定下一步。
brief.md、完整目标 Specs、实际实现和 Runtime 检查结果，最后才把 Builder handoff 当作调查线索。这种顺序可以减少 Builder 自述对验收判断的影响。
每个 scopeId 必须恰好出现一次，并且只能标记为：
passed：实现已经满足该验收项；failed：实现不满足该验收项，需要回到 Build；blocked：缺少用户决定、外部条件或其他必要信息，暂时无法判断。
等待原 Verifier，而非重复派发
任务包提供启动回执输入。尚未确认启动时，Agent 先核对平台是否接受启动并找回原任务；已经确认启动后，继续等待同一个 Verifier。回执迟到或等待工具超时，本身不算执行失败。只有平台确认任务失败、执行超时、任务丢失或结束后没有可用结果时，才登记错误并按当前指引重试。补充检查仍由 Runtime 统一执行
如果现有证据不足，Verifier 可以通过request-checks 请求额外检查。它只说明需要运行什么，命令仍由 Runtime 执行并记录。
补充检查属于当前 Verifier attempt，不会单独增加 attempt。Runtime 会复用当前候选已经完成的相同检查，过滤重复请求，并把新结果交回同一个 Verifier。每次 attempt 最多提供 2 轮补充检查，避免验收无限追加命令。允许重复执行的失败检查可以在现有限额内显式请求重跑，断言失败仍然算失败，不自动循环重试。
完整的 stdout 和 stderr 保存在本机日志中，用户报告只显示结论和必要摘要。长输出只截断预览，检查结果本身照常判定。
修复轮次设有明确的次数上限
Runtime 通过未解决验收项是否真正减少来判断进展。只有当前未解决项比上一轮更少，而且没有新增未解决项，才算可靠收敛。- 连续两轮没有可靠进展时，Runtime 会要求 Builder 更换修复思路；
- 连续三轮仍没有进展时，流程进入
await-user； - 验收失败轮次达到
native.max_verify_failures时进入await-user，默认上限为5； - Verifier 连续执行出错
3次时进入blocked，等待明确的重试动作。