aloekun · Jul 7, 2026 · Jul 7, 2026
diff --git a/CLAUDE.md b/CLAUDE.md
@@ -51,6 +51,7 @@
 - [ADR-048: reviewers→fix findings handoff の output-contract 標準化（markdown 統一・JSON 却下）](docs/adr/adr-048-facet-findings-handoff-markdown-contract.md) *(試験運用)*
 - [ADR-049: incident→eval 回帰スイート（カスタムルールの由来 incident 再現テスト）](docs/adr/adr-049-incident-eval-regression-suite.md) *(試験運用)*
 - [ADR-050: multi-iteration workflow の decision criteria scope 明示](docs/adr/adr-050-iteration-aware-decision-criteria.md) *(試験運用)*
+- [ADR-051: クロスシステム設定 coupling パターン — 内部設定と外部 SaaS 設定の論理結合の設計規律](docs/adr/adr-051-cross-system-config-coupling.md) *(試験運用)*
 
 ## 開発 convention / チェックリスト
 

diff --git a/docs/adr/adr-019-coderabbit-review-hybrid-policy.md b/docs/adr/adr-019-coderabbit-review-hybrid-policy.md
@@ -153,7 +153,7 @@ WP-03 は 2026-04-19 で却下した「rate-limit 耐性 (超過後の auto-retr
 #### 既知の制約
 
 - **手動 fix push は手動トリガーが必要**: 明示トリガーは監視の auto-push 経路 (`auto_push_severity` = critical/major) のみ。ユーザー手動 push (severity=none / minor) 後は `@coderabbitai review` を手動投稿する (fail-open のログが誘導する)。
-- **設定の二重管理**: `.coderabbit.yaml` の `auto_incremental_review` と `pr-monitor-config.toml` の `trigger_review_after_push` は必ず揃える (前者 false ⇔ 後者 true)。揃わないと再レビュー欠落 (両 off) or 二重レビュー (両誤設定) になる。派生プロジェクトの template では default false + コメント例で明示。
+- **設定の二重管理**: `.coderabbit.yaml` の `auto_incremental_review` と `pr-monitor-config.toml` の `trigger_review_after_push` は必ず揃える (前者 false ⇔ 後者 true)。揃わないと再レビュー欠落 (両 off) or 二重レビュー (両誤設定) になる。派生プロジェクトの template では default false + コメント例で明示。この「内部設定 × 外部 SaaS server-side 設定」の論理結合は今後の SaaS 統合で繰り返される汎用パターンであり、設計規律 (相互参照コメント / 期待値組み合わせ表 / 両側同一 PR / ランタイム検証の限界) を [ADR-051](adr-051-cross-system-config-coupling.md) に汎化した。
 
 #### 再トリガー抑止ガード (2026-07-05 追記、WP-05 follow-up)
 

diff --git a/docs/adr/adr-051-cross-system-config-coupling.md b/docs/adr/adr-051-cross-system-config-coupling.md
@@ -0,0 +1,77 @@
+# ADR-051: クロスシステム設定 coupling パターン — 内部設定と外部 SaaS 設定の論理結合の設計規律
+
+## ステータス
+
+試験運用 (2026-07-06)
+
+> 本 ADR は [ADR-019](adr-019-coderabbit-review-hybrid-policy.md) で個別対処した「`.coderabbit.yaml` (外部 SaaS 側設定) × `pr-monitor-config.toml` (内部 CLI 設定) の論理結合」を一般化し、内部設定と外部 SaaS 設定が **論理的に coupled** しているときの設計規律を codify する。今後の外部 SaaS 統合 (LLM service / CI provider 等) で繰り返される汎用パターンを横展開する。順位263 (PR #243 post-merge-feedback T3-2 採用)。
+
+## コンテキスト
+
+### 問題
+
+2 つの設定が「片方だけを変更すると壊れる」論理結合を持つとき、その結合が **同一プロセス内で完結しない** (一方が外部 SaaS の server-side で読まれる) と、ランタイムでの整合性検証が原理的に不可能になる。整合を保つ手段は文書化・規律に依存するため、結合の存在自体を明示しないと片側だけの変更で silent breakage が起きる。
+
+### 代表例 (ADR-019 § WP-03)
+
+| 設定 | 所在 | 読取主体 |
+|---|---|---|
+| `.coderabbit.yaml` の `reviews.auto_review.auto_incremental_review` | リポジトリ (外部 SaaS 側設定) | **CodeRabbit が server-side で読む** |
+| `pr-monitor-config.toml` の `[fix] trigger_review_after_push` | リポジトリ (内部 CLI 設定) | `cli-pr-monitor` がローカルで読む |
+
+この 2 つは論理的に結合しており、期待される組み合わせは 1 通りのみ:
+
+| `auto_incremental_review` | `trigger_review_after_push` | 挙動 |
+|---|---|---|
+| `false` | `true` | ✅ 正常 (fix 束ねごとに 1 回明示レビュー) |
+| `true` | `true` | ❌ 二重レビュー (自動増分 + 明示) |
+| `false` | `false` | ❌ 再レビュー欠落 (fix push が誰にもレビューされない) |
+| `true` | `false` | (従来の自動増分のみ、WP-03 前の挙動) |
+
+片側だけを変更すると再レビュー欠落 or 二重投稿 (= レート枠の浪費) を招く。CodeRabbit は `.coderabbit.yaml` を server-side で読むため、`cli-pr-monitor` から「外部側が今どういう設定か」をランタイムで照会・検証することはできない。
+
+## 決定
+
+内部設定と外部 SaaS 設定が論理結合するときは、以下 3 点を設計規律とする。
+
+### 1. 結合の存在を両設定ファイルに相互参照コメントで明示する
+
+結合する双方の設定ファイルに、**相手ファイル名・相手キー名・期待される連動関係** をコメントで記載する。片側だけ見て変更する事故を、編集者が結合に気付ける形で構造的に防ぐ。
+
+```yaml
+# .coderabbit.yaml (例)
+# NOTE: auto_incremental_review は pr-monitor-config.toml [fix] trigger_review_after_push と
+#       連動する (前者 false ⇔ 後者 true)。片側だけ変えると再レビュー欠落 or 二重投稿。詳細 ADR-051 / ADR-019。
+```
+
+### 2. 期待値の組み合わせ表を ADR に必須記載する
+
+結合する設定値の **全組み合わせと各挙動 (正常 / 異常の別と理由)** を表として ADR に残す。「どの組み合わせが正しいか」を一次情報として固定し、後続セッション・派生プロジェクトが再構築できるようにする (上記 ADR-019 の組み合わせ表が範例)。
+
+### 3. 変更は両側を同一 PR で扱う
+
+結合する設定の変更は、**両ファイルを 1 つの PR** に含める。片側だけの PR を作らない。派生プロジェクト向け template では、危険な既定 (両 off = 再レビュー欠落) を避けるため安全側の既定値 + コメント例を置く。
+
+### ランタイム cross-validation の限界 (明示)
+
+一方が外部 SaaS の server-side で読まれる設定 (`.coderabbit.yaml` 等) の場合、内部プロセスから外部側の実効値を照会・検証することは**原理的に不可能**である。したがって整合性の担保は「実行時チェック」ではなく **上記 1〜3 の文書化・規律** が中心になる。この限界を ADR に明記し、「なぜ lint / gate で機械強制しないのか」を将来の設計者が誤解しないようにする (両側が内部設定なら機械 cross-validation を検討する余地はある)。
+
+## 影響
+
+### 適用対象 (今後の外部 SaaS 統合)
+
+- LLM service (Ollama endpoint 設定 × classifier config 等)
+- CI/CD provider (workflow YAML × 内部 pipeline config)
+- その他、外部 server-side 設定と内部 CLI/hook 設定が連動するケース全般
+
+### 避けるべきアンチパターン
+
+- **結合を暗黙のままにする**: コメント・ADR 表なしで 2 設定を連動させると、片側変更で silent breakage。
+- **外部 server-side 設定にランタイム検証を期待する**: 照会不能なため実装できない。文書化に倒す。
+- **片側だけの PR**: レビュー時点で結合相手が見えず、整合性チェックが機能しない。
+
+## 参照
+
+- [ADR-019: CodeRabbit レビュー運用のハイブリッド構成](adr-019-coderabbit-review-hybrid-policy.md) § WP-03 (代表例・組み合わせ表の下敷き) / § 再トリガー抑止ガード
+- [ADR-022: 自動化コンポーネントの責務分離原則](adr-022-automation-responsibility-separation.md) — 設定所在の責務境界
+- [ADR-039: Experimental feature 標準パターン](adr-039-experimental-feature-standard-pattern.md) — 本 ADR の試験運用 (2 例目の cross-system coupling 出現で汎化の妥当性を確認)
diff --git a/docs/todo-summary.md b/docs/todo-summary.md
@@ -123,7 +123,6 @@
 | 255 | 💎 Tier 3 | **ADR-040 の実測値を新 GPU (RTX PRO 5000 48GB) で再 calibration (ADR-046 WP-01 スパイクで陳腐化を観測)** | todo13.md | S | なし (ADR-038/040 が前提とする RTX 3070 8GB は RTX PRO 5000 Blackwell 48GB に更新済み。27-31B Q4 モデルが 100% GPU で動き VRAM が制約でなくなったため、ADR-040 の VRAM/latency trade-off 表と「VRAM scarcity → model swap 制約」framing が陳腐化。ADR-046 で mistral:7b / gemma4 / qwen3-coder の VRAM・latency を実測済 → ADR-040 amendment に反映、num_ctx 選定 flow の memory 軸を latency 軸へ再重み付け) |
 | 256 | ⏳ Tier 5 | **classifier FP 検出強化プロンプトで格上げ候補を再評価 (WP-04 見送りの follow-up、ADR-038 amendment 由来)** | todo13.md | M | なし (WP-04 実測で全候補が FP 検出未達 = 能力限界か `classify.txt` の mistral 向け tune 不適合かが未分離。FP 検出強化プロンプト版で qwen3-coder:30b 等を再測し、能力限界と確認できれば恒久見送り、プロンプト不適合なら該当モデル + 専用プロンプトで格上げ。eval 手法・gold セットは scratchpad WP-04 資産を再利用。materially better な新モデル出現時も再評価トリガー) |
 | 257 | ⏳ Tier 5 | **push pipeline の `cargo test` を cargo-nextest 化 (WP-05 で Stop hook には無効と判明、push 側 follow-up)** | todo13.md | S-M | なし (WP-05 実測: Stop hook は cargo test 不在で nextest 非適用、真因は逐次実行→並列化で解決済。ただし push pipeline (cli-push-runner quality_gate) の `cargo test -- --ignored` は実測 ~80s で nextest 高速化の余地あり。ツール依存追加 = ADR-017 pinning + 派生プロジェクト配布のコスト、push が Stop より低頻度な点を踏まえた費用対効果を評価。doctest は nextest 非実行のため `cargo test --doc` 併走が必要) |
-| 263 | 💎 Tier 3 | **クロスシステム設定 coupling パターンの汎化 ADR 起票 (PR #243 post-merge-feedback T3-2 採用)** | todo13.md | M | なし (.coderabbit.yaml (外部 SaaS 側、server-side 読取) × pr-monitor-config.toml [fix] trigger_review_after_push (内部 CLI) の論理 coupling は片側変更で re-review 欠落 / 二重投稿を招く構造。ランタイム cross-validation は原理的に不可 = 文書化 + 期待値組み合わせ表 + 両側同 PR 変更原則が mitigation の中心。ADR-019 の CodeRabbit 固有記述を汎化、ADR-NNN placeholder 方式 (report 原文の ADR-046 は WP-01 却下で使用済みのため不使用)) |
 
 **戦略**: Tier 1 を 2〜3 セッションで片付け → Tier 2 で ADR-032 の前提 + rate-limit + convergence cost 削減を進める → Tier 3 で ADR-032 を land + ドキュメント整備。Tier 4-5 は cleanup / 外部展開で daily efficiency への直接効果は小さい。
 

diff --git a/docs/todo13.md b/docs/todo13.md
@@ -772,31 +772,6 @@
 
 ---
 
-### クロスシステム設定 coupling パターンの汎化 ADR 起票 (PR #243 post-merge-feedback T3-2 採用)
-
-> **動機**: `.coderabbit.yaml` (外部 SaaS 側設定、CodeRabbit が server-side で読む) と `pr-monitor-config.toml` の `[fix] trigger_review_after_push` (内部 CLI 設定) は論理的に coupled しており、**片方だけを変更すると re-review 欠落または二重投稿が発生する**構造になっている。SaaS 側が YAML を server-side で読むため、ランタイムでの cross-validation は原理的に不可能 = 文書化・期待値組み合わせ表・変更手順の規律が mitigation の中心になる。ADR-019 には CodeRabbit 固有の組み合わせ表が記録済みだが、この構造は今後の外部 SaaS 統合 (LLM service、CI provider 等) で繰り返される汎用パターンのため、汎化 ADR として横展開する。
->
-> **参照**: ADR-019 (CodeRabbit 固有事例と期待値組み合わせ表)、ADR-022 (責務分離)、ADR-039 (experimental feature 標準パターン)。ADR 採番は placeholder 方式 (「ADR-NNN、land 時に確定」)。**注意: post-merge report 原文は ADR-046 を提案していたが、ADR-046 は WP-01 却下記録で使用済みのため使わない**。
->
-> **実行優先度**: 💎 Tier 3 — Effort M。新規 ADR 1 本のため docs bundle とは別 PR 可。
-
-#### 作業計画
-
-- [ ] ADR-NNN「クロスシステム設定 coupling パターン」を起票: ① coupling の定義と実例 (ADR-019 の `.coderabbit.yaml` × `pr-monitor-config.toml` を代表例として参照)、② 設計ガイドライン (両設定ファイルに相互参照コメントを置く / 期待値の組み合わせ表を ADR に必須記載 / 変更時は両側を同一 PR で扱う原則)、③ ランタイム cross-validation の限界 (SaaS server-side 読取) の明記
-- [ ] ADR-019 から新 ADR へ cross-reference を追加
-- [ ] CLAUDE.md の ADR index に追記
-- [ ] 本 entry 削除 + todo-summary.md 行削除
-
-#### 完了基準
-
-- 汎化 ADR が land し、次回の外部 SaaS 統合設計時に参照できる状態になっていること。
-
-#### 詰まっている箇所
-
-- なし (ADR-019 に事例・組み合わせ表の下敷きあり)。
-
----
-
 ## 既知課題 (記録のみ、本セッションで未対応)
 
 (現時点で本ファイルへの既知課題は無し。docs/todo10.md / todo9.md 末尾を参照。)