> ## 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.

# サポートリカバリーランブック

> エスカレーション SLA フォローアップ、認証完了リカバリー、ドメイン検証、レジストリクロールリカバリーの運用ランブック。

# サポートリカバリーランブック

これらのランブックは、Addie、認証、レジストリのキューに黙って座るべきでないサポートケースをカバーします。

## エスカレーション SLA フォローアップ

Addie サポートリクエストは、管理エスカレーションダッシュボードとリクエスターのダッシュボードで可視です。SLA 強制ジョブは毎時実行されます。

管理フォローアップルール:

* 緊急のオープンリクエストは 4 時間後に設定されたプライベートエスカレーション Slack チャネルに再サーフェスされます。
* 他のオープンリクエストは 24 時間後に再サーフェスされます。
* 承認済みまたは進行中のリクエストは、更新なしで 24 時間後に再サーフェスされます。
* リクエスターは 24 時間後に可視のダッシュボード更新を受け取り、詳細を追加するか自分でリクエストをクローズできます。

オペレーターチェックリスト:

1. `/admin/escalations` を開く。
2. アクティブなリクエストにフィルターし「Needs pickup」または「Needs update」を探す。
3. 人間が所有するときリクエストを承認または進行中に移す。
4. リクエスターがステータスを必要とするときリクエスター可視のノートを追加する。
5. 修正されたときリクエストを解決し、適切なときユーザーに通知する。

Slack 通知が欠けている場合、`/admin/settings` でエスカレーションチャネルを設定してください。

## 認証完了リカバリー

認証リカバリージョブは 6 時間ごとに実行されます。モジュールまたは認証情報の再照合を終えなかった合格した試行を探します。

自動動作:

* 合格した試行を `learner_progress` に再照合。
* 認証情報の適格性と授与を再実行。
* 自動修復が認証情報を授与できない場合、重複排除されたエスカレーションを提出。

手動修復:

1. `/admin/certification` を開く。
2. 「Attempts needing attention」で、合格した試行に「Reconcile credentials」をクリック。
3. 試行にまだ警告がある場合、learner 詳細パネルを開く。
4. learner、モジュール、Addie スレッドの教育チェックポイントがあるときのみ「Admin completion repair」を使う。
5. ローカル認証情報が存在するが Certifier バッジフィールドが欠けているとき「Issue missing badges」を実行。
6. ノートフィールドにエスカレーション ID または理由を記録。

learner レコードが既にモジュール完了を証明しない限り、重複した手動認証情報を作らないでください。まず learner レコードを修復し、次に認証情報を発行またはバックフィルします。

## ドメイン検証リカバリー

メンバーが WorkOS DNS TXT レコードを公開したがセルフサービス検証パスがブロック、レート制限、または webhook がローカル状態を更新しなかったとき、管理ドメイン検証リカバリーを使います。

これは内部サポートワークフローです。認証された管理ドメインツールまたはプライベート運用ランブックを使ってください。公開ドキュメントは、管理エンドポイントパス、bearer トークン例、WorkOS チャレンジトークン処理を公開すべきではありません。

レジストリ/ドメインエスカレーションを解決済みとしてクローズする前に、AAO UI だけでなくレジストリ状態を確認してください:

* ターゲットドメインが意図された組織のローカル `organization_domains` 行を持つ。
* その行が `verified=true`。
* サポートリクエストが会社組織用のとき、行がメンバーの個人ワークスペースに添付されていない。
* レジストリが該当ドメインについて `member:null` をもはや返さない。
* 要求されたエージェントホスト名が登録組織の検証済みドメイン行でカバーされる。

WorkOS が検証済みドメインを示すがローカル行が欠けている、古い、または別の組織に添付されている場合、意図された組織の WorkOS-domain 再照合アクションを実行します。これは WorkOS を真実の源泉としてリプレイし、ドメインを `organization_domains` にミラーし、検証済みドメインのブランドレジストリ同期を再実行します。DNS 検証をバイパスしません。WorkOS はまずドメイン/チャレンジを知る必要があります。

