comet-verify

Comet 第 4 阶段：验证

首次进入某个阶段、移交给新的 Agent 或恢复上下文时，请阅读并遵循 任务上下文与制品语言。优先使用当前 continuation 或已认领 Action 的 contextRequest；在同一阶段持续工作期间，不要重复检索。

进入阶段后返回布局时，请遵循 comet-classic/reference/classic-layout.md，将每个逻辑根目录绑定到其目录。如果协议已在上下文中，则不要重新加载。调用 OpenSpec CLI 时使用适配器，路径使用已绑定的 <classic-*> 根目录；不要先额外运行 root show。

SDK 运行路径

首次进入当前 SDK 阶段、移交给新的 Agent 或恢复上下文时，请阅读 阶段进入与恢复 以及该参考文档中当前阶段的章节。如果本会话中已提供且仍有效，请重复使用。继续执行下方阶段；基于 nextAction.kind 的恢复路由仅适用于没有 continuation mode 的旧版响应。

对同一变更、工作区和 Run，重复使用最新的有效响应：agent.continuation、data.nextAction、阶段、修订版本和路径摘要。仅在冷恢复、工作区或外部状态发生变化、响应版本过期，或缺少当前步骤所需信息时，才运行 comet state next <change-name> --json；加载下一个 Skill 并非再次查询的理由。运行时仍会在写入时验证当前版本和证据；缓存的上下文不能绕过检查或审批。确认 data.runtimeFormat: sdk、data.phase: verify 和 nextAction.kind，并在已绑定的 projectRoot 中工作。仅当路径缺失或绑定发生变化时，才运行 comet classic workspace resolve <change-name> --json；仅当缺少当前任务、工作区或证据摘要时，才使用 comet state check <change-name> verify --json。对于 reconcile，使用 comet state check <change-name> verify --recover --json 调查原始 Action 和检查；如果结果仍然未知，请停止。

1. 遵循 SDK 执行方法中的风险评估、综合审查和轻量／完整验证方法，但以 SDK Run 作为证据依据。不要调用旧版 state scale、state set、comet handoff 或 comet check 证据命令。对于实现或任务缺陷，请报告具体故障。仅当 <profile>.verify.run 处于待处理状态（<profile> 为 full、hotfix 或 tweak）时，才运行 comet state transition <change-name> verify-fail --reason "<failure-reason>"。该命令会记录失败的 Verify Action 并返回 Build。根据该响应中的当前 Build Action 继续；仅当 continuation 信息缺失时，才查询 state next --json。报告另一个故障前，请先调查已有的失败或未知检查。
2. 验证通过后，在仓库报告 <report-ref> 中写明实际检查、证据引用、独立审查和可接受的偏差。直接运行 comet guard <change-name> verify --report <report-ref> --apply -- <program> [args...]，并提供明确且完整的验证命令。Guard 会在一次 Run 中记录报告、证据和实际检查回执；手动声明并不足够。检查失败时，使用同一响应中的失败回执和当前 Build 或 Verify Action；仅当这些信息缺失时，才查询 state next --json，并遵循最新的 Action。
3. Guard 成功后，直接使用该响应；仅当缺少阶段或 nextAction 时，才运行 comet state next <change-name> --json。仅当阶段为 Archive 且 nextAction.kind 指向该处时，才加载 /comet-archive。验证通过本身并不授权进入 Archive；请在那里获取当前交付决策。

兼容路径

其余原始 Runtime 步骤仅适用于 runtimeFormat: compat。请阅读 兼容操作，并继续当前阶段。SDK 不会加载该参考文档。