rp-destination
À utiliser uniquement lorsqu'aucune destination fiable n'est disponible ou que le contrat de destination est en conflit.
L'ordre de priorité est : destination fournie par l'hôte, puis site id non vide dans config/wix.env, puis un nouveau site Wix Managed Headless. Un conflit est un arrêt dur ; ne jamais réorienter sur une hypothèse.
Pour la création, confirmez que la Wix CLI est connectée au compte prévu, effectuez un scaffolding une seule fois dans le projet de migration actif, et conservez l'id metasite. Toujours effectuer le scaffolding avec --site-template blank, quel que soit le mode de livraison ou que la migration contienne un catalogue — Catalog V3 est garanti à la mise en service indépendamment du template (voir 0079-catalog-v3-guaranteed-retire-v1-gate.md), donc il n'y a plus de raison de partir d'un template non vierge. Laissez wix-headless-replatform fournir le contenu de page réel ; ne pas ignorer ce module juste parce qu'il n'y a pas de travail backend. Ne créez pas de sites de sonde, test, remplacement ou secondaires sans l'autorité de récupération explicite dans le contrat de destination existant.
Le scaffolding (wix-headless-scaffold.js) publie le site dans le cadre de la création — c'est le défaut propre de la Wix CLI ; ne jamais rajouter --no-publish. La délivrable entière d'une migration management-only est ce site publié exécutant son template non modifié : « aucun site web client n'est construit » signifie laissé non personnalisé, pas laissé non publié.
Après résolution, signalez l'URL du dashboard déterministe et retournez au routeur. Les identifiants source ne sont jamais demandés jusqu'à ce que cette destination existe.