From c6553dc9a3768dc67ab86951c99f2411f6851d4d Mon Sep 17 00:00:00 2001 From: Nicolas Date: Fri, 21 Aug 2026 07:58:02 +0200 Subject: [PATCH] docs(readme): documente GET /planning?date=, plus /planning/current MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Le README documentait encore `GET /planning/current` (401 sans session, couvre "aujourd'hui"), une route qui n'existe plus — `planning.routes.ts` ne définit que `GET /planning?date=YYYY-MM-DD` depuis l'introduction de la grille de semaine complète. Sans session, `/planning/current` renvoie un 404 générique (route inexistante), pas le 401 documenté. Documente aussi POST/DELETE /planning/items au passage, absents jusqu'ici. Closes #55 Co-Authored-By: Claude Sonnet 5 --- README.md | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/README.md b/README.md index 73e604c..ce79f96 100644 --- a/README.md +++ b/README.md @@ -192,16 +192,18 @@ provisionne un vrai Postgres de service (`.github/workflows/ci.yml`) et exécute ## Planning (apps/api) -- `GET /planning/current` — nécessite le cookie de session (401 sinon). Renvoie le - planning du foyer de l'utilisateur connecté qui couvre la date du jour (`Planning` - dont `start_date <= aujourd'hui <= finish_date`), items inclus avec leur recette - résolue en `{ id, name }` — ou `null` s'il n'y en a aucun (foyer sans planning en - cours, ou profil sans foyer). `null` est une réponse **valide** (200), pas une - erreur : aujourd'hui rien ne permet encore de créer un planning (le module « Calcul - batch-cooking », voir [specs/batch-cooking-architecture.md](specs/batch-cooking-architecture.md), - reste à construire), donc c'est l'état attendu tant que ce module n'existe pas. -- Type de réponse partagé : `PlanningView` (`packages/shared/src/types/planning.ts`), - consommé tel quel par `apps/web`. +- `GET /planning?date=YYYY-MM-DD` — nécessite le cookie de session (401 sinon). + Renvoie le planning du foyer de l'utilisateur connecté qui couvre `date` + (`Planning` dont `start_date <= date <= finish_date`), items inclus avec leur + recette résolue en `{ id, name }` — ou `null` s'il n'y en a aucun (foyer sans + planning couvrant cette semaine, ou profil sans foyer). `null` est une + réponse **valide** (200), pas une erreur. +- `POST /planning/items` — ajoute une recette à un créneau (jour/repas) du + planning du foyer connecté, créant la semaine correspondante à la volée si + besoin. +- `DELETE /planning/items/:id` — retire un item du planning. +- Type de réponse partagé : `PlanningView`/`PlanningItemView` + (`packages/shared/src/types/planning.ts`), consommé tel quel par `apps/web`. Détail de `AsyncRequestHandler`/`wrapAsyncHandler` (`packages/express-tools`) — premier endpoint à combiner `requireAuth`/`AuthLocals` avec un handler async, ce qui @@ -289,7 +291,7 @@ Une fois connecté, l'utilisateur atterrit sur `src/layouts/AppLayout.tsx` — s (nav Planning/Recettes/Liste de courses/Foyer & profil + nom/déconnexion en pied) et `` pour la route active — montée une seule fois comme route parente de tout l'espace authentifié (`App.tsx`), pas dupliquée par page. `src/pages/HomePage.tsx` -(routée sur `/`) affiche le planning de la semaine du foyer (`GET /planning/current`, +(routée sur `/`) affiche le planning de la semaine du foyer (`GET /planning?date=`, voir plus haut) avec ses états chargement/erreur/vide/rempli ; `Recettes` et `Liste de courses` n'ont pas encore de backend dédié et rendent pour l'instant le même composant `ComingSoonPage` — `Foyer & profil` (`src/pages/HouseholdPage.tsx`), lui,