wix-headless-replatform

Rôle

Piloter une interface Wix Headless visuellement soignée et suffisamment fidèle à partir d'un site source. Le périmètre implémenté couvre une page d'accueil résolue et la sortie par défaut est projects/<project-name>, dérivée du nom d'hôte. Utiliser Wix CLI Headless, Astro, TypeScript et Tailwind ; n'utiliser React que pour les îles interactives complexes. Rejeter les demandes de périmètre multi-pages et d'URL explicites avec une explication exploitable jusqu'à ce qu'un workflow approuvé ultérieurement définisse la résolution des pages et des preuves partagées entre routes.

Cette skill d'entrée est le superviseur. Elle décide de l'étape suivante du workflow et ne charge que la ressource pour cette étape. Ne pas charger à l'avance toutes les ressources ou références : les règles spécifiques à une étape sont délibérément chargées à la demande.

Deux modes existent :

Clone autonome : URL source vers un nouveau projet Wix CLI Headless réel.
Phase de migration : --handoff <migration-project>/website/handoff.json continue sur la destination appartenant à la migration. Ne jamais omettre --handoff pour une migration intégrée : la commande autonome crée un second site.

Invariants non négociables

Traiter la page d'accueil publique de marque demandée comme autorisée ; appliquer les limites dans references/safety.md sans poser de question d'autorisation séparée.
L'extraction assistée par navigateur est obligatoire. Ne pas substituer l'extraction HTML uniquement.
Résoudre la page d'accueil avant capture. Construire uniquement à partir d'un manifeste d'extraction validé et gelé ; les observations brutes ne sont jamais des entrées constructeur.
Une sortie autonome doit être un scaffold Wix CLI réussi avec identité Wix valide et scripts dev et build exécutables. Ne jamais créer manuellement un substitut ressemblant à Wix.
En mode migration, réutiliser le site/projet du handoff et l'intention de liaison route/données ; ne pas créer ou rediriger une second destination.
Préserver la structure source, les preuves du premier viewport, la hiérarchie chrome, les assets source, les polices, les interactions essentielles, le SEO, le comportement d'URL interne et le comportement de fallback de marque.
Une construction n'est pas l'achèvement. L'achèvement exige l'examen visuel post-construction accepté et la preuve de boucle de comblage des écarts décrite par rp-qa-gap-loop, plus acceptation optionnelle de facelift seulement quand l'utilisateur a explicitement sélectionné le mode facelift.

Protocole superviseur

À chaque exécution nouvelle ou reprise :

Résoudre l'URL source, le répertoire de sortie et le mode. En mode migration, lire website/handoff.json et docs/site-clone/frontend-automation-state.json en premier.
Sélectionner la première étape incomplète du tableau ci-dessous et lire uniquement le SKILL.md de cette ressource plus les références qu'elle mentionne explicitement.
Exécuter cette étape jusqu'à ce qu'elle écrive son artefact durable requis, ou enregistre un blocker spécifique et authentique avec preuves et action de déblocage exacte.
Re-sélectionner l'étape après chaque limite. Ne pas dire qu'une prochaine étape requise « doit se produire » et terminer l'exécution ; charger sa ressource et l'effectuer.

Étape	Charger uniquement si	Ressource	Résultat durable
Contexte	mode, périmètre, projet ou environnement navigateur non résolus	`resources/rp-project-context/SKILL.md`	contexte valide, dossier d'approbation, état projet/plan exécutable, ou blocker
Preuves	extraction gelée de page d'accueil absente ou obsolète	`resources/rp-source-evidence/SKILL.md`	`extraction/latest.json` validé et manifeste gelé, ou blocker global
Implémentation	plan de construction gelé existe et interface d'accueil incomplète	`resources/rp-ui-implementation/SKILL.md`	implémentation d'accueil exécutable et consciente du hash de manifeste
Vérification et amélioration	construction, QA, comparaison, examen, correction, rapport, lancement ou réception incomplets	`resources/rp-qa-gap-loop/SKILL.md`	résultat accepté, `done_with_gaps`, ou blocker global
Facelift optionnel	clone normal accepté et état d'automatisation demande facelift	`resources/rp-facelift/SKILL.md`	examen facelift accepté, ou blocker

Quand frontendPhase.allowedNow est plan, compléter uniquement le travail contexte et preuves admissible au plan et laisser un dossier d'état plan résumable. Quand c'est build, continuer à travers l'implémentation et la vérification sur le projet appartenant à la migration.

Continuation en un clic

Un handoff de migration déclarant automationMode: "one_click" autorise la routine de périmètre et les points de contrôle frontend. Enregistrer ces approbations dans docs/site-clone/frontend-automation-state.json ; ne pas mettre en pause pour demander si procéder avec une étape requise, examen de capture d'écran, ou passage de correction autorisé. Une demande de facelift explicite peut être portée de l'admission 1-clic, mais elle reste contrôlée jusqu'à l'acceptation du clone normal ; 1-clic n'implique jamais facelift par lui-même.

Dans une exécution de construction 1-clic, continuer à sélectionner et exécuter les étapes jusqu'à ce que l'un de ces résultats durables existe :

website/completion.json est valide et l'examen visuel le plus récent est complet sans constatation d'identité critique/haute ouverte ; ou
cinq cycles d'écart visuel ont été complétés et website/completion.json enregistre le statut terminal véridique done_with_gaps avec les preuves examinées finales ; ou
un blocker authentique est enregistré avec propriétaire, preuves, tentative de récupération, et action/autorité suivante exacte nécessaire.

Un écart d'extraction local appartenant au propriétaire n'est pas un blocker authentique. Continuer le travail non lié, utiliser au maximum deux tentatives ciblées distinctes de récupération, puis construire la fermeture de dépendance affectée provisoirement et exposer les choix post-assemblage dans final-report.json et .md.

Avant de classer un shell, navigateur ou panne réseau comme blocker, utiliser le tri PATH de la chaîne d'outils Wix/Yarn local repo et suivre l'ordre de récupération dans resources/rp-project-context/SKILL.md : nouvelle tentative shell alignée, puis l'escalade obligatoire navigateur/réseau et nouvelle tentative, puis blocker seulement s'il échoue toujours ou approbation est en attente. Après chaque itération d'écart, retourner immédiatement au tableau des étapes ; ne jamais traiter une première construction, un plan rapporté, ou une importation backend comme complétion frontend.

En mode migration la construction doit aussi laisser le manifeste de route final que la préservation d'ancien lien consomme (output-contract.md, « Reçu terminal de migration »). Un site construit n'est pas une preuve que les anciennes URL fonctionnent ; l'application de redirection et la vérification publique restent en attente jusqu'à ce que l'étape de cutover les exécute.

Commandes

Exécuter node scripts/site-clone.mjs <source-url> pour le mode autonome, ou node scripts/site-clone.mjs <source-url> --handoff <path> pour le mode migration. La ressource active donne les commandes exactes et les entrées pour son étape.

Références

Les ressources chargent leurs propres références. Les contrats partagés sont conservés sous references/ : safety.md, workflow.md, extraction-schema.md, output-contract.md, qa-checklist.md, et les contrats interaction/layout/control/normalisation/écart.