spider-king

スパイダーキング

ミッション

敵対的な Web クライアントを、安定したプロトコルコレクターに変えます。

これは純粋な Web プロトコル解析のスキルであり、ブラウザー自動化のスキルでも、APK／ミニプログラムのリバースエンジニアリングのスキルでもありません。ブラウザーツールは、Web の証拠を収集する場合にのみ使用してください。生の HTTP と、用途を絞ったローカルの署名、ブートストラップ、デコード、またはトランスポート用ヘルパーを提供してください。主な対象が APK、ネイティブアプリ、またはミニプログラムの場合は、Web 向けのデュアルブラウザによる初回調査を捏造せず、対象外であると明記してください。

必須事項

• 新しいタスクでツールを選択する前に、必ずこのファイルと references/mcp-routing-playbook.md の Auto Judge Card を実行し、受付内容、ブラウザーが必要かどうか、使用するベースラインホスト、使用するデバッガートレース手段（js-reverse および／または silent-value-capture）を決定してください。先にツールを開いてから、後付けで正当化してはいけません。
• 新しいウェブターゲットを live-target に分類した場合、ページ／ランタイムを理解したと主張する前に、両方の役割について、順序どおりに証拠を取得してください。順序は fingerprint-baseline、次に debugger-trace です。これより限定的な主張が許されるのは、references/startup-triage-playbook.md の transport-only direct-endpoint exception のみです。これは、厳格なネガティブコントロールとビジネスオラクルのゲートを通過した後に限り、ページ／ランタイムを理解したと主張せず、完全に一致する1つのエンドポイント用のコレクターを受け入れることができます。
• デフォルトの手段は、ベースラインに chrome-devtools、次にデバッガートレースに js-reverse です。DP／イニシエーターの作業がすでに必要な場合は、js-reverse が1つのホスト上で両方の役割を担ってもかまいません。Chromeをもう1つ起動してはいけません。launch と attach のどちらかを記録し、launch を attach と偽ってはいけません。フィンガープリントへの圧力が実証された場合、またはクリーンなベースラインの取得に失敗した場合に限り、ベースラインホストを Camoufox または別の管理プロファイルに切り替えてください。通常の低リスク作業や、CDP の navigator.webdriver が true であることを理由に、Camoufox をデフォルトで使用してはいけません。
• debugger-trace は、js-reverse による相関したイニシエーター／ミューテーションの証明、references/silent-value-capture-playbook.md に沿った相関済み silent-value-capture カード、またはその両方で満たしてください。attach が利用可能な場合は js-reverse を優先してください。
• attach が利用できない場合は、debugger_attach_gap を記録し、バックエンドが利用可能であれば、役割を放棄せず silent-value-capture でデバッガートレースを続行してください。必要なサイレントバックエンドも利用できない場合は、silent_value_capture_gap を記録し、オフラインで続行するか、成果物の形態を縮小してください。
• silent-value-capture はベースラインの代わりにはならず、compact-replay または collector の成果物を担うこともありません。APK、ネイティブアプリ、ミニプログラムが主対象のタスクは対象外です。形式的な手順としてブラウザーとのペア証明をでっち上げてはいけません。必要な役割を利用可能な手段で満たせない場合は、ライブターゲットを理解したと主張する前に、妨げとなる要因を報告してください。
• ブラウザーとエンジンキャプチャの証拠収集では、ターゲットごとに直列で進めてください。TARGET_ACTIVE にできるブラウザーまたはエンジンキャプチャのファミリーは同時に最大1つです。また、並列ツールバッチにターゲットの所有者を2つ含めてはいけません。references/tool-playbook.md の引き継ぎゲートを適用してください。サイレント値のエンジンキャプチャに許可を与える前に、ベースラインを一時停止するか保持してください。再現不能な一意の状態は、クリーンアップのために破棄せず、RETAINED_EXCEPTION で保持してください。
• compact-replay と collector では、ブラウザーを使わない Python の実行経路を提供してください。最終的なリプレイ経路やフォールバックに、ブラウザー自動化、Playwright、Selenium、CDP によるページ操作、ページコンテキストからの fetch、ブラウザープロファイル、手動のブラウザー状態、silent-value-capture バックエンド、エンジン計装を使用してはいけません。
• HTTP、オーケストレーション、解析、再試行、永続化、出力には、純粋な Python を優先してください。検証済みの Python 移植によるリスクがより高い場合に限り、JS／WASM を小さなローカルヘルパーとして残してください。ローカルのブートストラップはホストのセマンティクスをエミュレートしてもかまいませんが、ライブ HTTP は Python が担い、レポートにはブラウザー／ランタイムを使用しない実態を記載してください。リプレイの識別情報は、インストール済みの curl impersonate の Chrome メジャーバージョンに固定してください。それより低い impersonate のメジャーバージョンに、新しいライブ Chrome のメジャーバージョンをコピーしてはいけません。また、その差異を理由にリスク制御のリバースを再起動してはいけません。
• ページネーション、並行処理、送信、ランタイムの縮小に進む前に、安定したビジネスリクエストを1つ復元してください。リスク制御が未知の場合は、まず拒否されたリクエストをリバースしてください。未検証の追加ルートは1ラウンドにつき最大1つとし、省略によってオラクルが変化した場合に限って試してください。
• ローカルの JS／WASM／SDK ヘルパーをブラウザーを模したワークフローで繰り返し呼び出す場合、プロセス／VM／コンテキストの同一性と隠れた可変状態も変動要素として扱ってください。ヘルパーを縮小または拡張する前に、永続ワールドと新規ワールドの挙動を検証してください。自己無効化するインスタンスをページャーとして再利用してはいけません。
• 各結論は、宣言した成果物の形態に必要な証拠で裏付けてください。現在のライブ環境で受け入れられると主張する場合に限り、ライブリプレイの反復を要求してください。機微な生の値はローカルに保持し、認証情報、トークン、個人データ、Cookie の値をチャット、レポート、バージョン管理から必ず削除してください。
• ローテーションする状態は、書き込み元、スロット、スコープ、有効期限、更新経路を検証する前にハードコードしてはいけません。ブートストラップに依存するフローでは、セッションをまたいだ再利用が証明されるまで、1つのセッションチェーンを維持してください。
• 宣言した形態が機能固有のゲートを通過するか、実際の外部要因による妨げが証明されるまで停止してはいけません。evidence や local-proof を collector と呼んではいけません。また、自動化が未完成であることを、一時的な collector と偽ってはいけません。
• compact-replay と collector の成果物には、通常はプロジェクトルートの main.py または collector/main.py とし、ターミナル引数を必須としない、PyCharm で右クリックして実行できる Python エントリーポイントを含めてください。要求された成果物が実行可能コードでない限り、evidence と local-proof にエントリーポイントは不要です。
• 現在のツールレジストリ／スキーマで利用可能と確認された MCP ファミリーのみを対象にしてください。ディスク上のソースツリーは、利用可能であることの証明にはなりません。パッシブな通信ストアは TARGET_ACTIVE と共存できますが、ライブ環境での初回証拠収集の代わりにはなりません。また、compact-replay／collector では、ブラウザーランタイム、ページ操作、プロファイル、キャプチャバックエンド、エンジン計装を使用しないでください。
• ゲートファミリーのラベルを確定したり、ランタイムの範囲を広げたり、インストール済みの専門家に作業を引き渡したりする前に、references/evidence-corroboration-gate.md を確認してください。ステータスコード、Cookie 名、トークン名、古いメモ、または一見妥当なヘルパーの出力は、いずれも仮説にすぎません。
• 信頼できる陽性サンプルが通過し、ローカルの経路が失敗した場合は、サンプルの衛生確認後に references/positive-sample-ablation-playbook.md を使ってください。進行中の失敗で未解決のものには、コレクターが完成したかのように示すのではなく、references/failure-surface-taxonomy.md を使って名前を付けてください。行き詰まった場合は、そのファイルから Stuck の次のアクションを 1 つ選んでください。裏付けのない追加経路をまとめて追加しないでください。

