KDS intelligent

Tu construis KDS intelligent, une extension du Hackathon BraindCode.

Projet : KDS intelligent
Produit cible : FoodEatUp
Type de projet : Orchestrateur — Un noyau d’exécution unique qui enchaîne plusieurs outils et plusieurs produits en routines.
Promesse : priorisation des tickets en cuisine
Problème : Chaque établissement doit aujourd’hui suivre priorisation des tickets en cuisine en rapprochant des informations dispersées. Les écarts sont souvent découverts après le service ou la clôture, quand il est plus coûteux de les corriger. Le responsable manque d’une explication simple et vérifiable pour arbitrer. KDS intelligent doit consolider les faits sans exécuter une décision sensible à sa place.
Objectif : Fournir une vue opérationnelle et traçable de priorisation des tickets en cuisine, avec des priorités explicables et une validation humaine avant toute action.

PILE TECHNIQUE
TanStack Start, React, Tailwind, composants shadcn, Lovable Cloud pour l’authentification, la base de données et les fonctions serveur. Tous les appels MCP passent par des fonctions serveur.

IDENTITÉ VISUELLE
CHARTE GRAPHIQUE — FoodEatUp

Logo officiel du logiciel : https://build.braindcode.com/__l5e/assets-v1/64401626-4b06-49a4-88cf-c6f9f0348e04/foodeatup-logo.png

Logo BraindCode : https://build.braindcode.com/__l5e/assets-v1/b8ab3ddf-7aea-424d-9772-b9ef3a681d1d/braindcode-logo.jpg

Couleurs :
- primary : #0098F3
- night : #161B2C
- ink : #0F172A
- surface : #FFFFFF
- surface_alt : #F1F8FE
- border : #DCE7F0
- success : #10B981
- warning : #F59E0B
- danger : #EF4444

Typographie : titres Gilroy, 600/700 (repli Poppins) / corps Inter, 400 / technique JetBrains Mono.
Titre 30/38, sous-titre 20/28, corps 15/24, étiquette 12/16 en capitales espacées.

Rayon 8 px pour les cartes et champs, 6 px pour les boutons, 999 px pour les badges.
Échelle 4 / 8 / 12 / 16 / 24 / 32 / 48. Interface dense : préfère 12 et 16 dans les tableaux.
Icônes lucide-react, trait 1.5 px, taille 16 ou 20 px, jamais colorées en plein.

Règles d'interface :
- Interface de restaurant : lisible à distance, en cuisine, sur écran tactile.
- Cibles tactiles d'au moins 44 px, contrastes élevés, aucune information critique en gris clair.
- Statuts d'hygiène et de stock en vert #10B981, alerte en ambre #F59E0B, rupture ou non-conformité en rouge #EF4444.
- Les fiches recette, lots et codes HACCP s'affichent en monospace.

Interdits :
- Aucun emoji, nulle part.
- Aucun rendu 3D photoréaliste ni illustration décorative générique.
- Aucun dégradé violet/indigo sur fond blanc.
- Aucun logo de marque inventé : n'utilise que les URL de logo fournies.
- La couleur du logiciel reste un accent (bordures, badges, filets, états actifs), jamais un aplat de fond plein écran.

VISUELS DU PROJET
- Image officielle du projet (couverture 16:9) : https://build.braindcode.com/__l5e/assets-v1/828687ed-2488-4c7d-91c5-94ef8bfd24bf/kds-intelligent.jpg
- Accroche : priorisation des tickets en cuisine
- Punchline : Fournir une vue opérationnelle et traçable de priorisation des tickets en cuisine, avec des priorités explicables et une validation humaine avant toute action.
- Logo du logiciel : https://build.braindcode.com/__l5e/assets-v1/64401626-4b06-49a4-88cf-c6f9f0348e04/foodeatup-logo.png
- Logo BraindCode : https://build.braindcode.com/__l5e/assets-v1/b8ab3ddf-7aea-424d-9772-b9ef3a681d1d/braindcode-logo.jpg
Reprends l'accroche et la punchline dans l'écran d'accueil et la page de partage. Réutilise l'image officielle comme visuel de couverture, ne la remplace pas par une image générée.

