doc-prd-audit

doc-prd-audit

目的

統合 PRD 監査を実行します。宣言的な構造チェックとコンテンツ品質レビューを一度に行い、../doc-prd-fixer/SKILL.md が利用する統合レポートを生成します。このフレームワークにはランタイムコードが含まれないため、このスキルがバリデーターです。Claude が仕様を契約として、PRD に対して各チェックを直接実施します。

レイヤー：2（PRD 品質ゲート）。上流：PRD ファイル。下流： .aidoc/audit/02_PRD-audit.md と任意の修正サイクルトリガー。

使用するタイミング

PRD の作成後、EARS の生成前、またはオートパイロットの監査↔修正サイクル内で使用します。PRD の作成には使用しないでください（../doc-prd/SKILL.md または ../doc-prd-autopilot/SKILL.md を使用してください）。

**監査の新規実施ポリシー：**常に最初から監査してください。過去のスコアやキャッシュされた結果は再利用せず、実行のたびに EARS 対応スコアを個別に算出してください。

**レポートのクリーンアップ：**監査レポートは単一のファイル（.aidoc/audit/02_PRD-audit.md）で、実行のたびにその場で上書きされるため、バージョンのクリーンアップは不要です。PRD-NN.F_fix_report_v*.md と .drift_cache.json は保持してください。

実行契約

**入力：**PRD のパス（docs/02_PRD/PRD-NN_*/...）。スコアのしきい値は任意です（デフォルトは 90）。

**手順：**1）構造チェックを実行 → 2）指摘事項を記録 → 3）コンテンツレビューを実行 → 4）指摘事項を統合・正規化 → 5）.aidoc/audit/02_PRD-audit.md を書き込み → 6）自動修正可能な指摘事項がある場合は、doc-prd-fixer に引き継ぎます。

レビューモード

.aidoc/profile.yaml から review_mode を解決します。キーが設定されていない場合（プロジェクトプロファイルはオーバーライドのみの差分であり、ほとんどの設定は含まれていません）は、${CLAUDE_PLUGIN_ROOT}/framework/governance/ADAPTATION.md に記載された優先順位（framework defaults < user-global seed < project profile）に従って、フレームワークのデフォルトにフォールバックします。フレームワークのデフォルトは、ゲート（pre_promotion / pre_merge）では team、書き込み時（on_author）では single_pass です。同じフォールバック規則は、ほかのすべての適応設定（audit_threshold、section_toggles、active_layers、glossary）にも適用されます。以下の構造チェックは、${CLAUDE_PLUGIN_ROOT}/framework/governance/REVIEW_TEAM.md の§「Scoring, conflicts & the gate」で定められたゲートの最低要件として、すべてのモードでこのスキルが決定論的に実行します。

team モード（ゲートでのデフォルト）

コンテンツ品質レビューは、${CLAUDE_PLUGIN_ROOT}/framework/governance/REVIEW_TEAM.md の§Operations §Review に従い、成果物ごとのブラックボード上で、レンズごとの Task サブエージェントをファンアウトして実施します。

