> ## Documentation Index
> Fetch the complete documentation index at: https://adcp-docs-ja.pier1.co.jp/llms.txt
> Use this file to discover all available pages before exploring further.

# 障害モード能力スコープ

> カリキュラムスコープドキュメント — どの障害モードがどの認定モジュールに属するか、深さターゲット、評価アプローチ。作成はモジュールごとのフォローアップ issue。

# 障害モード能力スコープ

このドキュメントは、各 AdCP 障害モードシナリオを、それが属する認定モジュールにマップし、ティアごとの深さターゲットを指定し、評価アプローチを定義します。これはスコープアーティファクトです — 各モジュールの実際のコンテンツの作成は、モジュールごとのフォローアップ issue で追跡されます。

**以下で使われる深さレベル:**

| Level           | 意味                                          |
| --------------- | ------------------------------------------- |
| 表面 / 認識         | 障害モードが存在することを知る; 促されたときに名指せる                |
| 診断 / 説明         | 原因、影響を受けるプロトコル表面、正しい回復パスを記述できる              |
| 解決 / デモンストレーション | サンドボックスエージェントに対してプロトコルツールを使い、回復をハンズオンで実行できる |
| 評価 / 作成         | マルチドメインの衝突について推論し、競合するルールを裁定し、新規シナリオを構築できる  |

***

## FM-1 — 冪等性リプレイ / コンフリクト / 期限切れ

**ステータス:** 部分的にカバー。`#2346` と `#2367` がトレーニングエージェントに冪等性を確立しました。このエントリーは評価スコープを統合します。

| Module         | Depth           | 評価アプローチ                                                                                                                                                                                                 |
| -------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **S1**（メディアバイ） | 解決 / デモンストレーション | エラー発見: 3 呼び出しトランスクリプト — (1) 同じキー + 同じペイロードでリトライ → `replayed: true`; (2) 新しいペイロード + 同じキーで再計画 → `IDEMPOTENCY_CONFLICT`; (3) TTL 後に使われたキー → `IDEMPOTENCY_EXPIRED`。学習者はどの呼び出し元が契約に違反したか識別し、3 つすべての正しい動作を説明。 |
| A2             | 表面 / 認識         | 学習者は `idempotency_key` がエージェントのリトライを実際の金銭に対して安全にすることを説明 — より深いトラブルシューティングは不要。                                                                                                                           |
| C4（ビルドプロジェクト）  | 解決 / デモンストレーション | 学習者の提出エージェントが冪等性キーを正しく生成し、再計画せずにリトライを処理。                                                                                                                                                                |

**作成前に閉じるギャップ:** S1 ラボ演習 7（「ライフサイクル管理」）が `NOT_CANCELLABLE` だけでなく 3 つのエラー状態すべてをサンドボックスでステージングすることを確認。そうでない場合、演習 7 を `IDEMPOTENCY_CONFLICT` と `IDEMPOTENCY_EXPIRED` をカバーするよう拡張。

***

## FM-2 — ローンチ後のクリエイティブコンプライアンス障害

**ステータス:** まだどのモジュールにもない。前提読書は S2 と S4 に存在するが、ローンチ後の発見パスをウォークするラボ演習はない。

| Module          | Depth                | 評価アプローチ                                                                                                                                                                                                                         |
| --------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **S2**（クリエイティブ） | 診断 / 説明 + デモンストレーション | シナリオ: クリエイティブがビルド時に `preview_creative` コンプライアンスを通過するが、`validate_content_delivery` がフライト開始後に違反を返す（例: 配信されたバリアントがプレビューレンダーに存在する規制開示を省略）。学習者は `get_media_buy_artifacts` を使って監査アーティファクトを取得し、不一致を説明し、修復オプション（一時停止してスワップ 対 キャンセル）を記述。 |
| S4（副次的）         | 診断 / 説明              | 学習者は `get_media_buy_artifacts` と `validate_content_delivery` がガバナンス監査証跡にどう接続するか説明。                                                                                                                                              |
| C2              | 表面 / 認識              | 学習者はクリエイティブコンプライアンスがローンチ後に失敗しうること、発見パスがローンチ前チェックとは別であることを知る。                                                                                                                                                                    |

