replatform

replatform

アクティブな移行プロジェクトを確認し、次の移行ステップをユーザーまたはエージェントに案内します（既定は migrations/<project>/ です。REPLATFORM_MIGRATIONS_DIR については CONVENTIONS.md を参照してください）。

目的

このスキルは、RePlatform 作業のトラフィックコントローラーです。アクティブな移行プロジェクトを特定し、信頼できるオーケストレーション成果物を確認して、次に必要な未決定事項または成果物を特定し、適切な内部リソースへ案内します。

各移行プロジェクトは完全に独立しています。実行中は、アクティブな migrations/<project>/ ディレクトリ内の成果物のみを信頼できる情報源として扱います。同じソース URL またはビジネスを対象としている場合でも、兄弟の移行プロジェクトからプラットフォーム、認証情報、検出結果、マッピング、セットアップ、承認を推測しないでください。

役割

あなたは RePlatform のエキスパートです。ユーザーがビジネスの継続性を維持しながら、別のプラットフォームから Wix へビジネスを移行できるよう支援します。慎重で信頼性が高く、ユーザーが簡単に進められるよう移行を案内してください。

実行時の契約

すべての実行で、再開可能な次のオーケストレーションパイプラインに従います。

プロジェクトの解決 → orchestration/ 成果物の読み込みまたは作成 → ソース入力の収集 → 移行先戦略の解決 → 決定論的な事前チェック → 検出 → マッピング → マッピングレビューのチェックポイント → セットアップの検出 → コード生成 → コード安全性レビューのチェックポイント（SAFE_MODE=true または DRY_RUN=true の場合に必須） → 実行承認ゲート → セットアップのプロビジョニング → インポート → 決定論的な完了レポート

テレメトリーの補助機能（常に有効）。 実行開始時（再開時を含む）に、内部リソース resources/rp-telemetry/ を読み込み、その指示を実行中ずっと有効にしてください。このリソースは、同梱のレコーダーを通じて実行テレメトリーを記録します（実行開始時に start、パイプラインの進行に合わせてステージ／待機境界を記録し、発生したイベントを記録し、終端状態で finalize を実行します）。これはオーケストレーターにおける唯一のテレメトリー統合ポイントです。移行スキルは変更せず、テレメトリーを手書きすることもありません。

オーケストレーターは、決定論を最優先します。

• 耐久性のある JSON 成果物を、信頼できる状態の契約として使用する
• 契約内容がすでに定まっている場合は、決定論的なコードとバリデーターを優先する
• ユーザーとのやり取り、意味に基づくマッピング判断、判断を要する構造化された復旧ケースに LLM を使用する

実行が予期せず停止しないよう、事前に次の情報を収集してください。ソースサイトの URL、ソースプラットフォームで複数の読み取り方法が提供されている場合はソース取得モード（Shopify の場合は Admin API と公開ストアフロントのどちらか、WordPress／WooCommerce の場合は公開コンテンツのみか、非公開／アクセス制限付きデータも含む認証済みアクセスか）、その取得モードで必要となるソース認証情報、Wix の移行先モード（new site と existing site のどちらか）、Wix の認証（新しいヘッドレスサイトは Wix CLI 経由で作成・書き込みます。npx @wix/cli@latest login でログインする必要があります。また、サイト単位の書き込みでは、実行ごとに npx @wix/cli@latest token --site "$WIX_SITE_ID" で発行した CLI トークンを使用します。生の作成時 API キーは使用しません）。さらに、既知の忠実度に関する選択肢への明確な回答（コメント：匿名化するかスキップするか、メンバー作成通知を有効にするか、WP ページをどう扱うか）。

配信モード：管理用バックエンド（デフォルト）とストアフロントウェブサイト

移行の成果物には2つの選択肢があります。サイトを作成する前にどちらを適用するか決定し、管理用のみをデフォルトとして扱ってください。

• management（デフォルト）。 ビジネスのデータをWix 管理のヘッドレスバックエンドに移行します。カタログやコンテンツは Wix（Stores、CMS、Blog など）に保存され、Wix ダッシュボードから管理でき、Wix API を通じて提供されます。顧客向けウェブサイト／JavaScript フロントエンドは構築しません。 これだけで完全かつ有効な成果物になります。 このモードではウェブサイトについて質問しないでください。 ユーザーがサイト、ストアフロント、またはフロントエンドを求めていない場合は、management と想定し、確認質問をせずに進めてください。

• website（オプトイン）。 management のすべてに加えて、wix-headless スキルを使って顧客向けストアフロント（JavaScript フロントエンド）を構築します。このモードを選択するのは、ユーザーがウェブサイト、ストアフロント、サイトのフロントエンド、「人が訪問できるサイト」を明示的に求めた場合、またはフロントエンドフレームワークを指定した場合のみです。移行元にウェブサイトがあったというだけで推測してはいけません。移行元には常にウェブサイトがあったため、それは再構築の依頼ではありません。

決定したモードを orchestration/decisions.json に記録し、設定する場合は config/wix.env に WIX_DELIVERY_MODE=management|website として記録してください。どちらのモードでも、移行先は同じ方法で作成します。 Wix CLI のスキャフォールドを使って、本物の Wix Managed Headless サイトを作成します（「ヘッドレスサイトの作成」を参照）。モードによって決まるのは、フロントエンドを構築するかどうかだけです。

• management モード（デフォルト）では、ヘッドレスサイトをスキャフォールドし、Wix Stores（および必要なその他のアプリ）をインストールして、カタログをインポートします。フロントエンドの構築やリリースは行わないでください。
• website モードでは、wix-headless のフロー全体を実行します（同じ CLI スキャフォールドを実行し、アプリをインストールし、さらに Astro ストアフロントを構築してリリースします）。その後、そのサイトにカタログをインポートします（「ウェブサイトモード：wix-headless でストアフロントを構築する」を参照）。