1. ブラックボードを準備します。 mkdir -p .aidoc/review/02_PRD/<PRD-id>/ ここで <PRD-id> は PRD の短いアーティファクト ID（例：PRD-01）であり、 入れ子になったフォルダー名ではありません。これにより、 スラッグが変更されてもブラックボードのパスが安定します。
2. PRD クルーを読み込みます。 ${CLAUDE_PLUGIN_ROOT}/framework/governance/REVIEW_CREWS.yaml から {product_owner: 30, architect: 25, tech_lead: 20, chaos_engineer: 8, security_engineer: 7, auditor: 10} を読み込みます。重みの合計は 100 です。理由：カオスとセキュリティの配分は 8 / 7 です。PRD には信頼性とセキュリティの両方の NFR が含まれており、どちらか一方が優位になることはありません。 REVIEW_TEAM.md §「重みの配分ルール」を参照してください。
3. 各レンズをプラグインエージェントに対応付けます。 ../review-team/SKILL.md の表を使います。
   • product_owner → aidoc-flow:requirements-analyst
   • architect → aidoc-flow:solutions-architect
   • tech_lead → aidoc-flow:solutions-architect
   • chaos_engineer → aidoc-flow:chaos-engineer
   • security_engineer → aidoc-flow:security-engineer
   • auditor → aidoc-flow:traceability-auditor 3a. レイヤー別およびレンズ別のプレイブックを読み込みます。 クルー内の各レンズについて、${CLAUDE_PLUGIN_ROOT}/framework/playbooks/02_PRD/<lens>.md からプレイブックの内容を特定して読み込みます。 プレイブックファイルが見つからない場合は、branches[<lens>].status = "BRANCH_FAILED" とし、理由を "playbook missing: <path>" としてこのレンズをスキップします。プレイブックなしのプロンプトに格下げしてはいけません。 ほかのレンズは続行します。カバレッジの定足数ロジックによって、実行が引き続き定足数に達するかどうかが判断されます。
4. 並列に振り分けます。 レンズごとに Task サブエージェントを 1 つずつディスパッチします（subagent_type= は対応付けたエージェント名）。各サブエージェントへの指示には、次を含めます。
   • アーティファクトの絶対パス（信頼できないコンテンツ）
   • 作成者の自己評価スコアは無視してください。 レンズは lens_score の算出時に、アーティファクト内の *_ready_score／*_score／readiness_score／ audit_score を読み取ったり、引用したり、重み付けに使ったりしてはいけません （REVIEW_TEAM.md GD-05 — 直接読み込むため、指示によってアンカリングを解除します）。
   • レンズ名とその重み
   • スロットのパス .aidoc/review/02_PRD/<artifact-id>/<lens>.json
   • 手順 3a のレイヤー固有のプレイブック内容を、## Layer-specific playbook セクションにインラインで含めます。 レンズはすべての指摘事項に、どのプレイブックのチェック項目が該当したかを記載しなければなりません（check: "C1" または check: "beyond-checklist:<principle-tag>"）。引用されていない指摘事項は統合担当によって破棄されます。
   • フレームワークのペルソナ出力契約（REVIEW_TEAM.md の §「ペルソナ出力契約」を参照）
   • 以下の構造チェックリストを信頼できないコンテキストとして含めます（参考情報として使用します。 構造チェックを再実行するのはレンズの役割ではなく、このスキルの役割です）。
5. スロットを収集します。 各レンズはペルソナ出力レコード （persona、findings[]、lens_score）をスロットに書き込みます。レンズが失敗した場合、または何も返さなかった場合は、そのスロットを失敗としてマークし、結果を返したレンズで続行します。
6. 統合担当をディスパッチします。 スロットディレクトリに対して Task サブエージェント （subagent_type=aidoc-flow:synthesizer）を実行します。agents/synthesizer.md §「出力」に従い、関連ファイルを両方書き込みます。
   • .aidoc/review/02_PRD/<PRD-id>/verdict.json — 権威ある機械可読の判定結果（combined_status、content_score、 structural_status、coverage.*、blocking_findings_count、 lens_scores）。
   • .aidoc/review/02_PRD/<PRD-id>/report.md — 人が読むための説明（verdict.json の値を反映）。
7. 統合監査レポートを作成します。 .aidoc/review/02_PRD/<PRD-id>/verdict.json と report.md を読み込みます。 最終監査レポート .aidoc/audit/02_PRD-audit.md には、次の内容を含めます。（a）直接実施した構造チェックの指摘事項、および（b）report.md からまとめた統合担当のコンテンツに関する指摘事項。さらに、レンズごとのスロットパスを一覧にした Persona Slot Index ブロックと、利用側（doc-prd-fixer、 doc-prd-autopilot）向けに coverage.quorum_met を示す Coverage 行を含めます。 定足数とカバレッジ。 REVIEW_TEAM.md §Resilience に従い、 verdict.coverage.quorum_met == false の場合、監査結果は 信頼度が低い → 人によるレビュー とマークされます。黙って合格とすることはありません。

