replica

stardust:replica — 同一デザインへの移行

同じページ、同じコンテンツ、同じデザインで、新しいプラットフォームへ。replica は、現在のデザインをほぼピクセル単位で忠実に保ちながら、サイトを AEM Edge Delivery に移行します（またはフロントエンドだけを新しいプラットフォームへ移行します）。ターゲット仕様は、取得した現在の状態そのものです。許容される差分は、明示的な不整合レジスターの項目だけです。また、何かをリリースする前に、すべてのアーキタイプが稼働中のサイトとの測定済みソース忠実度ゲートに合格する必要があります。

このパイプラインがデザイン刷新のパイプラインと大きく異なる点は、次の2つです。

1. クリエイティブな判断はありません。 ディレクションの工程では、取得した仕様を機械的に昇格させます。stardust の direct スキルは呼び出されません。replica の実行における判断はすべて、好みではなく測定ポリシーに関するものです。
2. コピーではなく再作成です。 アーキタイプは、取得したコンテンツとソースサイト自身の CSS から抽出した値を基に、クリーンなセマンティック HTML/CSS で作成します。DOM のコピーも、ページ単位のスタイルシートの移植も行いません。忠実度は、作成方法から主張するのではなく、測定ツールで証明します。

エンドツーエンドで検証済みです（タイポグラフィを重視した小売サイトのホームページ、2026-07-03）：測定を3回繰り返し、ピクセル差分は 8.31% → 2.93% → 1.31%、高さの差 Δ は 0、コンテンツ差分の「検出結果：なし」（198/198 ノード）でした。すべての修正は測定ツールの結果に基づくもので、目視によるものではありません。

入力

• <URL> — 必須。移行するサイトです。
• --breakpoints <list> — 任意。ゲートの幅です。デフォルトは 1440,360 です。それぞれに独立したゲート判定が行われます（モバイルは無料ではありません。ゲートのドキュメント § Per-breakpoint を参照）。
• --target-breakpoints <list> — 任意。ソースサイトのブレークポイントの代わりに、納品するサイトのレイアウト切り替えに使用する、モバイルファーストの min-width の段階（例：600,900,1200）です。指定しない場合はソースのブレークポイントが維持され、ターゲットの各段階はスキップされます。DESIGN.json の extensions.breakpoints.target に保存されます。
• --register <file> — 任意。不整合レジスターの初期項目として追加する、ユーザー提供の不整合項目です（フェーズ2を参照）。これも監査もない場合、レジスターは空となり、純粋なレプリカになります。
• --first-page <url|home> — 任意。デフォルトは home です。フルサイトの実行で最初に納品するページです（reference/first-page-first.md）。

セットアップ

1. マスタースキルのセットアップ（../stardust/SKILL.md § Setup）を実行します。コンテキストローダー、状態の読み込みが含まれます。フローガード。 state.json.flow が redesign の場合は拒否し、混在禁止の文言と切り替えコマンド （$stardust replica --switch-flow。これにより、redesign フローで プロトタイプ作成済みおよび移行済みのページが古い状態になります — マスタースキル § Two migration flows）を出力します。flow がない場合は、flow: "replica"、 flowSource: "user-phrase"（../stardust/reference/state-machine.md § Flow keys）を設定します。replica の呼び出しが選択を示します。
2. プロジェクトルートから Playwright をインポートできることを確認します（extract で 必要になるため、ゲートスクリプトでも必要です）。
3. まずプロジェクトルートからゲートの依存関係を確認します — node -e "import('pixelmatch').then(()=>process.exit(0))"（および playwright、 pngjs、cheerio）。失敗した場合に限り、--no-save は使わず、 devDependencies としてインストールします：npm i -D playwright pixelmatch pngjs cheerio --legacy-peer-deps（../extract/SKILL.md § Setup）。すでに依存関係を解決できるハーネスでは、納品するコードリポジトリに変更は加わりません。それ以外の場合、devDependencies はスキルが push するリポジトリに追加されます。すべての確認はプロジェクトルートから実行してください。ESM はスクリプトの配置場所から playwright を解決します。
4. スクリプトをプロジェクトにコピーし、プラグインからではなくプロジェクト内から実行します。このスキルの scripts/ ディレクトリ全体を stardust/scripts/replica/ に、マスタースキルの ../stardust/scripts/ （ledger.mjs、state.mjs）を stardust/scripts/stardust/ に、migrate スキルの ../migrate/scripts/（migrate.mjs）を stardust/scripts/migrate/ に、 さらに ../diff/scripts/ ディレクトリ全体を stardust/scripts/diff/ にコピーします（diff スクリプトは diff-profiles.mjs をインポートします。また、stitch-shot のものを含むライブターゲットの強化機能はすべて、その live-session.mjs にあります。stitch-shot は stardust/scripts/replica/ の隣にある stardust/scripts/diff/ からこれを解決するため、この2つのディレクトリは兄弟ディレクトリのままにしてください）。プロジェクトルートの scripts/ には絶対にコピーしないでください。そこは EDS ボイラープレートのディレクトリです（マスタースキル § Artifacts、書き込み境界）。