失敗を示す反例については、references/anti-patterns-playbook.md を読んでください。結果をパッケージ化する前に、該当する機能ゲートのみを references/delivery-gate-playbook.md に従って適用してください。段階的な縮退：import／NameError はこちらのバグです（stderr にアラームを出します）。外部のタイムアウトにはフォールバックします。主要な応答は stderr に出力し、stdout は機械可読な JSON に保ってください。

軽量ディスパッチ

最初の動きを小さく保つため、内部では以下のラベルを使ってください。通常のユーザー向けの返信で、厳格な機械用ヘッダーを無理に使う必要はありません。

形状	成果物
evidence	実際のリクエスト、起点、状態ソース、変更箇所、または明確なブロッカー
local-proof	固定ベクトル、デコード済みサンプル、復元済みソース、またはライブ通信なしで呼び出せるヘルパー
compact-replay	実証済みリクエストに対する、範囲を限定した右クリック実行可能な再現
collector	範囲を限定した、繰り返し実行可能なブラウザー不要の Python コレクター

ユーザーの要望に応える最小の形状をデフォルトにしてください。ユーザー提供の HAR、パケットキャプチャ、リクエストテキスト、JS／WASM、Cookie／トークンのサンプル、固定ベクトル、または既存のプロジェクト成果物は、evidence または local-proof として扱い始めてください。ライブターゲットに関する形式的な手順を満たすためだけに、ブラウザーを起動しないでください。evidence と local-proof では、デュアルロールのブラウザー手順を自動開始してはなりません。URL だけが示されていても、ブラウザーナビゲーション、ライブ再現、書き込み、アカウント／セッションの使用、依存関係のインストール、または広範な収集は許可されません。

経路名は、ゲートファミリーではなく、現在その機能を担うものを表します：evidence-reuse、chromium-recon、browser-hook、static-ast、env-patch、iv8-local-runtime、verifier、transport、pure-python-rebuild、または python-collector。証拠または明示されたブロッカーが返されるまで、1 つの経路を実行してください。複数の経路が妥当そうな場合は、より小規模なオフライン経路を先に選び、エスカレーションを正当化する証拠を記録してください。

いずれかの経路がファイルへの書き込み、ライブ通信の送信、ターゲット提供コードの実行、アカウント／セッション状態の使用、依存関係のインストール、またはランタイム状態の変更を行う前に、references/provider-work-order.md の簡潔な契約を適用してください。

迅速なルートと担当範囲

目的がすでに絞られている場合は、対象不明の調査を最初からやり直さず、目的に特化したルートを使用してください。

現在の目的	ルート
境界が既知の場所に貼り付けて使えるブラウザー観測 Hook	references/profiles/browser-hook-snippets/index.md
提供された JS ファイルを構造化 Babel AST で復元する	references/profiles/static-ast/index.md
Node/VM で既知のエントリ、呼び出し、固定されたブラウザー出力を扱う	references/profiles/env-patch/index.md
JSVMP/SDK は読み込まれるが、XHR または fetch の署名が行われない、あるいはパスに依存する	references/profiles/env-patch/references/jsvmp-interceptor-contract.md。肯定・否定のパス制御で有効化を証明してください。CDP の navigator.webdriver が true の場合は、Camoufox の前に initScript で設定可能なプロトタイププロパティを削除してください。リストを伴う XHR がない状態の HTML のゼロ値はデータではありません
固定トレースに基づく純粋な Python での署名・デコーダー再構築、または回帰テスト	references/pure-python-rebuild-playbook.md
エンドツーエンドのコレクターが不明、または複数レイヤーにまたがる	以下の Startup Gate + Universal Reverse Loop を続行してください
エントリ／呼び出しチェーンの場所のみ	専用のリバースエンジニアリングスキルが利用可能ならそれを使用し、なければ chrome-devtools / js-reverse の initiator 証拠を使用してください
Python + iv8 ランタイムが明示的に必要	iv8 スキルが利用可能なら使用してください。利用できない場合は、満たせない制約を報告し、ユーザーが代替を承認した後にのみ env-patch／ローカルヘルパーを使用してください
導入済みの特化スキルが、裏付けのあるブロッカーに狭く該当する	capability snapshot にその特化スキルが記載され、かつ両サーフェスで裏付けが確認できる場合に限り引き継いでください。Spider は引き続き補助的なランタイム支援として扱います。特化スキルが導入されていない場合は汎用ループを続行し、系統別の近道を作らないでください
すでに取得済みの HAR、Reqable の履歴、または説明・リプレイ案の作成対象となるリクエストテキスト	ブラウザーを開く前に references/mcp-routing-playbook.md を読んでから、evidence-reuse を使用してください
証拠取得前にフィンガープリントまたは管理対象プロファイルが必要	フィンガープリント圧力が高いと自動判定した場合は、Camoufox／管理ホストのベースラインを使用し、デバッグエンドポイントが利用可能なら attach／js-reverse への引き継ぎを行ってください
HAR／リクエスト／JS／Cookie のサンプルが十分にあり、新たなライブ証拠が不要	artifact-only / evidence-reuse を使用してください。形式だけのために Camoufox、Chrome、js-reverse を開かないでください

特化プロファイルのルール：

