rp-execute-setup

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

Objectif

Cette compétence valide les prérequis découverts par rp-setup-discovery. Elle peut aussi 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 aux preuves exportées de cet environnement

Privilégiez les artefacts de configuration lisibles par machine ci-dessus. Les résumés en Markdown sont des rendus secondaires pour les humains, pas le contrat d'exécution primaire.

Configuration

Privilégiez la configuration locale du projet plutôt que l'état shell ad hoc. config/wix.env doit exister avant la vérification/configuration et contenir :

WIX_SITE_STRATEGY=
WIX_SITE_ID=
WIX_AUTH_TOKEN=

WIX_SITE_STRATEGY est toujours requis. WIX_SITE_ID est requis avant la vérification/configuration. Si la stratégie est new et aucun site n'a encore été créé, arrêtez-vous à needs-user et réorientez vers l'étape de création de site plutôt que de demander un ID de site existant. WIX_AUTH_TOKEN est la clé d'identification Wix canonique pour ce flux de projet ; pour les sites headless scaffoldés par CLI, il contient l'identifiant d'écriture du site (un jeton CLI envoyé en tant que jeton Bearer). Ne jamais afficher les valeurs secrètes. Créez le jeton sans l'imprimer en exécutant scripts/mint-token.sh à partir de la racine du projet de migration :

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

La copie canonique se trouve à skills/replatform/resources/rp-execute-setup/scripts/mint-token.sh. rp-import-codegen la copie dans migrations/<project>/scripts/ au moment du scaffolding — ne l'écrivez pas from scratch. Le script lit WIX_SITE_ID depuis config/wix.env, appelle npx @wix/cli@latest token --site "$WIX_SITE_ID", capture stdout (format du jeton : OauthNG.JWS.<base64>.<base64>.<sig>), l'écrit directement dans config/wix.env en tant que WIX_AUTH_TOKEN, et affiche uniquement une confirmation de décompte de caractères. NE PAS exécuter la commande de jeton brute dans un appel d'outil Bash — elle imprime l'identifiant en transcription.

Si WIX_SITE_ID manque pour un flux RePlatform new site + headless, le chemin de récupération est l'étape de Wix CLI headless scaffold définie dans replatform → « Headless site creation » (npm create @wix/new@latest headless). L'API Projects au niveau du compte est dépréciée pour ce flux. Remarque : le scaffold n'installe pas Wix Stores — c'est cette compétence (setup) qui installe Wix Stores et autres apps requises (via la compétence wix-manage / chemin app-install), puis les vérifie, avant l'import.

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

Flux de travail

Résoudre le projet actif.
Lire les artefacts de configuration lisibles par machine.
Vérifier chaque app requise, collection, schéma, champ et permission via le contrat de runtime setup partagé. Si les exigences de configuration proviennent de la connaissance du domaine, conservez la targetRef d'origine dans la sortie de vérification afin que les avertissements d'exécution ultérieurs puissent être retracés vers l'orientation d'entité sélectionnée.
Enregistrer le statut réussi, échoué ou bloqué pour chaque élément.
Si l'exécution est autorisée, effectuer les étapes de configuration manquantes via le runtime setup partagé et re-vérifier.
Sauvegarder les résultats de vérification et les artefacts d'exécution de configuration.

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

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

Cette compétence maîtrise l'exécution de ces artefacts. Elle ne maîtrise pas la redéfinition du plan de configuration ou la création d'un point de contrôle d'approbation de configuration séparé.

La configuration dry-run utilise le même plan de configuration et le même exécuteur que la configuration live. Quand DRY_RUN est activé par configuration 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 MCP tool, ou la commande CLI que la configuration live utiliserait. Le runtime setup partagé capture alors cette intention, marque l'étape planned_dry_run, et ne doit pas invoquer les MCP tools Wix, les commandes CLI Wix, les appels SDK, ou les appels fetch qui accèdent ou mutent l'état du compte/site Wix.

Ne pas ignorer DRY_RUN=true avec --no-dry-run pour la vérification ou la configuration de setup sauf si l'utilisateur a explicitement approuvé la sortie de dry-run pour la configuration. Préférez éviter cet ignorer entièrement quand un dry-run ou un plan/rapport peut répondre à la question. La seule action live 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 replatform ; cette compétence ne doit pas traiter cette exception comme une permission pour exécuter des écritures live ou des sondes de vérification live.

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

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

