docs: ADR-031 § Adoption Criteria threshold + Bundle CR-RL stale cleanup

docs/adr/adr-031-weekly-review-pipeline.md

@@ -22,6 +22,24 @@ Phase E dogfood は 2 回実施 (2026-05-30 / 2026-06-01) で計 18 findings (12
 
 **判断**: 試験運用 → **承認済み**。本 ADR の設計 (3 facets parallel + aggregate + skill + reminder hook) は dogfood で機能、改善余地 (重複検出 MVP+1 = todo10.md:368) は別 task として trackable。Phase F (自動化 cron 化) は本採用後の任意拡張のまま継続。
 
+### 採用判定の閾値 (本採用化条件)
+
+> 上記「採用判定の根拠」は Phase E dogfood の **観測値の記録** であり、本 section は「次に試験運用 ADR が本採用判定に到達したとき、どこを閾値とみなすか」を一意化するための **判定基準** を規定する。観測値と閾値を分離することで、将来 trial ADR (例: ADR-040 / ADR-041 等) の採用判定で「ADR-031 § 採用判定の閾値 を参照」で再利用可能にする。
+
+本 ADR で本採用判定に達したと判断するために満たす必要があった 5 閾値:
+
+| # | 閾値項目 | 基準値 | 設計上の意義 |
+|---|---|---|---|
+| 1 | **採用率** | ≥ 40% | low-quality findings が多すぎる pipeline は機能していない signal。観測 44% (= 8/18) で受容 |
+| 2 | **wall-clock** | ≤ 10 分 | 作業 flow への侵襲性。context warm cache (5 分 TTL) を破壊しない範囲。観測 ~5 分で受容 |
+| 3 | **false positive** | ≤ 5% | alert fatigue 防止、user 判断コスト線形成長を抑制。観測 0% で受容 |
+| 4 | **context window 圧迫** | なし | LLM facet が 1 リクエストに収まる、whole-tree review 自体の構造制約。観測なしで受容 |
+| 5 | **systemic finding 検出力** | 実検出ありで scope 軸の空白埋め | cross-PR drift / dead-pointer / partial overlap 等の whole-tree 特有 finding を実検出することで「軸の空白埋め」目的を達成。観測 S05↔順位 173 完全重複 / S01 4-5 crate 横断 / A01 ADR-032 dead-pointer 等で受容 |
+
+5 項目全てを充足した場合に本採用昇格と判断する。**1 項目でも未達なら継続 (試験運用延長) または却下** を選択する (継続は 1 回まで、[ADR-039 § Bounded lifetime](adr-039-experimental-feature-standard-pattern.md#3-bounded-lifetime-試験期限と採否判定基準) の 3 値 = 採用 / 却下 / 継続に対応する具体化例として参照可能)。
+
+閾値値 (40% / 10 分 / 5%) は Phase D + E の 2 回観測ベースの暫定値。将来の trial ADR 採用判定で dogfood data point が追加されたら、本 ADR の本 section を改訂して再校正する余地を残す。
+
 ## コンテキスト
 
 ### 問題: 既存 3 パイプラインの review scope の空白

docs/adr/adr-039-experimental-feature-standard-pattern.md

@@ -126,7 +126,7 @@ PR body にも kill-switch table を含める (起動経路 / 停止コマンド
 
 ## 関連
 
-- [ADR-031](adr-031-weekly-review-pipeline.md) — 試験運用、3 点セット部分適合
+- [ADR-031](adr-031-weekly-review-pipeline.md) — 承認済み (2026-06-01 本採用昇格)。§ 採用判定の閾値 (本採用化条件) が本 ADR § 3 (Bounded lifetime) の「採用 / 却下 / 継続」3 値判定基準の具体化例として参照可能 (5 閾値: 採用率 / wall-clock / FP / context 圧迫 / systemic 検出力)
 - [ADR-036](adr-036-bundle-z-three-layer-review.md) — 試験運用、3 点セット部分適合
 - [ADR-038](adr-038-local-llm-finding-classification.md) — 試験運用、3 点セット完全適合 (本 ADR の trigger 事例)
 - `~/.claude/rules/common/docs-governance.md` — Document Lifecycle Classification / Retirement Workflow

docs/todo-summary.md

@@ -77,9 +77,6 @@
 | 162 | 🔧 Tier 2 | **fail-closed error path (Option::None) 個別テスト追加 (PR #177 T2-#2 採用)** | todo9.md | S | なし (PR #177 Major #1 「`behind.unwrap_or(0)` fail-closed 漏れ」fix の回帰テスト、`check_todo_staleness` / `build_todo_staleness_message` の None ケース独立検証、Severity High + Frequency Medium、security gate + Option return pattern の reference) |
 | 163 | 🔧 Tier 2 | **Cross-ref edge case test coverage 追加 — percent-encode / GFM heading slug / relative path normalize (PR #179 T2-#1 採用)** | todo9.md | S | なし (PR #179 で cli-docs-lint の cross_ref validator を新規実装したが、percent-encode (`%20` / `%23`) / heading slug / `../` resolve の edge case が fixture テストで明示的に保護されていない silent regression リスク回避) |
 | 165 | 🔧 Tier 2 | **`pnpm create-pr` PR body truncation 回避を検証する e2e/integration test 追加 (PR #181 T2-#1 採用)** | todo9.md | S | なし (PR #134 + #181 の 2 回観測で Medium frequency に昇格、memory `feedback_pnpm_create_pr_body` の `--body-file` workaround を自動 regression gate 化、shell argument truncation の境界 (行数/バイト数) を fixture で測定、silent UX 劣化の早期検出、cli-pr-monitor の argv 組み立て層を test 対象、順位 166 と相補 = test 層 vs docs 層) |
-| 167 | 🚀 Tier 1 | **`check-ci-coderabbit` の `RATE_LIMIT_MARKER` を新フォーマット対応に更新 (PR #182 T1-#1 採用) ★ Bundle CR-RL** | todo9.md | M | なし (`src/check-ci-coderabbit/src/main.rs:251` 旧 marker `Rate limit exceeded` 固定 → multi-variant array `["Rate limit exceeded", "rate limited by coderabbit.ai"]` に変更、現行 CR は HTML マーカー + `## Review limit reached` フォーマットを使用、PR #182 で 30+ 分 polling 観測の root cause、`RateLimitOutcome::Parked` 経路 (ADR-018) が silent regression で無効化されている critical bug、順位 168 + 169 と Bundle CR-RL で同 PR land 推奨) |
-| 168 | 🔧 Tier 2 | **CR rate-limit detection integration test — 新旧両フォーマット対応 fixture 追加 (PR #182 T2-#1 採用) ★ Bundle CR-RL** | todo9.md | S | 順位 167 の marker 配列化と pair、`#[cfg(test)]` に新 format fixture 2-3 variant 追加 (HTML マーカー + `## Review limit reached` の minimum reproduction)、既存 6 fixture (旧 format) は維持して backward compat、silent regression を test で検出可能化 |
-| 169 | 💎 Tier 3 | **ADR-018 / ADR-034 に CR rate-limit format evolution と検出ロジック同期戦略を codify (PR #182 T3-#1 採用) ★ Bundle CR-RL** | todo9.md | XS | 順位 167 + 168 と同 commit 推奨、ADR-034 に「既知 format 一覧 + 検出 logic 更新手順」を追記、ADR-018 lines 185-186 を multi-variant 参照に更新、CR の format 進化への構造的予防策、永続 layer (ADR) での format drift 防止 |
 | 170 | 💎 Tier 3 | **`git-workflow.md § Multi-PR chaining` を「1 PR 内 multi-commit + intent 明記」パターンに拡張 (PR #183 T3-#1 採用)** | todo9.md | S | なし (PR #119/#120/#121 + #183 の 4 観測で Frequency High、commit 分割判断 + intent 記述ガイドを既存 section に追記、`~/.claude/rules/common/git-workflow.md` 編集、派生プロジェクトへ自動波及、`feedback_global_config_backup` 適用必須) |
 | 171 | 💎 Tier 3 | **`docs-governance.md` に「Operational reference vs Pointer reference」区別 section を追加 (PR #183 T3-#2 採用) ★ Bundle DG-RULES** | todo9.md | S | 順位 172 と同 PR 推奨、PR #183 A01 修正で実適用した判定ロジック (operational = workflow 動作記述 = 保持可 / pointer = section 名・順位番号参照 = 置換必要) を `~/.claude/rules/common/docs-governance.md` § Cross-File Reference Lifecycle に新 sub-section として codify、ADR-031 lines 79-302 中 line 270 のみが真の pointer だった実例を inline cite、派生プロジェクトへ自動波及、`feedback_global_config_backup` 適用必須 |
 | 172 | 💎 Tier 3 | **CR ephemeral artifact Nitpick の統一 skip 基準を memory に codify (PR #183 T3-#3 採用) ★ Bundle DG-RULES** | todo9.md | XS | 順位 171 と同 PR 推奨、CR が `docs/todo*.md` 系 ephemeral artifact 内の行番号参照を Nitpick 指摘した場合は skip 推奨という判断基準を新 memory `feedback_coderabbit_ephemeral_nitpick.md` に codify、既存 memory `feedback_coderabbit_no_actionable_merge_signal` の補完、本リポジトリ専用 (派生プロジェクトには波及しない)、`feedback_global_config_backup` 適用推奨 |

docs/todo9.md

@@ -751,132 +751,6 @@
 
 ---
 
-### `check-ci-coderabbit` の `RATE_LIMIT_MARKER` を新フォーマット対応に更新 (PR #182 T1-#1 採用) ★ Bundle CR-RL
-
-> **動機**: PR #182 セッションで CR の rate-limit が 30+ 分間検出されず、`cli-pr-monitor` が無効な polling を継続した実観測ベース。`src/check-ci-coderabbit/src/main.rs:251` の `RATE_LIMIT_MARKER = "Rate limit exceeded"` は CR の旧フォーマット時代の固定値で、現行 CR は `<!-- This is an auto-generated comment: rate limited by coderabbit.ai -->` HTML マーカー + `## Review limit reached` heading + `you've reached your PR review rate limit` 本文を使用。format drift により `is_rate_limit_comment()` が常に false を返し、`RateLimitOutcome::Parked` 経路 (ADR-018 設計) が完全に無効化されている silent regression。
->
-> **本タスクの位置づけ**: PR #182 post-merge-feedback Tier 1 #1 採用 (Severity High / Frequency Medium / Effort M / Adoption Risk None、2026-05-29 ユーザー承認)。Tier 1 機械強制層の修正、Bundle CR-RL (本 entry + 順位 168 + 順位 169) で同一 PR land 推奨。
->
-> **参照**: `.claude/feedback-reports/182.md` Tier 1 #1、`src/check-ci-coderabbit/src/main.rs:251` (現状コード)、`src/check-ci-coderabbit/src/main.rs:1298-1370` 周辺 (既存 fixture は旧フォーマットのみ)、`docs/adr/adr-018-pr-monitor-takt-migration.md` (rate-limit 経路の設計根拠、旧 marker 前提で記載)、`docs/adr/adr-034-coderabbit-auto-monitoring.md` line 64 (旧 marker regex 検出記述)、PR #182 セッションでの 30+ 分 polling 観測 (PR #182 / #183 land 時の transcript)
->
-> **実行優先度**: 🚀 **Tier 1** — Effort M。CR rate-limit 検出が常時無効化されている critical bug 修正。
-
-#### 設計決定 (案)
-
-- **multi-variant marker 配列化**: `const RATE_LIMIT_MARKERS: &[&str] = &["Rate limit exceeded", "rate limited by coderabbit.ai"]` (HTML マーカーは最も安定なため優先、旧 marker は backward compat)
-- **format 進化への耐性**: marker 配列の任意 1 件 hit で rate-limit 判定、新 CR format 追加時は配列 append のみで対応
-- **時刻パース logic 拡張**: 新 format は `More reviews will be available in N minutes and S seconds` (例: "26 minutes and 21 seconds")。旧 format `Please wait N minutes and S seconds before requesting another review` と異なる prefix のため、`rate_limit_event_time()` の reset 時刻計算ロジックを 2 variant 対応に refactor
-- **採用 marker source**: 現行 CR walkthrough HTML コメント `<!-- This is an auto-generated comment: rate limited by coderabbit.ai -->` を最も安定な検出 source とする (実観測: PR #182 で確認)
-- **fixture 追加**: `tests/` または `#[cfg(test)]` mod に新 format fixture (現実観測 body の minimum reproduction、4-6 lines) を 2-3 variant 追加 (順位 168 と pair で実装)
-
-#### 作業計画
-
-- [ ] `RATE_LIMIT_MARKER` を `RATE_LIMIT_MARKERS: &[&str]` に変更し、`is_rate_limit_comment()` を multi-variant check に refactor
-- [ ] `rate_limit_event_time()` / `parse_rate_limit()` を新旧両 format の時刻パースに対応 (regex or split-based parsing)
-- [ ] 既存 6 fixture (lines 1298-1370 周辺) はそのまま維持 (旧 format regression gate として継続)、新 format fixture を 2-3 件追加 (順位 168)
-- [ ] cargo test で pass 確認 + 意図的に新 marker を削除して test が落ちるか手動検証
-- [ ] markdownlint clean (test fixture の body 内 HTML エンティティ等が markdownlint で問題ないか確認)
-- [ ] 本エントリ削除 + todo-summary.md 行削除 (順位 168 / 169 と同 PR で land 推奨)
-
-#### 完了基準
-
-- `RATE_LIMIT_MARKERS` 配列化 + multi-variant check 実装
-- 旧 format + 新 format 両方で `parse_rate_limit()` が `RateLimitInfo` を正しく返す
-- `cli-pr-monitor` 実行時に新 format の CR rate-limit を `RateLimitOutcome::Parked` で検出
-- silent regression を test で 1 件以上検出できる構造 (= 単一 marker に戻すと test 失敗)
-
-#### 詰まっている箇所
-
-format パースの time prefix variant が複雑になる可能性あり (`Please wait N minutes` vs `More reviews will be available in N minutes`)。Effort M 想定だが parsing 戦略次第で実装難度が変動する。順位 168 と同時着手で fixture-driven 実装が現実的。
-
----
-
-### CR rate-limit detection integration test — 新旧両フォーマット対応 fixture 追加 (PR #182 T2-#1 採用) ★ Bundle CR-RL
-
-> **動機**: 順位 167 (`RATE_LIMIT_MARKER` 更新) と対になる regression gate。既存 6 fixture (lines 1298-1370) は全て旧フォーマット (`Rate limit exceeded`) のみで、CR の format 変更により無効化される構造的 silent regression リスクを抱えていた。新 format fixture を test に追加することで、将来 CR が format を変更しても test が早期検出する protective layer を確立する。
->
-> **本タスクの位置づけ**: PR #182 post-merge-feedback Tier 2 #1 採用 (Severity High / Frequency Medium / Effort S / Adoption Risk None、2026-05-29 ユーザー承認)。順位 167 と pair、同 PR での実装推奨。Bundle CR-RL (順位 167 + 本 entry + 順位 169) の test 層。
->
-> **参照**: `.claude/feedback-reports/182.md` Tier 2 #1、`src/check-ci-coderabbit/src/main.rs` の `#[cfg(test)]` モジュール (既存 fixture 配置先)、順位 167 設計決定との pair
->
-> **実行優先度**: 🔧 **Tier 2** — Effort S。順位 167 と同 PR で 1 day 程度を目安。
-
-#### 設計決定 (案)
-
-- **fixture variant**:
-  1. **新 format (HTML マーカー + Review limit reached)**: PR #182 で観測した実 body の minimum reproduction (`<!-- ... rate limited by coderabbit.ai -->` + `## Review limit reached` + 数 minutes and seconds + credit warning 部分)
-  2. **新 format (credit warning なし)**: rate-limit のみで credit 文言なし variant
-  3. **新 + 旧 format 共存**: 同一 PR 内に旧 marker comment と新 marker comment が混在する場合 (CR の format 移行期に発生しうる)
-- **memory `feedback_test_dry_antipattern`**: 各 variant 独立 setup、共通 helper 化しない (fixture body は format! ではなく直接記述)
-- **assert 観点**: `is_rate_limit_comment()` が新 format で true を返す + `parse_rate_limit()` が `RateLimitInfo` を返し reset 時刻 (unix epoch) が正しい
-
-#### 作業計画
-
-- [ ] `#[cfg(test)]` モジュールに新 format fixture 2-3 variant を追加 (順位 167 の marker 配列化と同 commit)
-- [ ] 既存 6 fixture (旧 format) を維持 = backward compat の regression gate
-- [ ] cargo test で pass 確認、意図的に時刻パース logic を旧 prefix のみに戻して新 fixture test が落ちるか手動検証
-- [ ] silent regression: marker 配列から HTML マーカーを削除 → 新 fixture test 失敗、を確認
-- [ ] 本エントリ削除 + todo-summary.md 行削除 (順位 167 / 169 と同 PR で land)
-
-#### 完了基準
-
-- 新 format fixture が test 配列に追加 (2-3 variant)
-- 既存 6 fixture が変更なく pass 継続 (regression なし)
-- 新 + 旧両方の `is_rate_limit_comment()` / `parse_rate_limit()` 経路が test で carry-through
-- silent regression を test で 1 件以上検出できる構造
-
-#### 詰まっている箇所
-
-なし。順位 167 の marker 配列化が完了すれば fixture 追加は機械的作業。
-
----
-
-### ADR-018 / ADR-034 に CR rate-limit format evolution と検出ロジック同期戦略を codify (PR #182 T3-#1 採用) ★ Bundle CR-RL
-
-> **動機**: 順位 167 で marker 配列化 + multi-variant 対応を実装するが、CR が今後さらに format を変更する場合に同じ silent regression パターンが再発する可能性が高い (CR は外部 SaaS で format は CR 側の都合で変わる)。永続 layer (ADR) に「既知 format 一覧 + 検出 logic 更新手順」を codify することで将来の maintainer が同じ trap に落ちない構造的予防策。
->
-> **本タスクの位置づけ**: PR #182 post-merge-feedback Tier 3 #1 採用 (Severity Medium / Frequency Medium / Effort XS / Adoption Risk None、2026-05-29 ユーザー承認)。順位 167 + 168 と同 commit での ADR 追記が analyzer 推奨。Bundle CR-RL の docs 層。
->
-> **参照**: `.claude/feedback-reports/182.md` Tier 3 #1、`docs/adr/adr-034-coderabbit-auto-monitoring.md` (line 64 で旧 marker 記述あり、第一候補)、`docs/adr/adr-018-pr-monitor-takt-migration.md` (lines 185-186 で `RateLimitOutcome::Parked` 設計、旧 marker 前提)、順位 167 / 168 の実装
-
-#### 設計決定 (案)
-
-ADR-034 (第一候補) に以下を追記:
-
-- **既知 CR rate-limit format 一覧** (実観測ベース、format 変更時に append):
-  1. 旧 format (〜2026 年初頃): `Rate limit exceeded\nPlease wait N minutes and S seconds before requesting another review`
-  2. 新 format (PR #182 で観測、2026-05-29 時点): `<!-- This is an auto-generated comment: rate limited by coderabbit.ai -->` (HTML マーカー) + `## Review limit reached` + `More reviews will be available in N minutes and S seconds`
-- **検出 logic 更新手順** (CR が format を変更した場合):
-  1. PR 観測 → marker drift で `is_rate_limit_comment()` が常時 false を返す symptom (= 30+ 分 polling 継続) を発見
-  2. `gh api issues/<PR>/comments` で walkthrough body を grep、新 marker を特定
-  3. `RATE_LIMIT_MARKERS` 配列に追加、`rate_limit_event_time()` の time prefix variant を追加
-  4. 新 format fixture を `#[cfg(test)]` に追加 (順位 168 と同 pattern)
-  5. ADR-034 § 既知 format 一覧に append
-- **HTML マーカー優先**: walkthrough comment の HTML マーカー (`<!-- ... rate limited by coderabbit.ai -->`) は heading 文言や本文より stable な可能性が高いため、検出優先順位を明示
-
-ADR-018 lines 185-186 については、旧 marker 記述を「順位 167 で multi-variant 対応済、詳細は ADR-034 を参照」に書き換える。
-
-#### 作業計画
-
-- [ ] `docs/adr/adr-034-coderabbit-auto-monitoring.md` の line 64 周辺に「既知 format 一覧」section を新設、旧 + 新 format を記載
-- [ ] 同 ADR に「検出 logic 更新手順」section を新設、6 step の標準手順を記述
-- [ ] `docs/adr/adr-018-pr-monitor-takt-migration.md` lines 185-186 の rate-limit 表 description を「順位 167 で multi-variant 対応、詳細は ADR-034 参照」に更新
-- [ ] markdownlint clean 確認
-- [ ] 本エントリ削除 + todo-summary.md 行削除 (順位 167 / 168 と同 PR で land)
-
-#### 完了基準
-
-- ADR-034 に既知 format 一覧 + 検出 logic 更新手順が codify される
-- ADR-018 lines 185-186 が現実の実装状態と整合 (multi-variant 参照)
-- 将来 CR format 変更時に reviewer / Claude が ADR から逆引き可能になる
-- markdownlint clean
-
-#### 詰まっている箇所
-
-なし。Effort XS、ADR の section 追記 + 既存表更新のみ。
-
----
-
 ### `git-workflow.md § Multi-PR chaining` を「1 PR 内 multi-commit + intent 明記」パターンに拡張 (PR #183 T3-#1 採用)
 
 > **動機**: PR #119/#120/#121 + 本 PR #183 で **4 回観測された** multi-commit single-PR bundling パターンを `~/.claude/rules/common/git-workflow.md` § Multi-PR chaining に codify する。現状の同 section は「複数 PR の分割」を扱うが、「1 PR 内で commit を分離する判断基準」「各 commit message での intent 明記の重要性」が未記載。reviewer (CodeRabbit / 人間) が PR diff を読む際、commit description 単位の intent が明確だと review 効率が向上する。Frequency High に到達したため Tier 3 codify 条件成立。