• browser-hook、static-ast、env-patch は、変更が元に戻せ、ログで秘密情報が安全に扱われる場合に限り、artifact-only または既知の境界であることが証明された作業について、対象不明時の手続きを省略できます。構造のみを対象とする AST 検出は、提供されたソースから開始できますが、動作に関する主張には固定サンプルが必要です。新たな操作が必要な場合は live-target に分類し、逐次的な役割の証拠を必須とします。ブートストラップ、セッション、トランスポート、デコード、ページネーションのいずれかの状態が不足している場合は、プロファイルを終了して Universal Reverse Loop に移行してください。
• プロセスの成果物は、実行対象のプロジェクト内の js_reverse_cache/tasks/<task-id>/（task.json、network.jsonl、runtime-evidence.jsonl、使用時の silent_value/、handoff.json、fixtures/、report.md）に保存してください。納品の証明は analysis/proof_manifest.json および関連する分析ファイルに残してください。このスキルのディレクトリにタスクの秘密情報を書き込まないでください。最初の保存または昇格の前に references/project-artifact-contract.md を適用してください。

自動ルートカード

ツールを選ぶ前に使用してください。納品に関するゲート要件が緩和されることはありません。シグナルの完全な表とホストのアップグレード規則は、references/mcp-routing-playbook.md および references/startup-triage-playbook.md に記載されています。

自動判定カード（シグナル駆動）

この順序で判定し、最初の対象操作の前に分岐を記録します。

1. 受付：オフラインサンプルが十分にあり、ライブでの受け入れ確認が不要 -> artifact-only；URLのみ、または新しいページ／セッションでの証拠が必要 -> Web の live-target；対象／環境／目標が同じ -> continuation；APK／アプリ／ミニプログラムが主対象 -> 対象外。
2. ブラウザー／エンジンが必要か？：純粋なオフラインでの説明／復元／固定ベクトル作業 -> ブラウザー不要；現在のリクエスト／ページ／通信の証拠が必要 -> ベースラインホスト；既知の境界値またはイニシエーターの作業が必要 -> ベースライン引き継ぎ後にデバッガートレースを実施し、js-reverse および／または silent-value-capture を使用します。
3. ベースラインホスト：通常の低リスクな調査では、デフォルトで chrome-devtools を使用します。DP／イニシエーターの作業がすでに必要な場合は、js-reverse にベースラインを担当させ、1つのホストでデバッガートレースを行います。2つ目の Chrome は起動しないでください。フィンガープリントの問題、またはクリーンなベースラインを取得できない場合に限り、Camoufox／管理対象ホストに切り替えます。通常の低リスク作業で Camoufox をデフォルトにしないでください。
4. デバッガートレースの手段：候補となるビジネスリクエストが見つかったら、役割を放棄せずに手段を選択します。
   • アタッチ可能 -> デフォルトでは、順次引き継いだ後、現在のホストで js-reverse を使用します。アタッチであるかのように装わず、launch モードを記録します。
   • 切り替え条件（フックがオブザーバーの動作を妨げる、体系的な取りこぼし、固定入力ベクトルが必要、JSVM の公開境界値が不足、ページワールドに対するページの自己チェックが不信を示す）があれば -> 直ちに silent-value-capture を有効にします。先にページワールドのフックを広げないでください。
   • アタッチ手段がない -> debugger_attach_gap を記録します。利用可能なサイレント値バックエンドがあれば、silent-value-capture でデバッガートレースを続行します。なければオフラインで続行します。
   • 必要なときにサイレントバックエンドがない -> silent_value_capture_gap を記録し、オフラインで続行するか、デリバリーの形態を下げます。正確な直接エンドポイントでは、references/startup-triage-playbook.md のすべての開始条件が個別に証明されている場合に限り、トランスポートのみの例外を利用できます。
5. 次のいずれかを満たせば、デバッガートレースの役割は完了：js-reverse による相関済みのイニシエーター／変更点の証明、1つ以上の相関済み fixed_input_ready サイレント値カード、またはその両方。オペコード／プログラム全体のトレースより、公開境界の入出力を優先します。protobuf の serializeBinary と wasm の encode(i32,i32) は対象に含まれます。キャプチャバックエンドを compact-replay または collector に配置しないでください。
6. ブラウザー／エンジンを早めに終了する：実際のリクエスト、変更点、再構築手順が証明できたら、ブラウザー MCP とサイレント値バックエンドを終了し、その後は純粋な Python で仕上げます。

ライブ時のデフォルト手順

capability snapshot (browser mode launch|attach|unavailable, curl impersonate max chrome, silent_backend)
  -> Auto Judge
  -> fingerprint-baseline (chrome-devtools default; js-reverse may own both roles when DP is already required; Camoufox/managed host only on pressure)
  -> sequential handoff (park/retain baseline)
  -> debugger-trace means (branch, not a linear tail):
       attach? yes -> js-reverse first
                 + silent-value-capture on upgrade triggers
       attach? no  -> debugger_attach_gap
                 + silent-value-capture if backend available
                 else offline continue
  -> offline rebuild + delivery gate

起動ゲート

詳細な分析の前に、このゲートを完了して報告します。拡張チェックリストは references/startup-triage-playbook.md にあります。

0. 受付モード

ツールを使用する前に、次のいずれか1つのモードを宣言します。

• live-target：現在の Web ページ／エンドポイントについて、新しいブラウザーおよび通信の証拠が必要です。役割の順序に従って進めます。
• artifact-only：保存済みのリクエスト／ソース／トークン／サンプルのみを使用します。ライブでの受け入れ確認は未証明として扱います。
• continuation：対象／環境／目標が同じです。現在のゲートを再利用し、変更された部分のみを再確認します。

1. 環境とツール

インストール済みの MCP ファミリー、ブラウザーモード（launch|attach|unavailable）、既知のデバッグエンドポイント、scripts/check_reverse_env.py から取得した curl の偽装可能な最大 Chrome バージョン、任意のサイレント値バックエンドの利用可否（silent_backend=available|absent）、任意のパッシブ通信ストアをスナップショットとして記録します。確認済みのツールのみを使用します。任意のファミリーまたはバックエンドが不足している場合は、形式的な手順ではなくギャップとして扱います。silent_backend=absent の場合、キャプチャバックエンドを調査しないでください。アタッチ／js-reverse にギャップがあった後は、オフラインで続行するか、デリバリーの形態を下げます。

2. ファミリーのトリアージ

現在の証拠に基づいて、主要なゲートファミリーを最小限の1つ（signer-gated、transport-gated、verifier-gated、decode-gated、session-gated）に分類し、その経路のみを開きます。

3. デリバリーの意図

宣言した形態（evidence、local-proof、compact-replay、collector）を明示し、そのゲートで停止します。不完全な自動化を一時的なコレクターとして銘打たないでください。

最小限のインテーク

ユーザーから対象ページまたは API の URL、サイトと収集目的、キャプチャしたリクエスト、JS または WASM のサンプル、Cookie またはトークンのサンプル、あるいはパケットキャプチャが提供されたら、すぐに開始します。ブラウザーの証拠が必要かどうかを判断する前に、インテークモードを選択します。

実装に影響する不足情報だけを尋ねます。対象フィールド、収集範囲、出力形式、ログインの要否、重複排除、再開、増分同期が必要かどうかです。

