review_mode 控制 Classic 在 build 阶段何时派发任务级代码审查、允许多少轮修复，并决定 verify 阶段最终综合审查的强度。build 内：off 不派 reviewer；standard 只审查风险任务；thorough 审查每个任务。整个变更的最终综合代码审查只发生在 verify 阶段，build 完成全部任务后不再追加 reviewer。
review_mode 只管流程内的自动审查。你也可以随时手动调用
/comet-review，对当前 change 做一次只读按需审查；它独立于
review_mode，也不推进工作流。它只报告实现 diff 中的正确性、安全、边界和覆盖问题，不修改文件、更新状态或替代 Verify。怎么选 review_mode
选哪一档，先看变更的风险面，再确认你能接受的时间与 token 开销。hotfix / tweak 默认off，新建 full workflow change 默认 standard；具体设置与生效范围见「怎么设置」。
三种模式的总对比：
三档模式的成本差异
三档的成本差异是结构性的。off 的 N 个任务一个任务级 reviewer都不派，最快也最省 token。standard 只给命中风险信号的任务派 reviewer，每个此类任务最多 1 轮自动修复。thorough 的开销是结构性的：N 个任务就会派 N 个任务级 reviewer，每个 reviewer都可能触发最多 2 轮修复。对 12 个任务的变更，standard 可能只给少数风险任务派 reviewer，而 thorough 会跑 12 次逐任务审查，审查 + 修复的 agent 数量是 standard 的数倍。
off、standard 和 thorough 对应不同的审查次数与 token 成本
一次任务会经历什么
review_mode 决定的是 build 阶段每个任务是否、在何时拿到任务级 reviewer，以及审查发现问题后能自动修几轮。三个模式共享同一个任务基线：实现者自测、提交、报告证据（包括主动上报的风险信号），coordinator 核验通过后勾选任务并派发下一个。下面按 subagent-driven-development 的流程描述；executing-plans 由主会话直接执行任务，审查形态不同，见「最终综合审查（verify 阶段）」与后文「与 build_mode 的配合」。
standard：命中风险信号才审查
选standard 的任务默认不派发任务级 reviewer。coordinator 读完实现者主动上报的内容并审查 diff 后，只有当上报内容命中风险信号，或 diff 审查发现风险信号时，才给这个任务派 1 个任务级 reviewer，审查范围是 spec 合规 + 代码质量（风险信号清单见后文）。审查没有 CRITICAL/IMPORTANT 发现时，任务核验通过后直接勾选、进入下一个；发现 CRITICAL/IMPORTANT 则进入 review-fix，最多 1 轮，每轮修复后复审。复审仍未通过 → 标记 BLOCKED，暂停并交给你处理。
thorough：每个任务都审查
thorough 下每个任务都会被派一个全新的后台任务级 reviewer，审查范围同样是 spec 合规 + 代码质量。它不做按批次的合并审查。高风险变更需要对每个任务做即时、聚焦的审查，把问题拖到批次边界再抓代价太大。CRITICAL/IMPORTANT 发现进入 review-fix，最多 2 轮；复审仍未通过 → 标记 BLOCKED，暂停并交给你处理。
off：没有自动审查，靠实现证据
off 在 build 阶段不派发任何自动 spec reviewer、代码质量 reviewer或审查修复 agent。任务是否完成，由实现者的自测、构建/测试证据、当前 worktree 确认和勾选前的核验决定。off 模式必须在持久化产物（tasks.md、commit body、验证报告草稿等）里记录跳过自动代码审查的原因。
- hotfix 和 tweak 预设默认
off。 - full workflow 也可以显式选
off，但离开 build 前必须确认这个选择并记录原因。
最终综合审查（verify 阶段）
整个变更的最终综合代码审查只在 verify 阶段执行。 build 完成全部任务后不会再追加最终 reviewer，而是直接进入 verify。review_mode 只决定 verify 是否执行这次自动代码审查：off 跳过并记录原因，standard 和 thorough 都会执行。
executing-plans 的边界如下：主会话直接执行任务，不会有 subagent-driven-development 那样的任务级 reviewer。代码审查面向已完成 diff，强度随 review_mode 调整。
standard 在 build 内不请求整变更审查，任务全部验收后直接进入 verify。
thorough 每完成 3 个任务做一次分段审查（总任务不超过 3 个时 build 内无审查），分段审查只覆盖该段 diff。整个变更的最终综合审查仍在 verify 阶段执行。
verify 阶段的审查由
verify_mode（light/full）驱动，不占 build 的审查预算。
review_mode 只决定 verify 是否触发自动代码审查（off
跳过；standard/thorough 在 light 验证下跑一次轻量代码审查，在 full
验证下依赖 openspec-verify-change）。verify 阶段没有单独的 per-
review_mode“完整”代码审查——权威行为见 verify 阶段文档。三种模式一图看懂
下面这张流程图汇总 build 阶段三种模式的任务级审查与修复流程。build 只按下图分支派发 reviewer，不额外增加；分支内标注的修复轮数就是该模式的自动修复上限。风险信号清单
命中以下任意一条即标记为风险任务（实现者主动上报 + coordinator diff 审查共同判定）。这是standard 模式下派发任务级 reviewer的触发依据：
- 跨模块 / 跨子系统协调改动
- 安全敏感面：认证、授权、加密、SQL、外部输入处理、密钥/凭据
- 并发、锁、共享可变状态
- 数据或 schema 迁移
- 公共 API 契约或外部接口变更
- 实现者返回
DONE_WITH_CONCERNS - 单任务 diff 超过 200 行
与 Superpowers SDD 的边界
Comet 的subagent-driven-development 扩展现在只依赖 Superpowers 公开的 task reviewer 契约：实现者完成任务后，协调者按任务材料、真实 diff、测试证据和风险信号决定是否派 reviewer。Comet 不读取、不写入、也不要求 Superpowers subagent-driven-development 的内部脚本名、workspace 路径或私有实现细节。
这意味着：
- Superpowers 仍提供连续任务调度、预检查 plan review、文件型 handoff、reviewer 中立提示、“材料不足无法验证” 的反馈语义，以及 progress reconciliation。
- Comet 只接管 reviewer 触发策略和 review-fix 预算，也就是
review_mode决定哪些任务要 task reviewer。 - 文档、恢复和测试都以公开行为为准，不把 shipped Skill 文案绑定到 Superpowers 内部目录结构。
在 build 阶段选择
off、standard 或 thorough。Superpowers SDD 可以独立升级实现，但需要继续满足公开的 task reviewer 契约。派发模型的选择规则（强制）
每一次实现者/修复者/reviewer派发都必须显式指定模型。省略模型会静默继承会话里最贵的模型，拖慢执行并抬高成本。遵循 Superpowerssubagent-driven-development 的 Model Selection 规则：
省略模型 = 让它跑会话里最贵的模型，直接违背这条规则的目标。
与 build_mode 的配合
executing-plans review gate（强度随 review_mode 调整）
executing-plans 下主会话直接执行任务（没有隔离的实现者子代理），所以没有 subagent-driven-development 那样的任务级 reviewer。代码审查针对已完成 diff，强度随 review_mode 调整：
review_mode: off：不做自动代码审查，不加载requesting-code-review。在验证报告草稿或 tasks.md 记录跳过原因，任务验收后进入 verify。review_mode: standard：build 内不请求整变更审查，任务全部验收后直接进入 verify。review_mode: thorough：每完成 3 个任务做一次分段代码审查（仅针对该段 diff），用requesting-code-review针对该段 commit 区间；总任务 ≤ 3 时 build 内不做任何审查，直接进入 verify。这是executing-plans下最接近逐任务审查的做法：主会话没有隔离的实现者子代理，无法逐任务派发 reviewer。
- 分段审查对应的
requesting-code-review必须在进入 verify 前完成加载。 - 如果必需的审查 Skill 无法加载，停止并报告失败，不得静默跳过。
- CRITICAL/IMPORTANT 发现（安全漏洞、数据丢失风险、构建/测试失败）必须在进入 verify 前修复。
- 非 CRITICAL 发现可以接受，但必须把原因和影响记录到持久化产物。
Reviewer 怎么工作
在subagent-driven-development 下，审查由全新的后台 agent执行。reviewer 会获得完整任务、实现 commit/diff 和（开启 TDD 时）RED/GREEN 证据，并必须直接核对真实代码后再下结论。
修复 agent 也是全新后台 agent，根据审查反馈独立修改代码。
进度检查点
coordinator 维护.comet/subagent-progress.md，记录每个任务的实现 commit、改动的文件、RED/GREEN 证据、所选 review_mode、已过的审查阶段、未解决的审查反馈、当前 review-fix 轮数（standard 最多 1、thorough 最多 2、off 为 0），以及 standard 模式下该任务是否已触发过风险任务审查（恢复时不重复派发已完成的任务审查）。
怎么设置
优先级
review_mode 的解析优先级：
.comet.yaml；hotfix/tweak 直接硬编码为 off。
从 0.4.0-beta.1 起，新建 change 的默认值从
null（关闭）改为 standard
：comet init 和新 change 创建快照时，若环境变量和项目配置都没有设置
review_mode，默认写入 standard（风险触发的逐任务审查），而不再是无审查。
已经存在的 change 不受影响：缺少该字段的存量 full change 在离开 build 时会被守卫拦截，
提示先运行 comet state set <change> review_mode <off|standard|thorough> 再继续。项目默认值
编辑.comet/config.yaml：
.comet.yaml。注意：环境变量和项目配置只在 resolver 层提供默认值，不影响已写入 change 的 review_mode。
单个 change
full workflow 在 build Step 3（执行方式选择）时由用户选择，通过comet-state 写入：
环境变量
review_mode。
硬约束（full workflow 离开 build）
review_mode 是 full workflow 的硬性门禁，由两层独立检查强制：
两层都必须通过才能离开 build。hotfix/tweak 豁免这个检查（它们默认
off）。
review_mode 不是必填字段，0.4.0 之前的
.comet.yaml 文件不用迁移就能解析。强制检查发生在 build→verify 的阶段守卫上，旧文件缺少该字段时走兼容路径，恢复时应回填。非法值（非 off/
standard/thorough）会被枚举校验拒绝。状态转换交互
review_mode 是 build 阶段的门禁字段。它不会改变 transition event 的字段 effects，但会在 build-complete 前作为硬性决策被检查。相关转换：
build-complete→ 调用requireBuildDecisions（含 review_mode 检查），通过后phase: verify, verify_result: pending。verify-pass→ 要求verification_report存在且branch_status: pending，然后写入phase: archive, verify_result: pass；handled由 Archive 在最终交付确认后写入。verify-fail→verify_result: fail, phase: build（回滚，下次 build-complete 时 review_mode 必须再次满足）。
下一步
- Classic 配置 — review_mode 字段和配置优先级
- build 阶段 — review_mode 在 build 中的使用位置和 build_mode 配合
- verify 阶段 — verify 中 light 路径的审查检查（由 verify_mode 驱动）
- 上下文压缩机制 — 另一个影响执行开销的项目配置项