docs: remediation audit vague 1 - sync Merise + journal/ADR + claims faux (#106)

SECURITY.md

@@ -19,7 +19,7 @@ d'authentification durci dans `docs/uml/security-sequence.md`.
 | Brute-force | double throttle : compteur par compte (`user`) + par IP (`login_throttle`), backoff degressif |
 | Sessions | cookies `HttpOnly` + `Secure` + `SameSite=Strict`, regeneration d'ID a la connexion (anti-fixation), idle 4h / absolu 10h |
 | Injection | PDO prepared statements exclusivement |
-| Upload | validation MIME + taille, stockage hors webroot |
+| Upload | non implemente (aucun flux d'upload livre) ; prevu : validation MIME + taille, stockage hors webroot |
 | En-tetes / PHP | `expose_php=Off`, `allow_url_fopen/include=Off`, `cgi.fix_pathinfo=0`, fonctions d'execution systeme desactivees |
 | RGPD | retention limitee (audit ~12 mois, throttle 24h, commandes ~3 ans), droit consultation/modif/suppression |
 | Secrets | `.env` gitignore, tenu hors de `.git/config` (credential helper lisant `.env`), secret-scan gitleaks en CI |

docs/ARCHITECTURE.md

@@ -17,13 +17,17 @@ Wakdo simule une borne de commande tactile de restauration rapide, avec back-off
 d'administration, workflow cuisine et API REST interne. Deux surfaces applicatives :
 
 - **Borne (kiosk)** — front statique (HTML/CSS/JS vanilla ES6) servi par Apache,
-  consommant des donnees (JSON statique en P5, API DB-backed au swap P4).
+  consommant l'API REST DB-backed (`/api/*`). Le repli JSON statique initial a ete
+  retire au profit d'un branchement direct sur l'API.
 - **Back-office + API** — application PHP rendue serveur (MVC maison) + endpoints
   `/api/*`, derriere authentification et RBAC.
 
 Trois canaux de commande (`source`) : `kiosk`, `counter`, `drive`. Le cycle de vie
-d'une commande et la machine a etats sont decrits dans `docs/merise/` (domaine
+d'une commande et la machine a etats sont decrits dans `docs/merise/`. Le domaine
-commande = phase **P4**, schema en base mais workflow applicatif a venir).
+commande est livre de bout en bout : creation et encaissement via l'API
+(`POST /api/orders`, `POST /api/orders/{number}/pay` avec decrement de stock),
+file cuisine (KDS), annulation et livraison cote back-office, saisie comptoir et
+drive (POS tactile).
 
 ---
 
@@ -132,8 +136,8 @@ src/app/
   Views/         admin/*  (pages back-office rendues serveur), auth/*  (login/reset)
 src/public/
   admin/         front controller + assets (CSS/JS) du back-office
-  borne/         front kiosk statique (index, categories, products, product, cart,
+  borne/         front kiosk statique (index, categories, products, payment,
-                 payment, confirmation) + assets JS modules + data JSON
+                 confirmation ; panier en panneau persistant) + assets JS modules
 ```
 
 Conventions transverses : controleurs non-`final` (seam de test : sous-classe injectant
@@ -165,7 +169,7 @@ Vue rendue dans admin/layout (sorties echappees, RG-T15) | ou JSON pour /api/*
 ```
 
 La borne (kiosk) est servie en statique par Apache ; ses pages consomment les donnees
-via `fetch` (JSON statique en P5 ; bascule sur `/api/*` DB-backed au swap P4).
+via `fetch` sur l'API DB-backed (`/api/*`).
 
 ---
 
@@ -214,7 +218,7 @@ Threat model STRIDE + classification des donnees : `docs/PROJECT_CONTEXT.md` sec
   `ingredient`, `product_ingredient`, `allergen`, `ingredient_allergen`, `stock_movement`.
 - **RBAC / comptes** : `user`, `role`, `permission`, `role_permission`,
   `role_visible_source`.
-- **Commande (P4, schema pret)** : `customer_order`, `order_item`,
+- **Commande (livre)** : `customer_order`, `order_item`,
   `order_item_selection`, `order_item_modifier`.
 - **Transverses** : `audit_log` (journal immuable), `login_throttle`, `pin_throttle`.
 

docs/PROJECT_CONTEXT.md

@@ -117,7 +117,7 @@ Client                Borne (Bloc 1)           API (Bloc 2)          BDD
 
 ### Compatibilite evaluation par bloc
 
-- **Jury Bloc 1** : voit le front seul ; le front peut tomber en fallback sur JSON statiques fournis (`src/public/borne/data/*.json`) si l'API est indisponible.
+- **Jury Bloc 1** : voit le front seul ; le front consomme les donnees via `fetch` sur l'API (`/api/*`). Le fallback JSON statique initialement envisage a ete retire (la borne est branchee directement sur l'API DB-backed).
 - **Jury Bloc 2** : voit le back-office + teste l'API via curl/Postman de maniere autonome, sans dependre du front.
 - **Jury Bloc 5** : lance `docker compose up` ou `docker compose up`, verifie la CI/CD, les crons, l'archi, les scripts.
 
@@ -205,7 +205,7 @@ Reseaux :
 ### Bloc 1 — Borne client (Front)
 
 **IN scope :**
-- Affichage dynamique menus + produits (charges par Ajax depuis API ou JSON fallback)
+- Affichage dynamique menus + produits (charges par `fetch` depuis l'API `/api/*`)
 - Composition panier : produits unitaires OU menus (burger + accompagnement + boisson + sauce)
 - Options taille (normale / grande, +0,50 € sur grande) pour accompagnements et boissons
 - Options de personnalisation simples (ex : sans oignon, avec fromage)
@@ -232,7 +232,7 @@ Reseaux :
 - **Manager** : catalogue (create/update), stock (reappro + inventaire), statistiques ; utilisateurs en **lecture seule** (`user.read`, pas de creation/modification/desactivation), pas d'acces RBAC
 - **Kitchen** : file des commandes `paid` triee par `paid_at` croissant, en **lecture seule** (KDS visuel) ; inventaire
 - **Counter** / **Drive** : saisir une commande (comptoir / drive-thru via casque/intercom), bouton "declarer livree" (geste unique `paid -> delivered`), annuler ; `source` auto-tague depuis `role.order_source` ; inventaire
-- Upload images produits (validation type MIME + taille + stockage dans volume `wakdo_uploads`)
+- Upload images produits : **non implemente** ; prevu (validation type MIME + taille + stockage dans volume `wakdo_uploads`)
 - Historique commandes par statut
 - Stats de base (commandes du jour, CA jour, produits top)
 

docs/adr/0011-pos-tactile-tuiles-comptoir-drive.md

@@ -0,0 +1,43 @@
+# ADR-0011 — POS tactile a tuiles pour la saisie comptoir/drive
+
+- Statut : Accepte
+- Date : 2026-06-25
+
+## Contexte
+La saisie de commande comptoir/drive (mlt 4.1, `CREATE_COUNTER_ORDER`) avait d'abord ete
+livree comme formulaire-liste enrichi (#100) : une liste de produits avec champs de
+quantite, prix, verrou du mode de service au canal drive, file des commandes recentes.
+Cet ecran est destine a des equipiers non-techniques, sur tablette, dans un contexte de
+caisse ou la rapidite compte. Le formulaire-liste se prete mal au tactile (petites cibles,
+defilement) et ne ressemble pas au geste deja appris cote borne client. Options :
+conserver et raffiner le formulaire-liste ; adopter un paradigme de caisse (POS) a tuiles
+reutilisant l'UX borne ; integrer une bibliotheque de POS tierce.
+
+## Decision
+La saisie comptoir/drive devient un **POS tactile a tuiles** (#104) calque sur la borne
+client : onglets categories en haut, grille de tuiles produits/menus, panneau commande
+persistant a droite ; un tap ajoute le produit, un produit a modificateurs ou un menu
+ouvre une modale de composition. Le panier est construit cote client en vanilla JS
+CSP-safe (`'self'`, zero handler inline) a partir d'un script JSON inerte, puis serialise
+dans un champ cache `items_json`. Le **serveur reste seul juge** : il revalide la forme
+(RG-T18), recalcule les prix et resout les modificateurs (RG-T16) ; les prix affiches cote
+client sont indicatifs. Un **seul controleur** sert les deux canaux, la `source`
+(counter/drive) etant derivee du chemin de la requete.
+
+## Consequences
+- (+) Geste unifie borne/comptoir : moins d'apprentissage, reutilisation des patterns
+  composeur deja eprouves cote borne.
+- (+) Cibles tactiles larges adaptees a la tablette ; zero jargon dev a l'ecran
+  (utilisateurs non-techniques).
+- (+) Decoupage par chemin (`/drive...` vs `/counter...`) : les canaux restent etanches,
+  un equipier ne peut pas requalifier sa commande via un champ falsifie.
+- (+) Sans framework front (coherent ADR-0002) ; coherent avec ADR-0001 (pas de
+  dependance tierce, donc pas de POS externe).
+- (-) Le POS est interactif par nature : sans JS, la grille ne s'affiche pas (un message
+  invite a activer JS). Un repli legacy `qty_<id>` reste accepte quand `items_json` est
+  absent, mais l'experience cible suppose JS.
+- (-) Cet ecran a ete refondu deux fois a court intervalle (#100 puis #104) ; le palier
+  #100 est assume comme etape, pas comme dette cachee.
+- Fichiers : `src/app/Controllers/CounterOrderController.php`,
+  `src/app/Views/admin/counter/new.php`, `src/public/admin/assets/js/counter-order.js`.
+  Detail : journal `docs/journal/2026-06-25--audit-remediation-et-features-94-105.md`.

docs/adr/0012-page-stock-tableau-de-bord.md

@@ -0,0 +1,41 @@
+# ADR-0012 — Page Stock en tableau de bord (alertes + reapprovisionnement en avant)
+
+- Statut : Accepte
+- Date : 2026-06-25
+
+## Contexte
+La page d'accueil Ingredients/Stock (domaine 8.8 + 9) etait une liste-CRUD exhaustive :
+tous les ingredients, avec les actions creer/modifier/supprimer en premier plan. Elle
+etait jugee trop chargee et opaque pour un equipier non-technique. Le besoin metier
+quotidien est de voir vite ce qui manque et de reapprovisionner ; l'edition de fiches est
+rare. De plus, le lien entre stock et disponibilite borne (un ingredient requis sous le
+seuil critique rend indisponibles les produits qui l'utilisent, RG-T21, cf. ADR-0003)
+n'etait pas visible a l'ecran. Options : garder la liste exhaustive triable ; basculer
+vers un tableau de bord oriente action ; deux pages distinctes (dashboard + gestion).
+
+## Decision
+La page Stock devient un **tableau de bord oriente action** (#105) : un bandeau explicite
+le lien stock -> disponibilite borne (RG-T21) ; un resume compte les ingredients
+critiques / en alerte / au-dessus du seuil ; une section "A reapprovisionner" met en avant
+les ingredients bas (critiques d'abord) avec barre de niveau et bouton de
+reapprovisionnement direct. La liste complete passe au second plan et le CRUD est relegue.
+Les compteurs par etat sont **calcules cote serveur** dans `IngredientController::index()`
+a partir du `stock_band` deja resolu par le depot, pour garder la vue declarative et la
+valeur directement testable. Les sous-pages (reappro, inventaire, mouvements, creation)
+restent inchangees.
+
+## Consequences
+- (+) L'ecran s'aligne sur le geste quotidien (reperer le manque, reapprovisionner) plutot
+  que sur l'edition de fiches.
+- (+) Le lien stock -> disponibilite borne (RG-T21) devient explicite a l'ecran, pas
+  seulement dans le code.
+- (+) Compteurs testables (la logique de comptage est cote serveur, pas dans la vue) :
+  +4 cas de test `IngredientController` (bandeau, promotion d'un critique en section
+  reappro, etat vide positif, compteurs par etat).
+- (-) La liste exhaustive et le CRUD sont moins immediats (un cran plus loin) : choix
+  assume, ces operations etant moins frequentes que la lecture d'alerte.
+- (-) Le tri/filtre avance de l'ancienne liste n'est pas reconduit en premier plan.
+- Coherent avec ADR-0002 (MVC rendu serveur) et ADR-0003 (disponibilite calculee depuis
+  le stock). Fichiers : `src/app/Controllers/IngredientController.php`,
+  `src/app/Views/admin/ingredients/index.php`, `src/public/admin/assets/css/admin.css`.
+  Detail : journal `docs/journal/2026-06-25--audit-remediation-et-features-94-105.md`.

docs/adr/README.md

@@ -18,6 +18,8 @@ une decision revisee donne une nouvelle fiche qui *supersede* l'ancienne (statut
 | [0008](0008-makefile-vers-compose-migrate.md) | Du Makefile a `docker compose up` (service wakdo-migrate) | Accepte |
 | [0009](0009-compose-standalone-et-prod-gitignore.md) | docker-compose.yml standalone + docker-compose.prod.yml gitignore | Accepte |
 | [0010](0010-cookie-secure-conditionnel-https.md) | Cookie de session Secure conditionnel au HTTPS | Accepte |
+| [0011](0011-pos-tactile-tuiles-comptoir-drive.md) | POS tactile a tuiles pour la saisie comptoir/drive | Accepte |
+| [0012](0012-page-stock-tableau-de-bord.md) | Page Stock en tableau de bord (alertes + reappro en avant) | Accepte |
 
 ## Modele de fiche
 

docs/journal/2026-06-25--audit-remediation-et-features-94-105.md

@@ -0,0 +1,210 @@
+# 2026-06-25 — Synthese : CD prod, SMTP reel, durcissement borne, POS comptoir/drive, dashboard stock (#94-#105)
+
+**Auteur : BYAN.** Retrospective de synthese couvrant douze PR mergees apres la session
+du 2026-06-18 (front login + amorce P4 commande). Elles se regroupent en quatre fils :
+mise en production reelle (#94-#97), finition du parcours borne client (#98, #99, #101,
+#102, #103), et refonte de la saisie comptoir/drive et de la page stock cote back-office
+(#100, #104, #105). Entree descriptive : on decrit ce qui est livre, pas ce qui est
+promis.
+
+---
+
+## Ce qui a ete livre (PR mergees)
+
+| PR | Bloc | Objet |
+|----|------|-------|
+| #94 | CD | Deploiement push-based vers Vision (prod) + preuve de version dans `GET /api/health` |
+| #95 | CD | Modeles versionnes `docker-compose.prod.yml.example` + `.env.prod.example` |
+| #96 | Auth | Envoi reel de l'email de reset via relais SMTP (Brevo) — client SMTP maison |
+| #97 | CD | Passage des variables SMTP/MAIL au conteneur `wakdo-app` (correctif #96) |
+| #98 | Borne | Menu Maxi agrandit la boisson en 50cl + transport du format choisi |
+| #99 | Borne | Produit/menu en rupture de stock rendu non commandable (RG-T21) |
+| #100 | Back-office | Refonte saisie comptoir/drive : prix, verrou du mode, navigation, file |
+| #101 | Borne | Panier unique = panneau persistant (retrait de `cart.html` et `product.html`) |
+| #102 | Borne | Confirmation avant l'abandon de la commande |
+| #103 | Borne | Bascule des allergenes sur `/api/allergens` + menage des donnees/docs statiques |
+| #104 | Back-office | Saisie comptoir/drive en POS tactile a tuiles (refonte de #100) |
+| #105 | Back-office | Page Stock en tableau de bord (alertes + reapprovisionnement en avant) |
+
+---
+
+## Bloc 1 — Mise en production reelle (#94, #95, #96, #97)
+
+### Ce qui a ete fait
+- **CD push-based (#94)** : `.forgejo/workflows/deploy.yml` ouvre, sur push `main`, une
+  session SSH vers Vision (l'hote de prod). `scripts/deploy.sh` y recupere `main` en
+  fast-forward, ecrit un marqueur de version (`src/VERSION` : SHA + date), journalise une
+  ligne dans `deploy.log`, puis reconstruit et recree la stack. `GET /api/health` expose
+  desormais `version` et `deployed_at`, lus depuis ce marqueur : c'est la preuve cote app
+  qu'un deploiement a bien repris le dernier commit. Doc : `docs/architecture/deployment.md`.
+- **Modeles de prod versionnes (#95)** : `docker-compose.prod.yml.example` et
+  `.env.prod.example` entrent au depot comme gabarits. Le fichier reel reste gitignore
+  (specifique a l'hote : Traefik, reseau externe), conformement a ADR-0009 ; le `.example`
+  documente la forme attendue.
+- **SMTP reel (#96, #97)** : la reinitialisation de mot de passe envoyait jusque-la un mail
+  inerte. Un client SMTP maison (`SmtpClient`, `SmtpMailer`, transport via flux PHP
+  `StreamSmtpTransport` derriere l'interface `SmtpTransport`) parle a un relais reel
+  (Brevo en l'occurrence). `PasswordResetController` s'y branche. #97 corrige un oubli :
+  les variables SMTP/MAIL n'etaient pas transmises au conteneur `wakdo-app` (declarees
+  dans les deux fichiers compose).
+
+### Pourquoi — decisions et alternatives
+- **Decision : CD par SSH, pas par Docker-in-CI.** Le runner Forgejo (sur Stark) n'a pas
+  acces au socket Docker, par choix de securite : un job CI ne pilote pas Docker sur son
+  hote. Le deploiement vers Vision se fait donc par SSH avec une *forced command* cote
+  serveur. *Alternative ecartee* : donner le socket Docker au runner — rejetee pour la
+  surface d'attaque. C'est le prolongement de la decision E2E-CI du 2026-06-18 (meme
+  contrainte de socket).
+- **Decision : client SMTP maison plutot qu'une bibliotheque.** ADR-0001 fige le projet
+  sans Composer ni dependance tierce ; un client SMTP minimal (EHLO/AUTH/MAIL/RCPT/DATA
+  sur flux) reste coherent avec cette contrainte et reste testable via un faux transport
+  (`FakeSmtpTransport`). *Alternative ecartee* : `mail()` de PHP — sans relais
+  authentifie, la delivrabilite est aleatoire et la configuration sort du depot.
+- **Decision : marqueur de version dans `src/VERSION` lu a chaud.** Le marqueur est sous
+  le mount du code (`./src` -> `/var/www/html`), donc relu sans rebuild. Cela donne une
+  preuve de deploiement observable de l'exterieur sans instrumentation supplementaire.
+
+### Criteres RNCP couverts
+- **Bloc 3 - deploiement** : chaine de livraison continue tracable (`deploy.yml`,
+  `deploy.sh`, `deployment.md`), preuve de version exposee.
+- **Bloc 1 - securite** : separation runner/prod sans socket Docker ; secrets de prod
+  hors du depot (gabarits `.example` seulement).
+
+---
+
+## Bloc 2 — Finition du parcours borne client (#98, #99, #101, #102, #103)
+
+### Ce qui a ete fait
+- **Menu Maxi -> boisson 50cl (#98)** : choisir le format Maxi d'un menu fait passer la
+  boisson de 33cl a 50cl. La migration `0007_product_size_variant` et le seed
+  `0006_drink_maxi_variant` portent la variante en base ; le format choisi est transporte
+  jusqu'au paiement (`checkout.js`, `page-product-menu.js`). Tests `OrderRepository` +
+  tests JS du composeur.
+- **Rupture non commandable (#99, RG-T21)** : un produit (ou un menu dont un composant
+  requis) sous le seuil critique de stock est marque indisponible et non ajoutable a la
+  borne ; le serveur refuse aussi la creation cote `OrderRepository` (defense en
+  profondeur, le client n'est pas seul juge). Visuel d'indisponibilite cote `style.css`.
+- **Panier unique = panneau persistant (#101)** : suppression des pages `cart.html` et
+  `product.html` ; le panier devient un panneau lateral persistant (`order-panel.js`)
+  present sur les pages au lieu d'une page dediee. Le net du diff est negatif
+  (-784 lignes) : c'est une simplification de l'architecture front borne.
+- **Confirmation d'abandon (#102)** : abandonner la commande ouvre une modale de
+  confirmation (`confirm-modal.js`) au lieu de vider le panier au premier clic.
+- **Allergenes via API (#103)** : la borne lisait des fichiers JSON statiques
+  (`allergens.json`, `categories.json`, `produits.json`) ; elle consomme desormais
+  `/api/allergens` (et le catalogue par API). Les JSON statiques et la doc afferente sont
+  retires (menage). `docs/api/conventions.md` et `docs/design/maquette-vs-build.md` mis a
+  jour.
+
+### Pourquoi — decisions et alternatives
+- **Decision : rupture controlee cote serveur ET cote client (#99).** L'indisponibilite
+  est calculee au plus pres de la verite (RG-T21, ADR-0003) ; le client la reflete pour
+  l'UX, mais `OrderRepository` revalide a la creation. *Alternative ecartee* : masquer
+  cote client seulement — laisse une fenetre ou une commande forgee passerait.
+- **Decision : panier persistant plutot que page panier (#101).** Sur une borne, l'aller-
+  retour vers une page panier ajoute une etape ; un panneau visible en permanence reduit
+  la navigation. Le retrait de deux pages reduit aussi la surface a maintenir.
+- **Decision : source de verite unique pour les donnees borne (#103).** Les JSON statiques
+  dupliquaient le catalogue de la base ; ils pouvaient diverger silencieusement. Passer par
+  l'API supprime la duplication et fait converger borne et back-office sur le meme modele.
+
+### Criteres RNCP couverts
+- **Bloc 2 - front client** : parcours borne complet (composeur, panier, abandon,
+  indisponibilite) sur donnees reelles par API.
+- **Bloc 1 - regles metier** : RG-T21 (disponibilite calculee) appliquee de bout en bout.
+
+---
+
+## Bloc 3 — Saisie comptoir/drive en POS tactile (#100 puis #104)
+
+### Ce qui a ete fait
+- **#100** a d'abord refondu la saisie comptoir/drive en tant que formulaire enrichi :
+  prix affiches, verrou du mode de service au canal drive, navigation, file des commandes
+  recentes. `CounterOrderController` derive la `source` (counter/drive) du chemin de la
+  requete ; ajout de la liste des commandes recentes par canal.
+- **#104** a ensuite remplace ce formulaire-liste par un **POS tactile a tuiles** facon
+  borne : onglets categories en haut, grille de tuiles produits/menus, panneau commande
+  persistant a droite. Pense pour la tablette (grandes cibles, un tap = ajout). Le panier
+  est construit cote client (`counter-order.js`, CSP `'self'`, vanilla, zero handler
+  inline) a partir d'un script JSON inerte, puis serialise dans un champ cache
+  `items_json`. Le serveur revalide la forme (RG-T18), recalcule les prix (RG-T16) et
+  resout les modificateurs : les prix cote client sont indicatifs.
+
+### Pourquoi — decisions et alternatives
+- **Decision : POS a tuiles, reutilisant l'UX borne (#104).** Cf. ADR-0011. L'equipier
+  comptoir et le client borne font le meme geste (choisir des produits, composer) ; un
+  meme paradigme tuiles+panneau reduit l'apprentissage et reutilise les patterns deja
+  eprouves. *Alternative ecartee* : garder le formulaire-liste (#100) — moins adapte au
+  tactile et a la rapidite attendue d'une caisse.
+- **Decision : serveur seul juge des prix et de la composition.** Le client propose, le
+  serveur fige (RG-T16). Coherent avec le reste du domaine commande.
+- **Decision : un controleur pour deux canaux, source derivee du chemin.** Le decoupage
+  par chemin (`/drive...` vs `/counter...`) plutot que par parametre rend les deux canaux
+  etanches : un equipier ne peut pas requalifier sa commande en falsifiant un champ.
+
+### Comment — points techniques cles
+- `CounterOrderController` : `source()` lue depuis le chemin ; `store()` decode
+  `items_json`, revalide, delegue a `createStaffOrder` (commande creee directement `paid`,
+  encaissement immediat, sans PIN — la permission `order.create` suffit). Repli legacy
+  `qty_<id>` accepte quand `items_json` est absent (degradation sans JS).
+- `counter-order.js` : construction des onglets/grille/panneau, modale de composition pour
+  produits a modificateurs et menus, serialisation a la soumission.
+
+### Criteres RNCP couverts
+- **Bloc 2 - back-office** : ecran de caisse pour equipiers non-techniques (zero jargon),
+  CSP-safe sans framework front.
+- **Bloc 1 - regles metier** : recalcul/revalidation serveur (RG-T16, RG-T18), etancheite
+  des canaux.
+
+---
+
+## Bloc 4 — Page Stock en tableau de bord (#105)
+
+### Ce qui a ete fait
+La page d'accueil Ingredients/Stock, jugee trop chargee et opaque, est refondue en
+tableau de bord. Elle porte desormais : un bandeau expliquant le lien stock ->
+disponibilite borne (un ingredient requis sous le seuil critique rend indisponibles les
+produits qui l'utilisent, RG-T21) ; un resume comptant les ingredients critiques / en
+alerte / au-dessus du seuil ; une section "A reapprovisionner" mettant en avant les
+ingredients bas (critiques d'abord) avec barre de niveau et bouton de reapprovisionnement
+direct. La liste complete passe au second plan et le CRUD est relegue. Les sous-pages
+(reappro, inventaire, mouvements, creation) restent inchangees. `index()` expose des
+compteurs par etat, calcules cote serveur a partir de `stock_band` deja resolu par le
+depot, pour garder la vue declarative et la valeur testable.
+
+### Pourquoi — decisions et alternatives
+Cf. ADR-0012. **Decision : dashboard oriente action plutot que liste-CRUD.** Le metier
+quotidien d'un equipier stock est de voir vite ce qui manque et de reapprovisionner, pas
+d'editer des fiches. Mettre les alertes et le bouton de reappro en avant aligne l'ecran
+sur ce geste. *Alternative ecartee* : garder une liste exhaustive triable — exhaustive
+mais muette sur l'urgence.
+
+### Criteres RNCP couverts
+- **Bloc 2 - back-office** : ergonomie orientee tache pour utilisateur non-technique.
+- **Bloc 1 - regles metier** : lien stock -> disponibilite (RG-T21) rendu explicite a
+  l'ecran.
+
+---
+
+## Verifications
+A la cloture du lot : suite JS 135 tests verte (verifiee en local), suites PHPUnit et PHPStan niveau 6 vertes en CI Forgejo,
+`php -l` propre. Chaque PR est passee par la CI Forgejo (checks requis) avant merge natif.
+
+## Points d'amelioration conscients
+- **#100 puis #104** : la refonte POS (#104) remplace une premiere refonte (#100) du meme
+  ecran a quelques jours d'intervalle. Le formulaire enrichi de #100 a servi de palier
+  avant le pivot tactile ; l'iteration est assumee plutot que masquee.
+- **SMTP** : le client maison couvre le cas d'usage reset (un destinataire, texte). Il
+  n'est pas un agent mail generaliste ; tout besoin plus large (pieces jointes, files)
+  serait a reevaluer.
+
+## Liens vers artefacts
+- Commits : `8c5d942` (#94) -> `03ef99d` (#105).
+- ADR associes : `docs/adr/0011-pos-tactile-tuiles-comptoir-drive.md`,
+  `docs/adr/0012-page-stock-tableau-de-bord.md`.
+- Fichiers principaux : `.forgejo/workflows/deploy.yml`, `scripts/deploy.sh`,
+  `src/app/Controllers/HealthController.php`, `src/app/Auth/SmtpClient.php`,
+  `src/app/Controllers/CounterOrderController.php`,
+  `src/public/admin/assets/js/counter-order.js`,
+  `src/app/Controllers/IngredientController.php`,
+  `src/app/Views/admin/ingredients/index.php`.

docs/journal/README.md

@@ -33,8 +33,13 @@ Les fichiers sont ordonnes chronologiquement par leur nom.
 | 2026-06-04 | [conception-prodlike-revision](2026-06-04--conception-prodlike-revision.md) | Revue d'alignement P1 + decisions prod-like du modele de donnees (drop commande_event, nommage EN, TVA par produit apres fact-check BOFiP, perso menus/ingredients, allergenes, ~16 entites) | `feat/p1-conception` |
 | 2026-06-15 | [p3-throttle-pin-rg-t22](2026-06-15--p3-throttle-pin-rg-t22.md) | P3 securite : throttle du PIN d'action sensible (RG-T22) — design multi-agents + verification adversariale, dimension "utilisateur agissant", entite 22 `pin_throttle` | `feat/p3-pin-throttle` -> `dev` |
 | 2026-06-16 | [audit-reel-livrables-p2-p3](2026-06-16--audit-reel-livrables-p2-p3.md) | Verification sur pieces des livrables du 2026-06-15 (sweep 10 dimensions + adversarial) : socle SbD confirme, miss confirmes par gravite (php.ini non deploye, CI sans tests DB, XSS kiosk, liens morts...) et remediations | `docs/journal-audit-2026-06-16` -> `dev` (PR #19/#20/#21) |
+| 2026-06-04 | [p1-merise-v0.2-rewrite-and-forgejo-migration](2026-06-04--p1-merise-v0.2-rewrite-and-forgejo-migration.md) | P1 Merise v0.2 (prod-like) reecrit + migration vers Forgejo auto-heberge | `feat/p1-conception` |
+| 2026-06-17 | [makefile-to-compose-migrate](2026-06-17--makefile-to-compose-migrate.md) | Du Makefile a `docker compose up` : service one-shot `wakdo-migrate` (migrate + seed idempotents) | `feat/compose-migrate` -> `dev` |
+| 2026-06-17 | [session-infra-doc-e2e](2026-06-17--session-infra-doc-e2e.md) | Session infra compose, documentation Forge, amorce des tests E2E Playwright | `dev` (PR #37/#38/#39 et suivantes) |
+| 2026-06-18 | [front-login-ui-admin-p4-commande](2026-06-18--front-login-ui-admin-p4-commande.md) | Page login, refonte UI admin (equipiers non-techniques), humanisation des libelles, amorce P4 commande (creation + encaissement) | `dev` (PR #48 a #58) |
+| 2026-06-25 | [audit-remediation-et-features-94-105](2026-06-25--audit-remediation-et-features-94-105.md) | Synthese #94-#105 : CD push-based vers Vision + preuve de version, modeles compose prod, SMTP reel reset (Brevo), durcissement borne (Maxi 50cl, rupture non commandable, panier persistant, confirm abandon, allergenes /api), POS tactile comptoir/drive, page Stock en tableau de bord | `dev`/`main` (PR #94 a #105) |
 
-*Mis a jour a chaque nouvelle entree.*
+*Mis a jour a chaque nouvelle entree. Les entrees sont ordonnees par leur nom de fichier (date) ; cet index les liste dans l'ordre de redaction.*
 
 ---
 

docs/merise/_diagrams/mcd-catalogue.mmd

@@ -13,6 +13,9 @@ erDiagram
         varchar name
         text description
         int price_cents
+        int maxi_variant_product_id FK
+        smallint size_cl
+        int base_product_id FK
         smallint vat_rate
         varchar image_path
         tinyint is_available
@@ -46,6 +49,8 @@ erDiagram
     category ||--o{ product : "groups"
     category ||--o{ menu : "groups"
     menu ||--|| product : "anchors (burger_product_id)"
+    product ||--o{ product : "maxi_variant (maxi_variant_product_id)"
+    product ||--o{ product : "size_variant_of (base_product_id)"
     menu ||--o{ menu_slot : "defines_slot"
     menu_slot ||--o{ menu_slot_option : "lists"
     product ||--o{ menu_slot_option : "is_eligible_for"

docs/merise/_diagrams/mcd-ingredients-stock.mmd

@@ -11,6 +11,9 @@ erDiagram
         int stock_capacity
         smallint pack_size
         varchar pack_label
+        smallint energy_kcal_100g
+        varchar nutrition_source
+        datetime nutrition_fetched_at
         smallint low_stock_pct
         smallint critical_stock_pct
         tinyint is_active

docs/merise/_diagrams/mcd-order.mmd

@@ -6,6 +6,7 @@ erDiagram
         enum source
         int acting_user_id FK
         enum service_mode
+        varchar service_tag
         enum status
         int total_ht_cents
         int total_vat_cents

docs/merise/_diagrams/mld-catalogue.mmd

@@ -11,6 +11,9 @@ erDiagram
         int category_id FK
         varchar name
         int price_cents
+        int maxi_variant_product_id FK
+        smallint size_cl
+        int base_product_id FK
         smallint vat_rate
         tinyint is_available
         smallint display_order
@@ -41,6 +44,8 @@ erDiagram
     category ||--o{ product : "category_id (RESTRICT)"
     category ||--o{ menu : "category_id (RESTRICT)"
     product ||--o{ menu : "burger_product_id (RESTRICT)"
+    product ||--o{ product : "maxi_variant_product_id (SET NULL)"
+    product ||--o{ product : "base_product_id (CASCADE)"
     menu ||--o{ menu_slot : "menu_id (CASCADE)"
     menu_slot ||--o{ menu_slot_option : "menu_slot_id (CASCADE)"
     product ||--o{ menu_slot_option : "product_id (RESTRICT)"

docs/merise/_diagrams/mld-ingredients-stock.mmd

@@ -6,6 +6,9 @@ erDiagram
         int stock_quantity
         int stock_capacity
         smallint pack_size
+        smallint energy_kcal_100g
+        varchar nutrition_source
+        datetime nutrition_fetched_at
         smallint low_stock_pct
         smallint critical_stock_pct
         tinyint is_active

docs/merise/_diagrams/mld-order.mmd

@@ -6,6 +6,7 @@ erDiagram
         enum source
         int acting_user_id FK
         enum service_mode
+        varchar service_tag
         enum status
         int total_ht_cents
         int total_vat_cents

docs/merise/dictionary.md

@@ -4,7 +4,7 @@
 **Version** : v0.3 — prod-like, 22 entites (19 prod-like + couche security-by-design, incl. les entites `login_throttle` et `pin_throttle`)
 **Date** : 2026-06-04 (ajouts security-by-design 2026-06-11)
 **Branche** : `feat/p1-conception`
-**Statut** : prod-like — toutes les decisions D1-D8 + stock appliquees (voir `docs/notes/revue-alignement-p1.md` §7) ; couche security-by-design en cours (voir note 13)
+**Statut** : prod-like — toutes les decisions D1-D8 + stock appliquees (voir `docs/notes/revue-alignement-p1.md` §7) ; couche security-by-design en cours (voir note 13) ; colonnes additives post-v0.3 des migrations 0003/0005/0006/0007 alignees sur le deploye (voir note 14)
 **Auteur** : BYAN (couche methodologie)
 
 ---
@@ -114,6 +114,9 @@ Un article vendable unique, disponible a la carte ou comme composant dans un slo
 | `name` | VARCHAR(120) | NO | — | INDEX | `nom` | renomme depuis `nom` |
 | `description` | TEXT | YES | NULL | — | (ajoute) | renseigne plus tard via l'admin |
 | `price_cents` | INT UNSIGNED | NO | — | CHECK > 0 | `prix` (FLOAT) | conversion FLOAT -> INT centimes au seed (voir note 1) |
+| `maxi_variant_product_id` | INT UNSIGNED | YES | NULL | FK -> `product(id)`, ON DELETE SET NULL | (migration 0006) | auto-reference : variante servie quand un menu est commande au format Maxi (ex. Moyenne Frite -> Grande Frite). Data-driven (la regle vit dans la donnee). SET NULL = degradation gracieuse : si la variante Grande est retiree du catalogue, le produit de base reste vendable, il perd seulement sa substitution Maxi. Voir note 14 |
+| `size_cl` | SMALLINT UNSIGNED | YES | NULL | — | (migration 0007) | variante de TAILLE a la carte : volume en centilitres d'une boisson fontaine (ex. 30 / 50 cl). NULL = produit sans dimension taille (bouteille, non-boisson). La ligne de base ET la variante portent leur volume pour l'affichage du picker. Voir note 14 |
+| `base_product_id` | INT UNSIGNED | YES | NULL | FK -> `product(id)`, ON DELETE CASCADE | (migration 0007) | auto-reference vers la ligne de base d'une variante de taille. NULL = produit de base ou autonome (visible dans la grille catalogue) ; NON NULL = variante de taille (masquee de la grille, atteinte via le picker). CASCADE : une variante de taille n'a pas de sens sans sa base (suppression de la base -> suppression de ses variantes). Voir note 14 |
 | `vat_rate` | SMALLINT UNSIGNED | NO | 100 | CHECK IN (55, 100) | (ajoute) | taux de TVA en pour-mille : 100 = 10%, 55 = 5,5%. Defaut 10%. Voir note 9 |
 | `image_path` | VARCHAR(255) | YES | NULL | — | `image` | chemin relatif, voir note 8 |
 | `is_available` | TINYINT(1) | NO | 1 | — | (ajoute) | bascule de disponibilite manuelle depuis l'admin |
@@ -197,6 +200,9 @@ Ingredient elementaire utilise dans la composition des produits. Porte les donne
 | `stock_capacity` | INT | NO | — | CHECK > 0 | niveau "plein" de reference en unites = les 100% servant a calculer le pourcentage de stock. Le `CHECK > 0` protege aussi la division du pourcentage contre la division par zero |
 | `pack_size` | SMALLINT UNSIGNED | NO | 1 | CHECK > 0 | unites par pack de reapprovisionnement (ex. 100 pour un sac de 100 portions) |
 | `pack_label` | VARCHAR(80) | YES | NULL | — | libelle humain du pack (ex. "Sac 100 portions") |
+| `energy_kcal_100g` | SMALLINT UNSIGNED | YES | NULL | — | enrichissement nutritionnel (migration 0005) : apport energetique pour 100 g, importe depuis l'API externe OpenFoodFacts (Cr 3.a.3). Nullable : un ingredient non enrichi reste valide. Voir note 14 |
+| `nutrition_source` | VARCHAR(120) | YES | NULL | — | enrichissement nutritionnel (migration 0005) : provenance de la donnee (ex. "OpenFoodFacts"). Voir note 14 |
+| `nutrition_fetched_at` | DATETIME | YES | NULL | — | enrichissement nutritionnel (migration 0005) : horodatage de l'import, pour tracer la fraicheur. Voir note 14 |
 | `low_stock_pct` | SMALLINT UNSIGNED | NO | 10 | CHECK BETWEEN 0 AND 100 | bande d’alerte, pourcentage de capacite : `stock_quantity <= stock_capacity * low_stock_pct/100` declenche l'indicateur de stock bas |
 | `critical_stock_pct` | SMALLINT UNSIGNED | NO | 5 | CHECK BETWEEN 0 AND 100 | seuil de rupture automatique, pourcentage de capacite : `stock_quantity <= stock_capacity * critical_stock_pct/100` rend le produit calcule en rupture |
 | `is_active` | TINYINT(1) | NO | 1 | — | desactiver les ingredients obsoletes sans supprimer |
@@ -281,11 +287,12 @@ Transaction client : 1 commande = 1 panier valide a un instant donne.
 | Attribut | Type | NULL | Default | Contrainte | Notes |
 |---|---|---|---|---|---|
 | `id` | INT UNSIGNED | NO | AUTO_INCREMENT | PK | |
-| `order_number` | VARCHAR(20) | NO | — | UNIQUE | format lisible par l'humain : `K`/`C`/`D`-YYYY-MM-DD-NNN. Prefixe par canal : K=kiosk, C=counter, D=drive. Voir note 4. |
+| `order_number` | VARCHAR(20) | NO | — | UNIQUE | numero lisible : prefixe canal + id sequentiel, soit `K<id>` / `C<id>` / `D<id>` (K=kiosk, C=counter, D=drive). Ecrit en deux temps (INSERT puis UPDATE avec `LAST_INSERT_ID()`). Voir note 4. |
 | `idempotency_key` | VARCHAR(36) | YES | NULL | UNIQUE | UUID genere par le client pour dedupliquer un `POST /api/orders` reessaye (anti-double-charge). UNIQUE rejette les doublons ; plusieurs NULL autorises. Security-by-design, voir note 13 |
 | `source` | ENUM('kiosk','counter','drive') | NO | — | INDEX | canal de saisie (qui a saisi la commande). Valeurs en anglais, voir note 5. |
 | `acting_user_id` | INT UNSIGNED | YES | NULL | FK -> `user(id)`, ON DELETE SET NULL | personnel back-office (counter/drive) ayant cree la commande, capture sous PIN. NULL pour `kiosk` (anonyme). Imputabilite ciblee sans imposer un login par personne sur la borne. Voir note 13 |
 | `service_mode` | ENUM('dine_in','takeaway','drive') | NO | — | — | mode de consommation, conserve pour les stats/KPI uniquement. Aucun role fiscal (voir note 9). La source `drive` implique le service_mode `drive` (contrainte croisee appliquee au niveau applicatif). |
+| `service_tag` | VARCHAR(20) | YES | NULL | — | numero de chevalet pour le service EN SALLE (migration 0003), saisi a la borne quand le client choisit `dine_in` ; permet d'apporter la commande a la bonne table (B4). NULL pour `takeaway` / `drive`. Voir note 14 |
 | `status` | ENUM('pending_payment','paid','delivered','cancelled') | NO | 'pending_payment' | INDEX | machine a 4 etats : `pending_payment -> paid -> delivered` (+ `cancelled`). Voir note 6. |
 | `total_ht_cents` | INT UNSIGNED | NO | — | CHECK >= 0 | total hors TVA, snapshot a la validation de la commande |
 | `total_vat_cents` | INT UNSIGNED | NO | — | CHECK >= 0 | montant de TVA, snapshot |
@@ -687,15 +694,28 @@ et evite tous les conflits.
 `order_item` est conserve comme nom de table de ligne : `item` n'est pas reserve, et le
 prefixe `order_` rend claire la relation parent.
 
-### Note 4 — Prefixe de numero de commande par canal
+### Note 4 — Prefixe de numero de commande par canal (existant : prefixe + id)
 
-Format : `K`/`C`/`D`-YYYY-MM-DD-NNN (kiosk / counter / drive).
+Format reel (decision utilisateur) : prefixe canal + id de la commande, soit `K<id>` / `C<id>` /
+`D<id>` (kiosk / counter / drive). Implemente dans `src/app/Order/OrderRepository.php` : la commande
+est inseree avec un `order_number` provisoire vide, puis l'`order_number` est ecrit en `prefix .
+LAST_INSERT_ID()` (ex. `K42`, `C7`, `D13`).
 
-Rationale : le prefixe encode le canal, ce qui est utile pour une identification visuelle rapide
+Rationale : le prefixe encode le canal, utile pour une identification visuelle rapide par le personnel
-par le personnel cuisine et comptoir sans interroger la colonne `source`. Le compteur sequentiel NNN
+cuisine et comptoir sans interroger la colonne `source`. Le suffixe est l'id sequentiel auto-incremente :
-repart chaque jour par canal. Sans collision sur une journee, vu le volume attendu.
+pas de compteur quotidien a tenir ni de `service_day` a gerer cote numerotation (rasoir d'Ockham,
+mantra #37).
 
-Alternative rejetee : prefixe neutre `W-` pour tous les canaux (plus simple, mais perd la lisibilite
+Ecart assume avec la cible v0.x initiale `K-AAAA-MM-JJ-NNN` (compteur journalier par canal) :
+cette derniere n'a pas ete retenue a l'implementation, jugee plus lourde sans valeur metier
+proportionnelle pour le volume attendu. La forme acte ici est celle qui tourne.
+
+Compromis connu : un numero `prefixe + id` est sequentiel, donc devinable (un client peut incrementer
+l'id). Couple a l'endpoint de paiement anonyme cote borne (lecture/encaissement par `order_number`
+sans authentification), c'est une surface a surveiller. Piste d'amelioration : numero non sequentiel
+(ex. suffixe aleatoire court) si le suivi anonyme par numero devait s'ouvrir davantage.
+
+Alternative rejetee : prefixe neutre `W` pour tous les canaux (plus simple, mais perd la lisibilite
 du canal pour le personnel).
 
 ### Note 5 — `source` vs `service_mode` (canal vs mode de consommation)
@@ -910,6 +930,49 @@ est un backoff degressif aux bornes propres (PIN_THROTTLE_*). Meme purge cron qu
 References : `docs/notes/revue-alignement-p1.md` §7 (decisions D), carte d'impact security-by-design
 (2026-06-11). Modele de menace et matrice de classification des donnees : `PROJECT_CONTEXT.md` §19 (a venir).
 
+### Note 14 — Colonnes additives post-v0.3 (migrations 0003 / 0005 / 0006 / 0007)
+
+Ces colonnes etendent le schema apres v0.3 par des migrations purement additives (ajout de colonnes
+nullables et de FK auto-referentes ; aucune donnee existante a retro-remplir, aucune table nouvelle).
+Le runner applique les `*.sql` dans l'ordre lexicographique via `schema_migrations`. Elles sont alignees
+ici sur le schema reellement deploye.
+
+**Migration 0003 — `customer_order.service_tag` VARCHAR(20) NULL (AFTER service_mode).** Numero de
+chevalet pour le service en salle (mode `dine_in`), saisi a la borne ; NULL pour `takeaway` / `drive`.
+Permet d'apporter la commande a la bonne table (B4). Entite 3.10.
+
+**Migration 0005 — enrichissement nutritionnel de `ingredient` (AFTER pack_label).**
+`energy_kcal_100g` SMALLINT UNSIGNED NULL, `nutrition_source` VARCHAR(120) NULL,
+`nutrition_fetched_at` DATETIME NULL. Donnees importees depuis l'API externe OpenFoodFacts (Cr 3.a.3 :
+exploitation d'informations externes dans le modele de donnees). Opt-in et egress maitrise : aucun appel
+automatique au runtime borne ; la passerelle (`App\Catalogue\OpenFoodFactsGateway`) est invoquee seulement
+par `IngredientController::enrich` (action explicite manager/admin). Toutes nullables : un ingredient non
+enrichi reste valide. Entite 3.6.
+
+**Migration 0006 — `product.maxi_variant_product_id` INT UNSIGNED NULL, FK -> `product(id)` ON DELETE
+SET NULL (AFTER price_cents).** Auto-reference : variante servie quand un menu est commande au format
+Maxi (ex. Moyenne Frite -> Grande Frite), substituee cote serveur dans `OrderRepository::resolveSelections`
+sans choix supplementaire. Approche data-driven (la regle vit dans la donnee, pas dans le code), et le
+decrement de stock frappe alors le bon produit. SET NULL plutot que RESTRICT : si la variante Grande est
+supprimee du catalogue, le produit de base reste vendable et perd seulement sa substitution Maxi
+(degradation gracieuse) ; la reference est un confort metier, pas une integrite forte de commande (les
+commandes figent deja leurs snapshots). Entite 3.2.
+
+**Migration 0007 — variante de TAILLE de `product` (AFTER price_cents).** `size_cl` SMALLINT UNSIGNED
+NULL, `base_product_id` INT UNSIGNED NULL avec FK -> `product(id)` ON DELETE CASCADE. La dimension taille
+des boissons fontaine (la maquette borne propose 30 / 50 cl) est modelisee en lignes produit distinctes
+(meme approche que Moyenne/Grande Frite) : le domaine commande facture deja par `product_id`, le flux reste
+inchange, la borne resout la taille choisie en `product_id`. `base_product_id` NULL = produit de base ou
+autonome (visible dans la grille catalogue) ; NON NULL = variante de taille (masquee de la grille, atteinte
+via le picker). CASCADE plutot que SET NULL (a la difference de 0006) : une variante de taille n'a aucun
+sens sans sa base (une "Coca Cola 50 cl" orpheline n'est pas commercialisable), donc supprimer la base
+emporte ses variantes de taille. Les deux groupings coexistent sur une boisson sans se confondre :
+`base_product_id` pilote la selection de taille a la carte (picker 30/50 cl) ; `maxi_variant_product_id`
+(0006) pilote la substitution Maxi en menu. Entite 3.2.
+
+References : `db/migrations/0003_order_service_tag.sql`, `0005_ingredient_nutrition.sql`,
+`0006_product_maxi_variant.sql`, `0007_product_size_variant.sql`.
+
 ---
 
 ## 5. Synthese du decompte des entites

docs/merise/mcd.md

@@ -111,6 +111,9 @@ erDiagram
         varchar name
         text description
         int price_cents
+        int maxi_variant_product_id FK
+        smallint size_cl
+        int base_product_id FK
         smallint vat_rate
         varchar image_path
         tinyint is_available
@@ -144,6 +147,8 @@ erDiagram
     category ||--o{ product : "groups"
     category ||--o{ menu : "groups"
     menu ||--|| product : "anchors (burger_product_id)"
+    product ||--o{ product : "maxi_variant (maxi_variant_product_id)"
+    product ||--o{ product : "size_variant_of (base_product_id)"
     menu ||--o{ menu_slot : "defines_slot"
     menu_slot ||--o{ menu_slot_option : "lists"
     product ||--o{ menu_slot_option : "is_eligible_for"
@@ -159,6 +164,8 @@ erDiagram
 | C4 | defines_slot | menu | (1,N) | menu_slot | (1,1) | Un menu doit definir au moins un slot (boisson, accompagnement, sauce) pour avoir une composition personnalisable. Un slot appartient a exactement un menu. |
 | C5 | lists | menu_slot | (1,N) | menu_slot_option | (1,1) | Un slot doit lister au moins un produit eligible (sinon le client ne peut pas le remplir). Chaque ligne d'option appartient a exactement un slot. |
 | C6 | is_eligible_for | product | (0,N) | menu_slot_option | (1,1) | Un produit peut etre eligible pour un nombre quelconque de slots a travers tous les menus, ou aucun s'il n'est vendu qu'a la carte. Chaque ligne d'option reference exactement un produit. |
+| C7 | maxi_variant (migration 0006) | product (base) | (0,1) | product (variante Maxi) | (0,N) | Auto-reference : un produit pointe vers 0 ou 1 variante servie en menu Maxi (`maxi_variant_product_id`, nullable) ; un produit peut etre la variante Maxi de plusieurs autres. ON DELETE SET NULL (degradation gracieuse). |
+| C8 | size_variant_of (migration 0007) | product (base) | (0,N) | product (variante de taille) | (0,1) | Auto-reference : une variante de taille pointe vers sa ligne de base (`base_product_id`, nullable ; NULL = base/autonome) ; un produit de base peut avoir plusieurs variantes de taille (30/50 cl). ON DELETE CASCADE (une variante de taille n'a pas de sens sans sa base). |
 
 ### 4.3 Notes sur le sous-domaine Catalogue
 
@@ -168,6 +175,8 @@ erDiagram
 
 **Format Normal / Maxi** : deux prix (`price_normal_cents`, `price_maxi_cents`) sur `menu` ; format enregistre au niveau de `order_item.format`. Aucun differentiel de prix au niveau du slot individuel n'est stocke (voir note 7 du dictionnaire).
 
+**Variantes de produit (migrations 0006 / 0007, voir note 14 du dictionnaire)** : deux auto-references sur `product`, distinctes par leur role et leur comportement `ON DELETE`. `maxi_variant_product_id` (SET NULL) designe la variante servie quand un menu est commande au format Maxi (ex. Moyenne Frite -> Grande Frite), substituee cote serveur. `size_cl` + `base_product_id` (CASCADE) modelisent une variante de TAILLE a la carte (boisson 30/50 cl) en lignes produit : `base_product_id` NULL = produit de base/autonome visible au catalogue, NON NULL = variante masquee de la grille et atteinte via le picker. Les deux groupings coexistent sur une boisson sans se confondre.
+
 ---
 
 ## 5. Sous-domaine : Ingredients & Stock
@@ -188,6 +197,9 @@ erDiagram
         int stock_capacity
         smallint pack_size
         varchar pack_label
+        smallint energy_kcal_100g
+        varchar nutrition_source
+        datetime nutrition_fetched_at
         smallint low_stock_pct
         smallint critical_stock_pct
         tinyint is_active
@@ -262,6 +274,8 @@ erDiagram
 
 **Disponibilite produit calculee (regle RG-T21, voir `mlt.md`)** : la commandabilite effective est derivee, pas stockee. Un produit est commandable quand `product.is_available = 1` ET que chaque ingredient non retirable (`is_removable = 0`) de son `product_ingredient` a `stock_quantity > stock_capacity * critical_stock_pct / 100`. Un ingredient requis atteignant la bande critique met le produit en rupture automatique sans ecriture et sans cascade ; un retrait manuel (`product.is_available = 0`) est une surcharge forte ; un reapprovisionnement au-dessus de la bande critique rend le produit commandable a nouveau de lui-meme. Un ingredient retirable/optionnel a la bande critique ne bloque pas le produit (seul son supplement devient indisponible). Le tableau de bord distingue un retrait manuel d'une rupture pilotee par le stock.
 
+**Enrichissement nutritionnel (migration 0005, voir note 14 du dictionnaire)** : `energy_kcal_100g`, `nutrition_source` et `nutrition_fetched_at` (toutes nullables) stockent une donnee importee depuis l'API externe OpenFoodFacts (Cr 3.a.3 : exploitation d'informations externes dans le modele de donnees). Opt-in : l'import est declenche par `IngredientController::enrich` (action manager/admin), pas au runtime borne ; un ingredient non enrichi reste valide.
+
 ---
 
 ## 6. Sous-domaine : Order
@@ -277,6 +291,7 @@ erDiagram
         enum source
         int acting_user_id FK
         enum service_mode
+        varchar service_tag
         enum status
         int total_ht_cents
         int total_vat_cents
@@ -382,6 +397,11 @@ enregistre l'employe de comptoir/drive qui a pris la commande sous PIN ; NULL po
 Cela ajoute une association `customer_order |o--o| user : "taken_by"` (cardinalite : une commande est
 prise par (0,1) user ; un user prend (0,N) commandes). Voir note 13 du dictionnaire.
 
+**Numero de commande (existant) et service en salle (migration 0003)** : `order_number` est un attribut
+non cle (UNIQUE) de forme `prefixe canal + id` (`K<id>` / `C<id>` / `D<id>`) ; pas une association. Voir
+note 4 du dictionnaire. `service_tag` (VARCHAR(20), nullable) porte le numero de chevalet du service en
+salle (mode `dine_in`), saisi a la borne ; NULL pour `takeaway` / `drive`. Voir note 14 du dictionnaire.
+
 ---
 
 ## 7. Sous-domaine : RBAC
@@ -580,7 +600,7 @@ Le MCD reste au niveau conceptuel. Les decisions suivantes sont reportees au MLD
    des PK composites.
 2. **PK technique vs identifiant metier** : `id INT UNSIGNED AUTO_INCREMENT` sur toutes les entites principales.
    `customer_order` porte en plus `order_number VARCHAR(20) UNIQUE` (lisible par un humain,
-   format `K/C/D-YYYY-MM-DD-NNN` par canal).
+   format prefixe canal + id : `K<id>` / `C<id>` / `D<id>`).
 3. **Regles ON DELETE** : CASCADE vs RESTRICT vs SET NULL. Detaillees dans le MLD.
 4. **Contraintes CHECK** : exclusivite de polymorphisme sur `order_item`, contrainte croisee
    `source/service_mode` sur `customer_order`, invariant arithmetique sur les totaux.

docs/merise/mct.md

@@ -143,7 +143,7 @@ Pour chaque operation, le document fournit :
 | **Synchronisation** | AND (les deux actions requises) |
 | **Condition** | Le panier contient au moins 1 article. Le numero de commande saisi est non vide. |
 | **Operation** | CREATE_ORDER |
-| **Description** | Creation atomique de la commande : INSERT `customer_order` avec statut `pending_payment`, source `kiosk`, snapshot des totaux HT/TVA/TTC (calcules ligne par ligne en utilisant `vat_rate` snapshote par article). INSERT des lignes `order_item` avec `label_snapshot`, `unit_price_cents_snapshot`, `vat_rate_snapshot`. INSERT `order_item_selection` pour chaque slot rempli dans un article de menu. INSERT `order_item_modifier` pour chaque modification d'ingredient. Decrement de `ingredient.stock_quantity` pour chaque ingredient consomme (ajuste par les modificateurs : retrait => pas de decrement ; ajout => decrement supplementaire) ; INSERT d'une ligne `stock_movement` de type `sale` par unite d'ingredient affectee. Les decrements de stock et l'insertion de la commande sont dans la meme transaction. Apres que le client a saisi son numero de commande, le statut passe `pending_payment -> paid` dans la meme transaction ; `paid_at` est positionne. Le systeme genere le numero de commande au format `K-YYYY-MM-DD-NNN`. |
+| **Description** | Creation atomique de la commande : INSERT `customer_order` avec statut `pending_payment`, source `kiosk`, snapshot des totaux HT/TVA/TTC (calcules ligne par ligne en utilisant `vat_rate` snapshote par article). INSERT des lignes `order_item` avec `label_snapshot`, `unit_price_cents_snapshot`, `vat_rate_snapshot`. INSERT `order_item_selection` pour chaque slot rempli dans un article de menu. INSERT `order_item_modifier` pour chaque modification d'ingredient. Decrement de `ingredient.stock_quantity` pour chaque ingredient consomme (ajuste par les modificateurs : retrait => pas de decrement ; ajout => decrement supplementaire) ; INSERT d'une ligne `stock_movement` de type `sale` par unite d'ingredient affectee. Les decrements de stock et l'insertion de la commande sont dans la meme transaction. Apres que le client a saisi son numero de commande, le statut passe `pending_payment -> paid` dans la meme transaction ; `paid_at` est positionne. Le systeme genere le numero de commande au format prefixe canal + id (`K<id>`, voir dictionnaire note 4). |
 | **Entites MCD** | R: `product`, `menu`, `ingredient`, `product_ingredient` (snapshot) — W: `customer_order` (INSERT status `pending_payment` then UPDATE status `paid`, `paid_at`), `order_item` (INSERT N lines), `order_item_selection` (INSERT per menu slot chosen), `order_item_modifier` (INSERT per modification), `ingredient` (UPDATE stock_quantity), `stock_movement` (INSERT type `sale` per unit) |
 | **Resultat** | Commande creee (statut `paid` en fin d'operation), numero de commande affiche au client, evenement logique ORDER_CREATED emis vers le domaine de preparation |
 
@@ -175,7 +175,7 @@ Pour chaque operation, le document fournit :
 | **Synchronisation** | Aucune |
 | **Condition** | L'acteur est authentifie et detient la permission `order.create`. La `source` est `counter` ou `drive` (auto-taggee depuis `role.order_source`). |
 | **Operation** | CREATE_COUNTER_ORDER |
-| **Description** | Composition manuelle de la commande via le back-office : selectionner produits et menus, choisir le mode de service (`dine_in`/`takeaway`/`drive`), remplir les slots de menu, ajouter des modificateurs d'ingredient. Logique de creation identique a CREATE_ORDER (snapshot, decrement de stock dans la meme transaction, transition atomique `pending_payment -> paid`). La `source` est auto-taggee depuis `role.order_source` (counter -> `counter`, drive -> `drive`). Format du numero de commande : `C-YYYY-MM-DD-NNN` (comptoir) ou `D-YYYY-MM-DD-NNN` (drive). Contrainte croisee : si `source = 'drive'` alors `service_mode = 'drive'` (verifie a la creation). |
+| **Description** | Composition manuelle de la commande via le back-office : selectionner produits et menus, choisir le mode de service (`dine_in`/`takeaway`/`drive`), remplir les slots de menu, ajouter des modificateurs d'ingredient. Logique de creation identique a CREATE_ORDER (snapshot, decrement de stock dans la meme transaction, transition atomique `pending_payment -> paid`). La `source` est auto-taggee depuis `role.order_source` (counter -> `counter`, drive -> `drive`). Format du numero de commande : prefixe canal + id (`C<id>` comptoir, `D<id>` drive). Contrainte croisee : si `source = 'drive'` alors `service_mode = 'drive'` (verifie a la creation). |
 | **Entites MCD** | R: `product`, `menu`, `menu_slot`, `menu_slot_option`, `ingredient`, `product_ingredient` — W: `customer_order` (INSERT status `pending_payment` then UPDATE status `paid`, `paid_at`), `order_item`, `order_item_selection`, `order_item_modifier`, `ingredient` (stock decrement), `stock_movement` (INSERT type `sale`) |
 | **Resultat** | Commande creee (statut `paid`), numero de commande communique au client |
 

docs/merise/mld.md

@@ -125,6 +125,9 @@ erDiagram
         int category_id FK
         varchar name
         int price_cents
+        int maxi_variant_product_id FK
+        smallint size_cl
+        int base_product_id FK
         smallint vat_rate
         tinyint is_available
         smallint display_order
@@ -155,6 +158,8 @@ erDiagram
     category ||--o{ product : "category_id (RESTRICT)"
     category ||--o{ menu : "category_id (RESTRICT)"
     product ||--o{ menu : "burger_product_id (RESTRICT)"
+    product ||--o{ product : "maxi_variant_product_id (SET NULL)"
+    product ||--o{ product : "base_product_id (CASCADE)"
     menu ||--o{ menu_slot : "menu_id (CASCADE)"
     menu_slot ||--o{ menu_slot_option : "menu_slot_id (CASCADE)"
     product ||--o{ menu_slot_option : "product_id (RESTRICT)"
@@ -171,6 +176,9 @@ erDiagram
         int stock_quantity
         int stock_capacity
         smallint pack_size
+        smallint energy_kcal_100g
+        varchar nutrition_source
+        datetime nutrition_fetched_at
         smallint low_stock_pct
         smallint critical_stock_pct
         tinyint is_active
@@ -235,6 +243,7 @@ erDiagram
         enum source
         int acting_user_id FK
         enum service_mode
+        varchar service_tag
         enum status
         int total_ht_cents
         int total_vat_cents
@@ -410,11 +419,14 @@ Pas de FK. Table racine du sous-domaine Catalogue.
 ### 4.2 `product`
 
 ```
-product (id, #category_id, name, [description], price_cents, vat_rate,
+product (id, #category_id, name, [description], price_cents,
+         [#maxi_variant_product_id], [size_cl], [#base_product_id], vat_rate,
          [image_path], is_available, display_order, created_at, updated_at)
 
   PK  : id
   FK  : category_id             -> category(id) ON DELETE RESTRICT
+  FK  : maxi_variant_product_id -> product(id)  ON DELETE SET NULL
+  FK  : base_product_id         -> product(id)  ON DELETE CASCADE
   IDX : (category_id, is_available, display_order)
   CHK : price_cents > 0
   CHK : vat_rate IN (55, 100)
@@ -427,6 +439,9 @@ product (id, #category_id, name, [description], price_cents, vat_rate,
 | `name` | VARCHAR(120) | NO | Libelle du produit |
 | `description` | TEXT | YES | Description longue optionnelle |
 | `price_cents` | INT UNSIGNED | NO | Prix a la carte, TVA incluse, en centimes |
+| `maxi_variant_product_id` | INT UNSIGNED | YES | FK -> product (auto-reference), ON DELETE SET NULL ; variante servie en menu Maxi (migration 0006, voir note de table) |
+| `size_cl` | SMALLINT UNSIGNED | YES | Volume en cl d'une variante de taille de boisson ; NULL si pas de dimension taille (migration 0007) |
+| `base_product_id` | INT UNSIGNED | YES | FK -> product (auto-reference), ON DELETE CASCADE ; ligne de base d'une variante de taille, NULL = base/autonome (migration 0007) |
 | `vat_rate` | SMALLINT UNSIGNED | NO | Pour-mille : 100 = 10%, 55 = 5.5% |
 | `image_path` | VARCHAR(255) | YES | Chemin relatif depuis la racine publique |
 | `is_available` | TINYINT(1) NOT NULL DEFAULT 1 | NO | Bascule de disponibilite manuelle |
@@ -437,6 +452,19 @@ product (id, #category_id, name, [description], price_cents, vat_rate,
 **ON DELETE RESTRICT** sur `category_id` : une categorie avec des produits ne peut pas etre supprimee. Empeche les
 produits orphelins.
 
+**Auto-references de variante (migrations 0006 / 0007, voir note 14 du dictionnaire)** : deux groupings
+distincts, tous deux pointant vers `product(id)`.
+- `maxi_variant_product_id` (ON DELETE SET NULL) : variante servie quand un menu est commande au format
+  Maxi (ex. Moyenne Frite -> Grande Frite). SET NULL = degradation gracieuse, le produit de base reste
+  vendable si la variante Grande est supprimee.
+- `size_cl` + `base_product_id` (ON DELETE CASCADE) : variante de TAILLE a la carte (boisson 30/50 cl)
+  modelisee en lignes produit. `base_product_id` NULL = produit de base/autonome (visible catalogue) ;
+  NON NULL = variante de taille (masquee de la grille, atteinte via le picker). CASCADE car une variante
+  de taille n'a pas de sens sans sa base.
+
+Les deux coexistent sur une boisson sans se confondre : `base_product_id` pilote la selection de taille a
+la carte ; `maxi_variant_product_id` pilote la substitution Maxi en menu.
+
 ---
 
 ### 4.3 `menu`
@@ -529,6 +557,7 @@ Pas d'horodatages. Table de jointure pure.
 
 ```
 ingredient (id, name, unit, stock_quantity, stock_capacity, pack_size, [pack_label],
+            [energy_kcal_100g], [nutrition_source], [nutrition_fetched_at],
             low_stock_pct, critical_stock_pct, is_active, created_at, updated_at)
 
   PK  : id
@@ -549,6 +578,9 @@ ingredient (id, name, unit, stock_quantity, stock_capacity, pack_size, [pack_lab
 | `stock_capacity` | INT NOT NULL | NO | Niveau "plein" de reference en unites = le 100% utilise pour calculer le pourcentage de stock ; CHECK > 0 protege aussi la division du pourcentage contre la division par zero |
 | `pack_size` | SMALLINT UNSIGNED NOT NULL DEFAULT 1 | NO | Unites par lot de reapprovisionnement |
 | `pack_label` | VARCHAR(80) | YES | Libelle humain du lot |
+| `energy_kcal_100g` | SMALLINT UNSIGNED | YES | Apport energetique pour 100 g, importe depuis l'API externe OpenFoodFacts (migration 0005) |
+| `nutrition_source` | VARCHAR(120) | YES | Provenance de la donnee nutritionnelle, ex. "OpenFoodFacts" (migration 0005) |
+| `nutrition_fetched_at` | DATETIME | YES | Horodatage de l'import nutritionnel, trace la fraicheur (migration 0005) |
 | `low_stock_pct` | SMALLINT UNSIGNED NOT NULL DEFAULT 10 | NO | Bande d’alerte, pourcentage de la capacite (CHECK BETWEEN 0 AND 100) |
 | `critical_stock_pct` | SMALLINT UNSIGNED NOT NULL DEFAULT 5 | NO | Plancher de rupture automatique, pourcentage de la capacite (CHECK BETWEEN 0 AND 100 ; CHECK de table `critical_stock_pct < low_stock_pct`) |
 | `is_active` | TINYINT(1) NOT NULL DEFAULT 1 | NO | Desactiver les ingredients obsoletes |
@@ -577,6 +609,11 @@ bloque pas le produit (seul son supplement devient indisponible). Le tableau de
 retrait manuel (`is_available=0`) d'une rupture pilotee par le stock (`is_available=1` mais un ingredient
 requis est critique).
 
+**Enrichissement nutritionnel (migration 0005, voir note 14 du dictionnaire)** : `energy_kcal_100g`,
+`nutrition_source` et `nutrition_fetched_at` (toutes nullables) stockent une donnee importee depuis l'API
+externe OpenFoodFacts (Cr 3.a.3). Opt-in : l'import est declenche par `IngredientController::enrich`
+(action manager/admin), pas au runtime borne ; un ingredient non enrichi reste valide.
+
 ---
 
 ### 4.7 `product_ingredient`
@@ -811,7 +848,7 @@ Pas d'horodatages. Table de jointure pure.
 
 ```
 customer_order (id, order_number, [idempotency_key], source, [#acting_user_id],
-                service_mode, status,
+                service_mode, [service_tag], status,
                 total_ht_cents, total_vat_cents, total_ttc_cents,
                 [paid_at], [delivered_at], [cancelled_at],
                 created_at, updated_at)
@@ -833,11 +870,12 @@ customer_order (id, order_number, [idempotency_key], source, [#acting_user_id],
 | Colonne | Type | NULL | Notes |
 |---|---|---|---|
 | `id` | INT UNSIGNED AUTO_INCREMENT | NO | PK |
-| `order_number` | VARCHAR(20) | NO | Format `K/C/D-YYYY-MM-DD-NNN` par canal |
+| `order_number` | VARCHAR(20) | NO | Prefixe canal + id sequentiel : `K<id>`/`C<id>`/`D<id>` (existant, voir note de table) |
 | `idempotency_key` | VARCHAR(36) | YES | UUID client, UNIQUE ; deduplique un POST reessaye (security-by-design) |
 | `source` | ENUM('kiosk','counter','drive') | NO | Canal de saisie |
 | `acting_user_id` | INT UNSIGNED | YES | FK -> user ; personnel counter/drive sous PIN ; NULL pour kiosk |
 | `service_mode` | ENUM('dine_in','takeaway','drive') | NO | Mode de consommation (stats uniquement, pas de role fiscal) |
+| `service_tag` | VARCHAR(20) | YES | Numero de chevalet du service en salle (`dine_in`), saisi a la borne ; NULL pour takeaway/drive (migration 0003) |
 | `status` | ENUM('pending_payment','paid','delivered','cancelled') NOT NULL DEFAULT 'pending_payment' | NO | Machine a 4 etats |
 | `total_ht_cents` | INT UNSIGNED | NO | Snapshot du total HT |
 | `total_vat_cents` | INT UNSIGNED | NO | Snapshot du montant de TVA |
@@ -848,6 +886,17 @@ customer_order (id, order_number, [idempotency_key], source, [#acting_user_id],
 | `created_at` | DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP | NO | Utilise comme base de `service_day` |
 | `updated_at` | DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP | NO | Audit |
 
+**Numero de commande (existant, voir note 4 du dictionnaire)** : `order_number` = prefixe canal + id
+sequentiel (`K<id>` / `C<id>` / `D<id>`), ecrit en deux temps (INSERT avec numero provisoire vide, puis
+UPDATE en `prefix . LAST_INSERT_ID()`) dans `OrderRepository`. La cible initiale `K-AAAA-MM-JJ-NNN`
+(compteur journalier) n'a pas ete retenue : la forme `prefixe + id` evite un compteur quotidien. Compromis
+connu : numero sequentiel donc devinable, couple a l'endpoint de paiement anonyme cote borne (piste
+d'amelioration : numero non sequentiel).
+
+**Service en salle (migration 0003)** : `service_tag` (VARCHAR(20), nullable) porte le numero de chevalet
+saisi a la borne pour le mode `dine_in` ; NULL pour `takeaway` / `drive`. Colonne additive, sans contrainte
+de BD (la coherence avec `service_mode` est appliquee au niveau applicatif).
+
 **Attribution du personnel (security-by-design)** : `acting_user_id` (FK -> `user`, ON DELETE SET NULL)
 enregistre le personnel counter/drive qui a pris la commande sous PIN ; NULL pour les commandes kiosk anonymes.
 Les commandes kiosk restent anonymes par conception. `stock_movement.user_id` couvre l'attribution des actions
@@ -1235,11 +1284,11 @@ et que toutes les tables se rattachent au MCD.
 | Entite MCD | Table MLD | Type de mapping | Notes |
 |---|---|---|---|
 | `category` (C1) | `category` (4.1) | entite 1:1 | |
-| `product` (C2) | `product` (4.2) | entite 1:1 | |
+| `product` (C2) | `product` (4.2) | entite 1:1 | Additif post-v0.3 : `maxi_variant_product_id` (0006), `size_cl` + `base_product_id` (0007) |
 | `menu` (C3) | `menu` (4.3) | entite 1:1 | Nouveau : `burger_product_id`, `price_normal_cents`, `price_maxi_cents` |
 | `menu_slot` (C4) | `menu_slot` (4.4) | entite 1:1 | Nouvelle entite (v0.2) |
 | `menu_slot_option` (C5) | `menu_slot_option` (4.5) | Table de jointure (PK composite) | Nouvelle entite (v0.2) |
-| `ingredient` (C6) | `ingredient` (4.6) | entite 1:1 | Nouvelle entite (v0.2) |
+| `ingredient` (C6) | `ingredient` (4.6) | entite 1:1 | Nouvelle entite (v0.2) ; additif post-v0.3 : `energy_kcal_100g`, `nutrition_source`, `nutrition_fetched_at` (0005) |
 | `product_ingredient` (C7) | `product_ingredient` (4.7) | Table de jointure avec attributs | Nouvelle entite (v0.2) |
 | `allergen` (C8) | `allergen` (4.8) | entite 1:1 | Nouvelle entite (v0.2) |
 | `ingredient_allergen` (C9) | `ingredient_allergen` (4.9) | Table de jointure (PK composite) | Nouvelle entite (v0.2) |
@@ -1248,7 +1297,7 @@ et que toutes les tables se rattachent au MCD.
 | `role_visible_source` (C12) | `role_visible_source` (4.12) | Table de jointure (PK composite) | Nouvelle entite (v0.2) |
 | `permission` (C13) | `permission` (4.13) | entite 1:1 | |
 | `role_permission` (C14) | `role_permission` (4.14) | Table de jointure (PK composite) | |
-| `customer_order` (C15) | `customer_order` (4.15) | entite 1:1 | Renommee depuis `commande` ; machine a 4 etats ; horodatages de phase |
+| `customer_order` (C15) | `customer_order` (4.15) | entite 1:1 | Renommee depuis `commande` ; machine a 4 etats ; horodatages de phase ; additif post-v0.3 : `service_tag` (0003) |
 | `order_item` (C16) | `order_item` (4.16) | entite 1:1 | Nouveau : `format`, `vat_rate_snapshot` ; CHECK de polymorphisme |
 | `order_item_selection` (C17) | `order_item_selection` (4.17) | entite 1:1 | Nouvelle entite (v0.2) |
 | `order_item_modifier` (C18) | `order_item_modifier` (4.18) | entite 1:1 | Nouvelle entite (v0.2) |

docs/merise/mlt.md

@@ -115,7 +115,7 @@ Ces regles s'appliquent a plusieurs operations et sont centralisees ici pour evi
 | **[PRE-3]** | Le corps JSON du POST est valide (validation de schema a la couche API) |
 | **[RG-1]** | Verification de disponibilite cote serveur : pour chaque article, verifier `product.is_available = 1` ou `menu.is_available = 1`. Si un article est indisponible, rejeter avec la liste des articles indisponibles. |
 | **[RG-2 — service_day]** | Le `service_day` d'une commande donnee est calcule a l'execution de la requete comme : `CASE WHEN HOUR(created_at) < 10 THEN DATE(created_at) - INTERVAL 1 DAY ELSE DATE(created_at) END`. La coupure est a 10:00. Ce n'est PAS stocke comme colonne — calcule uniquement a l'execution de la requete. La formule v0.1 avec `INTERVAL 4 HOUR 30 MINUTE` etait incorrecte et est abandonnee. |
-| **[RG-3 — order number]** | Format du numero de commande : `K-YYYY-MM-DD-NNN` ou NNN est le compteur sequentiel pour le service_day courant pour la source `kiosk` (SELECT COUNT + 1 avec un verrou au niveau table ou un insert serialise pour eviter une generation en double sous concurrence). La source est `kiosk` (definie par l'endpoint kiosk, derivee du point d'entree public). |
+| **[RG-3 — order number]** | Format du numero de commande : prefixe canal + id auto-incremente, soit `K<id>` pour la source `kiosk` (ex. `K42`). Genere en deux temps dans la transaction : INSERT avec `order_number` provisoire vide, puis UPDATE `prefix . LAST_INSERT_ID()`. Pas de compteur par service_day (voir dictionnaire note 4). La source est `kiosk` (derivee de l'endpoint public). Le numero provisoire vide partage avant l'UPDATE reste une surface de robustesse a durcir sous forte concurrence (suivi au backlog). |
 | **[RG-4 — VAT by line]** | Pour chaque `order_item` : `vat_rate_snapshot` est copie depuis `product.vat_rate`. Montants de ligne : `unit_ttc = unit_price_cents_snapshot` ; `unit_ht = ROUND(unit_ttc * 1000 / (1000 + vat_rate_snapshot))` ; `unit_vat = unit_ttc - unit_ht`. Totaux de commande : `total_ttc_cents = SUM(unit_ttc * quantity)` sur toutes les lignes ; `total_ht_cents = SUM(unit_ht * quantity)` ; `total_vat_cents = total_ttc_cents - total_ht_cents`. Invariant : `total_ttc_cents = total_ht_cents + total_vat_cents` (verifie avant l'INSERT). |
 | **[RG-5 — atomic transaction]** | Toutes les ecritures dans une seule transaction de base de donnees : (1) INSERT `customer_order` (status `pending_payment`, source `kiosk`, service_mode depuis le panier, totaux calcules) ; (2) INSERT des lignes `order_item` (label_snapshot, unit_price_cents_snapshot, vat_rate_snapshot, quantity, format, item_type, product_id ou menu_id) ; (3) INSERT des lignes `order_item_selection` pour chaque slot rempli dans un article menu (order_item_id, menu_slot_id, product_id, label_snapshot) ; (4) INSERT des lignes `order_item_modifier` pour chaque modification d'ingredient (order_item_id, ingredient_id, action, extra_price_cents snapshot) ; (5) pour chaque ingredient consomme : calculer units = `(order_item.format = 'maxi' ? product_ingredient.quantity_maxi : product_ingredient.quantity_normal) * order_item.quantity`, ajuste par les modificateurs (remove => pas de decrement pour cet ingredient ; add => decrement supplementaire) ; appliquer le decrement atomique `UPDATE ingredient SET stock_quantity = stock_quantity - :units WHERE id = :id` (instruction unique auto-verrouillante, sans lecture-gate prealable, RG-T20) ; `stock_quantity` est signe et peut devenir negatif (ampleur de survente, remontee aux managers) — le decrement ne se conditionne pas a un plancher ; INSERT `stock_movement` (type `sale`, delta = -units, order_id, user_id = NULL pour le kiosk) ; (6) UPDATE `customer_order` SET status = `paid`, `paid_at = NOW()`. Les six etapes committent ensemble ou sont entierement annulees. |
 | **[RG-6 — cross-constraint]** | La source `kiosk` n'implique aucune contrainte particuliere de service_mode ; le client selectionne `dine_in` ou `takeaway`. La contrainte croisee drive (RG-T09) ne s'applique pas aux commandes provenant du kiosk. |
@@ -163,7 +163,7 @@ Ces regles s'appliquent a plusieurs operations et sont centralisees ici pour evi
 | **[PRE-3]** | Le panier contient au moins 1 article |
 | **[RG-1]** | Logique de creation identique a CREATE_ORDER (RG-1 a RG-7 s'appliquent), avec les differences suivantes : `source` est auto-tagguee depuis `role.order_source` (role comptoir -> `counter`, role drive -> `drive`) ; `service_mode` est selectionne par le membre du personnel (`dine_in` / `takeaway` / `drive`) ; `user_id` est defini a l'id de l'utilisateur authentifie dans les lignes `stock_movement` (au lieu de NULL pour le kiosk). |
 | **[RG-2 — cross-constraint]** | Si `source = 'drive'` alors `service_mode` doit etre `'drive'` (RG-T09) ; verifie avant l'INSERT. HTTP 422 si viole. |
-| **[RG-3 — order number]** | Format : `C-YYYY-MM-DD-NNN` pour la source comptoir ; `D-YYYY-MM-DD-NNN` pour la source drive. Le compteur sequentiel NNN est par source par service_day. |
+| **[RG-3 — order number]** | Format : prefixe canal + id auto-incremente, soit `C<id>` (comptoir) ou `D<id>` (drive). Meme generation en deux temps que CREATE_ORDER RG-3. Pas de compteur par service_day (voir dictionnaire note 4). |
 | **[RG-4 — stock]** | Meme logique de decrement de stock que CREATE_ORDER RG-5 ; `stock_movement.user_id` est defini a l'id du membre du personnel authentifie. |
 | **[RG-5 — staff attribution + decrement]** | `customer_order.acting_user_id` est defini a l'id du membre du personnel authentifie (imputabilite ciblee sur les commandes comptoir/drive ; les commandes kiosk restent NULL). La re-validation des modificateurs cote serveur (3.3 RG-9), l'idempotence (RG-T19) et le decrement de stock atomique (RG-T20) s'appliquent a l'identique. Aucun PIN n'est requis pour creer une commande (la permission `order.create` suffit) ; la creation de commande n'est pas dans l'ensemble des actions sensibles. |
 | **[POST-1]** | Une ligne `customer_order` avec `status = 'paid'`, `source = 'counter'` ou `'drive'`, `paid_at` defini, `acting_user_id` defini. |

docs/uml/use-cases.md

@@ -211,7 +211,7 @@ flowchart LR
 
 | Cas | Operation MCT | Permission | Description | Entites |
 |---|---|---|---|---|
-| Saisir une commande comptoir/drive | 4.1 CREATE_COUNTER_ORDER | `order.create` | Composer une commande pour un client au comptoir (`counter`) ou au drive (`drive`). Logique identique a CREATE_ORDER ; `source` auto-tague depuis `role.order_source`. Numero `C-`/`D-YYYY-MM-DD-NNN`. | `customer_order`, `order_item`, `order_item_selection`, `order_item_modifier`, `ingredient`, `stock_movement` |
+| Saisir une commande comptoir/drive | 4.1 CREATE_COUNTER_ORDER | `order.create` | Composer une commande pour un client au comptoir (`counter`) ou au drive (`drive`). Logique identique a CREATE_ORDER ; `source` auto-tague depuis `role.order_source`. Numero prefixe canal + id (`C<id>`/`D<id>`, voir dictionnaire note 4). | `customer_order`, `order_item`, `order_item_selection`, `order_item_modifier`, `ingredient`, `stock_movement` |
 | Consulter la file de preparation | 5.1 LIST_ORDERS_DISPLAY | `order.read` | Voir les commandes `paid` triees par `paid_at` croissant, filtrees par `role_visible_source` (counter voit kiosk+counter ; drive voit drive). Couleur KDS = `now - paid_at`. | `customer_order`, `order_item`, `order_item_selection`, `order_item_modifier`, `role_visible_source` |
 | Remettre la commande | 6.1 DELIVER_ORDER | `order.deliver` | Geste unique `paid -> delivered`, `delivered_at = NOW()`. | `customer_order` |
 | Annuler une commande | 7.1 CANCEL_ORDER | `order.cancel` | Transition vers `cancelled` depuis `pending_payment`/`paid`, `cancelled_at = NOW()`. Re-credit du stock si `paid`. | `customer_order`, `ingredient`, `stock_movement` |