読み取りと確認の規律 — コンテキストが予算です （reference/reading-discipline.md。セットアップ時に一度読みます）。各ステップが出力するバイトは、後続のすべてのモデル呼び出しで再読込されます（記録例：77分のセッションでツール出力が75万文字）。ルールを1行ずつ示します。 参照ドキュメントはセクション単位で確認します（section.mjs <doc> --list の後、見出しを1つ選び、1回の呼び出しにつき1セクション）。取得した CSS は css-rules.mjs、取得した JSON は json-query.mjs で確認します（コマンドに渡す値はテーブルではなく --tsv／--path から取得します）。取得した HTML は html-slice.mjs で確認します。計測出力は run-bg.mjs wait と log --grep を使い、cat は使いません。ライブ版とプロトタイプのボックスは measure.mjs で確認し、独自のプローブは使いません。画像は事実1つにつき切り抜き1つとし、ページ全体の連結画像や live/build/diff の3枚セットは使いません（例外は extract のサムネイル thumb.mjs です）。スクリプトのフラグは、まず ../stardust/reference/scripts-index.md を確認し、次に --help を使います。ソースは確認しません。再び必要になる情報はすべて stardust/ 配下のファイルに書き込み、クエリで読み返します。

手順

5つのフェーズで構成されます。フェーズ1と5は既存のスキルに変更を加えず委譲し、フェーズ2〜4は replica が担当します。サイト全体を実行する場合は、最初のページを最初に開きます。 reference/first-page-first.md を参照してください。

フェーズ 1 — 抽出（$stardust extract --prep --dynamics に委任）

$stardust extract <URL> --prep をそのまま実行します。Prep モードが必要です。replica では、検出上限ではなく、移行対象全体のインベントリを使用します。

• stardust/current/pages/<slug>.json — ページごとの構造とコンテンツ（プロトタイプに引き継ぐすべての文字列の逐語的なソース）。
• stardust/current/assets/screenshots/ — ページごとのキャプチャ（ゲート独自の結合ショットと併せて、再現時の正解データとして使用）。
• stardust/current/assets/ — フォント（ネットワークから取得した woff2）、ロゴ、メディア。
• stardust/current/PRODUCT.md、DESIGN.md、DESIGN.json — 現状を記述したもの（フェーズ 2 でこれらを逐語的に昇格させます）。
• state.json.pages[].type — ページタイプ（それぞれが 1 つのアーキタイプになります）。
• DESIGN.json.extensions.modules[] — モジュール候補（ブロックになります）。

extract の概要が返ってきたら、まずフローの行を示してから提示します。このフローでユーザーが最初に目にするのは、その選択の根拠です。「Flow: replica — the design is kept. Say switch to redesign now if it is to change.」——switch to redesign を実行すると $stardust prepare-migration --switch-flow が起動します。再利用されるのは extract の結果だけで、それ以外は再利用されません。

範囲を限定した／単一ページのエントリ（1 ページのみ、またはパイロット実行）。 サイト全体を対象とする契約が --prep ですが、これだけが唯一の方法ではありません。「このページだけを再現する」という依頼の場合、または完全な移行を決める前に 1 つのアーキタイプをパイロットで試したい場合は、代わりに $stardust extract <URL> --single --dynamics を実行します（短いリストの場合は --pages <slug,...> --dynamics）。これは正式にサポートされたエントリであり、即興で行うものではありません。再現フェーズではページごとに、キャプチャしたページ JSON（逐語的なコンテンツ）、ページごとのスクリーンショット（正解データ）、キャプチャしたフォントが必要です。これらはすべて、範囲を限定した extract で取得できます。ソース CSS の収集とブレークポイントごとの計算済みスタイルは、いずれの方法でもフェーズ 3 の CSS 抽出で取得します。範囲を限定した実行で省略されるのは prep 専用のインベントリ（ページの分類、モジュール検出）です。これはフェーズ 5 で兄弟ページへ展開する場合にのみ必要です。また、記述的な統合も省略されます（フェーズ 2 では範囲限定向けの昇格ブランチ reference/preserve-direction.md § 1a が使用されます）。

extract の失敗時の挙動はそのまま適用されます（ボット管理による headed フォールバック、同意の処理、合成禁止ルール）。extract で headed Chrome へのフォールバックが必要だった場合、ゲートのキャプチャにも同じ対応が必要になると想定してください。

フェーズ 2 — 方向性の維持（機械的な処理 — stardust の direct スキルは絶対に呼び出さない）

契約の全文：reference/preserve-direction.md。概要：

1. 昇格：stardust/current/PRODUCT.md、DESIGN.md、DESIGN.jsonを そのままプロジェクトルートに昇格し、ターゲット仕様とします。逸脱のロールは行わず、 方向性の再設定も、Mode A/B もありません。現在の状態がそのままターゲットです。範囲限定 エントリー（--single／--pages）：これらのファイルは存在しません。代わりに 範囲限定の昇格ブランチ（reference/preserve-direction.md § 1a）を使用します。キャプチャしたページ JSON とフェーズ 3 の CSS 抽出 （パレット、タイプスケール、コンテナー、ボタン — 抽出で生成される値とまったく同じもの）から 最小限の記述仕様を合成し、出所を bounded-single とします。ブランチを 混在させないでください。current/PRODUCT.md が存在する場合、昇格はそのまま行います （Track A の最初のページ優先の場合を除く）。

