# Prompt — Phase données uniquement (avant la construction du code Laravel) À coller dans Claude Code CLI depuis `C:\Sites\lesiteduliberal`. `dev-instructions/AUDIT_ARCHITECTURE.md` et `dev-instructions/STRUCTURE_DOSSIER_CLIENT.md` doivent être présents. --- ## CONTEXTE Cette mission précède la construction du code Laravel (routes, contrôleurs, vues, admin) — elle ne touche à aucun de ces éléments. Son seul objectif : produire le schéma de référence, convertir les deux clients pilotes vers ce schéma, et créer la structure de dossiers correspondante. Le prompt de construction du code viendra dans une mission séparée, une fois ces données validées par le développeur. `AUDIT_ARCHITECTURE.md` documente l'existant dans `ancien-code/` : lis-le intégralement. `STRUCTURE_DOSSIER_CLIENT.md` documente l'arborescence cible pour chaque client : lis-le aussi, il fait autorité sur l'organisation physique des fichiers. Les deux sont dans `dev-instructions/`. ## CE QUE TU NE DOIS PAS FAIRE DANS CETTE MISSION - Ne crée aucune route, aucun contrôleur, aucune vue Blade. - Ne construis aucune commande Artisan. - Ne touche à rien dans `app/`, `routes/`, `resources/views/`. - Cette mission produit uniquement : du JSON, des dossiers, des fichiers images copiés/renommés, et de la documentation markdown. ## RÈGLES DE SCHÉMA — À APPLIQUER 1. **Toutes les listes sont de vrais tableaux JSON** (prestations, avis, FAQ, spécialités) — jamais de clés numérotées à plat (`prest_01_nom`). Longueur variable, aucun nombre de slots figé. 2. **Un seul type d'objet "prestation", réutilisé à deux endroits** : directement dans le tableau `prestations` du client (page dédiée, visible dans la navigation), ou dans un tableau optionnel `pages_liees` À L'INTÉRIEUR d'une prestation (même structure exacte, mais absente du menu, avec un lien retour automatique vers sa prestation parente). Un seul type d'objet partout. 3. **Portfolio : pas de tableau JSON listant les photos.** Le portfolio d'une prestation est déterminé par la présence d'un dossier `public/tenants/{slug}/portfolio/{slug-prestation}/` (voir `STRUCTURE_DOSSIER_CLIENT.md`). Le JSON ne contient qu'un champ optionnel `legendes_portfolio` (titre/description par photo, indexé par chemin relatif) — jamais la liste des photos elle-même, jamais de catégorie déclarée séparément (la catégorie est le nom du sous-dossier physique). 4. **CTA unifié** : une seule structure `cta: { lien, label, icone }`, `label`/`icone` avec valeurs par défaut (`"Prendre RDV"` / `"bi-calendar-date"`) si absentes. 5. **Liens partenaires et citations par prestation : conservés, optionnels.** Absents si non utilisés — jamais de valeur vide `""`. 6. **Convention de valeur vide : absence de clé, ou `null`.** Jamais `""`, jamais de texte placeholder, jamais de booléen dédié type `prest_01_active`. 7. **`ent_adeli`/`ent_rpps`** : champs optionnels liés à la verticale métier (professions de santé réglementées), pas des champs globaux présents partout. 8. **`metier`** : champ structuré obligatoire `{ "slug": "...", "libelle": "..." }`, combiné à `ville`. Prépare une future page annuaire, ne construis rien d'autre autour. 9. **Nom du client unifié** : `prenom` + `nom` séparés partout. 10. **Téléphone et adresse unifiés** : une seule représentation par donnée. 11. **`google_site_verification`** : champ optionnel, hash de vérification Google Search Console si le client en a un, `null` sinon. 12. **`domaines`** : tableau de noms de domaine du client, déclaré dans son propre JSON (pas de fichier de mapping séparé). 13. **`publie`** : booléen, `false` par défaut. 14. **Sérialisation JSON déterministe** : `JSON_PRETTY_PRINT`, clés triées alphabétiquement, à chaque écriture. ## MISSION — EXÉCUTION EN ÉTAPES, AVEC PAUSES DE VALIDATION ### Étape 1 — Schéma de référence (ARRÊT OBLIGATOIRE après cette étape) Produis trois fichiers dans `storage/app/tenants/` : - `exemple-template.json` : un exemple **complet**, toutes les sections optionnelles remplies (prestation avec page liée, prestation avec portfolio et légendes, avis, FAQ, spécialités, liens partenaires, citation). - `exemple-template-minimal.json` : un exemple **incomplet**, avec uniquement les champs strictement obligatoires — sert à documenter ce qu'un client "au plus simple" doit contenir. - `dev-instructions/SCHEMA_JSON.md` : chaque clé des deux exemples, son type, sa signification, et si elle est optionnelle. (Nommé ainsi pour ne pas être confondu avec le balisage schema.org généré par le template — deux choses différentes.) **Affiche les deux JSON et attends une validation humaine explicite avant de continuer.** Ne touche à rien d'autre avant cette validation. ### Étape 2 — Les deux fichiers JSON clients pilotes (ARRÊT — attendre confirmation) Une fois le schéma validé, convertis les deux clients pilotes vers le nouveau schéma — **uniquement les fichiers JSON à cette étape, aucun dossier `public/tenants/` ni image à créer.** **jerome-loze** (source : `sandbox/jloze/_data/data-client.json`, et son portfolio, clés `prest_01_folio_01..11` documentées en audit section 2.a) : écris `storage/app/tenants/jerome-loze/prod.json` et sa copie identique `storage/app/tenants/jerome-loze/sandbox.json` (`publie: false`). **sophie-libourel** (source : `sandbox/slibour/`, génération 1, contenu codé en dur, aucune donnée structurée source) : extrais manuellement/semi-automatiquement le contenu vers le nouveau schéma. Documente précisément ta méthode d'extraction (quels fichiers PHP lus, comment chaque section a été identifiée) dans `storage/app/tenants/sophie-libourel/NOTES_EXTRACTION.md` — cette méthode devra être répétable sur les 9 autres clients de génération 1 plus tard. Écris `storage/app/tenants/sophie-libourel/prod.json` et sa copie `sandbox.json` (`publie: false`). Pour les deux : signale toute clé source sans équivalent clair dans le nouveau schéma plutôt que de la deviner. **Affiche les deux paires de fichiers et attends une validation humaine explicite avant de continuer.** ### Étape 3 — Les deux dossiers physiques (ARRÊT — attendre confirmation) Une fois les JSON validés et `STRUCTURE_DOSSIER_CLIENT.md` confirmé, crée `public/tenants/jerome-loze/` et `public/tenants/sophie-libourel/` selon cette structure : photos de présentation renommées selon la convention `prenom-nom-metier-ville-[chiffre]`, et pour jerome-loze uniquement, les photos de portfolio organisées dans `portfolio/{slug-prestation}/{thematique}/`. Si une thématique n'est pas claire depuis la source, place la photo dans un dossier `a-trier/` plutôt que d'inventer une catégorie, et signale-le. Si sophie-libourel n'a pas de photos de portfolio identifiables, ne crée pas de dossier `portfolio/` vide. ### Étape 4 — Bilan (ARRÊT — attendre confirmation) Résume ce qui a été produit, liste toute clé ou donnée signalée comme ambiguë, et attends la validation humaine avant qu'une prochaine mission ne construise le code Laravel par-dessus ces données. ## CE QUE TU NE DOIS PAS FAIRE - Ne pas construire de route, contrôleur, vue ou commande Artisan. - Ne pas créer de client de test générique (`client-demo`) à cette étape — ce sera fait plus tard, avec le prompt de construction du code, quand il faudra une fixture pour tester sur `dev.lesiteduliberal.fr`. - Ne pas utiliser `sandbox/cms_portfolio` comme source pour Jérôme Loze — c'est la version obsolète (voir audit section 8.2). - Ne pas inventer de valeur pour une clé source ambiguë — signale et demande. - Ne pas toucher aux dossiers de suivi de prestation. - Ne jamais dupliquer `dossier_suivi_prestations_a_renommer/data.json` (données réelles de Caroline Poplawec).