rp-execute-setup

Vérifier que la configuration côté Wix requise existe et est prête pour l'import.

Objectif

Cette skill valide les prérequis découverts par rp-setup-discovery. Elle peut également piloter le travail de configuration quand l'environnement et les permissions le permettent.

Entrées requises

migrations/<project>/setup/setup-plan.json
migrations/<project>/setup/setup-requirements.json
migrations/<project>/execution/execution-manifest.json
migrations/<project>/config/wix.env ou valeurs d'environnement équivalentes
accès à l'environnement Wix cible ou preuves exportées depuis cet environnement

Préférez les artefacts de configuration lisibles par machine ci-dessus. Les résumés de configuration Markdown sont des renderings secondaires pour les humains, pas le contrat d'exécution principal.

Configuration

Préférez la configuration locale au projet plutôt qu'un état shell ad hoc. config/wix.env doit exister avant la vérification/provisioning de configuration et contenir :

WIX_SITE_STRATEGY=
WIX_SITE_ID=
WIX_AUTH_TOKEN=

WIX_SITE_STRATEGY est toujours requis. WIX_SITE_ID est requis avant que la vérification/provisioning de configuration commence. Si la stratégie est new et aucun site n'a encore été créé, arrêtez-vous à needs-user et redirigez vers l'étape de création de site plutôt que de demander un ID de site existant.

Quand WIX_SITE_ID désigne un site que cette exécution n'a pas créé, la posture de configuration change : vérifiez et combler les lacunes, ne provisionnez jamais à partir de zéro. Le site est déjà en utilisation, donc traitez tout ce qui s'y trouve comme un état préexistant à contourner plutôt que comme une ardoise vierge :