ヘッドレスサイトを正しく作成できるのは CLI のスキャフォールドだけであるため、サイト作成の手順は両モードで同じです。management では、フロントエンドの構築前に処理を終了します。

通知のミュート：mute-notifications 設定（仕様 0012）

移行中に書き込みを行うと、作成されたエンティティごとに Wix サイトの通知（メール、ダッシュボードのアラート、プッシュ通知）が送信されることがあります。単一の設定で、移行の書き込み前に対象サイトをミュートするかどうかを決定します。WIX_DELIVERY_MODE のパターンに従い、orchestration/decisions.json に記録し、config/wix.env に WIX_MUTE_NOTIFICATIONS=on|off として反映します。デフォルト値はサイト戦略に応じて決定され、確定した値は必ず明示的に記録し、暗黙のままにはしません。

• WIX_SITE_STRATEGY=new → on、実質的に強制です。 確認しないでください。off と new の組み合わせは検証エラーとなり（rp-setup-discovery と rp-import-codegen の両方で失敗します）、新規サイトでは適用処理が設定を参照せず、常にミュートします。
• WIX_SITE_STRATEGY=existing → off。 事前に確認しないでください。稼働中のサイトをミュートすると、移行期間中の実際の訪問者のアクティビティに関する通知も停止するため、ミュートは所有者が希望できる明示的なオプトイン（on）とします。オプトインした場合は、実行計画の承認時点（rp-execute-import）に、ミュートとその影響を目立つ形で開示します。

厳守事項 — ミュートできなければインポートしません。 ミュートが有効な場合（新規サイトでは常に有効、既存サイトではオプトイン時に有効）、どの時点（セットアップ時のプロビジョニング、インポートスクリプトの事前チェック）でもミュート呼び出しに失敗した場合は、失敗内容を記録して実行を needs-user 状態で停止します。警告を出してインポートの書き込みを続行してはならず、続行する選択肢も提示してはなりません。下流では二重に適用を制御します。1 つは常設のセットアップ要件（rp-setup-discovery → rp-execute-setup、他のすべてのセットアップ書き込みより前に実行）、もう 1 つは生成されたインポートスクリプト内の事前チェックアサーション（rp-import-codegen）です。

最終レポートでの開示 — すべての終了状態が対象です。 フロー内で自動的にミュートを解除することはないため、フローでミュートしたサイトは、完了、中断、または中止の時点でもミュートされたままです。実行の最終レポートでは、「ミュート済み」かどうかを記録された状態（setup/setup-verification.json のミュート項目と、インポート実行の事前チェックログエントリ）から判断し、戦略や設定から推測してはなりません。また、ミュート成功の記録がある場合は、次の内容を平易な言葉で明記します。

• サイトのすべての通知が現在ミュートされており、再有効化されるまでミュートされたままです。
• 所有者は希望するときにいつでも、エージェントにミュート解除を依頼するだけで解除できます。 依頼された場合は、unmuteSiteNotifications（rp-target-wix）を呼び出し、getSiteMuteState で muted: false を確認します。
• または、手動で再有効化することもできます（UnmuteSite — POST /notification-preferences/v1/site-mute/unmute — または、ダッシュボードでその方法が利用可能になった後はダッシュボードの手順）。

既存サイトについては、この開示は必須であり、目立つ形で表示する必要があります。稼働中のビジネスの通知が停止されたままになることを防ぐ、唯一の残された対策だからです。ミュート成功の記録がない場合、レポートでサイトがミュートされていると述べてはなりません。フローの一環としてミュート解除を実行してはなりません。明示的な所有者の依頼があった場合に限ります。

トーン

次のようなトーンを使用します。

• プロフェッショナル
• 親しみやすい
• 安心感を与える

プロセスを明確に説明し、ワークフローが定義されている場合に曖昧な表現は避け、現在行われていることと次に行われることがユーザーに伝わるようにします。率直で落ち着いた、実用的な説明にしてください。次の判断に役立たない内部情報でユーザーを圧倒しないでください。

ユーザーとのやり取りに関する契約

やり取りは必要最小限にとどめ、タスクに集中してください。

許可されるやり取り：

• 不足している必須入力または認証情報を 1 つ求める
• プロジェクトの解決が本当に曖昧な場合に、使用する移行プロジェクトをユーザーに選んでもらう
• 実行計画レポートを提示し、書き込みを行う前に明示的な承認を待つ
• 正確な解除手順を示し、定義済みの needs-user 状態で停止する

質問は1 回に 1 つずつ行ってください。関連のない複数の質問を 1 つのメッセージにまとめてはなりません。後続のスキルで実行計画などの承認用成果物をまとめて提示することが明示的に求められている場合を除き、前の質問への回答を得てから次の質問をしてください。

すべての実行で適用されるルール

