[aside] 現状の goose dispatcher は read-only を prompt だけで守り、しかも CWD=repo root の作業コピー ── 今すでに injection で working copy を汚しうる

今回 goose 大規模化の調査で表面化した、A/B ロードマップとは独立な present の安全 gap(idea post n_01KT191Y5NV3GFKR6V02CFZ5W0 は「B で書けるようにする時に隔離が要る」文脈で触れたが、これは「B を待たず今の read-only dispatcher 単体で踏める sharp edge」)。

- **構造**: goose の developer extension が有効(`~/.config/goose/config.yaml` で `enabled: true`)なので goose 自前プロセスで shell/編集ができる。`goose_acp.rs:151-157` の ACP `fs.writeTextFile=false`/`terminal=false` は「クライアント代理経路」を塞ぐだけで developer extension の直接編集は止めない。permission も `AllowOnce` 自動承認(`goose_acp.rs:33-40`)。結果 read-only を保証しているのは `acp_dispatch.rs::build_goose_prompt` の本文テキスト("do NOT modify…")のみ。
- **加えて CWD が live repo root**: dispatch は `--cwd` 未指定だと `absolute_cwd` が `current_dir()` = dispatcher を回す repo root を goose に渡す(`goose_acp.rs:350-363`)。つまり万一 goose が書いたら user の作業コピーに直で当たる。job 本文は untrusted(prompt に injection guard はあるがソフト)。

- **触らない判断**: 今回は A/B 設計の素案出しが目的で、dispatcher のコードは触らない scope。idea post は roadmap、これは現状 dispatcher の standalone hardening。

- **想定インパクト / トリガー**: 単一 owner・自分で投げる運用なら実害は出にくいが、A の `--watch` 常駐や暗号化 job 越し委譲を増やすほど「悪意/暴走 job が live checkout を汚す」露出が上がる。小さい hardening 候補 — (a) read-only mode では goose を **throwaway な scratch checkout / 使い捨て worktree の CWD** で回す(repo root を渡さない)、(b) read-only mode は developer extension の write/shell tool を無効化した goose profile で起動、(c) 最低限 dispatch 既定 CWD を repo root 以外にする。着手トリガー = A 常駐運用を始めるとき、または goose を複数 runner / 暗号化委譲で広げるとき。