Skip to main content
Verify 以已确认的需求为准，逐项判断实现是否达标；Builder 自己声明“已完成”仅作为线索，不构成结论。 Comet RC1 使用三层验证建立结论：新的只读 Reviewer Subagent 先审查候选实现，Runtime 再执行必要检查，最后由新的只读 Verifier Subagent 对照 brief.md、Specs 和验收项逐项判断。完成结论只能来自验收，代码修改只发生在 Build 阶段，Verifier 全程只读。

​
不同结果的处理方式

每次 Verify 结束，Runtime 会把结果归到下表几种情况之一。多数情况自动推进；少数情况会暂停等待你处理。先对上结果类型，再看你要做什么、流程去向哪里。 “验收未通过”和“Verifier 执行出错”不是一回事。前者说明实现仍不符合需求，或需求本身有问题，后者说明验收任务本身没有正常完成。Runtime 会分别记录，避免把基础设施故障误判为产品失败。 需要你从命令里做明确选择的暂停只有表里的两行，每个选项的语义和命令在下一节说明。

​
用户决定是否接受结果或调整目标

当 Skill 启动的最终 Verifier 已判断全部通过，但平台无法向 Runtime 证明它与 Builder 是独立执行时，Runtime 会暂停并提供三个互斥选项： 三个选项都通过 comet native next 提交：
如果平台根本无法启动语义 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 声明可能受本轮修改影响的验收项。
已经通过且未受影响的项目不需要在每轮修复中重复验收。不过，局部范围全部通过后还要过最后一关：Runtime 会把完整验收列表重新置为待验收，启动一个新的 Verifier Subagent 做最终全量验收，通过后才允许归档。 这种“局部修复，最终全量确认”的方式减少了重复工作，同时防止修复一个问题时引入新的回归。

​
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 协议参考

前面的选择建立在下面的机制上。日常做选择不需要先读完这些细节；当你想知道结果如何产生、边界如何判定、上限如何执行时，再读本参考。

​
三层验证

这三层关注的问题不同：Reviewer 关注代码质量，Runtime 证明命令确实执行，Verifier 判断功能是否符合需求。三层的结论共同决定最终结果。

​
候选实现带着独立审查进入 Verify

Builder 完成一轮实现后，必须先启动一个新的只读 Reviewer Subagent。Reviewer 检查本轮代码改动、相关测试和当前验收范围；发现问题时，Builder 修复后需要重新审查。 审查通过后，Builder 向 Runtime 提交一份精简的 handoff，其中包括：
  • 本轮完成了什么；
  • 处理了哪些验收 ID；
  • 实际运行或没有运行哪些开发期检查；
  • 当前已知限制；
  • Reviewer 的通过状态、简短摘要和执行标识。
Reviewer 的执行标识必须与 Builder 不同。Runtime 会把 handoff 保存到 comet-state.yaml，并绑定候选 ID、iteration 和 Builder 身份。handoff 是待验收候选的状态记录；是否通过，由后续验收决定。

​
Runtime 先执行检查，Verifier 再逐项验收

候选实现进入 Verify 后，流程按以下顺序推进：
  1. 确定验收范围。 首轮 Verify 覆盖全部验收项；后续每轮修复只覆盖上一轮未解决项和本次修改可能影响的项目。
  2. 执行必要检查。 Runtime 运行测试、构建或其他项目命令，并记录状态、退出码、耗时和摘要。项目策略携带的验证命令（见项目知识）也会作为必要检查在这里执行，只有真实通过才能把对应策略升级为 enforced。
  3. 准备验收上下文。 verifierDispatch 提供实际工作区、需求和证据位置、当前 scopeIds、Reviewer 摘要以及 Runtime 检查结果。
  4. 启动新的 Verifier Subagent。 Verifier 保持只读，对当前范围内的每个验收 ID 给出一次结论。
  5. 校验并接受结果。 Runtime 检查候选、身份、轮次、attempt 和验收范围是否匹配，再决定下一步。
Verifier 会先阅读当前验收场景、brief.md、完整目标 Specs、实际实现和 Runtime 检查结果，最后才把 Builder handoff 当作调查线索。这种顺序可以减少 Builder 自述对验收判断的影响。 每个 scopeId 必须恰好出现一次，并且只能标记为：
  • passed：实现已经满足该验收项；
  • failed：实现不满足该验收项，需要回到 Build；
  • blocked：缺少用户决定、外部条件或其他必要信息，暂时无法判断。
漏项、重复项、未知 ID、身份不匹配或迟到的旧结果都会被 Runtime 拒绝。Runtime 检查全部通过，Verifier 才能提交整体通过的结论。

​
补充检查仍由 Runtime 统一执行

如果现有证据不足，Verifier 可以通过 request-checks 请求额外检查。它只说明需要运行什么，命令仍由 Runtime 执行并记录。 补充检查属于当前 Verifier attempt，不会单独增加 attempt。Runtime 会复用当前候选已经完成的相同检查，过滤重复请求，并把新结果交回同一个 Verifier。RC1 为每次 attempt 最多提供 2 轮补充检查，避免验收无限追加命令。 完整的 stdout 和 stderr 保存在本机日志中，用户报告只显示结论和必要摘要。长输出只截断预览，检查结果本身照常判定。

​
修复轮次设有明确的次数上限

Runtime 通过未解决验收项是否真正减少来判断进展。只有当前未解决项比上一轮更少，而且没有新增未解决项，才算可靠收敛。
  • 连续两轮没有可靠进展时，Runtime 会要求 Builder 更换修复思路；
  • 连续三轮仍没有进展时，流程进入 await-user；
  • 验收失败轮次达到 native.max_verify_failures 时进入 await-user，默认上限为 5；
  • Verifier 连续执行出错 3 次时进入 blocked，等待明确的重试动作。
这些计数都由 Runtime 更新。重复同一条命令、改写说明文字或再次报告相同原因，都不会重置失败历史。 继续阅读 Native Loop，了解完整的 Build ↔ Verify 循环。阅读 连续推进 和 恢复手册，了解状态推进与异常恢复。
最后修改于 2026年9月4日