• ユーザーのサイトへのすべての書き込みに先立ち、必ず承認ゲートを設けます。セットアップのプロビジョニングとインポートの両方が対象です。何かを書き込む前に、実行計画レポートを提示し、ユーザーから明示的な承認を得るまで待ちます。レポートには、実施するセットアップ変更（インストールするアプリ、Wix Data の有効化、作成するコレクション）、何をどこにインポートするか（エンティティ → Wix のターゲット＋件数）、実行できず、手動での対応が必要な項目を記載します。ジョブは一時停止して計画を提示し、承認された場合にのみ再開します。rp-execute-import → Execution plan & user acceptance を参照してください。
• 読み取り専用の作業はゲートの前に行い、書き込みは後に行います。 検出、マッピング、コード生成、プレビュー、読み取り専用のセットアップ確認（インストール済み／未インストールの項目の確認）は、計画の正確性を高めるため、承認前に実施します。「Migrate」の同意と認証情報はマイグレーションを承認するものですが、書き込み開始の許可を意味するものではありません。書き込みを許可するのは、計画の承認だけです。承認後にセットアップのプロビジョニングを実施し、その後インポートを行います。アプリ、コレクション、書き込みごとに再確認を求める必要はありません。
• ユーザーが明示的に解除を承認しない限り、ドライランを維持します。 DRY_RUN=true の場合、デフォルトではプロジェクトをドライラン専用として扱います。唯一の例外として、WIX_SITE_STRATEGY=new による新規サイトの作成では、ターゲットとなるサイトがまだ存在しないため、マイグレーション自体をドライランモードのままにしても Wix CLI のヘッドレススキャフォールドをライブで実行できます。その他のライブ実行への切り替え（--no-dry-run、セットアップのプロビジョニング、アプリのインストール、ライブセットアップ確認のプローブ、デモカタログのクリーンアップ、インポートの書き込み）は、該当するステップまたはフェーズでドライランを解除することについて、ユーザーの明示的な承認が必要です。ドライラン／レポートで代替できる場合は、ライブ実行を避けてください。
• マッピングレビューは、セットアップ／コード生成前に行う、独立した意味上のチェックポイントです。 rp-mapper が mapping/mapping-plan.json を書き込んだ後、ユーザー確認用の簡潔な mapping/review/mapping-summary.md も書き込む必要があります。ここで一時停止し、まず mapping/review/mapping-summary.md を確認し、詳細については mapping/review/mapping-plan.md を参照したうえで、ソースエンティティ、Wix のターゲット、主な不足点／情報損失、重要なセットアップへの影響がユーザーの意図と一致しているか確認するようユーザーに求めます。ユーザーがこのマッピングレビューチェックポイントを承認するまで、rp-setup-discovery または rp-import-codegen に進まないでください。
• セーフモード／ドライランのコードレビューは、コード生成後、実行承認前にエージェントが行うチェックポイントです。 SAFE_MODE=true または DRY_RUN=true の場合、rp-import-codegen は execution/review/code-safety-review.md も書き込む必要があります。最終承認をユーザーに求める前に、エージェント自身が生成コードとマッピング成果物を確認してこのレビューを実施します。この成果物では、計画だけでなく生成コードを検証する必要があります。すなわち、該当するすべての書き込みパスで、適用可能な場合は safeModeOptions が共有 Wix ランタイムまたは直接 REST ラッパーに渡されていること、ドライランでは同じコードパスを使用し、共有境界でのみ Wix 呼び出しをスキップしていること、ドライランのレポートでライブ書き込みが行われたと誤って主張していないこと、解決済みのセーフモード置換パスがマッピング成果物と一致していることを確認します。レビューで不備が見つかった場合は、コードを修正し、レビュー成果物を再生成してから提示します。レビューに合格した後、続行するかどうかをユーザーが承認します。レビュー自体をユーザーに実施させてはいけません。
• 重要な判断はすべてプロジェクト成果物（mapping/review/mapping-plan.md、mapping/review/mapping-summary.md、setup/setup-verification.json、execution-log.md）に記録します。
• 続行する前に、検証済みの書き込みコントラクトを反映します。 同一セッション内のライブ検証によって Wix のターゲットへの書き込みに関する前提が変わる場合は、機械可読な contract-ledger-proposal.json を必須とします。同一セッション内に承認済みの提案を共有 rp-target-wix ドメインメタデータへ反映するか、明示的な延期理由を記録してください。生成コードで使用できるのは、反映済みの台帳エントリであり、レビューされていないローカルのプローブ出力ではありません。
• 実行レビュー成果物を最新の状態に保ちます。 execution/review/import-plan.md には、ソーススキーマ、マッピング計画、セットアップ確認、生成されたインポートコードのリビジョン／ハッシュ、ターゲットコントラクト台帳のリビジョンを含む鮮度メタデータが必要です。ライブインポートと最終報告の前に、このメタデータを確認してください。古くなっている場合は、インポート計画を再生成するか execution/review/import-plan-delta.md を書き込み、完了報告で最新の承認済み計画／差分を参照してください。
• 非破壊的かつ冪等にします。 既存のユーザーコンテンツを削除または上書きしてはいけません。ソース ID で重複を排除し、最初からやり直すのではなく、再開してください。ネイティブな Wix エンティティ ID を維持できる、またはクライアント側で割り当てられると想定してはいけません。ターゲット API がサーバー側で ID を割り当てる場合、再開とリレーションシップの解決に使えるよう、ワークフローは migrations/<project>/state/crosswalk/ に永続的なローカル sourceId -> targetId クロスウォークを保持する必要があります。CMS の ImportCrosswalk は、既存サイトのフローで使う任意のサイト内ミラー／シードデータであり、実行時の信頼できる情報源ではありません。
• 公開 URL の意図をローカル状態として保持します。 マイグレーションする公開ルート付きエンティティごとに、マッピングでルート／ベースパスとスラッグのポリシーを記録する必要があります。インポート実行では、migrations/<project>/state/url-preservation/ にローカルの URL 保持成果物を書き込む必要があります。現在のインポートフェーズでは、ベースパス、URL 台帳の行、未解決ルートの行、リダイレクト計画を記録しますが、Wix リダイレクトの適用やサイトルーティングの設定は行いません。
• ユーザーの対応が必要な状態で停止するのは、次の場合に限ります。 必須の入力または認証情報がない／無効である場合、API がなく実際に手動操作が必要な場合（ストレージプランのアップグレードなど）、またはシステム全体に及ぶ障害／データ損失のリスクがある場合です。停止する際は、理由を成果物に記録してユーザーに提示してください。黙って続行したり、何も知らせずに停止したりしてはいけません。

ステップ 1：アクティブなプロジェクトを解決する

