diff --git a/docs/adr/adr-018-pr-monitor-takt-migration.md b/docs/adr/adr-018-pr-monitor-takt-migration.md index fa78dcd..76e420c 100644 --- a/docs/adr/adr-018-pr-monitor-takt-migration.md +++ b/docs/adr/adr-018-pr-monitor-takt-migration.md @@ -130,3 +130,46 @@ takt fix の自動修正 + re-push が BG で走る間、Claude Code は state Claude Code が Task A (`pnpm create-pr`) と Task B (`pnpm observe-pr`) を 並行 BG 起動することで、observer は早期に終端状態を報告できる (ADR-022 責務分離原則と整合)。 + +## 追記 (2026-05-06): Bundle b で CronCreate を park モデルとして再導入 + observer モード撤廃 + +### 背景 + +本 ADR (2026-04-15 承認) は「daemon spawn + CronCreate による 4 段間接連携」を廃止する判断だった。当時の問題は **同一プロセス内の指揮系統が長すぎて各段が失敗しうる** ことであり、CronCreate の機能そのものを否定したわけではない。 + +PR #104 (2026-05 観測) で **47 分の長時間 rate-limit** が観測され、本 ADR 後の `std::thread::sleep` ベース in-process 待機 + `max_duration_secs=600s` (10 分) cap で auto-retry が機能しないケースが顕在化。同プロセス常駐モデルの構造的限界 (Claude Code session 終了で sleep 中の subprocess が kill される / 10 分超で `action_required` 通知に抜ける) が明らかに。 + +### Bundle b の決定 (2026-05-05、PR #113-115 で land) + +「daemon + CronCreate 4 段間接連携 (廃止対象)」とは異なる、**ADR-030 の責務分離パターン (Rust 状態管理 + Claude Code 周期確認) の 3 例目** として CronCreate を再導入: + +- **PR #113 (Bb-1)**: rate-limit retry の CronCreate park モデル化。Rust 側は state file (`pr-monitor-state.json`) に `next_wakeup_at_unix` / `wakeup_reason` を保存して exit、Claude Code 側は stdout の `[PR_MONITOR_PARK]` envelope を読んで CronCreate (`durable: true`) で wakeup を予約。in-process sleep を排除し session 終了でも CronCreate で次回起動が保証される +- **PR #114 (Bb-2)**: review 完了待ちの CronCreate park モデル展開。`finalize_initial_review_park` / `finalize_review_recheck_park` を追加し、polling を完全排除。**observer モード (2026-04-22 追記) は本 PR で撤廃** (二重 polling = 45s gh API + 5s observer の解消) +- **PR #115 (Bb-3)**: `[review_recheck]` config 化 + SessionStart catch-up nudge (`hooks-session-start` から `additionalContext` で再起動を促す `[PR_MONITOR_CATCHUP]` 出力) + +### CronCreate の重要事実 (廃止判断時に確認しなかった事項) + +Bundle b 設計時に再分析して判明した CronCreate の特性: + +- **時間制約なし**: 標準 5 フィールド cron 構文 (`MM HH DoM Mon DoW`)。「60 分上限」は **別ツール `ScheduleWakeup` (`/loop` 動的モード) の `clamped to [60, 3600]` 制約** であり、CronCreate には適用されない +- **One-shot**: `recurring: false` で任意の reset 時刻に 1 度だけ wakeup 可能 → 47 分でも 90 分でも cron で直接予約可能 +- **session 跨ぎ**: `durable: true` で `.claude/scheduled_tasks.json` に永続化、Claude Code 再起動を跨ぐ — 本 ADR (2026-04-15 時点) で言及した「Claude Code がセッション状態によっては CronCreate を正しく実行しない」リスクは durable 化で構造的に解消 +- **recurring の auto-expire**: 7 日で自動消滅 (rate-limit context では十分長い) + +### 廃止した 4 段間接連携 vs Bundle b park モデルの違い + +| 観点 | 廃止 (本 ADR の対象) | Bundle b 再導入 | +|---|---|---| +| アーキテクチャ | daemon spawn → state file → CronCreate → Claude → スキル | Rust exe (in-process sequential) → state file → Claude (`[PR_MONITOR_PARK]` 読み取り) → CronCreate (`durable: true`) → 再 invoke | +| 同期性 | daemon = 並行プロセス (通信失敗しうる) | exe = sequential、Claude が CronCreate 予約後に次回 invoke 待ち (in-process は 1 cycle 完結) | +| 失敗点 | 4 段全てで失敗しうる | Rust exe 1 段で完結、CronCreate は durable でロバスト | +| AI 分析 | お願いベース (失敗無音) | takt 分析 step を経由 (本 ADR の主流 + Bb-2/3 の park signal 経路) | + +→ Bundle b は本 ADR の **責務分離原則そのものを継承** しつつ、長時間 rate-limit (>10 分) を構造的に解消する補完層として整合。 + +### 関連 PR / commit + +- PR #113 (Bb-1): rate-limit retry CronCreate park +- PR #114 (Bb-2): review_recheck CronCreate park + observer 撤廃 +- PR #115 (Bb-3): config 拡張 + SessionStart catch-up nudge + sanitize() (CR Major #1+#2 fold-in) +- PR #116: Bb-3 post-merge-feedback 採用 3 件 (順位 76/77/78) を todo に登録 diff --git a/docs/adr/adr-033-todo-numbering-simplification.md b/docs/adr/adr-033-todo-numbering-simplification.md index 7cff8cc..f15cc45 100644 --- a/docs/adr/adr-033-todo-numbering-simplification.md +++ b/docs/adr/adr-033-todo-numbering-simplification.md @@ -121,7 +121,7 @@ grep -nE "順位 [0-9A-Za-z_-]+" docs/todo.md docs/todo2.md docs/todo3.md \ ### 「依存」列の二層追跡 — technical 依存 vs strategic 順序 -priority table の「依存」列 と、領域特化計画書 (例: `docs/coderabbit-monitoring-efficiency.md`) や Bundle 脚注に記録する依存関係は、**別レイヤ** を表す。両者が乖離していても矛盾ではない。 +priority table の「依存」列 と、領域特化計画書 (試験運用 doc / Bundle 脚注) に記録する依存関係は、**別レイヤ** を表す。両者が乖離していても矛盾ではない。 | 種別 | 記録先 | 意味 | 例 | |---|---|---|---| diff --git a/docs/adr/adr-034-coderabbit-auto-monitoring.md b/docs/adr/adr-034-coderabbit-auto-monitoring.md index 0c74d9b..0a29fbe 100644 --- a/docs/adr/adr-034-coderabbit-auto-monitoring.md +++ b/docs/adr/adr-034-coderabbit-auto-monitoring.md @@ -179,6 +179,34 @@ PR #99 セッションで以下の運用痛が観測された: - CR の rate-limit 仕様が変わっていないか (memory `project_coderabbit_rate_limit_overlay.md` の挙動が再現するか) を着手前に dogfood で確認 - `gh api` の rate-limit (CR とは別、GitHub API 側) が干渉しないか観察 +## Bundle b との関係 (2026-05-06 追記、`docs/coderabbit-monitoring-efficiency.md` retire 時に集約) + +Bundle b (Bb-1/Bb-2/Bb-3、PR #113-115、2026-05-05〜06 land) は本 ADR とは別領域 (Cron 機構 vs structured findings 消費) を扱うが、**Sub-PR 2 の主機能 = cli-pr-monitor rate-limit auto-retry + `@coderabbitai review` auto-trigger は Bb-1 で実質達成済**。Bundle a Sub-PR 2 の scope を再整理する。 + +### Sub-PR 2 の構成変化 (Bundle b land 後) + +| component | 旧 (本 ADR 当初) | 新 (Bundle b land 後) | +|---|---|---| +| rate-limit auto-retry 実装 (順位 42) | Sub-PR 2 で着手予定 | ✅ **Bb-1 (PR #113) で land 済**。CronCreate park モデルで `[rate_limit] reset 後の即時 retrigger → @coderabbitai review 自動投稿` が PR #115 dogfood で実証 | +| ADR-018 / ADR-009 retry policy 明文化 (順位 43) | Sub-PR 2 で着手予定 | ✅ **ADR-018 追記 (2026-05-06) で部分達成**。CronCreate 特性 + park モデル + Bundle b で再導入された経緯を記載済。残作業は ADR-009 navigation 注記 (Superseded by ADR-018 partial の link) | +| integration test (順位 46) | Sub-PR 2 で着手予定 | 未着手。Bb-1/Bb-2 の unit test (poll.rs / state.rs sibling parity) は存在するが、CR rate-limit 検出 → backoff → retry サイクルの **end-to-end test** はまだない | +| `parse_findings` error-path test infra (順位 49) | Sub-PR 2 で着手予定 | 未着手。Bundle b は `parse_findings` を touch していない別 area | + +### Sub-PR 2 着手時の推奨 scope + +旧 4 component → 残 3 component に縮小: + +- 順位 43 残 (ADR-009 navigation 注記、XS) +- 順位 46 (integration test、M) +- 順位 49 (parse_findings error-path test infra、M) + +順位 42 は Bb-1 で達成済のため Sub-PR 2 から除外、structured findings 駆動化 (= `check-ci-coderabbit --list-findings` 消費に切り替え) は残課題として 順位 46 の integration test 設計時に併せて検討する。 + +### Bundle b との並行進行性 (旧 `coderabbit-monitoring-efficiency.md` から引き継ぎ) + +- Bundle b と Bundle a Sub-PR 2 は **別領域** (Cron 機構 vs structured findings 消費) で並行進行可能と当初設計されたが、結果的に Bundle b 先行 land で Sub-PR 2 scope が縮小した +- 今後同種の bundle 並行設計を行う際の教訓: **「別領域」と判断した bundle が実装段階で重なる可能性がある** (Bb-1 の rate-limit auto-retry と Sub-PR 2 の rate-limit auto-retry が同 cli-pr-monitor を touch するため)。bundle 設計時に touched modules ベースで重複可能性を確認すべき + ## References - ADR-018: cli-pr-monitor takt 化 diff --git a/docs/coderabbit-monitoring-efficiency.md b/docs/coderabbit-monitoring-efficiency.md deleted file mode 100644 index 6a6451f..0000000 --- a/docs/coderabbit-monitoring-efficiency.md +++ /dev/null @@ -1,168 +0,0 @@ -# CodeRabbit 監視機能改善 - -> **目的**: 個人開発で CodeRabbit 無課金ユーザーの rate-limit (1 時間あたり 3 reviews 上限) で発生する待ち時間を、ユーザー手動介入なしに自動回復させる。「定期的に PR コメントを確認する」手間をなくし、快適な個人開発環境を整備する。 -> -> **本ドキュメントの役割**: CodeRabbit 監視機能の改善に関する task 分類・bundle 案を集約する index。各 task の作業詳細は `docs/todo*.md` 系列に置き、本ファイルは概要 + リンクに留める。 -> -> **状態**: 試験運用 (本ドキュメントは "計画書" であり、bundle が消化されたら役割を終える) -> -> **想定読者**: 本リポジトリで CodeRabbit と連携する自動 review 環境を運用するユーザー。「rate-limit に引っかかった時に手動介入を最小化したい」目的を持つ。 - ---- - -## 着手決定 (2026-05-05) - -### 採用案 - -**Bundle b (CR auto-monitoring core、3 PR 構成) を採用**。`max_duration_secs` 拡大による sleep 延長案 (案 C) は **却下**。 - -### 着手順 / 設計方針 - -- **着手は Bb-1 (順位 53) から** -- **CronCreate は `durable: true` で利用** — `.claude/scheduled_tasks.json` に永続化され、Claude Code session 再起動を跨ぐ -- **PR description で ADR-030 の責務分離パターン (L1 floor + L2 recovery) を引用** — post-merge-feedback で実証済の「機械的 Rust + Claude Code 定期チェック」分離原則を CR rate-limit に適用 (3 例目)。新 ADR で本パターン適用を明文化する想定 - -### 設計判断時に確認した CronCreate の重要事実 (今後の再分析を防ぐため記録) - -- 標準 5 フィールド cron 構文 (`MM HH DoM Mon DoW`) — **時間制約なし**。「60 分上限」は **別ツール `ScheduleWakeup` (`/loop` 動的モード) の `clamped to [60, 3600]` 制約** であり、CronCreate には適用されない -- One-shot (`recurring: false`) で任意の reset 時刻に 1 度だけ wakeup 可能 → 47 分でも 90 分でも cron で直接予約可能 -- `durable: true` で session 跨ぎが native サポート — 旧 ADR-009 設計の「session 終了で wakeup 発火しない」問題は durable 化で解消可能 (Bb-3 SessionStart catch-up は補完層として位置づけ) -- recurring task は 7 日 auto-expire (rate-limit context では十分長い) - -### ADR-018 との整合性 - -ADR-018 が廃止したのは「同一プロセス内で 4 段間接連携 (daemon → state file → CronCreate → Claude → skill) する旧設計」であり、**プロセス分離 + 責務分離原則そのものは ADR-018 流儀と整合**。Bundle b は ADR-030 の L1+L2 パターン (機械的 Rust 状態管理 + Claude Code 定期チェックの分離) を踏襲する。 - -### 案 C を却下した理由 - -- **`max_duration_secs` 1h cap 延長は短期的には有効だが、Claude Code session 終了時の silent loss を解消できない** — cli-pr-monitor は Claude Code Bash tool の child process として動作するため、session 終了で sleep 中の subprocess が kill される -- **CronCreate `durable: true` は session 跨ぎを native サポート** — 案 C 単体より UX が確実に良い -- 90+ 分 rate-limit に対する構造的限界 (案 C は cap 超過で fail、案 A は cron で任意時刻予約可能) -- 「30 分ごとに確認 → 残時間再計算で reschedule」chain pattern は CronCreate native 機能で実現可能 (ユーザー指摘、本決定の根拠の一つ) - -### 進捗 - -- ✅ **Bb-1 (順位 53) — マージ済 (PR #113、2026-05-05)**: `cli-pr-monitor` の rate-limit retry を CronCreate park モデルに切り替え。post-merge-feedback で T2-2 のみ採用 (順位 75)、T3-1/T3-2 はユーザー判断で却下 (memory: feedback_no_unenforced_rules)。 -- ✅ **Bb-2 (順位 54) + 順位 75 (T2-2 Bb-1 follow-up) — マージ済 (PR #114、2026-05-05)**: review 完了待ちを CronCreate park モデルに展開し、polling 完全排除 + 二重 polling (45s gh API + 5s observer) を撤廃。T2-2 の sibling parity 回帰テストを同 PR で bundled。CR Major 2 件 (head 不一致時の wakeup 誤判定 / fresh push での recheck count 持ち越し) は fold-in 修正で land。post-merge-feedback で 2 件採用 / 5 件様子見 / 3 件却下 (詳細レポート: `.claude/feedback-reports/114.md`)。 -- ✅ **Bb-3 (順位 55) — マージ済 (PR #115、2026-05-06)**: `[review_recheck]` config セクションを `pr-monitor-config.toml` に追加し旧 hard-coded const (INITIAL_REVIEW_WAIT_SECS / REVIEW_RECHECK_WAIT_SECS / MAX_REVIEW_RECHECKS) を `PollContext` 経由で thread。SessionStart hook (`hooks-session-start`) に catch-up nudge を追加 (state.action が `parked_*` かつ `next_wakeup_at_unix <= now` のとき additionalContext に `[PR_MONITOR_CATCHUP]` を注入)。MonitorConfig::poll_interval_secs (Bb-2 で未使用化) を削除し既存 toml は legacy フィールド無視で後方互換。T2-2 follow-up として `finalize_park_siblings_have_symmetric_write_state_handling` を 3 sibling 化 (`finalize_initial_review_park` を追加)。 - - **設計判断: SessionStart catch-up は別プロセス spawn せず additionalContext で nudge** (advisor 推奨 option b)。Windows 環境での handle 継承 / stdout 可視性問題を回避し、PARK signal flow を session 内に保つ。 - - **false-positive 抑制**: terminal action (`action_required` / `passed_clean` / `continue_monitoring`) では `next_wakeup_at_unix` が古い park 由来で残っていても nudge を出さない (action prefix `parked_` を gate に使用)。 - - **fold-in 修正 (PR review 中に発生)**: CR Major #1 (`max_review_rechecks=0` / `wait_secs=0` / overflow) → `ReviewRecheckConfig::sanitize()` を実装し `load_config` 経路で適用。CR Major #2 (sanitize 自身の境界値テストが overflow を許容する自己矛盾) → 上限を `i64::MAX` から `MAX_SAFE_WAIT_SECS = 1 年 (31,536,000秒)` に変更し `now_unix + wait_secs as i64` の overflow を構造的に防止。CR から両 Major fix に positive 評価あり (``)。 - - **dogfood 実証**: PR #115 自身で Bundle b 全機能 (Bb-1 rate-limit park + 自動 retrigger / Bb-2 wakeup 経路 / Bb-2 review_recheck count / Bb-3 sanitize) が連携動作。`@coderabbitai review` 自動投稿 → review_recheck park → wakeup → 再 review 取得のサイクルを実 PR で完走。 - - **post-merge-feedback で 3 件採用 / 4 件様子見 / 3 件却下** (詳細レポート: `.claude/feedback-reports/115.md`)。採用 3 件は順位 76 (cross-module overflow 統合テスト) / 順位 77 (Unix timestamp baseline 境界値テスト) / 順位 78 (ADR-038 + CLAUDE.md security 拡充) として todo.md に登録済。 - -**🎉 Bundle b 完成**: Bb-1 / Bb-2 / Bb-3 全 3 PR + 順位 75 (T2-2 Bb-1 follow-up) + 順位 76-78 (Bb-3 follow-up) = CronCreate park モデルへの移行完結。同プロセス常駐型 polling から「Rust 状態管理 + Claude Code 周期確認」の責務分離 (ADR-030 パターンの 3 つ目の適用例) へ転換。 - ---- - -## 現状の課題 - -- **CodeRabbit 無課金**: 1 時間あたり 3 reviews 上限 -- **上限到達時の挙動**: rate-limit comment が PR に投稿され、最大 60 分の `wait_minutes` が記載される -- **既存実装** (`cli-pr-monitor`、PR #97 で land 済) の限界: - - rate-limit 自動検出 + 再トリガー機構あり - - ただし `std::thread::sleep` 同プロセス内待機 + `max_duration_secs=600s` (10 分) cap で**長時間 rate-limit にバウンス**する - - PR #104 で 47 分 rate-limit を実観測、auto-retry が機能せず `action_required` 通知 → ユーザーは手動で PR コメントをチェックして再投稿する必要 - -## ボトルネック分析 - -| ボトルネック | 現状 | 改善方向 | -|---|---|---| -| 長時間 rate-limit (>10 分) の auto-retry | `std::thread::sleep` + 600s budget cap でバウンス | **CronCreate ベース wakeup** に置換、長時間待機を構造的に可能化 | -| review 完了待ちの polling 負荷 | 45s 間隔で gh API polling + observer 5s 間隔 polling | 計算時刻 wakeup に置換、**polling 完全排除** | -| AI 離席中の silent loss | wakeup 発火しない期間に rate-limit 解除しても検知できない | **SessionStart hook で pending wakeup catch-up** | -| structured findings 取得 | CodeRabbit comment text を grep ベース parse | `check-ci-coderabbit --list-findings` で構造化取得 (Sub-PR 1 で API 提供済) | -| 自動 trigger の信頼性 | error-path test infra なし、silent fail (`unwrap_or_else` で空配列 fallback) 検出機構なし | parse_findings の error-path test 追加 | -| ポリシーの暗黙化 | rate-limit retry の判断基準が ADR-018 / ADR-009 で散在 | ADR で明文化 | - ---- - -## 改善 task 分類 - -各 task の詳細 (動機 / 設計決定 / 作業計画 / 完了基準) は `docs/todo*.md` 系列を参照すること。本セクションは概要 + 効果のみ記載。 - -### 🎯 HIGH IMPACT — rate-limit 自動回復の中核 - -| 順位 | Tier | タスク概要 | 効果 | 作業詳細 | -|---|---|---|---|---| -| 53 | 🚀 Tier 1 | rate-limit retry の CronCreate 化 (Bundle b PR-1) | **致命点解消**。47 分 rate-limit を auto-retry 可能に。同プロセス常駐モデル → スケジュール起動モデルへ転換 | [todo5.md](todo5.md) | -| 42 | 🔧 Tier 2 | cli-pr-monitor rate-limit auto-retry + `@coderabbitai review` auto-trigger 実装 (Bundle a Sub-PR 2) | `check-ci-coderabbit --list-findings` (Sub-PR 1 land 済) を消費して構造化 retry に進化 | [todo4.md](todo4.md) | -| 54 | 🔧 Tier 2 | review 完了待ちの CronCreate 化 + observer 廃止 (Bundle b PR-2) | polling 完全排除、固定値 wakeup 化 | [todo5.md](todo5.md) | - -### 🛠 MEDIUM IMPACT — 信頼性 / silent loss 防止 - -| 順位 | Tier | タスク概要 | 効果 | 作業詳細 | -|---|---|---|---|---| -| 46 | 🔧 Tier 2 | CodeRabbit rate-limit auto-retry の integration test (Bundle a Sub-PR 2) | rate-limit auto-retry の信頼性確保 | [todo4.md](todo4.md) | -| 49 | 🔧 Tier 2 | `parse_findings` 系の error-path test infrastructure (Bundle a Sub-PR 2) | silent fail (`unwrap_or_else(\|_\| empty)`) を抑止、cli-pr-monitor mock infra も流用 | [todo5.md](todo5.md) | -| 55 | 💎 Tier 3 | config 拡張 + SessionStart catch-up (Bundle b PR-3) | AI 不在時の silent loss 防止、固定値 (`monitor.toml` 化) で調整可能 | [todo5.md](todo5.md) | -| 15 | 🔧 Tier 2 | cli-pr-monitor 通知 Recovery 経路 (SessionStart hook 拡張) ★ silent loss prevention | ADR-030 L2 recovery パターンを cli-pr-monitor に適用 | [todo3.md](todo3.md) | -| 11 | 🔧 Tier 2 | cli-pr-monitor プロセス正常終了の integration test (PR #85 T2-2) | プロセス挙動の信頼性確保 (auxiliary) | [todo2.md](todo2.md) | - -### 📋 LOW IMPACT — ドキュメント整備 - -| 順位 | Tier | タスク概要 | 作業詳細 | -|---|---|---|---| -| 43 | 💎 Tier 3 | ADR-018 / ADR-009 の rate-limit retry ポリシー明文化 (Bundle a Sub-PR 2) | [todo4.md](todo4.md) | - ---- - -## 推奨 bundle - -### Bundle "CR auto-monitoring core" (Bundle b、最優先) - -ユーザー目的「rate-limit 待ち時間に手動介入なし」の最短達成パス。 - -| 含む順位 | 概要 | 工数 | -|---|---|---| -| 53 | 中核: rate-limit retry の CronCreate 化 (PR-1) | M | -| 54 | review 完了待ちの CronCreate 化 + observer 廃止 (PR-2) | M | -| 55 | config 拡張 + SessionStart catch-up (PR-3) | S | - -**依存関係**: 54 は 53 land 後、55 は 53 + 54 land 後。PR を 3 本に分けて順次 land 推奨。 - -**期待効果**: - -- 順位 53 land 後: 47 分 rate-limit でも auto-retry が動作 (= ユーザー手動介入なしに review が再開) -- 順位 54 land 後: polling 排除で Claude Code セッション稼働中の overhead 削減 -- 順位 55 land 後: AI 離席時の silent loss 解消 (起動時に pending wakeup を catch-up) - -### Bundle "CR rate-limit auto-retry robustness" (Bundle a Sub-PR 2、補完) - -| 含む順位 | 概要 | 工数 | -|---|---|---| -| 42 | auto-retry + `@coderabbitai review` auto-trigger 実装 | M | -| 43 | ADR-018 / ADR-009 明文化 | S | -| 46 | integration test | M | -| 49 | `parse_findings` error-path test infra | M | - -**依存関係**: Sub-PR 1 (順位 44/45 = PR #100/#101 で land 済) の `check-ci-coderabbit --list-findings` API を消費。1 PR で 4 順位を統合する設計 (cli-pr-monitor mock infra を 4 順位で共有)。 - -**期待効果**: 既存 grep ベース parse から構造化 findings 駆動の auto-retry へ進化。`parse_findings` の silent fail を test 化することで、rate-limit 検出漏れによる手動介入リスクを抑止。 - -### 並行進行可能性 - -- **Bundle b** と **Bundle a Sub-PR 2** は別領域 (Cron 機構 vs structured findings 消費)、**並行進行可** -- ただし dogfood 観測の signal 純度を保つため 1 PR ずつ land を推奨 - -### 推奨実行順序 (ユーザー目的の最短達成) - -1. **順位 53** (Bundle b PR-1): 致命点解消、即座に user benefit -2. **順位 42 + 43 + 46 + 49** (Bundle a Sub-PR 2): auto-retry の信頼性 + 構造化 findings 駆動化 -3. **順位 54** (Bundle b PR-2): polling 排除 -4. **順位 55** (Bundle b PR-3): silent loss 解消、polish - -並行可: 1 と 2 は別領域なので、片方の dogfood 中にもう一方を着手できる。 - ---- - -## 関連ドキュメント - -- [docs/todo.md](todo.md) — 推奨実行順序サマリ表 (priority table) -- [ADR-035: docs-only PR 評価ポリシー](adr/adr-035-doc-evaluation-policy.md) — docs PR iteration 改善の核 (旧 docs-pr-iteration-efficiency.md は retire 済、本 ADR に集約) -- [ADR-036: Bundle Z 3 層アーキテクチャ](adr/adr-036-bundle-z-three-layer-review.md) — pre-push-review 改善 (旧 pipeline-token-efficiency.md #B セクション) -- [ADR-037: takt fix-trust shortcut](adr/adr-037-takt-fix-trust-shortcut.md) — post-pr-review 短縮 (旧 #C-2) -- [ADR-009: Post-PR Monitor — push/PR作成後の CI・CodeRabbit 自動監視](adr/adr-009-post-pr-monitor.md) -- [ADR-018: cli-pr-monitor の takt ベース移行と CronCreate 廃止](adr/adr-018-pr-monitor-takt-migration.md) — Bundle b で再導入する CronCreate の設計根拠 (廃止判断と整合) -- [ADR-019: CodeRabbit レビュー運用のハイブリッド構成](adr/adr-019-coderabbit-review-hybrid-policy.md) — CodeRabbit 運用根拠 -- [ADR-034: CodeRabbit 監視・対話の自動化戦略 — Bundle a 設計根拠](adr/adr-034-coderabbit-auto-monitoring.md) — Bundle a の設計根拠 diff --git a/docs/todo.md b/docs/todo.md index a6e1005..1faa79a 100644 --- a/docs/todo.md +++ b/docs/todo.md @@ -28,7 +28,6 @@ | 8 | 🔧 Tier 2 | 週次レビュー (ADR-031) Phase B 実装 | todo.md | 中-高 | なし (順位 20 の compensating check 前提) | | 10 | 🔧 Tier 2 | ADR-032 PR-broken-link: broken-link-check + 内部アンカー検査 統合 | todo2.md | Small-中 | なし (clean baseline 確立済) | | 11 | 🔧 Tier 2 | `cli-pr-monitor` プロセス正常終了の integration test (PR #85 T2-2) | todo2.md | S | なし | -| 15 | 🔧 Tier 2 | **cli-pr-monitor 通知 Recovery 経路 (SessionStart hook 拡張)** ★ silent loss prevention | todo3.md | S/M | なし (ADR-030 L2 recovery パターンを cli-pr-monitor に適用) | | 16 | 🔧 Tier 2 | **`vitest` を devDependencies に固定 (PR #88 T2-3)** | todo3.md | Small | なし | | 17 | 🔧 Tier 2 | **`pnpm create-pr` 必須引数ヘルプ改善 (PR #88 T2-5)** | todo3.md | Small | なし | | 18 | 🔧 Tier 2 | **`.failed` marker への recovery 手順自己文書化 (PR #90 T2-2)** | todo3.md | S | なし | diff --git a/docs/todo3.md b/docs/todo3.md index f8b2c7b..f1a57b3 100644 --- a/docs/todo3.md +++ b/docs/todo3.md @@ -272,55 +272,6 @@ prompt and prompt Claude to re-run the workflow. --- -### cli-pr-monitor 通知 Recovery 経路 (SessionStart hook 拡張) - -> **動機**: cli-pr-monitor は `pnpm push` / `pnpm create-pr` 内で in-process 同期実行され、CodeRabbit findings の検出結果を **親プロセスの stdout** で Claude shell に渡す設計 (ADR-018)。しかし Claude Code の再起動 / parent shell の orphan 化が起きると stdout が消失し、`.claude/pr-monitor-state.json` の `notified=false` 状態のまま silent loss する。本リポジトリでも PR #91 直後に Claude Code 再起動でこの事象を実体験。 -> -> **本タスクの位置づけ**: ADR-029 → ADR-030 で確立した「`.failed` marker + L2 recovery hook (UserPromptSubmit)」と同型のパターンを cli-pr-monitor 系に適用。SessionStart hook (`hooks-session-start`) を拡張し、`.claude/pr-monitor-state.json` の `notified=false + last_checked が古い (例: > 30 分)` を検出したら additionalContext で「未通知の review findings あり、`gh pr view` で確認推奨」を出力する。 -> -> **参照**: PR #91 セッション中のユーザー言及。post-merge-feedback report には未含、明示的に採用合意あり。 -> -> **実行優先度**: 🔧 **Tier 2** — 工数 S/M。silent loss 防止の保険。rate-limit critical 系 (cli-pr-monitor ポーリング延長 / post-pr-review rate-limit 自動検出) との優先度については rate-limit 系の方が日次影響大だが、本 task は **「再起動跨ぎの確実な通知伝達」** をカバーする補完層。 - -#### 設計決定 (案) - -- 配置先: `src/hooks-session-start/` (既存 SessionStart hook crate に機能追加) -- 検出ロジック (案): - - `.claude/pr-monitor-state.json` を読む (なければ no-op) - - `notified == false` AND `last_checked` が現在時刻から 30 分以上前 → recovery 必要 - - 該当 PR の概要 (action, summary, findings count) を additionalContext で出力 -- 出力例: - ```text - [PR_MONITOR_RECOVERY] - PR #N の cli-pr-monitor 結果が未通知です (last_checked: )。 - action: action_required, findings: 2 件 - 詳細: cat .claude/pr-monitor-state.json または gh pr view N - ``` -- 設計上の選択肢: - - 案 A: `notified=true` への自動更新は行わない (Claude が `pnpm mark-notified` を呼ぶ既存経路を維持) - - 案 B: SessionStart hook が自動的に `notified=true` にする (薄い recovery、二重通知を避ける) - - 推奨: 案 A (Claude の判断に委ねる方が安全) - -#### 作業計画 - -- [ ] hooks-session-start crate に state file 読み込み + recovery 判定ロジック追加 -- [ ] additionalContext 出力フォーマット決定 -- [ ] dogfood: state file を手動で `notified=false + last_checked が古い` 状態にして SessionStart hook 起動 → recovery context 出力確認 -- [ ] 派生プロジェクトに deploy -- [ ] 本 todo3.md エントリを削除 - -#### 完了基準 - -- Claude Code 再起動後の SessionStart で、未通知の cli-pr-monitor 結果があれば additionalContext として届く -- silent loss が再発しない (再起動跨ぎでも recovery 経路で必ず pickup される) -- 派生プロジェクト (techbook-ledger / auto-review-fix-vc) でも同機構が動作 - -#### 詰まっている箇所 - -なし (Effort S/M、ADR-030 の L2 recovery パターンを cli-pr-monitor に適用するだけ) - ---- - ### takt ハーネスの `REJECT-ESCALATE` terminal verdict 実装 (PR #91 T2-2) > **動機**: PR #91 の post-pr-review で `supervise` step が 4 回、`fix_supervisor` step が 4 回の計 8 ステップを「修正不可能な制約あり」と繰り返し報告したにもかかわらず、takt harness はループを継続した。`.claude/` filter + ADR-030 制約明記 task (PR #91 T2-1 + T3-2 Bundle) が path-based に解決するのに対し、本 task は **iteration 上限到達前に「人間判断に委譲する」と AI 自身が宣言できる verdict** を提供する一般解。