2. stardust/direction.md を作成し、維持モードを記録します。何を、 どこから昇格したか、出所（そのままの --prep 昇格か bounded-single による合成か）、 登録簿へのポインターを記載します。これによって、後続のスキルに「方向性の設定ステップが完了した」と 伝わります。

3. 不整合登録簿を作成：stardust/replica/inconsistency-register.md — 許可されるデザイン差分、「ほぼピクセルパーフェクト」の「ほぼ」を記録する唯一の場所です。情報源： stardust の audit スキルによるデザイン上の指摘（ユーザーが改善候補を求めている場合のみ audit を実行） および／またはユーザー提供の項目（--register）。各項目にはキャプチャした エビデンス、最小限の変更、ステータスが必要です。登録簿が空の場合は、純粋な レプリカです。これは妥当でよくある結果であり、失敗ではありません。

4. ターゲットのブレークポイント（--target-breakpoints が指定された場合のみ）：CSS が 存在する前に設定します（reference/preserve-direction.md § 4）。リストを 保存し、各ソースブレークポイントを意図に基づいてステップにマッピングし、 stardust/replica/breakpoint-map.md に記録して、登録簿に唯一の項目を追加します。フェーズ 3 と C0 はこのマップを適用します。マップを決定することはありません。

5. 動的サーフェス（移行ゲート — stardust の dynamics スキルのフェーズ 1〜3）。 フェーズ 1 では extract --dynamics を実行している必要があります。アーキタイプに対して 検出器を実行し、トリアージ案を作成し（EDS ホストが判明している場合は --target-origin を指定）、 stardust/dynamic-features.md と -plan.md を精査します。各行に処置方針を記載します。 静的な再現は引き続き進めます。これにより、ピクセルゲートでは正しいと認定されるモーダル、 プレーヤー、フォーム、検索、タグ、およびホストに依存する API が明らかになります。契約： skills/dynamics/reference/triage.md。

登録簿に記載されていない内容は、変更対象外です。再現時の選択によって、登録されていないものを 「改善」してしまう場合、それは忠実性のバグです。

フェーズ 3 — 再現（ページタイプごとに1つのアーキタイプ）

手法の全容：reference/recreation-procedure.md。インベントリ内の各ページタイプ（アーキタイプ：仕様の archetypes.json にある、そのタイプの rep_url）について、stardust/prototypes/<slug>-proposed.html（およびページごとの CSS）を、次の3つのソースからセマンティクスに沿ったクリーンな HTML/CSSで作成します。順序は次のとおりです。

(a) キャプチャしたページの JSON コンテンツ — 一字一句そのまま。 見出し、本文、CTA とその href、代替テキスト、メタデータは current/pages/<slug>.json から取得します。移行時のコンテンツ保持ルール（../migrate/reference/content-preservation.md）は最初の行から適用されます。言い換えも、内容の捏造も禁止です。 (b) ソースサイト独自の CSS から取得した正確な値。 ライブのスタイルシートを取得し、タイポグラフィのスケール、ボタンの仕様、セクションのパディング、角丸、影、ヒーローの高さを抽出します。コンテナモデルは実測値を使い、抽出するものではありません。DESIGN.json の extensions.breakpoints を使用します（extract の cap-probe.mjs を実行します。エントリーに上限がある場合は、まず cap-probe.mjs <live-url> --write-design stardust/current/DESIGN.json を実行します）。 忠実度の値は目測ではなく、元サイトの CSS から取得します。これにより、3〜4回の推測とスクリーンショット撮影の繰り返しが1回で済みます。ライブページと配信中のプロトタイプのボックス単位の比較には、同梱の measure.mjs を使います（node stardust/scripts/replica/measure.mjs <live-url> --against <prototype-url> --selectors "<css>,…"。セレクターごと、幅ごとに rect と算出値を比較し、差分を1行ずつ表示します）。作成したプローブは使用しません。 (c) CSS では指定されないすべての要素（構成、画像の切り抜き、描画効果）の正解データとして、キャプチャしたスクリーンショットを使用します。

ターゲットセットがある場合、すべての @media ルールと JS の幅しきい値（matchMedia、innerWidth）は、最初の行から breakpoint-map.md に従ってターゲットのステップで作成します。 後から固定することはできません（後付けすると完全な再ゲートが必要になります）。breakpoint-lint.mjs は、ゲートの前にプロトタイプに対して終了コード 0 を返す必要があります。

各アーキタイプには、独立したプロトタイプを必ず作成します。累積方式とし、省略は禁止です。 新しいアーキタイプを直接プラットフォーム上で作成するために、プロトタイプを省略してはいけません。プロトタイプを作成したアーキタイプは現場で品質の上限を維持しました（3.5%／5.6%）。一方、直接作成したページは 8〜16% で頭打ちになりました。新しいプロトタイプには、それ以前にゲートを通過した共有レイヤー（共有のカノン CSS と、アーキタイプごとのファイル）を読み込み、新しいモジュールだけを反復します。契約の詳細：reference/recreation-procedure.md § Cumulative archetype prototypes。

