rp-execute-setup

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

Objectif

Cette skill 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-requirements.md
migrations/<project>/config/wix.env ou valeurs d'environnement équivalentes
accès à l'environnement Wix cible ou à des preuves exportées de cet environnement

Config

Préférer la config locale du projet à l'état shell ad hoc. config/wix.env doit exister avant la vérification/provisioning de configuration et contenir :

WIX_SITE_ID=
WIX_AUTH_TOKEN=

Si l'une des valeurs requises manque après chargement de la config et de l'env du processus, s'arrêter sur needs-user avec le nom de la clé manquante. Ne jamais imprimer le token.

Traiter migrations/<project>/config/*.env comme porteur de secrets une fois qu'ils peuvent contenir des valeurs réelles. Ne pas les vérifier avec des lectures de fichier complet qui répercutent les contenus en sortie d'outil. Vérifier uniquement l'existence et le statut present / blank / missing pour les clés requises.

Flux de travail

Résoudre le projet actif.
Lire l'artefact des exigences de configuration.
Vérifier chaque app, collection, schéma, champ et permission requis.
Enregistrer le statut pass, fail ou blocked pour chaque élément.
Si l'exécution est autorisée, effectuer les étapes de configuration manquantes avec prudence et re-vérifier.
Sauvegarder les résultats de vérification.

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

Privilégier le provisioning via API. Ne pas étiqueter une exigence « manuel » ou « action propriétaire » tant que vous n'avez pas confirmé qu'aucune API ne peut le faire.

Transport (décision intérimaire) : les écritures de provisioning de configuration — installations d'apps, activation de Wix Data, création de collections/champs — peuvent être effectuées par l'agent via le Wix MCP (CallWixSiteAPI) pour l'instant. Cela diffère de l'import, qui doit exécuter le script généré et ne jamais utiliser MCP comme transport d'écriture (rp-execute-import → "Exécuter les scripts générés — jamais un flux agentic MCP"). La raison pour laquelle la configuration est traitée différemment : c'est un petit ensemble fini, mostly one-time, d'appels avec peu de logique par projet (la variance est quelles apps/collections — des données, pas du code), pas un pipeline en masse redémarrable. Ceci est un choix intérimaire ; d'autres options (par ex. une bibliothèque de provisioning partagée et paramétrée dans rp-target-wix pilotée par setup-requirements.md) sont encore en discussion. La gate d'approbation est inchangée : aucune écriture de configuration avant que l'utilisateur accepte le plan d'exécution.

Si le transport Wix MCP / CallWixSiteAPI attendu pour la vérification/provisioning de configuration manque du runtime, traiter cela comme une lacune prérequise avant de supposer que vous devez travailler en aveugle :

d'abord essayer de s'assurer que le Wix MCP est installé/connecté dans le runtime actuel
si l'environnement supporte les flux d'installation de connecteur/plugin, les utiliser
sinon s'arrêter sur needs-user avec les instructions d'installation/connexion exactes du Wix MCP et expliquer quelles capacités de vérification/provisioning de configuration sont bloquées sans lui

Ne procéder dans une posture docs-only/read-only que lorsque le MCP est véritablement indisponible et que l'étape peut quand même produire une sortie utile non destructive.

Mécanismes concrets :

L'installation / activation des apps Wix (Blog, Members, etc.) EST automatisable. Utiliser l'App Installation API :
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ée, installer avec POST /apps-installer-service/v1/app-instance/install. Body (tous les champs requis — confirmés par des 400 en 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, la sauter et vous fier à /install.)
3. Lister l'état actuel avec GET /apps-installer-service/v1/app-instances.
- Baser appDefId sur le tableau officiel "Apps Created by Wix" (/docs/api-reference/articles/work-with-wix-apis/platform/about-apps-created-by-wix), PAS sur un exemple docs — par ex. l'exemple install-app utilise 1380b703-…, qui est Wix eCommerce, pas Blog. Installer la mauvaise app sur un site en live est un vrai risque ; vérifier que l'ID correspond à l'app que vous visez.
Wix Data / collections CMS (le cas WDE0110: Wix Code not enabled). Activer Wix Data en installant l'app Wix Data appDefId e593b0bd-b783-45b8-97c2-873d42aacaf4 via l'App Installation API (même forme de body /install que toute autre app ; elle installe aussi automatiquement une app dépendante 1a711f05-2040-47df-a9f0-4f9cddb4c3c6). Une fois installée, un simple REST POST /wix-data/v2/collections crée des collections NATIVE sans WDE0110 — pas de toggle d'éditeur de code, pas d'app personnalisée nécessaire. Vérifié en live 2026-06-10 sur un site gratuit vierge (install → 200 ; création de collection → 200 collectionType: NATIVE).
- C'est le chemin préféré. L'app data-collections-extension plus ancienne (création d'une app personnalisée qui déclare des collections, FR-005) est maintenant un fallback — nécessaire seulement si vous devez déclarer des schémas de collection au moment de l'installation, et elle ne peut toujours pas exprimer les champs REFERENCE (FR-004 ; les ajouter après installation via create-field).
- Note : l'app "Wix CMS" standalone (appDefId 675bbcef-…) est non installable (is-permitted-to-install → false) — ne pas l'utiliser ; utiliser e593b0bd-….
Collection crosswalk d'import (idempotence, FR-010). Les entités blog/CMS natives n'ont pas de source id settable par le client et Wix réécrit les slugs, donc une re-exécution ne peut pas dédupliquer sans une table secondaire. Après activation de Wix Data, provisionner une collection ImportCrosswalk native (POST /wix-data/v2/collections) avec les champs entityType (TEXT), sourceId (TEXT), targetId (TEXT), targetType (TEXT). L'importeur généré s'en alimente (queryAllDataItems) avant écriture et enregistre chaque entité créée, donc les continuations/re-exécutions sautent les enregistrements terminés au lieu de créer des doublons. Provisionner cela chaque fois que le plan écrit des entités natives qui doivent être idempotentes. Si les artefacts upstream l'appellent toujours MigrationRefs, le normaliser ici plutôt que de créer les deux collections.
Véritablement manuel (aucune API existe) : upgrader le plan de stockage, générer des credentials de système externe (par ex. un WordPress Application Password), et la facturation au niveau du compte. Ce sont les seules catégories qui peuvent être rapportées comme manuelles — et seulement après confirmation qu'aucune API ne les couvre.

Artefact à créer ou mettre à jour

migrations/<project>/setup-verification.md

Format de sortie de vérification

Pour chaque exigence, capturer :

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

Vérification optionnelle de la disponibilité des médias

Quand la migration inclut l'import de médias par URL source, vérifier si les URLs de médias découvertes sont publiquement accessibles par Wix. Si l'URL source est localhost, 127.0.0.1, ou un hôte private-only, marquer l'import de médias comme blocked ou deferred, mais ne pas bloquer les entités non-médias non liées. Ceci est une configuration optionnelle et, autant que nous le sachions aujourd'hui, n'affecte que l'import Wix Media.

Enregistrer le chemin choisi par l'utilisateur dans setup-verification.md :

Tunneler les URLs de médias : demander à l'utilisateur d'exposer la source via un tunnel HTTPS public, puis utiliser cette URL pour WP_BASE_URL / SOURCE_URL ou réécrire les URLs de médias pour ce base.
Sauter/déférer les médias : procéder seulement si le plan d'exécution dit clairement que les médias et toute référence dépendante des médias (images hero, galeries, téléchargements) seront sautés ou déféré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

Diviser 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 la gate d'acceptation du plan d'exécution et alimente le plan.
Les écritures de provisioning — installation d'apps, activation de Wix Data (via l'enabler data-collections), création de collections, ajout de champs — se produisent seulement après que l'utilisateur accepte le plan d'exécution. Aucune écriture de site avant acceptation. Une fois acceptée, le consentement "Migrate" couvre les écritures individuelles, donc ne pas re-prompt par app/collection. S'arrêter sur needs-user seulement pour les éléments véritablement manuels (upgrade du plan de stockage) ou une credential manquante/invalide.

Garde-fous

Ne jamais rapporter la configuration comme complète sans preuve.
Avant de marquer un élément bloqué ou manuel, confirmer qu'aucune API ne peut le faire (voir Provisioning ci-dessus). Réserver « manuel » aux étapes de stockage/facturation/credential externe.
Si les credentials ou permissions manquent véritablement, marquer l'élément bloqué et énoncer l'API exacte qui a été refusée et pourquoi.
Ne pas commencer l'exécution d'import depuis cette skill.