読み取り専用の証拠確認やローカルでの検証を求められた場合は、不足しているサンプル、ベクトル、トリガー操作、またはソースパスだけを尋ねます。次のアクションで書き込み、対象コードを実行、または対象に接続する段階まで、プロジェクトルート、保持期間、ライブ再生、リクエスト予算に関する質問は保留します。

compact-replay または collector を実装する前に、実装方法が複数残っている場合、または次のステップで、現在確定しているランタイム、依存関係、書き込み可能範囲、ライブ権限の境界を広げることになる場合は、references/provider-work-order.md の条件付き実装ブリーフを使用します。このブリーフを、evidence、local-proof、またはユーザーがすでに選択した実装方法に対する必須の承認手続きにしないでください。

共通リバースループ

簡潔な実行マップとして references/workflow-overview.md を、ツールの選択には references/tool-playbook.md を使用します。以下のフェーズ番号だけをフェーズ番号体系として使用します。複数段階の安定化チェックリストと段階別フィールドのチェックリストは横断的なものであり、そのファイルに対応付けられています。

フェーズ 0：フィンガープリント

• オブザーバー効果が起こり得る場合は、大規模なフックを仕掛ける前にクリーンなベースラインを記録します。おとりと実際のエンドポイント、トランスポートとアプリケーションのゲート、表示されるパラメーターとラッパーによる書き換え、ブートストラップとデータ API、単一のリクエストと状態を持つトランスクリプト、HTML のプレースホルダーのゼロ値とリスト取得用 XHR のデータ、ダミーの HTTP 系エンドポイントと WebSocket またはテキストチャネル、chrome-devtools の HTTP ログと WebSocket フレーム、ビジネス JSON ではない WebSocket のプレフィックスフレームとビジネス JSON を区別します。
• プレーンな JSON、GraphQL、WebSocket、protobuf、バイナリエンベロープ、暗号化されたレスポンス、グリフマッピング、CSS 内の HTML スプライトまたはオフセットグリフ、JSVMP、ホストにバインドされたランタイムを早期に特定します。オペコードより protobuf の serializeBinary / wasm の encode を優先します。バイナリは UTF-8 ダンプではなく、16 進数としてキャプチャします。
• 最大のバンドルダンプではなく、次に必要な最小限の証拠を選びます。

フェーズ 1：実際のリクエストを検証する

• リダイレクトとラッパー／互換ページをたどり、エントリー、ブートストラップ、リスト、詳細、送信、検証、ウォームアップ、テレメトリー、ダウンロード、リスク制御、非同期のエクスポート／レポートの各ルートを個別にマッピングします。
• 正確な URL、メソッド、クエリ、ボディのバイト列、ヘッダー、送信される Cookie ヘッダー、レスポンスの形式、イニシエーターをキャプチャします。
• ページネーションの切り替えと、チャレンジを受けたドキュメントの再生を、プロトコル契約の一部として扱います。
• 同じ直接エンドポイントと業務入力で、クライアントのトランスポートだけが異なる場合は、署名や環境の調査に入る前に、この段階で references/transport-pre-gate-playbook.md の同一入力マトリックスとネガティブコントロールを実行します。references/startup-triage-playbook.md にある transport-only direct-endpoint exception の条件をすべて満たす場合は、そのエンドポイントに限って受け入れ、ブラウザー役割の不足は明示したままにします。

実際の業務パスで確認できたリクエストを 1 件提示します。

フェーズ 2：変化する状態を切り分ける

変更モデルが判明したと判断する前に、references/minimal-verifiable-facts-playbook.md にある静的解析の 6 つの質問に回答してください。

変化する要素をすべて分類します。タイムスタンプ、ノンス、署名付きクエリまたはボディ、ローテーションするヘッダーまたは Cookie、ラッパーフィールド、操作名、カーソル、ブートストラップアーティファクト、デコードキー、グリフマップ、セッションシークレット、プロファイルベースライン、スパースデルタ、カウンター、ハートビート、経過時間への依存、メディアキー、ページ例外、アカウント状態、ホストのセマンティクスが対象です。 同じローカルランタイムが複数のリクエストまたはステップを処理する場合は、ヘルパーの有効期間、VM／コンテキストの同一性、モジュールインスタンス、クロージャ、キャッシュ、キュー、遅延初期化、呼び出し順序マーカーも分類します。カウンター／Cookie の再現だけでは、状態の継続性を証明できません。 サーフェスがエクスポート系または署名付きオープンプラットフォーム形式の API の場合は、再生成の設計前にフィールドをビジネス、静的アプリ、サーバー発行、リクエストごとの動的なクラスに分類します。これとは別に、ソースクラス（fixed／plaintext／local-algorithm／server-issued／risk-interactive）と所有者クラス（python-owned／host-owned／server-owned）を付与します。ソースを所有者として扱わないでください。

Cookie の由来を立証し、サーバー発行のアーティファクトとローカルで生成された埋め草を区別します。セッションへの参加に関するページ上の説明は、ワイヤー上の挙動で確認されるまでは仮説としてのみ扱います。ログインが最初のゲートにすぎない場合は、エクスポート前に最終的な ID の再読み込みでテナント、ロール、データ範囲を検証してください。references/multi-context-session-playbook.md を参照してください。保存された Cookie jar の状態と、それらが異なる場合の正規の送信 Cookie ヘッダーは分けて管理します。ブラウザーで成功したパケットに対するビジネスリプレイが失敗する場合は、署名処理をさらに深掘りする前に、references/session-contract-playbook.md を使ってリクエスト契約を復元してください。

フェーズ 3：正規の変更点を特定する

次の順序で追跡します。

1. トランスポートラッパー、インターセプター、beforeSend、fetch、Ajax、XHR、ワーカー、またはメッセージ境界。ワイヤー上のデータを固定します。空の beforeSend IIFE は署名処理ではありません。
2. ブートストラップスクリプトとインラインペイロード
3. 公開されたヘルパーと返される子オブジェクト
4. WASM エクスポート、または内部のシリアライザー、パッカー、署名処理、デコーダーのプリミティブ
5. サーバーから返されるチャレンジとレスポンス側の更新フィールド
6. フレームシリアライザー、Protocol Buffers パーサー、ハンドシェイクトランスクリプト、鍵スケジュール

正規の変更点とは、ビジネスコードがプレースホルダーを作成する場所ではなく、ワイヤー形式のペイロードが実際に変化する箇所です。

名前付きダイジェストまたは名前付きの AES/GCM/WASM エクスポートがある場合は、固定入力で動作を立証し、標準ライブラリを信頼する前にフレーム、パックされた鍵のレイアウト、内部フィールドの PRNG を固定します。UI や関数名よりも、環境によって選択されるダイジェスト定数とブラウザーブランチを優先し、references/crypto-patterns.md を参照してください。ALU トレースに 0x9E3779B9 が現れる場合、または VM が 4 文字のリトルエンディアンブロックをパックする場合も、同じファイルを参照してください。

