import { z } from "zod";
import { MEALS, WEEK_DAYS } from "../types/planning.js";

// See schemas/auth.ts for the shared client/server validation rationale.

/**
 * Payload accepted by `GET /planning`'s `?date=` query param. Only checks
 * the `YYYY-MM-DD` *shape* — whether it's a real calendar date (e.g.
 * rejecting `2026-02-30`) is checked service-side via
 * `@batch-cooking/date-tools`'s `parseDateOnly`, not here: `packages/shared`
 * has no runtime dependencies of its own, and pulling in a date library just
 * for this one check isn't worth losing that.
 */
export const getPlanningByDateSchema = z.object({
  date: z.string().regex(/^\d{4}-\d{2}-\d{2}$/, "Date invalide"),
});
/** Inferred TS type for {@link getPlanningByDateSchema}'s validated output. */
export type GetPlanningByDateInput = z.infer<typeof getPlanningByDateSchema>;

/**
 * Payload accepted by `POST /planning/items` — adds a recipe to one
 * (day, meal) slot of the household's planning for the week containing
 * `date`, creating that week's `Planning` row on the fly if it doesn't
 * exist yet (see `planning.service.ts`'s `addPlanningItem`). `weekDay`/
 * `meal` are finally validated against a closed set here — until now
 * `WEEK_DAYS`/`MEALS` were only a documented convention (see their doc
 * comments in `types/planning.ts`), never enforced, since no write endpoint
 * existed yet.
 */
export const addPlanningItemSchema = z.object({
  date: z.string().regex(/^\d{4}-\d{2}-\d{2}$/, "Date invalide"),
  weekDay: z.enum(WEEK_DAYS),
  meal: z.enum(MEALS),
  recipeId: z.number().int().positive(),
  /** How many portions to prepare for this slot — a plain manual entry, see `PlanningItemView.portions`. */
  portions: z.number().int().positive("Le nombre de portions doit être positif"),
});
/** Inferred TS type for {@link addPlanningItemSchema}'s validated output. */
export type AddPlanningItemInput = z.infer<typeof addPlanningItemSchema>;
