rp-execute-import

Exécuter le pipeline de migration généré et capturer les résultats d'import.

Objectif

Cette skill exécute le pipeline d'extraction/import généré pour le projet actif une fois que la configuration et la génération de code sont terminées.

Entrées requises

code généré sous migrations/<project>/src/
migrations/<project>/import-plan.md
migrations/<project>/setup-verification.md

Préconditions

Ne pas procéder tant que :

la vérification de configuration montre que les éléments requis sont validés ou acceptés ; un bloqueur non résolu arrête en needs-user
le code de lecture, transformation et écriture existe pour les entités prévues
la stratégie d'exécution pour les lots, les retries et les points de contrôle est claire
le rapport de plan d'exécution a été présenté et l'utilisateur l'a accepté (voir ci-dessous)

Plan d'exécution et acceptation de l'utilisateur (contrôle obligatoire)

Ce contrôle précède toutes les écritures sur le site de l'utilisateur — à la fois l'approvisionnement rp-execute-setup et cet import. Avant d'écrire quoi que ce soit, produisez un rapport de plan d'exécution lisible et obtenez l'acceptation explicite de l'utilisateur. N'écrivez rien tant que l'utilisateur n'accepte pas. Le rapport doit montrer :

Modifications de configuration à effectuer en premier : apps à installer (Blog / Members / Wix-Data enabler), activation de Wix Data et collections à créer — afin que l'utilisateur voie les changements du site, pas seulement les écritures de contenu.
Ce qui sera importé et où : chaque entité source → sa cible Wix (app ou collection) avec nombres d'enregistrements — par ex. posts → Wix Blog (1088) ; episodes → PodcastEpisodes (86) ; catégories/tags → taxonomies Blog ; media → Media Manager (~1499).
Ce qui ne migrera pas proprement / nécessite une action manuelle : les éléments avec perte d'informations et bloqués, tirés du registre de fidélité du plan de mapping et des éléments setup-verification.md toujours manuels ou bloqués — par ex. hiérarchie de catégories aplatie, commentaires anonymisés, brouillons absents sans auth, mise à niveau du plan de stockage requise. Ceci doit également inclure toute cible sans primitive Wix vérifiée — précisez si elle bascule vers une collection CMS générique, vers un appel unverified/best-effort dérivé au runtime, ou est ignorée. Rien d'non-vérifié ou de lossy ne peut être écrit sans d'abord figurer ici pour consentement. Les coupons suivent la même règle native-first que les autres entités Wix natives : préférez les Coupons Wix natifs et ne mentionnez le fallback CMS que pour une sémantique de coupon vraiment non supportée.
- Énoncer toujours l'exclusion des données d'analyse explicitement. Les données d'analyse historiques — statistiques de trafic / visiteurs accumulées sur la source — sont hors périmètre et ne sont pas importées (voir « Hors périmètre » ci-dessous). Appelez-le dans le plan afin que l'utilisateur sache avant d'accepter que les données d'analyse ne migreront pas ; ne laissez pas cela passer silencieusement.
Ordre et idempotence : l'ordre d'écriture et comment les réexécutions dédupliquent. Précisez que les ID source sont la clé de migration stable, tandis que nombreuses cibles Wix natives ont des ID assignés par le serveur. Le plan doit préciser si chaque entité réexécutée se résout via un champ source-id contrôlé par le client sur la cible ou via un crosswalk durable sourceId -> targetId.

Persistez ceci dans import-plan.md (ou un rapport adjacent). C'est le point d'approbation défini : le job pause, présente le plan à l'utilisateur et reprend seulement sur acceptation. Rien n'est écrit avant l'acceptation.

Hors périmètre — analytics (amélioration future)

N'essayez pas d'importer les données d'analyse. Les statistiques de trafic / visiteurs historiques — les enregistrements d'analyse accumulés sur la source (pages vues, sessions, comptages de visiteurs, rapports chronologiques) — ne font pas partie de la migration. Ne générez pas de lecteurs, de transformations ou d'écrivains pour eux. (Ceci concerne les données, non la configuration/configuration d'analytics telle que les balises de suivi — c'est une préoccupation séparée et ce n'est pas ce que cette exclusion couvre.)

