breezing

Breezing — Team Execution Mode

後方互換エイリアス: harness-work をチーム実行モードで動かします。

Default Pipeline（plan → work → review → report を 1 コマンドで完走）

/breezing は「計画 → 実装 → OK が出るまでレビュー → 報告」を 1 回の起動で完走する。 operator が /harness-plan や /harness-review を個別に指示する必要はない（operator 裁定 2026-07-24）。

1. Plan gate: 依頼スコープに対応する task が Plans.md に無い、または不足している場合、先に harness-plan を実行して task を生成してから続行する。既に plan がある場合はそのまま Phase 0 へ。plan 生成時のスコープは harness-plan の「スコープ既定: 今進められる全作業」に従う。
2. Work: 既存の Phase 0 → A → B（per-task review 含む）。
3. Integrated Review Gate（Phase D、既定 ON）: Phase B 完了後、Phase C の最終化（完了報告・run 完了宣言）より前に、run 全体の diff に harness-review を実行する。
   • review target: 通常 run は {base_ref}..HEAD。--no-commit run は commit range が空になりうるため、working tree（未 commit 変更 + untracked ファイル）を対象にする
   • fresh-context の独立 reviewer subagent（実装 Worker と会話状態を共有しない）と、bash "${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh" review --base "${base_ref}" の second opinion を併走させる
   • いずれかが REQUEST_CHANGES 相当 → 修正 → 再レビュー。APPROVE が出るまで反復する（最大 3 回）。未収束の場合は影響 task の marker を cc:WIP に戻し、human escalation で停止して findings と修正状況を報告する
   • primary verdict（APPROVE | REQUEST_CHANGES）は brain（claude host）が出す。role-scoped 制約は維持
4. Finalize + Report（Phase C）: gate の APPROVE を得てから Plans.md 更新・commit・完了報告を確定する。gate 未通過のまま run を「完了」として報告してはならない。最終報告は easy 作法で出す（host session に easy skill があれば invoke してその作法に従う。無ければ harness-work の Completion Report テンプレート）。

--reviewer-only / --no-commit 等の既存フラグは、この pipeline の該当段だけを動かす per-run override として働く。 低リスクの高速 run で Phase D を省きたい時は --no-review-gate を渡す（Phase B の per-task review は省かれない。省くのは run 全体 diff への統合レビューだけ）。

Work Mode Lifecycle (bin/harness work-mode)

R04/R05 の確認 skip が読む ctx.WorkMode は、HARNESS_WORK_MODE / ULTRAWORK_MODE env （skill から設定できない）か SQLite work_states 行のどちらかで立つ。bin/harness work-mode <on|off|status> が後者を書く唯一の入口（harness-work の「Work Mode Lifecycle」節が正本）。

• Lead は Plan gate に入る前（run 開始時）に bin/harness work-mode on を実行する。 --codex run では bin/harness work-mode on --codex を使う（R07 = Lead の直接 Write/Edit 禁止が同時に立つ）
• Lead は run 終了時、成功・失敗・中断の全経路で bin/harness work-mode off を実行する （backend が claude / codex / cursor のどれでも同じ規律。cursor fast path の session declare / --clear と同じ「run 境界で必ず対で呼ぶ」形）
• run 単位で 1 回のみ。task ごとに on/off しない
• session ID が解決できない場合は非ゼロ終了 + 理由が stderr に出る（無言で成功しない）

Breezing run state (breezing-active.json) — guardrail の file producer

Lead は run 開始時に .claude/state/breezing-active.json を書く。guardrail は このファイルを R07（codex mode）と R08（reviewer subagent 判定のスコープ）の file producer として読む（go/internal/guardrail/breezing_state.go）:

{"impl_mode": "codex", "started_at": "<ISO8601>"}