**作成前に閉じるギャップ:** `validate_content_delivery` を使ってローンチ後コンプライアンス障害を明示的にステージングする番号付きラボ演習を S2 に追加。前提読書カードは存在する; 演習は存在しない。ステージングされたシナリオなしでは、評価は完全に会話に依存し、IACET Element 7（実証可能な能力証拠）を満たせない。作成 issue は、読書カードがラボ演習として提出されるのを防ぐため 3 つのことを指定しなければならない: (a) サンドボックスエージェントは、シミュレートされたフライト開始イベント後に特定のクリエイティブ ID で `validate_content_delivery` 違反を返すよう構成されなければならない; (b) 学習者は同じセッション内で `get_media_buy_artifacts` を呼び、監査アーティファクトを違反に相関させなければならない; (c) これは安定した基準 ID（例: `s2_postlaunch_sc0`）を持つ必須デモンストレーションを構成する — 再認定機構は ID が存在するときのみ発火する。

***

## FM-3 — 支払い / 決済の照合差異

**ステータス:** まだどのモジュールにもない。スキーマは `#2391`（billing reconciliation、AdCP 3.1）で最終化中。現在の配信とアカウンタビリティ条件の表面に対して今スコープ; `#2391` が着地したとき深さが拡大する。

| Module         | Depth   | 評価アプローチ                                                                                                                                                                                                                                                                                                                        |
| -------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **S1**（メディアバイ） | 診断 / 説明 | シナリオ: `get_media_buy_delivery` がフライト中間点で保証コミットメントより 12% 低いレポートインプレッションと、バイ作成時に受け入れられた `measurement_terms` と異なる `billing_measurement` ベンダーエントリーを示す。学習者は (a) 不一致タイプ — 配信不足 対 測定ベンダー不一致 — を識別; (b) 各の正しい修復 — ペーシング調整のための `update_media_buy` 対 `measurement_terms` 交渉に従った測定ベンダー不一致のエスカレーション — を名指す; (c) どのプロトコルアーティファクトが決済レコードか識別。 |

**作成のためのフラグ:** 作成時に安定した基準 ID（例: `s1_recon_sc0`）を割り当てる。`#2391` が照合スキーマを出荷したとき、現在の基準の下で発行された S1 クレデンシャルはターゲットを絞った再認定のためフラグされなければならない — インストラクショナルデザインフレームワークの再認定機構は基準 ID が存在するときのみ発火する。これを暗黙のままにしないこと。

**`#2391` 保留の深さ TBD:** billing reconciliation スキーマが着地したら、新しい決済フィールドをカバーする 2 番目の基準（`s1_recon_sc1`）を追加。その追加前に発行されたクレデンシャルは、プロトコルトリガー再認定ポリシーに従い再認定の候補。

***

## FM-4 — ガバナンストークン不一致 / ライフサイクル途中の認可失効

**ステータス:** 部分的にカバー。S4 は `GOVERNANCE_DENIED` 回復、15 ステップの JWS 検証、`governance_context` 相関モデルをカバー。ライフサイクル途中の失効はチェック時の拒否とは別で、まだシナリオとして名指されていない。

