doc-brd-audit

doc-brd-audit

目的

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

レイヤー：1（BRD 品質ゲート）。上流：BRD ファイル。下流： .aidoc/audit/01_BRD-audit.md および任意の修正サイクルのトリガー。

使用するタイミング

BRD の作成後、PRD の生成前、または自動操縦の監査↔修正サイクル内で使用します。BRD の作成には使用しないでください（../doc-brd/SKILL.md または ../doc-brd-autopilot/SKILL.md を使用してください）。

**監査の初期化ポリシー：**常に最初から監査を実行します。以前のスコアやキャッシュ済みの結果は再利用せず、実行のたびに PRD-Ready スコアを個別に算出してください。

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

実行契約

**入力：**BRD のパス（docs/01_BRD/BRD-NN_*/...）、任意のスコアしきい値（デフォルトは 90）、任意の review_mode の上書き（team|single_pass）。デフォルトは .aidoc/profile.yaml から解決します。

**手順：**1）構造チェックを実行（常に決定論的）→ 2）検出事項を記録 → 3）コンテンツレビューを実行（review_mode に応じて分岐。以下を参照）→ 4）検出事項を統合・正規化 → 5）統合監査レポートを .aidoc/audit/01_BRD-audit.md に書き込む（従来のバージョンごとの監査レポートの内容は維持し、.aidoc/ の来歴レイヤーに移動します）→ 6）自動修正可能な検出事項がある場合は、doc-brd-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/01_BRD/<BRD-id>/ ここで <BRD-id> は BRD の短い成果物 ID（例：BRD-01）であり、 入れ子になったフォルダー名ではありません。これにより、スラッグが変更されても 黒板のパスが安定します。
2. BRD クルーを読み込みます。 ${CLAUDE_PLUGIN_ROOT}/framework/governance/REVIEW_CREWS.yaml から読み込みます — {architect: 30, business_analyst: 30, auditor: 20, chaos_engineer: 12, security_engineer: 8}。重みの合計は 100 です。理由：BRD では、このレイヤーでは 脅威モデリングより信頼性 NFR の比重が大きいため、カオスエンジニアの重みを 高くしています。REVIEW_TEAM.md §「重みの割り当てルール」を参照してください。
3. 各レンズを対応するプラグインエージェントに割り当てます。 ../review-team/SKILL.md の表を使います。
   • architect → aidoc-flow:solutions-architect
   • business_analyst → aidoc-flow:requirements-analyst
   • auditor → aidoc-flow:traceability-auditor
   • chaos_engineer → aidoc-flow:chaos-engineer
   • security_engineer → aidoc-flow:security-engineer 3a. レイヤーとレンズのプレイブックを読み込みます。 クルー内の各レンズについて、 ${CLAUDE_PLUGIN_ROOT}/framework/playbooks/01_BRD/<lens>.md から プレイブックの内容を特定して読み込みます。 プレイブックファイルが見つからない場合は、理由を "playbook missing: <path>" として branches[<lens>].status = "BRANCH_FAILED" に設定し、このレンズをスキップします。 プレイブックなしのプロンプトに格下げしてはなりません。他のレンズは続行します。 実行がクォーラムに達するかどうかは、カバレッジ・クォーラムのロジックで判定します。
4. 並列に振り分けます。 各レンズにつき 1 つの Task サブエージェントを ディスパッチします（subagent_type= は対応するエージェント名）。 各サブエージェントのブリーフには、次の内容を含めます。
   • 成果物の絶対パス（信頼できないコンテンツ）
   • 作成者の自己評価スコアは無視してください。 レンズは lens_score の 算出時に、成果物内の *_ready_score／*_score／readiness_score／ audit_score を読んだり、引用したり、重み付けに使用したりしてはなりません （REVIEW_TEAM.md GD-05 — 直接読み取るよう指示することで、アンカリングを 防ぎます）。
   • レンズ名とその重み
   • スロットのパス .aidoc/review/01_BRD/<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 §「出力」に従い、付随する 2 つのファイルを両方書き込みます。
   • .aidoc/review/01_BRD/<BRD-id>/verdict.json — 正式な機械可読の判定結果 （combined_status、content_score、structural_status、coverage.*、 blocking_findings_count、lens_scores）。
   • .aidoc/review/01_BRD/<BRD-id>/report.md — 人間向けの説明 （verdict.json の値を反映します）。