• impl_mode は --codex なら "codex"、それ以外は "claude" / "cursor"
• run 終了時（全経路）にこのファイルを削除する。残すと次の通常セッションでも R07/R08 のスコープ判定が生き続ける
• reviewer teammate（worktree spawn）には env HARNESS_BREEZING_ROLE=reviewer を spawn コマンドの環境に付ける。セッション内 reviewer subagent は CC が付与する agent_type で自動判定されるため追加作業は不要

Narration Rules (UX Contract)

敵は 冗長さ であって進捗報告ではない。起動時に実行計画を簡潔に明示してから実行を開始する。見やすい進捗報告は歓迎する。冗長な繰り返し・中身のない前置きだけを禁ずる。

起動時に必ず出すもの (banner + plan、合計 5 行以内)

最初の応答で、何を・どの順で進めるかを示してから tool 実行に入る:

🚀 cursor / composer-2.5-fast / feat/hah-11-golden-rule-lint / Reviewer
これから:
1. backend/model を resolve
2. composer に advisory findings を委譲 (read-only)
3. brain 一次レビューで verdict を確定 → 3-5 行要約 → Plans.md 更新

banner 1 行 (🚀 <backend> / <model> / <branch> / <task>) + 計画 2-4 行。1 秒以内に出し、即 Step 1 へ。

Backend 默认值与 per-run 平坦判断（2026-07-24 operator 裁定）

默认 backend 为 claude（Native subagent）。resolver 未设置时的 fallback 也是 claude，这不是陷阱，而是有意设定的默认值。 ⚠️ 只有当 resolver 因 无效值 fallback 输出 stderr 警告时，才在 banner 后立即用一行显示警告（正常解析为 claude 时不显示。同一 run 内不重复显示）。

Lead 可以根据工作内容和工作量，按 run 为单位灵活选择 backend。选择时，请使用对 resolver 的显式 override（--backend <v> / --codex / --cursor）。仍然禁止直接读取 env：

工作性质	推荐 backend	原因
常规实现、修复和测试（默认）	claude (native)	Worker 合约（worker-report.v1 / self_review 5 项）全部生效
大规模且独立性高的批量实现，或规避 Claude 侧 rate limit	codex	可通过 xhigh 委派 deep tier（model 由 model-routing.sh 解析）
大量生成 UI、精简快速委派	cursor	lean path（通过 worktree 隔离 + Lead diff review）

不要在 skill 中写模型 ID。权威来源是 bash "${HARNESS_PLUGIN_ROOT}/scripts/model-routing.sh" --host <backend> --role worker。

可以报告进度（以清晰易读为限）

• 每个步骤开始和完成时，用一行状态报告（✓ backend=cursor / model=composer-2.5-fast）
• 提供决策所需的中间结果（pre-check 要点、resolved model、检测到的 branch 等）
• 用一行说明选择该分支的原因（例如：「仅委派 Reviewer：Worker 已在另一条路径上完成」）

禁止事项（= 冗长）

• 重复换种说法描述同一事实：说过一次的内容，后续不要再解释
• 没有实质内容的开场白：例如「确认一下用法」之类，tool call 已能清楚表明的声明
• 超过 3 行的过程回顾：冗长的开场白会拖延结论。需要交代经过时，压缩为一行
• 启动序列中的 ★ Insight 块：Insight 只在最终 report 中出现一次

示例（违规 → 正确）：

× 「composer 2.5 使うモード」= cursor backend で Composer に委託、ですね（解釈の言い換え、中身のない前置き）
○ 🚀 cursor / composer-2.5-fast / feat/hah-11-golden-rule-lint / Reviewer
  これから: backend resolve → composer に advisory findings 委譲 (read-only) → brain 一次レビューで verdict 確定

快速参考

/breezing                       # スコープを聞く（claude backend）
/breezing all                   # 全タスク完走（claude backend）
/breezing 3-6                   # タスク3〜6を完走
/breezing --codex all           # Codex CLI で全タスク委託
/breezing --cursor              # cursor backend lean path (--no-discuss all 既定)
/breezing --cursor --reviewer-only  # Reviewer のみ cursor に委譲（Worker は別系統で既完了）
/breezing composer 2.5 all      # 自然言語 trigger: cursor backend として扱う
/breezing --parallel 2 all      # 2並列で全タスク完走
/breezing --no-discuss all      # 計画議論スキップで全タスク完走
/breezing --auto-mode all       # 互換な親セッションで Auto Mode rollout を試す