VARIABLES CSS À DÉCLARER
--color-primary: #0098F3;
--color-night: #161B2C;
--color-ink: #0F172A;
--color-surface: #FFFFFF;
--color-surface-alt: #F1F8FE;
--color-border: #DCE7F0;
--color-success: #10B981;
--color-warning: #F59E0B;
--color-danger: #EF4444;
--font-heading: Gilroy, 600/700 (repli Poppins);
--font-body: Inter, 400;
--font-mono: JetBrains Mono;

Tu vas produire l'interface d'une extension tierce du logiciel FoodEatUp, éditée par un développeur indépendant dans le cadre du Hackathon BraindCode.\n\nIDENTITÉ À RESPECTER\nMon extension est un produit distinct : elle porte son propre nom et sa propre identité, mais elle doit être visuellement compatible avec FoodEatUp et signaler clairement son appartenance à l'écosystème BraindCode.\n\nCouleur d'accent produit : #0098F3\nTypographie produit : Gilroy, fallback Poppins\nLogo produit : https://build.braindcode.com/__l5e/assets-v1/64401626-4b06-49a4-88cf-c6f9f0348e04/foodeatup-logo.png, à afficher uniquement dans une mention d'appartenance du type « Extension pour FoodEatUp », jamais comme logo principal de mon application.\n\nRÈGLES D'USAGE DES LOGOS\nNe jamais déformer, incliner, recolorer ou recomposer le logo FoodEatUp ni le logo BraindCode.\nNe jamais laisser croire que l'extension est éditée par BraindCode.\nRespecter la zone de protection autour de chaque logo.\n\nSYSTÈME VISUEL DEMANDÉ\nFond clair par défaut, surfaces sombres en #161B2C, texte #000000, gris de bordure #C1C1C1, une seule couleur d'accent : #0098F3. Monospace pour tout élément technique.\nComposants : cartes, tableaux denses, badges d'état, barre latérale de navigation.\nInterface en français, sobre, orientée métier.

MVP À LIVRER
- tableau de synthèse de priorisation des tickets en cuisine
- filtres par période, établissement et statut
- détail sourcé de chaque signal
- priorités et recommandations explicables
- export ou partage du résultat

DONNÉES NÉCESSAIRES
- établissements et zones
- produits, stocks et services concernés
- événements opérationnels horodatés
- statuts, responsables et historiques

ENTITÉS À MODÉLISER
- établissement
- service
- signal
- indicateur
- recommandation

CAPACITÉS MCP À COUVRIR (à découvrir à l’exécution, jamais en dur)
- lire les référentiels autorisés
- consulter les événements et historiques
- filtrer par établissement et période
- obtenir les statuts et indicateurs agrégés

Connecte d'abord le serveur BraindCode Build à l'adresse https://build.braindcode.com/api/mcp. Utilise get_project_context pour récupérer le contexte de cette idée et list_connectors pour connaître uniquement les connecteurs réellement configurés. N'invente jamais d'adresse MCP tierce.

Serveur MCP concerné : FoodEatUp — récupère son adresse avec get_project_context. Authentification OAuth 2.0 révocable. Prévois néanmoins la connexion de plusieurs serveurs : un seul mécanisme, plusieurs connecteurs découverts via list_connectors.

CONNEXION AUX SERVEURS MCP (FoodEatUp)

Construis une couche de connexion MCP générique, utilisable pour FoodEatUp, RapidoCRM, RapidoCMS et RapidoRH.

1. Table de connecteurs : clé du serveur, nom affiché, URL HTTPS, type d'authentification (aucun, clé, OAuth), statut (connecte, deconnecte, erreur), dernier test, message d'erreur. Lecture réservée aux comptes autorisés.
2. Table de secrets séparée : jeton d'accès, jeton de rafraîchissement, clé API, expiration. Jamais lisible depuis le navigateur, jamais renvoyée par une fonction serveur.
3. Dialogue MCP en JSON-RPC 2.0 sur HTTP « Streamable » côté serveur uniquement :
   - en-têtes : Content-Type: application/json et Accept: application/json, text/event-stream ;
   - séquence : initialize (protocolVersion 2025-06-18), puis notifications/initialized, puis tools/list, puis tools/call ;
   - conserver l'identifiant de session renvoyé dans l'en-tête Mcp-Session-Id et le renvoyer sur les appels suivants ;
   - accepter aussi bien une réponse JSON qu'un flux d'événements, en extrayant les lignes data: ;
   - délai maximum 15 secondes, messages d'erreur lisibles (injoignable, non autorisé, délai dépassé).