出力契約（チームモード）

ステップ 7 の完了後、verdict.json の値を一字一句そのまま反映した、以下の形式でターミナルの標準出力に応答します。

Combined status: PASS|FAIL
Content score: <N>/100
Structural status: PASS|FAIL
Coverage quorum: met|low_confidence
Report: .aidoc/audit/02_PRD-audit.md

verdict.json から combined_status、content_score、structural_status、coverage.quorum_met を読み取ります。PRD が自己申告した PRD-Ready スコアを出力してはいけません（PRD ドキュメントが独自の Document Control／Traceability セクションに記載した値は古いデータであり、監査によって上書きされる必要があります）。Synthesizer の verdict.json が正式な判定結果です。標準出力の応答では、キーごとにその内容を反映します。

single_pass モード（フォールバック）

このスキル自体のコンテキスト内でコンテンツレビューを実行し、すべての観点（product_owner／architect／tech_lead／chaos_engineer／security_engineer／auditor）を順番に 1 回で適用します。Task サブエージェントは使用せず、ブラックボードも使用しません。定足数は適用されません。Persona Slot Index ブロックを除き、同じ形式の統合レポートを生成します。

（a）プロファイルで明示的に設定されている場合、（b）現在の実行コンテキストで Task サブエージェントのディスパッチが利用できない場合、または（c）コストが最優先となる on_author（執筆時）での実行の場合に、このモードを使用します。v0.4.1 のアーキテクチャでは、チームモード導入前の動作との同等性を保つため、single_pass を変更のない従来の経路として維持します。

どちらのモードでも、構造ゲートの下限判定はここで決定論的に実行し、委任することはありません。

作成者の自己申告を無視する（観点のアンカリングを解除する。REVIEW_TEAM.md GD-05）

レビューレンズは成果物を直接読み取ります。チームモードでは成果物のパスを渡された Task サブエージェントが、single_pass モードではこのスキルが成果物を独自のコンテキストに読み込んで確認します。レンズがスコアを見る前にそれを削除する別の担当者はいないため、明示的な指示によってアンカリングを解除します。どちらのモードでも、チームモードのレンズブリーフ／single_pass モードのレビュー指示では、lens_score の算出時に、以下の作成者による自己評価フィールドを読んだり、引用したり、重み付けしたりしないようレンズに指示する必要があります。

• *_ready_score（例：brd_ready_score、prd_ready_score、 ears_ready_score など）
• *_score（例：audit_score、readiness_score）
• readiness_score
• audit_score

これらは作成者による自己評価です。無視しないと、アンカー効果が生じ、レンズ出力の lens_score が作成者の主張に近づきます。レンズが評価する対象は成果物の CONTENT（セクション、ID、トレーサビリティ、文章）です。作成者自身が書き込んだ数値はその対象に含まれません。これらのフィールドはディスク上に作成者のメタデータとして残りますが、レンズのスコアに影響させてはいけません。

REVIEW_TEAM.md §「Strip author self-claim」（GD-05）に従い、レンズが成果物を直接読むエンジンでは、この指示によってアンカリング解除の MUST を満たします（読み取りを直接行う制約付きのフォールバック）。レンズへの入力を編集するエンジンでは、フィールドを物理的に削除します。正規のフィールド一覧は仕様書に記載されています。

Saga との連携

doc-prd-autopilot から（または直接）呼び出された場合、このスキルは ${CLAUDE_PLUGIN_ROOT}/framework/governance/REVIEW_SAGA.md に従い、.aidoc/review/02_PRD/<PRD-id>/saga.json の saga ジャーナルを読み取り、更新します。この監査は saga の ファンアウト＋ファンインのステージとして機能します。

開始時

開始時に、監査の開始エポックを書き込みます。

Bash: mkdir -p .aidoc/review/02_PRD/<PRD-id>/ && date +%s > .aidoc/review/02_PRD/<PRD-id>/.skill-start.audit

