reskin

stardust:reskin — 同じコンテンツに、ドナーのデザインを適用

ユーザーはサイト（コンテンツソース）と、すでに別の場所にあるデザイン（別の公開サイト、または静的 HTML プロトタイプのディレクトリであるドナー。Figma は今後の対応範囲です）を用意します。Reskin は、表示されるコンテンツのすべてのバイト（テキスト、順序付き画像、CTA、SEO メタデータ）を維持したまま、サイトのページを再構築します。一方、ページの表層はすべてドナーのトークンとモジュールの語彙から構成します。

両者には異なる条件があります。

• コンテンツは譲れません。 ゲートで確認するのは、空白を正規化した表示テキスト、順序付きの表示画像セット、メタデータの完全な引き継ぎがバイト単位で一致することです。「ほぼ一致」ではなく、明示的に宣言された実行可能な正規化台帳に基づいて一致する必要があります。
• デザインには柔軟性があります。 コンテンツはドナーのモジュールに合わせて再レイアウトされます。カルーセルが静的なカードグリッドになったり、サイドバーがバンドになったりすることがあります。構造（要素数、タグの並び）は参考情報であり、ゲートの判定条件ではありません。再スキンでは意図的にマークアップを再構成するためです。

決定的なルールは、UC2-E1 の実験（ヘルスケアサイト × フィンテックのドナー：2281/2281 テキストバイト、7/7 画像、47/47 スロット、13/13 メタデータ、17/17 ドナートークンのプローブ）で検証されています。ページは取得したコンテンツモデルからプログラムで生成し、コンテンツ文字列を手入力しないこと。 この方法ならバイト単位の忠実性を構造上保てるため、コンテンツゲートはデバッグ用ではなく、リグレッションチェックになります。

入力

• <content-url> — 必須。コンテンツを保持するサイトです。
• ドナーは次のいずれか 1 つです。
  • --donor <url> — デザインシステムを採用する公開サイトです。
  • --donor-dir <path> — ローカルの静的 HTML プロトタイプ（claude-design / Mobirise / Relume / Lovable / v0 / 手書きコード）のディレクトリです。localhost で配信し、同じ経路で取得します — 手順は reference/donor-sources.md § ローカルプロトタイプを参照してください。
  • --donor-figma <url> — まだ実装されていません。 仕様は定義済み（reference/donor-sources.md § Figma）ですが、アダプターは今後の対応範囲です。ユーザーには、次のとおり正確に伝えてください。"Figma ドナーはまだ実装されていません。フレームを静的 HTML プロトタイプとしてエクスポートするか（または、デザインのステージング用公開 URL を指定して）、--donor-dir / --donor を使って再実行してください。Figma アダプター — variables→palette、text styles→type、frame screenshots→vision references、provenance class figma-mcp — は skills/reskin/reference/donor-sources.md に仕様があり、今後のリリースで提供予定です。" Figma の取得を一部だけ独自に実装しないでください。
• --pages <slug,slug,...> — 任意。コンテンツの取得対象を特定のページに限定します。デフォルトは archetype セット（ページファミリーごとに 1 ページ。spec の archetypes.json に記載されています。類似ページへの展開は Phase 6 で migrate を使って行います）です。
• --scope <selectors> — 任意。単一ページの実行で、コンテンツルートのスコープを事前に宣言します（カンマ区切り。末尾に ! を付けるとスコープ全体を保持します。reference/content-model.md § スコープ宣言を参照してください）。指定しない場合は、ページごとにスコープ検出手順を実行します。

セットアップ