これは再設計ではなく再現です。impeccable craft に委任してはいけません。 Impeccable の再設計ゲート（批評、テンプレートの回避、差別化）は適用されません。これらはソース忠実度ゲート（フェーズ 4）に完全に置き換えられます。「洗練された改善」を加えたセクションは不合格です。

フォント： 利用可能な場合は、同じ公開ソースを使用します（オープンなフォント、またはセルフホスト可能なフォントには、extract が傍受した woff2 を使用します）。ライセンス付きの商用キットは、新しいドメインで再ホストしてはいけません。メトリクスが一致する代替フォントを選び、後からライセンス済みフォントを追加した場合に優先されるよう、フォントスタックではブランドのファミリー名を先頭に置き、代替フォントを使用することをユーザーに伝えます。（先行事例：以前の空港サイト移行に関する改善メモ、§3.7。）

CSS の移植は、セクション単位でのみ使用するフォールバックです。 算出スタイルから復元できない描画レベルの効果、JS でハイドレーションされるコマースウィジェット、動画、アニメーション付きヒーローが対象です。そのセクションに必要な最小限のソースルールをスコープ付きで移植し、ページ全体には適用しません。基準：reference/recreation-procedure.md § Fallback。

フェーズ 4 — ソース忠実度ゲート（核心 — ブレークポイントごとに測定）

契約の全容：reference/source-fidelity-gate.md。アーキタイプごと、ブレークポイントごと（デフォルトでは 1440 と 360）に、ソースとしてライブ URL、比較対象として配信中のプロトタイプを使用して実行します。

PROTO="http://localhost:8791/<slug>-proposed.html"   # python3 -m http.server from the prototypes dir
# ONE server, ONE port — probe with curl first (gate doc § Per-breakpoint procedure): no answer →
# start yours; answers but not your file → foreign server, never kill it, take a per-project port
curl -sI localhost:8791/<slug>-proposed.html | head -1   # 200 = it serves YOUR dir: reuse it
LIVE="https://<site>/<path>"

# One command per round — gate.sh, through run-bg. The FIRST round of a breakpoint and the
# CONFIRMATION round after the last fix run `--full` (pixel probe — stitched captures, NEVER
# fullPage:true — plus content-diff, visual-diff and chrome-parity under deadlines, one verdict
# line each, reports in the gate dir); rounds in between are pixel rounds. Never hand-write a
# wrapper around the instruments (a recorded one lost the deadlines; a round took 15 minutes).
# content-diff inside --full compares --main AND the header/footer roots by default — no chrome flag.
node stardust/scripts/replica/run-bg.mjs start --name <slug>-1440-iter1 -- \
  stardust/scripts/replica/gate.sh <slug> "$LIVE" "$PROTO" 1440 iter1 --full --main "<content-root>"
node stardust/scripts/replica/run-bg.mjs start --name <slug>-360-iter1 -- \
  stardust/scripts/replica/gate.sh <slug> "$LIVE" "$PROTO" 360 iter1 --full --main "<content-root>"
# A consent manager the built-in candidates miss: add --consent "<accept selector>" to every gate.sh
# round — it reaches both stitched captures and the probes alike (gate doc § Hardening rule 6).
node stardust/scripts/replica/run-bg.mjs wait      # verdict lines: pixel %, height delta, hot bands, structural 🔴, flags, chrome deltas

# Iteration inner loop (gate doc § Band breakdown): anchor probe + pixel round
G=stardust/replica/gates/<slug>-1440
node stardust/scripts/replica/anchor.mjs "$LIVE"  --width 1440 --cache $G/anchor-live.json   # live side: probed once, reused
node stardust/scripts/replica/anchor.mjs "$PROTO" --width 1440   # build-side runs are free
# Chrome: computed-style parity BEFORE any pixel round on header/footer/strips
node stardust/scripts/replica/chrome-parity.mjs "$LIVE" "$PROTO" --width 1440 --live-cache $G/chrome-live.json   # exit 0 = quiet, then crop-compare
# --headed in any instrument = the window-free real-Chrome stealth tier (#125); STARDUST_HEADED_WINDOW=1 is the only way to a window.
# gate.sh: live.png cached, every step under a deadline (exit 124 = re-run, not FAIL). Rounds run in
# the BACKGROUND: start every round at once (the slots pace the Chromiums — no `sleep N;` staggering),
# then `wait` prints verdict lines only; exit 75 = still going → `wait` again as your NEXT step, never
# in a shell loop, never after a `sleep` (gate doc § Iteration discipline). A propagation wait is a
# bounded inline poll (`curl -sf` ≤ 5 s apart, capped), never a fixed sleep.
node stardust/scripts/replica/run-bg.mjs start --name <slug>-1440-iter2 -- stardust/scripts/replica/gate.sh <slug> "$LIVE" "$PROTO" 1440 iter2
node stardust/scripts/replica/run-bg.mjs start --name <slug>-360-iter2  -- stardust/scripts/replica/gate.sh <slug> "$LIVE" "$PROTO" 360  iter2
node stardust/scripts/replica/run-bg.mjs wait      # returns within 100 s; full output: run-bg.mjs log <job> --grep <re>
# Content-cap row — once per archetype after the 1440 pass, at DESIGN.json's derived probeWidth (never a pinned 1920)
node stardust/scripts/replica/cap-probe.mjs "$LIVE" --against "$PROTO" --design DESIGN.json --slug <slug> --main "<content-root>"

