wix-headless-replatform

Rôle

Piloter un frontend Wix Headless suffisamment proche et visuellement poli à partir d'un site source. La portée implémentée est 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 ; utiliser React uniquement pour les îles interactives complexes. Rejeter la portée multi-pages et les URL explicites avec une explication exploitable jusqu'à ce qu'un workflow approuvé ultérieur définisse la résolution de 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 charge uniquement la ressource pour cette étape. Ne pas précharger toutes les ressources ou références : les règles spécifiques à chaque étape sont intentionnellement 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 détenue par 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 homepage publique de marque demandée comme autorisée ; appliquer les limites dans references/safety.md sans poser de question d'autorisation routine distincte.
• L'extraction assistée par navigateur est obligatoire. Ne pas substituer une extraction HTML seule.
• Résoudre la page d'accueil avant la capture. Construire uniquement à partir d'un manifeste d'extraction validé et gelé ; les observations brutes ne sont jamais des entrées de 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 à la main un substitut en forme de Wix.
• En mode migration, réutiliser le site/projet du handoff et l'intention de liaison route/données ; ne pas créer ou réorienter une seconde destination.
• Préserver la structure source, les preuves du premier viewport, la hiérarchie chrome, les assets source, les polices, les interactions core, le SEO, le comportement des URL internes et le comportement de fallback de marque.
• Une construction n'est pas l'achèvement. L'achèvement demande l'examen visuel post-construction accepté et la preuve de boucle de gap décrite par rp-qa-gap-loop, plus acceptation optionnelle de facelift uniquement quand l'utilisateur a explicitement sélectionné le mode facelift.

Protocole superviseur

À chaque exécution nouvelle ou reprise :

1. Résoudre l'URL source, le répertoire de sortie et le mode. En mode migration, lire d'abord website/handoff.json et docs/site-clone/frontend-automation-state.json.
2. 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 explicitement demande.
3. Exécuter cette étape jusqu'à ce qu'elle écrive son artifact durable requis, ou enregistre un blocker spécifique et authentique avec preuve et action de déblocage exacte.
4. Re-sélectionner l'étape après chaque limite. Ne pas dire qu'une étape requise suivante « doit arriver » et terminer l'exécution ; charger sa ressource et l'exécuter.

Quand frontendPhase.allowedNow est plan, accomplir uniquement le travail context et evidence admissible au plan et laisser un enregistrement d'état plan reprendre. Quand il est build, continuer à travers implementation et verification contre le projet détenu par la migration.

Continuation en un clic

Un handoff migration déclarant automationMode: "one_click" autorise les checkpoint scope et frontend routines. Enregistrer ces approbations dans docs/site-clone/frontend-automation-state.json ; ne pas faire de pause pour demander si procéder avec une étape requise, review screenshot ou passe correction autorisée. Une demande de facelift explicite peut être portée depuis l'intake 1-clic, mais reste fermée jusqu'à acceptation du clone normal ; 1-clic n'implique jamais facelift par soi-même.

Dans une exécution build un-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 la dernière visual review complète sans aucun finding identité critique/élevée ouverte ; ou
• cinq cycles visual gap ont été complétés et website/completion.json enregistre le statut terminal véridique done_with_gaps avec la preuve finale reviewée ; ou
• un blocker authentique est enregistré avec propriétaire, preuve, tentative de récupération et action/autorité exacte suivante requise.

Un gap d'extraction local détenu n'est pas un blocker authentique. Continuer le travail non lié, ne pas dépasser deux tentatives de récupération ciblées distinctes, puis construire la fermeture dépendance affectée provisoirement et surfacer les choix post-assembly dans final-report.json et .md.

Avant de classer un shell, navigateur ou défaillance réseau en blocker, utiliser l'ordre PATH Wix/Yarn local repo et suivre l'ordre de récupération dans resources/rp-project-context/SKILL.md : retry aligned-shell, puis l'escalade browser/network requise et retry, puis blocker uniquement si ça échoue toujours ou approbation en attente. Après chaque itération gap, revenir immédiatement à la table d'étape ; ne jamais traiter une première construction, un plan rapporté ou import backend comme fin frontend.

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 et entrées exactes 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/normalization/gap.