Brief Composer v0

对于与任何 argument-hint 都不匹配的自由文本输入，使用 bash scripts/breezing-brief.sh classify "<args>" 判断其属于 structured 还是 free-text。 对于 free-text，将其拆分为 3〜7 个 subtasks，向用户展示 brief-card.v1 卡片，并通过 breezing-brief.sh confirm <yes|no> <card.json> 确认。 有关分解逻辑、schema 和 DISPATCH 合约的详情，请参阅 references/lean-path-detail.md。

选项

Option	Description	Default
all	处理所有未完成任务	-
N or N-M	指定任务编号/范围	-
--codex	委派 Codex CLI 执行实现	false
--cursor	cursor backend lean path（per-run 显式 override。等同于 resolver 输出为 cursor 时的行为）。跳过 Worker 介入 / self_review / sprint-contract 3 段链 / Phase 0，并在 3 秒内开始启动 → 委派	false
--reviewer-only	仅向独立路径委派 Reviewer（前提是 Worker 实现已完成）。与 --cursor 组合时改由 Composer 处理	false
--parallel N	Implementer 并行数	auto
--no-commit	禁止自动提交	false
--no-discuss	跳过计划讨论	在 --cursor 下默认 true
--no-review-gate	跳过 Phase D（Integrated Review Gate）。保留 Phase B 的 per-task review	false
--auto-mode	明确启用 Harness 侧的 Auto Mode rollout。与在 CC 2.1.111 中已不再需要的 --enable-auto-mode 不同	false

--parallel N 与 CC 侧的实际上限（133.9，已通过一手来源确认）

--parallel N 是 Harness 侧的期望值，实际同时运行的数量由 CC 决定。 CC 默认将同时运行的 subagent 限制为 20 个（CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS，2.1.217）。 即使传入大于 20 的 N，超出的部分也只会进入队列等待，不会报错。 也就是说，--parallel 40 并非「40 并行」，而是「20 并行 + 等待」。

嵌套 spawn 默认最多为 3 层（CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH，在 2.1.219 中从 1 放宽至 3）。 Lead（深度 0）→ Worker / Reviewer（1）→ Worker 调用的 advisor 等（2）均在范围内。 Mode 1 的 Producer → Sub-Lead → Composer 也不超过 3 层。 设计超出此层级的结构时，应假设除非通过 env 提高上限，否则 spawn 会被静默拒绝。

Harness 侧不会显式设置这两项的 env（遵循 CC 默认值）。如需更改，请通过 run 的 env 传入。

自然语言后端触发词

composer / コンポーザー / Composer で / composer 2.5 / composer モード 正式作为 cursor backend 的触发词。 这表示与 --cursor 等效的意图，Lead 会通过 resolve-impl-backend.sh 确定 backend。 解析时，将 --backend cursor 作为显式 override 传入，其优先级高于 env / project / user file / default。

输入示例	解释	执行路径
composer 2.5 で	cursor backend	Lead → cursor-companion.sh task --write --workspace <wt>
コンポーザーで全部	cursor backend	Lead → cursor-companion.sh task --write --workspace <wt>
composer モード	cursor backend	Lead → cursor-companion.sh task --write --workspace <wt>

composer 不是在 Claude Worker 内部 spawn 的额外 Agent。 它遵循非 claude backend 的拓扑结构，Lead 不经过 Worker agent，直接调用 cursor-companion.sh。

CC 2.1.111 说明： Opus 4.7 可按字面使用 /effort xhigh。 仅在明确要求时额外使用内置 /ultrareview，不替代默认评审。

