perf(pre-push-review): loop_monitor judge を haiku 化 (push パイプライン改善 R2)

.takt/workflows/pre-push-review-refute.yaml

@@ -32,7 +32,11 @@ loop_monitors:
     threshold: 2
     judge:
       persona: supervisor
-      model: sonnet
+      # haiku: judge は Healthy/Unproductive の 2 択 routing のみ (R2 / T13 項目 3)。
+      # post-pr-review.yaml の analyze (haiku で approved/needs_fix/user_decision を分類) に前例。
+      # ⚠ 変更時は 非 refute 側 (pre-push-review.yaml) と必ず揃えること (原則 6 / T10 の罠)。
+      # refute_enabled = true のため実走はこちら (push-runner-config.toml)。
+      model: haiku
       instruction: loop-monitor-reviewers-fix
       rules:
         - condition: Healthy (progress being made)

.takt/workflows/pre-push-review.yaml

@@ -24,7 +24,10 @@ loop_monitors:
     threshold: 2
     judge:
       persona: supervisor
-      model: sonnet
+      # haiku: judge は Healthy/Unproductive の 2 択 routing のみ (R2 / T13 項目 3)。
+      # post-pr-review.yaml の analyze (haiku で approved/needs_fix/user_decision を分類) に前例。
+      # ⚠ 変更時は refute 側 (pre-push-review-refute.yaml) と必ず揃えること (原則 6 / T10 の罠)。
+      model: haiku
       instruction: loop-monitor-reviewers-fix
       rules:
         - condition: Healthy (progress being made)

docs/push-pipeline-fix-plan2.md

@@ -32,6 +32,7 @@ cli-pr-monitor) の遅延 (コード変更 push 最大 14.6 分) と不具合の
 | T11 | #288 | docs-only PR (ADR-035 path 基準) の rust gate 決定論 skip。`lib-docs-policy` 新設 (ADR-057、判定期限 8/15) |
 | T12 | #289 | fix 後の決定論再ゲート `post_takt_regate` + fix.md 自己検証義務の縮小 (ADR-058、判定期限 8/15) |
 | T13 | #290 + 判定 | backlog 13 項目の処置確定: **採用 2 (→ R1/R2)**、todo 移管 3 (項目 9→順位 324 / 項目 10→順位 323 / 項目 12→既存順位 16)、却下 6 (項目 2/4/5/6/8/11)、条件付き却下 2 (項目 7/13、再評価トリガー付き)。判断根拠は旧計画 §6/§8 |
+| R1 | #292 | quality_gate 失敗 step の出力を全量表示 (40 行 truncate 除去。成功経路は cap 維持 = T5「失敗経路は診断を落とさない」の残り半分。ADR-049 流の回帰テスト 2 本追加) |
 
 ### 実測の現在地 (2026-07-18 時点)
 
@@ -65,15 +66,15 @@ cli-pr-monitor) の遅延 (コード変更 push 最大 14.6 分) と不具合の
 
 ## 3. 残タスク (1 PR 1 タスク、推奨順)
 
-### R1: gate 失敗時出力の truncate 改善 (T13 項目 1 採用分) — XS **【実装済み・未 push, 2026-07-18】**
+### R1: gate 失敗時出力の truncate 改善 (T13 項目 1 採用分) — XS **【マージ済み #292, 2026-07-18】**
 
 - **内容**: quality_gate の step 失敗時、cargo test の失敗一覧が 40 行 truncate で消え
   診断できない問題の解消。`run_cmd_shell_capped_reporting` (truncate 明示 variant) + cap
   引き上げ、または失敗経路のみ全量表示 (T5 の「失敗経路は診断を落とさない」原則の残り半分)。
 - **対象**: `src/cli-push-runner/src/stages/quality_gate.rs` + `lib-subprocess` の必要 variant
 - **受け入れ基準**: 失敗 step の出力が truncate されず表示されることの回帰テスト。
   成功経路の表示は現状維持 (cap あり) で退行なし。