7. 統合監査レポートを作成します。 .aidoc/review/01_BRD/<BRD-id>/verdict.json と report.md を読み込みます。最終監査レポート .aidoc/audit/01_BRD-audit.md には、 (a) 直接実行した構造チェックの指摘事項と、(b) report.md から抽出した 統合担当のコンテンツ指摘事項を含めます。さらに、レンズごとのスロットパスを列挙する Persona Slot Index ブロックと、利用側（doc-brd-fixer、doc-brd-autopilot）向けに coverage.quorum_met を示す Coverage 行を含めます。 定足数と網羅性。 REVIEW_TEAM.md §Resilience に従い、 verdict.coverage.quorum_met == false の場合、監査結果は 信頼度低 → 人によるレビュー としてマークされます。サイレントパスにはなりません。

出力コントラクト（team mode）

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

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

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

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

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

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

どちらのモードでも、構造ゲートの下限チェックはここで決定的に実行され、 委任されることはありません。

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

レビュー観点は成果物を直接読み取ります。team mode では、成果物のパスを渡された Task サブエージェントが読み取り、single_pass モードでは、このスキルが成果物を 自身のコンテキストに読み込みます。観点がスコアを見る前にスコアを取り除く別の主体は 存在しないため、アンカリングの解除は明示的な指示によって行います。両方のモードで、 観点へのブリーフ（team）／レビュー指示（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-brd-autopilot から（または直接）呼び出された場合、このスキルは .aidoc/review/01_BRD/<BRD-id>/saga.json にある saga ジャーナルを読み取り、 ${CLAUDE_PLUGIN_ROOT}/framework/governance/REVIEW_SAGA.md に従って更新します。 監査は saga のファンアウト＋ファンイン段階として機能します。

開始時

開始時に、監査の開始エポックを記録します。

Bash: mkdir -p .aidoc/review/01_BRD/<BRD-id>/ && date +%s > .aidoc/review/01_BRD/<BRD-id>/.skill-start.audit

.aidoc/review/01_BRD/<BRD-id>/saga.json が存在する場合は読み取ります。 現在の saga の status が次のいずれかであることを検証します：FANOUT_STARTED（初回監査）、 BRANCH_COMPLETED（修正後の再監査）。status がそれ以外の場合（例：前回の break-circuit による 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/01_BRD/<BRD-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 に従い、 変更なし）。
• 終了すると呼び出し元に制御が戻ります。呼び出し元は判定 （combined_status: PASS ⇒ レイヤーのゲートを満たしているため、 呼び出し元は次に進みます。それ以外 ⇒ 修正担当をディスパッチします） に基づいて次のフェーズを決定します。

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

.aidoc/review/01_BRD/<BRD-id>/saga.json が存在しない場合（例： ユーザーが autopilot ループの外で /aidoc-flow:doc-brd-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 は1500秒です （ORCHESTRATOR_TIMEOUT=1800s から300秒のバッファを差し引いた値）。

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

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

構造チェックリスト

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

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

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

チェック	検証内容
要素 ID の形式	すべての ID が BRD.NN.SS.xxxx（4桁の16進数ハッシュ）に一致すること
構造	上記で列挙したすべてのセクションが存在し、内容が空でないこと
セクション間ルール	テンプレートの cross_section_rules を満たしていること
品質ゲート	PRD-Ready スコアがしきい値以上であること（デフォルトは90）

