coordination-cuisine

# Coordination cuisine (pass / KDS) Pendant le service, la cuisine dicte l'état des plats (« le tartare de la 12 est prêt ») et ce skill tient le KDS à jour, plat par plat, jusqu'au passage de la commande complète. Complète `gestion-commandes` (statut de la COMMANDE) en travaillant au niveau de l'ITEM. ## Étape 0 — Références et établissement (obligatoire) 1. Charger `${CLAUDE_PLUGIN_ROOT}/reference/directives-outils.md` et appliquer ses règles pendant toute l'exécution (IDs, confirmations, données, formats, erreurs). 2. S'assurer d'avoir l'`establishment_id` (le demander si absent) avant tout appel. 3. Règle « Résolution des noms » (directives § 1 ter) : tout nom parlé ou écrit (produit, ingrédient, plat, équipement, table, recette) se résout via `search_entities` AVANT tout autre appel — fuzzy FR géré par le serveur (accents, pluriels) ; si `ambiguous=true`, présenter les candidats et DEMANDER confirmation avant d'agir. Jamais d'ID deviné. ## Machine à états d'un plat (KDS) `pending → in_progress → ready → served` — vérifié serveur. Transitions STRICTES : **jamais de saut en avant** (pending ne passe pas directement à ready), **jamais de retour arrière sans confirmation explicite**. `served` (plat envoyé en salle) : uniquement quand la salle confirme l'envoi. ## Workflow 1. **Vue du pass** — `list_orders` (`establishment_id`, `status: "en_preparation"` — ajouter `confirmee` si la cuisine veut voir ce qui arrive) : commandes en cours avec leurs items. L'`item_id` d'un plat est l'ID de l'ITEM DE COMMANDE (ligne `boutique_commande_items` renvoyée dans la commande) — jamais l'ID du plat au menu. 2. **Résoudre les noms dictés à l'oral** — quand l'utilisateur nomme un plat (« le burger », « la 12 »), croiser d'abord avec les items des commandes en cours ; si le nom reste ambigu, `search_entities` (`establishment_id`, `query`, `types: ["dish", "table"]`) pour retrouver le plat ou la table — si `ambiguous=true`, DEMANDER confirmation avant d'agir. Ne jamais deviner quel item d'une commande correspond à un nom flou. 3. **Faire avancer les plats** — `update_kds_item_status` (`establishment_id`, `item_id`, `status`) plat par plat : `pending → in_progress` quand la cuisine attaque, `→ ready` quand le plat est au pass, `→ served` quand la salle l'a envoyé. Annoncer chaque changement (« Tartare table 12 → prêt »). 4. **Commande complète** — quand TOUS les plats d'une commande sont `ready`, le signaler et PROPOSER `update_order_status` (`order_id`, `status: "prete"`) — décision de l'utilisateur, jamais automatique (machine à états des commandes : voir `gestion-commandes`). 5. **Commandes qui attendent** — à chaque vue du pass, signaler toute commande en cours depuis plus que le seuil maison (`./rapido-kb/processus-internes.md`, défaut 15 min) : « ⏱ table 7 attend depuis 18 min ». Proposer l'action, ne pas la décider. 6. **Charge par poste** — `get_station_load` (`establishment_id`) : la file de chaque poste (grill, froid, pâtisserie…). Un poste qui déborde pendant que les autres respirent = proposer de re-séquencer les lancements, pas d'empiler. À lire avant d'annoncer un temps d'attente à la salle. ## Mode coup de feu Pendant le service : réponses ULTRA-COURTES — une ligne par action (« ✅ Tartare table 12 → prêt »), pas de récapitulatif intermédiaire, un « ✅ » de l'utilisateur vaut confirmation de la dernière proposition. Le récapitulatif complet (IDs, statuts, retards) se fait EN FIN DE SERVICE. L'agent `chef-de-pass` incarne ce mode. ## Garde-fous - Item ≠ plat au menu : `update_kds_item_status` prend l'ID de la ligne de commande. En cas de doute, relister la commande (`get_order`) avant d'agir. - Un nom ambigu (plusieurs commandes contiennent le même plat) = question à l'utilisateur, jamais un choix silencieux. - Le passage de la commande en `prete` est PROPOSÉ, pas imposé : la cuisine peut vouloir tenir un plat au chaud. - Récapituler en fin de séquence : items avancés (IDs + nouveaux statuts), commandes proposées au passage.