dynamics

stardust:dynamics — 移行における動的な側面

静的な移行では、ページをコンテンツとレイアウトとして扱います。このスキルでは、ページを動作として扱います。つまり、JavaScript、サービス、データソースからソースがレンダリングするすべてのものと、移行先のホストで同じようには提供できないすべてのものが対象です。実際の移行を3件調べたところ、いずれも同じ問題が見つかりました。動的な側面は、ブロックスコープでピクセル検証を行うパイプラインから見えません。そして、どのゲートでも正しいと判定される形で見えなくなっています。リンクとしてレンダリングされるモーダル、リンク先のないCTAとして表示される動画ピル、404になる検索ボックス、レンダリングはされても送信できないフォーム。このスキルでは、こうした側面を可視化し、インポート前に行ごとに対応を決定させ、その後、デプロイ後の動作を検証します。静的なパスを妨げることはありません。すべてのページは、引き続き静的ページとして機能する必要があります。

実行タイミング — 移行に限定され、移行時はデフォルトで有効、それ以外では実行されない

エントリーポイント	ここで実行される内容
prepare-migration Phase 4.5 · replica Phase 2	Phase 1–3（アーキタイプで検出、分類、トリアージ）— インポート前のゲート
migrate Phase 1	セーフティネット：インベントリがなければ、今すぐPhase 1–3を実行（手動で実行するextract → direct → prototype → migrateでは、ゲートを通過しなかったため）
deploy	インベントリをブリーフの入力として読み込む（フォールバック行、#modalマーカー、エンドポイント設定。client-onlyやモーダルを含むセクションは決してフラット化しない）
rollout B2 · D2	B2は新たなエビデンスに照らしてインベントリを検証。D2はselfセットに対するPhase 4と、オーナー1名分のバッチを実行
qa dynamics check · rollout report	parity.jsonを使ったPhase 5のリプレイ
スタンドアロン $stardust dynamics <origin>	すでに移行済みのサイトですべてのフェーズを実行

uplift、audit、単独のextractでは実行されません。dynamicsは移行に関するものであり（現時点ではEDS、将来的には他のプラットフォームも対象）、再設計に関するものではありません。

Phase 1 — 検出

node skills/dynamics/scripts/dynamics-detect.mjs --from-state stardust/state.json --out stardust/current [--reach stardust/current] （または、アーキタイプごとに1つずつ、ホームページも含めた--urls）。アーキタイプでは詳細な調査を行い、リーチはクロール時に取得したページごとのextract --dynamicsシグナルから得ます。出力はstardust/current/_dynamics.jsonとdynamic-features.generated.mdです。ここではエビデンスのみを扱います。reference/classes-and-signals.mdを参照してください。見つかった検索フォームごとに、ソースで検索語を1つ試し、表示される結果数、上位のタイトル（≤ 3）、既知の一致結果1件を記録してください。これらを、その機能のsearch-queryチェック（Phase 5）にexpectCount／expectTitles／expectIncludesとして指定します。仕様のknowledge/search-probes.jsonにすでに記載されている場合は、それを使います。これらがなければ、再構築した検索機能で確認できるのは、存在の有無だけです。

Phase 2 — 分類

すべての検出項目にL S F M V T A R X I18N CR Dのいずれかのクラスを割り当てます。既知のベンダーはscripts/vendors.jsonを通じて役割に解決します。未知のサードパーティーホストは「要調査」として表示したままにします。移行先のホストがある場合、dynamics-plan.mjs --target-origin <host>は、記録されたファーストパーティーAPIのパスをすべてそこでプローブし、応答しないパスにホスト依存の印を付けます。これは、ピクセルゲートが「バンドが短い」と報告するシグナルです。

フェーズ 3 — トリアージ（ゲートの出力）

node skills/dynamics/scripts/dynamics-plan.mjs [--target-origin …] [--migrated stardust/migrated] [--knowledge] [--chrome] --out stardust/dynamics は、各検出事項につき 1 行を作成し、4 つの軸 — 分類 · 対応方針 · 再現性 · ステータス — と、パターン、フェーズ、担当者の判断、target、配信形式（作成済みの行が残っていない場合は widget。reference/triage.md § Target を参照）をあらかじめ入力します。--knowledge を指定すると、仕様の厳選された機能と、未解決の質問に対する判断が追加されます。--chrome を指定すると、ヘッダー契約ファミリーごとに 1 行が追加されます（カートとアカウントはバックエンドを決定し、UI は提供されます）。これを stardust/dynamic-features.md（§ Listings contract + § Features + § Decision batch + § Register）と stardust/dynamic-features-plan.md にまとめます。契約は reference/triage.md です。このフェーズの形を決定するルールは次のとおりです。

• スケジュールを組む前に、移行済みの出力と照合してください。
• 自律的に提供するのは再現性が self のものだけです。それ以外はすべて1 つの判断バッチにまとめます。
• クライアント側でレンダリングされた空のキャプチャ用にコピーを捏造してはいけません。regulated-pii フォームを自動で接続してはいけません。検索ボックスがあれば結果ページが必要です。対象外とする決定は明示し、担当者が判断する必要があります — 手を加えないという前提だけで対象外にしてはいけません。
• ゲート： 対応方針がない行があると、prepare-migration 4.5 / replica Phase 2 / rollout B2 は失敗します。静的移行は引き続き実行されます。
• Martech は依頼があった場合のみ： 担当者からタグまたは同意管理の維持を依頼された場合は、--martech（reference/martech.md）を追加します。それ以外はすべてスキャフォールドから除外されます。