长时间会话建议（CC 2.1.108+）： 如果预计会话时长超过 30 分钟，在解析 plugin bundle root 后，运行 bash "${HARNESS_PLUGIN_ROOT}/scripts/enable-1h-cache.sh"，选择启用 1 小时 prompt cache。 此脚本会将 export ENABLE_PROMPT_CACHING_1H=1 追加到 env.local（幂等）。 在超过 1 小时的 breezing 会话中，默认的 5 分钟 TTL 缓存会导致 cache miss 累积， input token 成本可能增至最高 12 倍，因此长时间团队执行时应显式选择启用。 Codex CLI 子进程（例如 scripts/codex-companion.sh task --write）通常通过 env 继承 读取 ENABLE_PROMPT_CACHING_1H，但如果启用了 CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1， 则需要使用显式保留 export 的 shell wrapper。详情请参阅 docs/long-running-harness.md。

执行

此技能委派给 harness-work。 请使用以下设置运行 harness-work：

1. 将参数原样传递给 harness-work
2. 强制使用团队执行模式 — Lead → Worker spawn → Reviewer spawn，三方分离
3. Lead 专注于委派 — 不直接编写代码
4. Auto Mode 视为 opt-in — 接受 --auto-mode 作为兼容的父会话 rollout 标志
5. 仅在需要时调用 Advisor — 只有当 Worker 返回 advisor-request.v1 时，Lead 才调用 advisor

如何处理计划阶段的预先确认

Breezing run 开始时，Lead 会执行与 harness-work 相同的 preapproval preflight。

• 每个 task 开始时，在 task worktree 的 .claude/state/active-task.json 中原子写入 {"phase":"<phase>","task":"<task>"}。task 结束时，无论成功、失败还是停止，都要删除该文件。
• 如果存在 .claude/state/plan-preapprovals.json，使用 scripts/plan-preapproval.sh validate 验证 v2。v1 作为现有记录的读取兼容格式接受。
• 仅将执行目标 task 中 decision: approved 的事项视为已声明，并传递给 Worker briefing。
• 对于 secret-read，通过 bash "${HARNESS_PLUGIN_ROOT}/scripts/plan-preapproval.sh" apply-secret-allow "$PROJECT_ROOT"，按每次运行将设置应用到 project config .claude-code-harness.config.json 的 runtimefloor.secretAllow，并与 108.2 的 project config floor 衔接。
• R12 的 ask 仅在 phase/task 相同、未过期且未超出使用次数时，才会被同时匹配 external-send 和执行命令的 v2 批准抑制。显式 deny 和 runtime floor 不会被抑制。
• 对已声明事项不中途停止；work 期间由已声明事项引起的 AskUserQuestion 次数应为零。仅在计划获批时确认一次。
• 记录中未包含的未计划 secret-read / 外部发送 / 破坏性操作，仍按原有方式通过 runtime floor / ask 停止。不削弱安全网。

与 harness-work 的区别

特征	harness-work	breezing（此技能）
并行方式	根据需要的数量自动拆分	Lead/Worker/Reviewer 角色分离
Lead 的职责	协调 + 实现	delegate（专注协调）
评审	Lead 自行评审	独立 Reviewer
默认范围	下一个任务	全部

团队组成

角色	Agent 类型	模式	职责
Lead	(self)	-	协调、指挥、任务分配
Worker ×N	claude-code-harness:worker	bypassPermissions（当前） / Auto Mode（后续）*	实现
Advisor	claude-code-harness:advisor	只读	提供方向建议（PLAN / CORRECTION / STOP）
Reviewer	claude-code-harness:reviewer	bypassPermissions（当前） / Auto Mode（后续）*	独立评审

*如果父会话或 frontmatter 使用 bypassPermissions，则优先采用该设置。当前分发模板仍使用 bypassPermissions，因此 Auto Mode 是后续 rollout 的目标，并非默认行为。

模式 1 — Sub-Lead 层级与 review→iterate（可选启用）

