goose ACP を「大規模・高速開発」に使う設計判断(2026-06-01 合意、段階推奨で進行)

## 出発点(調査で確定した事実)

- goose のモデルは `kimi-for-coding`(Kimi のコード用)。コード編集を任せられる水準。
- developer extension が有効なので goose は本来 shell 実行・ファイル編集ができる。ACP の `writeTextFile=false`/`terminal=false` は「クライアント代理経路」を塞ぐだけで goose 自前プロセスの編集は止めない。permission も `AllowOnce` 自動承認。
- **今 goose を read-only に保っているのは prompt テキストだけ**(`acp_dispatch.rs` の `build_goose_prompt`)。安全含意: untrusted な job 本文に injection が入ると CWD(= repo root の作業コピー)に書かれうる。開発含意: 「書ける goose」化は配管的に近い。
- dispatch は単発 prompt = 単一ターン、timeout 既定 120 秒、CWD はバッチ全体で 1 つ共有(`acp_dispatch.rs:271/320/362`)、並列上限 8(`--watch` 既定 2)。

## A と B は別のボトルネックを解く別物

- **A(read-only 大量並列)** = 「Claude が自分で調べ物する」を置換 → Claude の context 消費を減らす。
- **B(書ける goose)** = 「bg Claude 子が実装する」を置換 → 機械的タスクを goose に流して、より安く・広く並列に実装する。

## 決定: 排他ではなく段階で進める

1. **まず A を `--watch` 常駐運用して kimi の信頼性と実用度を実測**(ほぼ無料・リスクなし)。これで B 最大の不確実性(kimi が自律多段でどれだけ正しく動くか)を安く先に観測する。配管はほぼ揃っており、実需は常駐運用 + Claude 側が enqueue する習慣 + 取り込み導線。
2. **並行して B は `B-edit`(編集+commit、worktree 隔離、機械的タスク限定)を第一歩として設計**。
3. **B-PR(commit→rebase→push→PR 自走)と CLAUDE.md ポリシー全面転換(「code edit/PR 委譲しない」改訂)は、A / B-edit で kimi の信頼性が確認できてから**(seam を残す段階構成)。

## B-edit に要る変更(設計対象)

1. 書き込みモードの prompt 変種(read-only 縛りを外し編集/commit を許可。`--mode write` 的フラグで選択)。prompt が唯一のゲートなのでここが本丸。
2. **job ごとの worktree 隔離(必須)**: dispatcher が job ごとに worktree を切り、各 job の CWD をその worktree に設定(今は CWD バッチ共有 = 並列で書くと互いに踏む)。
3. handoff は B-edit = 編集+commit まで、branch を残し取り込む側が review+統合。push/PR 自走は B-PR で後回し。
4. ターン/時間モデル: 120 秒単一ターンでは feature 実装は無理。timeout 600 秒+ に上げ goose 内部ループにテスト実行まで回させる。
5. 安全: worktree 隔離でファイル破壊は封じ込むが、push/破壊的 git/network は残る。force-push 禁止・gh token スコープ制限・goose PR に追加 review フラグ。

## 主要リスク

- B 最大の不確実性は配管でなく **kimi の自律多段の信頼性**(→ だから A を先に回して観測)。
- worktree ごとに cargo+DuckDB ビルド(sccache+mold で緩和済だが N 並列なら N ビルド)。
- goose PR 増 → CI 実行増(現状コストの支配項は CI)。

次アクション: A の常駐運用立ち上げ + B-edit の具体設計。

replies