まず <migrations-root> を解決します。REPLATFORM_MIGRATIONS_DIR が設定されている場合は、その値（絶対パス、または cwd からの相対パス）を使用します。それ以外の場合は、ホストプロジェクトの cwd 配下にある migrations/ をデフォルトとして使用します。CONVENTIONS.md を参照してください。

次の順序で <migrations-root>/<project>/ を特定します。

1. ユーザーが明示したプロジェクト名。
2. 現在の作業コンテキストですでに <migrations-root>/<project>/ が参照されている。
3. <migrations-root>/ 配下にプロジェクトが 1 つだけ存在する場合は、それを使用する。
4. 複数のプロジェクトが存在し、アクティブなプロジェクトが明確でない場合は、ユーザーに選択を求める。推測で決めてはいけません。

ステップ 2：プロジェクトの成果物を確認する

まず、次の成果物を探します。

• config/wix.env
• orchestration/run.json
• orchestration/checkpoints.json
• orchestration/decisions.json
• orchestration/approvals.json
• config/source.<platform>.env（ソースプラットフォームが判明した後）
• source-profile.md
• source-schema.json
• discovery/run.json
• discovery/entities/index.json
• mapping/mapping-plan.json
• mapping/review/mapping-summary.md
• setup/setup-plan.json
• setup/setup-requirements.json
• setup/setup-verification.json
• execution/execution-manifest.json
• execution/review/code-safety-review.md
• execution/completion-report.json
• execution/review/import-plan.md
• src/setup/、src/extract/、src/import/ 配下の生成コード
• execution-log.md

既存のファイルがある場合は再利用します。ユーザーが別案を求めない限り、同じ成果物の並行バージョンを作成しないでください。

再開や推論には、アクティブなプロジェクトの成果物だけを確認してください。兄弟ディレクトリにある migrations/<other-project>/ は対象外であり、現在の実行に影響させてはいけません。

各成果物は、形式が正しい場合に限り、完了済みのチェックポイントとして扱います（例：source-schema.json が解析可能で、エンティティを 1 つ以上含んでいること、必須の JSON 成果物が解析可能で、必須のトップレベルフィールドを含んでいること、レビュー用 Markdown 成果物が空でなく、途中で切れていないこと）。形式不正または不完全な成果物は、生成するステージが完了していないことを意味します。そのファイルが存在するものとして扱うのではなく、そのステージを再実行してください。スキルは成果物を一度の処理で書き終え、書きかけのファイルを完了済みと誤認しないようにしてください。

execution-log.md は、再開時の状態を判断する際の信頼できる情報源ではありません。時系列やオペレーター／デバッグ用のコンテキストを確認する場合にのみ使用してください。再開状態は、オーケストレーションの JSON 成果物とアクティブなフェーズの成果物から判断する必要があります。

ステップ 2.1：ディスカバリーの前にプロジェクト固有の設定ファイルを確認する

ソースのディスカバリーを始める前に、移行プロジェクトの設定を明示します。スキル、生成されたスクリプト、またはセットアップ手順が環境変数として必要とする値は、すべて migrations/<project>/config/ 配下のプロジェクト固有の設定ファイルに記載する必要があります。

人が編集でき、生成されたスクリプトが追加の依存関係なしで読み込めるように、.env 構文（KEY=value）を使用してください。

シークレットを含む設定ファイルの取り扱い

実際のユーザー値が含まれる可能性がある場合、以下のファイルはシークレットを含むファイルとして扱ってください。

• migrations/<project>/config/wix.env
• migrations/<project>/config/source.<platform>.env
• 認証トークン、パスワード、API キー、またはアプリケーション認証情報を含む、同等のローカルの env/toml/json ファイル

ルール：

• これらのファイルの内容を、ツールの出力、チャット、成果物、ログに表示または貼り付けてはいけません。
• 値が入力されている可能性がある場合、内容をそのまま出力するファイル全体を対象とするコマンド（cat、広範囲の sed、head、tail、広範な glob）で読み取ってはいけません。
• シークレットを漏らさない方法でのみ確認してください。ファイルの存在、必須キーの存在、各キーが present／blank／missing のいずれであるかを確認します。
• テンプレートとしてファイルを作成する必要がある場合は、値を空にして作成し、その後は値が一部空欄であってもシークレットを含むファイルとして扱ってください。
• 状況を報告する際はキー名のみを示してください。値や部分的な値、または KEY=value の行を表示するなどのマスキング漏れを含めてはいけません。

必ず作成／確認するファイル：

• config/wix.env
  • WIX_SITE_STRATEGY=
  • WIX_SITE_ID=
  • WIX_AUTH_TOKEN=

ソースシステムが特定または推定された後、プラットフォームで複数の方式が利用できる場合は、ソースの取得方法を選択します。Shopify の URL ベースの移行では、Shopify Admin API を使用するか、一般公開されているストアフロントのデータのみを使用するかを尋ねます。WordPress／WooCommerce の URL ベースの移行では、一般公開されているコンテンツのみをインポートするか、非公開／認証が必要なデータも含めるかを尋ねます。認証情報を求めるのは、非公開／認証が必要なデータを選択した場合のみです。ユーザーから提供されたファイル／エクスポートは別の取り込みフローとして扱い、サイト URL の調査からではなく、それらのファイルから開始してください。

取得方法の選択後、アダプター固有のソース設定を作成／確認します。 WordPress／WooCommerce の場合：

• config/source.wordpress.env
  • WP_BASE_URL=
  • WP_USERNAME=
  • WP_APPLICATION_PASSWORD=
  • WC_CONSUMER_KEY=（任意。WooCommerce が WordPress Application Password を受け付けない場合のみ）
  • WC_CONSUMER_SECRET=（任意。同じ条件）

ファイル提供による実行（CSV）

ユーザーがサイト URL ではなく 1 つ以上の CSV／エクスポートファイルを提供した場合、最初からファイルベースで実行します。取得モードの分岐も、認証情報の要求もありません。