gate.sh --help にフラグと終了コードが表示されます（124 = 期限切れ。判定ではないため再実行してください。0 = 4つすべてが実行され、合格した場合のみ）。 合格基準（ブレークポイントごとに4項目すべて、およびコンテンツ上限行）：

• content-diff：メインルートと chrome ルートで 🔴 が0件、nothing-lost 🟡 が0件（ゲート文書 § Pass bar 項目1）。
• visual-diff：フラグがないか、正当な理由があること。
• ピクセル差分：フルページで ≤ 10%、未説明の500px帯が残っていないこと （帯ごとの内訳はナビゲーション手段です。最初に差分が大きい帯を上から順に修正してください。 それより下はすべてオフセットの影響を受けています）。
• 高さの差 |Δ| ≤ 8px（pixel-compare 自体の警告バー）。
• コンテンツ上限行：cap-probe.mjs … --against が cap-probe: PASS を出力すること （ゲート文書 § Pass bar 項目6 — すべての実際の上限が種類ごとに ±20 px 以内に収まっており、 プロトタイプ側だけで上限に達しているものがないこと。✗ はサイズ設定ルールを示し、 ピクセル単位での反復調整は不要です）。
• clip-probe：ビルド側で Clipped: 0（--full 実行でチェックします。切れている、 または非表示のテキスト／コントロールがあると、ピクセル差分がしきい値を超えた場合と同様に 実行が失敗します — #125）。宣言された反復単位ファミリー（stardust/replica/units.json、 ゲート文書項目7）は4 px 以内であること。
• また、基準および上限とは別に、横方向のオーバーフローをアサートします。 すべてのブレークポイントで、ビルド側の document.documentElement.scrollWidth が ビューポートから4 px 以内（整数丸め、GATE_OVERFLOW_TOLERANCE）であること。 gate.sh はピクセル値に関係なく、これを超えると実行を失敗させます。 capture failed (exit 1) となった実行（gate.sh の1回の再試行後）は再キューされ、 カウントされません。

ターゲットを設定した場合（#131）： ゲート幅には各ターゲットのステップが加わります。 シフトした帯の中でのピクセル差分の失敗は、tier-shift（レジスター項目に記録し、反復調整はしません） または defect（引き続き失敗）です — ゲート文書 § Target breakpoints。

すべてのプロトタイプを1行として記録します（#125）。 アーキタイプが合格すると、 幅ごとに1回の実行でプロトタイプ表が書き込まれます — node stardust/scripts/replica/gate-all.mjs --stage prototype --proto-base "$PROTO_BASE" --width 1440（続いて360）を run-bg.mjs 経由で実行します。 各アーキタイプのキャッシュ済み live.png を再利用します。gate-evidence.mjs がこの表を 正式な記録として読み込みます。行のないプロトタイプにはゲートがかかっていません。

反復の規律：ブレークポイントごとに最大3回。 各反復での修正は、目視判断ではなく 計測結果に基づいて行います。3回後は残差を台帳に記録して先に進みます。 記録のない4回目のループより、文書化された2%の残差のほうが望ましいです。 コンテキストキャッシュの有効期間を超えて待たせるステップはありません。 時間のかかる計測は run-bg.mjs を使います（start の後、≤ 100秒の区切りで wait）。 メインエージェントもサブエージェントも同様です。時間のかかる計測をフォアグラウンドで実行することも、 1ターン内で2つをツール呼び出しとして並列実行することも、同じくステップをブロックします （参照文書 § Iteration discipline）。

堅牢化（いずれも誤計測を招く要因として記録されています — 全項目は参照文書を参照）： すべてのキャプチャで実際の Chrome の UA と標準リクエストヘッダーを使用します （共有の diff/scripts/live-session.mjs に組み込み済み）。 チャレンジ／ブロックのインタースティシャル画面、または2xxの拒否ページは **明示的に失敗（exit 3）**させ、測定しません — --headed でエスカレーションします。 それでもブロックするサイトには crawl.mjs クラスのキャプチャが必要です。 ライブターゲットでは domcontentloaded を使い、networkidle は使いません。 両側で対称に --main のスコープを設定します（--main body は決して有効ではありません）。 --dismiss ですべてのオーバーレイクラスを解除します（同意通知と時間指定のマーケティングモーダルの両方）。 キャプチャ中はアニメーションを停止します。 解除クリック後はポインターを所定位置に移動します。 固定／スティッキーな chrome は固定状態で再現し、スクロール状態による変化も再現します （reference/recreation-procedure.md § Fixed and sticky chrome）。 JOIN/SPLIT の誤検知による赤判定には粒度の同等性に関するポリシーを適用します（#87）。 CDN-403 の画像およびハイドレーション用プレースホルダーにはキャプチャ状態のポリシーを適用します （キャプチャどおりに再現し、記録します）。DOM／スタイルのキャプチャでは検出できず、 ゲートでのみ検出される不具合クラスは2つあります。内側の span における描画フォントの不一致 （幅プローブ）と、計算済みスタイルからは見えないオーバーレイのスクリーン （行ごとの輝度フィッティングで特定します）。 ライブターゲットの強化は、live-session.mjs を基盤とする差分スクリプトのフラグ（--ua、 --wait-until、--dismiss、--headed、--locale、ビジュアル差分の --main）として提供されます。スクリプトをコピーしてフラグを渡してください。手編集を加えたプロジェクトコピーは欠陥です （reference/source-fidelity-gate.md § スクリプトの調整）。