Par défaut, configurez via API. Ne pas marquer une exigence comme « manuelle » ou « action du propriétaire » jusqu'à avoir confirmé qu'aucune API ne peut le faire.

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

l'exécution de setup consomme des artefacts de setup machine
l'exécution de setup suit le comportement du runtime partagé
la configuration de setup n'est pas re-planifiée live par l'agent

La gate d'approbation est inchangée : pas d'écriture de setup avant que l'utilisateur accepte le plan d'exécution.

Si une surface Wix tool utile est disponible dans le runtime, elle peut être utilisée sous le runtime setup partagé pour la vérification ou le transport. Si aucune surface n'est disponible, ne traitez pas cela seul comme un bloquant ; continuez avec le contrat setup/runtime partagé et le comportement rp-target-wix vérifié, marquant les éléments non vérifiés selon les besoins.

Ne procédez à une posture docs-only/read-only que quand le MCP est vraiment indisponible et l'étape peut encore produire une sortie utile non-destructive.

Mécanismes concrets :

Mettre en sourdine les notifications du site EN PREMIER (spec 0012). 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 setup — immédiatement après que le site cible soit disponible et que WIX_AUTH_TOKEN soit créé, et avant les installations d'app, la création de collection, ou toute autre configuration — afin que les écritures de setup elles-mêmes ne puissent pas déclencher de 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-mise en sourdine 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 élément 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 OauthNG du site mintéd par CLI fonctionne ; une clé API de compte reçoit un 403 body-vide. Un échec de mise en sourdine est un bloquant, pas un avertissement : la run s'arrête à needs-user et ne procède jamais aux écritures d'import — pas de mode dégradé, pas de continue-anyway. Ne jamais appeler unmuteSiteNotifications depuis cette compétence — la levée de sourdine est une demande explicite du propriétaire gérée au niveau de l'orchestrateur. Enregistrez le résultat de configuration via l'enregistreur 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 manifeste via l'événement user_decision de la gate d'approbation) — pas de nouvelle surface de telemetry.
Installer / activer les apps Wix (Blog, Members, etc.) EST automatable. Utilisez l'API App Installation :
1. Pré-vérifier 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é, installer avec POST /apps-installer-service/v1/app-instance/install. Body (tous les champs requis — confirmé par des 400s live) : { appInstance: { appDefId, enabled: true }, tenant: { tenantType: "SITE", id: <siteId> }, installType: "INSTALL_TYPE_SITE", appsInstallOptions: {} }. (La pré-vérification is-permitted-to-install utilise un body différent, basé sur oneof et est informationnelle uniquement — si sa validation vous pose problème, ignorez-la et fiez-vous à /install.)
3. Lister l'état actuel avec GET /apps-installer-service/v1/app-instances.
- Fonder appDefId sur la table officielle "Apps Created by Wix" (/docs/api-reference/articles/work-with-wix-apis/platform/about-apps-created-by-wix), PAS sur un exemple docs — p. ex. l'exemple install-app utilise 1380b703-…, qui est Wix eCommerce, pas Blog. Installer la mauvaise app sur un site live est un risque réel ; vérifiez que l'ID correspond à l'app que vous avez l'intention d'installer.
- Après installer Wix Stores, vérifier que le catalogue est V3 — avant tout écrit Stores. L'installation de Stores ne garantit pas Catalog V3 : sur un site scaffoldé à partir du modèle headless blank, l'installation arrive avec V1_CATALOG, que les primitives V3 Stores ne peuvent pas écrire (vérifié de manière difficile sur une migration live, 2026-07-30). La version du catalogue est fixée à la configuration — il n'y a pas de switch V1 → V3 in-place. Vérifiez-la avec l'API Catalog Versioning read-only :
```
curl -s -H "Authorization: Bearer $WIX_AUTH_TOKEN" -H "wix-site-id: $WIX_SITE_ID" \
  https://www.wixapis.com/stores/v3/provision/version
```
  catalogVersion est V3_CATALOG (procédez), STORES_NOT_INSTALLED (installez, re-vérifiez), ou V1_CATALOG — enregistrez-le comme un bloquant dans setup/setup-verification.json, n'écrivez rien à Stores, et arrêtez-vous à needs-user. La prévention est en amont de cette compétence (replatform → « Headless site creation » : scaffold avec --site-template commerce) ; la récupération est un site de remplacement approuvé par l'utilisateur, jamais un créé silencieusement, et jamais un site sonde jetable.
