Add specs + Prisma schema for the documented data model (#3 )

* Add project specs, gitignore the source PDF

specs/batch-cooking-architecture.md and specs/batch-cooking-modele.md
are the clean markdown transcription of "Projet batch cooking.pdf"
(a scanned/image-only PDF, no extractable text). The PDF itself is
gitignored — source working document, not meant to be committed.

* Add Prisma schema for the documented data model

Models every table from specs/batch-cooking-modele.md: users/household
(user_profiles, house, diet, allergy, category), planning (planning,
planning_item), and recipes (recipe, ingredients, step, tech_step,
tech_step_mapping, sources).

Two deliberate deviations from the literal spec doc, per project
discussion:

- recipe_ingredient (recipe <-> ingredients) carries quantity + unit.
  The spec describes a plain many-to-many with no extra fields, but a
  shopping list / batch-cooking calculation needs quantities.
- step is modeled one-to-many from recipe (not many-to-many as labeled
  in the doc): the documented `order` column only makes sense scoped
  to a single recipe, which isn't reconcilable with steps being
  shared across recipes.

Everything else follows the doc as-is, including field nullability
choices made where the doc doesn't specify (e.g. user_profiles.house_id
optional, recipe.source_id optional) and onDelete behavior (Cascade
for owned child records, SetNull for optional references) — first
draft, not meant as final production hardening.

Verified: `prisma validate`, `prisma generate`, and a real
`prisma migrate dev` against a local Postgres (via docker-compose) —
the migration applies cleanly and produces the expected schema.

README: documents the migrate command and a Postgres port-conflict
gotcha hit during validation (a native Postgres service on this
machine was already bound to 5432, intercepting the Docker container's
connections).

* Add COMMENT ON for every table and column in the init migration

Descriptions pulled from specs/batch-cooking-modele.md's per-table
field tables. The two tables not in the original spec (join tables
recipe_ingredient, user_profile_allergy) get a comment explaining
why they exist.

Amends the still-unmerged init migration directly rather than adding
a follow-up migration, since it hasn't been applied anywhere but this
local dev database.

Verified: `prisma migrate reset --force` reapplies cleanly, and a
query against pg_description confirms every column of every project
table has a comment (only Prisma's own internal _prisma_migrations
table is uncommented, out of scope).

2026-08-16 12:23:59 +02:00

2 KiB

Raw Blame History

Architecture technique — Projet Batch-cooking

Documentation de l'architecture serveur/client de l'application.

Vue d'ensemble

L'application repose sur une architecture client-serveur classique :

Un serveur exposant une API (échanges standards) et un canal websocket (communication temps réel)
Plusieurs clients (Client 1, Client 2, Client 3...) connectés simultanément au serveur
Une base de données PostgreSQL

flowchart TB
  subgraph SERVER["Server"]
    WS["Web socket"]
    API["API"]
    CALC["Calcul batch-cooking<br/><i>(TODO)</i>"]
    IMPORT["Import d'une recette"]
    IMP1["Import depuis source"]
    IMP2["Traduction en étapes"]
    IMP3["Sauvegarde"]
    DB[("Database<br/>PostgreSQL")]

    IMPORT --> IMP1 --> IMP2 --> IMP3 --> DB
    CALC --> WS
  end

  C1["Client 1"]
  C2["Client 2"]
  C3["Client 3"]

  API <--> C1
  API <--> C2
  API <--> C3
  WS --> C1
  WS --> C2
  WS --> C3

  style SERVER fill:none,stroke:#888,stroke-width:1px

Composants

API

Point d'entrée principal pour les échanges entre les clients et le serveur (requêtes classiques).

Web socket

Canal de communication temps réel entre le serveur et les clients connectés.

Module « Calcul batch-cooking »

Logique de calcul du batch-cooking (optimisation du planning/des recettes selon le planning). Statut : TODO — reste à développer.

Module « Import d'une recette »

Pipeline d'ajout d'une recette, en trois étapes :

Import depuis source — récupération de la recette (via sources)
Traduction en étapes — découpage en step / tech_step
Sauvegarde — persistance en base de données

Database (PostgreSQL)

Stockage de l'ensemble des données de l'application (voir le modèle de données pour le détail des tables).

Notes

Le module de calcul batch-cooking est le principal chantier restant côté serveur (TODO).
Le websocket est utilisé pour la communication temps réel, en complément de l'API.

2 KiB Raw Blame History