rp-destination

À utiliser uniquement quand aucune destination faisant autorité n'est disponible ou que le contrat de destination est en conflit.

La priorité est le reçu de création orchestration/destination.json, puis un site id non vide dans config/wix.env (une destination existante ou héritée : l'adopter, ne jamais demander de type), puis un nouveau site du type explicitement choisi par l'opérateur. Un conflit est un arrêt définitif ; ne jamais rediriger sur une supposition.

Nouveau site : exécuter le coordinateur

Pour un nouveau site, exécutez le coordinateur déterministe ; ne composez pas vous-même les demandes de création :

node <skill>/scripts/wix-destination.js ensure --project-dir <projectDir>

Il affiche un résultat JSON et n'affiche jamais les identifiants :

• awaiting_site_type — aucun targetSiteType n'est enregistré. Il a soulevé la demande de type de site requise (headless, studio, harmony_store, harmony_bookings, harmony_other, ou harmony = « pas sûr, commencer vierge »). En chat, posez cette question combinée une fois ; en one-click, groupez-la avec les autres informations manquantes ; dans les exécutions replatform, terminez le tour — la demande est la question. Enregistrez une réponse de chat avec orchestration-state.js decide --key targetSiteType --value <type> [--business-type store|bookings|other] ; une réponse Harmony sans type de métier enregistre unknown. Ne posez jamais une question de type de métier séparée, ne répondez jamais pour l'opérateur, et ne transformez jamais une réponse générique « Editor » en Studio ou Harmony. Il n'y a pas de type par défaut, y compris dans les exécutions one-click et backend uniquement.
• awaiting_editor_website_decision — management_and_website avec Studio/Harmony : la demande explique que RePlatform n'a pas de migration automatique du site Editor. L'opérateur choisit backend uniquement (le périmètre devient management) ou un handoff d'Editor website séparé.
• awaiting_account_confirmation — avant la première création Studio/Harmony, la demande nomme le compte dans lequel la CLI Wix est connectée et le nom du site. Relayez-la ; ne la répondez jamais pour l'opérateur. confirm_account lie ce compte ; switched_account affiche le compte à nouveau après un changement de connexion. Une connexion qui diffère du compte confirmé n'est jamais utilisée pour une création.
• verified / created / existing_destination — signalez l'URL du tableau de bord (et, pour un site Editor, l'URL editor vérifié) et retournez au routeur.
• failed_before_create, ambiguous, awaiting_recovery, blocked — une demande de récupération durable est en attente (nommée par recoveryRequestId). Relayez-la ; ne la contournez jamais par une nouvelle tentative.

