aloekun · aloekun · Aug 18, 2026 · Aug 18, 2026 · coderabbitai · Aug 18, 2026
diff --git a/docs/bugfix-batch-plan.md b/docs/bugfix-batch-plan.md
@@ -12,7 +12,7 @@
 
 | # | PR | 対象順位 | 状態 |
 |---|---|---|---|
-| A | fix(merge-pipeline): feedback ループの誤 bail・誤ブロック解消 | ~~444~~ + 328 + 347 | **順位 444 は [PR #417](https://github.com/aloekun/claude-code-hook-test/pull/417) で実装完了・マージ待ち** (本計画とは独立に起票済みだった)。**残りは 328 + 347** |
+| A | fix(merge-pipeline): feedback ループの誤 bail・誤ブロック解消 | 444 + 328 + 347 | **完了。** 444 は [PR #417](https://github.com/aloekun/claude-code-hook-test/pull/417) でマージ済み。328 は順位 398 の guard 変更で既に解消済みと判明し、再発防止テストのみ追加。347 は実装済み |
 | B | fix(merge-pipeline): 分析ソース選定を陽性照合ベースに統一 | 336 + 288(a) + 446 | 未着手 |
 | C | fix(hooks): smoke suite の ETXTBSY 解消 | 396 | 未着手 |
 | D | fix(check-ci-coderabbit): rate-limit 第 3 format + 実レビュー有無分離 | 318 + 320 | 未着手 |
@@ -41,9 +41,9 @@
 
 ## PR A: fix(merge-pipeline): feedback ループの誤 bail・誤ブロック解消 (順位 444 + 328 + 347)
 
-**束ねる理由**: 3 件とも `cli-merge-pipeline` の post-merge-feedback 経路の欠陥。444 (stale meta による恒久ブロック) と 328 (leftover context.json による誤 bail) は同じ「進行中誤判定」機構の裏表、347 (空 fix commit) も同経路の後始末不備。
+**束ねた理由 (起案時)**: 3 件とも post-merge-feedback 経路の欠陥で、444 (stale meta による恒久ブロック) と 328 (leftover context.json による誤 bail) は同じ「進行中誤判定」機構の裏表、347 (空 fix commit) も同経路の後始末不備、と見立てていた。**実際には 347 の実装先は `cli-merge-pipeline` ではなく `cli-pr-monitor` だった** (下記 347 の節)。444 / 328 は見立てどおり `cli-merge-pipeline` (と reaper 側の `hooks-session-start`)。
 
-> **順位 444 は [PR #417](https://github.com/aloekun/claude-code-hook-test/pull/417) で実装完了 (2026-08-18)、マージ待ち。** 本計画の作成前から独立に起票されていた。**本 PR の残作業は 328 + 347 のみ**で、下記 444 の節は「当初計画がどう変わったか」の記録として残す (マージ後、台帳の後始末と同じタイミングで削除してよい)。
+> **PR A は完了 (2026-08-18)。** 順位 444 は [PR #417](https://github.com/aloekun/claude-code-hook-test/pull/417) で**マージ済み**。328 は着手時に前提が消えていたため seal のみ。347 は [PR #418](https://github.com/aloekun/claude-code-hook-test/pull/418) で実装。**以下 3 節は「当初計画がどう変わったか」の記録**で、実装内容そのものは各 PR を参照する。
 >
 > 実行時間分布の実測は #417 の中で完了した (自身の成果物を書いた完了 run 140 件: 中央値 8.9 分 / p95 16.5 分 / 最大 23.3 分 / 25 分超 0 件、分布は対数正規)。**閾値 1500 秒は実測で裏付けられた**ため変更していない。詳細は `run_registry::running_runs` の doc を参照。
 >
@@ -57,17 +57,21 @@
 - **回帰テスト**: 再実行シナリオ (1 本目=成果物ゼロ、2 本目=完走) で 1 本目が `failed` になること、`endTime` を捏造しないこと、status 確定の失敗を成功と報告しないこと、`reportDirectory` の `..` で別 run に到達できないこと。
 - **完了基準**: 達成済み。reaper 通過後に run 単位の成果物に基づいて終端化されること、reaper が走らなくても stale running がブロックしないこと、閾値内 running のブロック非退行。
 
-### 順位 328: 成功後に context.json が残り次マージの feedback を誤 bail させる
+### 順位 328 (前提消滅 — 記録): 成功後の context.json 残存による誤 bail
 
-- **不具合**: #295 の feedback が正常完了しても `.takt/post-merge-feedback-context.json` を掃除しないため、1500s 以内の連続マージで次の feedback が「進行中」と誤 bail (#296 で実観測、手動 recovery 済み)。
-- **対処**: `src/cli-merge-pipeline/src/pipeline.rs` の post_merge_feedback step で**正常完了時に context.json を削除**。fail 時は marker を残す現行 L2 recovery (ADR-030) を維持。先に leftover で誤 bail する再現テストを固定 (base_dir 注入等) してから直す。
-- **完了基準**: 連続マージ (成功後 25 分以内) で 2 回目の feedback が誤 bail しないこと (回帰テストで seal)。
+- **不具合 (2026-07-19 #296 で実観測)**: 旧 guard は `context.json` の mtime を見て「1500 秒以内に書かれていれば進行中」と判定していた。#295 の feedback が正常完了しても `context.json` を掃除しないため、25 分以内の連続マージで #296 の feedback が誤 bail した。
+- **着手時の確認で前提が消えていた**: 現行の `check_concurrent_run_guard` は `run_registry::running_runs` (= `meta.json` の `status` + `startTime`) **だけ**を読み、`context.json` を一切参照しない。判定根拠を run の状態へ移した**順位 398 (PR #388) の時点でこの結合は消えている**。`CONCURRENT_RUN_GUARD_SECS` も既に廃止済みで、コード上の残存は doc コメント内の言及のみ。
+- **したがって当初の対処 (成功時に context.json を削除) は実装しなかった**。guard がもう読まない以上、削除で得られるのは後片付けの綺麗さだけである一方、timeout kill を生き延びた orphan takt が `context.json` を読み直す経路が実在するため (ADR-030 § Reconciliation)、消す側にわずかながら実害の芽がある。**利得がほぼ無く risk が非ゼロなので採らない。**
+- **代わりに入れたもの**: 「書きたてで放置された `context.json` があっても guard を通る」ことを固定する回帰テスト (`a_leftover_context_file_does_not_block_the_next_feedback`)。同じ結合を将来再導入させないための seal。
+- **完了基準**: 達成済み (上記テストで seal)。
 
-### 順位 347: CodeRabbit findings が空でも fix commit が生成され abandon される
+### 順位 347 (実装済み): CodeRabbit findings が空でも fix commit が生成され abandon される
 
-- **不具合**: findings 0 件でも fix commit 生成 → abandon の noise (PR #310 で実観測)。
-- **対処**: 該当コードパスを特定 (cli-merge-pipeline / takt fix step、実装時に再調査が必要と明記されている) し、actionable findings 0 (空、または全件 nitpick/informational) なら commit 生成・abandon を skip。actionable 判定はテストで明示する。
-- **完了基準**: 「findings 空」「全 non-actionable」の両ケースで空 fix commit が作られないこと (回帰テストで seal)。
+- **不具合**: findings 0 件でも fix commit 生成 → abandon の noise (PR #310 で実観測。2026-08-18 の PR #417 監視でも再現)。
+- **該当コードパス (再調査の結果)**: `cli-merge-pipeline` ではなく **`src/cli-pr-monitor/src/stages/monitor.rs`** の `invoke_takt_into_outcome`。takt は「CodeRabbit がコメントを投稿した」だけでも起動する (`has_coderabbit_findings` は `new_comments` / `unresolved_threads` でも真になる) ため、findings 0 件のまま `create_fix_commit` が呼ばれていた。
+- **対処**: findings が 0 件なら fix commit の事前作成を skip する。
+- **「全件 non-actionable なら skip」は実装しなかった**: `extract_severity` の `"Info"` は `Critical` / `Major` / `Minor` / `High` / `Low` のどれにも一致しない場合の**受け皿**でもある。severity で絞ると、書式が変わって解析できなかった実指摘まで黙って skip する。判定根拠が確かな件数だけを条件にした。この契約はテストで固定している。
+- **完了基準**: 達成済み。findings 0 件で作成されないこと、`Info` のみでも「対象なし」に倒さないことを回帰テストで seal。
 
 **後始末**: todo22.md「順位 444」節 / todo17.md「post-merge feedback が成功後に…誤 bail させる」節 / todo14.md「CodeRabbit findings が空のとき fix commit 生成を skip」節を削除、todo-summary2.md の 444 / 328 / 347 行を削除。
 

diff --git a/docs/todo-summary2.md b/docs/todo-summary2.md
@@ -81,7 +81,6 @@
 | 324 | 🚀 Tier 1 | **`cli-pr-monitor::push_to_remote` に push 拒否検知が無く post-PR re-push が無言で失敗し得る (push-pipeline-fix-plan §6 backlog 9 移管)** | todo17.md | XS | なし (T5 = PR #282 が cli-push-runner 側で塞いだ silent-failure push と同型の穴。出力は `run_cmd_direct` で全量取得済のため判定追加のみ) |
 | 326 | 🔧 Tier 2 | **並列設計レビュアー (design-fit reviewer) の実験起案 — 見落とし実績の事前調査付き (R4/ADR-047 却下分析の代替案)** | todo17.md | S (Phase 0) / M (Phase 1 条件付き) | なし (Phase 0 の需要調査で見落とし実績ゼロなら見送り = negative result 永続化。ADR-047 却下確定 = refute.yaml 削除 revert PR とは独立に進められる) |
 | 327 | 🔧 Tier 3 | **多段コミットの ADR/observability 更新チェックリストを dev-conventions に追加 (#295/#296 post-merge feedback 採用: status 同期 / plain-text 参照 / セクション同期)** | todo17.md | S | なし (実害は各 PR review/feedback で捕捉済。doc checklist のみ、機械化は再発観測後にエスカレーション) |
-| 328 | 🚀 Tier 1 | **post-merge feedback が成功後に `post-merge-feedback-context.json` を残し次マージの feedback を誤 bail させる (cleanup gap、#296 マージで実観測)** | todo17.md | S | なし (連続マージで後発 PR の再発防止分析が構造的に skip。成功時 cleanup の追加 + 回帰テスト。ADR-030 L2 recovery で今回は手動救済済) |
 | 329 | 💎 Tier 3 | **新規 ADR 起案時の「判断根拠 × 既存 ADR 定義」矛盾チェックリストを dev-conventions に追加 (#301 post-merge feedback 採用)** | todo17.md | S | なし (ADR-055 初版が自定義の `decision` 軸と矛盾する除外根拠を採用→Amendment 撤回の手戻り。ADR 59件超で同型見落とし再発しうる。#327 と対の doc-only 対処) |
 | 330 | 💎 Tier 3 | **「行動要求 nudge は 2 チャネル返却」+「多義的戻り値は struct 化」convention の明文化 (#299 post-merge feedback 採用)** | todo17.md | XS | なし (ADR-059 の 2 チャネルパターンと `WeeklyReviewNudge` struct 化。第2弾展開 3件で再利用見込み。dev-conventions 1節追記) |
 | 331 | 🔧 Tier 2 | **hooks-session-start に systemMessage を含む JSON 出力の exe-spawn E2E テスト追加 (#299 post-merge feedback 採用)** | todo17.md | S | なし (現状 pure function レベルのみ、実 config パース込み exe 駆動の検証なし。ADR-049 exe-spawn E2E 先例流用。UI 実描画確認は別途 dogfood) |
@@ -97,7 +96,6 @@
 | 344 | 💎 Tier 3 | **並行性バグの root cause 分析で推測を禁止し観測的再現を要求するルール追加 (#312 post-merge feedback 採用)** | todo14.md | S | なし (#312 で「128-bit token 衝突」誤 root cause を 3 回外した後 atomic 計装で確定した実績。誤分析のまま fix は再発防止にならず Severity High。推論/観測判定は semantic 要で機械化不可につき rule docs のみ) |
 | 345 | 🚀 Tier 1 | **deploy 時の exe/config feature 互換性診断 (内容ベース、mtime 不使用) — stale-exe silent fail 防止 (#310 post-merge feedback 採用)** | todo14.md | M | なし (deployed exe が config 要求 feature を満たさず silent command-not-found で quality gate 誤 block、本セッションで 2 回実観測。exe 埋め込みバージョン vs config min_exe_version の内容ベース比較、mtime 不使用) |
 | 346 | 🔧 Tier 2 | **pre-merge checklist に「Deferred Tests Completed」ブロッカー項目を追加 (#310 post-merge feedback 採用)** | todo14.md | S | なし (PR #310 自体が workflow_dispatch スモークを post-merge に defer、実施漏れリスク実在) |
-| 347 | 🔧 Tier 2 | **CodeRabbit findings が空のとき fix commit 生成を skip (#310 post-merge feedback 採用)** | todo14.md | S | なし (空 fix commit → abandon の noise を PR #310 monitor で実観測。該当コードパスは実装時に再調査) |
 | 348 | 💎 Tier 3 | **CodeRabbit marker / GitHub event state の統合契約 doc + ADR-042 実例追記 (#310 post-merge feedback 採用)** | todo14.md | S | なし (marker format 変更時の無音失敗リスクが PR analysis で指摘、marker/state 依存が散在) |
 | 349 | 💎 Tier 3 | **pr-monitor.yml に state semantics / if 式 / hardening 意図のインラインコメント追加 (#310 post-merge feedback 採用)** | todo14.md | S | なし (state guard が redundant と誤認・折り畳み if 式が誤読される混乱が本セッションで 2 件実発生) |
 | 350 | 💎 Tier 3 | **新 config directive と要求最小 exe version の CHANGELOG/FEATURES 記録 (#310 post-merge feedback 採用)** | todo14.md | S | なし (順位 345 の互換性チェック機構と対になる human-readable 契約。2 回の stale-exe 実観測) |

diff --git a/docs/todo14.md b/docs/todo14.md
@@ -344,29 +344,6 @@
 
 ---
 
-### CodeRabbit findings が空のとき fix commit 生成を skip
-
-> **動機**: CodeRabbit findings が空でも fix commit が生成され abandoned になる挙動を PR #310 monitor で実観測した。空 commit → abandon は workflow noise / レビュー時の不確実性という UX 劣化を招く。PR #310 post-merge feedback Tier2 #3 で採用。
->
-> **対処案**: **actionable findings が 0 の場合** (findings が空、または全 findings が non-actionable〔nitpick / informational のみ〕) に fix commit 生成・abandon をスキップする。actionable 判定を作業計画とテストで明示する。該当コードパス (cli-merge-pipeline または該当 takt fix step) は実装時に再調査が必要。
->
-> **参照**: `.claude/feedback-reports/310.md` Tier2 #3、`src/cli-merge-pipeline` (post_merge_feedback / fix state 処理周辺)。
->
-> **実行優先度**: 🔧 Tier 2 — Severity Medium / Frequency Medium / Effort S / Adoption Risk None (該当コードパスは実装時に再調査)。
-
-#### 作業計画
-
-- [ ] 空 fix commit を生成しているコードパスを特定 (cli-merge-pipeline / takt fix step)
-- [ ] findings が空、または actionable findings が 0 (全 non-actionable) の場合に commit 作成・abandon をスキップするよう修正 (actionable 判定を明示)
-- [ ] 「findings 空」と「全 non-actionable」の両ケースをテストスコープに追加
-- [ ] 本エントリ削除 + todo-summary2.md 行削除
-
-#### 完了基準
-
-- CodeRabbit findings が空、または全 findings が non-actionable のとき、空 fix commit が作成されず abandon 処理も走らないこと (両ケースを回帰テストで seal)。
-
----
-
 ### CodeRabbit marker / GitHub event state の統合契約 doc + ADR-042 実例追記
 
 > **動機**: PR #310 の pre-push simplicity review が新 gate を「internally consistent」と評価した一方、marker format 変更時の無音失敗リスクが PR analysis で指摘された。CodeRabbit の marker 文字列 (summarize / rate-limited 等) と GitHub event state fields への依存が複数箇所に散在している。PR #310 post-merge feedback Tier3 #1 で採用。

diff --git a/docs/todo17.md b/docs/todo17.md
@@ -250,28 +250,6 @@
 
 ---
 
-### post-merge feedback が成功後に `post-merge-feedback-context.json` を残し次マージの feedback を誤 bail させる (cleanup gap、#296 マージで実観測)
-
-> **動機**: 2026-07-19 の #296 マージで、post_merge_feedback step が「前回の feedback がまだ進行中の可能性 (context.json が 820s 前に書かれた)」と判定して bail し、`.claude/feedback-reports/296.md.failed` marker を残した ([ADR-030](adr/adr-030-deterministic-post-merge-feedback.md) L2 recovery 経路)。原因は **#295 マージの post-merge feedback が正常完了 (295.md 生成) したにもかかわらず自身の `.takt/post-merge-feedback-context.json` を掃除せず残した**こと。約 25 分 (1500s threshold) 以内に次のマージを行うと、前回の leftover context.json を「進行中」と誤判定して feedback が走らない = **連続マージで後発の feedback が構造的に skip される**。今回は手動で context.json 削除 + `--feedback-only 296` で recovery したが、根治は context.json の cleanup。
->
-> **対処案**: post-merge feedback workflow (または cli-merge-pipeline) が feedback の**正常完了時に `post-merge-feedback-context.json` を削除**する。あわせて staleness 判定を「時刻ベース (820s < 1500s)」から「稼働中プロセスの実在確認」等に寄せるか、少なくとも成功時 cleanup で leftover を残さないようにする。fail 時は marker を残す現行 L2 recovery を維持 (真の中断と区別)。
->
-> **参照**: `src/cli-merge-pipeline/src/pipeline.rs` (post_merge_feedback step / context.json の書き出し・cleanup)、[ADR-030](adr/adr-030-deterministic-post-merge-feedback.md) (L1 floor / L2 recovery、marker 運用)、`.takt/post-merge-feedback-context.json`、#296 マージ実観測 (2026-07-19)。
->
-> **実行優先度**: 🚀 Tier 1 — Severity Medium (連続マージで後発 PR の再発防止分析が構造的に skip される。今回は手動 recovery で救済したが、気付かなければ feedback が静かに欠落) / Frequency Low〜Medium (連続マージ運用時) / Effort S (成功時 cleanup の追加)。
-
-#### 作業計画
-
-- [ ] 再現テスト: leftover context.json がある状態で 2 回目のマージ feedback が誤 bail することを固定 (base_dir 注入等)。
-- [ ] post-merge feedback の**正常完了時に context.json を削除**する (fail 時は marker を残す現行動作を維持)。
-- [ ] 本エントリ削除 + todo-summary2.md 行削除。
-
-#### 完了基準
-
-- 連続マージ (前回 feedback 成功後 25 分以内) でも 2 回目の post-merge feedback が leftover context.json で誤 bail せず実行されること (回帰テストで seal)。
-
----
-
 ### 新規 ADR 起案時の「判断根拠 × 既存 ADR 定義」矛盾チェックリストを追加 (#301 post-merge feedback 採用)
 
 > **動機**: PR-N3 (#301) で、ADR-055 初版が**自ら定義した `decision` 軸 (block/warn = 発火の重み)** と矛盾する除外根拠 (「nudge は block/warn に乗らない」) を採用しており、本 PR で Amendment を追加して除外根拠を撤回する手戻りが発生した。ADR は既に 59 件超を相互参照しており、新規 ADR が既存 ADR の定義・原則と衝突する見落としは他 ADR でも再発しうる。#301 の post-merge feedback が採用候補と判定 (Severity Medium / Frequency Medium / Effort S / Adoption Risk None)。