Surfacez-le avant l'exécution. Cette exclusion doit figurer dans la liste « Ce ne sera pas migré » du rapport de plan d'exécution (voir le contrôle ci-dessus) afin que l'utilisateur soit informé avant d'accepter et de commencer l'écriture — non découvert après.
Amélioration future. La migration d'analytics est un élément de portée différé, non une limitation permanente. Si/quand un chemin d'analytics source→Wix fidèle existe, revisitez et levez cette exclusion. Jusque-là, traitez les analytics comme explicitement ignorées.

Exécuter les scripts générés — jamais un flux MCP agentic (requis)

L'import est effectué en exécutant l'artefact généré (node le point d'entrée du projet sous migrations/<project>/src/), qui écrit sur Wix via son propre transport (fetch + identifiants injectés vers www.wixapis.com, ou le SDK client Wix). L'agent ne doit pas effectuer les écritures d'import lui-même en émettant des appels Wix MCP par enregistrement (CallWixSiteAPI) et en traduisant les formes manuellement.

(Portée : cette règle est spécifique à l'import. L'exécution de configuration (rp-execute-setup) peut actuellement utiliser l'agent+MCP pour les écritures d'approvisionnement — une décision provisoire, d'autres options restant en discussion.)

Pourquoi l'import doit exécuter l'artefact :

Reproductibilité et idempotence. Les réexécutions, la reprise à partir d'un point de contrôle, l'ordre d'écriture et la déduplication basée sur l'ID source résident dans l'artefact. Pour les entités Wix natives dont les ID cibles sont assignés par le serveur, cela signifie que l'artefact doit maintenir et consulter un crosswalk durable sourceId -> targetId. Un agent reconstruisant les écritures ad hoc contourne tout cela — un pipeline de données en masse et redémarrable ne peut pas être piloté manuellement par enregistrement.
Formes vérifiées. L'artefact appelle les primitives vérifiées de rp-target-wix. Un agent reconstruisant les corps de requête live réouvre la classe exacte de bogue de forme que nous avons éliminée (FR-007 enums Ricos, FR-009 corps de tag, FR-010 heroImage.id).
MCP peut être absent au runtime. Les serveurs MCP authentifiés interactivement peuvent manquer dans les exécutions headless/cron, donc MCP ne peut pas être utilisé comme transport d'écriture quelle que soit l'approche du runtime. De toute façon, les écritures doivent circuler via l'artefact testé, pas être reconstruites par le modèle.
Honnêteté de la validation. Écrire à la main via MCP laisse le propre code d'auth, d'exécution de requête, de polling asynchrone de média, de retry et de point de contrôle de l'artefact non exercés — un test vert ne dit alors rien sur le chemin que les vrais utilisateurs obtiennent. Le rôle du Wix MCP ici est l'ancrage/vérification au moment de la génération de code et le test de contrat live unique dans rp-target-wix, pas le transport d'import.

Conséquence pour les identifiants : l'artefact a besoin de vraies identifiants d'écriture Wix pour s'exécuter. S'ils sont absents, arrêtez en needs-user — ne substituez pas l'authentification du compte MCP de l'agent pour « accomplir les écritures ». Les identifiants manquants sont un bloqueur à signaler, pas un chemin à contourner. (Remarque : les écritures live wporg-news Run 2/3 sont passées par l'agent+MCP comme test sans token. Cela a validé les formes de requête uniquement ; ce n'est explicitement pas comment les imports s'exécutent — le chemin fetch/auth/polling propre de l'artefact a encore besoin d'une validation end-to-end live.)

Fichiers de configuration

Avant d'exécuter le point d'entrée généré, vérifiez que les fichiers de configuration locaux au projet existent et contiennent les valeurs requises :

migrations/<project>/config/wix.env
- WIX_SITE_ID
- WIX_AUTH_TOKEN ou une autre clé d'authentification Wix supportée par le code généré
migrations/<project>/config/source.<platform>.env
- valeurs source spécifiques à la plateforme, par exemple WordPress : WP_BASE_URL, WP_USERNAME, WP_APPLICATION_PASSWORD

Le script généré doit charger ces fichiers et ensuite permettre à l'env process de les surcharger. Si une clé requise est manquante ou vide, arrêtez en needs-user avec le nom exact de la clé. Ne jamais imprimer les valeurs secrètes.

Traitez migrations/<project>/config/*.env comme porteur de secrets une fois qu'il peut contenir de vraies valeurs. Ne les inspectez pas avec des lectures de fichier entier qui impriment le contenu dans la sortie d'outil ; vérifiez seulement l'existence et le statut des clés requises (present, blank, missing).

Workflow

Résoudre le projet actif.
Examiner le plan d'import et le code généré ; présenter le rapport de plan d'exécution et obtenir l'acceptation (voir ci-dessus) avant toute écriture.
Exécuter un chemin de validation sûr en premier quand possible, comme dry-run, lot d'exemple ou validation en lecture seule. Si l'import de média est dans la portée et que les URL de média source sont locales/privées (localhost, 127.0.0.1, hôtes Docker uniquement, etc.), ne pas traiter un dry-run réussi comme preuve que l'import de média live peut fonctionner. L'import Wix Media récupère les URLs depuis les serveurs Wix, donc l'utilisateur doit soit exposer la source via un tunnel HTTPS public, soit ignorer/différer le média. C'est optionnel et, autant que nous le sachions aujourd'hui, affecte seulement l'import de média.
Exécuter l'extraction de source en premier en utilisant le point d'entrée du lecteur généré (par exemple node src/extract-source.js, ou un mode équivalent run-import.js --extract-only). Cette étape écrit des fichiers source durables sous le projet et doit être terminée avant la phase d'écriture.
Exécuter l'import en exécutant le point d'entrée d'import généré (par exemple node src/run-import.js ou node src/run-import.js --import-only) avec les identifiants injectés via config/env. L'import doit lire à partir des fichiers extraits sur le disque — pas en relisant la source en mémoire, et pas en émettant les écritures via l'agent/MCP.
Capturer les comptages, erreurs, retries, enregistrements ignorés et informations de point de contrôle.
Enregistrer un journal d'exécution durable.

Média localhost avant import live

Quand les URL de média source sont locales/privées, demandez à l'utilisateur de choisir un chemin avant les écritures de média live :

Exposer la source avec un tunnel HTTPS public tel que ngrok :

brew install ngrok
ngrok config add-authtoken "<YOUR_AUTHTOKEN>"
ngrok http 8090
export WP_BASE_URL=https://<id>.ngrok-free.app

Ou ignorer/différer l'import de média et enregistrer l'effet sur les images héros, galeries, fichiers téléchargeables et autres références dépendantes de média.

Les entités sans média peuvent continuer si le plan d'exécution exclut ou diffère clairement le média.

Artefact à créer ou mettre à jour

migrations/<project>/execution-log.md

Contenu minimum du journal d'exécution

timestamp d'exécution
commande ou point d'entrée utilisé
localisation de l'extraction de source / manifeste utilisé
entités traitées
enregistrements lus, transformés, écrits, ignorés, échoués
comportement de retry
erreurs bloquantes
réparation de suivi

Garde-fous

Les écritures d'import passent par l'artefact exécuté, pas l'agent. Ne jamais effectuer des écritures d'import via CallWixSiteAPI/MCP comme substitut à l'exécution du script. MCP est vérification uniquement ici (voir la section ci-dessus). (L'exécution de configuration est hors portée pour cette règle — voir rp-execute-setup.)
Préférer les dry-runs ou lots d'exemples avant l'import complet.
Arrêter sur les défaillances de mapping ou d'écriture systémiques plutôt que d'amplifier les mauvaises écritures.
Préserver suffisamment de logging pour supporter la relecture et le débogage.