1. マスタースキルのセットアップを実行します（../stardust/SKILL.md § Setup）。 依存関係のチェック、コンテキストの読み込み、状態の読み取りを行います。フロー。 未設定の場合は state.json.flow: "reskin" を記録します （../stardust/reference/state-machine.md § Flow keys）。別の フローが設定されている場合は、実行せずにそのフローと切り替えコマンド （$stardust reskin --switch-flow）を表示します。
2. Playwright のインポート解決可能性プローブ — 次と同じ仕様です： ../extract/SKILL.md § Setup。 プロジェクトのルートから node -e "import('playwright').then(()=>process.exit(0))" を実行し、失敗した場合は npm i -D playwright --no-save --legacy-peer-deps を実行します。レンダリングを行う各フェーズの開始時に、プローブを再実行してください。後続の実際の npm i によって、--no-save でインストールしたパッケージは削除されます。
3. スクリプトをプロジェクトにコピーします。 ESM は import('playwright') を スクリプトの ディレクトリから解決しますが、プラグインツリーには node_modules が含まれていません。skills/reskin/scripts/*（5つのファイルすべて — capture-content.mjs と dom-equality.mjs は兄弟ファイルとして source-normalize.mjs をインポートします）を stardust/scripts/reskin/ にバイト単位で同一のままコピーし、さらに skills/diff/scripts/live-session.mjs を stardust/scripts/diff/ にコピーします。すべての reskin ゲートスクリプト（capture-content、dom-equality、donor-probe、および slot-coverage）は、対象の種類にかかわらず起動時に必ずこれをインポートします。コピーがない場合、--help やローカルファイルの --rendered 対象であっても、各スクリプトは直ちに終了コード 2 で終了します。これはすべてのライブ対象向けの強化機能（実際の Chrome の UA と標準ヘッダー、チャレンジ検出、ヘッド表示のステルス強化）を提供し、../reskin/ の隣にある ../diff/ から解決されるため、この2つのディレクトリは兄弟のままにしてください。コピーを実行します。
4. オリジンの衝突 — stardust/state.json に別の site.originUrl が記録されている場合は、サイトを混在させる前に停止して確認を求めてください（../extract/SKILL.md § Setup に従います）。

手順

フェーズ 1 — ドナーを取り込む

ドナーのデザインシステムはコンテンツサイトとは別に取得し、stardust/canon-source/ に保存します。ドナーの種類ごとの詳しい手順は reference/donor-sources.md に記載されています。概要は次のとおりです。

• ライブ URL（--donor <url>）：
  $stardust extract <content-url> --design-source <donor-url> を実行します。既存のスキルをそのまま使用します。結果は stardust/canon-source/ に保存されます。内容はドナーの pages/、assets/（スクリーンショットを含む）、_brand-extraction.json、_crawl-log.json、説明的な DESIGN.md と DESIGN.json です。また、state.json.designSource = { url, capturedAt, path } が記録されます。../extract/SKILL.md § クロスサイトのブランドソースを参照してください。
• ローカルのプロトタイプディレクトリ（--donor-dir <path>）：
  ディレクトリを localhost で配信し（python3 -m http.server <port> --directory <path>）、localhost のオリジンに対して同じ --design-source 取得パスを実行します。実際の出所（<path> を localhost で配信したこと）を canon-source/_crawl-log.json に記録します。ページ一覧、index のないディレクトリ、ポートの管理については、reference/donor-sources.md § ローカルのプロトタイプを参照してください。
• Figma（--donor-figma）：
  将来対応予定です。§ 入力に記載されたメッセージをそのまま表示して停止します。

続いて、reskin が所有する次の 2 つのドナー成果物を作成します（仕様は reference/donor-sources.md を参照）。

• stardust/reskin/donor-tokens.json — 厳選した、プローブで検証可能なトークンシートです。パレットの役割、文字サイズの段階、レイアウト指標、ボタン仕様、角丸、シャドウ、モチーフを含みます。各値は Phase 5 のプローブでそのまま検証できる computed-style 文字列です。canon-source/DESIGN.json、_brand-extraction.json、生の computed style から厳選し、各値の取得元となったドナーページを記載します。範囲を限定したドナー取得（ドナーの単一ページで、--design-source を全面実行しない場合）では、DESIGN.json、_brand-extraction.json、designSource の記録は存在しないため、ドナーのページから raw computed-style をサンプリングしてトークンシートを作成します。これは第一級の並行パスです（reference/donor-sources.md § トークンの調達における 2 つの第一級パス）。
• stardust/reskin/donor-modules.md — 列挙されたモジュール語彙（M1..Mn）です。ドナーの各モジュールにつき 1 行を設け、確認できる箇所のスクリーンショットを証拠として示し、構造を説明します。これが、Phase 3 のマッピング概要で対応付ける確定済みの集合です。

参照ページを 1 つ固定するルール（必須）。 実際のドナーでは、複数のデザインシステムが並行して使われていることがあります。実験で使ったドナーは、ホームページでは半径 4px／1266px、古い製品ページではピル型の角丸／1080px を採用していました。これらを統合すると、実際に公開されたことのない合成デザインになり、トークンプローブの検証対象もなくなります。ドナーページ間でトークンに違いがある場合は、モジュールファミリーごとにドナーの参照ページを 1 つ固定し、donor-tokens.json に記録してください（curatedFrom と、参照ページを明記した注記を含めます）。その他のページは補強資料として扱います。

フェーズ 2 — コンテンツモデルのキャプチャ

新しい機能は、各コンテンツページをバイト単位でキャプチャすることです。extract のデザイン指向のキャプチャとは異なります。移植したキャプチャスクリプトをページごとに実行します。

node stardust/scripts/reskin/capture-content.mjs \
  --url <page-url> \
  --scope '<sel1,sel2!,...>' \
  --normalize stardust/reskin/normalize/<slug>.mjs \
  --out stardust/reskin/content-model/<slug>/

stardust/reskin/content-model/<slug>/content-model.json に出力されます（契約の全容は reference/content-model.md を参照）。セクションスロットごとの見出しとレベル、アイブローなどのその他の要素、本文の段落、リスト項目、絶対 href を持つ CTA、表示順の画像（currentSrc + alt）、および順序付きストリーム（ordered）が含まれます。これは、ネストと区切りフラグを持つ、ドキュメント順の種類タグ付きノードとして表した同一コンテンツであり、フェーズ 4 が使用するレンダリングサーフェスです。ページレベルでは、SEO メタデータ全体（title、description、canonical、OG、Twitter、JSON-LD、lang、favicon）、スコープ内の空白を正規化した可視テキスト（コンテンツゲートの参照文字列）、およびページ全体のスクリーンショットが含まれます。

実験で最も多かった 2 つの失敗を防ぐため、ページごとに次の 2 つの宣言が必須です。

1. CONTENT-ROOT SCOPE 宣言。 安易なスコープ設定では、実験ページのコンテンツの 30% が気付かれないまま欠落しました。ヒーローとバナーのカルーセルが <header> 内にあり、明白な #content ルートの外側に配置されていたため、不完全な参照データとのバイト一致が「合格」してしまいました。main や #content を無条件に信頼しないでください。スコープ検出手順（reference/content-model.md § Scope discovery）に従って、キャプチャしたスコープのテキストを body 全体のテキストおよびページのスクリーンショットと比較し、h1 がスコープ内にあることを確認します。カンマ区切りの複数スコープセレクターを使って範囲を広げ、宣言済みのクロームではないスクリーンショット上の可視要素がすべてモデルに含まれるようにします。クローム（nav、footer）の除外は、暗黙に省略するのではなく、D1 形式の差分として宣言します。キャプチャスクリプトは、確認を機械的に行えるよう、カバレッジ行（bodyTextLen / scopeTextLen / h1InScope）を出力します。
2. 実行可能な正規化台帳。 Cookie 同意画面のクロームの除去、カルーセルの重複除去（非表示のスライドは innerText に含まれませんが、複製スライドは重複するため、回転するカルーセルではバイト単位の決定性が崩れます）、およびページ固有のクリーンアップは、共有デフォルト（scripts/source-normalize.mjs）を拡張するページごとの台帳モジュール stardust/reskin/normalize/<slug>.mjs に記述します。同じ台帳ファイルをキャプチャとすべてのゲートにそのまま渡す（--normalize）ことで、ゲートはキャプチャで宣言した正規化とまったく同じ処理を検証します。台帳は説明文ではなくコードです。形式については reference/content-model.md § Normalization ledger を参照してください。

フェーズ 3 — マッピング概要

stardust/reskin/mapping.md を作成します。これは、オリジンをまたぐマッピング概要です。 契約全体とエントリーのスキーマについては、reference/mapping-brief.md を参照してください。コンテンツモデルのすべてのコンテンツスロットについて、次を記載します。

• 割り当てるドナーモジュール ID（donor-modules.md のクローズドボキャブラリーから選択）と、スロットの構造とモジュールの構造に基づく1行の根拠。
• ステータス ∈ {mapped, new-module, chrome, carried-invisible}。最後のステータスは、バイトスコープ内の sr-only／visually-hidden コンテンツに使用します（同等の非表示要素にそのまま引き継ぎ、ドナーモジュールは割り当てません。reference/mapping-brief.md § Status semantics を参照）。

レンダリング前のゲート：

• コンテンツスロットの 80% 以上を、名前付きドナーモジュールに mapped として割り当てます。それを下回る場合、ドナーボキャブラリーではこのコンテンツを網羅できません。そこで停止し、問題を提示してください（§ Stop conditions を参照）。
• すべての new-module エントリーは、ドナートークンから明示的に構成し（借用するトークンを明記します。例：入力仕様＋プライマリボタン仕様）、概要の統計ブロックに記載します。新しいモジュールをレンダリング中にひそかに即興で作ることはできません。
• Chrome の置換について記録します。ナビゲーション／フッターを、ソースのリンクを引き継ぐドナーの Chrome に置き換える場合は、宣言済みの差分とし、コンテンツゲートの対象外とします。
• 大文字・小文字の扱い／text-transform ポリシーを宣言します。ドナーによって見出しラベルが大文字でレンダリングされる場合や、ソースでそうなっている場合があります（Chrome の innerText には text-transform が反映されるため、取得されるテキストは レンダリング後の大文字・小文字 です）。元のテキストはバイト単位で忠実に維持し、大文字・小文字の変換には CSS の text-transform のみを適用します。文字列自体を編集してはいけません。ポリシーの詳細は reference/mapping-brief.md § Casing policy を参照してください。

複合的なソースセクション（1つのラッパー div に2つの論理領域が含まれるもの）は、概要内でアトミックなスロットに分割します。セクションとスロットは同じではありません。

フェーズ 4 — プログラムによるレンダリング

検証済みの決定的なルールは、ページは content-model.json から生成するものであり、決して手作業で書き直してはならないということです。各アーキタイプごとに、実験用の render-reskin.mjs を参考にしたレンダラースクリプト（stardust/reskin/renderers/<archetype>.mjs）を作成します。このスクリプトは次の要件を満たす必要があります。

• ページの content-model.json を読み込み、表示されるすべての文字列、href、画像 URL をモデルから補間します（HTML エスケープすること）。出力 HTML に文字列があるのにモデルに存在しない場合、レンダラーは誤りです。
• 各スロットの構造は、順序付きストリーム（sections[].ordered、reference/content-model.md § The ordered stream）から取得します。つまり、種類をタグ付けされたノードをドキュメント順に並べ、ネストを保持し（CTA が見出しを包む場合も、その逆の場合も）、sep フラグで区切り文字なしのインライン結合を示します。このストリームは構造上、innerText と整合しています（そのテキストノードは親のレンダリング済み innerText から切り出されており、これがバイトゲートの基盤です）。そのため、そのまま出力しても安全です。ノードはストリームの順序で出力します。隣接するノードの sep: "" は空白を入れずに出力します（インライン）。順序を入れ替えず、visibleText から順序や区切り文字を再構築しないでください。最初のフィールド実行ではまさにこれを行い、型ごとの配列をオラクルとして visibleText に貪欲に照合した結果、同一の文字列が重複するケース、CTA とコンテナーの両方向のネスト、区切り文字のないインラインの li の連続という問題に対処するため、デバッグを 3 ラウンド行うことになりました。これらの構造はすべて、現在のストリームで保持されています。
• formControl ノードはテキストではなく、同等のコントロールとしてレンダリングします。取得したオプションテキストをそのままの順序で保持する <select>、および値／プレースホルダーを保持する入力欄／テキストエリアを使用し、ドナートークンで再スタイルします（新規モジュールの合成ルールを適用します）。文章に平坦化したり、削除したりしてはなりません。select のオプションテキストはソースの innerText の一部です。そのため、コントロールを削除すると、構造化してレンダリングできる情報が何もないままバイトゲートに失敗します（reference/content-model.md § Slot taxonomy, formControls）。
• メタデータブロックをそのまま <head> に引き継ぎます（title、description、canonical、OG、Twitter、JSON-LD を含みます。URL が壊れている JSON-LD など、ソースに含まれる不備も含めて、修正より忠実性を優先します。そのような項目は実行レポートで人間向けにフラグを立て、黙って修正したり、そのまま残したりしてはなりません）。
• 表層のデザインには、donor-tokens.json（CSS カスタムプロパティとして出力）と、mapping.md で割り当てたドナーモジュールパターンのみを使用します。フェーズ 5 のプローブで検証するレンダリング済みページの規約に従います。コンテンツは <main> 内に置き、幅の基準には .container、ドナーのプライマリボタンには .btn を使用します（reference/gates.md § Rendered-page conventions）。
• stardust/reskin/pages/<slug>.html に自己完結型のファイルとして書き出します。

レンダラーは単一ノードのテキストを分割して解析してもかまいません（リスト項目の行をキッカー／日付／タイトルに分割するなど）。ただし、解析結果がノードのテキストと一致しない場合は、必ずエラー（throw）で明示的に失敗させてください。解析の一部だけに成功しても黙認すれば、コンテンツが黙って欠落します。orderedVerified が false のスロットは、レンダリング前に確認し、無条件に信頼してはなりません。確認の結果、ストリームのテキストがスロットの visibleText に実際に存在しないと分かった場合、許可されているフォールバックは、そのテキストをレンダリング前に削除し、モデルの来歴に削除を記録することです。visibleText と照合してゴーストを除外する方法は文書化された解決策であり、禁止されている順序の再構築とは異なります（reference/content-model.md § When orderedVerified is false）。

フェーズ 5 — ゲート

ページごとに 3 種類のゲートがあります。コマンド、合格基準、許容範囲、失敗モードについては reference/gates.md を参照してください。レンダリングしたページをサーバー経由で、または file:// でアドレス指定して、次を実行します。

(a) コンテンツゲート — 3 つすべてに合格する必要があります。

node stardust/scripts/reskin/dom-equality.mjs \
  --source <page-url> --source-scope '<declared scope>' \
  --normalize stardust/reskin/normalize/<slug>.mjs \
  --rendered stardust/reskin/pages/<slug>.html --rendered-scope main \
  --report stardust/reskin/reports/<slug>-content-gate.md
node stardust/scripts/reskin/slot-coverage.mjs \
  --model stardust/reskin/content-model/<slug>/content-model.json \
  --rendered stardust/reskin/pages/<slug>.html \
  --report stardust/reskin/reports/<slug>-slot-coverage.md

dom-equality.mjs（github.com/aemcoder/skills からベンダー提供され、適応したもの。Apache-2.0）は、空白を正規化した表示テキストのバイト単位の一致と、順序を維持し URL を正規化した表示画像の集合を基準に判定します。要素数とタグの並びは報告されますが、参考情報です。 slot-coverage.mjs はさらに、すべてのモデルスロットが存在すること（スロットテキストの部分文字列、すべての CTA を（テキスト、絶対 URL の href）のペアとして確認、すべての画像）を検証し、メタデータがフィールドごとに引き継がれていることをアサートします。

(b) デザイン採用ゲート：

node stardust/scripts/reskin/donor-probe.mjs \
  --tokens stardust/reskin/donor-tokens.json \
  --rendered stardust/reskin/pages/<slug>.html \
  --report stardust/reskin/reports/<slug>-donor-probe.md

レンダリングしたページで、ドナーのトークン値（背景色／前景色、フォントファミリーのトークン文字列、表示ウェイト、ボタン仕様、コンテナ幅、帯の配色、セクションのリズム）に対する計算済みスタイルのアサーションを行います。許容範囲（色／角丸／フォントファミリーは完全一致、ボタンのパディングは ±2px、コンテナは ±20px、セクションのリズムは ±16px）については reference/gates.md の「許容範囲」に記載されています。 続いて、並べて比較して判定します。レンダリングしたページをドナーの参考ページのスクリーンショット（canon-source/assets/screenshots/）の横に開き、ドナーのデザインが採用されているかを目視で判定します。プローブでトークンを検証し、目視でページがドナーのものとして見えることを検証します。判定結果を記録してください。

(c) サニティチェック — 1440px と 360px で横方向にはみ出さないことを確認します（donor-probe が自動で実行します。変更するには --widths を指定します）。

ゲートファミリーごとに修正は 1 回まで — コンテンツゲートで 1 回、デザイン採用／サニティチェックで 1 回です。あるファミリーで失敗した場合は 1 回修正し、すべてのゲートを再実行します（あるゲートの修正が別のゲートを壊すことがあります）。ファミリーの反復回数を使い切った後に残った失敗は、ページの residuals[] の下にある stardust/reskin/ledger.json に記録します。黙って受け入れたり、無期限に繰り返したりしないでください。（どちらの実地実行でも、この上限で対応できることが確認されました。検証実験では 360px のクロームに対して 1 回反復し、スモーク実行では各ファミリーにつきちょうど 1 回反復しました。内容側ではセパレーター出力を、サニティチェック側では 360px のクロームを修正しました。共通の反復回数を 1 回だけにすると誤った残存項目が発生していたところを、ファミリーごとに分けることで、実際の失敗を受け入れることなく反復を制限できます。）

フェーズ 6 — 引き継ぎ

Reskin がアーキタイプページを担当します。スケーリングとリリースは既存のパイプラインを変更せずに使用します。

• stardust の migrate スキル（../migrate/SKILL.md）でスケーリングします。ドナーを固定したターゲットを使用してください（フェーズ 1 で書き込まれた state.json.designSource のスタンプは、ドナーを固定するために direct／migrate が読み取るものと同じです。範囲を限定したドナーキャプチャではスタンプが書き込まれないため、代わりに引き継ぎでドナーの出所を記録してください。reference/donor-sources.md の「2 つの主要なトークン取得経路」を参照してください）。 同じタイプの兄弟ページは、ゲートに合格したアーキタイプを基準に兄弟ティアでレンダリングします。コンテンツのルールは、reskin がすでに適用しているものを使用します。../migrate/reference/content-preservation.md がそのまま継承されます。
• stardust の deploy および rollout スキルでリリースし、変更は加えません。ドナーモジュール向けに作成したブロックは、Experience Workspace の編集可能性に関する契約（deploy SKILL.md の § 8、EW1–EW10）に従い、作業完了前に EW ゲート（block-roundtrip --ew）に合格する必要があります。

Reskin は独自の状態を stardust/reskin/ に書き込みます。ledger.json にはページごとのステータス（captured → mapped → rendered → gated）、ゲートの結果、残存項目が記録されます。Reskin はコアの状態遷移マシン（../stardust/reference/state-machine.md）を変更しません。state.json に触れるのは、フェーズ 1 で extract 自体が書き込む designSource のスタンプだけです。

reskin が決して行わないこと

• コンテンツの書き換えや要約は行いません。 見出しも本文も、 CTA ラベルも、大文字・小文字の編集も行いません。忠実であることは 整っていることとは異なります。ソースの不備はそのまま引き継ぎ、 修正せずに フラグを付けます。
• セクションを新たに作りません。 レンダリングされるすべてのスロットは コンテンツモデルのスロットに対応し、すべてのモジュールは donor-modules.md または mapping.md の明示的な新規モジュール項目に対応します。
• ドナートークンから逸脱しません。 色、フォント、角丸、間隔は donor-tokens.json に含まれるものに限定されます。ライセンスされたドナーのフォントは、 ローカルフォールバックを付けてファミリーの トークン文字列 として採用し、 バンドルし直すことはありません。
• スロットを黙って削除しません。 ゲートの対象範囲から除外するものは、 明示的なクローム差分または台帳の正規化として宣言します。宣言は mapping.md に記載し、normalize モジュールで実行可能にします。

停止条件

• ドナーのキャプチャに失敗した場合（ヘッド付きフォールバックでもボットによるブロックを回避できない、 prototypes ディレクトリを配信できない）— extract のエラーをそのまま提示します。
• マッピング率が 80% 未満の場合 — ドナーの語彙ではこのコンテンツを扱えません。 次のどちらにするか確認します。ドナーのキャプチャ範囲を広げる（ドナーページを増やす → モジュールを増やす）か、 明示的な新規モジュールのリストを増やすことを受け入れるか。
• 対象範囲を決定できない場合 — コンテンツページの可視コンテンツを どのセレクターセットでもカバーできません（シャドウ DOM の多用、iframe に埋め込まれた コンテンツなど）。スクリーンショットの証拠とともに提示します。
• Figma ドナーを求められた場合 — 今後の対象範囲です。正確なメッセージは § Inputs にあります。

出力

パス	用途
stardust/canon-source/	ドナーのキャプチャ + 説明的な DESIGN.md/json（extract --design-source、変更なし）
stardust/reskin/donor-tokens.json	1 つの参照ページに固定された、プローブ可能な厳選トークンシート
stardust/reskin/donor-modules.md	スクリーンショットの証拠付きで列挙したドナーモジュールの語彙（M1..Mn）
stardust/reskin/content-model/<slug>/content-model.json	ページごとのバイト指向コンテンツモデル（+ ソースのスクリーンショット）
stardust/reskin/normalize/<slug>.mjs	ページごとの実行可能な正規化台帳（キャプチャとゲートで共有）
stardust/reskin/mapping.md	マッピングの概要：すべてのスロット → ドナーモジュール、ステータス、根拠
stardust/reskin/renderers/<archetype>.mjs	プログラムによるレンダラー（入力はモデル、出力は HTML）
stardust/reskin/pages/<slug>.html	レンダリングされた reskin ページ
stardust/reskin/reports/	ページごとのゲートレポート + スクリーンショット
stardust/reskin/ledger.json	ページごとのステータス、ゲート結果、残存項目
stardust/scripts/reskin/	5 つのスキルスクリプトのプロジェクトローカルコピー

参考資料

• reference/donor-sources.md — 3 種類のドナーとそのキャプチャ手順、 参照ページの固定、donor-tokens.json と donor-modules.md の仕様、Figma の今後の仕様。
• reference/content-model.md — キャプチャの仕様：スロットの分類、 順序付きストリーム（レンダリング対象面）、対象範囲の特定手順、 正規化台帳の形式、来歴。
• reference/mapping-brief.md — エントリースキーマ、≥80% のゲート、 新規モジュールの構成ルール、大文字・小文字の方針。
• reference/gates.md — 両ゲートのコマンド、合格基準、許容範囲、 失敗モード、残存項目の記録。
• ../extract/SKILL.md § クロスサイトのブランドソース — Phase 1 が委任する --design-source ドナーキャプチャの手順。
• ../migrate/reference/content-preservation.md — reskin が引き継ぐ コンテンツのルール（さらにバイトレベルまで厳格化）。
• ../diff/SKILL.md — ピクセルと構造のプローブ。Phase 6 のデプロイ後に ビルド側の補助チェックとして再利用します。--profile eds。