| Module        | Depth           | 評価アプローチ                                                                                                                                                                                                                                                                                                           |
| ------------- | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **S4**（ガバナンス） | 解決 / デモンストレーション | シナリオ: `governance_context` トークンがキャンペーンローンチ時に発行された; フライト途中、ガバナンスエージェントが認可を失効させる（ブランドが市場を退出、権利付与が期限切れ）。セラーの execution フェーズの `check_governance` が失効ステータスを返す。エラー発見: 失効を受け取った後に静かに配信を続けるセラー実装。学習者は障害を識別し、正しい動作（実行停止、webhook オーケストレーター、更新されたパラメーターで `sync_plans` を再実行）を説明し、15 ステップの JWS 検証のどのステップがキー侵害 対 有効な失効を捕捉するか説明。 |
| C2            | 表面 / 認識         | 学習者はガバナンストークンがライフサイクル途中で失効しうること、セラーの義務が続けることではなく停止することであることを知る。                                                                                                                                                                                                                                                   |

**作成前に閉じるギャップ:** S4 の「あなたがデモンストレーションすること」セクションは 15 ステップの JWS 検証と `governance_context` 相関モデルをカバーするが、ライフサイクル途中の失効を個別のシナリオとして名指していない。それをデモンストレーション項目として追加し、ラボ演習 7（「GOVERNANCE\_DENIED 回復」）を実行中失効バリアントで拡張。

***

## FM-5 — ライフサイクル状態がスタック（メディアバイ、クリエイティブ、アカウント、SI セッション、カタログ）

**ステータス:** 明示的な障害モードシナリオとしてまだどのモジュールにもない。S1 ラボ演習 6 は `pending_start` からの強制拒否をカバーするが、レスポンスなしのタイムアウトはカバーしない。S5 は通常の SI セッション管理をカバーするが、スタックまたは期限切れセッションはカバーしない。

| Module                   | Depth           | 評価アプローチ                                                                                                                                                                                                                                                                       |
| ------------------------ | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **S1**（メディアバイ）           | 解決 / デモンストレーション | シナリオ: メディアバイがセラー起動の遷移も webhook もなしに 36 時間 `pending_start` にある。学習者は (a) `get_media_buys` を使って `valid_actions` を読み状態を確認; (b) `cancel` が `pending_start` から利用可能であることを識別; (c) なぜ `pause` が `pending_start` から有効でないか説明; (d) セラーがフライト開始時に送らなければならない（MUST）webhook とそれが不在のとき何が起こるか記述。 |
| **S2**（クリエイティブ — 同期スタック） | 診断 / 説明         | シナリオ: `sync_creatives` 呼び出しが `accepted` を返すが、クリエイティブ承認ステータスが決して更新されず、バイが `pending_creatives` に留まる。学習者はバイの `valid_actions` を読み、セラー側の義務を識別し、エスカレーションパスを記述。                                                                                                                      |
| **S5**（SI — セッションスタック）   | 診断 / 説明         | シナリオ: SI Chat Protocol セッションが期待される TTL 後に `session_end` イベントを持たない。学習者はセッション期限切れセマンティクス、ホストが何をしなければならないか、終了されないセッションが作る状態リスクを説明。                                                                                                                                               |
| D1 / D3（プラットフォームトラック）    | 表面 / 認識         | 学習者は非同期プロトコル操作が停滞しうること、ポーリング対 webhook 照合パターンを説明。                                                                                                                                                                                                                              |

**作成前に閉じるギャップ:**

* S5 の現在の「あなたがデモンストレーションすること」は通常のセッション管理のみをカバー。セッション期限切れとスタックセッション回復を明示的なデモンストレーション項目として追加。
* S1 ラボ演習 6 は、既にステージングされた強制拒否とは別に、レスポンスなしのタイムアウトケースのために拡張（またはバリアント追加）されるべき。

***

## FM-6 — Webhook 配信障害 / リトライ

**ステータス:** 障害シナリオとしてまだどのモジュールにもない。D3 の前提読書はエラー処理を参照するが、webhook 障害をカバーするラボ演習や評価次元はない。