静的ゲートの通過後、操作の同等性はアーキタイプごとに必須のゲート出力です ――ゲート通過後の作業ではありません （reference/recreation-procedure.md § 操作の同等性）。モーションは静的クラスや CSS から推測せず、必ず観察します。アーキタイプごとにライブ URL で stardust/scripts/replica/motion-observe.mjs を実行し → stardust/replica/motion/<slug>.json を作成します。発生した動作のみを実装します（動作しないクラスは未実装）。その後、同じ順序で同じ --click／--hover の操作を行い、配信するプロトタイプを観察して（→ stardust/replica/motion/<slug>-build.json）、2 つのファイルをレポーターである stardust/scripts/replica/motion-compare.mjs で比較します。これはゲートではありません（ヘッダーの挙動はヘッダーの契約に従います）。MISSING または EXTRA の行はクラス行で確認し（サンプラーはクラスの切り替えや疑似要素の仕組みを検出しません）、プロトタイプで解決するか、動作しないものとして記録します。progress.json に motion: {observed, implemented, dead[]} を記録し、pixel-compare を再実行します。数値はゲートで確認した値に戻る必要があります。 ウィジェットは実装するものであり、正当化して省略するものではありません。コンポーネントに作成済みのコンテンツがない場合は、EDS では widgets/<path>/<name> として実装し、空の行を持つブロックにはしません。 タイマー駆動のメディアも発生した動作として扱います（自動再生／ループ動画、自動で切り替わるスライド ― 観察 JSON の media ブロック）。キャプチャ時の停止状態は captureState[].restoreAtDelivery として記録し、仕様としてそのままリリースせず、復元した状態で配信します。 ファンアウト用ブリーフには、エビデンスのルールと計測ツールの呼び出しをそのまま記載します。

すべてのブレークポイントを通過したら、標準のプロトタイプ承認フローに従い、承認を得るためにアーキタイプとそのゲート指標を提示します（ハンズオフモードでは、../stardust/reference/state-machine.md に従い approvedBy: "hands-off" を記録します）。 記録処理はそれぞれ 1 つのコマンドで行い、手書きの JSON 行や node -e による state.json のインライン編集は決して行いません。 node stardust/scripts/stardust/state.mjs advance <slug> --to approved --by hands-off --prototype stardust/prototypes/<slug>-proposed.html および node stardust/scripts/stardust/ledger.mjs replica source-fidelity-gate end --detail "<per-breakpoint numbers>" を実行します。実行を再開する際は、cat ではなく ledger.mjs tail と state.mjs summary --slugs から始めます。 このスキルのすべてのフェーズ（extract と preserve-direction を含む）は、フェーズのスクリプトを実行する前に、最初のコマンドとして node stardust/scripts/stardust/ledger.mjs replica <phase> start を実行します（記録済みのハンズオフ実行では、109 分間作業した後にフェーズの start が end の隣に記録され、監督者には何もしていないように見えました。ledger.mjs は --strict の下では、開始済みの start がない end を拒否します）。また、end 行と、stardust/journal.md の ## <Phase name> — <what happened> (<date>) という見出しを付けたセクションをもってフェーズを終了します。このセクションはフェーズの end の一部であり、見つからない場合は ledger.mjs … end が警告します（記録済みの実行では、ジャーナルが 2 回目のセッションから始まっていたものもあれば、実行全体で 1 つのセクションしかなかったものもありました）。

フェーズ 5 — 引き継ぎ（委任 — 移行 → デプロイ → ロールアウト、変更なし）

