Skip to content

docs(adr): coderabbit-monitoring-efficiency.md retire — knowledge を ADR-018/034 に集約 #117

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
aloekun merged 1 commit into from
May 6, 2026
Merged

docs(adr): coderabbit-monitoring-efficiency.md retire — knowledge を ADR-018/034 に集約 #117

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 43 additions & 0 deletions docs/adr/adr-018-pr-monitor-takt-migration.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 モード撤廃

Comment on lines +134 to +135
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot May 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

見出しが現行判断を誤解させる可能性があります

追記で CronCreate の再導入を正式に記録しているため、タイトルの「CronCreate 廃止」は現時点の意思決定状態としてはミスリードです。
CronCreate 廃止 を「当初判断」に限定する表現（例: 「当初廃止→parkモデルで再導入」）に更新すると、ADR 単体読解時の誤読を防げます。

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/adr/adr-018-pr-monitor-takt-migration.md` around lines 134 - 135, The
heading "CronCreate 廃止" is misleading now that the note documents reintroducing
CronCreate; update the title to reflect it as the initial decision (e.g., change
"CronCreate 廃止" to "当初廃止→parkモデルで再導入" or equivalent) so the ADR clearly shows
the original abolishment and subsequent reintroduction; locate and edit the
heading string "CronCreate 廃止" (and nearby summary line "追記 (2026-05-06): Bundle
b で CronCreate を park モデルとして再導入 + observer モード撤廃") to use the revised phrasing.

### 背景

本 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 に登録
2 changes: 1 addition & 1 deletion docs/adr/adr-033-todo-numbering-simplification.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 脚注) に記録する依存関係は、**別レイヤ** を表す。両者が乖離していても矛盾ではない。

| 種別 | 記録先 | 意味 | 例 |
|---|---|---|---|
Expand Down
28 changes: 28 additions & 0 deletions docs/adr/adr-034-coderabbit-auto-monitoring.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 化
Expand Down
Loading