wix-replatform

Par wix · skills

Dirige les migrations source-to-Wix de RePlatform vers le prochain module de workflow requis en inspectant les artefacts de migration faisant référence. À utiliser pour démarrer, reprendre ou récupérer une exécution de migration.

npx skills add https://github.com/wix/skills --skill wix-replatform

wix-replatform

wix-replatform est le superviseur compact d'une migration source-vers-Wix reprise. Il sélectionne un module interne pour l'étape active ; il ne porte pas chaque procédure d'étape dans son propre contexte.

Contrat toujours actif

  • Résoudre le projet actif sous migrations/<project>/ (ou REPLATFORM_MIGRATIONS_DIR) avant d'inspecter ou de créer quoi que ce soit. Seuls les artefacts de ce projet font autorité.
  • Démarrer/reprendre resources/rp-telemetry/ au début de chaque exécution et le finaliser à un état terminal. Ne jamais écrire manuellement les événements de télémétrie.
  • Utiliser l'orchestration JSON plus les artefacts d'étape validés comme autorité de reprise. Les journaux et l'historique de chat sont uniquement du contexte diagnostic.
  • Préserver les données utilisateur : écrire de manière idempotente, dédupliquer par identité source, reprendre plutôt que redémarrer, et ne jamais créer un deuxième site de destination pour une migration.
  • Ne jamais imprimer de secrets, de contenus de config porteurs de secrets, de tokens ou d'identifiants. Signaler uniquement les noms de clés et l'état présent/vide/manquant.
  • Ne pas déclarer une migration complète à partir de prose ou d'un seul artefact. Le routeur déterministe et l'artefact de complétude agrégée possèdent la complétude terminale.

Pipeline

intake → destination → source inputs → preflight → (standard: discovery → mapping → codegen;
quick: adapter preflight → quick plan) → setup discovery → website handoff
→ safety review/approval → setup → import
→ storefront continuation (website only) → aggregate finalization

Les modes de livraison sont management (backend uniquement), website (frontend uniquement) et management_and_website (le flux intégré ci-dessus). Accepter l'entrée utilisateur both comme management_and_website et persister la valeur canonique.

Pour deliveryMode=management, la finalisation agrégée nécessite une comptabilité d'import backend valide. Pour deliveryMode=management_and_website, elle nécessite également un website/completion.json à jour avec examen des captures d'écran complété, aucun écart critique/élevé non résolu, et preuve de lancement. execution/completion-report.json est la comptabilité backend, jamais la complétude de migration website par elle-même.

Router avant d'agir

À chaque tour nouveau ou repris :

  1. Résoudre le projet et initialiser/charger ses artefacts d'orchestration.
  2. Exécuter node skills/wix-replatform/scripts/orchestration-route.js <projectDir>.
  3. Charger uniquement la nextResource retournée par le routeur, puis suivre cette ressource jusqu'à ce qu'elle écrive sa sortie requise ou un bloqueur durable.
  4. Router à nouveau après chaque limite d'étape. Ne jamais décider l'étape suivante de mémoire.

Si un artefact est malformé, partiel, obsolète ou échoue son validateur, traiter l'étape productrice comme incomplète et router vers le producteur. Ne pas créer d'artefacts de remplacement parallèles.

Carte de modules chargée à la demande

Situation du routeur Charger
project, delivery mode, source mode, ou grouped intake est non résolu resources/rp-project-intake/
destination est absente, conflictuelle, ou nécessite création/adoption resources/rp-destination/
source URL/files/config/acquisition mode/credentials sont requis resources/rp-source-inputs/
preflight déterministe est manquant ou bloqué resources/rp-preflight/
quick mode nécessite résolution de plateforme, preflight d'endpoint, plan, extraction, ou import resources/rp-quick-<platform>/ sélectionné
source schema est manquant resources/rp-discovery/ et son adaptateur source sélectionné
mapping est manquant ou nécessite review resources/rp-mapper/
Wix requirements sont manquants resources/rp-setup-discovery/
import code/review est manquant ou obsolète resources/rp-import-codegen/
setup verification est manquant resources/rp-execute-setup/
backend completion report est manquant resources/rp-execute-import/
frontend-only work, ou integrated website handoff/build/gap loop/release receipt est incomplet resources/rp-website-continuation/
aggregate completion est manquant resources/rp-execution-policy/

La ressource nommée par le routeur est le contrat d'étape complet. Ne pas charger de source-file, secret, scaffolding, ou storefront procedures pour une étape où ils sont non pertinents.

Politique d'interaction

Le mode normal demande uniquement une entrée requise manquante, un projet actif véritablement ambigu, ou une approbation d'écriture obligatoire. Poser une question à la fois sauf si un module en dit autrement.