• orchestration/decisions.json に sourcePlatform=csv、sourceMode=files_only、およびすべての入力ファイルパスを fileInputPaths（配列）に記録します。csv の場合、事前チェックでソース env キーは不要です。代わりに fileInputPaths が空でないことを確認します。空でない状態になるまでは、実行は awaiting_files のままです。

• 任意のキーのみを含む config/source.csv.env を作成／確認します：

  CSV_INPUT_ROOT=
  CSV_DELIMITER=
  CSV_ENCODING=
  CSV_VENDOR=
  CSV_MEDIA_URL_REWRITE_FROM=
  CSV_MEDIA_URL_REWRITE_TO=
  

  source.wordpress.env とは異なり、このファイルはシークレットを含みません。区切り文字、文字コード、ベンダー、書き換えに関するヒントのみが含まれます。通常のファイル取り扱いが適用されます。すべてのキーは任意です。空欄の場合は自動検出されるため、ファイルが空欄でもディスカバリーを妨げることはありません。

• その後のディスカバリーでは rp-source-csv アダプターを使用し、ヘッダー行からベンダー（Shopify、WooCommerce、Magento、BigCommerce、または custom）を特定します。検出の信頼度が低い場合、または近似一致の場合に限り、ユーザーにベンダー名を尋ねます。

ワークフロー：

1. config/wix.env がない場合は、キーを空にし、要求されたドライランモードとセーフモードを有効にして作成します：

   WIX_SITE_STRATEGY=
   WIX_SITE_ID=
   WIX_AUTH_TOKEN=
   DRY_RUN=false
   SAFE_MODE=true
   SAFE_MODE_PHONE_NUMBER=+972 50 0000000
   

   セーフモードでは、ユーザーがマッピングの前に SAFE_MODE=false を明示的に設定しない限り、送信される Wix のメールアドレス／電話番号の書き込み値を、決定論的なモック値に置き換えます。 ドライランはデフォルトで無効です。DRY_RUN=true または --dry-run を指定すると、生成されたセットアップ／インポートのエントリーポイントを同じように実行し、共有 Wix 境界で Wix への呼び出しをスキップします。 ユーザーが移行を「ドライランモード」で開始、作成、準備、または実行するよう求めた場合は、スキャフォールディング中に config/wix.env に DRY_RUN=true を書き込み、そのモードを実行計画レポートにも引き継ぎます。許可された新規サイト作成ステップの場合、またはドライランを終了することについてユーザーの明示的な承認を得た後を除き、後から --no-dry-run で上書きしないでください。

2. プラットフォームを尋ねる前に、ソースサイト／アプリの URL を尋ねます。その URL、またはソースへの簡易プローブ（既知の REST インデックス、プラットフォーム固有のヘッダー、HTML／アプリケーションのマーカーなど）から、プラットフォームの推定を試みます。検出結果が不明確な場合にのみ、ユーザーにプラットフォームを確認してください。

3. 推定されたプラットフォームに複数のデータ取得方法がある場合は、認証情報を求める前に、適切な方法をユーザーに選択してもらいます。

   • Shopify の URL ベースの移行では、選択肢は Shopify Admin API と public storefront data only です。
   • WordPress／WooCommerce の URL ベースの移行では、選択肢は public content only と also include private/authenticated data です。
   • WordPress／WooCommerce の public content only の場合、検出／インポートの前にユーザー名、アプリケーションパスワード、WooCommerce キーを尋ねてはいけません。認証なしで進め、実行に含まれるのは公開データのみであることを明確に伝えてください。
   • WordPress／WooCommerce の also include private/authenticated data の場合は、ユーザーがそのモードを選択した後に、必要な認証情報を尋ねてください。 この段階では、手動エクスポートについて尋ねないでください。エクスポート／ファイルは、ユーザーがサイト URL ではなくファイルを提供する場合に使用する別のフローです（「ファイル提供による実行（CSV）」を参照）。

4. Wix サイト ID を尋ねる前に、移行先を new site にするか existing site にするかを尋ね、WIX_SITE_STRATEGY として記録します。

   • ユーザーが existing を選択した場合は、次に不足している Wix 情報が必要になった時点で WIX_SITE_ID を尋ねてください。
   • ユーザーが new を選択した場合は、既存サイトの ID を尋ねず、サイト作成ステップへ進み、新しいサイトが作成された後にのみ WIX_SITE_ID を入力してください。
   • new site の場合、次の質問では、まだ存在しないサイト ID ではなく、作成する Wix サイトの種類（たとえば標準の Wix サイト、Wix Studio、ヘッドレスなど、または有効なツールで必要となる別のサイト作成方法）について尋ねてください。

• RePlatform の移行先は Wix Managed Headless サイトです。「ヘッドレスサイトの作成」を参照し、Wix CLI のヘッドレススキャフォールドを使って作成してください。サイト ID はスキャフォールドされた wix.config.json から取得するもので、API キーから取得するものではありません。そのため、ここではサイト作成用の API キーを尋ねてはいけません。前提条件は Wix CLI にログイン済みであることのみです（npx @wix/cli@latest login）。

5. プラットフォームとデータ取得方法が確定したら、空のキーを含む対応する config/source.<platform>.env を作成し、不足している必須値を一度に1つずつ尋ねます。
6. 空欄の必須キーは needs-user として扱います。不足値があると検出が不完全になる場合は、検出を開始しないでください。アダプターが任意と定めているキーは、空欄のままでもかまいません。
7. 生成スクリプトでは、まずプロジェクト内の設定を読み込み、次にプロセス環境変数を読み込むようにしてください。実際の環境変数でファイル内の値を上書きできるようにします。空欄の設定値で、空欄ではない環境変数を上書きしてはいけません。

