feat(planning): attribution et jet des restes + exclusion liste de courses / cuisine #49

Merged

kyuno merged 1 commit from feat/leftovers-assign-discard into main

2026-09-06 00:08:09 +02:00

kyuno commented

2026-09-05 23:53:48 +02:00

Owner

Chantier « gestion des restes » (issue #34) — PR 2/4 : endpoints + exclusions. Toujours pas d'UI ; le panier arrive en PR 3.

Routes

Route	Service	Rôle
`POST /planning/items/leftover`	`assignLeftoverPlanningItem` (201)	Crée un item « restes » (`sourcePlanningItemId` non nul) sur `(date, weekDay, meal)`, même recette que la source — `recipeId` copié depuis `sourceItemId`, jamais dans le body. `portions` revérifié contre `computeAvailableLeftover` côté serveur.
`PATCH /planning/items/:id/discard-leftover`	`discardLeftover` (200)	`discardedPortions += pool disponible`. Idempotent : rien à jeter → item renvoyé inchangé, aucun évènement.

Erreurs : 409 LEFTOVER_QUANTITY_EXCEEDED (nouveau code 4024, plage 4020-4029) si portions dépasse le disponible ; 404 PLANNING_ITEM_NOT_FOUND si sourceItemId inconnu, d'un autre foyer, ou lui-même un item « restes » (pas de restes-sur-restes) — et pour discard-leftover, même garde que removePlanningItem.

Exclusion

shopping-list.service.ts et cooking-session.service.ts ajoutent items: { where: { sourcePlanningItemId: null } } à leur include Prisma — un créneau qui ne fait que resservir un plat déjà cuisiné n'a rien à acheter ni à cuisiner. Filtré à la requête, donc jamais atteint par aggregateShoppingList / toOptimizerRecipe. getPlanningForDate ne filtre pas : la grille du planning doit afficher ces items (badge « restes » en PR 4).

Divers

planning.leftover_assigned ({ recipeId, portions, sourceItemId }) et planning.leftover_discarded ({ recipeId, portions }) via analytics.recordEvent.
Le mapping PlanningItem → PlanningItemView est factorisé dans toPlanningItemView (4 chemins le partagent).
assignLeftoverSchema dans @batch-cooking/shared ; libellé errors.LEFTOVER_QUANTITY_EXCEEDED côté web.

Tests (Mocha, contre une vraie base)

assignLeftoverPlanningItem : succès + recipeId copié de la source ; 409 sur dépassement du pool ; 404 source d'un autre foyer / inconnue / elle-même « restes » ; suppression de la source → cascade sur les items « restes ».
discardLeftover : jette le disponible, idempotent, ne jette que ce qui n'a pas déjà été servi, 404 sur id inconnu.
Non-régression : GET /shopping-list (quantité inchangée malgré un item « restes ») et GET /cooking-session (le plan ne contient la recette qu'une fois).

build + lint verts localement ; suite Mocha en CI (pas de base locale ici).

🤖 Generated with Claude Code

**Chantier « gestion des restes » ([issue #34](https://git.dev.kyuno.fr/kyuno/batchCooking/issues/34)) — PR 2/4 : endpoints + exclusions.** Toujours pas d'UI ; le panier arrive en PR 3. ## Routes | Route | Service | Rôle | |---|---|---| | `POST /planning/items/leftover` | `assignLeftoverPlanningItem` (201) | Crée un item « restes » (`sourcePlanningItemId` non nul) sur `(date, weekDay, meal)`, **même recette que la source** — `recipeId` copié depuis `sourceItemId`, jamais dans le body. `portions` revérifié contre `computeAvailableLeftover` côté serveur. | | `PATCH /planning/items/:id/discard-leftover` | `discardLeftover` (200) | `discardedPortions += pool disponible`. Idempotent : rien à jeter → item renvoyé inchangé, aucun évènement. | Erreurs : **409 `LEFTOVER_QUANTITY_EXCEEDED`** (nouveau code `4024`, plage 4020-4029) si `portions` dépasse le disponible ; **404 `PLANNING_ITEM_NOT_FOUND`** si `sourceItemId` inconnu, d'un autre foyer, ou lui-même un item « restes » (pas de restes-sur-restes) — et pour `discard-leftover`, même garde que `removePlanningItem`. ## Exclusion `shopping-list.service.ts` et `cooking-session.service.ts` ajoutent `items: { where: { sourcePlanningItemId: null } }` à leur `include` Prisma — un créneau qui ne fait que resservir un plat déjà cuisiné n'a **rien à acheter ni à cuisiner**. Filtré à la requête, donc jamais atteint par `aggregateShoppingList` / `toOptimizerRecipe`. `getPlanningForDate` **ne** filtre pas : la grille du planning doit afficher ces items (badge « restes » en PR 4). ## Divers - `planning.leftover_assigned` (`{ recipeId, portions, sourceItemId }`) et `planning.leftover_discarded` (`{ recipeId, portions }`) via `analytics.recordEvent`. - Le mapping `PlanningItem → PlanningItemView` est factorisé dans `toPlanningItemView` (4 chemins le partagent). - `assignLeftoverSchema` dans `@batch-cooking/shared` ; libellé `errors.LEFTOVER_QUANTITY_EXCEEDED` côté web. ## Tests (Mocha, contre une vraie base) - `assignLeftoverPlanningItem` : succès + `recipeId` copié de la source ; 409 sur dépassement du pool ; 404 source d'un autre foyer / inconnue / elle-même « restes » ; suppression de la source → cascade sur les items « restes ». - `discardLeftover` : jette le disponible, idempotent, ne jette que ce qui n'a pas déjà été servi, 404 sur id inconnu. - Non-régression : `GET /shopping-list` (quantité inchangée malgré un item « restes ») et `GET /cooking-session` (le plan ne contient la recette qu'une fois). `build` + `lint` verts localement ; suite Mocha en CI (pas de base locale ici). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

kyuno added 1 commit 2026-09-05 23:53:49 +02:00

feat(planning): attribution et jet des restes + exclusion liste de courses / cuisine

CI / lint (push) Successful in 52s

Details

CI / build (push) Successful in 1m30s

Details

CI / e2e (push) Successful in 5m38s

Details

CI / intent-service-test (push) Successful in 3m32s

Details

CI / test (push) Successful in 14m17s

Details

1c62625c47

PR 2/4 du chantier « gestion des restes » (issue #34).

Deux nouvelles routes sur `/planning` :
- `POST /planning/items/leftover` → `assignLeftoverPlanningItem`, 201.
  Crée un item « restes » (`sourcePlanningItemId` non nul) sur un créneau,
  même recette que la source (`recipeId` copié, jamais envoyé par le
  client). `portions` revérifié serveur contre le pool réellement
  disponible via `computeAvailableLeftover` → 409
  `LEFTOVER_QUANTITY_EXCEEDED` (nouveau code, 4024) si dépassé ; 404
  `PLANNING_ITEM_NOT_FOUND` si source inconnue / d'un autre foyer / elle-
  même un item « restes » (pas de restes-sur-restes).
- `PATCH /planning/items/:id/discard-leftover` → `discardLeftover`, 200.
  Jette tout le pool restant (`discardedPortions += disponible`) ;
  idempotent (rien à jeter → renvoyé inchangé, aucun évènement).

Exclusion : `shopping-list.service.ts` et `cooking-session.service.ts`
filtrent `items: { where: { sourcePlanningItemId: null } }` dans leur
`include` — un créneau qui ne fait que resservir un plat déjà cuisiné n'a
rien à acheter ni à cuisiner. `getPlanningForDate` ne filtre pas (la
grille affiche ces items).

Analytics : `planning.leftover_assigned` / `planning.leftover_discarded`.

Le mapping `PlanningItem` → `PlanningItemView` est factorisé
(`toPlanningItemView`) — 4 chemins le partagent désormais.

Tests (Mocha, DB) : `assignLeftoverPlanningItem` (succès + `recipeId`
copié, 409 sur dépassement, 404 source étrangère/inconnue/« restes »,
cascade à la suppression de la source) ; `discardLeftover` (jette le
disponible, idempotent, ne jette pas ce qui est déjà servi, 404) ;
non-régression liste de courses et session de cuisine ignorant les items
« restes ».

Réf #34

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>