batchCooking/apps/api/test
Nicolas eba0ea70bd
All checks were successful
CI / lint (push) Successful in 2m37s
CI / intent-service-test (push) Successful in 4m26s
CI / test (push) Successful in 15m8s
CI / build (push) Successful in 2m45s
CI / e2e (push) Successful in 8m6s
feat(planning): sépare portions demandées et portions préparées
Première PR du chantier « gestion des restes » (issue #34) — les
fondations, sans encore d'UI de panier.

À l'ajout d'une recette au planning on ne saisit plus qu'un seul nombre,
`portionsRequested` (« combien ce créneau doit nourrir »). Le serveur en
dérive `portions` (ce qui est réellement préparé) via
`computeBatchedPortions` : arrondi au multiple supérieur du rendement de
la recette (on cuisine des lots entiers, jamais une fraction de plat).
L'écart est le futur pool de restes de l'item.

Modèle (`PlanningItem`, purement additif) :
- `portionsRequested` NOT NULL — migration nullable → backfill (`= portions`
  pour les lignes existantes, sans restes à l'époque) → verrou, même
  discipline que `ingredient_unit_catalog`.
- `sourcePlanningItemId` (auto-FK nullable, `onDelete: Cascade`) et
  `discardedPortions` (défaut 0) — posés maintenant, utilisés plus tard.

Partagé (`@batch-cooking/shared/logic/planning-portions.ts`) :
- `computeBatchedPortions(recipePortions, requested)` → `{ portions, leftover }`
- `computeAvailableLeftover(item)` → pool encore disponible (posé pour les
  PRs suivantes : validation d'écriture côté API, affichage du panier
  côté web — une seule formule, deux appelants)

API : `addPlanningItemSchema` prend `portionsRequested` ; `addPlanningItem`
calcule et stocke les deux valeurs + l'évènement analytics ; `PlanningItemView`
et `getPlanningForDate` exposent `portionsRequested`/`discardedPortions`/
`sourceItem`.

Front : `RecipePickerDialog` — champ « portions demandées » + indice en
direct « → N préparées, M en restes » quand l'arrondi crée un reste ;
envoie `portionsRequested`. `RecipeImportForm` — envoie `portionsRequested`
(un import atterrit à son propre rendement, donc reste nul).

Tests : `planning-portions.test.ts` (les deux exemples de #34 + bornes) ;
nouveau bloc `POST /planning/items` dans `planning.test.ts` (arrondi au
lot, plusieurs lots, borne exacte, 400 sur non-positif) ; fixtures
`planningItem.create` des suites existantes mises à jour ; scénario
Cypress planning ajusté (`portionsRequested` dans le corps).

Docs : `batch-cooking-modele.md`, `backend-architecture.md`,
`frontend-architecture.md`.

Réf #34

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-05 23:29:58 +02:00
..
internal feat(admin): pousse le monitoring en WebSocket au lieu du polling client 2026-09-05 14:44:39 +02:00
recipe feat(recipes): permet de corriger la température d'un tech-step 2026-09-04 23:53:14 +02:00
recipe-matching feat(cooking-session): regroupement d'étapes sensible aux métadonnées d'action 2026-09-03 12:05:44 +02:00
recipe-sources fix(recipes): stoppe le scroll infini des sources au lieu de boucler 2026-09-05 20:20:43 +02:00
sources fix(recipes): active le matching ingredients/unites pour les sources en francais (#72) 2026-08-22 20:34:32 +02:00
admin-auth.test.ts fix(admin): isole l'API admin sous /admin/api pour éviter la collision avec les pages front 2026-09-05 13:48:07 +02:00
admin-catalog-normalize.test.ts feat(recipes): permet d'ajouter des ingredients hors-catalogue 2026-08-28 23:36:42 +02:00
admin-catalog.test.ts fix(admin): isole l'API admin sous /admin/api pour éviter la collision avec les pages front 2026-09-05 13:48:07 +02:00
admin-metrics.test.ts fix(admin): isole l'API admin sous /admin/api pour éviter la collision avec les pages front 2026-09-05 13:48:07 +02:00
admin-monitoring-socket.test.ts fix(admin): ferme le serveur socket.io en fin de suite de test monitoring 2026-09-05 19:56:45 +02:00
admin-tech-steps.test.ts fix(admin): isole l'API admin sous /admin/api pour éviter la collision avec les pages front 2026-09-05 13:48:07 +02:00
auth.test.ts Tests API: couverture Mocha + Cucumber pour le foyer et la suppression de compte (step 4/8) 2026-08-17 10:40:23 +02:00
cooking-session.test.ts feat(planning): sépare portions demandées et portions préparées 2026-09-05 23:29:58 +02:00
health.test.ts Scaffold generic pnpm monorepo (api + web + shared) (#1) 2026-08-16 10:55:13 +02:00
house.test.ts fix: corrige les bugs ouverts du repo (import TheMealDB, sidebar mobile) + doc (#59) 2026-08-21 12:16:22 +02:00
logger.service.test.ts fix: corrige les bugs ouverts du repo (import TheMealDB, sidebar mobile) + doc (#59) 2026-08-21 12:16:22 +02:00
planning-portions.test.ts feat(planning): sépare portions demandées et portions préparées 2026-09-05 23:29:58 +02:00
planning.test.ts feat(planning): sépare portions demandées et portions préparées 2026-09-05 23:29:58 +02:00
preferences.test.ts API: module preferences — GET/PATCH /preferences (step 2/4) 2026-08-17 15:55:45 +02:00
profile.test.ts refactor(catalog): authoring 100% anglais — uid camelCase, plus de français dans le code 2026-08-19 20:40:55 +02:00
recipe-placeholder.test.ts feat(recipes): permet d'ajouter des ingredients hors-catalogue 2026-08-28 23:36:42 +02:00
recipe.test.ts feat(planning): sépare portions demandées et portions préparées 2026-09-05 23:29:58 +02:00
reference.test.ts fix(tests): corrige 3 suites Mocha DB revelees par leur 1er run sur main 2026-08-29 12:00:43 +02:00
shopping-list.test.ts feat(planning): sépare portions demandées et portions préparées 2026-09-05 23:29:58 +02:00