フェーズ 4：オフラインで再構築する

• ミント形式のトークン生成後にマルチサーフェス検証器が拒否する場合は、まず形態／状態チェーンをアブレーションし、day-card とキルスイッチ K1-K8 を埋め、ゴールド類似度を進捗と誤認しないでください（references/verifier-morph-and-state-chain-playbook.md）。
• 同じファミリーの解決済みスケルトンがある場合は、まずホスト／パス／状態チェーンを移行してください（references/case-reuse-playbook.md）。動作の壁に達したメインラインを再開しないでください。
• 一度に 1 段階ずつ進めてください：固定入力のパリティ、狭い境界の観測、純粋なローカル再現、狭いホストのブートストラップ、そして証拠に裏付けられたホストサーフェスのパッチ適用。段階数がブラウザの経路と異なる場合は、アルゴリズムを書き換える前に references/workflow-overview.md のマルチステージ安定化ルールに従ってください。各段階では、references/reproducible-evidence-playbook.md の first_divergence に該当する最小単位だけにパッチを適用し、継続時には証拠の鮮度を再検証してください。
• ヘルパーが繰り返し呼び出される場合は、ブラウザー API を追加する前に references/runtime-state-continuity-playbook.md の最小継続性マトリクスを実行してください：永続ワールド 1 つ、新規ワールド 1 つ、そして可能な限り他の入力を一定に保った明示的状態のアブレーション 1 つです。
• エスカレーションの前に、最後に証明された成果物、正確な未解明点、次の段階が最小である理由、ブラウザーを使わない配布を維持する方法を記録してください。
• ランタイム、パッチ適用範囲、またはトランスポートプロファイルを拡大する前に、references/escalation-ladder-playbook.md を読んでください。
• トランスポートの証拠から、最も近い保守対象バックエンドでは許可されたブラウザープロファイルを表現できないことが明らかになった場合は、ルート固有のネイティブアダプターを構築する前に references/native-transport-profile-playbook.md を読んでください。
• 不透明なステージング済み成果物がキャプチャされたランタイム入力に依存する場合は、references/opaque-runtime-profile-playbook.md を読んでください。1 回のアトミックな実行を維持し、ステージごとに移植して、アルゴリズムによる生成とスナップショット駆動の生成またはプールの再生を区別してください。非決定的なフィード（Math.random / Date.now / canvas / audio）はセッションに依存します。古いフィードに対して新しいセッションのスクリプトを決して実行しないでください。
• シリアライズ、フィールドスロット、フレーミング、JSONP コールバック、区切り文字、圧縮、暗号、デコード順序を正確に維持してください。
• JS ダイジェストを Python に移植する場合は、ライブ再生の前に、固定したプリイメージを使って uint32 の切り捨て、ROTL のエッジケース、バイトごとのパッキングマスクを検証してください。
• 文字列テーブルを多用するバンドルでは、まず非実行型の references/profiles/static-ast/index.md 検出器と保守的な書き換えから始めてください。その後、深い整形処理に進む前に、2 パスの書き換えでデコーダーをオフラインで復元してください。references/obfuscation-guide.md と references/offline-inline-deob-playbook.md を参照してください。
• ページ、キーワード、本文、リファラー、タイムスタンプ、またはセッション状態によってリクエスト形式の成果物が変わる場合は、リクエストループ内で再生成してください。
• 永続ワールドと新規ワールドで動作が異なる場合は、証明済みのシーケンスに対して狭いローカルヘルパーを稼働させ続け、初期化、存続期間、リセット、タイムアウト、クリーンアップ、ランタイムバージョンを記録してください。永続ワールドが最初の encrypt 後に自己無効化する場合は、インスタンスを消費した状態でページングするのではなく、その encrypt を分離するか移植してください。呼び出しごとのサブプロセスを中立的な実装詳細として扱わないでください。

フェーズ 5：再現性とスケーラビリティを実証する

references/workflow-overview.md では、このフェーズを フェーズ 5：納品（再現性の実証と納品パッケージ化）としてまとめています。同じフェーズ番号であり、別のシステムではありません。

• 固定入力または固定ペイロードのテストベクトルを使って、ヘルパーとデコーダーを検証します。
• ランタイムのスケーリングまたは縮小の前に、1 つのセッションチェーンで、新規の単一ページのリプレイを 1 回成功させます。
• ライブリプレイを少なくとも 2～3 回繰り返すことを必須とします（ハードゲート指標で安定性を主張する場合、検証ゲートでは 10～20 回）。ヘルパーの読み込み成功やトークンらしい値は、受け入れ条件にはなりません。
• フィンガープリント／デバイスの付随要素を伴う検証ゲート付きフローでは、references/device-trust-sidecar-playbook.md を読み、納品レベル L0～L3 を明記します。ローカル SDK ランタイムのパッチ適用については、references/local-sdk-env-patch-playbook.md を参照してください。
• 検証ゲート付きフローでは、必須の付随要素、同一環境での共有状態、1 つのプロトコルプロファイル、実際のリクエストタイミング、最終的な検証ロジック、および最初の下流コンシューマーを、1 回の完全なラウンドで実証します。上記の厳格な順序を維持し、リトライを増やす前にアブレーションマトリックスとローカルのエラー意味マップを記録します。
• 検証ゲート付きフローでは、良好なサンプルの衛生状態を実証します。クリーンな成功サンプルは、汚染された自動化による失敗よりも優先されます。環境リスク（出口 IP、自動化の痕跡、連続失敗）は、トラック品質とは別の失敗要因です。ローカルリプレイがクリーンな成功サンプルと一致しない場合は、references/failure-surface-taxonomy.md で分類し、references/positive-sample-ablation-playbook.md を使って各レイヤーを切り分けます。
• 次のページまたはカーソル、ルートの切り替え、更新動作、フィールドの完全性、および関連する権限境界を実証します。
• 非同期エクスポートでは、作成前のタスク ID スナップショットと条件一致を用いて作成を実証し、ポーリング対象のタスクを切り分けます。ダウンロードされた列が要求したフィールドより少ない場合は、永続化をブロックします。詳しくは、references/async-export-job-playbook.md を参照してください。
• 生のサンプルは早い段階で保存し、想定外のレスポンス形式があれば明確に失敗させます。

実装契約