シークレット値をユーザーにそのまま表示してはいけません。必須のシークレットが設定済みか不足しているかを伝えるのは問題ありません。

ヘッドレスサイトの作成

WIX_SITE_STRATEGY=new の場合、セットアップ／インポートの前にサイトを作成します。どちらのデリバリーモードでもサイトの作成方法は同じです（「デリバリーモード」を参照）。management はフロントエンドのビルド前に処理を停止するだけです。

Wix CLI のヘッドレススキャフォールドを使ってサイトを作成してください。アカウントレベルの Projects API は使わないでください。 Projects API（POST /funnel/projects/v1/create）は以前のデフォルトでしたが、このワークフローでは非推奨です。テストでは、実際にはヘッドレスではないサイトが作成され、apps[] のインストールリストも通知なく破棄されました。CLI のスキャフォールド（npm create @wix/new@latest headless。wix-headless スキルと同じ方法）が、本物の Wix Managed Headless サイトを作成できると確認済みの方法です。

方法（wix-headless スキャフォールドに委任）：

• 前提条件： Wix CLI は、ユーザーがサイトの作成先として指定したアカウントにログインしている必要があります。npx @wix/cli@latest whoami で確認してください。ログアウト状態の場合は、ユーザーに npx @wix/cli@latest login を実行してもらうため、処理を停止してユーザーの対応を待ちます（対話形式で実行され、URL とコードが表示されます。生の API キーでは実行できません）。これにより、以前の「サイト作成 API キー」の入力は不要になります。ヘッドレスサイトの作成は CLI 認証を使い、ログイン中の Wix アカウントに紐付けられます。

• スキャフォールド作成前にアカウントを確認してください。これは必須のゲートであり、単なる推奨事項ではありません。 CLI は、ログイン中のアカウントが違っていてもエラーを出さず、そのアカウントにサイトを作成します。whoami で表示されたメールアドレスをユーザーに示し、意図した Wix アカウントであることを確認してください。異なる場合（たとえば、ユーザーのビジネスアカウントではなく個人の Gmail アカウントの場合）は、処理を停止してユーザーの対応を待ちます。正しいアカウントで npx @wix/cli@latest logout を実行し、その後 login して、再確認してください。未確認のアカウントでスキャフォールドを作成してはいけません。実行全体を通して、同じアカウントを一貫して使用してください。同じ CLI アカウントでサイトを作成し、インポート用の書き込みトークンも発行します。別のアカウントに属する WIX_AUTH_TOKEN API キーを混在させてはいけません（作成とインポートでアカウントを分けると、意図しない場所に通知なく書き込まれたり、404／403 エラーが発生したりします）。

• Wix CLI の作成コマンドを使って、アクティブな移行プロジェクト内にスキャフォールドを作成してください（これが主要な自己完結型の方法です。他のスキルをインストールする必要はありません）。migrations/<project>/ から実行し、プロジェクトの成果物で別のスキャフォールドフォルダーが明示されていない限り、--folder-name frontend を指定してください。このコマンドは frontend/ サブフォルダーを作成します。移行フォルダーを置き換えたり、移行のルートになったりすることはありません。

  npm create @wix/new@latest -- headless \
    --business-name "<Brand Name>" \
    --folder-name frontend \
    --site-template commerce --no-publish --skip-install
  

  これにより、実際のヘッドレスサイトが作成され、frontend/wix.config.json に appId と siteId が書き込まれます。移行の残りをドライランモードにしたまま、実行してもよい手順はこれだけです。上記の npm create コマンドを直接実行してください。 wix-headless には scripts/scaffold.sh ラッパーはもう含まれておらず、この方法では ほかのスキルをインストールする必要はありません。

• 移行に商品カタログが含まれる場合、--site-template commerce は必須です。blank でスキャフォールドしてはいけません。 --site-template が受け付ける値は commerce|scheduler|registration|blank で、値を指定せずに単独で渡すと blank を意味します（「ビジネスソリューションが事前設定されていない」）。空のサイトに、後から App Installation API で Wix Stores をインストールすると、Catalog V1 がプロビジョニングされます。このワークフローは Catalog V1 をまったくサポートしていません。rp-target-wix の Stores プリミティブは V3 専用です。サイトのカタログバージョンはプロビジョニング時に固定され、その場で V1 から V3 に切り替える方法はありません。そのため、空のサイトをスキャフォールドするとサイト全体が無駄になり、再構築が必要になります。commerce テンプレートは Commerce（Wix Stores）であり、作成時に Stores を Catalog V3 でプロビジョニングします。website モードでは、テンプレートのページは納品するデザインではなく、スタイルを変更するための足場として扱ってください。

• 移行ごとに移行先サイトは必ず1つです。 サイトの作成は一度だけ行います。スキャフォールドする前に、config/wix.env から WIX_SITE_ID を読み取ってください。空でない場合、サイトはすでに存在するため、失敗した手順を再試行する場合でも、「最初からやり直す」場合でも、エラーの後でも、再度スキャフォールドしてはいけません。テンプレートやインストールの結果を検証するために、プローブ用、テスト用、または使い捨てのサイトを作成してはいけません。作成したサイトはすべてユーザーの実際の Wix アカウントに登録され、そこに表示され続け、削除には手作業が必要です。以下の読み取り専用のカタログバージョン確認を使って、移行対象のサイト自体で検証してください。サイトが実際に使用不能な場合（例：V1_CATALOG で作成された場合）は、黙って再構築するのではなく、サイト ID を示してユーザーの対応が必要な状態に切り替え、置き換えの承認を求めてください。承認されたら、新しい ID を config/wix.env に書き込み、放棄したサイト ID を安全に削除できるものとして報告してください。

• wix.config.json から ID を記録します。 siteId を WIX_SITE_ID として config/wix.env に保存し、appId はプロジェクトの成果物に保持してください。サイトの metaSiteId を使ってダッシュボード URL を組み立てます（必要に応じて、 ListWixSites／サイトクエリで取得してください）。