在 Go orchestrator 路径（harness work --team）中，除了 Breezing 的 Lead/Worker/Reviewer 三方分离外，还可以选择启用 Producer → Sub-Lead → Composer 模式 1 层级。Lead（Producer 固定为 Claude Code）将 lane 委派给 Sub-Lead；Sub-Lead 使用由 orchestrator 启动的无头 CLI（与 Lead 使用相同的 backend）制定 mini-plan；实现工作则由 Composer 2.5（cursor backend）按 lane 汇总到 companion-result.v1 中。通过 HARNESS_TEAM_HIERARCHY=sublead 启用（默认关闭）。

在质量方面，可通过 HARNESS_REVIEW_ITERATE=on 将 worker 输出纳入 review→iterate 循环。在 fresh-context 并行 advisory + cross-CLI review 之后，先经过 brain-only verdict；如果未达到 DoD，就向同一 worktree 重新提交精细化任务，并反复迭代直至 OK（通过 HARNESS_REVIEW_ITERATE_MAX 设置上限；未能收敛时升级交由人工处理）。有关接线和契约的详细信息，以 harness-work 中的「模式 1 — Producer → Sub-Lead → Composer 层级」「review→iterate 循环」章节为准。

• 如果在同一会话中对同一个符号执行两次 grep，请改用 harness_ast_search。
• 修复 bug 时，如果多个模块中存在同源实现，请在编辑前运行 harness_ast_search 查找所有实现。
• 仅当改动文件包含 .ts 或 .tsx 时，DoD 才要求新增 harness_lsp_diagnostics 错误为零；如果 harness MCP 未连接，或改动文件类型不符合要求，则将 diagnostics 视为未配置且不阻塞流程。

Codex 模式（--codex）

通过官方插件 codex-plugin-cc 将所有实现工作委托给 Codex CLI 的模式：

# タスク委託（書き込み可能）
bash "${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh" task --write "タスク内容"

# stdin 経由（大きなプロンプト向け）
CODEX_PROMPT=$(mktemp /tmp/codex-prompt-XXXXXX.md)
# タスク内容を書き出し
cat "$CODEX_PROMPT" | bash "${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh" task --write
rm -f "$CODEX_PROMPT"

执行后端（持久设置）

backend 判定必须通过 resolver。不得直接读取 HARNESS_IMPL_BACKEND env 来决定 backend。 使用 bash "${HARNESS_PLUGIN_ROOT}/scripts/resolve-impl-backend.sh" 对 env / --cursor 单次运行 flag / 项目 env.local / 用户文件进行 precedence 解析，并将其输出作为 backend （即使 env 未设置，也可以从项目文件或用户文件中读取）。如果要更改持久默认值，请使用 bash "${HARNESS_PLUGIN_ROOT}/scripts/set-impl-backend.sh" <claude|codex|cursor> [--user] 写入项目文件或用户文件， run 开始时由 resolver 解析（当前 operator 默认值为用户作用域的 claude）。review / advisor 角色始终固定为 brain。 有关 backend 选择的权威说明（precedence、role-scope、self_review 跳过、cursor banner），请参阅 harness-work 中的「执行后端选择（Execution Backend Selection）」。

下方的 Cursor Backend Fast Path 是另一条独立路径，通过单次运行 flag（--cursor）作为传给 resolver 的显式 override 启用 lean path；请与本节一并阅读。

Cursor Backend Fast Path（--cursor / lean 模式）

当 bash "${HARNESS_PLUGIN_ROOT}/scripts/resolve-impl-backend.sh" 的输出为 cursor 时启用 （--cursor 作为传给 resolver 的显式 override，优先级最高）。Lead 不经过 Worker 层，直接调用 cursor-companion.sh（Phase 85 SSOT，.claude/rules/cursor-cli-only.md Topology 章节）。

cursor backend 会跳过 Worker agent 启动、self_review 5 项门槛、sprint-contract 3 段链、Phase 0 交互式流程和 effort 评分，将首个任务的委派启动时间从基线 15-35s 缩短至目标 3-7s。完整的节省明细表请参阅 references/lean-path-detail.md。

