役割: drp/ 配下のコードファイル・プロンプト設計ドキュメント・移行記録のファイルマップ。「このファイルは何をするか」の索引。プロンプト SSoT 経路・I/O 契約の詳しい説明は EDD-003 プロンプト仕様書 にある。

1. 現行(LangGraph 構成)

パス役割
README.md全体像・案内(本文書を含む layer 群へのハブ)
prompts/01_triage.mdGate 0 プロンプト設計ドキュメント (v0.3 / Triage)。背景・テストケース付き。プロンプト本文の SSoT は prompts/production/gate0-triage/prompt.md (ADR-0042 Type 1 管理)
prompts/02_scoring.mdGate 4 プロンプト設計ドキュメント (v0.2 / Scoring 50 点満点)。SSoT は prompts/production/gate4-scoring/prompt.md
prompts/03_socratic.mdGate 1 (盲点検出 / ADR-0071) 設計ドキュメント。SSoT は prompts/production/gate1-da/gate1-pm/gate1-judge/prompt.md の 3 本(socratic ノードはこの 3 つをロード)。prompts/production/gate1-socratic/prompt.md は ADR-0071 前の旧問診プロンプトで現在ロードされない死蔵ファイル(整理は main 申し送り)
prompts/04_consistency.mdGate 2 (過去整合性) 設計ドキュメント + TC-C01〜C05。SSoT は prompts/production/gate2-consistency/prompt.md
prompts/05_parallel_review.mdGate 3 (並列レビュー) 設計ドキュメント v2.0。プロンプト本文は parallel_review.tsbuildSystemPrompt で inline 構築(ノードは loadPrompt を呼ばず、KVgate3-parallel-review:params のみ参照)。prompts/production/gate3-parallel-review/prompt.md は旧 strengths/concerns/suggestions スキーマのままでノードから参照されていない(annotations スキーマへの同期は main 申し送り)
phase3_parallel_review_design.mdPhase 3 設計メモ — 並列実行アーキテクチャ / 3 モデル役割分担 / エラー吸収 / 情報提供型 vs 差戻し型の判断
test_cases.mdTriage / Scoring 検証用テストケース (TC-01〜07)。自動実行は drp/test-tc.mjs
(Socratic 用テスト)TC-S01〜S03。設計ドキュメントは prompts/03_socratic.md 末尾、自動実行は drp/test-tc-socratic.mjs
(Consistency 用テスト)TC-C01〜C05。設計ドキュメントは prompts/04_consistency.md 末尾、自動実行は drp/test-tc-consistency.mjs
src/do/pipeline_session.tsPipelineSessionDO — Durable Object で非同期実行の状態管理 (ADR-0066 Phase A1)
src/queues/pipeline_consumer.tsConsumer Worker — Cloudflare Queues からメッセージ取得し buildGraph().invoke() 実行 (ADR-0066 Phase A2)
.github/workflows/drp-trigger.ymlCI trigger — workflow_dispatch で Pipeline 実行 (ADR-0064 先行実装 / ADR-0066 Phase A4)
(起案者向け運用ガイド)docs/_internal/05_how-to/operator_guide_langgraph.md (LangGraph 版・現運用) + operator_guide.md (Dify Retired) は ADR-0045 §決定 (人間手順書 = 05_how-to/) 準拠で別ディレクトリへ移動済

SSoT について: ゲート別の SSoT 経路(git production ファイル → KV → inline fallback)と I/O 契約の詳しい説明は プロンプト仕様書 (EDD-003) にまとめてある。prompts/*.md(01〜05)は設計背景・テストケース付きの人間可読ドキュメント(Type 3)。プロンプト更新時は production / 設計 doc / プロンプト仕様書を同一 PR で更新すること。
ライフサイクル運用手順: docs/_internal/06_ops/prompt_lifecycle_guide.md

2. 起案 / 検証プロンプト(operator-prompts)

起案者(社内メンバー / 業務委託パートナー / 代表取締役)が KV ストレージ(DRAFTS_KV)への ADR draft 投入を別 Claude Code セッションで実行するための自己完結プロンプト集。各プロンプトは認証情報取得(macOS keychain 経由)→ POST /drafts → 確認 → 代表取締役への報告 までの手順を含む。

パス役割
RQ-051_kv_submission_prompt.mdRQ-051 (bizlp Lint Rule Reference 文書構造) ADR 起案: Decision Pipeline KV 投入プロンプト (Standard Mode、PR 自動作成あり)
ADR-0050_retroactive_validation_prompt.mdADR-0050 (Synthesis 標準テンプレート) の Retroactive Validation 用プロンプト (Critical Mode、PR 作成スキップ — 既に main 統合済 ADR の事後検証のため)
ADR-0050_gate4_validation_report.mdADR-0050 Retroactive Validation の結果記録 (Gate 4 v1 40/50 差し戻し → v2 47/50 通過、改善余地 3 件、Parallel Review 重要指摘、Pipeline UI 改善余地) — Pipeline 自己審査の第一適用例として参考

Retroactive Validation とは: 既に main 統合済の ADR を後から Pipeline に通して Gate 0-4 のスコアと指摘のみ取得する事後検証フロー。新規 PR は作らない(/chat/create-pr を呼ばない)。「Critical 案件は Pipeline 経由」と規定する framework 自身が Pipeline 未経由だった矛盾を解消するメタレベルの検証手段。

3. 実装記録(Step 1〜8 の手順書 / 退役対応表)

Steps 1〜8 で参照した手順書。本番稼働後も実装の経緯を残すために保持する。

パス役割
langgraph_migration/migration_overview.mdDify 退役対応表 + Dify N1〜N13 → LangGraph node マッピング
langgraph_migration/main_workspace_checklist.mdSteps 1〜8 実装チェックリスト (完了済)
langgraph_migration/lint_baseline.mdadr-kit lint pass 率ベースライン (撤退条件 50% の判定材料)

4. 履歴(Dify Phase / Retired 2026-05-08, ADR-0019)

並行稼働期間なしで LangGraph TS に直接移行したため、以下は履歴として保持。新規参照は不要。

パス役割
phase2a_design.mdDify Phase 2a 設計書 (Retired)
dify_workflow_spec.mdDify Workflow 13 ノード仕様 (Retired)
dify_setup_instructions.mdDify Cloud セットアップ手順 (Retired)

変更履歴

日時変更
2026-06-07初版 — README §9 から移植(経緯: ADR-0117)