Avant les écritures, préserver la porte d'approbation du plan d'exécution obligatoire. La découverte en lecture seule, le mapping, la vérification de setup, la génération de code et la review interviennent avant.

Mode d'import management quick

Quand managementImportMode=quick, sélectionner l'adaptateur de plateforme uniquement après que la sonde source déterministe identifie une plateforme compatible. Le mode quick est un import de données publiques borné : la quick-mode.json versionnée de l'adaptateur possède ses routes source, graphe d'entité, matrice de champs, et exclusions. Ne pas exécuter de discovery agentique, mapping, ou génération de code spécifique au projet pour la branche backend quick. Toujours exécuter destination setup, installation d'application, vérifications de sécurité Catalog-V3 et notification, approbation d'exécution, runtime d'écriture partagé, crosswalks, et comptabilité d'exécution. Si aucun adaptateur ne qualifie, persister le résultat unsupported-mode et demander à l'utilisateur de sélectionner le mode standard ; ne jamais basculer silencieusement.

S'arrêter uniquement pour entrée requise manquante/invalide, une action manuelle sans API, ou une défaillance systémique/risque de perte de données. Un arrêt doit persister le code, la preuve, le propriétaire, et l'action de déblocage exacte ; ne jamais s'arrêter silencieusement.

Mode 1-click

Quand explicitement demandé par l'utilisateur, enregistrer automationMode=one_click avec source=user et appliquer ce qui suit. Un mode manquant ou une valeur one_click enregistrée comme deterministic_inference/prior_artifact est un mode interactif normal et ne doit pas sauter un checkpoint :

  • collecter toutes les valeurs d'intake toujours manquantes dans une demande groupée unique ; puis ne pas faire de pause pour les approbations de routine ;
  • enregistrer les approbations de mapping et d'exécution comme approved, decidedBy=agent ; sauter une pause sans état est invalide ;
  • pour les exécutions CSV/file-only, valider et accepter l'aperçu d'échantillon requis comme l'agent ; sans one-click explicitement rédigé par l'utilisateur, faire une pause pour la review de mapping normale, la validation d'aperçu d'échantillon, et l'approbation d'exécution ;
  • par défaut, un nouveau site isolé sauf si une destination existante est explicitement fournie ou déjà épinglée ; choisir la portée website de manière déterministe à partir des familles de routes découvertes ;
  • réessayer les défaillances de résolution PATH/tool sous le shell de connexion interactif compatible de l'opérateur ; demander l'escalade requise de sandbox navigateur/réseau et réessayer avant de l'appeler bloqué ;
  • réessayer la récupération évidente avant d'arrêter : aligned shell en premier pour les défaillances PATH/tool, puis l'escalade de réessai requise pour sandbox navigateur ou défaillances réseau/API ;
  • continuer à travers le livrable complet sélectionné. En mode management_and_website cela inclut build frontend, analyse de gap post-build, boucle de correction bornée, et réception de lancement ; quand l'utilisateur a sélectionné facelift à l'intake, cela inclut aussi la review facelift post-clone séparée ;
  • avant de céder, re-router. Une exécution 1-click est uniquement completed avec completion/migration-completion.json, ou blocked avec un bloqueur durable typé.

Utiliser le shell Node/Yarn local compatible de l'opérateur lors de la récupération d'une défaillance de résolution PATH ou tool. Les chemins shell spécifiques à la machine n'appartiennent qu'aux instructions d'agent locales, git-exclues.

Contrat de shell interactif repo-local : une défaillance de résolution PATH/tool en première tentative peut signifier que la commande a s'exécuté sous un shell simple, non-interactif qui n'a jamais sourcé le profil Node/Yarn de l'opérateur. Résoudre le shell de connexion compatible de l'opérateur à partir de l'environnement local ou des instructions d'agent git-exclues, vérifier qu'il est exécutable, et réessayer la même commande exacte à travers ce shell en mode connexion interactif pour que le profil qui résout node/yarn/npx se charge. Ne pas coder en dur un chemin shell spécifique à la machine dans cette skill publique. Escalader à un bloqueur durable uniquement si le réessai compatible-shell lui-même échoue.

Garde-fous

  • Ne jamais contourner un validateur, mise à jour d'état d'approbation, notification mute vérifiée, ou porte Catalog-V3 pour faire paraître une étape terminée.
  • website signifie frontend uniquement ; management_and_website signifie la migration backend et frontend intégrée. Ne jamais remettre la destination de migration intégrée à la skill frontend ou créer un deuxième site frontend en ce mode.
  • Ne pas implémenter un storefront manuellement quand wix-headless-replatform n'est pas disponible ; persister un bloqueur avec la capacité runtime requise exacte.
  • En mode management, toujours générer website/handoff.* après setup discovery pour qu'un storefront ultérieur puisse démarrer sans répéter la backend discovery.

Skills similaires