DRP プロンプト仕様書（ゲート別 I/O 契約）

役割: 各ゲートのプロンプト I/O 契約（EDD-003）の正典 — 入力変数・出力 JSON スキーマ・SSoT 経路（git ファイル → KV → inline fallback）。プロンプト本文の SSoT はリポルート prompts/production/<gate-id>/prompt.md（ADR-0042 Type 1 管理）であり、本書はその契約面だけを定義する（本文の転載はしない。test-tc*.mjs 内の転写コピーは陳腐化しているため引用禁止）。 整合検証: 本書の契約表 ↔ src/nodes/*.ts の使用プロンプト一致チェックは CI 化予定（main 分担・ADR-0117 §Confirmation の内容整合指標②）。機械可読スキーマは各 prompts/production/<gate-id>/output_schema.json が持ち、本書 §3 の表と突合する。 設計背景: prompts/01〜05_*.md（配置は README §9.1）は人間可読の設計ドキュメント（Type 3）。プロンプト更新時は production / 設計 doc / 本書を同一 PR で更新する。運用手順は prompt_lifecycle_guide.md。

1. SSoT 経路（3 層）

prompts/production/<gate-id>/prompt.md   (git SSoT / ADR-0042 Type 1)
  │  scripts/prompt-kv-push.mjs でデプロイ
  ▼
PROMPTS_KV  bizlp:prompts:<gate-id>:<semver>  (+ :active ポインタ / :params)
  │  loadPrompt() が実行時に読込
  ▼
src/nodes/<node>.ts の FALLBACK_PROMPT      (KV 読込失敗時のみ。production と一字一句同期義務)

• KV のキー設計は データ定義書 §2.2。
• LLM パラメータ（temperature / seed / sampling_n）は prompt.meta.yaml → KV :params → loadLlmParams()。

2. ゲート × プロンプトソース対応表（機械突合の対象）

3. ゲート別 I/O 契約

出力はすべて JSON。機械可読の正典は各 output_schema.json、ここでは要点を示す。担当モデルは src/llm/gateway.ts の MODELS マップ（triage/slug=gemini-flash、socratic=claude-sonnet、scoring/body/consistency/cross-validation/policy/reviewClaude=claude-opus、reviewGemini=gemini-pro、reviewGpt4=gpt-o3）。

3.1 gate0-triage（記録価値判定）

• 入力: タイトル / 背景・目的（context）/ 検討した代替案（options）
• 出力: { is_adr_worthy: boolean, mode: "Light"|"Standard"|"Critical"|null, reason: string(≤80字), suggested_title: string(≤30字)|null }
• 特記: Grapheme ≤80 かつ ADR 識別子なしの短文は LLM 呼出前に short-circuit（ADR-0095 Phase A）。判定は golden eval（26 ケース・FN=0 ブロッキング）が正。

3.2 gate1-da / gate1-pm / gate1-judge（盲点検出 3 段 DAG）

• DA 出力: { findings: [{ title, severity: critical|high|medium|low, evidence(≤3文), suggested_action }] } — 反論・見落としリスク 3〜5 件。観点は constitution.yaml の 22 観点から原稿シードで決定的に 3 観点選択（FNV-1a + mulberry32 / SOCRATIC_DETERMINISTIC 既定 ON）
• PM 出力: DA + category: technical|operational|business_regulatory|cognitive + probability: likely|possible|unlikely — 6 ヶ月後の失敗シナリオ
• Judge 出力: { findings: [{ source: devil_advocate|premortem|both, title, severity, actionability: block|revise_adr|add_to_risks|monitor, evidence, suggested_action, dedupe_group }], summary } — 統合・重複排除・最大 10 件
• 特記: Light モードは critical/high のみ最大 5 件に cap（ADR-0102）。差戻しには使わない（情報提供型）。

3.3 body-generation（ADR 本文生成）

• 入力: タイトル / context / options / triage mode
• 出力: テンプレート（docs/adr/_template.md）準拠の ADR 本文 Markdown（JSON でない唯一のゲート）。Scope / Kruchten Type / Confirmation H2 等の必須要素はテンプレート強制
• 特記: mode 別構造（Light=単一節・Standard/Critical=サブ見出し必須）。temperature 0.6。

3.4 gate4-scoring（品質採点）

• 入力: ADR 本文 + mode + KV :thresholds（Light 35 / Standard 40 / Critical 45。プロンプト本文内の固定値より KV が優先）
• 出力: { scores: { 1_problem_definition..10_long_term_impact: { score(0-5), comment } }, total(0-50), mode, threshold, pass, weakest_items[], feedback_for_user(≤150字), score_summary_md }
• 特記: N=5 Self-Consistency 多数決（ADR-0056。Light は N=1 固定）。

3.5 cross-validation（盲点 × Must 軸整合検証）

• 入力: 盲点 findings + 評価軸×スコア行列（本文 §3 から抽出）+ 起案者の生入力（title/context/options）+ 生成済み本文
• 出力: { verdicts: [{ finding_title, must_axis, must_score, undermines: boolean, body_only_mitigation: boolean, reasoning(1-2文) }] }
• 特記: ライフサイクル整合バー（実装時にしか検証できない前提は具体的緩和機構があれば addressed）+ body-only mitigation 割引（生入力に基づかない本文上の対処は割引）。bounded rounds 終端は LLM 外の純ロジック（crossval_loopbreaker.ts）が担う。

3.6 gate2-consistency（過去決定整合）

• 入力: ADR ドラフト + 既存 ADR 一覧（GraphQL 一括取得 + KV キャッシュ 3600s）
• 出力: { verdict: PASS|CONFLICT|SUPERSEDE|INFO, conflicts: [{ adr_number, adr_title, severity, reason }], rejection_hint(≤150字)|null, summary_md }

3.7 gate3-parallel-review（3 モデル並列レビュー / inline 構築）

• 入力: ADR 本文 + reviewer 設定（role / focus を 3 モデル別に buildSystemPrompt で組み立て）
• 出力（3 モデル共通）: { annotations: [{ quote: 本文引用|"#overall", type: strength|concern|suggestion, comment(1-2文) }] }
• 特記: Promise.allSettled で単一プロバイダ障害を吸収。Light モードは全スキップ（LIGHT_SKIP_GATE3 既定 ON）。

3.8 policy-alignment（会社方針整合）

• 入力: ADR ドラフト + COMPANY_POLICY（env 経由・デフォルト BIZLP_POLICY = 6 優先順位）
• 出力: { priority_alignment: [{ priority, label, aligned, comment }], accepted_risks[], unaccepted_risks[], tech_constraint_violations[], summary_md }
• 特記: §2 のとおり production ファイル欠落の既知ギャップあり。

4. 変更時の手続き

• プロンプト I/O 契約（出力スキーマ・閾値の意味・判定値域）の変更は L3: 本書 + output_schema.json + production prompt + 設計 doc（prompts/0X_*.md）を同一 PR で更新し、ADR を書く（id_conventions.md §3）。
• 本文の文言調整のみ（契約不変）は L4 扱いだが、golden eval（FN=0 ブロッキング）通過が必須（テスト計画書）。

変更履歴