• まず契約カードを読む：reference/handoff-contract.md — このフェーズで必要な、移行／デプロイ／ロールアウトの要点をまとめたルール、ロールアウト台帳の正確なフェーズ文字列（A-inventory … I-dashboard）、デプロイおよびロールアウトスクリプトごとの使用例（1 行）、帳簿管理用コマンドが記載されています。兄弟の SKILL.md ファイルを丸ごと読むことは避けてください（ある記録済みセッションでは、最初の Phase 5 出力の前にそれらを 26 万文字分読み、その後、あふれた分も読み直しました）。手順に詳しい説明が必要な場合に限り、section.mjs で該当セクションを取得してください。
• アーキタイプ以外のページは、アーキタイプが公開オリジンで稼働し、ゲートを通過した後に限り（契約 § 3 の行 C、ユニット C-archetype、#126）、stardust の migrate スキルを兄弟ページ向けの階層（../migrate/reference/fidelity-tiers.md）で適用します。構造的クローンをエンコーダーへの入力として使用し、コンテンツ忠実度、デリバリー lint、メディア照合を行います。兄弟ページでカウントされる数値は、PUT とプレビュー後のゲート行のみです（ローカルのピクセル基準はありません）。兄弟ページは、実証済みのアーキタイプのエンコーダーを引き継ぎます。エンコーダーを新たに作成してはいけません。テンプレートの一定性は仮定せず、測定します。クローンする前に、テンプレートごとに一度 stardust/scripts/replica/sibling-variance.mjs <archetype> <siblings…> --probe <block>=<sel> … を実行し、すべての差分を兄弟ページのコンテンツ上のブロック VARIANT クラスとして予算化します（同じファイルの § Sibling variance probe）。コンテンツ忠実度はインポート時にページごとに測定します（同じファイルの § Content-count acceptance）。これにより、修正コストが低いうちにインポーターのバグを検出できます。
• デリバリーは、ページごとに stardust の deploy スキルで行います。固定構成のセクションでは、デコード層をテンプレートスロット方式に寄せてください（deploy #95）。レプリカのセクションは、稼働中のオリジナルに一致させた固定構成です。繰り返しグループ（カード、リスト）は再構成方式のままにします。ブロックは Experience Workspace の編集可能性に関する契約（deploy § 8、EW1–EW10：値ではなくノードにスロットを設定）に準拠し、block-roundtrip --ew を通過します。
• サイト全体のロールアウトは、変更せずに stardust の rollout スキルで行います。ブロックの重複排除によって、「サイト全体で同じブロック」を実現します。
• ターゲットのブレークポイント： C0 で基盤と再利用ブロックをターゲットのステップに合わせて作成し、breakpoint-lint.mjs を npm run lint に組み込みます（reference/handoff-contract.md）。これにより、デプロイとロールアウトのすべての lint 実行で準拠を検証します。
• C-deliver はユニット単位で実行します（reference/handoff-contract.md § 3、行 C ＋ Fan-out discipline）：C0 — 1 つの基盤サブエージェントが基盤を作成し、デプロイします。メインエージェントは、ヘッダー契約も含めて（chrome-compare の終了コードが 0、../diff/SKILL.md § The header contract）、公開オリジンでシェルのゲートを通過させ、その後 foundation-freeze.mjs freeze を実行してコミットします。C-archetype — テンプレートごとに、ゲートを通過したアーキタイプをデプロイし、プレビュー URL で完全なゲート行を通過させます（修正は最大 3 ラウンド。その後は再プロトタイプ化を判断）。その後に兄弟ページをレンダリングします。C1…Cn — テンプレートのクラスターごとに 1 つのサブエージェントが、PUT → プレビュー → 公開オリジンのゲートを含む一連の工程全体を実行し、独自のバッチ台帳（ロックセーフな deploy-batch.mjs --ledger …）を使って、判定を 1 行で報告します。メインエージェントは調整と記録のみを行います。C-final — check、キューに登録された foundation-requests.md の行を一度だけ適用、C-deliver end。各ユニットは stardust/rollout/progress.json に記録してコミットします。これは安全に再開できるポイントですが、これだけを理由にセッションを終了してはいけません。進行中のウェーブでは、凍結済みファイルを編集しません。
• 最終ゲートはハーネスではなく、公開オリジンに対して実行します （reference/source-fidelity-gate.md § The published-origin gate）：まずデプロイ（PUT → preview）し、その後 run-bg.mjs を介して gate.sh <slug> "$LIVE" "<preview-url>" <width> pub1 --full --marker "<brand or domain string>" を、通常の gates/<slug>-<width>/ ディレクトリ内で pub<N> ラベルを付けて実行します（新しいディレクトリを使うと、ライブキャプチャーを取り直すことになります）。ローカルハーネスでは、ピクセルに関する処理を実行しません。ローカルハーネスの用途は qa-gate／block-roundtrip のみです。
• デリバリーゲートは全ページを対象とする実行であり、ピクセル値だけではなく、4 つの基準で判定します （reference/source-fidelity-gate.md § The all-pages published-origin gate、#125）：run-bg.mjs を介して node stardust/scripts/replica/gate-all.mjs [--only <slug,…>] [--skip-existing] [--eds-host <host>] を実行します。DELIVERED の条件は、ピクセル % ≤ 10、|Δh| ≤ 5 %、クリップされたテキスト／コントロールが 0 個（clip-probe）、MISSING／HIDDEN のリンク／見出しが 0 個（content-presence）です。記録上はピクセル基準を通過していたものの、すべてのカードがクリップされていたページもありました。エビデンスとサイドカーは stardust/replica/gates/all-<width>/ にあります。Phase 4 の prototypes-<width>/ テーブルと合わせて、gate-evidence.mjs が読み込む一組になります（行のないページはゲート未通過です）。各クラスターのサブエージェントは、ファンアウト内で自分のページを対象に --only を実行します。C-final のロスター実行は、記録対象のユニット gate-all（--skip-existing、キャプチャーを再利用）で行い、続けて update-coverage.mjs --gate を実行します（handoff contract § 3、行 C）。 状態： replica は独自の状態を stardust/replica/ の下に保存します。不整合レジスター、progress.json（1つのマップ：types.<archetype> — ページタイプ、使用した反復回数、ブレークポイントごとのゲート結果、残差、モーションインベントリー — gate-evidence.mjs の siblings / migrate と並列に配置し、エントリーごとに拡張し、置き換えは行いません）、motion/<slug>.json、および gates/<slug>-<width>/ のエビデンスです。 デリバリーゲート（#125）では gates/all-<width>/ が追加されます。デプロイ済みページごとに1つのディレクトリ（origin.png、eds.png、diff.png、pixel.json、content.json、clip.json、units.json）、summary.{json,md}、--only 実行用の runs/、およびドキュメントに記載されたサイドカー（masks.json、overrides.json、clip-allow.json、presence.json、units.json）です。 Phase 5 では stardust/rollout/ の下に3つのファイルが追加されます。progress.json（C-deliver ユニット台帳 — 各ユニットのステータス、ゲート、判定）、foundation-freeze.json（凍結された基盤の sha256 マニフェスト）、および foundation-requests.md（C-final で一括適用される、保留中の基盤変更リクエスト）です。パイプラインのステータス（extracted → prototyped → approved → migrated）は、標準の状態機械に従い、コアの state.json に保持されます。replica がこれを再定義することはありません。

