rp-setup-discovery

Déterminer la configuration côté Wix requise avant que l'import puisse s'exécuter en toute sécurité.

Purpose

Ce skill analyse les artefacts de mapping approuvés et dérive les prérequis d'environnement tels que les applications 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.

Required inputs

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
any Wix environment constraints or destination account details provided by the user

Pour managementImportMode=quick, remplacez les entrées de mapping ci-dessus par migrations/<project>/quick-mode/plan.json. Son requiredWixCapabilities et son graphe d'entités font autorité pour la configuration. Générez les mêmes artefacts de configuration et les exigences de notification permanente/Catalog-V3 ; ne demandez pas un plan de mapping et ne demandez pas à un agent d'inférer des entités quick supplémentaires. Lorsque le plan inclut des articles de blog, ajoutez un auteur de blog de secours dédié et automatisable, persistez son ID en tant que WIX_BLOG_FALLBACK_MEMBER_ID, et divulguez la politique d'attribution dans le résumé de configuration. C'est une configuration obligatoire, jamais une décision utilisateur ou un bloqueur d'import.

Générez les artefacts de configuration en mode quick de manière déterministe :

node skills/wix-replatform/resources/rp-setup-discovery/scripts/quick-setup-plan.js <projectDir>

L'adaptateur déclare son graphe d'entités et ses capacités ; ce générateur partagé définit la politique universelle de configuration de destination et ne doit pas inférer d'entités d'import supplémentaires.

Workflow

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 compacts domaine/entité via rp-target-wix/scripts/domain-knowledge.js summarize-entities et incluez wixAppsRequired, setupRequirements, classification cible, et niveau de vérification d'écriture dans l'analyse de configuration.
Déterminez quelles applications 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 configuration dépendent les unes des autres.
Rédigez un artefact de configuration que l'exécution en aval puisse vérifier.

Artifact to create or update

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 adressée à l'utilisateur et mapping/mapping-plan.json comme le contrat détaillé. S'ils sont en désaccord matériel, arrêtez et renvoyez le workflow à rp-mapper pour les corriger avant de dériver les exigences de configuration.

Minimum contents

applications Wix requises
autorité de crosswalk local et exigences optionnelles de CMS mirror
collections et schémas requis
définitions de champs requises
permissions ou prérequis d'accès
ordre de configuration
étapes manuelles vs. étapes automatisables
critères de vérification pour chaque exigence

Optional source reachability setup for media

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 configuration optionnelle pour l'accessibilité des médias. Ce n'est pas un bloqueur pour les entités non-média et ne doit pas être présenté comme un élément de configuration ou d'application Wix requis. À notre connaissance actuelle, cela affecte uniquement l'import de Wix Media car l'API d'import-from-URL de Wix récupère les fichiers à partir des serveurs Wix.

Proposez deux options dans setup/review/setup-summary.md et préservez 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édia en direct.
Ignorez/reportez l'import de média pour la première exécution en direct et continuez avec les entités non-média.

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 redirection HTTPS comme WP_BASE_URL / SOURCE_URL, ou assurez-vous que le code généré réécrit les URL de média source de l'URL base locale vers l'URL base du tunnel.

Verifying Wix APIs

Confirmez que les applications, collections, types de champs et références que vous exigez existent réellement dans Wix avec les noms/types que vous déclarez — ne les inventez jamais.

Vérifiez au moment où vous écrivez l'exigence ; ne la 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'y a pas de type SLUG — un slug Wix est un champ TEXT.)
Si une surface d'outil Wix telle que Wix MCP est disponible, utilisez-la comme aide de vérification rapide.
Si aucune surface d'outil Wix n'est disponible, fiez-vous aux contrats vérifiés de rp-target-wix plus la documentation REST/SDK Wix publiée et les noms conservateurs et reconnus comme bons, et marquez l'exigence unverified pour qu'un humain la confirme avant que rp-execute-setup s'exécute.

Standing requirement: mute site notifications

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

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, du domain knowledge ou du jugement d'agent, et non conditionnelle à WIX_MUTE_NOTIFICATIONS (pour les nouveaux sites la sourdine est inconditionnelle).
WIX_SITE_STRATEGY=existing — uniquement quand le propriétaire a explicitement opté pour WIX_MUTE_NOTIFICATIONS=on. Sous la valeur par défaut existing-site (off), n'émettez aucune exigence.

Contenu de l'exigence : sévérité blocker, mode automation automatable, ordonnée en premier parmi les écritures de configuration (avant les installations d'app, la création de collections, et toute autre approvisionnement), exécutée via la primitive muteSiteNotifications dans rp-target-wix/lib/wix-writers.js (VERIFIED 2026-08-04) avec un reason 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 site token généré par CLI (WIX_AUTH_TOKEN) — une clé API de compte reçoit 403.

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

Crosswalk authority and CMS mirror

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

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

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

Classifying manual vs. automatable

Ne déclarez pas "manual" / "cannot self-provision" par supposition — vérifiez la surface de l'API.

L'activation d'une application Wix (Blog, Members, etc.) est automatisable via l'App Installation API ; classifiez-la automatisable et citez la méthode. (Piège courant : ne marquez pas Blog ou Members "cannot self-provision" — les deux sont installables via l'API.)
Catalog V3 est garanti au provisioning quel que soit le template scaffold (0079-catalog-v3-guaranteed-retire-v1-gate.md), donc une installation Wix Stores sur un site créé cette exécution n'a besoin d'aucune exigence de version de catalogue séparée — n'en émettez pas. Cette garantie ne s'étend pas à un site existant que cette exécution n'a pas créé : quand WIX_SITE_STRATEGY=existing et la migration porte un catalogue de produits, émettez toujours l'exigence stores-catalog-v3 aux côtés de l'installation de l'app Wix Stores — état attendu catalogVersion: V3_CATALOG, vérifiée lecture seule via GET https://www.wixapis.com/stores/v3/provision/version, sévérité blocker, mode automation automatable. Un catalogue d'un site préexistant prédoit cette garantie, donc il doit être confirmé plutôt que supposé (voir rp-execute-setup → "A V1_CATALOG verdict is terminal here").
La création de collections CMS est automatisable ; l'activation de Wix Data elle-même est automatisable 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ée en direct 2026-06-10 ; voir rp-execute-setup).
Seules les mises à niveau de plan de stockage, les credentials de système externe et la facturation de compte sont véritablement manuelles. Marquez quelque chose de manuel uniquement après avoir confirmé qu'aucune API ne l'explique.

Runtime policy

Cette phase est un travail de planification déterministe. Elle ne crée pas une deuxième porte d'approbation. setup/review/setup-summary.md est un contexte de planification d'exécution de 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 de l'API (voir ci-dessus), pas par supposition. Si une 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 fassent remonter avant l'exécution.

Guardrails

Séparez la configuration requise des optimisations optionnelles.
Évitez d'intégrer la logique d'import ici ; ce fichier concerne les prérequis.
Soyez explicite sur le fait que les exigences proviennent de quelle décision de mapping.
Ne devinez pas les noms de configuration ou les valeurs d'énumération quand vous ne pouvez pas les vérifier. Marquez-les unverified et mettez en avant le risque avant l'exécution.