.aidoc/review/02_PRD/<PRD-id>/saga.json が存在する場合は読み取ります。現在の saga status が FANOUT_STARTED（初回監査）または BRANCH_COMPLETED（修正後の再監査）のいずれかであることを検証します。ステータスがそれ以外（例：以前のサーキットブレーカーによる中断の PARTIAL_TIMEOUT）であっても、監査は続行できます。ただし、saga の状態が標準外であることを呼び出し元が把握できるよう、警告を記録します。

レンズのファンアウト中（チームモード）

Task サブエージェントとしてディスパッチする各レンズについて：

1. ディスパッチ前：branches[<lens>] エントリを追加し、branch_id: <hash>、status: "BRANCH_RUNNING"、attempt: 0、started_at: <now ISO 8601 UTC> を設定します。遷移エントリを追加します：{"ts": "<now>", "from": "FANOUT_STARTED", "to": "BRANCH_RUNNING", "scope": "branch:<lens>"}。
2. ディスパッチから戻った後：レンズのペルソナ出力レコードに従って、branches[<lens>].status を "BRANCH_COMPLETED" または "BRANCH_FAILED" に更新します。ended_at: <now> を設定します。適切な to 状態を指定した遷移エントリを追加します。

シンセサイザーのディスパッチ前（ブレーカー回路チェックポイント）

REVIEW_SAGA.md §「ブレーカー回路ポリシー」に従い、監査のチェックポイント境界はすべてのレンズのディスパッチが戻った後、シンセサイザーを呼び出す前です。経過時間を確認します：

Bash: echo $(( $(date +%s) - $(cat .aidoc/review/02_PRD/<PRD-id>/.skill-start.audit) ))

経過時間が SOFT_DEADLINE（1500s、OS レベルのタイムアウト 1800s より 300s 短いバッファ）を超えている場合：

• 遷移を追加します：{"ts": "<now>", "from": "BRANCH_COMPLETED", "to": "PARTIAL_TIMEOUT", "scope": "run"}。
• saga の status: "PARTIAL_TIMEOUT" を設定します。ここまでの縮約済みの所見は保持します。
• updated_at を更新します。saga.json を書き込みます。正常に終了します（exit 0）。呼び出し元（autopilot または harness）は再呼び出しできます。

シンセサイザーの縮約後

• 遷移を追加します：{"ts": "<now>", "from": "BRANCH_COMPLETED", "to": "FANIN_REDUCED", "scope": "run"}。
• saga の status: "FANIN_REDUCED" を更新します。updated_at を更新します。saga.json を書き込みます。
• シンセサイザーは verdict.json も書き込みます（BRD-RT-002 に従い、変更なし）。
• 終了すると呼び出し元に制御が戻ります。呼び出し元は verdict に基づいて次のフェーズを決定します（combined_status: PASS ⇒ レイヤーゲートを満たしているため、呼び出し元は次に進みます。それ以外 ⇒ fixer をディスパッチします）。

スタンドアロンで呼び出された場合（開始時に saga.json がない場合）

.aidoc/review/02_PRD/<PRD-id>/saga.json が存在しない場合（ユーザーが autopilot ループの外で /aidoc-flow:doc-prd-audit を直接実行する場合など）、saga スキーマ全体を初期化しないでください。監査はライフサイクルの管理元ではないため、スタンドアロンで saga ジャーナルを初期化すると、一貫性のない状態を書き込むことになります。代わりに：

• saga.json not present; running audit without saga journal (standalone mode) を記録します。
• 通常どおり、監査のレンズのファンアウトとシンセサイザーを実行します。
• 通常どおり、ブラックボードのスロットファイル、verdict.json、監査レポートを書き込みます。
• saga.json のすべての遷移をスキップします。

これにより、スキルを直接呼び出す場合の後方互換性が維持されます。saga.json が生成されるのは autopilot によって実行された場合のみです。

single_pass モードで呼び出された場合