默认流程（cursor backend）

1. banner + 执行计划（🚀 cursor / <model> / <branch> / <task> + 接下来要执行的 2-4 个步骤，总计不超过 5 行，1 秒内完成）
   • 整个 run 仅执行一次；如果尚未执行，则运行 bin/harness work-mode on（启用跳过 R04/R05 确认，详情见「Work Mode 生命周期」章节）
2. 通过 1 条 bash 命令并行执行 pre-check：git branch --show-current + cat VERSION + Plans.md tail + cursor-agent --version
3. 通过 1 条 bash 命令进行 resolve：bash "${HARNESS_PLUGIN_ROOT}/scripts/resolve-impl-backend.sh" + bash "${HARNESS_PLUGIN_ROOT}/scripts/model-routing.sh" --host cursor --role worker --field model
4. 立即委派：bash "${HARNESS_PLUGIN_ROOT}/scripts/cursor-companion.sh" task --write --workspace <wt> "<task>"
   • 开始委派时，通过 bin/harness session declare --task <task-id> 在共享 presence 中声明任务（其他会话可以按任务编号反向查找）
5. Lead 审查 cursor 输出的 diff → cherry-pick → 更新 Plans.md cc:done [hash]
   • 更新后，通过 bin/harness session declare --clear 清除 presence 中的任务声明
   • 整个 run 结束时（无论成功、失败还是中断），都不要忘记运行 bin/harness work-mode off

仅审查者模式（--cursor --reviewer-only）——读取 = 精简

Worker 实现已完成（已由其他系统 claude / Codex 完成），这是让 Composer 执行 advisory pre-review 的精简路径。由于是只读委派，不需要 worktree、不需要 cherry-pick、不需要审查 Cursor 输出的合并结果（Cursor 不会生成新的 diff）。但不可省略对目标 diff 的 brain 一次审查（primary verdict）：

1. banner + 计划：🚀 cursor / composer-2.5-fast / review +「接下来：委派 Composer 提供 advisory findings → 通过 brain 一次审查确定 verdict」
2. bash "${HARNESS_PLUGIN_ROOT}/scripts/cursor-companion.sh" task "diff レビュー: <base_ref>..HEAD" —— 不要添加 --write 或 --workspace
   • 未指定 --write 时，companion 默认使用 --mode ask（硬性只读限制）（cursor-companion.sh 的 workspace guard 仅在 --write 时触发）
   • Cursor 侧已禁用文件写入和命令执行，无需隔离 worktree
3. Lead 解读 Cursor 输出（相当于 REQUEST_CHANGES / APPROVE），并将其作为 advisory 存入 dual_review.cursor_verdict
4. primary verdict 必须由 brain reviewer 给出。不能仅凭 Cursor 确定 APPROVE（这符合 spec.md Execution Backend Contract 中的 self-review scope 契约，即“生成 diff 的同一上下文不得审查自己的输出”）。此精简路径本身就是 fresh-context advisory pre-review，且委派到的 Cursor session 不与实现 Worker 共享对话状态
5. brain 一次审查：Lead 将 Cursor 的 advisory findings 作为输入，自行检查目标 diff 并给出 verdict（APPROVE | REQUEST_CHANGES）。若 brain reviewer 不可用（例如 rate limit），则暂不确定 verdict，并将任务保持为 cc:wip 交由用户判断（不能仅凭 Cursor advisory 将任务标记为 cc:done）
6. brain 给出 APPROVE 后，由 Lead 更新 Plans.md cc:done [hash]

read mode 下可省略的内容：专用 .git worktree / 审查 Cursor 输出的合并结果 / cherry-pick / worker-report.v1 / 5 项 self_review。不可省略：对目标 diff 的 brain 一次审查（确定 verdict）。 read mode 下仍须保留：.cursorignore / egress allowlist（*.cursor.sh）/ permissions.json（尽力而为）。详情请参阅 .claude/rules/cursor-cli-only.md 中的“Read mode delegation (lean path)”一节。

