rp-website-continuation

Utilisez cette ressource uniquement quand le routeur d'orchestration retourne nextResource: resources/rp-website-continuation/.

Contrat

Destinations de l'éditeur. Quand targetSiteType est studio ou harmony, il n'existe pas de migration de site automatique supportée : n'invoquez jamais wix-headless-replatform, ne scaffoldez jamais frontend/, et ne publiez jamais le site. Le routeur rapporte editor_website_handoff_outstanding ; maintenez l'obligation de site en attente via les actions d'opérateur du rapport de fin editor_website_unfinished / editor_publication_outstanding (propriétaire du site/designer, puis Operateur de Cutover) et ne déclarez pas la fin combinée tant qu'un website/completion.json valide et publié n'existe pas pour le site lié.

Pour deliveryMode=website, c'est une exécution frontend uniquement — mais elle a toujours besoin d'une destination, et cette destination est du ressort de rp-destination, pas de cette skill ou de wix-headless-replatform. Ne laissez pas wix-headless-replatform scaffolder son propre site ici : sa seule protection contre un doublon est « un dossier local a-t-il déjà un package.json », ce qui n'est pas la même vérification de compte, persistance de WIX_SITE_ID, et rapport d'URL du dashboard que chaque autre mode de livraison obtient.

1. Résolvez la destination via rp-destination d'abord, en scaffoldant dans <projectDir>/frontend avec --site-template blank (il n'y a pas de catalogue backend à provisionner, et cela correspond au choix de template par défaut de wix-headless-replatform pour le clonage de scope initial que cette invocation effectue). Persistez WIX_SITE_ID dans config/wix.env et rapportez l'URL du dashboard, comme tout autre mode.
2. Invoquez alors wix-headless-replatform avec l'URL source et --out <projectDir>/frontend ; n'exécutez pas la découverte backend, le mapping, la configuration, ou l'import. Parce que <projectDir>/frontend contient déjà un scaffold valide depuis l'étape 1, la vérification de réutilisation autonome de wix-headless-replatform le trouve et continue à partir de là plutôt que de scaffolder un deuxième site.

Finalisez sa compilation et sa boucle d'écarts. Seulement si l'utilisateur a explicitement demandé un lifting au recueil, exécutez le lifting UI/UX Pro Max séparé après clonage et l'examen d'acceptation ; sinon ne chargez pas cette étape. Puis publiez et écrivez website/completion.json avec finalize-migration-website.mjs --project-dir <projectDir> --out <projectDir>/frontend --release-url <public-url>.

execution/completion-report.json désigne la comptabilité d'import backend. Ce n'est pas le résultat terminal d'une migration deliveryMode=management_and_website.

Deux documents différents, deux tâches différentes. website/handoff.json est le package backend-vers-frontend : une compilation de site a besoin de son contrat de liaisons avant de commencer, donc il continue d'être produit quand il l'est, à partir du plan. Ce n'est pas le compte rendu de l'exécution de la migration. C'est execution/review/migration-handoff.md, généré après la dernière écriture de execution/completion-report.json — ne remettez jamais handoff-summary.md à quiconque comme compte rendu de ce que la migration a fait.

La vérification de fraîcheur se compose avec ceci : une fois que l'import backend écrit son rapport de fin, liveImportSummary ou recoveryLog, l'empreinte enregistrée se déplace et le routeur retourne stale_website_handoff, forçant le package à être régénéré à partir de l'exécution terminée avant que la compilation frontend la consomme.

Quand la raison de routage est missing_website_handoff ou stale_website_handoff, exécutez d'abord node skills/wix-replatform/scripts/website-handoff-generate.js <projectDir> et routez à nouveau. Sinon chargez le website/handoff.json actuel, puis invoquez wix-headless-replatform en mode migration via son drapeau --handoff :

node scripts/site-clone.mjs <source-url> --handoff <projectDir>/website/handoff.json

--handoff est requis ici, pas optionnel. C'est la seule chose qui met wix-headless-replatform en mode phase-migration ; sans cela la skill revient au mode autonome et exécute inconditionnellement un nouvel appel @wix/new headless — un deuxième site orphelin, qui est exactement l'échec que « ne créez jamais un deuxième site de destination » (voir rp-destination) existe pour prévenir. Continuez sa compilation réelle, l'analyse d'écarts post-compilation, la boucle de correction bornée, et la séquence de publication. Ne vous arrêtez pas après l'implémentation ou une compilation réussie.

La skill frontend doit écrire website/completion.json de façon atomique avant que cette ressource puisse terminer. Un reçu réussi contient le handoffFingerprint actuel, l'examen de screenshot terminé, zéro écarts critiques/élevés non résolus, et un état de publication publié (ou explicitement non applicable).

Si un vrai bloqueur persiste après les tentatives requises de récupération/escalade en 1 clic, persistez un reçu status: "blocked" avec le code de bloqueur, la preuve, la récupération tentée, le propriétaire, et l'action d'déblocage exacte. Puis routez à nouveau. Ne décrivez pas une devanture en attente comme une migration complétée.

Après que la boucle d'écarts ait passé et la devanture publiée, écrivez le reçu avec :

node skills/wix-headless-replatform/scripts/finalize-migration-website.mjs \
  --handoff <projectDir>/website/handoff.json --release-url <public-url>