aloekun · aloekun · May 5, 2026 · May 4, 2026 · coderabbitai · May 5, 2026
diff --git a/docs/adr/adr-030-deterministic-post-merge-feedback.md b/docs/adr/adr-030-deterministic-post-merge-feedback.md
@@ -120,6 +120,32 @@ skill ベースで運用していた analyze-pr / post-merge-feedback Phase 4
 
 両方とも repository には含めない (`.gitignore` で除外、内部 artifact)。
 
+### Global rules editing の追跡
+
+global rules (`~/.claude/rules/`、`~/.claude/CLAUDE.md`、`~/.claude/skills/` など、ユーザーホーム配下の `.claude/` 配下) の編集は **project repository VCS の管理外** であり、`jj diff` や PR diff には出現しない。しかし post-merge-feedback の analysis は **transcript 経由でこれらの編集も全件捕捉する**。
+
+| 編集対象 | VCS への現れ | post-merge-feedback での visibility |
+|---|---|---|
+| project files (`docs/`, `src/`, `.claude/hooks-config.toml` 等) | `jj diff` / PR diff に出現 | `analyze-pr` (PR data) と `analyze-session` (transcript) の双方で見える |
+| global rules (`~/.claude/rules/**`, `~/.claude/CLAUDE.md`, `~/.claude/skills/**`) | **VCS に出現しない** | `analyze-session` (transcript) のみで見える |
+
+仕組み: Claude Code session transcript には全 Edit / Write 操作が記録される (`tool_use_input` field に file path と new content)。`cli-merge-pipeline` が transcript filter で当該 PR の merge 時刻 range で抽出するため、PR スコープの global rules 編集も merge 後の analysis 対象に含まれる ([transcript 抽出戦略](#transcript-%E6%8A%BD%E5%87%BA%E6%88%A6%E7%95%A5-phase-0-%E8%AA%BF%E6%9F%BB%E7%B5%90%E6%9E%9C%E5%8F%8D%E6%98%A0) 参照)。
+
+結論: **global rules の透明性は VCS ではなく post-merge-feedback workflow が担保する**。pre-merge レビュー (pre-push-review / CodeRabbit) では global rules 編集は見えないが、post-merge レビュー (post-merge-feedback) では完全に visible。
+
+#### 実証
+
+PR #111 (Bundle e、2026-05-04 merged) は `~/.claude/rules/common/{coding-style,git-workflow,development-workflow,code-review}.md` + `~/.claude/CLAUDE.md` の **5 ファイル** を編集したが、project diff は 0 行。にもかかわらず post-merge-feedback report (`.claude/feedback-reports/111.md`) には全 5 ファイルの編集内容が反映され、10 件の findings (うち 4 件採用) が抽出された。
+
+#### Pre-merge 補完層の必要性
+
+global rules 編集の pre-merge 検証は本 ADR の scope 外だが、補完層として:
+
+- [coding-style.md § Codification claims の検証手順](file:///~/.claude/rules/common/coding-style.md) — claim と実体の事前同期
+- [docs-governance.md § Cross-File Reference Lifecycle](file:///~/.claude/rules/common/docs-governance.md) — permanent ↔ ephemeral 参照の正しさ
+
+これらが pre-merge の人間/AI レビューで先回り防止し、post-merge-feedback が事後検証する二段構え。
+
 ### transcript 抽出戦略 (Phase 0 調査結果反映)
 
 ```text

diff --git a/docs/adr/adr-033-todo-numbering-simplification.md b/docs/adr/adr-033-todo-numbering-simplification.md
@@ -115,6 +115,59 @@ grep -nE "順位 [0-9A-Za-z_-]+" docs/todo.md docs/todo2.md docs/todo3.md \
 # ADR の本文中で「絶対番号を示唆する placeholder を本文に書かない」方針を機械検証する。
 ```
 
+## priority table 運用ルール (PR #111 post-merge-feedback で追加)
+
+本 ADR 採用後の運用で発見された 2 件の暗黙的設計を明文化する。
+
+### 「依存」列の二層追跡 — technical 依存 vs strategic 順序
+
+priority table の「依存」列 と、領域特化計画書 (例: `docs/coderabbit-monitoring-efficiency.md`) や Bundle 脚注に記録する依存関係は、**別レイヤ** を表す。両者が乖離していても矛盾ではない。
+
+| 種別 | 記録先 | 意味 | 例 |
+|---|---|---|---|
+| **technical 依存** | priority table の「依存」列 | そのタスクが land する前に **technically blocking** な前提タスク。前提が land しないと本タスクが破綻する | `順位 20 ADR-032 PR-β` の依存 = `6, 8, 10` (前提 PR がないと実装不可) |
+| **strategic 順序** | 領域特化計画書 / Bundle 脚注 | technical 依存はないが **bundle 化推奨 / 効率的な land 順** という soft な指示。違反しても破綻はしないが iteration コストが上がる | 順位 10 broken-link-check は table 上「依存なし」だが、計画書では「ADR-032 全体 (6/20/21) と bundle 化推奨」 |
+
+両者は **読み手が別** で読まれる:
+
+- priority table の「依存」列は **着手判断** に使う (依存が解けたか?)
+- 領域特化計画書は **bundle 化判断** に使う (この task だけ単独 land して efficient か?)
+
+priority table 単独で見て「依存なし」だからといって即着手できるわけではない場合がある。**領域特化計画書 (もし存在すれば) を併読して strategic 順序を確認する** のがレビュー手順。
+
+### Bundle 分割時の land 期限明記ルール
+
+Bundle を Sub-PR に分割する際 (例: Bundle d → d-1 / d-2、Bundle a → Sub-PR 1 / 2)、**残り片方の land 期限を明示する**。期限なしで分割すると、片方が long-tail に滞留しても priority table から検知しにくい。
+
+#### 期限フォーマット
+
+Bundle 脚注 / strategy テキスト内で以下のいずれかで記述する:
+
+- 具体日付: `(land 期限: 2026-05-15)`
+- 関連 PR: `(land 期限: 次 docs PR で集約)` / `(land 期限: 次セッション)`
+- 戦略保留: `(保留: <理由>)` — 期限を設けない場合は理由を明示
+
+#### 期限超過時の運用
+
+期限を過ぎても land しない残存タスクは、Bundle 名から派生命名に変えて再可視化する:
+
+- `Bundle d` (順位 70 が land、68/69 残) → 期限超過したら `Bundle d-followup` に rename
+- 「Bundle 分割の名残」ではなく「独立した task 群」として priority table 内で見える状態にする
+
+これにより priority table 脚注を見るだけで「どの Bundle が滞留中か」が把握できる。
+
+#### 保留 Bundle のケース
+
+戦略的に保留する場合 (例: 上流依存待ち、外部条件待ち) は、Bundle 脚注で保留理由を明示する。期限を設けないが「なぜ保留か」を残すことで、後日読み返した時の判断材料が消えない。
+
+#### 由来
+
+- Bundle U (順位 29 = PR #110、順位 30 = Bundle e で land) は分割消化に約 1 週間
+- Bundle V (順位 31/32 = PR #109、順位 33 = Bundle e で land) は 2 件先行 land + 1 件後追いで運用上問題なし
+- Bundle d (順位 70 = Bundle e で land、順位 68/69 残) は intermediate state を経由
+
+これら過去 split は事後的にトレース可能だが、新規分割時には「期限を書く」を default ルールとすることで滞留を可視化する。
+
 ## アンチパターン
 
 ### 「table 内まで採番除去」してはならない

diff --git a/docs/coderabbit-monitoring-efficiency.md b/docs/coderabbit-monitoring-efficiency.md
@@ -114,7 +114,7 @@
 ## 関連ドキュメント
 
 - [docs/todo.md](todo.md) — 推奨実行順序サマリ表 (priority table)
-- [docs/docs-pr-iteration-efficiency.md](docs-pr-iteration-efficiency.md) — 並列の docs PR iteration 領域
+- [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)

diff --git a/docs/docs-pr-iteration-efficiency.md b/docs/docs-pr-iteration-efficiency.md
diff --git a/docs/todo.md b/docs/todo.md
@@ -62,7 +62,6 @@
 | 57 | 🔧 Tier 2 | **Aggregation cap integration test (PR #105 T2-1 採用)** | todo5.md | S | なし (`collect_all_violations` の MAX_VIOLATIONS contract を test 化、将来の lint 追加時に `truncate(MAX)` 削除 regression を防止する explicit 安全網) |
 | 60 | 💎 Tier 3 | **analyze-session の transcript filter 絞り込み (旧 #A-3)** | todo5.md | M | なし (旧 docs/pipeline-token-efficiency.md #A-3、ADR-036/037 化に伴い計画書削除、本 task のみ todo に移管。analyze-session の input range を PR 作成 commit〜merge に限定して input token 30-50% 削減見込み、dogfood で実測必要) |
 | 61 | 🔧 Tier 2 | **post-PR 検証フローに CR review.body 手動スキャン step 追加 (PR #108 T2-1 採用)** | todo5.md | XS | なし (PR #108 で analyze-coderabbit が review body の outside diff range comment を検出漏れし line 371/378 の修正が後追い、blind spot の暫定緩和策として手動 checklist を整備) |
-| 62 | 💎 Tier 3 | **Document Governance: docs lifecycle 区分明文化 (PR #108 T3-1 採用)** | todo5.md | XS | なし (PR #108 dogfood で本セッションが暗黙的に運用した docs/todo*.md = ephemeral / ADR / docs/ = permanent の区分を `~/.claude/rules/common/` に codify、ephemeral artifact 参照禁止 + retirement 2-step workflow を明文化) |
 | 63 | 🚀 Tier 1 | **cli-merge-pipeline に Drop guard / signal handler 追加 (PR #109 T1-1 採用) ★ Bundle c** | todo5.md | M | なし (PR #109 SIGPIPE 事故で ADR-030「失敗マーカーによる recovery」仕様の構造的違反が実証、Pre-emptive marker + signal trap で abrupt 経路を多層防御) |
 | 64 | 🚀 Tier 1 | **orphan run reaper (`meta.json status=running` 5-15 分放置検出 + 自動再起動) (PR #109 T1-2 採用) ★ Bundle c** | todo5.md | M | なし (順位 63 で救済不可の致命系 = kill -9 / SIGKILL / power loss / OOM の backstop、SessionStart hook または cli-pr-monitor 経路で実装) |
 | 65 | 🚀 Tier 1 | **exe + `--help` を PreToolUse でブロックして src/ Read に誘導 (PR #109 T1-3 採用) ★ Bundle c** | todo5.md | S | なし (PR #109 SIGPIPE の直接トリガ = AI が `cli-merge-pipeline.exe --help` 実行 → exe は --help 未対応で merge 本体実行を構造的に防止、今後追加 exe にも自動適用) |
@@ -97,6 +96,8 @@
 
 **Bundle d (PR #110 post-merge-feedback、2026-05-04)**: PR #110 (Bundle "docs quality pre-write") merge 後の post-merge-feedback で 6 findings 中 3 件採用。共通テーマは「PR #110 で導入した `no-ephemeral-todo-reference` rule (順位 29 採用分) の robustness 強化 + 設計 doc / 実装の乖離 ガード」。**順位 68 (T2 self-exclusion test)** は placeholder N 戦略の機械的保護で OBS-3 (fragile naming convention) 対策、**順位 69 (T3 yaml/yml コメント)** は OBS-2 (spec-impl 乖離) 対策。順位 70 (code-review checklist) は Bundle e で land 済。残り順位 68 (test infra) と 順位 69 (config コメント) は scope 異なるため独立 PR 推奨。
 
+**Bundle f + retirement (PR #111 post-merge-feedback + 計画書 retire、2026-05-05)** ✅ 完了: PR #111 (Bundle e) merge 後の post-merge-feedback で 10 findings 中 4 件採用 (順位 71/72/73/74 = Tier 3 XS×4) + 順位 62 (Document Governance) + `docs/docs-pr-iteration-efficiency.md` retirement を **1 PR で集約 land**。Sub-PR 分割推奨ルール (順位 73 自身が codify する内容) を本 PR で **dogfood**: 順位 73 が land する PR 自身が「分割 vs 統合」判断対象 → ファイル削除 + 順位 62 + Bundle f を統合した結果、scope は 5 ファイル touch (global rules 2 + ADR 2 + 削除 1) + cleanup で clean、Bundle 分割で得られる review 容易性より統合 PR の atomic な lifecycle 完結性が勝った。共通テーマ: 「PR #111 自己違反事例 → self-application 強化」 + 「Document Governance を global rule に codify」 + 「計画書 retirement を実例化」の 3 layer 同時 land。
+
 ---
 
 ## 現在進行中