• クライアント、設定、ブートストラップ、ヘッダーと Cookie、署名、エンベロープ、デコード、抽出、リトライ、ストレージ、テストを、それぞれの関心事ごとに分割します。
• 書き始める前にタスクプロジェクトを 1 つ決め、動的な証拠は js_reverse_cache/tasks/<task-id>/ 配下に保存します。OS の一時フォルダー、デスクトップのドロップフォルダー、スキルディレクトリ、非表示のブラウザープロファイルを主な保存先として使用しないでください。
• 安定した足場は、変動するキャプチャーや生成されたランタイムの Blob と分けて管理します。
• サーバー発行の状態とローカルで計算された状態は、別々にカタログ化します。
• ブートストラップに依存する取得とリプレイは、再利用が実証されるまで同じセッションチェーン上で行います。
• UA／Client-Hints、Cookie／ストレージ、フィンガープリントのサーフェス、トランスポート／出口のすべてにおいて、ベースラインを 1 つに保ちます。references/env-diff-playbook.md を参照してください。Chrome のページワールドのレプリカとローカルの DOM ホストを区別します。ホスト忠実度を L0-L4（ネイティブ数／シーケンス LCS／値フィード／プロトコルのパラメーターセット／eval sha256）で評価します（デバイス信頼度 L0-L3 やスモークテスト L1-L4 ではありません）。Canvas や navigator の JS シムはプローブ数に含められません。外部のフィンガープリントキャッシュを実行パスに取り込まないでください（references/environment-patch-playbook.md）。
• 中間ゲッター、コールバック、Cookie ジャーと異なる場合は、ワイヤー上の送信内容を正として扱います。
• トラフィックがアプリケーションのセマンティクスに達する前に途絶える場合は、トランスポートの受け入れを個別にテストします。
• 決定論的な証明モードとライブ生成モードは分けてください。
• 最終的なすべてのヘルパーは自己完結型にし、ランタイムに依存する前段ヘルパーのインポートを含めないでください。
• 最終ヘルパーがステートフルな場合は、そのライフサイクルを明示し、状態の継続と意図的なリセットの両方をテストします。ライブ HTTP は引き続き Python が担い、ヘルパーをブラウザーの代替にしてはなりません。
• 解決済みの既存ヘルパーは、references/case-reuse-playbook.md に従ってのみ再利用します。対象の範囲が完全に一致するか、複数の独立したシグナルが一致することを確認し、まず固定ベクトルを実行します。また、コピーしたシークレットや過去のメモを現在の証明として扱わないでください。

Python を中心とするプロジェクトには scripts/scaffold_reverse_project.py、リクエストまたはレスポンスの差分には scripts/protocol_diff.py、TLS および H2 プロファイルの構造化された差分には scripts/transport_profile_diff.py、段階的なランタイムの同等性確認には scripts/transform_trace_diff.py、エンコーディングまたはダイジェストの予備的な手掛かりには scripts/crypto_fingerprint.py を使用します。

再利用可能な証拠については、references/reproducible-evidence-playbook.md を読みます。秘匿化された順序付きパッケージの作成には scripts/evidence_normalizer.py、チェーンの最初の不一致箇所の特定には scripts/transcript_diff.py、オフラインでのプロトコルのポジティブ／ネガティブ制御の検証には scripts/practice_lab.py を使用します。

スキルに付属するループバック練習ラボは、決定論的なフィクスチャの評価環境であり、新たなライブターゲットではありません。直接 HTTP のみで検証してください。このセルフテストでは、ライブの連続 Startup Gate（fingerprint-baseline／debugger-trace）を有効にしないでください。

検証と報告

宣言された形態に関係するすべてのゲートに合格するまで、完了としないでください。

• Startup Gate が最新の状態であること。
• ライブに関する主張では、実際のエンドポイント、正規の変更箇所、変化する状態が実証されていること。
• 新規の Web live-target では、初回の両方の役割（fingerprint-baseline と debugger-trace）について、選択した手段または明示的な不足を記録すること。不足がある場合、ページやランタイムの理解に関する主張はできません。厳密にトランスポートのみを対象とする直接エンドポイントの例外に限り、エンドポイントの範囲に限定した実行可能な成果物を1つ受け入れることができます。artifact-only の Web 作業では、これらのサーフェスが未検証であることを明記します。Web 以外の主対象は範囲外とし、Web ブラウザーの証明を捏造しないでください。
• 該当する場合、クリーンベースラインとオブザーバー効果のリスクに対処すること。
• 固定入力のヘルパーまたはデコーダーの検証に合格すること。
• 空でないことやミント形式の兆候、妥当な長さ、ヘルパーの読み込み、HTTP 200 が1回返ること、最新の Cookie、安定した拒否 JSON、ゴールドとの類似性、ミントバリアントの件数は、受け入れの根拠になりません。1つのゴールドサンプルでのモーフロックは、メインラインの必須条件ではありません。
• 該当する場合、Cookie の出所、スロットへの配置、セッションチェーンの整合性、トランスポート、エンベロープ、デコード、ストリーム、ページネーション、権限のルールを文書化すること。
• compact-replay と collector では、受け入れ結果がライブでの受け入れを未検証と明記した、明確に範囲を限定したオフライン再生でない限り、ライブ再生を繰り返して成功させること。
• 最終的な再生または collector は、ブラウザー自動化やブラウザープロファイルを使わずに実行すること。
• 指定された形式で出力を保存すること。
• 機密性の高い成果物は、タスク専用のシークレットストア以外では編集して秘匿すること。正規化済みのエビデンスパッケージを永続化する場合は、references/project-artifact-contract.md にあるエビデンス固有のマニフェストスキーマを使用します。実行可能な replay または collector のマニフェストには、シークレットを複製せずに、機能、セッションの範囲、ヘルパー、再生エビデンスも記録します。ファイルへの書き込みを伴わない会話形式のエビデンス結果には、マニフェストファイルは不要です。

各重要フェーズの後に、references/report-templates.md の簡潔なフェーズ差分形式を使い、browser_mode、curl impersonate、capsule major、business_request、unproven_routes、next_action を埋めてください。完全なテンプレートは、重要な判断と最終成果物にのみ使用します。compact-replay と collector では、冗長なプロジェクト文書を作成せず、それぞれの簡潔なプロトコル引き継ぎサマリーで締めくくってください。ファミリーの選択、各利用可能なエビデンスサーフェスで実証された内容、実際のエンドポイント、変化する要素、誤解を招くシグナル、固定入力による証明、最終的なプロトコル経路、collector とヘルパーの分担、保存先のパス、ブラウザーを使わない実行状況、残る不安定要素は必ず報告してください。Cookie、オブザーバー効果、兄弟ルート、エンベロープファミリー、デコード、セッション、ページネーション、または最小検証可能事実の詳細は、関連する場合にのみ追加してください。

再利用可能なファミリーが見つかった場合は、references/minimal-verifiable-facts-playbook.md を使い、構造的な事実を5〜15個保存してください。1回限りの教訓はタスク専用に保ち、独立した再現が2回行われた後に、references/experience-card-schema.md を使って、不変条件、フィクスチャ、肯定／否定のオラクル、適用範囲の境界のみを昇格させてください。