| Module           | Depth              | 評価アプローチ                                                                                                                                                                                                                                                           |
| ---------------- | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **D3**（プラットフォーム） | 診断 / 説明 + 構成       | シナリオ: セラーの `active` → `paused` 遷移が失われる — webhook エンドポイントが最初の試行で 503 を返し、リトライバックオフがバイヤーの期待ウィンドウを超えた。学習者は (a) 正しいリトライセマンティクス（指数バックオフ、配信イベントの冪等性）を記述; (b) 期待される webhook が到着しないときバイヤーエージェントが何をすべきか識別（`get_media_buys` をポール）; (c) webhook 駆動と poll 駆動の状態照合間のトレードオフを説明。 |
| S1（副次的）          | 診断 / 説明（コンシューマー視点） | 学習者は欠けている webhook をどう検出するか、いつ代わりにポールするか、これがキャンペーン状態管理にどう影響するか説明。                                                                                                                                                                                                  |
| B3（パブリッシャートラック）  | 表面 / 認識            | 学習者は webhook が失敗しうること、セラーがリトライを実装しなければならないことを知る。                                                                                                                                                                                                                  |

**作成前に閉じるギャップ:** webhook 配信障害をエンドツーエンドでウォークするシナリオを D3 のエラー処理議論内に追加（必ずしも完全な新演習でなくてよい）。D3 は現在エラー処理ドキュメントを前提読書としてリストするが、運用回復をテストするラボ演習や評価項目がない。

***

## FM-7 — 署名付きリクエスト検証障害

**ステータス:** 障害シナリオとしてまだどのモジュールにもない。S1 はバイヤーアイデンティティ解決チェーン（署名 → JWKS → エージェントエントリー → brand.json）を概念的にカバーするが、fail-closed 実装をテストするモジュールはない。

| Module           | Depth               | 評価アプローチ                                                                                                                                                                                                                                 |
| ---------------- | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **D2**（プラットフォーム） | 解決 / デモンストレーション（実装） | エラー発見: セラー実装が、`iss` が既知のブランドに一致するが JWKS フェッチがネットワークエラーで失敗し、実装が `iss` クレームを信頼することにフォールバックするリクエストを受け入れる。学習者は (a) 脆弱性 — キー検証なしにアイデンティティクレームを受け入れる — を識別; (b) 正しい動作 — fail closed、リクエストを拒否、フォールバックしない — を説明; (c) JWKS フェッチの SSRF リスクと緩和を記述。 |
| S1（副次的）          | 診断 / 説明（推論）         | 学習者はアイデンティティチェーンの各リンクが何を防御するか、なぜ JWKS フェッチ障害がむき出しの `iss` トラストへのフォールスルーをトリガーしてはならないか説明。                                                                                                                                                  |
| B2（パブリッシャートラック）  | 表面 / 認識             | 学習者は着信リクエストが署名検証されなければならないこと、検証障害が受け入れではなく拒否しなければならないことを知る。                                                                                                                                                                             |

**基準 ID に関する注記:** RFC 9421 リクエスト署名への将来の変更が両モジュールで独立して再認定をトリガーするよう、作成時に D2（`d2_sig_sc0`）と S1（`s1_sig_sc0`）に別々の基準 ID を割り当てる。

**関連（下の FM-C）:** エージェントディスカバリー時の `adagents.json` / `brand.json` 認可障害は、別途スコープされる密接に関連したオンボーディング障害モード。

***

## FM-8 — TMP プロバイダー統合障害

**ステータス:** 「TMP 証明障害」から再分類。TMP 暗号証明は AdCP 3.0 で SHOULD（MUST ではない）で、仕様で「将来の拡張」とマークされている — 現在の適合性モデルは HTTPS 上の `adagents.json` 経由のパブリッシャー証明。メカニズムが安定する前に暗号証明障害を認定トピックとして教えることは、現在のプロトコル動作ではなく将来のフィーチャーの知識をクレデンシャル化することになる。今日の運用上の実際の障害モードは: (1) `adagents.json` バインディング障害 — プロバイダーがリストされていない、`seller_agent` URL 不一致、または bypass モード誤構成; (2) TMP Router プロバイダー構成障害; (3) 統合誤構成による Identity Match が結果を返さず、フリークエンシーキャップロジックが no-cap 動作にフォールバックする。ホームは S3 ではなく S1 — TMP はメディアバイ実行メカニズムで、シグナル / オーディエンストピックではない。