フェーズ 4 — 実装（計画の各フェーズに従う）

reference/patterns.md（カタログ + 契約 + 埋め込み型のメカニズム例）、reference/listings.md、reference/off-origin-data.md、reference/forms.md、reference/locale-trees.md を参照してください。3 つのサイトで有効だった原則：まず静的に、その後接続する · コードを書く前にオーサリング契約を定める · 担当者からの入力がなくても待たない（暫定ティアを提供し、判断事項を明示する） · 既存ライブラリを優先する（それを活用し、フォークしない） · 対象外とする決定は明示する。各フェーズの最後に、公開済みオリジンで 1440 と 360 におけるフローを検証し、パリティ行、ジャーナルエントリー、コミットを作成します。ツール：snapshot-api.mjs、snapshot-forms.mjs、sync-sheets.mjs。クエリーインデックスはコードブランチの helix-query.yaml から取得します — コミット、プッシュ、公開、ポーリングの順に行います。設定サービスへの書き込みから取得してはいけません。ブランチに書き込みできない場合に限り、シートを基にした暫定インデックスを使用します（reference/listings.md § Getting an index at all）。検索は reference/patterns.md § search-index-backed に従います。リスティングとデータフィード型バンドはドキュメント優先です。ドキュメントには作成済みの行として項目テキストを含め、ブロックはテキスト以外のフィールドと補完データに限り、インデックスまたはスナップショットを読み取ります（reference/listings.md § Block contract。理由：deploy/reference/ai-readability.md）。

フェーズ 5 — 検証：動的パリティ

閉じたチェックセットから再実行可能なチェックを含めて stardust/dynamics/parity.json（reference/parity-report.md）を作成します。node skills/dynamics/scripts/dynamics-check.mjs --origin <published origin> [--auth-header … | --token-env SITE_TOKEN] を実行すると、stardust/qa/dynamics-report.md が作成されます。存在ではなく、フローを検証します。 search-query チェックでは、結果の件数と上位タイトルをソースに記録された値と比較します — 件数が一致しなければ失敗です。サイトシークレットはオリジンをスコープとするルートフィルター経由でのみ渡します。サードパーティリクエストのステータスは、すべてのアサーションの横に記録します。

手を加えずに解決できる項目

ゲート	解決方法
オーナーの判断（バックエンド、新しいホスト上のタグ、データソースの所有権、ロケールの範囲）	暫定ティアをリリースし、計画書とパリティレポートに判断者の名前を記録して続行します。decided-out にするのは決して避けてください。これにはオーナーの明言または重大なブロッカーが必要です
未知のサードパーティーホスト	XHR の本文から分類します。それができない場合は T「調査」とします。黙って除外してはいけません
クライアント側でレンダリングされたキャプチャが空白	コンテンツの重大な欠落として扱い、手動キャプチャのバッチに回します。空白のまま移行してはいけません
規制対象の個人情報を扱うフォーム	UI を再構築し、送信をブロックして、必ず判断を仰ぎます
引き継ぎ先にテストネットワークから到達できない	エグレスリージョンを記載した environment-limit の行を追加します。これは不具合ではありません
コンテンツソースで送信を受け付けられない	「バックエンドに接続されていません」と明示してローカルでキャプチャし、判断者の名前を記録します

重大なブロッカー（event: "blocked"）

プローブネットワークからソースに到達できない場合、エンドポイントの間接参照が必要なのにターゲット設定を書き込めない場合、規制対象データをキャプチャする暫定ティア（代わりに decided-out として記録します）。

成果物

stardust/current/_dynamics.json、dynamic-features.generated.md · stardust/dynamics/dynamic-features.generated-plan.{md,json} · stardust/dynamic-features.md、stardust/dynamic-features-plan.md（編集済み） · helix-query.yaml（リスティング＋検索、コードブランチにコミット） · data/<feature>/*.json ＋ _provenance.json（スナップショット、コードバス） · scripts/site-config.js（オーナー向けインテグレーション、無効） · stardust/martech-contract.json、martech-handoff.md、scripts/martech.js（オプトイン） · stardust/dynamics/parity.json · stardust/qa/dynamics-report.{md,json} · 登録行 · ジャーナル＋ステータス行。

参考資料

• reference/classes-and-signals.md — クラス軸、検出手順、ベンダーテーブルのポリシー、オリジン制約付きプローブ。
• reference/triage.md — 4 つの軸、ルール、インベントリファイルの形式。
• reference/patterns.md — カタログ：各パターンの契約と検証、メカニズムの例。
• reference/listings.md — メタデータ契約とクエリーインデックスの仕組み（以前の rollout の dynamic-listings）。
• reference/off-origin-data.md — オリジン外から既存ライブラリにデータを提供する方法、シートを使用したデータ、Chrome の URL 空間。
• reference/forms.md — フォームタグではなくコントロール、コンテンツソースによる受付、規制対象データ。
• reference/parity-report.md — スキーマ、チェックの種類、ルール。
• reference/locale-trees.md — ツリーとしての I18N。
• reference/martech.md — オプトインのマーケティングテクノロジー契約、オーナーによる有効化、ランタイム、検証。
• scripts/ — dynamics-detect.mjs、dynamics-plan.mjs、dynamics-check.mjs、snapshot-api.mjs、snapshot-forms.mjs、sync-sheets.mjs、vendors.json、lib.mjs、martech.mjs。