-- **実施結果 (2026-07-18, 実装済み / 未 push)**:
+- **実施結果 (2026-07-18, マージ済み / PR #292)**:
   - **方針**: 受け入れ基準「truncate されず表示」に従い**失敗経路の全量表示**を採用
     (`capped_reporting` + cap 引き上げ案は truncate を明示するだけで基準を満たさないため
     不採用)。T5 (§4/PR #282) が push stage で確立した「判定は exit status ベース・失敗経路は
@@ -99,16 +100,45 @@ cli-pr-monitor) の遅延 (コード変更 push 最大 14.6 分) と不具合の
     実証済みのため、XS 相応の検証に留める。
   - **exe 再ビルド済み** (`pnpm build:cli-push-runner`)。`cargo clippy -p cli-push-runner
     --all-targets` warning 0 / `cargo test -p cli-push-runner` 252 passed。
-  - **§1 表への行追加と PR 番号 backfill は push/マージ時に実施** (§1 は「全 PR マージ済み」
-    のスナップショットのため、未 push の本タスクは §3 の本欄で完了記録とする)。
+  - **§1 表に R1 行 (#292) を追加済み** (2026-07-18 マージ完了に伴い backfill)。未 push
+    だった間は §1 (「全 PR マージ済み」スナップショット) に載せず §3 本欄を完了記録としていた。
 
-### R2: loop_monitor judge の haiku 化 (T13 項目 3 採用分) — XS
+### R2: loop_monitor judge の haiku 化 (T13 項目 3 採用分) — XS **【実装済み・未 push, 2026-07-18】**
 
 - **内容**: loop_monitor の `judge.model: sonnet` → `haiku` (2 択判定のみ。post-pr-review.yaml に前例)。
 - **対象**: `pre-push-review.yaml` と `pre-push-review-refute.yaml` の**両方** (原則 6 参照。
   片方だけ変えると効果ゼロで気付けない = T10 で実際に起きた罠)。
 - **受け入れ基準**: 実 push で judge が haiku で完走。fix iteration 発生 run での遷移時間を
   記録できれば尚可 (R3 未実装の間は push ログの手動保存)。
+- **実施結果 (2026-07-18, 実装済み / 未 push)**:
+  - **方針**: loop_monitor の stall-detection judge を `sonnet` → `haiku`。judge は cycle が
+    threshold (2) 回反復した時に `Healthy → reviewers(refute 側も同じ) / Unproductive → supervise`
+    の **2 択 routing** を返すだけで、コード読解や修正判断を伴わない。haiku で十分という前例は
+    post-pr-review.yaml の analyze step (haiku で approved/needs_fix/user_decision の **3 分類**を
+    担当) = より複雑な分類を既に haiku が捌いている実績。
+  - **対象 (両方変更した)**: `pre-push-review.yaml` (judge L30) と `pre-push-review-refute.yaml`
+    (judge L39) の 2 ファイル。`refute_enabled = true` / `refute_workflow = "pre-push-review-refute"`
+    (`push-runner-config.toml` L213-214) のため**実走は refute 側**だが、kill-switch
+    (`refute_enabled = false`) で非 refute 側へ即戻せる設計 (ADR-047) のため、片方だけ変えると
+    戻した瞬間に効果が消え気付けない (原則 6 / T10 で実際に起きた罠)。両 yaml の judge に
+    「もう片方と揃えよ」inline コメント (原則 6 / T10 参照付き) を追加し、同期義務を人可読に明記した。
+  - **ADR-039 の観点**: これは experimental feature の**新設ではなく既存 judge の model 変更のみ**。
+    opt-in / kill-switch / bounded-lifetime は refute facet 自体 (ADR-047、判定期限 7/31) が
+    既に保持しており、haiku judge はその配下に入る。非 refute 側の judge も同値 (haiku) に
+    揃えたのは、refute 廃止 (kill-switch or ADR-047 却下) 時の着地先として効果を維持するため。
+  - **exe 再ビルド不要**: yaml 設定変更のみで Rust 変更なし (原則 4 は非該当)。takt (0.35.3、
+    ADR-017 で固定) が実行時に yaml を読む配布物であり、`.claude/*.exe` は無関係。
+  - **検証**: `takt prompt pre-push-review` / `takt prompt pre-push-review-refute` で両 workflow が
+    step 4 まで正常にパース・レンダリングされることを確認 (judge step preview の
+    `reportContent is required` は実 report 本文を要さない dry preview 固有の制約で、yaml 不正
+    ではない)。両ファイルの `loop_monitors[0].judge.model` が `haiku` であることも確認済み。
+  - **受け入れ基準の充足度 (未検証事項として記録)**: 基準「実 push で judge が haiku で完走」は
+    本 work unit のスコープ (commit まで) 外。judge は **loop_monitor が cycle 停滞を検出した
+    時のみ fire** する = fix iteration が 1 回以上発生する run でしか起動しないため、fix なし run
+    (§1 実測では T10 後 0/4 が fix なし) では judge 自体が呼ばれない。よって「haiku 完走」の
+    実証は fix 発生 run が出た時の push ログ手動保存 (R3 未実装のため) に持ち越す。
+  - **§1 表への行追加と PR 番号 backfill は push/マージ時に実施** (R1 と同じ扱い。§1 は
+    「全 PR マージ済み」のスナップショットのため、未 push の本タスクは §3 本欄で完了記録とする)。
 
 ### R3: push per-run メトリクスの JSONL 永続化 (todo 順位 325) — S