**延期:** 暗号証明障害シナリオは、TMP が実験的ステータスから移行したときに追加される。

| Module         | Depth           | 評価アプローチ                                                                                                                                                                                                                                                                                                                                                                                                                                        |
| -------------- | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **S1**（メディアバイ） | 診断 / 説明         | シナリオ: マッチプロバイダーの `adagents.json` エントリーがセラーの `seller_agent` URL をリストしないか bypass モードが誤構成されているため、TMP Identity Match リクエストが結果を返さない。オーケストレーターのフリークエンシーキャップロジックが no-cap 動作にフォールバックし、過剰配信を招く。学習者は (a) `adagents.json` バインディングが何を証明するか — レスポンスがユーザーデータを露出せずに登録された TMP プロバイダーから来ること — を説明; (b) 正しいフォールバック動作 — 保守的: ユーザーを未知として扱い、デフォルトフリークエンシーキャップを適用 — を記述; (c) なぜ Context Match と Identity Match が構造的に分離され、この障害がクリエイティブ選択ではなくフリークエンシーキャッピングにどう影響するか説明。 |
| D3（副次的）        | 診断 / 説明（ルーター構成） | 学習者は TMP Router セットアップのプロバイダー構成ギャップを識別: `adagents.json` エントリー欠如または `seller_agent` URL 不一致。診断ステップと回復のための構成変更を説明。                                                                                                                                                                                                                                                                                                                                |
| S3（第三次的）       | 表面 / 認識         | 学習者は TMP 統合障害がコンテキストマッチングではなくアイデンティティマッチングを劣化させること、フォールバックが保守的フリークエンシー動作であることを知る。                                                                                                                                                                                                                                                                                                                                                              |

**作成前に閉じるギャップ:** S1 ラボ演習 9 に障害バリアントを追加 — 同じクロスパブリッシャー抑制シナリオだが、Identity Match が `adagents.json` 誤構成のため結果を返さない。これは既存演習の拡張で、新しいものではない。

***

## FM-9 — クロスプロトコルポリシー衝突

**ステータス:** まだどのモジュールにもない。S4 はガバナンスドメイン（campaign、property、collection、content standards、creative）の合成をカバーするが、複数ドメインからのルールが衝突し裁定されなければならないシナリオを含まない。

| Module        | Depth   | 評価アプローチ                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
| ------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **S4**（ガバナンス） | 評価 / 作成 | オープンエンド試験問題（ラボなし）: キャンペーンプランが `restricted_attributes: ['zip_code']` を持つ `policy_categories: ['fair_housing']` を指定する。クリエイティブガバナンスフィーチャー評価（`get_creative_features`）が zip-code 隣接の geo シグナルを参照するクリエイティブを通過させる。geo/mobility プロバイダーのシグナルアクティベーション（`activate_signal`）が zip コードから派生したが `restricted_attributes` でラベルされていないトレードエリアセグメントを含む。どのガバナンスドメインが優先されるか、バイヤーエージェントの義務は何か、正しい実装は何をするか? 学習者はキャンペーンガバナンス（プランレベル制約）、クリエイティブガバナンス（フィーチャー評価）、シグナルガバナンス（シグナルメタデータの制限属性）にまたがって推論しなければならない。 |
| S1, S2, S5    | 相互参照    | 各モジュールの「あなたがデモンストレーションすること」セクションは、クロスドメインポリシー裁定の権威的ホームとして S4 を相互参照すべき。S1/S2/S5 に独立した評価はない。                                                                                                                                                                                                                                                                                                                                                                                      |