4. Écran d'administration des connecteurs : une carte par produit avec son logo et sa couleur d'accent, champ URL, choix d'authentification, bouton « Tester la connexion », pastille de statut et nombre d'outils découverts.
5. L'URL de chaque serveur MCP est saisie dans cet écran. N'invente jamais une adresse et n'en code aucune en dur.

OUTILS DÉCOUVERTS À L'EXÉCUTION

1. Après chaque connexion réussie, appelle tools/list et enregistre pour chaque outil : nom, titre, description, schéma d'entrée, serveur d'origine et indicateur « lecture seule / modifiant / destructif ».
2. Construis un registre unifié en mémoire, indexé par nom normalisé, fusionnant les outils de tous les serveurs connectés. En cas de doublon, préfixe par la clé du serveur.
3. Expose une recherche d'outil par intention en français (mots-clés sur le nom, le titre et la description) afin que l'assistant choisie l'outil pertinent sans liste figée.
4. N'écris jamais un nom d'outil MCP en dur dans le code ni dans l'interface : tout part du registre. Si un outil attendu est absent, affiche-le honnêtement plutôt que de simuler.
5. Valide systématiquement les paramètres contre le schéma d'entrée réel avant tout appel, et affiche les erreurs de validation à l'utilisateur.
6. Prévois un rafraîchissement manuel du registre et un affichage « N outils disponibles sur M serveurs ».

ORCHESTRATEUR D'EXÉCUTION

Tous les chemins d'appel d'outil (interface, assistant, routine automatique) passent par un noyau serveur unique. Ce noyau, et lui seul, réalise dans cet ordre :

1. Résolution de l'outil dans le registre unifié.
2. Validation des paramètres contre le schéma réel ; refus explicite sans consommation de quota.
3. Garde-fou : toute action modifiante ou destructrice exige une confirmation humaine explicite, transmise comme paramètre de confirmation. Sans elle, refus.
4. Consommation d'un quota par compte et par jour, avec refus lisible quand il est épuisé.
5. Journal d'exécution : outil, serveur, paramètres non sensibles, statut, durée, résultat résumé, erreur éventuelle.
6. Retour d'un résultat typé succès/échec, jamais une exception brute.

Ajoute au-dessus un planificateur : à partir d'une demande en langage naturel, il propose une suite d'étapes (outil + paramètres), l'affiche pour validation, puis l'exécute étape par étape avec possibilité d'arrêt. Les routines enregistrées rejouent une suite d'étapes et sont visibles dans un tableau de bord : dernières exécutions, taux de succès, durée moyenne, erreurs récentes.

SÉCURITÉ — RÈGLES NON NÉGOCIABLES

1. Aucun jeton, clé ou identifiant MCP dans le navigateur, dans le code source, dans une variable publique ou dans un journal.
2. Seules les URL HTTPS sont acceptées. Refuse les adresses locales, les réseaux privés et les redirections automatiques.
3. Tout appel MCP part du serveur. Le navigateur n'envoie qu'une intention et des paramètres validés.
4. Chaque appel est journalisé sans secret : utilisateur, serveur, outil, statut, durée.
5. Les actions destructrices exigent une confirmation humaine explicite et sont toujours réversibles ou tracées.
6. Les données affichées respectent les droits du compte connecté : jamais d'élévation de privilèges pour « faire fonctionner » une fonctionnalité.
7. Aucune donnée client réelle en démonstration : jeu de données fictif crédible.

TESTS ET LIVRABLES

1. Tests automatiques : validation des paramètres, refus d'une action sensible non confirmée, épuisement du quota, serveur MCP injoignable, outil absent du registre.
2. Tests manuels documentés : connexion d'un serveur, découverte des outils, exécution d'une action lecture, exécution d'une action sensible confirmée, consultation du journal.
3. États d'interface à couvrir : vide, chargement, erreur, résultat, confirmation.
4. Rapport de tests exportable, avec date, périmètre et résultats.
5. Livrables : dépôt public, serveur MCP de l'extension documenté et joignable, déclaration dans Plan'It, plugin publié sur plugin.braindcode.com, validation par un modèle tiers (Claude, Mistral ou OpenAI).
6. Vérifie le rendu sur ordinateur et sur téléphone avant de considérer le projet terminé.

