rp-setup-discovery

Détermine la configuration requise du côté Wix avant que l'import puisse s'exécuter de manière sûre.

Objectif

Cette skill analyse les artefacts de mapping approuvés et dérive les prérequis environnementaux tels que les apps installées, les collections SMC, les schémas de champs étendus, les références, les permissions et toute autre dépendance de configuration du système cible.

Entrées requises

migrations/<project>/mapping/mapping-plan.json
migrations/<project>/mapping/review/mapping-gaps.json
migrations/<project>/mapping/review/mapping-summary.md
migrations/<project>/orchestration/approvals.json
tout contrainte environnementale Wix ou détail de compte de destination fourni par l'utilisateur

Flux de travail

Confirmez que le point de contrôle d'examen du mapping a été accepté, puis lisez le plan de mapping et le résumé du mapping et identifiez chaque exigence non native.
Pour les entités mappées avec targetRef, chargez les résumés de domaine/entité compacts via rp-target-wix/scripts/domain-knowledge.js summarize-entities et incluez wixAppsRequired, setupRequirements, classification cible et niveau de vérification de l'écriture dans l'analyse de setup.
Déterminez quelles apps Wix doivent être installées ou activées.
Déterminez quelles collections SMC doivent exister.
Déterminez quels schémas de champs étendus, références, énumérations ou règles de validation doivent exister.
Capturez l'ordre des dépendances où les étapes de setup dépendent les unes des autres.
Rédigez un artefact de setup que l'exécution en aval peut vérifier.

Artefact à créer ou mettre à jour

migrations/<project>/setup/run.json
migrations/<project>/setup/setup-plan.json
migrations/<project>/setup/setup-requirements.json
migrations/<project>/setup/setup-blockers.json
migrations/<project>/setup/llm-handoff.json
migrations/<project>/setup/review/setup-summary.md
migrations/<project>/orchestration/checkpoints.json

Traitez mapping/review/mapping-summary.md comme la déclaration d'intention destinée à l'utilisateur et mapping/mapping-plan.json comme le contrat détaillé. S'ils divergent matériellement, arrêtez et renvoyez le flux de travail à rp-mapper pour les corriger avant de dériver les exigences de setup.

Contenu minimum

apps Wix requises
autorité de crosswalk local et exigences optionnelles de miroir CMS
collections et schémas requis
définitions de champs requises
prérequis de permissions ou d'accès
ordre de setup
étapes manuelles vs. étapes pouvant être automatisées
critères de vérification pour chaque exigence

Setup optionnel de reachabilité source pour les médias

Si le mapping importe des médias par URL et le profil source affiche localhost, 127.0.0.1 ou une autre URL source privée uniquement, ajoutez une note de setup optionnelle pour la reachabilité des médias. Ceci n'est pas un blocker pour les entités non-médias et ne doit pas être présenté comme un élément de setup/app Wix requis. Autant que nous le sachions aujourd'hui, cela n'affecte que Wix Media import car l'API d'import par URL de Wix récupère les fichiers depuis les serveurs Wix.

Proposez deux options dans setup/review/setup-summary.md et conservez l'effet lisible par machine dans setup/setup-blockers.json ou setup/setup-requirements.json :

Exposez la source locale via un tunnel HTTPS public avant l'import de médias en direct.
Ignorez/reportez l'import de médias pour la première exécution en direct et continuez les entités non-médias.

Pour ngrok, incluez :

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

Dites à l'utilisateur d'utiliser l'URL de forwarding HTTPS comme WP_BASE_URL / SOURCE_URL, ou assurez-vous que le code généré réécrit les URLs de médias source depuis l'URL de base locale vers l'URL de base du tunnel.

Vérification des APIs Wix

Confirmez que les apps, collections, types de champs et références que vous demandez existent réellement dans Wix avec les noms/types que vous énoncez — ne les inventez jamais.