用途（rate limit 时提前汇总 / 将 Reviewer 分散到其他系统 / Codex review auth 失败时的 fallback，详情见 references/lean-path-detail.md）。

Cursor adapter 支持声明

Cursor 属于 supported tier（H8 pin：live H4 2026-07-17 + H7 release-preflight fail-closed）。没有 FS jail——隔离由 harness 侧负责（docs/CURSOR_INTEGRATION.md）。--cursor 精简路径本身不会提升 tier。

Bootstrap 路径：.cursor/AGENTS.md + .cursor-plugin/plugin.json。

验证：

bash tests/test-cursor-adapter-candidate.sh
bash tests/test-support-claim-wording.sh

流程概要

breezing [scope] [--codex] [--parallel N] [--no-discuss] [--auto-mode]
    │
    ↓ Load harness-work with team mode
    │
Phase 0: Planning Discussion (--no-discuss でスキップ)
Phase A: Pre-delegate（チーム初期化）
Phase B: Delegate（Worker 実装 + 必要時 Advisor + Reviewer レビュー）
Phase C: Post-delegate（統合検証 + Plans.md 更新 + commit）

Advisor 协议

Worker 不会增加通用 subagent。 遇到疑问时，只返回结构化 JSON 格式的咨询请求，由 Lead 调用 advisor。

1. Worker → advisor-request.v1
2. Lead → Advisor
3. Advisor → advisor-response.v1
4. Lead → 将 advice 返回给同一个 Worker 并继续
5. Reviewer 只查看最终成果物

咨询条件与 loop / solo 保持一致。

• 高风险 task（needs-spike / security-sensitive / state-migration）首次执行前
• 同一原因的失败连续发生 2 次后
• 因 plateau 即将返回 PIVOT_REQUIRED 前
• 同一 trigger_hash 仅咨询 1 次。每个 task 最多咨询 3 次

进度 Feed（Phase B 期间的进度通知）

Lead 在 Worker 每次完成任务时，按以下格式输出进度：

📊 Progress: Task {completed}/{total} 完了 — "{task_subject}"

输出示例：

📊 Progress: Task 1/5 完了 — "harness-work に失敗再チケット化を追加"
📊 Progress: Task 2/5 完了 — "harness-sync に --snapshot を追加"
📊 Progress: Task 3/5 完了 — "breezing にプログレスフィードを追加"

设计意图：breezing 通常会长时间运行。 用户快速查看终端时，可以一眼看出“目前进展到哪里了”。 task-completed.sh 钩子会通过 systemMessage 输出同等信息，因此能与 Lead 的输出互为补充。

静默策略（整理长时间运行时的通知）

在 Codex 0.123.0 的 realtime handoff 中，background agent 会接收 transcript delta，并可在不需要时明确保持静默。 Breezing 的 progress feed 会遵循这一前提，将通知限定在“工作节点”。

需要报告的内容：

• task 完成、blocked、validation failure、review REQUEST_CHANGES
• Advisor 的 PLAN / CORRECTION / STOP
• Reviewer 的 APPROVE / REQUEST_CHANGES
• advisor / reviewer drift、plateau、contract readiness failure
• 用户明确请求 status 时提供的摘要

可以保持静默的内容：

• 仅接收到 transcript delta，判定或 status 未发生变化时
• tool stdout 的细微增量，记录到 log 中即可时
• 并行 Worker 等待期间的 heartbeat

原则上“每个 task 完成时通知 1 次”。 不要通过增加 heartbeat 来营造安心感，而应将职责分别交给 status / log / drift 检测。 但 Advisor request 未响应、Reviewer result 未到达、plateau 前的警告不属于静默范围。

Monitor 工具使用指南 (CC 2.1.98+)

对于通过 run_in_background: true 启动的长时间运行 shell 进程（gh run watch、build --watch 等），应使用 Monitor 工具逐步接收 stdout 通知，而非轮询。监控 Agent（Worker/Reviewer）是否完成或运行短时单次命令时，无需使用它。 工具选择表和典型模式请参阅 references/monitor-and-learning.md。

