最終更新: 2026/06/22 18:56
commonid: adr-accepted-curationtype: how-tostatus: active
pageaudience: both

ADR Accepted 化 (Pipeline マージ後キュレーション PR) 運用ガイド

Status: SSoT (2026-05-30 制定、ADR-0088 PR-F 実装中に「Status 自動更新 webhook 不発」誤認を解消する目的で起案) 対象: doc workspace (キュレーション PR の起案者) と main workspace (Pipeline 実装担当)

1. なぜこのガイドが必要か

Decision Pipeline が生成する ADR PR (例 #1135 / #1143 / #1148) は Status: Proposed 固定 で merge される。マージ後の Status 更新は 自動化されていない (webhook.ts の webhookNode は PR 作成のみ担当)。

過去に「Status 自動更新 webhook が不発」と handover で表現されたケースが複数あるが、これは 誤認: そもそも webhook は実装されていない。手動キュレーションが正規プロセスである。本ガイドはその正規プロセスを明文化する。

1.1 なぜ自動化しないか (デザイン判断)

Accepted 化 PR には Status 更新以上の本質的価値が含まれる:

  1. §11 Pipeline 審査履歴の追記: Gate0-4 の各結果・採点表・Cross-Validation 判定の全文を ADR 本文に記録 (audit trail)
  2. Status 遷移ログ: 採点時の改善余地 (低評価項目) を本文上で訂正した内容を Status 遷移節に記載
  3. 連動 doc 更新: operator_guide 改修・handover 起案・nav 登録など、ADR の決定を反映する周辺ドキュメント

→ Status 1 行だけ自動化しても §11 audit trail (人間判断 + Pipeline 実行結果データ統合) は出せない。中途半端な webhook より、「Pipeline 実行結果がメモリに残っているうちに doc が 1 つのまとまった PR で全部やる」 ほうが結果的に堅牢。

2. タイミング

ADR PR が main に merge された 当日中 (推奨)。

  • 遅延すると Pipeline 実行ログから §11 用データを再構築するコストが上がる
  • Implementation Status を Pipeline 等で参照する後続処理 (cross-ADR consistency 等) は Proposed 状態のままだと判定が不正確になる

3. キュレーション PR の構造 (ADR-0088 #1145 例)

3.1 ブランチ・タイトル

  • ブランチ: docs/adr-NNNN-status-update または docs/ADR-NNNN_accepted (doc 既存パターンに合わせる)
  • PR タイトル: docs(ADR-NNNN): Accepted化 + §11審査履歴 + <連動 doc 名>

3.2 必須変更

  1. メタデータブロックの Status 更新:
    - **Status**: Proposed
+ **Status**: Accepted
  2. 承認日時 (JST) 追記 (PR mergedAt UTC + 9h):
    - **承認日時 (JST)**: -
+ **承認日時 (JST)**: YYYY-MM-DD HH:MM (Pipeline 通常 flow <Mode> XX/50 通過 + Cross-Validation <verdict>、PR #NNNN マージ)
  3. ## 11. 参照: Pipeline 審査履歴 セクションを末尾に追加 (<details> で折りたたみ):
    • Gate 0-4 各結果サマリ
    • Gate4 採点項目 10 件 × 各点数の表
    • Status 遷移節 (採点時の改善余地と本 PR での反映内容)
    • 過去の Accepted 化 PR (#937 / #953 / #982 / #1139 / #1145 など) の §11 を雛形として参照

3.3 連動 doc 更新 (該当時のみ)

  • ADR の決定が「Pipeline ノード追加」「テンプレ拡張」「prompt 変更」を含む場合は同 PR で実装側 doc も更新 (例 ADR-0088 → operator_guide §4.1 コスト試算必須化)
  • 同 PR に main 向け実装 handover prompt (tasks/prompts/main_YYYY-MM-DD_*.md) を同梱することも多い

4. 連動 doc を含むキュレーション PR の責務境界

変更対象担当
docs/adr/NNNN-*.md 本文 (Status / 承認日時 / §11)doc
docs/_internal/05_how-to/operator_guide_*.md 等の連動 docdoc
実装 handover prompt (tasks/prompts/main_*.md)doc が起案、main が消費
実装本体 (drp/src/、scripts/、prompts/)main (doc の handover に従う)

詳細は workspace_rules.md のファイルマトリクス参照。

5. main 担当への影響

main 側は docs/adr/ を編集しないのが原則だが、Implementation Status は実装 PR で main 側が更新可 (例: 実装 PR が ADR-NNNN の Implementation Status を Done (PR #MMMM) に書き換える)。

  • ✅ main が触ってよい: ADR の Implementation Status: 1 行のみ
  • ❌ main が触ってはいけない: Status / 承認日時 / §11 セクション / 本文の論旨 (これらは doc のキュレーション PR で扱う)

6. 検証

キュレーション PR の本 ADR 単体に対する adr-lint が PASS することを確認する:

node scripts/adr-lint.mjs docs/adr/NNNN-*.md

リポ全体の adr-lint 結果は既存債務 (ADR-0078〜0090 の scope-meta / confirmation-section 等) で赤のままでも、当該 ADR が単体 PASS していれば merge 可。

7. 将来の自動化検討余地

§11 audit trail を Pipeline 実行ログから自動生成する選択肢はあり得る (Pipeline が DO に書き込んでいる gateProgress / gate_timings / scoringDetail 等を集計)。ただしその場合も:

  • Status / 承認日時 / 連動 doc 更新は引き続き手動キュレーションが必要
  • 自動生成された §11 を人間がレビューして PR に取り込む半自動運用が現実的

優先度は高くない (現状の手動運用が十分機能している)。実装する場合は別 ADR で検討する。

8. 参照

  • ADR-0088 PR-F (本ガイドの起案 PR): キュレーション PR の運用を初めて明文化した PR
  • 雛形にできる過去のキュレーション PR: #937, #953, #982, #1139, #1145
  • workspace_rules.md: main / doc のファイル境界
  • handover_prompt_guide.md: キュレーション PR と同梱されることが多い main 向け handover の書式