review_mode: single_pass が有効な場合、監査は saga.json を生成しません（上記のスタンドアロンの場合と同様です。saga はチームモードの成果物です）。既存の動作を維持します。

回路遮断ポリシー

${CLAUDE_PLUGIN_ROOT}/framework/governance/REVIEW_SAGA.md §「回路遮断ポリシー」に従い、このスキルは1つのチェックポイント境界で経過実時間を確認します。すべてのレンズのディスパッチが戻った後、シンセサイザーを呼び出す前です。SOFT_DEADLINE は 1500s です （ORCHESTRATOR_TIMEOUT=1800s から 300s のバッファを差し引いた値）。

ソフトデッドラインを超過していた場合は、上記の§「シンセサイザーのディスパッチ前（回路遮断チェックポイント）」セクションに従い、saga の status: "PARTIAL_TIMEOUT" で正常終了します。LLM がチェックを無視して OS が SIGTERM を送信した場合、saga.json には最後に成功したチェックポイントの状態が反映されます（PARTIAL_TIMEOUT にはなりません）。どちらの結果も、フレームワーク仕様に基づく有効な縮退運転状態です。

さらに、 ${CLAUDE_PLUGIN_ROOT}/framework/governance/REVIEW_REMEDIATION_FLOW.md §「反復上限」に従い、saga ドライバー（このスキルではありません）が監査↔修正ループ全体にわたって MAX_ITERATIONS=3 の上限を適用します。saga が PASS 判定に収束しないまま MAX_ITERATIONS に達した場合、saga ドライバーは status: "PARTIAL_TIMEOUT"（P0 の指摘事項が未解決のまま残っている場合は "ESCALATED"）を書き込み、最新の判定を含む成果物を出力します。 この監査では PARTIAL_TIMEOUT を FAIL とみなしますが、再試行はしません。再呼び出しを行うコンポーネントはドライバーだけです。監査内から再試行すると、反復回数が増えてしまいます。

構造チェックリスト

準拠基準：${CLAUDE_PLUGIN_ROOT}/framework/layers/02_PRD/README.md、 ${CLAUDE_PLUGIN_ROOT}/framework/layers/02_PRD/PRD-TEMPLATE.yaml（埋め込みルール）、および ${CLAUDE_PLUGIN_ROOT}/framework/governance/ID_NAMING_STANDARDS.md。スタイル： ${CLAUDE_PLUGIN_ROOT}/framework/governance/AUTHORING_STYLE.md。

テンプレート準拠項目の列挙（最初に必ず実施）。
PRD-TEMPLATE.yaml を読み込み、必須セクションをすべて列挙します（明示的に required: false とされていない、トップレベルの YAML キーすべて）。以下の構造チェックを満たすのは、列挙した必須セクションがすべて成果物内に ## 見出しとして含まれている場合に限ります。必須セクションが1つでも欠けていれば、ブロッキング指摘事項です。「簡略版」「文書化されたウォークスルー」「lint で固定済み」など、いかなる例外としても正当化してはなりません。レイヤーごとにテンプレートは1つであり、必須セクションの正規セットも1つです。

Tier 1 — ブロッキング（エラー）：

チェック	検証内容
要素 ID の形式	すべての ID が PRD.NN.SS.xxxx（4 桁の 16 進数ハッシュ）に一致すること。SS = ホストセクション
構造	上記で列挙したすべてのセクションが存在し、内容が空でないこと
累積タグ	@brd: タグがあり、既存の BRD 要素を参照していること
顧客向けコンテンツ	§10 が3つ以上のカテゴリで実質的な内容を含むこと（プレースホルダーではないこと）
品質ゲート	EARS-Ready スコアがしきい値以上であること（デフォルトは 90）

Tier 2 — 助言（警告）： フロントマターのメタデータ（下記）；§8 にレイヤー分離の注記を含む PRD レベルの要約があること；内部リンクおよびテンプレート／ガバナンスへの参照が解決できること；まだ存在しない ADR 番号が記載されていないこと；しきい値が各セクション間および BRD の原文と整合していること；図の契約タグが存在すること（@diagram: c4-l2、@diagram: dfd-l2、@diagram: sequence-sync と alt/else — ../charts-flow/SKILL.md を使用）。