Collections Wix Data / 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 body /install que tout autre app ; elle installe aussi automatiquement une app dépendance 1a711f05-2040-47df-a9f0-4f9cddb4c3c6). Une fois installée, la REST simple POST /wix-data/v2/collections crée des collections NATIVE sans WDE0110 — pas de toggle éditeur de code, pas d'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'app data-collections-extension plus ancienne (authoring une app personnalisée qui déclare des collections) est maintenant un fallback — uniquement nécessaire si vous devez déclarer les schémas de collection à l'installation, et elle ne peut toujours pas exprimer les champs REFERENCE (ajoutez-les après l'installation via create-field).
- Remarque : l'app « Wix CMS » autonome (appDefId 675bbcef-…) n'est pas installable (is-permitted-to-install → false) — ne l'utilisez pas ; utilisez e593b0bd-….
Miroir CMS crosswalk d'import optionnel. Les entités Wix natives utilisent l'état crosswalk local sous migrations/<project>/state/crosswalk/ pour l'idempotence. Configurez une collection native ImportCrosswalk uniquement quand les artefacts de setup approuvés demandent explicitement un miroir CMS pour le seeding de site existant ou la référence site-locale. Après activation de Wix Data, créez-la 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 configurez pas cette collection comme le mécanisme d'idempotence native-entity par défaut. Si les artefacts en amont appellent toujours le miroir optionnel MigrationRefs, normalisez-les ici plutôt que de créer les deux collections.
Vraiment manuel (aucune API existe) : mettre à niveau le plan de stockage, générer des identifiants de système externe (p. ex. un WordPress Application Password), 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/report artifacts émis par le runtime setup partagé
captures de requête dry-run dans migrations/<project>/state/attempts/wix-request-captures.ndjson quand la setup est exécutée avec dry-run activé

Les vérifications live setup Stores qui nécessitent un enregistrement de sonde doivent utiliser la CLI de vérification rp-target-wix partagée, pas des snippets ad hoc. Pour le support des abonnements, exécutez :

node skills/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 contract-ledger aux côtés de la vérification setup. La proposition n'est pas elle-même une connaissance produit partagée ; l'orchestrateur 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 report. Si le cleanup échoue, ne marquez pas la sonde comme propre ; préservez l'avertissement et exécutez la commande de récupération stores delete-probe émise après la correction des permissions ou de l'état cible.

Format de sortie de vérification

Pour chaque capture d'exigence :

nom de l'exigence
état attendu
état observé
statut : réussi, échoué, bloqué
correction requise

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

ID d'exigence stable
ID d'étape checkpoint/configuration quand applicable
référence de preuve de vérification
mode d'automation : automatable | manual | blocked | unverified

Vérification optionnelle de joignabilité média

Quand la migration inclut l'import de média par URL source, vérifiez si les URL média découvertes sont publiquement joignables par Wix. Si l'URL source est localhost, 127.0.0.1, ou un hôte private-only, marquez l'import 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 sachions 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 révision :

Tunneliser les URL 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éécrivez les URL média à cette base.
Passer/reporter les médias : procédez uniquement si le plan d'exécution dit clairement que les médias et toute référence dépendante média (images héros, galeries, téléchargements) seront passés ou reportés.

Ngrok quick setup 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

Divisez le travail de cette compétence par effet de bord :

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

Le comportement d'exécution lui-même devrait provenir du runtime setup partagé et des artefacts setup approuvés, pas de logique par-run improvisée dans cette compétence.

Guardrails

Ne jamais rapporter la setup comme complète sans preuve.
Privilégiez les artefacts de vérification setup lisibles par machine plutôt que le rapportage prose-only.
Avant de marquer un élément comme bloqué ou manuel, confirmez qu'aucune API ne peut le faire (voir Configuration ci-dessus). Réservez « manuel » pour les étapes storage/billing/external-credential.
Si les credentials ou permissions manquent vraiment, marquez l'élément comme bloqué et déclarez l'API exacte qui a été refusée et pourquoi.
Ne pas commencer l'exécution d'import depuis cette compétence.
Ne pas réinterpréter les exigences de configuration à partir de Markdown quand les artefacts machine existent.