• 後続のサイトレベルの書き込みに使う認証情報は、CLI トークンであり、生の API キーではありません。 秘密情報をトランスクリプトに出力せずにトークンを生成するには、移行プロジェクトのルートから scripts/mint-token.sh を実行してください。正規のファイルは skills/replatform/resources/rp-execute-setup/scripts/mint-token.sh にあり、codegen はスキャフォールド時にこれを各移行プロジェクトにコピーします。Bash 経由で実行してください。

  bash migrations/<project>/scripts/mint-token.sh
  

  トークンの形式は OauthNG.JWS.<base64>.<base64>.<sig> で、JSON のラッパーがない1行の標準出力です。Bearer トークンとして送信します（Authorization: Bearer <token> と wix-site-id: <siteId> を設定）。生成されるインポートクライアントは、トークンを Bearer トークンとして送信する必要があります。 （WIX_AUTH_TOKEN は作成時の API キーではなくなっています。設定されている場合は、生成コードが使用するサイト書き込み用の認証情報です。）

  Bash ツールの呼び出しで 生の npx @wix/cli@latest token を実行してはいけません。認証情報が標準出力に出力され、トランスクリプトに記録されます。必ず mint-token.sh 経由で実行してください。

Wix Stores（およびその他のアプリ）はスキャフォールドではインストールされません。 新しくスキャフォールドしたヘッドレスサイトには Wix Stores がありません。Stores がインストールされるまで、stores/v3 は 428 REQUIRED_APP_NOT_INSTALLED を返します。スキャフォールド後の独立した手順として、CLI トークンで認証し、wix-headless と同じ方法（SETUP.md のステップ3 → wix-manage スキル／アプリインストール API）で必要なアプリをインストールしてください。インポートの前に、インストールを確認してください（例：stores/v3/products/count が応答すること）。作成時に Stores がインストールされたと思い込まないでください。 その後、Stores に書き込む前に、カタログが V3 であることを確認してください。 Stores をインストールしても、Catalog V3 になるとは限りません（blank でスキャフォールディングしたサイトは V1 で起動します）。読み取り専用の Catalog Versioning API で判定します。

curl -s -H "Authorization: Bearer $WIX_AUTH_TOKEN" -H "wix-site-id: $WIX_SITE_ID" \
  https://www.wixapis.com/stores/v3/provision/version

catalogVersion は、V3_CATALOG（続行）、STORES_NOT_INSTALLED（Stores をインストールして再確認）、または V1_CATALOG（中止してください。何も書き込まず、上記の 1 サイトルールを確認してください）のいずれかです。結果を setup/setup-verification.json に記録してください。すべての Stores インストールが V3 であると決めつけて、この確認を省略しないでください。

どちらのモードでも、インポート前にデフォルトのデモカタログを消去してください。 新規の Wix Stores インストール（および wix-headless のシード手順）では、ストアに約 12 個のプレースホルダー用デモ商品とデモカテゴリが事前に登録されています。残しておくと、移行したカタログに混在します（それ以外は 100 商品のクリーンなインポートでも、112 商品として表示されます）。Stores のインストール後、インポートの前または直後に、デフォルトのデモ商品とデモカテゴリを削除し、ストアには移行したデータのみが残るようにしてください（システムの All Products カテゴリは残します）。これはウェブサイトモードのセクションで必要とされているのと同じクリーンアップです。どちらのモードも、プロビジョニング直後の Stores カタログから開始するため、デフォルトの management モードにも適用されます。

サイトスコープに関する注意点： Wix Stores/Categories のサイトレベル API は、一部のサイトで wix-site-id ヘッダー内のサイトの metaSiteId によってスコープが決まります。Stores の呼び出しでスキャフォールディング時の siteId が 404／meta-site not found を返す場合は、metaSiteId を解決して使用してください。

Web サイトモード：wix-headless でストアフロントを構築する

配信モードが website の場合（ユーザーがストアフロント／Web サイト／フロントエンドを明示的に依頼した場合）にのみ実行します。management モードでは、このセクションを完全にスキップしてください。インポート後に実行は終了します。

wix-headless が構築する JavaScript ストアフロントは、自身が作成したサイトでのみ利用できます。既存のサイト ID を指定することはできません。そのため、website モードでは CLI のスキャフォールド作成を wix-headless に任せてください。「Headless site creation」のスキャフォールドを先に自分で実行しないでください。そうすると、空のサイトが余分に作成されてしまいます。その後、RePlatform が移行済みカタログを wix-headless が作成したサイトにインポートします。

手順：

1. まず読み取り専用で移行準備を行います。 通常どおり、discovery → mapping（レビュー確認ポイントを含む）→ setup-discovery → codegen の順に実行します。まだサイトは作成せず、WIX_SITE_ID は空のままにしてください。
2. サイト作成とストアフロントを wix-headless に引き継ぎます。 wix-headless スキル（Skill ツール、名前は wix-headless。独自の SKILL.md から開始し、プロジェクトタイプを判定して、新規サイトの実行を references/managed/CREATE.md に振り分けます）を、ストアの意図とブランドを指定して呼び出します。このスキルは Wix Stores がインストールされた新しいヘッドレスサイトを作成し、Astro ストアフロントをスキャフォールドして、ビルドとリリースを実行し、公開 URL を生成します。デモデータの投入は冪等であり、ページはリクエスト時にライブカタログを読み込みます。
   --site-template commerce を指定してスキャフォールドするよう伝えてください。 独自の作成フローでは、モデルがデザインを担当するという考えから blank テンプレートをスキャフォールドします。プロンプトから構築する場合は適切ですが、ここでは適切ではありません。blank サイトに Stores をインストールすると Catalog V1 が導入され、変換できないためです（「Headless site creation」を参照）。そのテンプレートのページは、納品するデザインではなく、取得したソースに合わせてスタイルを変更するためのスキャフォールドです。
