harness-work

# Harness Work

Harness の統合実行スキル。
以下の旧スキルを統合:

- `work` — Plans.md タスクの実装（スコープ自動判断）
- `impl` — 機能実装（タスクベース）
- `breezing` — チームフル自動実行
- `parallel-workflows` — 並列ワークフロー最適化
- `ci` — CI 失敗時の復旧

## Quick Reference

| ユーザー入力 | モード | 動作 |
|------------|--------|------|
| `/harness-work` | **auto** | タスク数で自動判定（下記参照） |
| `/harness-work all` | **auto** | 全未完了タスクを自動モードで実行 |
| `/harness-work 3` | solo | タスク3だけ即実行 |
| `/harness-work --parallel 5` | parallel | 5ワーカーで並列実行（強制） |
| `/harness-work --codex` | codex | Codex CLI に委託（明示時のみ） |
| Cursor host (adapter candidate) | cursor | Task/subagent routing via `.cursor/AGENTS.md`; not auto-selected |
| `/harness-work --breezing` | breezing | チーム実行を強制 |
| `/harness-work 3 --plan roadmap` | solo | named Plans の `roadmap` からタスク3を実行 |

## Execution Mode Auto Selection（フラグなし時の自動判定）

明示的なモードフラグ（`--parallel`, `--breezing`, `--codex`）がない場合、
対象タスク数に応じて最適なモードを自動選択する:

| 対象タスク数 | 自動選択モード | 理由 |
|-------------|---------------|------|
| **1 件** | Solo | オーバーヘッド最小。直接実装が最速 |
| **2〜3 件** | Parallel（Task tool） | Worker 分離のメリットが出始める閾値 |
| **4 件以上** | Breezing | Lead 調整 + Worker 並列 + Reviewer 独立の三者分離が効果的 |

### ルール

1. **明示フラグは常にオートモードを上書き**する
   - `--parallel N` → Parallel モード（タスク数に関係なく）
   - `--breezing` → Breezing モード（タスク数に関係なく）
   - `--codex` → Codex モード（タスク数に関係なく）
2. **`--codex` は明示時のみ発動**。Codex CLI が未インストールの環境があるため、自動選択しない
3. `--codex` は他モードと組み合わせ可能: `--codex --breezing` → Codex + Breezing

## Execution Backend Selection（実装バックエンド選択）

バックエンド（どのランタイムが**実装するか**）は、実行モード（トポロジー: solo / parallel / breezing）と直交する。
実行モードが「何ワーカーで・どう分割して回すか」を決めるのに対し、バックエンドは「実装の手を誰が動かすか」を決める。

| backend | 実装の担い手 | 委託コマンド |
|---------|------------|------------|
| `claude`（既定） | Task subagent（`agents/worker.md`） | Agent tool で worker を spawn |
| `codex` | Codex CLI | `bash "${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh" task --write "<prompt>"` |
| `cursor` | cursor-agent（model `composer-2.5-fast`） | `bash "${HARNESS_PLUGIN_ROOT}/scripts/cursor-companion.sh" task --write --workspace <worktree> "<prompt>"` |

### 解決手順

run 開始時に 1 回だけ解決する。backend 判定は **必ず resolver 経由**にし、`HARNESS_IMPL_BACKEND` env だけを直読みして判定しない:

```bash
bash "${HARNESS_PLUGIN_ROOT}/scripts/resolve-impl-backend.sh"
```

precedence（高い順）: `--backend <v>` / `--cursor` / `--codex` フラグ > `HARNESS_IMPL_BACKEND` 環境変数 > プロジェクト `env.local` の同名行 > ユーザー `~/.config/claude-harness/impl-backend.env` の同名行 > 既定値 `claude`。プロジェクト設定はユーザースコープを上書きする。
明示フラグ（`--backend` / `--cursor` / `--codex`）は env / file / default を常に上書きする。

### 自然言語 backend trigger

ユーザーが `composer` / `コンポーザー` / `Composer で` / `composer 2.5` / `composer モード` と言った場合は、`cursor backend` 指定として扱う。
これは `--cursor` と同じ intent だが、backend の確定値は必ず `resolve-impl-backend.sh` で解決する。
解決時は明示 override として `--backend cursor` を渡し、env / project / user file / default より優先させる。
Lead は `composer` を Claude Worker 内の追加 agent と解釈せず、非 `claude` backend の規約どおり Worker agent を挟まずに `cursor-companion.sh` を直接呼ぶ。