Tier 2 — 助言（警告）： フロントマターのメタデータ（以下参照）、内部リンクおよびテンプレート／ガバナンスへの参照が解決できること、下流の数値を確定前に引用していないこと、図の契約タグが存在すること（@diagram: c4-l1、@diagram: dfd-l1 — BRD では助言事項です。../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	はい	brd-document（template ではない）
artifact_type	はい	BRD
layer	はい	1
deliverable_type	はい	code、document、ux、risk、process

指摘：VALID-M001 deliverable_type がない、VALID-M002 無効な値、VALID-M003 document_type が brd-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 の視点）

成果物の機能要件セクション（テンプレートで「機能要件」「要件」など、どのようなラベルが付けられていても）にあるすべての受け入れ基準は、記載どおりにテスト可能である必要があります。テスト可能とは、次のいずれかを満たすことです。

• 数値のしきい値がある（例：p95 < 50ms、≥ 99.9%）。
• 観測可能な定義が 1 つに定まる二値の結果がある（例：「リダイレクト先が最初に送信された 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 の過剰な厳格さではありません — lint の無視設定で対処するのではなく、ここで修正してください。

出力パス：.aidoc/audit/01_BRD-audit.md（.aidoc/ 来歴ティア）。セクション — Summary（ID、タイムスタンプ、全体ステータス、構造ステータス、コンテンツスコア、mode（team | single_pass）） · Score Calculation（100 − deductions、しきい値との比較） · Coverage（team モードのみ：実行されたレンズと期待されるレンズ、quorum_met ブール値） · Persona Slot Index（team モードのみ：.aidoc/review/01_BRD/<BRD-id>/<persona>.json スロット、シンセサイザーの verdict.json および report.md へのパス） · Metadata Findings · Structural Findings · Content Findings（team モードではシンセサイザーのレポートから集約、single_pass ではこのスキル独自のレンズごとのレビューから集約） · Diagram Contract Findings · Fix Queue（auto_fixable / manual_required / blocked） · Recommended Next Step · Cleanup Summary。

解決された review_mode が single_pass の場合、トリガーの状況にかかわらず、必ず single_pass の注意書きを含めてください（このスキルはゲートにあるかどうかを確実には把握できません）。注意書きは Summary セクションにコールアウトの引用ブロックとして配置します。

注意モード。 この監査は single_pass で実行されました — 1 つのモデルが 1 つのコンテキスト内ですべてのレンズを適用しています。
${CLAUDE_PLUGIN_ROOT}/framework/governance/REVIEW_TEAM.md §「Scoring, conflicts & the gate」にあるとおり、ゲートレビューの標準モードは team です。single_pass はコストを抑えるためのフォールバックであり、レンズ間の独立性が低下します。ここでの 0〜100 のスコアは参考情報です。本番環境のゲート実行では、team モードで再監査してください。

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

iter-N 監査で、場所が iter-(N-1) の「Fixes Applied」行と一致する指摘が見つかった場合、ペルソナ出力レコードでその指摘に fixer_introduced: true が付与されます。Combined Report では、これらの指摘はメインの指摘一覧ではなく、独立した ## 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> |

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

スキーマ：framework/governance/saga.schema.json finding.fixer_introduced を参照してください。
検出：シンセサイザーが iter-N の指摘の場所を iter-(N-1) の Fixes Applied エントリーと比較します（agents/synthesizer.md を参照）。

doc-brd-fixer への引き継ぎ

すべての指摘を次の形式に正規化してください：source（structural|content）、code、severity（error|warning|info）、file、section、action_hint、confidence（auto-safe|auto-assisted|manual-required）。doc-brd-fixer は .aidoc/audit/01_BRD-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-brd/SKILL.md · 修正：../doc-brd-fixer/SKILL.md · 生成： ../doc-brd-autopilot/SKILL.md
• 権威ある参照先：${CLAUDE_PLUGIN_ROOT}/framework/layers/01_BRD/README.md、 ${CLAUDE_PLUGIN_ROOT}/framework/layers/01_BRD/BRD-TEMPLATE.yaml、 ${CLAUDE_PLUGIN_ROOT}/framework/governance/ID_NAMING_STANDARDS.md