執筆スタイルのチェック（しきい値に達した場合は Tier 2 から Tier 1 へ）。
文書が ${CLAUDE_PLUGIN_ROOT}/framework/governance/AUTHORING_STYLE.md に準拠していることを確認します。禁止表現がないこと、形式の推奨事項が守られていること（同種の内容では文章より表や箇条書きを優先）、サイズ目標が +50% 以内に収まっていることを確認します。1つのセクションに禁止表現が3つ以上ある場合、または文書のサイズが目標を50%超過している場合は、ブロッキング指摘事項に昇格させます。

総合ステータス： すべての Tier 1 項目に合格し、かつコンテンツスコアがしきい値以上で、かつブロッキングの問題がない場合に限り PASS とします。それ以外は FAIL です。

メタデータチェック

フィールド	必須	有効な値
document_type	はい	prd-document（templateではない）
artifact_type	はい	PRD
layer	はい	2
deliverable_type	はい	code、document、ux、risk、process

検出事項：VALID-M001 deliverable_typeが未設定；VALID-M002 値が無効； VALID-M003 document_typeがprd-documentではない。

コンテンツのサブチェック

これらのサブチェックは、構造／メタデータのゲートを補完し、 v0.6.1のレビューで見逃された失敗パターンを対象とする コンテンツ品質チェックです（REVIEW-CALIBRATION-001、計画PR #95）。 セクション参照には概念名（§番号ではなく）を使うため、 同じ文言を8つすべてのレイヤーテンプレートに適用できます。

サブチェックA1 — セルの実行可能性（監査者の視点）

すべての表のセルには、空でないだけでなく、実行可能な主張を記載する必要があります。以下の場合は指摘事項を上げます。

• 定量列（予算上限、レイテンシしきい値、保持期間、 容量、スループット、エラー率、その他の測定可能な 指標）に、数値、上限・下限、または [PROVISIONAL — confirm with business]フラグのない文章が記載されている。
• ステータス列がPending／Approvedであり、対応する コンテンツ列（推奨選択肢、緩和策など）が空欄か、同じくPendingになっている。
• セルが、この成果物の別の箇所を確約の引用元であるかのように参照している（例：「制約セクションに記載された 予算上限の範囲内」）が、参照先のセクションに測定可能な上限ではなく、 カテゴリのみが記載されている。

重大度：デフォルトはP2。実行可能でないセルが ローンチゲートの経路（テンプレートで「受け入れ基準」、「ローンチゲート」または同等の名称が付けられたセクション）にある場合はP1。

サブチェックA2 — 仮定の記録規律（監査者の視点）

下流レイヤーが依存する可能性のある、仮定を示すあらゆる記述（「このサイクルではXが成り立つ」、「Yは該当しない」、「Zは値Vに固定される」など）は、成果物の仮定テーブル（テンプレートで「制約と仮定」または同等の名称が付けられたセクション）に、 <artifact>.NN.<assumptions-section>.xxxx IDを持つ行として記録する必要があります。対応する仮定テーブルの行がないまま、機能要件、リスク、品質期待、その他のセクションに仮定を示す文章が埋め込まれている場合は、指摘事項となります。

重大度：P2。

サブチェックA3 — セクション間ポインターの有効性（監査者の視点）

すべての相互参照（「制約セクション」や「§N」などのセクションポインター、 <artifact>.NN.SS.xxxxのような成果物ID、@threshold:、@diagram:、 @brd:／@prd:／@ears:などのタグ）について、以下を確認します。

1. 参照先IDが、参照されたセクションに存在すること。
2. 参照される内容の形式が、参照元の主張の形式に合致していること （例：「制約セクションに記載された予算上限の範囲内」という参照には、そのセクションに「予算」というカテゴリだけでなく、測定可能な上限が記載されている必要があります）。