### role-scoped 制約

バックエンドは **role-scoped**。解決済みバックエンドを使うのは実装（worker）ロールだけ。
Reviewer と Advisor の両ロールは常に brain（`--host claude`、Opus）に固定する。
Reviewer を cursor / codex バックエンドに routing しない（実装したバックエンドが自分の出力をレビューしてはならない）。

```bash
# 実装ロールだけ解決済み backend に従う（例: backend=cursor なら composer-2.5-fast を解決）
bash "${HARNESS_PLUGIN_ROOT}/scripts/model-routing.sh" --host cursor --role worker --field model
# review / advisor は常に claude（Opus）固定
bash "${HARNESS_PLUGIN_ROOT}/scripts/model-routing.sh" --host claude --role reviewer --field model
bash "${HARNESS_PLUGIN_ROOT}/scripts/model-routing.sh" --host claude --role advisor --field model
```

> モデル名の正本は `model-routing.sh` 側。本ドキュメント中の `composer-2.5-fast` は参照値であり、実際の解決は上記コマンドに従う（drift 防止）。

### 非 `claude` バックエンドのトポロジー（Worker 介在なし）

backend が `codex` または `cursor` の場合、**Lead は Worker agent (`claude-code-harness:worker`) を spawn しない**。
代わりに Lead 自身が `cursor-companion.sh` / `codex-companion.sh` を直接呼ぶ。
Worker 層の介在は backend=`claude` のときだけ。

配線:

| backend | 経路 |
|---------|------|
| `claude`（既定） | Lead → Worker (`claude-code-harness:worker` agent) → … → Lead review → cherry-pick |
| `codex` | Lead → `codex-companion.sh task --write` → Lead review → cherry-pick |
| `cursor` | Lead → `cursor-companion.sh task --write --workspace <isolated-wt>` → Lead review → cherry-pick |

非 claude backend で Worker を間に挟むと、Lead → Worker → companion → composer/codex と二段委譲になり、Worker の存在意義（agent 契約による self_review 5 件のゲート）が空回りする（非 claude では `worker-report.v1` も `self_review` も生成されないため）。Lead は Worker をスキップして companion を直接呼ぶ。

非 claude backend の companion 呼び出しでも、Lead は先に専用 worktree を作り、companion stdout を `companion-result.v1` 相当の `{baseCommit, commit, worktreePath, branch, files_changed, summary}` に正規化してから既存の Lead review / cherry-pick 経路へ渡す。`REQUEST_CHANGES` 時は `SendMessage` を使わず、同じ worktree で `cursor-companion.sh` / `codex-companion.sh` を再実行し、`baseCommit..HEAD` を再レビューして range cherry-pick する。

### 非 `claude` バックエンドの self_review ゲート

backend が `codex` または `cursor` の場合、`worker-report.v1` も `self_review` 配列も生成されない。
そのため Lead は self_review ゲートを**スキップ**し、Lead の diff レビューを唯一の品質ゲートとする（既存の codex path と同じ扱い）。

### cursor バックエンドの banner（委託前に必須）

backend が `cursor` のとき、Lead は委託前に次の 1 行 banner を必ず出力する:

```
⚠️ cursor backend: model=composer-2.5-fast / R01-R13 ガードレールは cursor-agent 内部に適用されない / 出力は Lead レビューまで untrusted
```

cursor の write 委託は専用 `.git` を持つ worktree 内で実行し、Lead が main へ cherry-pick する（cherry-pick 経路で R01-R13 が適用される）。
ガバナンス詳細は `.claude/rules/cursor-cli-only.md` を参照。

### Lead の cherry-pick 前ゲート（contract grep を必須）

非 claude backend (cursor / codex) の出力を main にとり込む前に、Lead は **目視 diff + contract grep の二段ゲート**を必ず通す。目視 diff だけで APPROVE しない。

| ゲート | コマンド | 検知できるもの |
|--------|----------|----------------|
| diff 目視 | `git show <sha>` | 変更が意図どおりか・他ファイル touch なしか・support tier 表記不変か |
| contract grep | `bash tests/test-support-claim-wording.sh` | 公開 support 表記の破壊 |
| contract grep | `bash scripts/ci/check-consistency.sh` | i18n / locale / mirror / capability matrix の固定文字列契約破壊 |
| contract grep | `bash tests/validate-plug