rp-website-continuation
Utilisez cette ressource uniquement quand le routeur d'orchestration retourne
nextResource: resources/rp-website-continuation/.
Contrat
Pour deliveryMode=website, c'est une exécution frontend uniquement — mais elle a toujours besoin d'une destination,
et cette destination reste le travail de rp-destination, pas celui de cette skill ou de
wix-headless-replatform. Ne laissez pas wix-headless-replatform scaffolder son propre site ici :
sa seule sauvegarde contre un doublon est « un dossier local a-t-il déjà un
package.json », ce qui n'est pas la même barrière de confirmation de compte, la
persistance de WIX_SITE_ID, et le rapport d'URL du dashboard que chaque autre mode de delivery obtient.
- Résolvez la destination via
rp-destinationd'abord, en scafoldant dans<projectDir>/frontendavec--site-template blank(il n'y a aucun catalogue backend à provisionner, et cela correspond au choix de template par défaut dewix-headless-replatformpour le clonage du scope home que cette invocation effectue). PersistezWIX_SITE_IDdansconfig/wix.envet rapportez l'URL du dashboard, comme pour tout autre mode. - Puis invoquez
wix-headless-replatformavec l'URL source et--out <projectDir>/frontend; n'exécutez pas la découverte, le mapping, la configuration ou l'import du backend. Parce que<projectDir>/frontendcontient déjà un scaffold valide de l'étape 1, la vérification de réutilisation autonome propre dewix-headless-replatformle trouve et continue à partir de là au lieu de scaffolder un deuxième site.
Finalisez son build et la boucle de gap. Uniquement si l'utilisateur a explicitement demandé un facelift à l'intake,
exécutez le facelift UI/UX Pro Max séparé post-clone et l'examen d'acceptation ; sinon ne chargez pas
cette étape. Puis releasez et écrivez website/completion.json avec
finalize-migration-website.mjs --project-dir <projectDir> --out <projectDir>/frontend --release-url <public-url>.
execution/completion-report.json signifie la comptabilité d'import backend. Ce n'est pas le
résultat terminal d'une migration deliveryMode=management_and_website.
Quand le motif du 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 courant, puis invoquez
wix-headless-replatform en mode migration via son flag --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 jamais créer un deuxième site destination » (voir rp-destination)
existe pour prévenir. Continuez son vrai build, l'analyse post-build des gaps, la boucle de fix bornée,
et la séquence de release. N'arrêtez pas après l'implémentation ou un build réussi.
La skill frontend doit atomiquement écrire website/completion.json avant que cette ressource puisse
finir. Un reçu réussi a le handoffFingerprint courant, un examen de screenshot complété, zéro gaps
critiques/hauts non résolus, et un état de release libéré (ou explicitement non applicable).
Si un bloquant vrai persiste après les tentatives requises de récupération 1-clic/escalade, persistez un
reçu status: "blocked" avec le code du bloquant, les preuves, la récupération tentée, le propriétaire,
et l'action de déblocage exacte. Puis routez à nouveau. Ne décrivez pas une vitrine en attente
comme une migration complétée.
Après que la boucle de gap soit passée et que la vitrine soit releasé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>