参照先ルーター

現在のエビデンスに該当する参照先のみを読み込みます。ただし、ここからすべての参照先へ直接アクセスできる状態を保ってください。

中核ワークフローとメンテナンス

• Hook／環境変数パッチ／純粋な Python のルートに特化した情報については、「Fast Routes and Ownership」を参照してください
• references/profiles/browser-hook-snippets/index.md
• references/profiles/static-ast/index.md
• references/profiles/env-patch/index.md
• references/runtime-state-continuity-playbook.md
• references/pure-python-rebuild-playbook.md
• references/startup-triage-playbook.md
• references/workflow-overview.md（フェーズ 0〜5 のマップ、複数段階の安定化、ステージのフィールド）
• references/tool-playbook.md
• 観測性の低い境界での値取得の改善：references/silent-value-capture-playbook.md
• MCP ファミリーの選択とシグナル駆動の自動判定：アーティファクトのみ、Camoufox／管理ホスト、chrome-devtools、js-reverse、silent-value-capture、パッシブなワイヤーストア、ワイヤーの可視性、環境プロバイダーのいずれを選ぶか判断する際は、references/mcp-routing-playbook.md を参照してください
• ローカル接続ポートまたはデバッグプロファイルのパスに関する問題：references/local-mcp-environment.md
• references/escalation-ladder-playbook.md
• references/delivery-gate-playbook.md
• references/anti-patterns-playbook.md
• references/report-templates.md
• references/doctrine-index.md
• references/symptom-heuristics.md
• references/pattern-atlas.md
• references/minimal-verifiable-facts-playbook.md
• references/provider-work-order.md
• references/specialist-handoff-contract.md
• 主張の格上げ／両面での確認：references/evidence-corroboration-gate.md
• ローカル要因と成功要因の因果関係の分離：references/positive-sample-ablation-playbook.md
• 複数面にわたる形態／状態連鎖の検証ツール：references/verifier-morph-and-state-chain-playbook.md
• 主な失敗箇所のラベルと、次のアクションで行き詰まった場合の対応：references/failure-surface-taxonomy.md
• アンチボットのクラス（シグネチャに依存／インターセプター／純粋な難読化）：references/anti-bot-class-playbook.md
• references/project-artifact-contract.md
• references/case-reuse-playbook.md
• references/experience-card-schema.md
• 昇格済みのシークレットを含まないカード：references/experience-cards/page-local-exception-needs-negative-control.json、references/experience-cards/standard-primitive-concat-before-custom-port.json、references/experience-cards/signer-egress-stub-must-match-callsite.json、references/experience-cards/server-clock-must-enter-observed-writer.json

リクエストパス、署名者、難読化

• 署名者ステージの同等性と、順序付きリプレイ失敗の段階的な切り分け：references/signer-parity-chain-playbook.md
• VM／インターセプターは終了処理を最初に確認し、ネストされた標準 ISA のメモリーイメージ、オペコードより前の protobuf serializeBinary／wasm encode(i32,i32)、逆トレース、ALU 重複 ID を調べます。パラメーター置換後のコンパイル本体のスナップショットは呼び出しトレースではなくキー素材です。fromCharCode の発生数（100 万対 0）で VM エントリーを診断します：references/jsvmp-analysis-playbook.md
• 改変された標準ダイジェスト、定数を移植する前に確認するネイティブ実装の有無、IV／Tj／各ラウンドの K／パッキング／圧縮分岐の選択（採取したダイジェストを Node で評価してもブラウザーのオラクルにはなりません）、カスタム実装を移植する前の定数プール連結、文単位に分割された JSEncrypt／JSBN／RSA という名前があっても連結と PKCS#1 が必要（ゴールドトークンのポリシーを決める前にパディング文字列を固定します。ランダムパディングでは不一致が想定されます）、ブロックのアバランシェが欠けている場合は同梱ヘルパーを使い続ける、アバランシェが確認できる AES/GCM という名前があってもパック済みキー／GCM フレーム／ゴールドペア XOR／内部フィールドの PRNG が必要、見せかけのタイムスタンプ／PRNG ラッパーと内部ハッシャーの区別、または観測された writer（署名者引数、クエリークロック、ajax の success など）に入れる必要があるサーバー発行クロック（内部の Date を固定するのではありません）、2 段階ミックス（プレースホルダー対ホスト、パディングなし対ありの 16 進数、長さは最初のミックスの 16 進数に従います）、サイズフィンガープリントによる DES／3DES／AES／RC4 の判別（AES という名前があるのに短いベクトルで CT が 8 バイトなら DES／3DES です。ホストオブジェクトの catch パスで暗号キーの順序が変わる場合があります）、TEA／XTEA ファミリーの定数、バイトコード内のキー復元、uint32 の移植、MD5 とタイムスタンプの両方が一致しない場合は同梱ヘルパーを使い続ける、復元した R をハッシャー内部で eval／setInterval するものはプレイメージではなくスタブです、固定サンプルの暗号処理：references/crypto-patterns.md
• 文字列テーブルまたは難読化ツール形式の復元、デコーダーの整合性ループ、フェッチごとにローテーションする書き込みスロット、巨大なチャート／描画ラッパーと小さなリスト URL モジュールの比較：references/obfuscation-guide.md、references/offline-inline-deob-playbook.md
• リスト XHR を伴わない HTML プレースホルダーのゼロ値、ダミー HTTP の埋め草では WebSocket のリストが不要にならないこと、chrome-devtools の HTTP ログには WebSocket が記録されないこと、JSON ではない WS プレフィックスフレームをスキップすること：references/decoy-and-real-request-playbook.md、references/structured-transport-playbook.md
• 空の beforeSend IIFE は署名者ではありません。ワイヤー上の本文を固定します：references/transport-wrapper-playbook.md
• references/patched-helper-playbook.md
• 不透明なステージ、収集してからパッチを適用する手順、ネストされたメモリーイメージ、バックエンド比較、同一セッション内の非決定的フィード：references/opaque-runtime-profile-playbook.md

Cookie、ブートストラップ状態、セッション

• ログイン後の多層ビジネスアイデンティティ：references/multi-context-session-playbook.md
• Cookie の writer／更新と、ホスト名に紐づけたなりすまし用 Cookie jar（空の domain と host-only の分岐）：references/cookie-provenance-playbook.md
• references/session-contract-playbook.md
• references/public-bootstrap-envelope-playbook.md
• チャレンジの主キー／同一ラウンドでのペナルティ HTML／ローテーションするドキュメントトークン／200 の埋め草 JSON ペナルティ／回答受理と完了ラッチ：references/challenge-state-envelope-playbook.md
• 1 つのパラメーター名に対する二重 writer、Cookie とクエリー、またはメモリー内グローバル変数の使い分け：references/dual-writer-param-playbook.md
• ローカルチャレンジ実行器、初期化／観測／操作／署名、マーカーのライフサイクル、正式なバックエンドの選択、ヘルパーの同一性は URL ではなく引数の数と I/O で判断、ビジュアルオラクルのドラッグ開始位置は中央ではなくボックスの x1、OCR／CAPTCHA プラットフォームは診断専用であり、収集ランタイムでは使用しない：references/local-challenge-executor-playbook.md
• ドキュメント完了時のロードラッチ生成、Cookie とクエリーの WAF スロット、ローテーションする 202 JS、Cookie と window スロットの使い分け、200 の埋め草値によるペナルティ：references/server-js-cookie-bootstrap-playbook.md
• references/side-asset-bootstrap-playbook.md

