| / | Cockpit « qu'est-ce que je dois faire maintenant ? » : file unifiée à traiter, production photos, activité récente. |
| /leads | Pipeline commercial (kanban/liste) Prospect → Lead → Client. |
| /leads/[id] | Fiche lead : édition de l'audit vitrine + aperçu du document exact ; envoi, conversion en client. |
| /leads/[id]/presentation | Mode rendez-vous : l'audit plein écran tel que le lead le voit. |
| /leads/import | Import de prospects en masse. |
| /leads/fusions | Doublons détectés (place_id Google) à fusionner ou écarter. |
| /terrain · /terrain/saisie | PWA mobile du commercial : ajout de prospect, objectifs, RDV du jour, saisie rapide terrain. |
| /prospection | Audit flash : une URL Talabat → audit complet ~2 min, lead « démarchage » créé. |
| /performance/sprint | Saisie du soir du sprint terrain (objectifs vs réalisé). |
| /performance/activite | 📊 Activité du commercial (16/09) : appels passés (dont aboutis), portes poussées, argumentaires avec à qui (patron · manager · staff), RDV pris — aujourd'hui, cette semaine, sur le sprint (ou 30 jours si aucun sprint ne couvre le jour), et jour par jour sur 14 jours. Un commercial voit les siens ; un administrateur choisit la personne (défaut : le premier commercial de terrain) et voit le tableau de l'équipe. Faits : interactions, appels sans réponse (journal), argumentaires (journal interaction / argumentaire, posés depuis la fiche 📞 et la saisie terrain), rendez-vous créés — règles pures lib/activite/regles.ts. |
| /carte | QR vCard du commercial connecté. |
| /rendezvous | RDV : à clôturer / à venir / historique — vues Liste, Mois, Semaine, 3 jours. |
| /relances | File de relances commerciales (en retard / aujourd'hui / à venir), journée à l'heure de Dubaï, heure convenue affichée (15/09). |
| /bibliotheque | Supports de vente FR/EN (grille tarifaire, contrat, deck, scripts). |
| /parrainages | Programme de parrainage B2B/B2C : prime LIBRE par partenaire (la famille propose 400 / 250 AED, le champ remplace), code unique, double confirmation calculée ; un admin modifie (nom, famille, prime) ou supprime depuis la ligne, chaque geste journalisé (14/09). Depuis le 15/09 : le commercial PROPOSE, l'admin VALIDE — le commercial propose un partenaire (nom + famille) et ne voit que les siens ; les admins sont notifiés (cloche + Telegram/push) et trouvent en tête de page le bloc rouge « À valider » où ils fixent la prime et valident (le code s'active, le commercial est notifié) ou refusent ; confirmations possibles seulement après validation, paiement/modification réservés aux admins côté serveur. Aucune colonne : l'état se déduit du journal CRM (lib/crm/parrainages-regles.ts, règles pures testées). |
| POST /api/clients/[id]/plateformes | statut de mise en ligne d'une plateforme (live exige |
| POST /api/clients/[id]/moments | un des six rendez-vous ; la règle d'ordre (visibilité / |
| GET|POST /api/clients/[id]/conformite | indice de conformité menu d'une plateforme |
| POST /api/clients/[id]/blocage | « bloqué, et par qui » (aucun / delivup / client / plateforme). |
| POST /api/clients/[id]/cycle | champs internes (stade de marque, objectifs) — jamais montrés au client. |
| /clients | Liste des clients : par ligne, le chemin en 5 cases PROUVÉES (Contrat · Menu · Photos · Livrable · En ligne — lib/clients/avancement.ts, 08/09), la prochaine action et qui l'a en main (nous / client / plateforme), l'argent vérifié (ou « non renseigné »), l'inactivité (rien depuis N j), puis les phases 2 (plateformes) et 3 (rendez-vous). Filtres : bloqués, rien depuis 7 j, phase 2, phase 3, partiel. clients.status est dérivé du moteur (jamais saisi). |
| /clients/[id] | LA fiche client, onglets pilotés par ?onglet= (chaque onglet ne paie que ses requêtes) : |
| /clients/[id]/saisie | Vue « Route C » : copier-coller champ par champ pour publier le menu. |
| /documents | « À traiter » d'abord (chaque ligne porte son bouton), puis l'archive filtrable. |
| /cdc/[id] | La page d'un document CDC : stepper de cycle de vie, puis (12/09) le journal du document (généré, modifié, recontrôlé, envoyé, validé — qui et quand) et la provenance de chaque décision (champ · règle · source · détail, repliée par famille), édition, envoi, réponse client. L'éditeur interne couvre textes, styles, table du menu, structure proposée (destination + raison par catégorie, colonne « Proposé » reconstruite par lib/cdc/plan-categories.ts) et retraits (un plat coché revient au menu) ; chaque enregistrement est journalisé et recontrôlé. |
| /cdc/regles | Les règles du CDC : ce que le générateur décide pour chaque client, dans l'ordre (verrou, structure, retraits, plats signature, prix, noms, onboarding, traçabilité, rédaction des fiches). Rend docs/planning/REGLES_CDC.md, embarqué au prebuild comme le registre photos ; même composant de rendu (app/components/RegistreRegles.tsx). Lecture seule : une règle change par constat daté → registre → lib/cdc/regles.ts + test sur le cas réel → contrôle de cohérence. Les règles 📋 attendent l'arbitrage de Redwane (brief 09/09, points 7 et 12). |
| /cdc/import | Importer un CDC fait main dans le circuit normal. |
| /cdc/photos | Retoucher les photos d'un CDC HTML autonome. |
| /visuels | Hub de production photos : une carte par client, la prochaine action en évidence. |
| /visuels/essais | Essais internes (avant/après changement de règle), jamais livrés. |
| /performance | Performance commerciale agrégée, filtrable par membre. |
| /finance | Tableau financier des fondateurs (admins uniquement). |
| /costs | Coûts API réels 30 j + soldes fournisseurs + estimateur. |
| /equipe | Membres, rôles (Commercial/Admin) et objectifs. |
| /visuels/plaques | Bibliothèque d'art direction : archétypes, plaques, décors. |
| /visuels/contenants | 🏠 Bibliothèque de contenants MAISON (16/09) : les contenants nus que le moteur emploie quand le client n'a pas fourni le sien, grille de couverture famille × usage (un trou = un contenant inventé par l'IA). Même mécanique que la carte Packaging d'un client (lib/visuels/contenants-gestion.ts) ; résolution en cascade client → maison → contenant neutre (lib/visuels/contenants-resolution.ts, pur, testé) ; sonde contenants_references sur /sante. |
| /notifications | Centre de notifications : décisions à trancher en tête, non-lues par jour, filtre par famille (?famille=) avec compteurs, lues repliées, réglages d'envoi (13/09). |
| /visuels/matrice | La matrice expliquée : le parcours visuel complet, chiffres lus en base. Les 8 thématiques d'habillage en deux familles (tirées du plat / tirées du client) avec leur couverture RÉELLE sur les plats de la base (moteur rejoué) et la validation humaine posé/nu des 30 derniers jours (12/09). |
| /visuels/regles | Les règles de génération : ce que le moteur décide pour chaque photo, dans l'ordre où il le décide. S'ouvre sur le parcours d'une photo (7 décisions : quel plat, quelle liberté, quel décor, quel angle, quel contenant, quel contenu, quel habillage), puis chaque règle avec son titre en français et son incident d'origine dépliable. Lecture seule : la page rend docs/planning/REGLES_GENERATION.md, embarqué au prebuild — une règle change par le circuit incident → registre → code → banc, jamais par un champ de texte. Affiche aussi les conflits ouverts qui attendent un arbitrage humain. |
| /config/traductions | Traductions de l'admin : chaque libellé français et sa version anglaise (code, IA à relire, corrigé par l'équipe) ; une correction s'applique en ≤ 60 s sans déploiement (table traductions_admin). |
| /visuels/referentiel | Référentiel visuel : images de référence et libellés anglais des styles de bannière (A–E) et des archétypes photo, montrés au client dans le CDC (« Choose ONE direction »). Sans image, le CDC affiche une illustration générée qui nomme le style. |
| /prompts | Les prompts IA dans l'ordre du process, version réellement en prod ; fiches d'expertise des agents ; blocs de base du moteur photo (poids, usage 7 j, édition par la même API que la consolidation 🔬 — 10/09). |
| /sante | Santé du moteur : modèles IA, BiRefNet, VPS, latence base. |
| /workflows | Journal des exécutions robot + registre DV-01→DV-12 (liens n8n). |
| /config | Mode manuel/auto par étape + modèle d'IA par tâche + référentiels CRM + whitelist d'habillage (activer/désactiver une ligne, AJOUTER un terme à la main ou depuis les mots fréquents des menus réels — thématique + code du catalogue, 12/09 ; les anciennes listes épices/végétaux du routage ont été absorbées). |
| /emails | Templates emails/WhatsApp dans l'ordre du parcours, lus en base à l'envoi. |
| /sync-notion | (admin) sas de validation des propositions Claude avant push Notion. |
| /login | connexion admin (OTP email) · /c/[prenom] — carte de visite publique. |