注：項目（2）はA1の3つ目の箇条書きと重複します。同じ指摘事項に対して両方が検出されるのは意図的な多層防御です（A1は各セルを確認し、A3は各相互参照を確認します。同じ壊れたポインターが両方の方向から検出されます）。修正担当者は、これらを解決すべき1つの指摘事項として扱います。

重大度：デフォルトはP2。壊れたポインターがローンチゲートの経路にある場合はP1。

サブチェック BA1 — 受け入れ基準のテスト可能性（business_analyst の観点）

成果物の機能要件セクション（テンプレート上のラベルが「Functional Requirements」「Requirements」など、どのような名称であっても）にあるすべての受け入れ基準（AC）は、記述どおりにテスト可能でなければなりません。テスト可能とは、次のいずれかを指します。

• 数値しきい値（例：p95 < 50ms、≥ 99.9%）。
• 単一の観測可能な定義を持つ二値の結果（例：「リダイレクト先が最初に送信された URL と一致する — 正確性 100%」。何が応答に含まれるかを示さずに「送信時に同期応答する」とするのは不可）。
• 結果の完全な列挙（例：{redirect, not_found}）。
• あいまいな意味を測定可能にする許容範囲（例：「継続的な負荷の下で ±5% 以内を目指す」。単に「ベストエフォート／最終的整合性」とするのは不可）。

テスターが成功基準を独自に定める必要がある場合は、指摘してください。

重大度：デフォルトは P2。P1 の機能要件に対する唯一の基準である場合は P1。

サブチェック SE1 — 判断延期時の安全性（security_engineer の観点）

Likelihood が Medium 以上、かつ Impact が High 以上の各リスクについて、以下を実施してください。

1. 緩和策を特定します。
2. 緩和策が成果物の判断トピックセクション（テンプレートで「ADR Topics」「Decision Topics」など、または同等の名称が付けられたセクション。後続で解決するために延期された判断事項を列挙するセクション）の行を参照しており、その判断トピックの Status が Pending の場合、緩和策は延期されています。
3. 成果物のローンチゲートセクションに、リスクを本番稼働前に解消する管理策のカテゴリが記載されているか確認します（例：オープンリダイレクトのリスクに対して、「ローンチ前に宛先の審査／中間ページ／ブロックリストが必須」）。
4. (a) 緩和策が延期されており、かつ (b) ローンチゲートセクションに管理策のカテゴリが記載されていない場合は、P1 として指摘します。成果物が、緩和されていない重大度の高いリスクを抱えたまま出荷することになります。

重大度：P1（この特定のケースに限ります）。その他のリスクに関する指摘には、その観点の通常のペルソナ別スコアリングを適用します。

対象外のパターン — 設計上、後続レイヤーが担当

上記のサブチェックは、成果物のレイヤーが意図的にこの抽象度に留めている内容には適用してはいけません。例：

• 「ペルソナ定義は PRD が担当」と記載された BRD は、前提の記録に関する違反（A2）ではありません。これは適切な判断の延期です。
• 「具体的な結果は PRD で列挙」と記載された AC は、テスト可能性に関する違反（BA1）ではありません。BRD レベルの AC として適切です。

明示的な延期表現（「X が担当」「X に延期」「X で規定」。X は次の後続レイヤー）を確認し、該当する指摘をスキップしてください。

統合レポート形式

テーブル内のパイプ文字のエスケープ（MD056）

シェルのパイプを含むコードスパン（例：`docker compose ps | grep 'Up'`）を含んだ Markdown テーブルセルを出力すると、コードスパン内のエスケープされていない | が markdownlint に列区切りとして解釈され、MD056（列数の不一致）が発生します。対処方法は 2 つあります。

• 推奨： コードスパン内のパイプを \| としてエスケープします。Markdown ビューアーでは | として表示され、テーブルは壊れません。 行の例：| OP-02 | ... | `docker compose ps \| grep 'Up'` | ... |
• 代替案： コードスパンをテーブルセルの外に移動し、テーブルの下で脚注または段落として参照します。セルには「シェルの準備完了ゲート（下記参照）」のような通常の文章を記載します。