個人ワークスペース/会社組織分割インシデントについては、まず読み取り専用の管理プレビューを実行します:

* 内部運用ランブックまたは管理 UI からプライベートなドメイン分割プレビューを使う。
* プレビューは WorkOS 状態、ローカル `organization_domains`、メンバープロファイル存在、組織メンバーシップ、次の安全なアクションをレポートする。
* プレビューが WorkOS が既に会社組織のドメインを検証すると言うときのみ再照合アクションを実行。
* 課金が個人ワークスペースに添付されているように見える場合、人間レビュー後に別の Stripe 顧客プレビュー/確認ワークフローを使う。ドメイン修復パスで課金を動かさない。

結果:

* `success: true`: WorkOS が DNS を確認しローカル `organization_domains` が再照合された。
* `still_pending`: WorkOS がまだ TXT レコードを見られない。メンバーにレコード名とトークンを確認するよう依頼。
* `no_challenge`: メンバードメイン設定または管理ドメインツールから新しいドメインチャレンジを発行。

DNS 伝播は通常数分かかりますが、古いプロバイダーキャッシュはより長く続きうる。数秒ごとにリトライし続けないでください。DNS レコードを修正し伝播後にリトライしてください。

リクエストが無効または疑わしい場合、ノート付きで `wont_do` としてクローズします。ローカルドメイン行が欠けている、未検証、または誤った組織に添付されている間、レジストリ/ドメインエスカレーションを `resolved` とマークしないでください。

## レジストリとハートビートリカバリー

メンバーが `adagents.json`、`brand.json`、認可、またはエンドポイントヘルスを修正した後、これらのトリガーを使います。

パブリッシャーとブランドのクロールリクエストは、認証されたメンバーまたは管理リクエストと JSON `domain` ボディを要求します:

```bash theme={null}
curl -X POST "https://agenticadvertising.org/api/registry/crawl-request" \
  -H "Content-Type: application/json" \
  -b "$SESSION_COOKIE" \
  --data '{"domain":"example.publisher"}'
```

期待される受理レスポンス:

```json theme={null}
{ "message": "Crawl request accepted", "domain": "example.publisher" }
```

ブランドマニフェストについては、同じボディ形状を使います:

```bash theme={null}
curl -X POST "https://agenticadvertising.org/api/registry/brand-crawl-request" \
  -H "Content-Type: application/json" \
  -b "$SESSION_COOKIE" \
  --data '{"domain":"example.brand"}'
```

期待される受理レスポンス:

```json theme={null}
{ "message": "Brand crawl request accepted", "domain": "example.brand" }
```

エージェントリフレッシュとハートビート再キューは、エンコードされたエージェント URL を使います。呼び出し元はエージェントを所有するか AAO 管理者でなければなりません。

```bash theme={null}
AGENT_URL="https://seller.example/adcp"
ENCODED_URL="$(node -e 'process.stdout.write(encodeURIComponent(process.argv[1]))' "$AGENT_URL")"

curl -X POST "https://agenticadvertising.org/api/registry/agents/$ENCODED_URL/refresh" \
  -b "$SESSION_COOKIE"
```

リフレッシュは最新のプローブ結果、または監視が一時停止、レート制限、プローブ失敗の場合 `409`、`429`、`502` エラーを返します。

エージェントが通常のモニターによって確認されるべきとき、同期プロービングなしでハートビートをキューイング:

```bash theme={null}
curl -X POST "https://agenticadvertising.org/api/registry/agents/$ENCODED_URL/monitoring/requeue" \
  -b "$SESSION_COOKIE"
```

期待されるレスポンス:

```json theme={null}
{ "requeued": true }
```

エンドポイントまたはケイパビリティ修正後の特定エージェントにはリフレッシュを使います。パブリッシャー認可変更にはクロールリクエストを使います。