Coeur pur du module "Calcul batch-cooking" (specs/batch-cooking-architecture.md, jusqu'ici TODO) : optimizeCookingPlan() prend les recettes planifiees d'une semaine et les reorganise en phases ordonnees. - Mutualisation de la mise en place : une meme technique de decoupe (chop, peel, mince...) appliquee au meme ingredient par >= 2 recettes est regroupee en une seule tache "merged-prep" (les oignons de plusieurs recettes = une decoupe). - Parallelisme : les cuissons passives (simmer, braise, bake, marinate...) sont poussees en tache de fond des phases suivantes pendant qu'une autre recette avance en actif. - Fonction pure sans base (meme split matchXxx pur / loadXxx DB-backed que ingredient-matcher / tech-step-matcher), testable en isolation. Types partages : OptimizedCookingPlanView + schema getCookingSessionSchema. Tests Mocha purs (6 cas) : merge, non-merge d'une decoupe solo, tache de fond, mise a l'echelle par portions, plan vide, legende. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
18 lines
879 B
TypeScript
18 lines
879 B
TypeScript
import { z } from "zod";
|
|
|
|
// See schemas/auth.ts for the shared client/server validation rationale.
|
|
|
|
/**
|
|
* Payload accepted by `GET /cooking-session`'s `?date=` query param — same
|
|
* shape/rationale as `schemas/shopping-list.ts`'s `getShoppingListSchema`
|
|
* (only the `YYYY-MM-DD` shape is checked here; real-calendar-date
|
|
* validation is service-side via `@batch-cooking/date-tools`'s
|
|
* `parseDateOnly`). Kept as its own schema rather than importing another
|
|
* module's near-identical one — each router owns its own request contract
|
|
* in this repo, even when two happen to share a shape.
|
|
*/
|
|
export const getCookingSessionSchema = z.object({
|
|
date: z.string().regex(/^\d{4}-\d{2}-\d{2}$/, "Date invalide"),
|
|
});
|
|
/** Inferred TS type for {@link getCookingSessionSchema}'s validated output. */
|
|
export type GetCookingSessionInput = z.infer<typeof getCookingSessionSchema>;
|