[B-edit 設計確定] goose に編集+commit を任せる実装ブループリント(2026-06-01、A 第1回検証の知見を反映)

## 確定した2分岐
- **mode 区別 = job tag `goose:edit`(per-job)**: 1 つの `--watch` daemon が read/edit 混在 backlog をそのまま捌く。`enqueue-goose --mode edit` でタグ付与。tag 不在=Read=現行挙動(後方互換)。
- **verify コマンド = repo 既定 + per-job 上書き**: dispatcher に既定の速い check を持たせ、特殊な job だけ上書き。

## 中核機構(A 検証の知見)
kimi は構造的詳細を自信ありげに捏造する(検証 1回目で存在しない関数名 `run_goose_batch` を生成)。よって **成功判定に goose の自己申告を使わず、dispatcher が worktree で verify を独立実行した exit code に置く**。これが B-edit と「goose を信じる」を分ける機構。

## パイプライン差分(`acp_dispatch.rs`)
claim 後、job ごとに mode 判定 → Edit なら ① 使い捨て worktree 作成(cwd=隔離)→ ② `build_goose_edit_prompt` → ③ goose ターン(cwd=worktree)→ ④ dispatcher が verify 実行 → ⑤ commit有無 × verify結果で done/failed → ⑥ reply に branch名+diff stat+verify出力、worktree は成功keep/失敗remove。Read job は無改変で同居。

## 作るもの
- `acp_dispatch.rs`: `JobMode{Read,Edit}`(tags から純関数判定)/ `build_goose_edit_prompt`(隔離 worktree で編集可・push/gh/破壊的git/network 禁止・テスト未確認で成功と言うな)/ worktree create-remove helper / **3 経路(`run_goose_jobs`/`run_goose_once`/watch の `run_turn`)を `run_one_job` に抽出して per-job cwd 化**(今は cwd バッチ共有)/ verify gate `decide_edit_outcome(commit, verify)→Done|Failed|NeedsReview`(純関数 unit test)/ `DispatchOptions.verify_cmd` / Edit finalize(`done`+`goose-edit` タグ、human review フラグ)。
- `goose_acp.rs`: Edit spawn 時に `GH_TOKEN` 等を子 env から scrub(worktree で FS 隔離 + push/network は env+prompt で塞ぐ、aside n_01KT195Q… と同根)。
- `cli.rs`: `enqueue-goose --mode edit` / `dispatch goose --verify-cmd`。
- server `claim_goose_jobs`: 変更不要。

## build 順
1. 3 経路を `run_one_job` 抽出(純 refactor、挙動不変)→ 2. worktree helper + per-job cwd 配線 → 3. `JobMode` + edit prompt → 4. verify gate + `decide_edit_outcome` + Edit finalize → 5. CLI flag + env scrub → 6. テスト(mode判定/prompt/真理値表/worktree lifecycle)。

## リスク
worktree ごと build コスト → `CARGO_TARGET_DIR` 共有 + Edit 並列上限低め(既定2)。verify 粒度は repo 既定の速い check から。`goose-edit` 成果は B-edit では常に human review(auto-merge しない、push/PR 自走は次段 B-PR)。