19. Edge Block (補助モジュール)

TL;DR（このノードは何をする・専門語ゼロ）: 生成された ADR の本文先頭に、ADR 同士の関係 (supersedes / depends_on など 7 種類) を書く YAML ブロックを必ず置くための補助モジュール。空のままでも構わないが、ブロック自体が無いと CI が落ちる。本文に既に書いてあれば何もせず、無ければ全部空配列の雛形を前置する。事業軸 (business) を起案時に指定していれば、その 1 行も先頭へ挿入する。AI は使わず、正規表現で frontmatter を見るだけの単純な処理。

実装: drp/src/nodes/edge_block.ts 呼び出し元: drp/src/nodes/body_generation.ts (ensureEdgeBlock で生成直後に前置) / drp/src/nodes/webhook.ts (insertBusinessLine で PR 起票直前に business 行を挿入) プロンプト: なし (LLM 呼出なし) テスト: drp/test/edge_block.test.ts 基盤 ADR: ADR-0131 (新規 ADR の辺フィールド 7 種必須化) / ADR-0133 (辺の意味監査)

1. 役割と位置づけ

パイプライン生成本文に ADR 同士の型付き辺 frontmatter (7 種) が無いと、adr-lint --check-edges-new が error になり生成 PR が CI green にならない (PR #1722 検収差し戻し)。本モジュールは生成直後に決定的に前置し、CI gate を確実に通す。

• 解決する課題: LLM 任せでは frontmatter の有無や 7 キー網羅が安定せず、生成 PR が CI で落ちる。LLM を介さず純コードで前置することで確実性を担保する。
• 設計思想: graph には独立ノードとして addNode されない補助モジュール。body_generation.ts の本文生成直後に ensureEdgeBlock を呼び、webhook.ts の PR 起票直前に insertBusinessLine を呼ぶ 2 段構成。雛形は全空配列 ([]) で十分。辺の意味は人間レビュー / ADR-0133 の意味監査で補正可能、という sub 検収の指針に従う。
• 由来: ADR-0131 (#1703) で新規 ADR の辺 frontmatter 7 種が必須化された。

2. フロー図

flowchart LR
    BG[body_generation] -->|生成直後| EE[ensureEdgeBlock]
    EE -->|前置済 adrBody| BG
    BG --> SC[scoring]
    WH[webhook] -->|起票直前| IB[insertBusinessLine]
    IB -->|business 行挿入済 adrBody| WH

3. トリガー条件

graph の独立ノードではないため graph 上の edge 条件はない。以下 2 つの呼び出し点で発火:

4. 入力 (引数)

ensureEdgeBlock:

insertBusinessLine:

5. 処理ロジック

1. ensureEdgeBlock(adrBody):
   a. /^---\n([\s\S]*?)\n---\n?/ で frontmatter を抽出
   b. frontmatter なし → SKELETON (7 キー全空配列 + コメント) を前置、added=全 7 キー
   c. frontmatter あり → EDGE_KEYS のうち欠落分だけを補完、added=補完したキーのみ
   d. すべて揃っていれば adrBody 不変、added=[]

2. insertBusinessLine(adrBody, business):
   a. frontmatter 抽出
   b. frontmatter なし or business 行が既にある → 何もしない (冪等)
   c. frontmatter 先頭に `business: <value>  # 事業軸 ...` を 1 行挿入

EDGE_KEYS (7 種):

• supersedes / amends / refines / depends_on / relates_to / conflicts_with / follows_up_on

最終 frontmatter 順序 (CI autofix と整合): trio (id / type / status) → メタ → business → 辺ブロック。CI autofix (scripts/pipeline-adr-autofix.mjs) のトリオ+メタ複製は frontmatter 先頭へ挿入するため、business は trio+メタの直後・辺ブロックの直前に入る。

6. LLM 設定

LLM 不要 (コード合成のみ)。正規表現で frontmatter を抽出し、欠落キーを補完するだけ。冪等性は両関数とも保証。

7. 副作用

なし。本文文字列を返すのみ。

8. 出力

ensureEdgeBlock:

{
  body: string,       // 雛形前置 / 補完済の本文 (変更なしなら入力と同一)
  added: string[],    // 追記したキー (変更なしは空配列)
}

insertBusinessLine:

string  // business 行挿入済の本文 (frontmatter なし / business 既存なら入力と同一)

9. 分岐 (次の処理)

graph の独立ノードではないため graph edge を持たない。

• body_generation は ensureEdgeBlock の body を adrBody に上書きして scoring へ進む
• webhook は insertBusinessLine の戻り値で adrBody を上書きして PR を起票する

10. エラー時の挙動

エラー無し (deterministic)。

• frontmatter なし → SKELETON を前置 (例外なし)
• 全キー揃い → 入力をそのまま返す
• business 既存 → 何もしない (冪等)
• 正規表現マッチが入れ子になることはない (^---\n を行頭固定マッチ)

11. 既知の弱点・運用注意

• 雛形は全空配列: 辺の型 (どの ADR を supersede するか等) は人間レビューで補正する前提。LLM に推論させる選択肢もあるが、誤った辺は混乱の元のため空配列の雛形で gate を通すのが sub 検収の指針。
• EDGE_KEYS 変更時の追従: 配列を増減させると CI 側 --check-edges-new の検査キーも追従が必要 (adr-lint 側で SSoT 共有していない場合)。
• 業務軸 (business) の正規語彙: webhook 側 routing の正規語彙 (corp / mas / drp 等) に依存。CI 側の nav 登録グループ既定マップ (corp→09.5 / mas→09.3 / drp→09.4) と同期している必要がある。
• 冪等性: insertBusinessLine は business 行が既にあれば何もしない。401 途中再開でも二重挿入しない設計。
• frontmatter なし時の前置: 本文先頭の空白 (\s+) を除去してから前置するため、生成 LLM が改行を入れすぎても無害化される。

12. テストケース

drp/test/edge_block.test.ts (vitest):

13. 過去の設計判断ログ

14. 関連リンク

• 呼び出し元: 03_body_generation.md / 11_webhook.md
• 関連 ADR:
  • ADR-0131 — 辺フィールド 7 種必須化
  • ADR-0133 — 辺の意味監査
• CI gate: adr-lint --check-edges-new
• CI autofix: scripts/pipeline-adr-autofix.mjs