**S4 の根拠（新しいクロスドメインセクションではなく）:** S4 は既に、campaign、property、collection、content standards、creative にわたる相互作用を含むガバナンスドメインの合成をカバー。クロスプロトコルシナリオは既存の S4 スコープの拡張で、S4 + S3 前提知識で評価可能。新しいモジュールセクションは、この issue が明示的に延期する作成スコープを要求する。

**`#2391` のためのフラグ:** billing reconciliation が支払い認可にガバナンス次元を導入する場合（例: 支出を制約するプランが billing reconciliation ルールに対して検証しなければならない）、`#2391` が閉じたときその相互作用のための 2 番目の基準 ID を S4 に追加。

***

## FM-A — アカウント支払い要求がアクティブバイをブロック

**ステータス:** 元の候補リストにない。カリキュラムレビュー中に実際の高頻度運用障害として識別。アカウントステートマシンはアカウントが `payment_required` に遷移することを許可し、それは新しい支出をブロックするが飛行中のキャンペーンを終了しない。すべての認可障害を一時的として扱うバイヤーエージェントは過剰リトライする; それらを致命的として扱うエージェントは依然として変更可能なキャンペーンの管理を止める。どちらの動作も正しくない。

| Module         | Depth   | 評価アプローチ                                                                                                                                                                                                                     |
| -------------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **S1**（メディアバイ） | 診断 / 説明 | シナリオ: `create_media_buy` が `ACCOUNT_PAYMENT_REQUIRED` を返す。同じアカウントでの `update_media_buy`（既存バイの変更）への 2 番目の呼び出しが成功する。学習者は (a) 新規支出認可障害と既存コミットメントの変更の区別を説明; (b) バイヤーエージェントの正しい動作 — 新規バイを止め、既存を放棄せず、支払いステータスをオーケストレーターに表面化 — を記述。 |

***

## FM-B — report\_usage 価格不一致

**ステータス:** 元の候補リストにない。課金紛争トリガーとして識別: バイヤーが `report_usage` でバイ時に交渉されたレートに一致しない `pricing_option_id` をレポートし、セラーエージェントがそれを拒否する。これは、価格オプション ID がバイとレポート呼び出しの間で変わる CPA とパフォーマンス価格キャンペーンで運用上苦痛。

| Module         | Depth   | 評価アプローチ                                                                                                                                                                                                                                                      |
| -------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **S1**（メディアバイ） | 診断 / 説明 | シナリオ: レポートの `pricing_option_id` が `create_media_buy` で受け入れられた `pricing_option_id` に一致しないため、`report_usage` 呼び出しがエラーを返す。学習者は権威的な価格オプション ID がどこに記録されるか（元の製品リスティングではなく、受け入れられたバイレスポンスに）、なぜ異なる ID をレポートすることがプロトコルエラーか、正しい回復（バイを再読、受け入れられた価格オプションを抽出、レポートを再送信）を説明。 |

**スコープ注記:** `#2391` が正式な billing reconciliation メカニズムを導入する場合、この障害モードは FM-3 と統合された決済モジュールにマージするかもしれない。`#2391` が閉じたときレビューのためフラグ。

***

## FM-C — ディスカバリー時の adagents.json / brand.json 認可障害

**ステータス:** 元の候補リストにない。新規統合の最も一般的なオンボーディング障害として識別: バイヤーエージェントが `get_adcp_capabilities` 経由で販売エージェントを発見し、OAuth 認証を試み、バイヤーの `adagents.json` が正しい `authorized_agents[]` 関係を宣言しない — または `brand.json` エントリーが署名付きリクエストで提示されたエージェントアイデンティティに一致しない — ため、セラーがトークンを拒否する。