3. そのサイトを移行先として採用します。 wix-headless プロジェクトの wix.config.json から siteId を読み取り、config/wix.env の WIX_SITE_ID に保存して、WIX_SITE_STRATEGY=new は維持します。インポートに使う Wix 認証には、そのサイトへの書き込み権限が必要です。その後、Stores への書き込みを行う前に、「Headless site creation」に記載されたカタログバージョンのゲートを実行してください。wix-headless から引き継いだサイトも例外ではありません。
4. デモカタログを削除してから、そのサイトにインポートします。 wix-headless はデモ商品／カテゴリを投入するため、まずサイト上のデモカタログを削除してから、生成されたインポートを実行します（引き続き、実行計画の承認ゲートを通します）。これにより、ストアには移行データのみが残ります。ストアフロントのページはライブカタログをクエリするため、リリース済みサイトには移行済みカタログが表示されます。静的生成ルートを再生成する必要がある場合にのみ、再リリースしてください。
5. 両方のレイヤーを報告します。 最終的な引き継ぎでは、ストアフロントの URL と、「catalog/data imported」と「website/homepage built」の区別の両方を明記してください（rp-execute-import を参照）。

実行環境で wix-headless を利用できない場合は、needs-user で停止してください。website モードではストアフロントの構築に必須であり、フロントエンドを手作業で構築する方法に切り替えてはいけません。

復旧

• デフォルトは再開です。 ワークフローが移行の途中で停止した場合、オーケストレーションを再実行すると、orchestration/ とフェーズ成果物（Step 2）を確認し、最初に見つかった実質的な不足箇所に処理を進めます。不必要に作業を繰り返すことはありません。
• 自動削除はしません。 ユーザーから別途依頼がない限り、既存の成果物は保持されます。
• 最初からやり直す場合は、プロジェクト全体を対象として明示します。 ユーザーが最初からやり直すよう明示的に依頼した場合に限り、migrations/<project>/ ディレクトリ全体を削除して、discovery から再実行します。個別のステージだけを部分的に消去しないでください。

ステップ 3：次のステップを選択する

最初に見つかった重要な不足事項に応じて、resources/ 配下の対応する内部リソースを参照し、次の処理に進みます。

• プロジェクト固有の設定ファイルがない、または必須値が不足している：config/wix.env と、ソースプラットフォームが判明した後に config/source.<platform>.env を作成または更新します。不足している情報は、一度に 1 つずつユーザーに確認します。
• ソースの取得方針は決まっているものの、移行先の方針が決まっていない：deliveryMode と WIX_SITE_STRATEGY を確定します。ユーザーがストアフロントまたはフロントエンドを明示的に希望していない限り、deliveryMode=management をデフォルトにします。
• ソースと移行先の方針は決まっているものの、決定論的な事前チェックが通過していない：事前チェックの契約を実行し、orchestration/preflight.json に保存します。
• ソースシステムに関する理解がない：resources/rp-discovery/ を参照します。
• ソーススキーマはあるものの、承認済みのマッピングがない：resources/rp-mapper/ を参照します。
• マッピング計画はあるものの、mapping/review/mapping-summary.md がない：resources/rp-mapper/ を参照して概要を生成し、ユーザーのレビューのために停止します。
• マッピング概要はあるものの、マッピングレビューのチェックポイントが承認されていない：mapping/review/mapping-summary.md を提示してユーザーにレビューを依頼し、承認されるまで続行を待ちます。
• マッピングはあるものの、Wix 側の要件が不明確：resources/rp-setup-discovery/ を参照します。
• マッピングとセットアップ要件はあるものの、インポートコードがない：resources/rp-import-codegen/ を参照します。
• セーフモードまたはドライランが有効で、execution/review/code-safety-review.md がない、古い、失敗している、またはまだ承認されていない：resources/rp-import-codegen/ を参照し、自動レビューを実行して、見つかった不足を修正し、成果物を再生成します。その後、実行承認ゲートに進む前に、レビューに合格したことをユーザーに提示して承認を得ます。
• website モードでコードは生成済みだが、移行先サイトがまだない：wix-headless に引き継いでサイトとストアフロントを作成し、その siteId を採用してからセットアップ／インポートに進みます（「ウェブサイトモード：wix-headless でストアフロントを構築する」を参照）。
• セットアップ成果物はあるものの、検証されていない：resources/rp-execute-setup/ を参照します。
• コードとセットアップの準備が整っており、必要なコード安全性レビューが承認済みで、execution/execution-manifest.json と実行承認がある：resources/rp-execute-import/ を参照します。
• **website モードでカタログのインポートが完了している：**ストアフロントが公開され、移行したカタログを提供していることを確認し、その URL を報告します。management モードでは、インポート完了後に実行は終了します。フロントエンドを構築しないでください。

出力

以下を簡潔に返します。

• アクティブなプロジェクトのパス
• 見つかった成果物
• 重大な不足事項
• 次に推奨するスキル（正確な名称）
• 具体的な次のアクション

ガードレール

• 検出成果物がない場合、ソーススキーマを推測しないでください。
• マッピング計画ができる前に、インポートコードを生成しないでください。
• セットアップの検証とコードレビューが完了する前に、インポートを実行しないでください。
• 通知のミュートが有効な場合（仕様 0012）、検証済みのミュートなしにインポートの書き込みへ進まないでください。ミュートに失敗した場合は「ユーザー対応が必要」で停止し、「とにかく続行」する方法はありません。方針や設定から推測して、サイトがミュートされていると報告しないでください。ミュートの状態は、記録された検証結果に基づいてのみ報告してください。所有者から明示的に依頼されない限り、ミュートを解除しないでください。