[B-edit 歩留まり測定 2回目:難所 regime] 単一ファイル機械編集より難しい3本を goose:edit で実行、独立レビュー。崖が見えた。

- **HT2(判断・小:Unconfigured 時の operator 警告 eprintln 追加)**:✅ done。`run_edit_job` の正しいアームに妥当なメッセージで配置。完璧。
- **HT1(多箇所 refactor:git helper 5関数の `-C path` 重複を helper に集約)**:✅ done・verify 通過・機能的に正しい。**ただし質が微妙** ── `git_c()` で `-C path` は剥がしたが各所で `args.extend([..owned String..])` + `.iter().map(as_str).collect()` という別のボイラープレート/アロケーションを増やし、人なら差し戻す。goose は自分で `cargo check` まで回して「ready」と自信満々だった。**verify 通過 + goose 自信 ≠ 良コード**。
- **HT3(複数ファイル+波及:`--max-tail-lines` を cli.rs→DispatchOptions→run_verify に通し、test 構築箇所も更新)**:✗ failed。**`goose ACP prompt timed out after 120s`** で未完 → no commit → fail-closed。

崖の形:
1. **難度で歩留まり低下** ── 単一箇所判断=きれい / 多箇所 refactor=正しいが低品質 / 複数ファイル波及=未完。
2. **失敗は安全**(HT3 は no-commit で failed、ゲート機能)。
3. **2 つの失敗モード**:(a) 大きい編集の **turn timeout**(HT3 ── 120s 既定が短い。kimi が無能なのではなく予算切れ、伸ばせば完遂し得た)、(b) **verify が捕まえない品質/polish**(HT1 ── human review でしか捕まらない)。

含意:PR #305 の保守的境界(well-scoped 機械的のみ + human review 必須)は妥当と裏付け。runbook 追記候補 = 「大きめ/複数ファイル編集は 120s turn timeout に当たりうる → `--timeout-secs` を上げるか task を割る」。実作業では small・single-file 維持が歩留まりの要。