ホストに依存するランタイムと観測

• heat と因果関係のあるホスト読み取り、ページワールドのレプリカとローカル DOM ホスト、WebIDL FTS、window.eval のコンストラクター、Proxy に弱いライブコレクション。webpack の __wpRequire を公開し、UI の $mount はスキップします。setTimeout はコールバックを同期実行してはいけません（__drainTimers__ で駆動します）。偽の canvas／audio でも、impersonate がすでにビジネスレベルの 200 を返していれば、cookie を生成するヘルパーには十分な場合があります。Camoufox の前に、CDP の webdriver を設定可能な形で削除します：references/environment-patch-playbook.md
• ローカルベンダーのフィンガープリント SDK ランタイム：references/local-sdk-env-patch-playbook.md
• references/embedded-browser-runtime-playbook.md
• スクリプトの文字コード混在、名前のない meta content、page.load の baseURL、ThreadPool の分離、Node の偽装による生成とネイティブホストの違い：references/iv8-runtime-cheatsheet.md
• 暗号化チェーンを再構築する前に、公開されている複数アリティのエクスポートをオラクルとして利用します。cookie／リダイレクトの結果が優先されます：references/challenge-artifact-harvest-playbook.md
• Number.prototype.toString、TextEncoder.encode、TypedArray／ライブコレクションの Proxy をラップするとオブザーバーに悪影響があります。パラメーター置換後に Function コンストラクター／eval でコンパイルされた本体が重要な素材です。グローバルの Function.prototype.apply／call は決してラップしないでください。Array.join で平文が露出する場合があります：references/hook-techniques.md
• Function("debugger")／Function("while (true) {}") は、live js-reverse の再呼び出しも含めてハングします。完全一致する本体のみを除去してください。コンストラクター周辺の死んだ !== を 1 つ取り除いても attach は解消されません。デコーダーの整合性ループ、debugger 命令、復元した R を使うハッシャー内部の eval／setInterval（ホストをスタブ化し、ダイジェストは維持します）、MCP の select_page タイムアウトは debugger_attach_gap であり、その後はオフラインで取得します。webdriver による JSVMP の XHR 無応答は attach ハングではありません：references/anti-debug-playbook.md

トランスポート、デコード、構造化プロトコル

• 非同期エクスポート、レポートのダウンロード、タスクの分離：references/async-export-job-playbook.md
• 兄弟ルートが 200 で、このルートが標準ライブラリ経由で 403 の場合：署名処理や canvas のリバースをやり直す前に、許可済みの同一トークンバイト列でインストール済みの curl impersonate をアブレーションします：references/transport-pre-gate-playbook.md
• references/native-transport-profile-playbook.md
• HTML 内 CSS のスプライトの非表示クラス／フロー内オフセット／画像バイトの同一性、フォントまたはグリフマップ、JSON 数値の CR／LF 除去：references/response-decode-playbook.md
• UTF-8 の MCP ダンプでは protobuf が破損します。シリアライザーで 16 進数を取得してください。古いクロックバケットのトークンは 403 になります。JSON 以外の WebSocket のプレフィックス／ACK フレームはスキップしてください：references/structured-transport-playbook.md
• references/stateful-stream-e2ee-playbook.md

検証器、ページネーション、例外、復旧

• デバイス信頼のコンパニオンゲート／L0-L3：references/device-trust-sidecar-playbook.md
• ローカルフィンガープリント SDK の環境パッチ：references/local-sdk-env-patch-playbook.md
• ゲートウェイ／許可／ビジネス判定の受け入れ、同一ワールド、プロファイルの識別情報、再試行／スモークテストの段階的手順。ソースクラスと所有権クラスは直交します：references/verifier-replay-playbook.md、references/parameter-ownership-playbook.md
• 発行されたチャレンジ画像／トークンは必ず使用してください。未使用の取得によってセッションの合格率が損なわれる場合があります。受け入れ率と拒否率は異なる指標の場合があります：references/challenge-state-envelope-playbook.md
• references/verifier-error-localization-playbook.md
• 複数サーフェスの変形／状態チェーンのゲート：references/verifier-morph-and-state-chain-playbook.md
• 肯定的サンプルの衛生管理と、衛生管理後の動作の調整：references/positive-sample-hygiene-playbook.md
• references/pagination-route-pivot-playbook.md
• references/page-specific-exception-playbook.md
• 次のアクションが進まない場合と、症状別の対処レシピ：references/troubleshooting-playbook.md

スキルの検証

• メンテナンス、公式スイート、独立した動作レビュー：references/skill-maintenance.md、references/official-self-test-task-suite.md、references/forward-testing-playbook.md

このスキルの保守

編集する前に、references/skill-maintenance.md をお読みください。references/official-self-test-task-suite.md に照らして検証し、scripts/validate_skill.py がある場合は実行してください。デフォルトの検証は静的検証です。scripts/validate_skill.py --run-trusted-self-tests は、信頼できる現在のスキルルートに対してのみ実行してください。機械可読な JSON テストスイートが必要な場合は、scripts/validate_skill.py --export-tests <path-outside-skill> を使用してください。Markdown のテストスイートを唯一の信頼できる情報源として維持してください。静的検証の PASS は、動作の証明にはなりません。動作上の非回帰を主張する場合は、references/forward-testing-playbook.md に従い、外部の新規ランナーと独立レビュー担当者によるレポートを scripts/forward_test_report.py で検証してください。レポートと回答の成果物は、このスキルのツリー外に保管してください。

再利用可能な詳細は、内容に最も合ったリファレンスに記載してください。このエントリはプロトコルを優先する実行経路と、適切な参照先へ導くルーターとして維持してください。汎用的な事実と固定ベクトルは保持し、実際の秘密情報、コピーした Cookie、アカウントトークン、サイト固有の俗説は決して含めないでください。

要点

サイトがブラウザー専用に見える場合、実際のリクエストは何か、実際に変化する状態はどれか、その状態をローカルで再構築できるかを確認してください。

通信内容の証拠と再現可能なリプレイによってこれらの問いに答えれば、ほとんどのターゲットの仕組みを解明できます。