rp-discovery

Découvrir et documenter le schéma de la plateforme source pour le projet de migration actif.

Objectif

Utilisez cette skill pour inspecter le système source, identifier les entités, les relations, les champs, les identifiants, les médias, le contenu riche et les contraintes spécifiques à la plateforme. Les exemples incluent Shopify, WordPress, WooCommerce et les plateformes CMS personnalisées.

Cette skill est responsable du processus de découverte indépendant de la plateforme et de son contrat de sortie (source-profile.md + source-schema.json). Les détails spécifiques à la plateforme — comment capturer une source donnée, son modèle d'authentification, les particularités REST — résident dans une skill source adapter dédiée, pas ici. Pour WordPress / WooCommerce, cet adaptateur est rp-source-wordpress. Pour supporter une nouvelle plateforme, ajoutez un adaptateur similaire (par exemple rp-source-shopify) et laissez cette skill inchangée.

Entrées

Les entrées attendues peuvent inclure :

nom de la plateforme source
docs API source ou exports
credentials, tokens, ou fichiers de dump locaux si disponibles
projet actif sous migrations/<project>/
config locale du projet sous migrations/<project>/config/

Vérification de la config avant la capture

Avant de lancer la capture source, vérifiez les fichiers de config locaux créés par rp-orchestration :

config/wix.env doit toujours exister avec les clés WIX_SITE_ID et WIX_AUTH_TOKEN, même si la découverte elle-même n'utilise pas encore les credentials Wix.
config/source.<platform>.env doit exister une fois la plateforme source connue. Pour WordPress, c'est config/source.wordpress.env.

Si une clé requise est manquante ou vide, demandez à l'utilisateur cette valeur et remplissez le fichier config pour lui avant de continuer. Demandez une valeur à la fois. Ne répétez jamais les valeurs secrètes à l'utilisateur ; rapportez uniquement le statut présent/manquant.

Traitez migrations/<project>/config/*.env comme porteurs de secrets une fois qu'ils peuvent contenir des valeurs réelles. Ne les inspectez pas avec des lectures de fichier entier qui répercutent le contenu dans la sortie de l'outil. Utilisez uniquement des vérifications sûres : existence, noms de clés requis, et statut présent / vide / manquant.

Flux de travail

Confirmez le projet actif sous migrations/<project>/.
Identifiez la plateforme source et la méthode d'acquisition, puis sélectionnez la skill source adapter correspondante (par exemple rp-source-wordpress pour WordPress / WooCommerce). Si aucun adaptateur n'existe pour la plateforme, capturez les entités manuellement en suivant le même contrat de sortie.
Exécutez l'étape de capture de l'adaptateur pour produire un dump brut capturé par machine sous <migrations-root>/<project>/data/<source>-discovery/. Pour WordPress, le script de capture réside dans rp-source-wordpress/scripts/ — exécutez-le depuis le répertoire de cette skill (voir la section Capture de rp-source-wordpress et CONVENTIONS.md). L'adaptateur est propriétaire de la mécanique de capture, du modèle d'authentification et des particularités de la plateforme ; cette skill consomme sa sortie.
- Distinguez les entités supportées (annoncées par la source) des entités utilisées (celles avec recordCount > 0). Les entités annoncées mais vides doivent être signalées, pas mappées comme si elles contenaient des données.
- Une capture effectuée sans credentials est généralement incomplète (entités verrouillées, champs privés, les PII retournent 401/403). Ne traitez pas une capture non authentifiée comme faisant autorité — l'adaptateur documente l'authentification requise pour une exécution complète.
Capturez les détails de schéma au niveau des champs, incluant le type, la cardinalité, l'obligatoriété et les valeurs d'exemple.
Notez les contraintes opérationnelles comme la pagination, les rate limits, le modèle d'authentification et les options de synchronisation incrémentale. Si l'URL de base de la source ou les URL de médias/fichiers découverts utilisent localhost, 127.0.0.1 ou un autre hôte privé uniquement, enregistrez une note de réachabilité des médias dans source-profile.md. Localhost convient pour la découverte et les lectures source locales, mais l'import de médias Wix est basé sur les URL et les serveurs Wix ne peuvent pas récupérer le localhost de l'utilisateur. C'est une étape de préparation optionnelle et, à notre connaissance actuelle, affecte uniquement l'import de médias. Énoncez les deux choix acceptables :
- exposez la source avec un tunnel HTTPS public comme ngrok avant l'import de médias en direct
- ignorez/différez l'import de médias tout en continuant les entités non-médias
Incluez des instructions concises de configuration ngrok si pertinent :
```
brew install ngrok
ngrok config add-authtoken "<YOUR_AUTHTOKEN>"
ngrok http 8090
export WP_BASE_URL=https://<id>.ngrok-free.app
```
Synthétisez la capture brute dans les artefacts normalisés ci-dessous.

Artefacts à créer ou mettre à jour

migrations/<project>/data/<source>-discovery/ : sortie brute capturée par machine depuis l'adaptateur source. Traitée comme une preuve, pas un artefact à transmettre — les skills en aval la référencent pour la traçabilité mais ne la lisent pas en totalité.
migrations/<project>/source-profile.md : plateforme source, méthode d'accès, limites, authentification et notes opérationnelles. Synthétisée à partir de la capture brute. Capturez les faits opérationnels que l'adaptateur documente (modèle d'authentification, pagination, rate limits) afin que rp-import-codegen les ait sans les re-dériver.
migrations/<project>/source-schema.json : schéma lisible par machine pour les entités et champs. Synthétisé à partir de la capture brute — ceci et source-profile.md sont la transmission canonique à rp-mapper. Incluez des pointeurs de traçabilité afin que le mapper puisse explorer le fichier brut d'une entité spécifique si nécessaire :
- rawDiscovery au niveau supérieur : chemin relatif au répertoire de capture brute, par exemple data/wp-discovery/.
- rawFile par entité : nom de fichier dans ce répertoire, par exemple wp-v2--posts.md.
- recordCount et inUse par entité afin que les consommateurs puissent distinguer les entités supportées vs. réellement utilisées.
- relations par entité dérivées des relations déclarées par la source dans la capture brute, afin que les relations soient soutenues par la preuve plutôt que devinées. Chaque relation doit porter un pointeur evidence vers le signal source dont elle provient.
- Suivez le source-schema.example.json de l'adaptateur pour la structure (par exemple rp-source-wordpress/source-schema.example.json). C'est un modèle à suivre, pas un schéma strict à valider — gardez le cœur indépendant de la plateforme stable et poussez les particularités de plateforme dans le blob sourceMeta ouvert de chaque entité.
Notes de support optionnelles sous migrations/<project>/research/ si nécessaire.

Règles de qualité de sortie

Séparez les faits confirmés des hypothèses.
Enregistrez le volume par entité (comptages d'enregistrements) afin que les skills en aval sachent ce que le site utilise réellement, pas seulement ce qu'il supporte.
Préservez exactement les identifiants spécifiques à la source.
Incluez suffisamment de détails pour le mapping en aval et la génération de code.
Signalez explicitement les inconnues au lieu d'inventer une structure.