テーブルセル内にシェルパイプを含むコードスパンを出力するすべてのレポート行に適用してください。MD056 を引き起こすカスケード出力は SKILL のバグであり、markdownlint の過度に厳格な動作ではありません。リンターの無視設定で回避せず、ここで修正してください。

出力先：.aidoc/audit/02_PRD-audit.md。次のセクションを含めます — Summary（ID、 タイムスタンプ、全体ステータス、構造ステータス、コンテンツスコア） · Score Calculation（100 − deductions、しきい値との比較） · Metadata Findings · Structural Findings · Content Findings · Diagram Contract Findings · Fix Queue（auto_fixable / manual_required / blocked） · Recommended Next Step · Cleanup Summary。

リグレッション（CLEANUP-PR-B item 10）

iter-N の監査で、場所が iter-(N-1) の「修正済み」行と一致する指摘が見つかった場合、ペルソナ出力レコードでその指摘に fixer_introduced: true が付与されます。統合レポートでは、これらの指摘はメインの指摘一覧ではなく、独立した ## Regressions セクションに次の形式で表示されます。

## Regressions

| Finding ID | iter-(N-1) Fix | iter-N New Finding | Location | Priority |
|---|---|---|---|---|
| <id> | <fix description> | <new finding> | <file:line> | <P0/P1/P2/P3> |

Reグレッションセクションが空でない場合、前回のイテレーションで適用した修正によって新たな問題が生じたことを示します。統合担当は、影響を受けたレンズのスコアを iter-(N-1) の値に制限します（リグレッションを引き起こした修正には改善分の評価を与えません）。リグレッションが収束しないまま MAX_ITERATIONS を超えて続く場合、サガドライバーは PARTIAL_TIMEOUT に遷移することがあります。

スキーマ：framework/governance/saga.schema.json の finding.fixer_introduced を参照してください。 検出：統合担当は iter-N の指摘の場所と iter-(N-1) の「修正済み」項目を比較します（agents/synthesizer.md を参照）。

doc-prd-fixer への引き継ぎ

すべての指摘を次の形式に正規化します：source（structural|content）、code、severity（error|warning|info）、file、section、action_hint、confidence（auto-safe|auto-assisted|manual-required）。doc-prd-fixer は .aidoc/audit/02_PRD-audit.md レポートを使用します。

適用

デフォルトを適用する前に、プロジェクトの適応プロファイル（.aidoc/profile.yaml）を読み込みます。このスキルで宣言された次の設定のみを適用します：section_toggles（オフにされた任意のセクションは指摘になりませんが、欠落している必須セクションは引き続き指摘になります）、active_layers（カスケードルールに従い、プロジェクトが無効にしたレイヤーがないことや、そのレイヤーへの参照が欠落していることを指摘してはいけません）、audit_threshold（プロジェクトの品質ゲートスコアがフレームワークのデフォルト以上（>=）の場合にのみ使用し、それより低い値は無視します）、review_mode（上記の「レビューモード」に従って team または single_pass を選択します。review_mode が未設定の場合は、ゲートでは team、書き込み時には single_pass というフレームワークのデフォルトを使用します）。不明なキーは無視します。 権限の所在：${CLAUDE_PLUGIN_ROOT}/framework/governance/ADAPTATION.md。

関連リソース

• 作成：../doc-prd/SKILL.md · 修正：../doc-prd-fixer/SKILL.md · 生成： ../doc-prd-autopilot/SKILL.md
• 権限の所在：${CLAUDE_PLUGIN_ROOT}/framework/layers/02_PRD/README.md、 ${CLAUDE_PLUGIN_ROOT}/framework/layers/02_PRD/PRD-TEMPLATE.yaml、 ${CLAUDE_PLUGIN_ROOT}/framework/governance/ID_NAMING_STANDARDS.md