Quand le contexte d'exécution établit déjà le type de métier pour un site Harmony, écrivez-le avant d'exécuter le coordinateur pour que la demande réduise Harmony à un seul choix : orchestration/destination-brief.json avec businessType (store, bookings, other) et businessTypeEvidenceRef (d'où provient la preuve). Le type est un contexte pour l'exécution ; il ne change pas la façon dont le site est créé. N'inventez jamais de détails.

Ce que fait le coordinateur :

• Détient orchestration/destination.lock, revérifie le reçu et config/wix.env, et écrit un marqueur de tentative avant toute création. Studio et Harmony utilisent leurs modèles vierges via POST /msm/v1/meta-site/create-from-template avec la connexion du compte CLI Wix. La génération de site IA de Harmony s'exécute sur un service Wix privé sans promesse de stabilité, elle n'est donc utilisée pour aucun type de métier. Headless délègue une seule fois à wix-headless-scaffold.js (ci-dessous).
• Enregistre l'id de métasite retourné dans le reçu, vérifie que le propriétaire de la réponse est la connexion confirmée, puis écrit WIX_SITE_ID dans config/wix.env (jamais sur une valeur différente), crée une identifiant CLI Wix limité au site, et vérifie l'éditeur (WIX_STUDIO / ODEDITOR) et que le site n'est pas publié (relecture des URLs publiées). Seule une relecture unpublished fraîche permet à l'importation de continuer : chaque réexécution sur un site verified répète la relecture, et le routeur renvoie setup/import ici (destination_publication_recheck) quand la dernière relecture date de plus de 10 minutes.
• Un reçu Headless est repris, jamais redélégué : un site confirmé est adopté, et tout marqueur WIX_SCAFFOLD_STATUS reste la récupération du wrapper.
• Ne répète jamais une création dont l'issue est inconnue, ne publie jamais, ne dépublie pas et ne supprime jamais un site, et ne bascule jamais vers un autre éditeur ou vers Headless.

Demandes de récupération et ce que chaque réponse fait (chaque réponse déclenche une étape bornée) :

Prompt de l'Opérateur Import pour une création incertaine, un décalage d'éditeur ou une relecture published/unknown : « Dans l'espace de travail de migration original, réconciliez la tentative de création de destination avec le compte prévu, conservez l'ID de métasite retourné, réexécutez la vérification de l'éditeur et la relecture des URLs publiées, et reprenez uniquement après avoir enregistré le reçu résolu. Ne créez pas de site de remplacement, et ne publiez pas ou ne dépubliez pas sans une décision explicite de publication humaine. »

Un site Editor n'est pas une construction de website : ne scaffoldez jamais les fichiers frontaux Headless pour lui, et ne le confiez jamais à wix-headless-replatform. Son website et sa publication restent à la charge du propriétaire/designer du site et de l'Opérateur Cutover (rapport de fin operatorActions).

Headless

Pour la création Headless, le coordinateur exécute le wrapper une seule fois ; le wrapper confirme que la CLI Wix est connectée au compte prévu, scaffold à l'intérieur du projet de migration actif, et persiste l'id de métasite. Toujours scaffold avec --site-template blank, quel que soit le mode de livraison ou si la migration porte un catalogue — Catalog V3 est garanti à l'approvisionnement quel que soit le modèle, il n'y a donc plus de raison de commencer par un modèle non vierge. Laissez wix-headless-replatform fournir le contenu de page réel ; ne sautez pas ce module juste parce qu'il n'y a pas de travail backend. Ne créez pas de site sonde, test, remplacement ou secondaire sans l'autorité de récupération explicite du contrat de destination existant.

Le Scaffolding (wix-headless-scaffold.js) publie le site dans le cadre de la création — c'est le défaut propre de la CLI Wix ; n'ajoutez jamais --no-publish. La livraison entière d'une migration management uniquement est ce site publié exécutant son modèle non modifié : « aucun website grand public n'est construit » signifie laissé non personnalisé, non laissé dépublié.

Le script corrige également le astro.config.mjs/package.json généré juste après qu'une destination est confirmée, une seule fois, pour que le serveur de dev local d'un projet en mode website fonctionne sans corrections manuelles, sur n'importe quel client l'exécutant à partir d'une Wix Remote Machine : un joker Vite allowedHosts + host: true (le nom d'hôte de prévisualisation dynamique de la machine distante et son défaut 127.0.0.1 uniquement rompent sinon une prévisualisation locale avec un blocage d'hôte ou un 504), et des hooks predev/prebuild/prerelease qui réexécutent wix env pull (le .env.local du frontend — WIX_CLIENT_ID et compagnie — est gitignored et est effacé chaque fois que la machine distante redémarre, donc il doit être redérivé, pas supposé persister). Le correctif Vite est conservateur : il saute (en enregistrant pourquoi) plutôt que de toucher une forme de config qu'il ne reconnaît pas, donc un modèle qui définit cela délibérément l'emporte. Les hooks corrigent à la place en composant wix env pull devant tout ce qu'un hook exécute déjà — de manière idempotente, jamais dupliqué sur une réexécution — puisqu'un hook existant fait presque toujours quelque chose de sans rapport (ex. codegen) et le sauter intégralement laisserait silencieusement ce projet sans prévisualisation fonctionnelle.

Après résolution, signalez l'URL du tableau de bord déterministe et retournez au routeur. Les identifiants sources ne sont jamais demandés jusqu'à ce que cette destination existe.

Sortie

WIX_SITE_ID de config/wix.env persiste, orchestration/destination.json pour un nouveau site (choix, méthode de création, tentative, id de métasite, éditeur vérifié et relecture de publication), et l'URL du tableau de bord signalée — ou une demande durable dans orchestration/user-actions/ qui nomme ce qui manque. C'est ce qu'une exécution dispatché doit produire.