Contexte du projet

Chargez cette ressource uniquement quand le mode de la run, la source/portée, le projet de sortie, l'état d'approbation ou l'environnement navigateur n'est pas résolu. Elle maîtrise les décisions de configuration, non l'extraction ou le travail d'interface utilisateur.

Consultez references/safety.md et les sections mode/portée et preflight applicables de references/workflow.md. Consultez references/output-contract.md uniquement lors de la validation de l'artefact du projet ou de l'état d'automatisation.

Résoudre le mode et la portée

• Le mode Standalone utilise l'URL source publique et nécessite la portée home sans --urls.
• Le mode Migration nécessite --handoff. Consultez ses familles de routes, l'intention d'URL publique, les liaisons Wix, la politique de slug, websiteScope, automationMode et frontendPhase.allowedNow. Le handoff fait autorité.
• Si un handoff demande une reconstruction non-home ou avec URL explicite, arrêtez-vous avec l'exigence exploitable pour le futur workflow multi-page. Le mode one-click n'étend pas la portée.
• En phase plan, écrivez/rafraîchissez uniquement le contexte et les preuves éligibles au plan ; n'exigez pas un frontend exécutable ni ne tentez de build/release. En build, validez le projet appartenant à la migration avant de continuer.

Provisionner ou valider le projet

Pour le clonage home standalone, provisionnez ou vérifiez le répertoire de sortie final exact avant la génération d'artefacts ou l'écriture d'interface utilisateur. Il doit s'agir d'un vrai scaffold Wix CLI réussi, pas d'un secours manuel, et contenir une configuration Wix valide plus les scripts dev et build dans package.json. Créez son yarn.lock vide comme limite de projet en amont. Si le scaffold utilise @wix/astro-wix-hosting-adapter, supprimez une dépendance @astrojs/cloudflare standalone directe avant la normalisation install/build.

Pour le mode Migration, réutilisez uniquement le projet/site appartenant au handoff. Si l'identité du projet ou son contrat exécutable échoue, enregistrez la défaillance précise et récupérez-la ; ne créez jamais un scaffold frère.

Utilisez clear-wix-starter.mjs après qu'un template valide crée des fichiers de démo, avant le début du travail d'interface utilisateur de clonage.

Preflight navigateur et récupération

Avant la run d'extraction navigateur :

node scripts/browser-extraction-preflight.mjs --project-root <project-root>

Si nécessaire, tentez d'abord --fix. L'hôte doit avoir une résolution node_modules normale, les dépendances navigateur/design requises et Chromium ; Yarn Plug'n'Play n'est pas suffisant.

Pour ce repository, exécutez les commandes sensibles aux chemins Wix/Yarn dans un zsh interactif avec la chaîne NVM locale du repo. Dans une run one-click, retentez une incompatibilité shell/PATH une fois sous ce shell aligné. Si le lancement du navigateur ou l'accès réseau est bloqué par sandbox, demandez l'escalade requise et retentez. Enregistrez un blocker seulement après ; une approbation runtime en attente est une vraie attente, pas une raison de demander des confirmations de routine non liées.

Écrivez/mettez à jour frontend-automation-state.json chaque fois que le mode, la phase, la portée effective, le checkpoint de portée ou la politique d'auto-progression change. Revenez au superviseur racine une fois le contexte durable.