Ajoute à ce projet la couche d'accès au serveur MCP FoodEatUp, hébergé par une application Laravel.\n\nRÈGLE NON NÉGOCIABLE\nAucun jeton, aucune clé, aucun identifiant MCP ne doit exister côté navigateur. Tout appel passe par une fonction serveur qui joue le rôle de proxy.\n\nÀ CONSTRUIRE\n1. Une fonction serveur mcp-proxy qui reçoit une action et ses paramètres, ajoute l'authentification depuis les secrets du projet, appelle le serveur MCP, et renvoie la réponse. Les secrets ne sont jamais journalisés.\n2. Une authentification par jeton porteur émis par Laravel, avec rafraîchissement et gestion de l'expiration. Sur 401, demander une reconnexion sans réessayer en boucle.\n3. Une découverte dynamique des outils au démarrage : lister les outils exposés, les mettre en cache pour la session, ne jamais coder une liste en dur.\n4. Une isolation stricte par établissement ou compte client ; refuser tout appel sans périmètre.\n5. Une distinction lecture / écriture avec confirmation explicite avant toute écriture.\n6. Un journal des appels : horodatage, outil, périmètre, statut, durée.\n7. Des erreurs lisibles en français avec comportement de repli.\n\nÀ NE PAS FAIRE\nN'invente aucun nom d'outil : construis le code autour de la liste découverte à l'exécution. N'implémente aucune écriture avant que la lecture ne fonctionne de bout en bout.

Les skills, routines et plugins publiables se trouvent sur https://plugin.braindcode.com. Cette marketplace complète le MCP BraindCode mais ne remplace pas son adresse de connexion.

ROUTINE & LOOP-ENGINEERING
Une extension livrée ne vaut que par ce qu'elle fait tourner. Connecte-toi au serveur MCP de la marketplace de prompts et de routines : https://plugin.braindcode.com/mcp (catalogue public sur https://plugin.braindcode.com).
Outils de routine disponibles côté marketplace : chercher_prompts, prompts_pour_agent, lister_routines, obtenir_routine, proposer_routine, mettre_a_jour_routine, planifier_routine, installer_routine, enregistrer_execution_routine, journal_routine, auditer_routines, rendre_verdict_routine, promouvoir_routine, lister_boucles, obtenir_boucle, definir_kpi, enregistrer_kpi, serie_kpi, rattacher_kpi_routine, alertes_kpi, tableau_de_bord, ma_semaine, lister_mcp, routines_pour_mcp. Découvre-les à l'exécution, n'en code aucun en dur.
Avant d'écrire du code, cherche s'il existe déjà une routine ou un prompt éprouvé pour FoodEatUp et repars de là.
Quand le projet est livré, écris sa routine par défaut avec les six champs obligatoires — objectif chiffré et échéance, déclencheur, outils MCP autorisés, garde-fous chiffrés, point d'arrêt humain, mesure (KPI et sa source) — fais-la auditer avec auditer_routines, puis propose-la avec proposer_routine. Elle s'exécutera ensuite dans Plan'It.
Points d'arrêt humains non négociables : dépenser de l'argent, publier publiquement, écrire à un client, signer. L'agent prépare, l'humain valide. Aucune clé d'API ni jeton dans un prompt ou dans le navigateur.

ÉCRANS À CONSTRUIRE
- tableau de bord
- liste filtrable
- détail d’un signal
- paramètres

ÉTATS À GÉRER
- chargement
- aucune donnée
- erreur de connexion
- résultats disponibles
- action confirmée

ACTIONS SENSIBLES — CONFIRMATION HUMAINE OBLIGATOIRE
- modifier une donnée opérationnelle
- déclencher une notification externe
- valider, annuler ou lancer une opération

NOTES DE CADRAGE
Commencer en lecture seule sur un établissement de démonstration. Rendre chaque résultat traçable jusqu’à sa donnée source. Tester la qualité et la fraîcheur des données avant de proposer une action.

SUIVI BRAINDCODE
Enregistre l'avancement avec save_project_progress, utilise check_project_readiness avant la publication, puis publish_project pour créer la vitrine publique sur build.braindcode.com.