Attendez-vous à ce que les apps, collections et champs existent déjà. Installez uniquement le delta que le mapping a réellement besoin. Une app déjà installée est un PASS, pas une étape à refaire, et le re-provisioning est comment un site fonctionnant acquiert des collections dupliquées.
Ne supprimez jamais et ne recréez jamais une entité pour « corriger » une discordance. Une collection dont le schéma diffère de ce que le mapping attend est une exigence blocked avec une note de correction — c'est au propriétaire de décider, pas à cette skill.
Un verdict V1_CATALOG est terminal ici. La récupération du site de remplacement dans resources/rp-destination/ s'applique uniquement à un site que cette exécution a échafaudé. Enregistrez le bloqueur, n'écrivez rien dans Stores, arrêtez-vous à needs-user.
Provisionnez la collection ImportCrosswalk sur le site (voir « Miroir CMS crosswalk d'import optionnel » ci-dessous) — sur une destination existante, ce n'est pas optionnel.
Enregistrez quelles exigences étaient déjà satisfaites par rapport à celles nouvellement provisionnées dans setup/setup-verification.json. Sur un site que l'utilisateur possède, « nous n'avons rien changé ici » est en soi un résultat digne d'être signalé.

WIX_AUTH_TOKEN est la clé de credential Wix canonique pour ce flux de projet ; pour les sites headless échafaudés par CLI, elle contient le credential d'écriture du site (un token CLI envoyé comme token Bearer). Ne publiez jamais les valeurs secrètes. Générez le token sans l'imprimer à la transcription en exécutant scripts/mint-token.sh depuis la racine du projet de migration :

bash migrations/<project>/scripts/mint-token.sh

La copie canonique se trouve dans skills/wix-replatform/resources/rp-execute-setup/scripts/mint-token.sh. rp-import-codegen la copie dans migrations/<project>/scripts/ au moment de l'échafaudage — ne l'écrivez pas à partir de zéro. Le script lit WIX_SITE_ID depuis config/wix.env, appelle npx @wix/cli@latest token --site "$WIX_SITE_ID", capture stdout (forme du token : OauthNG.JWS.<base64>.<base64>.<sig>), l'écrit directement dans config/wix.env comme WIX_AUTH_TOKEN, et affiche uniquement une confirmation du nombre de caractères. N'EXÉCUTEZ PAS la commande token brute dans un appel d'outil Bash — elle affiche le credential à la transcription.

Si WIX_SITE_ID est manquant pour un flux RePlatform new site + headless, le chemin de récupération est resources/rp-destination/, qui échafaude via npm create @wix/new@latest headless. L'API Projects au niveau du compte est dépréciée pour ce workflow. Note : l'échafaudage n'installe pas Wix Stores — cette skill (setup) est l'endroit où Wix Stores et autres apps requises sont installées (via la skill wix-manage / chemin app-install), puis vérifiées, avant l'import.

Traitez migrations/<project>/config/*.env comme porteurs de secret une fois qu'ils peuvent contenir de vraies valeurs. Ne les vérifiez pas avec des lectures de fichier complet qui échouent les contenus dans la sortie d'outil. Vérifiez uniquement l'existence plus le statut present / blank / missing pour les clés requises.

Workflow

Résolvez le projet actif.
Lisez les artefacts de configuration lisibles par machine.
Vérifiez chaque app requise, collection, schéma, champ et permission à travers le contrat de runtime de configuration partagé. Si les exigences de configuration provenaient de connaissances du domaine, préservez le targetRef d'origine dans la sortie de vérification afin que les avertissements d'exécution ultérieurs puissent être retracés à la guidance d'entité sélectionnée.
Enregistrez le statut pass, fail ou blocked pour chaque item.
Si l'exécution est autorisée, effectuez les étapes de configuration manquantes via le runtime de configuration partagé et re-vérifiez.
Enregistrez les résultats de vérification et les artefacts d'exécution de configuration.

Exécutez les artefacts de configuration — ne re-dérivez pas la configuration à partir de la prose

L'exécution de configuration doit suivre les artefacts machine approuvés et le runtime de configuration partagé. Elle ne devrait pas reconstruire les décisions de configuration à partir de markdown ou de raisonnements ad hoc quand setup/setup-plan.json, setup/setup-requirements.json et execution/execution-manifest.json existent déjà.

Cette skill possède l'exécution de ces artefacts. Elle ne possède pas la redéfinition du plan de configuration ou la création d'un checkpoint d'approbation de configuration séparé.

La configuration en dry-run utilise le même plan de configuration et le même exécuteur de configuration que la configuration en direct. Quand DRY_RUN est activé par config ou --dry-run, chaque étape de configuration doit d'abord être réduite à une intention structurée décrivant la requête REST, l'opération SDK, l'appel d'outil MCP, ou la commande CLI que la configuration en direct utiliserait. Le runtime de configuration partagé capture ensuite cette intention, marque l'étape planned_dry_run, et ne doit pas invoquer les outils Wix MCP, les commandes Wix CLI, les appels SDK, ou les appels fetch qui accèdent ou mutent l'état de compte/site Wix.

Ne surchargez pas DRY_RUN=true avec --no-dry-run pour la vérification ou le provisioning de configuration sauf si l'utilisateur a explicitement approuvé la sortie du dry-run pour la configuration. Préférez éviter complètement cette surcharge quand un dry-run ou un plan/rapport peut répondre à la question. La seule action en direct autorisée tandis qu'un projet reste autrement en mode dry-run est l'étape de création de nouveau site séparée gérée en amont par wix-replatform ; cette skill ne doit pas traiter cette exception comme une permission d'exécuter des écritures de configuration en direct ou des probes de vérification de configuration en direct.

La configuration en dry-run ne doit pas mettre à jour setup/setup-verification.json d'une manière qui prétend qu'une capacité Wix, une installation d'app, une collection, ou un site existe. Écrivez plutôt un rapport de configuration dry-run séparé ou des observations clairement scoped au dry-run.

Provisioning — épuisez les options programmatiques avant de déclarer quoi que ce soit « manuel »

Par défaut, provisionnez via l'API. Ne pas étiqueter une exigence « manuel » ou « action du propriétaire » jusqu'à ce que vous ayez confirmé qu'aucune API ne peut le faire.

Le contrat préféré est un runtime de configuration partagé détenu par rp-target-wix, exécuté contre les artefacts de configuration machine produits en amont. Cette skill peut utiliser les surfaces API/MCP Wix disponibles comme le transport sous ce runtime, mais le contrat au niveau RePlatform est :

l'exécution de configuration consomme les artefacts de configuration machine
l'exécution de configuration suit le comportement du runtime partagé
le provisioning de configuration n'est pas re-planifié en direct par l'agent

Le gate d'approbation est inchangé : pas d'écriture de configuration avant que l'utilisateur n'accepte le plan d'exécution.

Si une surface d'outil Wix utile est disponible dans le runtime, elle peut être utilisée sous le runtime de configuration partagé pour la vérification ou le transport. Si aucune surface de ce type n'est disponible, ne traitez pas seul cela comme un bloqueur ; continuez avec le contrat de configuration partagée/runtime et le comportement rp-target-wix vérifié, en marquant les items non vérifiés selon les besoins.

Procédez dans une posture docs-only/read-only uniquement quand le MCP est véritablement indisponible et l'étape peut toujours produire une sortie utile non-destructive.

Mécanismes concrets :

Murez les notifications du site EN PREMIER. Quand les artefacts de configuration portent l'exigence mute-site-notifications (toujours pour WIX_SITE_STRATEGY=new ; opt-in pour les sites existants), exécutez-la avant chaque autre écriture de configuration — immédiatement après que le site cible soit disponible et WIX_AUTH_TOKEN soit généré, et avant les installations d'app, la création de collection, ou tout autre provisioning — afin que les écritures de configuration elles-mêmes ne puissent pas déclencher les notifications. Utilisez la primitive muteSiteNotifications depuis rp-target-wix/lib/wix-writers.js (VERIFIED 2026-08-04) avec une raison d'identification de projet (RePlatform migration — <project>); vérifiez via getSiteMuteState → muted: true (méthode de vérification status-read; une re-mute idempotente n'est qu'un fallback documenté, méthode idempotent-recall). Enregistrez le résultat dans setup/setup-verification.json sur l'exigence au moment de l'appel — statut (pass/fail/blocked), timestamp, et méthode de vérification — comme tout autre item vérifié ; les rapports en aval lisent cet état enregistré, ne l'inférez jamais. AUTH TRAP : les endpoints acceptent uniquement les tokens utilisateur — le token de site OauthNG généré par CLI fonctionne ; une clé API de compte obtient un 403 avec corps vide. Un mute échoué est un bloqueur, pas un avertissement : l'exécution s'arrête à needs-user et ne procède jamais aux écritures d'import — pas de mode dégradé, pas de continue-anyway. N'appelez jamais unmuteSiteNotifications depuis cette skill — unmute est une demande explicite du propriétaire gérée au niveau de l'orchestrator. Enregistrez le résultat du provisioning via le recorder rp-telemetry standard comme tout autre boundary notable (un événement error avec error_code en cas d'échec ; l'opt-in du site existant se surface via l'événement user_decision du gate d'approbation) — aucune nouvelle surface de telemetry.
Installer / activer les apps Wix (Blog, Members, etc.) EST automatable. Utilisez l'API App Installation :
1. Pré-vérifiez avec POST /apps-installer-service/v1/app-instance/is-permitted-to-install (read-only) pour voir si l'identité peut installer l'app.
2. Si autorisé, installez avec POST /apps-installer-service/v1/app-instance/install. Corps (tous les champs requis — confirmé par live 400s) : { appInstance: { appDefId, enabled: true }, tenant: { tenantType: "SITE", id: <siteId> }, installType: "INSTALL_TYPE_SITE", appsInstallOptions: {} }. (La pré-vérification is-permitted-to-install utilise un corps différent, basé sur oneof, et n'est qu'informationnelle — si sa validation vous pose problème, sautez-la et fiez-vous au /install.)
3. Listez l'état actuel avec GET /apps-installer-service/v1/app-instances.
- Basez appDefId sur le tableau officiel « Apps Created by Wix » (/docs/api-reference/articles/work-with-wix-apis/platform/about-apps-created-by-wix), PAS depuis un exemple docs — ex. l'exemple install-app utilise 1380b703-…, qui est Wix eCommerce, pas Blog. Installer la mauvaise app sur un site en direct est un vrai risque ; vérifiez que l'ID correspond à l'app que vous entendez.
- Installer Wix Stores sur un site que cette exécution a créé provisionne Catalog V3 inconditionnellement — Catalog V3 est maintenant garanti au provisioning indépendamment du template d'échafaudage (0079-catalog-v3-guaranteed-retire-v1-gate.md), donc il n'y a pas d'étape de vérification ici pour ce cas. Cela ne s'applique pas à un site existant que cette exécution n'a pas créé — voir « Un verdict V1_CATALOG est terminal ici » ci-dessus pour ce cas, qui est inchangé.
Wix Data / collections CMS (le cas WDE0110: Wix Code not enabled). Activez Wix Data en installant l'app Wix Data appDefId e593b0bd-b783-45b8-97c2-873d42aacaf4 via l'API App Installation (même forme de corps /install que toute autre app ; elle installe aussi automatiquement une app de dépendance 1a711f05-2040-47df-a9f0-4f9cddb4c3c6). Une fois installée, la simple REST POST /wix-data/v2/collections crée des collections NATIVE sans WDE0110 — aucune bascule d'éditeur de code, aucune app personnalisée requise. Verified live 2026-06-10 sur un site gratuit frais (install → 200 ; collection create → 200 collectionType: NATIVE).
- C'est le chemin préféré. L'ancienne app data-collections-extension (authoring d'une app personnalisée qui déclare les collections) est maintenant un fallback — nécessaire uniquement si vous devez déclarer les schémas de collection au moment de l'installation, et elle ne peut toujours pas exprimer les champs REFERENCE (ajoutez-les après l'installation via create-field).
- Note : l'app autonome « Wix CMS » (appDefId 675bbcef-…) n'est pas installable (is-permitted-to-install → false) — NE l'utilisez PAS ; utilisez e593b0bd-….
Miroir CMS crosswalk d'import — REQUIS sur une destination existante, optionnel sur un site que cette exécution a créé. Les entités Wix natives utilisent l'état crosswalk local sous migrations/<project>/state/crosswalk/ pour l'idempotence. Cet état est par-projet, donc une frontière de projet est aussi une frontière d'idempotence — et sur un site que l'utilisateur possède déjà, cette migration n'est pas nécessairement la seule chose qui y a jamais écrit. Refléter le crosswalk dans une collection native ImportCrosswalk sur la destination met le record « ce qui a déjà été importé ici » SUR LE SITE, où toute exécution ultérieure peut le voir : un re-import d'un autre projet, une deuxième migration de la même source, ou une exécution démarrée depuis une surface différente coûte alors le re-mapping au lieu de dupliquer le catalogue. Provisionnez-le dès que WIX_SITE_STRATEGY=existing ; sur un site que cette exécution a échafaudé, il reste optionnel (il n'y a rien d'autre qui aurait pu y écrire), demandé par les artefacts de configuration approuvés. Après activation de Wix Data, créez-le avec POST /wix-data/v2/collections et des champs tels que entityType (TEXT), sourceId (TEXT), sourceStableKey (TEXT), targetId (TEXT), targetType (TEXT), et updatedAt (DATETIME/TEXT). Ne provisionnez pas cette collection comme le mécanisme d'idempotence d'entité native par défaut. Si les artefacts en amont nomment toujours le miroir optionnel MigrationRefs, normalisez-le ici plutôt que de créer les deux collections.
Véritablement manuel (aucune API n'existe) : upgrader le plan de stockage, générer des credentials de système externe (ex. un Application Password WordPress), et facturation au niveau du compte. Ce sont les seules catégories qui peuvent être rapportées comme manuelles — et uniquement après confirmation qu'aucune API ne les couvre.

Artefact à créer ou mettre à jour

migrations/<project>/setup/setup-verification.json
migrations/<project>/setup/review/setup-verification.md
audit/rapport artifacts émis par le runtime de configuration partagé
captures de requêtes dry-run dans migrations/<project>/state/attempts/wix-request-captures.ndjson quand la configuration est exécutée avec dry-run activé

Les vérifications de configuration live Stores qui requièrent un record de probe doivent utiliser l'CLI de vérification rp-target-wix partagé, pas des snippets ad hoc. Pour le support d'abonnement, exécutez :

node skills/wix-replatform/resources/rp-target-wix/scripts/verify-stores.js stores subscription-create \
  --artifact migrations/<project>/setup/stores-subscription-verification.json \
  --proposal-artifact migrations/<project>/setup/contract-ledger-proposal.json

Gardez l'artefact de vérification JSON et la proposition de contract-ledger à côté de la vérification de configuration. La proposition n'est pas elle-même connaissance produit partagée ; l'orchestrator doit promouvoir les données de proposition acceptées dans rp-target-wix/domains/**/entities/*.json dans la même session ou enregistrer une raison de deferral. Si le cleanup échoue, ne marquez pas la probe comme nettoyée ; préservez l'avertissement et exécutez la commande de récupération stores delete-probe émise après que les permissions ou l'état cible soit corrigé.

Format de sortie de vérification

Pour chaque capture d'exigence :

nom de l'exigence
état attendu
état observé
statut : passed, failed, blocked
remédiation requise

L'artefact de vérification lisible par machine doit aussi préserver :

ID d'exigence stable
ID de checkpoint/provisioning step le cas échéant
référence de preuve de vérification
mode d'automation : automatable | manual | blocked | unverified

Vérification optionnelle de la réachabilité du média

Quand la migration inclut l'import de média par URL source, vérifiez si les URLs de média découvertes sont publiquement accessibles par Wix. Si l'URL source est localhost, 127.0.0.1, ou un hôte private-only, marquez l'import de média comme blocked ou deferred, mais ne bloquez pas les entités non-média sans rapport. C'est une configuration optionnelle et, autant que nous le savons aujourd'hui, affecte uniquement l'import Wix Media.

Enregistrez le chemin choisi par l'utilisateur dans setup/setup-verification.json et rendez-le dans le markdown de revue :

Tunnelisez les URLs de média : demandez à l'utilisateur d'exposer la source via un tunnel HTTPS public, puis utilisez cette URL pour WP_BASE_URL / SOURCE_URL ou réécrire les URLs de média à cette base.
Sautez/déférez le média : procédez uniquement si le plan d'exécution dit clairement que le média et les références dépendantes du média (images hero, galeries, téléchargements) seront sautés ou déférés.

Configuration rapide de Ngrok pour macOS :

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

Politique de runtime

Scindez le travail de cette skill par effet de bord :

La vérification est read-only — vérifier ce qui est installé, ce qui manque, et ce qui est véritablement manuel. Elle s'exécute avant le gate d'acceptation du plan d'exécution et alimente le plan.
Les écritures de provisioning — installer les apps, activer Wix Data (via l'enabler data-collections), créer les collections, ajouter des champs — se produisent uniquement après que l'utilisateur accepte le plan d'exécution. Aucune écriture de site avant l'acceptation. Une fois accepté, le consentement « Migrate » couvre les écritures individuelles, donc ne re-signalez pas par app/collection. Arrêtez-vous à needs-user uniquement pour les items véritablement manuels (upgrade du plan de stockage) ou une credential manquante/invalide.

Le comportement d'exécution lui-même doit provenir du runtime de configuration partagé et des artefacts de configuration approuvés, pas de la logique improvisée par exécution dans cette skill.

Garde-fous

Ne rapportez jamais la configuration comme complète sans preuve.
Préférez les artefacts de vérification de configuration lisibles par machine à la seule rapporte en prose.
Avant de marquer un item bloqué ou manuel, confirmez qu'aucune API ne peut l'effectuer (voir Provisioning ci-dessus). Réservez « manuel » aux étapes stockage/facturation/credential externe.
Si les credentials ou permissions sont véritablement manquants, marquez l'item bloqué et indiquez l'API exacte qui a été refusée et pourquoi.
N'démarrez pas l'exécution d'import depuis cette skill.
Ne réinterprétez pas les exigences de configuration à partir de markdown quand les artefacts machine existent.