replica が決して行わないこと

• 再設計しません。 新しいカラーパレット、書体、間隔、構成、モーションは追加しません。ターゲット仕様は、キャプチャした現状です。
• コンテンツを書き換えません。 キャプチャした文字列はそのまま使用します。プレースホルダーとハイドレーション状態も「修正」せず、キャプチャした状態を再現します。
• 改善を捏造しません。 不整合レジスターに記載のない変更は、どれほど洗練されていても欠陥です。
• DOM をコピーしません。 ライブ DOM を貼り付けたり、ページ単位の CSS をプロトタイプとして移植したりしません（それはスノーフレークの逃げ道であり、このスキルの目的ではありません）。クリーンに再構築することが目的です。再実装の価値を生まないバイト単位の忠実性は、移行の価値を損ないます。

出力

stardust/
├── state.json                          ← core state machine (unchanged contract)
├── direction.md                        ← preserve-mode record (Phase 2)
├── current/                            ← from extract --prep
├── prototypes/<slug>-proposed.html     ← gated archetypes (one per page type)
├── replica/
│   ├── inconsistency-register.md       ← the ONLY permitted design deltas
│   ├── breakpoint-map.md               ← source → target breakpoint map (only with --target-breakpoints)
│   ├── progress.json                   ← per-page-type ledger: iterations, gate results, residuals, motion inventory
│   ├── motion/<slug>.json              ← motion-observe evidence
│   └── gates/<slug>-<width>/           ← live.png, proto.png, diff.png, probe outputs per iteration
├── migrated/                           ← from migrate (Phase 5)
└── rollout/                            ← from rollout (Phase 5); coverage/, plan.json … per its SKILL.md
    ├── progress.json                   ← C-deliver unit ledger: status, gates, verdict per unit
    ├── foundation-freeze.json          ← sha256 manifest of the frozen foundation (C0 → C-final)
    └── foundation-requests.md          ← queued foundation change requests, applied once at C-final

PRODUCT.md / DESIGN.md / DESIGN.json    ← promoted verbatim from current/ (Phase 2)

参考資料

• reference/preserve-direction.md — 機械的な昇格の契約と、不整合レジスターのエントリースキーマ。
• reference/recreation-procedure.md — CSS の抽出方法（ゲートのブレークポイントごと）、フォントポリシー、スクラム／輝度の復元、span-face の分岐、キャプチャ状態のポリシー、折り返し接合部のマージン、固定／スティッキーなクローム、粒度の同等性、役割の同等性（各文字列についてライブ表示を再現）、インタラクションの同等性（モーションは推測せず観察し、Swiper-lock を適用）、CSS 移植のフォールバック条件。
• reference/source-fidelity-gate.md — ゲートの完全な契約：コマンド、しきい値、ブレークポイントごとの手順、堅牢化ルール、帯域別内訳の読み方（セクションアンカーの内側のループを含む）、反復の規律、公開済みオリジンのゲート（EDS パイプラインの差分）、残差の記録形式。
• ../diff/SKILL.md — replica が再利用する2つのプローブ（--profile generic）；content-diff 出力の読み方；#87 の JOIN/SPLIT の制限。
• ../extract/SKILL.md § Prep mode — Phase 1 が提供する内容。
• reference/reading-discipline.md — 読み取りと検査に関するルールの全容：各ヘルパーが読み取る対象、画像ルール、その根拠となるエビデンス。
• reference/handoff-contract.md — Phase 5 の契約カード：同階層の手順、デプロイの編集可能性／デコード／DA プロトコル、台帳フェーズ文字列を含むロールアウトフェーズ A～I、デプロイおよびロールアウトスクリプトごとの使用方法の記載行、記帳コマンド。
• ../stardust/scripts/ledger.mjs、../stardust/scripts/state.mjs — 台帳および状態の書き込みスクリプト（プロジェクト内のコピーは stardust/scripts/stardust/ にあります）；各スクリプトの --help。
• ../migrate/reference/fidelity-tiers.md — Phase 5 が引き継ぐアーキタイプ／同階層モデル。
• ../deploy/SKILL.md § decode tiers (#95) — テンプレートスロットにおけるバイアス。
• ../stardust/reference/scripts-index.md — 提供されるすべてのスクリプトを1行ずつ記載した一覧（処理内容、主要なフラグ）；--help を実行する前に読んでください。