用途
comet-verify 是 Comet 工作流的第四阶段（Phase 4：Verify），用于验证一次 Classic 变更并记录验证结果。当用户调用 /comet-verify，或 Classic Runtime 进入 Verify 阶段时使用。
前提条件
- 代码已提交，Phase 3 已完成。
- tasks.md 中的每个任务均已完成。
主要能力
设置输出语言与校验入口状态
使用本次调用入口结果中的 configuration.language 作为报告语言，不单独查询语言字段。通过 comet CLI 执行状态检查：
comet state select <change-name>
comet state check <change-name> verify --json
若上一阶段的 guard 已返回本阶段状态，则从该状态和 agent.continuation 继续，不重复 select/check；仅在恢复、工作区变更或外部状态变更后运行入口检查。若 select/check 返回 BLOCKED 或分支绑定 ERROR（bound_branch 与当前分支不一致），暂停并让用户选择：返回绑定分支并重跑入口检查，或在用户明确确认当前分支接管该变更后运行 comet state rebind <change-name> 并重跑入口检查。不要自行切换或重绑分支。
评估变更规模
运行：
comet state scale <change-name>
脚本统计任务数、delta specs 和变更文件数，返回 light/full 建议但不改变 verify_mode。使用 --json 获取 data.recommendation、data.selected 和 data.metrics。保留已选模式；否则根据风险选择并用 comet state set <change-name> verify_mode <light|full> 记录。当任务数 > 3、delta-spec 能力数 > 1 或变更文件数 > 8 时，scale 建议 full。
验证前检查未提交改动：属于本次变更的未提交改动应纳入验证输入；Verify 中不得修改或提交实现、测试、任务、delta spec 或 Design Doc。仅文档编辑（comet-build 定义的中性文档集）可在 Verify 中正常完成。若实现存在但 tasks.md 未勾选，直接运行 verify-fail 返回 Build。若无法确定归属或改动属于其他变更，报告停止条件。
返回 Build 修复：
comet state transition <change-name> verify-fail
修复验证失败与处理用户决策
失败时读取连续失败次数和 nextAction。前 3 次可修复失败自动返回 Build：报告失败、运行 verify-fail、调用 /comet-build 仅完成缺失工作。严重程度分类：CRITICAL 仅用于构建失败、测试失败或安全问题；IMPORTANT 用于对核心验收或正确性有确定影响的问题；模糊或不确定的问题标记为 WARNING 或 SUGGESTION。CRITICAL/IMPORTANT 或明确可修复的范围内问题在未达限制时自动返回 Build。WARNING/SUGGESTION 若修复会改变行为、范围或风险权衡，交由用户选择修复或接受。当 verify_failures >= 3 时，不再自动运行 verify-fail，仅提供“继续修复”或“停止此工作流并寻求外部决策”。CRITICAL/IMPORTANT 发现不可豁免。
读取验证所需产物
需要 OpenSpec 产物时，使用入口已返回的 handoff 状态。仅在入口缺少当前比较时运行：
comet handoff <change-name> --hash-only
根据 [HANDOFF] 状态处理：FRESH 复用上下文中已有内容；STALE（changed: <files>）在验证验收前完整读取列出的变更产物；STALE 无文件列表时完整读取所有必需源文件。
最终集成代码审查
Verify 拥有整个变更的唯一最终集成代码审查。在进入 verify_mode 分支前审查最终 diff（含 Build 审查的修复）：review_mode: off 跳过自动代码审查并记录原因；review_mode: standard|thorough 派遣独立审查者审查整个变更，关注正确性、安全性和边界情况。独立审查不可用时停止，实现者自审不能替代。
Light 验证（2a）
检查全部 7 项：
- tasks.md 每个任务已完成 [x]。
- 变更文件与 tasks.md 匹配（对比 git diff --stat 等）。
- 编译通过。
- 相关测试通过。
- 无明显安全问题（如硬编码密钥或新的不安全操作）。
- 最终集成审查通过，或在非 full-autonomous 的 review_mode: off 下记录其省略。
- 核心成功、重要失败/边界情况以及本次变更影响的高风险需求全部通过。
复用 Build 证据：
comet check run <change-name> build --local -- <program> [args...]
仅当 Runtime 返回 reused=true 时才算复用。记录报告路径并运行验证命令：
comet state set <change-name> verification_report docs/superpowers/reports/YYYY-MM-DD-<change-name>-verify.md
comet check run <change-name> verify --local -- <program> [args...]
--local 仅用于确定性本地检查；外部服务检查省略 --local。成功后立即运行 guard，中间不写入 comet state，guard 通过后才提交。
通过标准：全部 7 项通过，无 CRITICAL 或 IMPORTANT 问题。失败时按 Step 1b 报告并分类，需要修复且未达自动限制时返回 Build 并调用 /comet-build。
Light 验证不包含：所有 spec 的逐场景覆盖计数、实现与 Design Doc 的详细对比、与正确性/安全性/边界无关的代码模式一致性建议、delta-spec/Design-Doc 分歧检测。
Full 验证（2b）
规模评估选择大变更时：必须使用 Skill 工具加载 openspec-verify-change，不得跳过。适配外部 OpenSpec 指令：仅使用其验证方法，将直接官方 CLI 调用、固定 cwd 和固定物理 OpenSpec 路径替换为 comet classic openspec -- <args...> 和 resolver 提供的 <classic-*> 逻辑根。
检查项：
- tasks.md 每个任务已完成 [x]。
- 实现遵循 <classic-change-dir>/design.md 的高层决策。
- 实现遵循 docs/superpowers/specs/ 下的 Design Doc。
- 所有能力 spec 场景通过。
- proposal.md 目标达成。
- Delta spec 与 Design Doc 不冲突。
- docs/superpowers/specs/ 下链接的设计文档存在且属于本次变更。
失败时报告缺失项并按 Step 1b 分类。若可在本次变更内完成且未达自动修复限制，返回 Build 并调用 /comet-build。
解决 spec 分歧：若第 6 项发现 delta spec 中有 Design Doc 未反映的内容，暂停并呈现单选问题等待用户，不自动选择。选项 A：向 Design Doc 追加“Implementation Divergence”章节说明偏差（这是允许的 Verify 产物，不触发 Step 1b dirty-worktree 决策；Design Doc 是检查输入而非中性文档，写入后需重跑 comet check run）。
使用方式
通过 /comet-verify 调用，或由 Classic Runtime 在进入 Verify 阶段时触发。所有验证命令通过 Runtime 执行，使用 comet CLI 进行状态管理、规模评估、检查运行和阶段转换。
适用场景
- Classic 变更完成实现后需要验证并记录结果。
- 需要根据变更规模选择 light 或 full 验证模式。
- 需要执行最终集成代码审查、编译与测试验证。
- 验证失败需要分类并决定是否返回 Build 修复。
限制
- 前提是代码已提交且 Phase 3 完成、tasks.md 全部完成。
- Verify 中不得修改或提交实现、测试、任务、delta spec 或 Design Doc。
- 不得自行切换或重绑分支。
- CRITICAL/IMPORTANT 发现不可豁免。
- 当 verify_failures >= 3 时不再自动运行 verify-fail。
- 独立审查不可用时停止，实现者自审不能替代。
- 不得仅凭自我评估宣布验证成功。
- 具体收费、价格、平台支持等信息暂未提供。