rp-quick-shopify
À utiliser uniquement quand le routeur a sélectionné cette ressource pour managementImportMode=quick et que la sonde source a identifié shopify avec une confiance élevée. Cet adapter importe uniquement le graphe d'entités catalog déclaré dans quick-mode.json : produits publics, collections, tags produits, médias produits, variantes et appartenance aux collections. Il les lit via l'API GraphQL Storefront sans token du magasin (POST /api/<storefrontApiVersion>/graphql.json, aucun token d'accès) à la version d'API épinglée dans quick-mode.json. Une seule requête produit paginée porte les variantes, images et appartenances aux collections de chaque produit, de sorte qu'un magasin avec des milliers de collections ne nécessite que quelques requêtes. Il n'utilise jamais les identifiants, un token d'accès Storefront ou Admin, l'extraction navigateur, le scraping de page, les endpoints applicatifs ou une étape de mappage LLM.
Exécutez l'adapter à partir de la racine du repository :
node skills/wix-replatform/resources/rp-quick-shopify/scripts/quick-mode.js preflight <projectDir>
node skills/wix-replatform/resources/rp-quick-shopify/scripts/quick-mode.js plan <projectDir>
node skills/wix-replatform/resources/rp-quick-shopify/scripts/quick-mode.js extract <projectDir>
node skills/wix-replatform/resources/rp-quick-shopify/scripts/quick-mode.js import <projectDir> [--dry-run]
node skills/wix-replatform/resources/rp-quick-shopify/scripts/quick-mode.js request-reverify <projectDir>
node skills/wix-replatform/resources/rp-quick-shopify/scripts/quick-mode.js reverify <projectDir>plan écrit aussi discovery/source-coverage.json : une ligne adapter-excluded par entrée excluded[], chacune disposée selon l'exclusion déclarée par l'adapter et portant la traduction excludedCapabilities validée depuis quick-mode.json (une capacité cible, ou source-scope.<name> quand Wix n'en a pas). Le plan refuse si cette traduction manque, est supplémentaire, dupliquée ou en dehors des deux namespaces, et appose sourceCoverageContract: 1 dans quick-mode/plan.json. import refuse d'écrire son résumé d'achèvement quand le plan manque ou n'est pas apposé, ou son fichier de couverture manque ou ne se réconcilie pas (une exclusion déclarée doit nommer une entrée excluded[] du contrat validé, avec sa capacité validée) ; relancez plan pour corriger l'un de ces éléments. Le résumé porte sourceCoverage[] et sourceCoverageStatus.
preflight pagine à travers les connexions produits et collections (complétant tout produit dont les variantes, images ou collections dépassent la première page imbriquée) et stocke la capture que extract réutilise, avant que plan n'écrive le plan rapide et le manifeste d'exécution faisant autorité. HTTP 429, 5xx, THROTTLED, les connexions perdues et les appels bloqués sont réessayés : un premier appel plus six retries au maximum par requête, chaque appel limité en temps, et chaque attente (y compris un Retry-After demandé par le serveur, en secondes ou en date HTTP) plafonnée à 30 secondes. Toute autre erreur est une réponse réelle et bloque immédiatement. Quand les retries s'épuisent, quick-mode/preflight.json enregistre une vérification bloquée avec la connexion, la page, le statut, les codes d'erreur et les attempts. La découverte setup normale et l'approbation d'exécution restent obligatoires avant l'import. Un endpoint inaccessible (p. ex. protégé par mot de passe), malformé ou modifié est un bloqueur durable : ne remplacez pas par un navigateur, des identifiants ou un endpoint différent ; créez un choix durable entre arrêter et le mode standard à la place. Le choix du mode standard doit porter cet effet pour que le CLI applique la sélection de l'utilisateur avant de reprendre :
{"kind":"decision","key":"managementImportMode","choices":{"switch_to_standard":"standard"}}Les enregistrements sont normalisés à la forme de ligne storefront-JSON que l'import consomme (ids legacy numériques, body_html, variants[].option1..3, variants[].available, images[].src), de sorte que les crosswalks indexés par id Shopify restent valides entre les versions d'adapter. Une exécution sèche écrit uniquement execution/dry-run-completion-report.json, execution/dry-run-final-report.md, execution/dry-run-inventory-report.json et execution/dry-run-category-capacity.json ; elle ne crée jamais ou ne change jamais un artefact live (les rapports live completion, final et inventory, le crosswalk, le journal de récupération limite, le fichier de capacité, le marqueur import-started ou un fichier de revérification), de sorte que le routeur envoie toujours le projet au live import ensuite.
L'extraction persiste les enregistrements bruts et les arêtes d'appartenance. Seules les collections contenant au moins un produit extrait deviennent des catégories (manifest.entities.collection.excludedEmptyCount compte les autres) : Wix Stores permet au maximum 1 000 catégories par site, y compris la catégorie intégrée All Products. L'import vérifie cette limite par rapport aux catégories actuelles de la destination avant sa première écriture et refuse, en nommant les deux comptages, plutôt que de créer des catégories jusqu'à la limite et de laisser les appartenances restantes en suspens. La vérification compte uniquement les catégories encore à créer (celles déjà crosswalkées ou déjà sur la destination par slug sont réutilisées) plus la catégorie intégrée All Products, et enregistre quick-mode/category-capacity.json. Quand c'est blocked, rien n'a été écrit et le routeur retourne quick_mode_category_capacity_blocked : créez un choix durable entre free_destination_categories_and_retry (l'opérateur libère les catégories sur la destination, puis l'import est relancé et réécrit le fichier sous passed) et stop. Une exécution sèche ne peut pas voir la destination, elle applique donc la même règle avec la catégorie intégrée comme plancher et signale le vrai jeu d'espace comme inconnu. Les collections omises pour n'avoir aucun produit importé sont listées par nom dans le rapport d'achèvement (excludedCollections) et le rapport final, de sorte que l'opérateur peut recréer celles que le commerçant a toujours besoin. L'import utilise le runtime Stores V3 partagé, les crosswalks durables et les points de contrôle. L'écrivain partagé valide le produit option et la charge utile variante ; un enregistrement qui ne peut pas être représenté de manière sûre est ignoré et signalé plutôt que réduit à une forme de produit différente.
Le mode rapide mappe le booléen available explicite de chaque variante Shopify publique à un inStock non suivi ; une valeur manquante ou non booléenne est un écart signalé, jamais une disponibilité implicite. Les produits créés avec l'endpoint autonome sont suivis par la réconciliation d'inventaire partagée. Faites correspondre les variantes retournées par leurs identités d'option/choix, pas l'ordre de réponse ou le SKU. À la reprise, conservez le crosswalk produit et réconciliez le stock pour les produits existants aussi.
Un produit qui existe sur la destination avec des variantes corrélées de manière unique mais échoue une relecture de champ (par exemple un fragment de description que Wix a supprimé) est toujours signalé comme ignoré et listé dans la liste writtenUnverified.product du résumé (sourceId, targetId, name, failedFields), mais son stock est réconcilié et ses appartenances aux catégories sont écrites : les deux dépendent uniquement de l'identité du produit et de la variante, et un article à vendre ne doit pas rester avec le mauvais stock à cause d'un champ sans rapport. L'exécution reste partial et le rapport final liste chaque produit de ce type sous « Products to check ». Un produit dont les variantes ne correspondent pas en one-to-one n'obtient aucun stock et aucun lien de catégorie, et est signalé comme un écart.
Après que l'opérateur ait corrigé ou accepté ces différences, request-reverify enregistre une requête (quick-mode/reverify-request.json ; refusée quand le rapport d'achèvement live n'en liste aucune) et le routeur retourne quick_mode_reverification_required pour un import partiel terminé. reverify (refuse --dry-run) relit chaque produit listé une seule fois avec la comparaison de relecture de l'import et ne lit jamais que depuis Wix. Il prépare d'abord son résultat complet dans quick-mode/reverification-staged.json, puis le publie par replay — rapport d'achèvement, rapport final, puis le reçu quick-mode/reverification.json — de sorte qu'un crash à n'importe quel étape est terminé par l'étape de routage suivante sans relire Wix. Une fois que le reçu correspond à la requête, la même requête ne route jamais plus ; un correctif ultérieur a besoin d'une nouvelle requête.
La relecture post-création recommence brièvement un 404 transitoire (le produit peut être illisible un moment après sa création) ; une création échouée n'est jamais reessayée en ligne, car la reprise la réutilise par slug.
state/inventory-report.json rend compte de toutes les variantes extraites (y compris les écarts) et exige une relecture d'Inventory et de Catalog en localisation par défaut avant l'achèvement. Un échec d'inventaire laisse le rapport d'achèvement rapide partiel même quand tous les ID produit existent. Un recensement d'inventaire vide est no-data avec complete:false ; un décompte d'extraction différent de son manifeste bloque avant les écritures. Les exécutions sèches écrivent un rapport d'inventaire simulé séparé et ne peuvent pas compléter ou écraser un point de contrôle d'inventaire live.
Setup scope : le routeur setup rapide vérifie la réception setup normale (y compris la protection des notifications requises et l'approvisionnement de Stores). Son plan setup déterministe n'exécute pas de canari d'écriture d'inventaire. Ne signalez pas les octrois d'écriture de création/mise à jour d'inventaire comme prévérifiés à partir de cette réception ; une écriture d'inventaire refusée reste partielle dans le rapport de stock persisté.