| Module           | Depth           | 評価アプローチ                                                                                                                                                                                                            |
| ---------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **D2**（プラットフォーム） | 解決 / デモンストレーション | ラボシナリオ: バイヤーエージェントが新しく統合されたセラーに認証できない。学習者はセラーのエラーを読み、バイヤーの `adagents.json` で `authorized_agents[]` エントリーをチェックし、`brand.json` エージェントアイデンティティを検証し、解決チェーンをトレース。3 つの一般的な根本原因のどれが適用されるか正しく識別: エントリー欠如、URL 不一致、または期限切れ認可。 |
| S1（副次的）          | 診断 / 説明         | 学習者は `adagents.json` と `brand.json` がディスカバリーと認可フローで何をエンコードするか、なぜ不一致が拒否を生むか、バイヤー側からそれをどう診断するか説明。                                                                                                                    |
| S4（副次的）          | 診断 / 説明         | 学習者は `brand.json` 認可障害がガバナンストークンチェーンとどう相互作用するか — 具体的に、なぜ有効な `authorized_agents[]` エントリーを持たないバイヤーがガバナンスコンテキストトークンを取得できないか、エスカレーションパスは何か — 説明。                                                                       |

***

## オープンアイテムトラッカー

| Item                                     | Status                | ブロック解除                     |
| ---------------------------------------- | --------------------- | -------------------------- |
| Billing reconciliation スキーマ（`#2391`）     | アクティブ / 飛行中（3.1 スコープ） | FM-3 深さ拡大、FM-9 `#2391` フラグ |
| トレーニングエージェントで冪等性カバレッジ確認（`#2346`、`#2367`） | 出荷済み                  | FM-1 作成（ラボ演習拡張のみ検証）        |
| ライフサイクル状態スタック issue（`#1612`–`#1616`）     | オープン                  | FM-5 S1/S5 シナリオ詳細          |

***

## モジュール影響サマリー

以下のテーブルは、どのスペシャリストと practitioner モジュールが作成フォローアップを必要とするか示します。各 ✦ は新しいラボ演習またはデモンストレーション項目; 各 ✧ は新しい試験シナリオまたは相互参照。

| Module | 新しいラボ演習                                                      | 新しい試験シナリオ                                                            | 追加する相互参照                         |
| ------ | ------------------------------------------------------------ | -------------------------------------------------------------------- | -------------------------------- |
| **S1** | FM-1（冪等性状態）、FM-5（スタック `pending_start`）、FM-8（TMP プロバイダーバリアント） | FM-3（配信照合）、FM-6（webhook コンシューマー）、FM-A（payment\_required）、FM-B（価格不一致） | FM-9 → S4、FM-C（adagents.json）    |
| **S2** | FM-2（ローンチ後コンプライアンス — IACET に必須）、FM-5（クリエイティブ同期スタック）          | —                                                                    | FM-2 → S1（ステートマシン相互参照）、FM-9 → S4 |
| **S3** | —                                                            | —                                                                    | FM-8（TMP プロバイダー表面）               |
| **S4** | FM-4（実行中失効バリアント）                                             | FM-9（クロスプロトコル裁定）                                                     | FM-C（adagents.json / ガバナンスチェーン）  |
| **S5** | FM-5（SI セッションスタック / 期限切れ）                                    | —                                                                    | FM-9 → S4                        |
| **D2** | FM-C（adagents.json/brand.json ラボ）                            | FM-7（署名付きリクエスト fail-closed）                                          | —                                |
| **D3** | FM-6（webhook 配信障害）、FM-8（TMP Router 構成）                       | —                                                                    | —                                |
| **B2** | —                                                            | —                                                                    | FM-7（表面 / 認識）                    |
| **B3** | —                                                            | —                                                                    | FM-6（表面 / 認識）                    |
| **C2** | —                                                            | —                                                                    | FM-2、FM-4（表面 / 認識）               |
| **C4** | FM-1（冪等性 解決 / デモンストレーション）                                    | —                                                                    | —                                |
| **A2** | —                                                            | —                                                                    | FM-1（表面 / 認識）                    |