rp-project-intake
À utiliser quand le routeur signale un projet non résolu, un mode de livraison, une stratégie de destination ou un mode source.
Résoudre la précédence du projet : projet utilisateur explicite, contexte de projet actuel, l'unique projet sous la racine des migrations, sinon demander à l'utilisateur de choisir. Ne jamais déduire d'un projet frère.
L'initialisation du projet crée également EXPECTATIONS.md à la racine du projet s'il manque. Mentionnez-le comme un lieu optionnel pour enregistrer les attentes ; ne le posez pas comme une question d'intake ni ne remplacez un fichier existant de l'utilisateur.
Résoudre le mode de livraison avant la création de la destination : par défaut management ; choisir website pour le frontend uniquement ; choisir management_and_website quand l'utilisateur souhaite à la fois une migration backend et une vitrine orientée client. Accepter both comme alias d'entrée pour management_and_website, puis enregistrer la valeur canonique dans orchestration/decisions.json.
Pour un nouveau site de destination, le type de site est un choix explicite de l'opérateur sans défaut : Headless (un site web développé en code), Wix Studio, ou Wix Harmony. Il détermine où vivent les données importées et ne peut pas être changé ultérieurement en tant que paramètre. Une réponse générique « Editor » est incomplète tant que Studio ou Harmony n'est pas nommé ; l'éditeur Wix classique n'est pas proposé. Poser cette question ensemble avec le type métier de Harmony en une seule question combinée — magasin, réservations/services, autre secteur, ou « pas sûr, commencer vide » — jamais en deux questions. Enregistrer avec orchestration-state.js decide --key targetSiteType --value <type> [--business-type store|bookings|other] ; une réponse Harmony qui ne nomme aucun type métier enregistre unknown. Un choix que l'opérateur a déjà fourni compte ; ne pas demander à nouveau. rp-destination déclenche la demande durable quand elle manque toujours. L'adoption de site existant n'a besoin d'aucun type.
Pour les modes de livraison qui incluent la gestion, enregistrer aussi managementImportMode. Par défaut standard ; accepter un choix explicite de l'utilisateur quick à l'intake même avant que l'URL source soit sondée. Le résultat du sondage source-inputs ultérieur valide si un adaptateur quick correspondant existe ; ne jamais promettre le support quick uniquement d'après le choix de l'utilisateur.
Enregistrer faceliftMode=requested seulement quand l'utilisateur demande explicitement un relooking UI/UX post-clonage. C'est optionnel, par défaut désactivé, et ce n'est pas un substitut à la fidélité normale du clonage. En mode 1-clic demandé explicitement par l'utilisateur, inclure ce choix dans l'intake groupé initial pour que l'étape de relooking ultérieure et distincte soit autorisée sans une autre approbation de routine.
En mode normal, poser uniquement la décision manquante actuelle. En mode 1-clic demandé explicitement par l'utilisateur, enregistrer automationMode=one_click avec source=user, collecter chaque valeur d'intake encore manquante, enregistrer les réponses et continuer. Ne jamais déduire le 1-clic d'un fichier uploadé ou d'une surface d'exécution. Déléguer toutes les procédures de destination, fichier source et identification aux modules dédiés.
Output
Le projet résolu, plus les entrées orchestration/decisions.json pour chacune des valeurs deliveryMode, managementImportMode, targetSiteType (avec targetSiteBusinessType pour Harmony), faceliftMode, et automationMode que cette exécution a résolue. C'est ce qu'une exécution dispatched doit produire.