Review Policy（所有模式统一）

即使在 Breezing 模式下，Review 也遵循统一政策：优先使用 Codex exec → 回退到内部 Reviewer。 详情请参阅 harness-work 的“Review 循环”部分。

• Worker 在 worktree 内实现并 commit → 将 worker-report.v1（含 5 项 self_review）返回给 Lead
• self_review 门禁（spawn Reviewer 前）：Lead 以机器方式验证 self_review[].verified 和 evidence。只要有 1 项 verified:false 或 evidence:""，就不 spawn Reviewer，而是自动退回给 Worker（同一会话内最多 2 次，第 3 次时升级处理）
• Lead 使用 Codex exec 进行 Review（超时 120s，回退方案：Reviewer agent）
• REQUEST_CHANGES → Lead 通过 SendMessage 向 Worker 下达修改指示，Worker 执行 amend（最多 MAX_REVIEWS 次。MAX_REVIEWS = read_contract(contract_path, ".review.max_iterations") or 3）
• APPROVE → Lead cherry-pick 到 main → 将 Plans.md 更新为 cc:完了 [{hash}]

完成报告（Phase C — 由 Lead 生成）

所有任务完成后，Lead 按以下步骤生成详细完成报告：

1. 使用 git log --oneline {base_ref}..HEAD 收集所有 cherry-pick 提交
2. 使用 git diff --stat {base_ref}..HEAD 获取整体变更规模
3. 提取 Plans.md 中剩余的 cc:TODO / cc:WIP 任务
4. 按照 harness-work 的 Completion Report Output Contract 和 references/completion-report.md 中的 Breezing 模板输出

生成者是 Lead，不是 Worker 或 hook。Lead 在 Phase C 读取 git 和 Plans.md 后生成报告。

Phase 0：Planning Discussion（结构化 3 问检查）

执行所有任务前，通过 3 个问题检查计划是否合理：范围（Q1）、依赖关系（Q2，仅当存在 Depends 列时）和风险标记（Q3，仅当存在 [needs-spike] 时）（总计 30 秒设计）。 指定 --no-discuss 时全部跳过。3 个问题的具体表述和判断逻辑请参阅 references/lean-path-detail.md。

Universal Violations Injection（会话内 Worker 间的经验传播）

同一 /breezing 启动期间积累的 Reviewer 通用注意事项会自动注入下一位 Worker briefing 的开头。仅在同一会话内有效（会话结束后丢弃，不写入 session-memory）。实现方式（in-memory 数组 + briefing 注入代码）请参阅 references/monitor-and-learning.md。

基于依赖图分配任务

如果 Plans.md 中有 Depends 列（v2 格式），则先并行 spawn Depends 为 - 的独立任务；每个 Worker 完成后，由 Lead 进行 Review 并 cherry-pick（参见 harness-work Phase B）。依赖项进入 main 后，再执行依赖于它的任务，重复此过程，直到所有任务完成。只有“Worker 完成→Review→cherry-pick”按顺序处理；可以并行化的只有独立任务的 Worker spawn 部分。详情请参阅 references/lean-path-detail.md。

Codex Native Orchestration

Codex 使用原生 subagent。 主要控制接口包括 spawn_agent、wait、send_input、resume_agent、close_agent。

Claude Code 与 Codex 的通信 API（SSOT：team-composition.md 的 API 映射表）：

• Claude Code：使用 SendMessage(to: agentId, message: "...") 向 Worker 下达修改指示
• Codex：使用 resume_agent(agent_id) 恢复 Worker → 使用 send_input(agent_id, "...") 发送指示

harness-work 的伪代码使用 Claude Code 语法编写。在 Codex 环境中，请按上述方式转换。

相关 Skills

• harness-work — 从单项任务到团队执行（主体）
• harness-sync — 进度同步
• harness-review — 代码 Review（在 breezing 中自动启动）