Vérifiez au moment où vous rédigez l'exigence ; ne reportez pas. Vérifiez les valeurs d'énumération, pas seulement les noms : confirmez chaque Field.type par rapport au schéma Create Data Collection. (Piège courant : il n'existe pas de type SLUG — un slug Wix est un champ TEXT.)
Si une surface Wix comme Wix MCP est disponible, utilisez-la comme aide de vérification rapide.
Si aucune surface Wix n'est disponible, fiez-vous aux contrats vérifiés de rp-target-wix plus la documentation Wix REST/SDK publiée et les noms conservateurs connus pour être corrects, et marquez l'exigence unverified pour qu'un humain la confirme avant que rp-execute-setup s'exécute.

Exigence permanente : mute les notifications du site (spec 0012)

Émettez une exigence mute-site-notifications dans setup/setup-plan.json et setup/setup-requirements.json chaque fois que mute est en vigueur :

WIX_SITE_STRATEGY=new — toujours, comme règle permanente basée sur la valeur de stratégie seule. Non dérivée des décisions de mapping, de la connaissance du domaine ou du jugement de l'agent, et non conditionnelle à WIX_MUTE_NOTIFICATIONS (pour les nouveaux sites le mute est inconditionnel).
WIX_SITE_STRATEGY=existing — uniquement quand le propriétaire a explicitement opté avec WIX_MUTE_NOTIFICATIONS=on. Avec la valeur par défaut des sites existants (off), n'émettez aucune exigence.

Contenu d'exigence : sévérité blocker, mode automation automatable, ordonné en premier parmi les écritures de setup (avant les installs d'apps, création de collections et tout autre provisioning), exécuté via la primitive muteSiteNotifications dans rp-target-wix/lib/wix-writers.js (VERIFIED 2026-08-04) avec une raison identifiant le projet (RePlatform migration — <project>). Critère de vérification : getSiteMuteState retourne muted: true. Note d'auth pour l'exigence : l'appel doit utiliser le jeton de site émis par CLI (WIX_AUTH_TOKEN) — une clé API de compte reçoit un 403.

Validation de config (fail fast) : WIX_MUTE_NOTIFICATIONS=off accompagné de WIX_SITE_STRATEGY=new est une erreur de validation — arrêtez avec le conflit de config enregistré plutôt que d'émettre des artefacts. (rp-import-codegen revalide la même règle.)

Autorité de crosswalk et miroir CMS

Les fichiers locaux sous migrations/<project>/state/crosswalk/ sont l'autorité durable sourceId -> targetId pour les entités Wix natives. Ne faites pas de setup CMS une exigence minimum pour l'idempotence d'entité native.

Créez/provisionnez ImportCrosswalk CMS uniquement quand le plan de mapping approuvé demande explicitement un miroir CMS (cmsMirror: "download" | "upload" | "download-and-upload"). Le miroir est des données de référence site-local compactes et une source de seed pré-exécution pour les flux de sites existants quand un état de crosswalk local valide n'existe pas déjà. Ajoutez un avertissement de quota CMS chaque fois qu'un miroir est demandé.

Si les anciens artefacts appellent le miroir optionnel MigrationRefs, normalisez-le à ImportCrosswalk et appelez le renommage dans l'artefact pour que le setup/codegen en aval partagent un contrat.

Classification manual vs. automatable

N'affirmez pas "manual" / "cannot self-provision" par hypothèse — vérifiez la surface API.

L'activation d'une app Wix (Blog, Members, etc.) est automatable via l'App Installation API ; classifiez-la automatable et citez la méthode. (Piège courant : ne marquez pas Blog ou Members « cannot self-provision » — les deux sont installables via l'API.)
Quand la migration porte un catalogue de produits, émettez une exigence stores-catalog-v3 aux côtés de l'install de l'app Wix Stores : état attendu catalogVersion: V3_CATALOG, vérifié en lecture seule via GET https://www.wixapis.com/stores/v3/provision/version, sévérité blocker, mode automation automatable (il est provisionné en scaffoldant le site depuis le template commerce — voir replatform → "Headless site creation"). Une install Stores seule n'implique pas V3 ; un site scaffoldé blank arrive V1_CATALOG et ne peut pas être converti, donc ceci doit être une exigence de première classe plutôt qu'une hypothèse.
Créer des collections CMS est automatable ; activer Wix Data elle-même est automatable en installant l'app Wix Data appDefId e593b0bd-b783-45b8-97c2-873d42aacaf4 via l'App Installation API, après quoi POST /wix-data/v2/collections crée des collections NATIVE sans WIX0110 (vérifié en direct 2026-06-10 ; voir rp-execute-setup).
Seules les mises à jour de plan de stockage, les credentials de système externe et la facturation de compte sont réellement manuelles. Marquez quelque chose de manuel seulement après avoir confirmé qu'aucune API ne le couvre.

Politique d'exécution

Cette phase est un travail de planification déterministe. Elle ne crée pas un deuxième portail d'approbation. setup/review/setup-summary.md est du contexte de planification d'exécution support, pas un point de contrôle d'approbation utilisateur séparé.

Vérifiez les noms et énumérations plutôt que d'émettre unverified par défaut. Classifiez l'automatabilité en vérifiant la surface API (voir ci-dessus), pas par hypothèse. Si un aide de vérification directe n'est pas disponible, utilisez le fallback documenté et marquez l'exigence unverified pour que les étapes en aval la surfacent avant l'exécution.

Garde-fous

Séparez le setup requis des optimisations optionnelles.
Évitez d'embarquer la logique d'import ici ; ce fichier concerne les prérequis.
Soyez explicite sur les exigences provenant de quelle décision de mapping.
Ne deviquez pas les noms ou valeurs d'énumération de setup quand vous ne pouvez pas les vérifier. Marquez-les unverified et surfacez le risque avant l'exécution.