99 commits

Author	SHA1	Message	Date
Nicolas	30f975d29a	feat(admin): crée un ticket Forgejo depuis un message de contact (#81) ... Depuis /admin/messages, un admin peut créer une issue Forgejo à partir d'un message utilisateur : bouton « Créer un ticket » → modale pré-remplie éditable → l'issue est créée via l'API Forgejo et le lien (#N) est mémorisé sur le message. Première intégration Forgejo d'apps/api. - Modèle : `forgejoIssueNumber` / `forgejoIssueUrl` sur `ContactMessage` (migration `20260908130000_contact_message_forgejo_link`, 2 colonnes nullables, aucun backfill). - Config : `FORGEJO_BASE_URL` / `FORGEJO_TOKEN` / `FORGEJO_REPO`, toutes `.optional()` — **fail-closed** (même posture que `ADMIN_JWT_SECRET`) : bouton masqué + endpoint `503` tant que les trois ne sont pas là. Documentées dans `.env.example` ; valeurs de test dans `ci.yml`. - `ForgejoService` (`lib/forgejo/forgejo.service.ts`, singleton `forgejo`) : `isConfigured()` + `createIssue({ title, body })` → `POST .../issues`, en-tête `Authorization: token <pat>`, lit `{ number, html_url }` ; erreur réseau / non-2xx / JSON invalide ⇒ `HttpError 502 FORGEJO_REQUEST_FAILED`. - `admin-contact` : `POST /admin/api/contact/:id/forgejo-issue` (`createForgejoIssueFromMessage` — ordre 503 → 404 → 409 → Forgejo → écriture BDD ; un échec Forgejo ne touche pas la BDD) et `GET /admin/api/contact/forgejo/status`. - Contrat partagé : `createForgejoIssueSchema` (title 1–255, body 1–60000), `ContactMessageAdminView` étendu, `ForgejoIntegrationStatus`, nouveaux `ErrorCode` (`FORGEJO_NOT_CONFIGURED`=5001, `FORGEJO_REQUEST_FAILED`=5002, `CONTACT_MESSAGE_ALREADY_LINKED`=4026, `CONTACT_MESSAGE_NOT_FOUND`=4055) + labels i18n. - Front : `MessagesPage` — sonde `forgejo/status` au montage, colonne « Ticket » (lien `#N` si lié, bouton sinon, « non configurée » sinon), `CreateForgejoIssueModal` + helpers purs `messages.ts` (`buildIssueTitle` / `buildIssueBody`). - Tests : `forgejo.service.test.ts` (stub `globalThis.fetch`), `admin-contact.test.ts` étendu (nominal / 503 / 404 / 409 / 502 + ligne intacte / 400), `admin-messages.cy.ts` étendu (modale pré-remplie, lien après création, masquage si non configuré). - Docs : `backend-architecture.md`, `batch-cooking-modele.md`. Closes #81. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-08 20:10:54 +02:00
Nicolas	0c8cda7f3e	feat(admin): consultation des messages de contact (#80) ... PR 2/2 de l'issue #80 — la vue admin en lecture seule des messages remontés via le formulaire de contact (PR 1 = #123). - Contrat partagé : `listContactMessagesQuerySchema` (filtre `type` optionnel) + `types/contact.ts` `ContactMessageAdminView` (`author` = `{ id, firstName, lastName, email } | null`, `null` = compte supprimé). - API : `admin-contact.{routes,service}.ts` — `GET /admin/api/contact?type=` (`requireAdmin`), tri `createdAt desc`, plafond `CONTACT_MESSAGES_PAGE_SIZE = 200` (même esprit que `CORRECTIONS_PAGE_SIZE`). Branché dans `admin.routes.ts` (`adminRouter.use(/contact, …)`). Aucune route d'écriture. - Front : page `/admin/messages` (`MessagesPage` + `.scss`) — tableau lecture seule (date, expéditeur ou « Compte supprimé », badge de type, message, page, user-agent tronqué + titre au survol), un filtre par type. Entrée de nav « Messages » (icône `Inbox`) dans `AdminLayout` + `adminApiClient.getContactMessages` + i18n `admin.nav.messages` / `admin.messages.*`. - Tests : `apps/api/test/admin-contact.test.ts` (Mocha — 401 sans session admin, tri récent d'abord + `author` résolu, filtre `type`, type inconnu → 400, plafond 200, `author: null` après suppression du compte), `apps/web/cypress/e2e/admin-messages.cy.ts` (rendu lecture seule, filtre par type via le query param). - Docs : `backend-architecture.md` (section `admin` + event `contact.submitted` dans la liste). Closes #80. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-08 09:17:45 +02:00
Nicolas	a252640fe6	feat(contact): modèle + POST /contact + formulaire utilisateur (#80) ... Formulaire in-app de remontée de bug / suggestion pour les utilisateurs connectés (PR 1/2 de l'issue #80). - Modèle Prisma `ContactMessage` (+ relation inverse sur `UserProfile`) et migration `20260908120000_contact_message` — table neuve, aucun backfill. `authorId` nullable + `onDelete: SetNull` : un signalement survit à la suppression de son compte. - Contrat partagé `schemas/contact.ts` : `CONTACT_MESSAGE_TYPES`, `submitContactMessageSchema` (type enum, message 10-5000 trim, pageUrl / appVersion optionnels — jamais le user-agent). - Module API `contact` : `POST /contact` (`requireAuth`, monté `/contact`), `204` sans corps. Le user-agent est lu de l'en-tête de requête, jamais du corps. Émet `analytics.recordEvent(contact.submitted, …)`. - Page `/parametres/contact` (`ContactPage` + `contact.ts` + `.scss`) : select de type, textarea, validation cliente via le schéma partagé, états succès / erreur (`ErrorMessageService`, jamais `err.message`). Entrée de nav « Nous contacter » dans `SETTINGS_ITEMS` + clé i18n + icône. `apiClient.submitContactMessage(input)` ajoute `pageUrl` / `appVersion`. - Tests : `apps/api/test/contact.test.ts` (Mocha — insertion, en-tête UA, champs nullables, message trop court / trop long, type inconnu), `contact.feature` + steps (Cypress e2e — envoi + confirmation + contexte), `contact-page.cy.ts` (rendu + garde `RequireAuth` + label d'erreur). - Docs : `batch-cooking-modele.md`, `backend-architecture.md`, `frontend-architecture.md`. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-08 08:26:47 +02:00
Nicolas	5e478188a2	fix(api): autorise l'origine WebView Capacitor dans CORS_ORIGIN ... L'app Android n'arrivait a se logger/inscrire nulle part (204 + "erreur inattendue" cote client) : CORS_ORIGIN n'etait jamais defini en prod (docker-compose.yml ne le passe pas a `app`), donc il retombait sur son default `http://localhost:5173` (le serveur Vite de dev), qui ne matche evidemment jamais l'origine reelle de l'appli packagee (`https://localhost`, cf. capacitor.config.ts). Le site web n'est lui jamais touche : il est servi depuis la meme origine que l'API en prod, donc jamais de preflight CORS du tout sur /auth/*. Le symptome trompeur vient du package `cors` : un preflight OPTIONS recoit toujours 204, meme pour une origine rejetee — la difference invisible sans inspecter les headers est l'absence de Access-Control-Allow-Origin, qui fait ensuite bloquer le vrai POST cote client sans jamais atteindre le serveur. Vu depuis les logs serveur, la route a bien l'air "appelee" (le preflight matche le meme chemin) alors que /auth/login lui-meme n'est jamais reellement recu. CORS_ORIGIN devient une liste separee par des virgules (le type `ExpressServerCoreOptions.corsOrigin` acceptait deja `string | string[]`) et son default inclut desormais `https://localhost` — l'origine de l'appli packagee est fixe et non secrete (contrairement au domaine du site en prod, qui n'a de toute facon pas besoin d'etre dans cette liste puisqu'il est same-origin), donc la coder en dur dans le default couvre tout deploiement sans configuration supplementaire. Verifie en local : script ad hoc qui demarre le vrai `createServer()` et envoie un preflight OPTIONS /auth/login avec differentes origines — `https://localhost` et `http://localhost:5173` recoivent maintenant Access-Control-Allow-Origin, une origine arbitraire non listee continue de ne pas le recevoir (pas de bypass en wildcard). Egalement `pnpm --filter api exec tsc --noEmit` et `pnpm exec biome check` sur les fichiers touches. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-07 08:22:49 +02:00
Nicolas	3abb7217dd	feat(mobile): proxie le telechargement de l'APK via l'API (pas de CORS) ... Suite au fix de /releases/latest (precedent), l'utilisateur voulait un lien qui declenche le telechargement du .apk directement, sans quitter l'appli web. Verifie en direct : fetch("https://git.dev.kyuno.fr/api/...") depuis le navigateur echoue avec "Failed to fetch" (confirme via un essai en mode no-cors : la requete reseau aboutit bien, seule la reponse est bloquee) — Forgejo n'envoie aucun header CORS sur son API Releases, publique ou non. Ca ne concerne pas que la page d'accueil : le hook de verification de mise a jour (#66, useAppUpdateCheck) faisait exactement le meme fetch cross-origin depuis la WebView native, et echouait donc tout aussi silencieusement en production sans que personne ne puisse s'en rendre compte (le hook avale toute erreur reseau par design). Ajoute un petit module apps/api/src/modules/mobile/ (2 routes publiques, aucune ne touche la base de donnees) : - GET /mobile/latest-release -> { version } (proxy JSON, remplace le fetch direct de useAppUpdateCheck) - GET /mobile/download -> redirection 302 vers l'asset .apk reel de la derniere release (ou vers la page /releases/latest en repli si Forgejo est injoignable ou qu'aucun .apk n'est encore attache) Cote frontend : LandingPage.tsx et UpdateBanner.tsx pointent maintenant vers ce proxy (`${API_BASE_URL}/mobile/download`, target="_blank") au lieu d'une URL Forgejo directe — un clic, telechargement immediat, jamais de navigation hors de l'appli. useAppUpdateCheck.ts appelle desormais apiClient.getLatestMobileVersion() au lieu d'un fetch direct. Verifie en local (sans Postgres, ces routes n'en ont pas besoin) contre les vraies donnees Forgejo : GET /mobile/latest-release -> {"version":"v0.2.0"} GET /mobile/download -> 302, Location vers le vrai .apk signe pnpm lint / tsc (api + web) / pnpm --filter web build : tous verts. Le scenario Cypress "offers the Android app download" echoue encore en local (meme souci pre-existant deja documente sur la PR precedente, confirme independant du code par CI reel) ; mis a jour pour asserter le nouveau href relatif. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-06 23:40:06 +02:00
Nicolas	2beff139a3	feat(api): CRUD admin des scénarios de didacticiel (#44) ... Deuxième volet backend du tutoriel guidé, sur le socle de #42/#44 : permet à un admin de créer/éditer/supprimer les scénarios que `GET /reference/tours` sert au moteur front. `/admin/api/tours` (agrégateur `admin.routes.ts`, tout derrière `requireAdmin`) : - `GET /` — tous les scénarios (activés **et** désactivés) + étapes ordonnées. - `GET /targets` — le catalogue `TourTarget` pour le sélecteur de cible de l'éditeur. - `POST /` — crée un scénario vide (`key` + `name`) ; 409 `TOUR_KEY_ALREADY_IN_USE` (nouveau code 4025) sur une clé prise. - `PATCH /:id` — édite `name`/`enabled` **et remplace toute la liste d'étapes en bloc** (delete-all puis recreate avec `order` = index), même convention que `updateRecipe` pour les étapes d'une recette. `key` immuable. 404 `TOUR_NOT_FOUND` (id inconnu), 404 `TOUR_TARGET_NOT_FOUND` (nouveau code 4054, `targetKey` d'une étape hors catalogue — vérifié avant d'écrire, les étapes réelles restent intactes si la requête est rejetée). - `DELETE /:id` — 204 ; les étapes et les `TourProgress` des utilisateurs cascadent. Tests Mocha (`admin-tours.test.ts`) : 401 sans session admin sur chaque route ; list (activés+désactivés) ; targets ; create→patch pour remplir les étapes ; remplacement en bloc ; 409 clé dupliquée ; 404 cible inconnue (sans toucher aux étapes existantes) ; 404 id inconnu ; delete + cascade vérifiée ; un scénario désactivé disparaît de `/reference/tours` mais reste dans la liste admin. Refs #44 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-06 05:39:37 +02:00
Nicolas	cd8ce42df7	feat(api): modèle de données + API des scénarios de didacticiel (#42/#44) ... Socle backend, entièrement testable en CI, pour le tutoriel guidé. Le moteur front (driver.js), l'instrumentation `data-tour-*` et le CRUD admin viendront ensuite. Schéma (`schema.prisma` + migration `20260906120000_tour_scenarios`) — les 4 modèles de #44, qui révisent le registre statique prévu par #42 : - `TourTarget` (`key` PK + `description`) : catalogue des cibles de surlignage valides, seedé, comme `TechStep`/`Unit`. - `TourScenario` (`key` stable, `name`, `enabled`) : un scénario rejouable. - `TourScenarioStep` (`order`, `route?`, `targetKey`, `title`, `content`) : `title`/`content` sont du **texte libre**, pas des clés i18n (#44 : contenu administrable → texte, comme le nom d'une recette). - `TourProgress` (`userProfileId` + `scenarioId`, PK composite) : présence d'une ligne = scénario vu (terminé *ou* passé). Seed (`reference-seed-data.ts`) : les 9 `TourTarget` correspondant aux `data-tour-*` à poser côté front, + les 2 scénarios de #42 (`general`, `techStepMetadata`) **créés seulement s'ils sont absents** (un admin en devient propriétaire ensuite). `techStepMetadata` reste court pour l'instant — #36 (popover qui se ferme en pleine sélection) est ouvert, v1 ne couvre que les gestes qui marchent déjà. API : - `GET /reference/tours` (public) → scénarios **activés** + étapes ordonnées, forme consommée directement par le futur `useTour()`. - `GET /profile/tours` → `{ completedTourKeys: string[] }`. - `POST /profile/tours/:tourKey/complete` → upsert idempotent ; corps vide = terminé, `{ skipped: true }` = passé. Émet `analytics.recordEvent` `tour.completed` / `tour.skipped` (le dashboard admin agrège déjà tout type d'`AnalyticsEvent` génériquement — analytics de #44 quasi gratuites). 404 `TOUR_NOT_FOUND` (nouveau code 4053) sur une clé inconnue/désactivée. `reset-db.ts` truncate les 4 nouvelles tables (reseedées juste après). Tests Mocha : `GET /reference/tours` (scénarios + étapes ordonnées, exclusion d'un scénario désactivé) ; `/profile/tours` GET+POST (upsert idempotent, `skipped`, 404 clé inconnue, 404 tour désactivé, isolation par profil). Pas de base Postgres locale → exécutés en CI. Refs #42, #44 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-06 05:08:43 +02:00
Nicolas	1d8c001035	feat(auth): accepte un jeton Bearer en repli du cookie de session ... Phase 1 du portage mobile (#39) : purement additif côté navigateur, qui continue d'utiliser le cookie `session` httpOnly inchangé. - `POST /auth/login` et `POST /auth/signup` renvoient aussi le JWT dans le corps de la réponse (`AuthResponse` = `SafeUserProfile` + `token`), en plus de poser le cookie. Un client dont l'origine ne peut pas recevoir un cookie `SameSite=Lax` (WebView Capacitor) le stocke et le renvoie. - `requireAuth` lit le cookie en priorité, puis se rabat sur un en-tête `Authorization: Bearer <jwt>` quand le cookie est absent. Les deux mécanismes coexistent, aucun n'est retiré. - `apps/web` : `ApiClient` gagne une abstraction `TokenStore` (`get`/`set`/`clear`) ; l'implémentation par défaut est un no-op navigateur (le cookie fait tout). `_request` ajoute l'en-tête `Authorization` quand un jeton existe ; `login`/`signup` le stockent, `logout`/`deleteAccount` l'effacent. `setTokenStore` est le point d'injection de la version Capacitor (`@capacitor/preferences`), branchée en phase 2 quand la dépendance sera ajoutée. Tests Mocha : `requireAuth` authentifie via l'en-tête `Authorization` sans cookie, rejette un jeton Bearer invalide ou un schéma non-Bearer ; `login`/`signup` exposent bien le jeton dans le corps. Refs #39 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-06 02:47:57 +02:00
Nicolas	2251aa93d7	feat(sources): ajoute ohmonbento.com comme source de recettes importable ... 6e adaptateur, le plus simple des scrapés : `fetchDetail`/`parse` délèguent tels quels à `jsonLdRecipeAdapter` — une page recette porte un `Recipe` WP Recipe Maker dans un `@graph` Yoast, déjà géré nativement par `findRecipeNode`. `list()` : recherche WordPress `GET /?s={query}&paged={N}` — **même URL que la requête soit vide (tout le catalogue) ou non**, aucun branchement (contrairement à `750g.ts`). Scrape de cartes `<div class="entry-thumb"><a href="/<slug>/"><img alt src>` — image dans `src` (pas de lazy-load `data-src` ici), `href` relatif résolu contre l'origine. Une page au-delà de la dernière renvoie une vraie 404 → fin de liste propre (comme `marmiton.ts`). `rekeySourceError` dupliqué localement. Enregistré dans `registerAllRecipeSources()`. Tests : `ohmonbento.test.ts` (`stubFetchHtml`, pas de base) — scrape des cartes, 404 = fin de liste, URL `/?s=` identique pour requête vide, query + page dans `/?s={q}&paged={n}`, erreurs re-labellisées `ohMonBento`, `parse` sur un `@graph` Yoast + WPRM (`recipeYield` en tableau géré). Vérifié localement, 9/9. + `sources-index.test.ts` couvre l'enregistrement. Docs : section `ohmonbento.ts` dans `backend-architecture.md`. Closes #40 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-06 01:30:44 +02:00
Nicolas	4906accd85	feat(sources): ajoute quitoque.fr comme source de recettes importable ... 5e adaptateur, calqué sur `marmiton.ts` (le plus fin des wrappers scrapés) : `fetchDetail`/`parse` délèguent tels quels à `jsonLdRecipeAdapter` — une page recette quitoque.fr porte un `Recipe` schema.org, seul élément d'un tableau JSON-LD de premier niveau, déjà géré nativement par `findRecipeNode`. Seul `list()` est spécifique : `GET /recettes?page=N` (page 1 implicite si curseur absent), scrape des cartes `<a class="card__content_header" href="/recettes/…">` (image réelle dans `data-src`, `src` n'étant qu'un placeholder lazy-load ; `href` relatif résolu contre l'origine). Extraction agnostique à l'ordre des attributs. Pas de vraie recherche serveur sur le site → `query` est un filtre sous-chaîne « best effort » sur les titres de la page courante (même lacune assumée que `750g.ts`). Fin de liste = page sans aucune carte (comme `marmiton.ts`). `rekeySourceError` dupliqué localement (750g / manger-bouger en ont chacun une copie). Enregistré dans `registerAllRecipeSources()`. Tests : `quitoque.test.ts` (`stubFetchHtml`, pas de base) — scrape des cartes, pagination `?page=N`, filtre par query, fin de liste, erreurs re-labellisées `quitoque`, `parse` sur un JSON-LD tableau-de-premier- niveau. Vérifié localement, 9/9. + `sources-index.test.ts` couvre l'enregistrement. Docs : section `quitoque.ts` dans `backend-architecture.md` (+ correction de la ligne « n'enregistre que TheMealDB », devenue fausse). Closes #37 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-06 01:11:48 +02:00
Nicolas	1c62625c47	feat(planning): attribution et jet des restes + exclusion liste de courses / cuisine ... 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>	2026-09-05 23:53:25 +02:00
Nicolas	eba0ea70bd	feat(planning): sépare portions demandées et portions préparées ... Première PR du chantier « gestion des restes » (issue #34) — les fondations, sans encore d'UI de panier. À l'ajout d'une recette au planning on ne saisit plus qu'un seul nombre, `portionsRequested` (« combien ce créneau doit nourrir »). Le serveur en dérive `portions` (ce qui est réellement préparé) via `computeBatchedPortions` : arrondi au multiple supérieur du rendement de la recette (on cuisine des lots entiers, jamais une fraction de plat). L'écart est le futur pool de restes de l'item. Modèle (`PlanningItem`, purement additif) : - `portionsRequested` NOT NULL — migration nullable → backfill (`= portions` pour les lignes existantes, sans restes à l'époque) → verrou, même discipline que `ingredient_unit_catalog`. - `sourcePlanningItemId` (auto-FK nullable, `onDelete: Cascade`) et `discardedPortions` (défaut 0) — posés maintenant, utilisés plus tard. Partagé (`@batch-cooking/shared/logic/planning-portions.ts`) : - `computeBatchedPortions(recipePortions, requested)` → `{ portions, leftover }` - `computeAvailableLeftover(item)` → pool encore disponible (posé pour les PRs suivantes : validation d'écriture côté API, affichage du panier côté web — une seule formule, deux appelants) API : `addPlanningItemSchema` prend `portionsRequested` ; `addPlanningItem` calcule et stocke les deux valeurs + l'évènement analytics ; `PlanningItemView` et `getPlanningForDate` exposent `portionsRequested`/`discardedPortions`/ `sourceItem`. Front : `RecipePickerDialog` — champ « portions demandées » + indice en direct « → N préparées, M en restes » quand l'arrondi crée un reste ; envoie `portionsRequested`. `RecipeImportForm` — envoie `portionsRequested` (un import atterrit à son propre rendement, donc reste nul). Tests : `planning-portions.test.ts` (les deux exemples de #34 + bornes) ; nouveau bloc `POST /planning/items` dans `planning.test.ts` (arrondi au lot, plusieurs lots, borne exacte, 400 sur non-positif) ; fixtures `planningItem.create` des suites existantes mises à jour ; scénario Cypress planning ajusté (`portionsRequested` dans le corps). Docs : `batch-cooking-modele.md`, `backend-architecture.md`, `frontend-architecture.md`. Réf #34 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-05 23:29:58 +02:00
Nicolas	c48625cb0c	fix(recipes): stoppe le scroll infini des sources au lieu de boucler ... Deux volets de l'issue #38. **Bug de bouclage** — l'`IntersectionObserver` de `SourceItemTable` n'a que `[hasMore]` comme dépendance et ne se réabonne donc jamais pendant un scroll normal (`hasMore` reste `true`). Il figeait la toute première closure `onLoadMore`, laquelle rappelait indéfiniment le même curseur périmé — la liste s'allongeait en boucle avec les mêmes éléments et `nextCursor` n'atteignait jamais son vrai `null`. - `SourceItemTable` lit maintenant `onLoadMore` via une ref réassignée à chaque rendu : l'observer appelle toujours la closure fraîche, sans réabonnement inutile (intention d'origine du `biome-ignore` conservée, le commentaire n'étant plus nécessaire). - `RecipeSourcesPanel` dédoublonne le merge par `externalId` et traite « cette page n'a rien apporté de nouveau » comme une fin de liste même si la source renvoie encore un `nextCursor` — garde-fou contre une éventuelle heuristique de fin imparfaite côté adaptateur. **Couverture recherche vide** — `theMealDbAdapter.list()` tapait `/search.php?s=` même sans requête, ce que TheMealDB borne à ~25 recettes (`nextCursor` toujours `null`). Une requête vide déroule désormais la liste des catégories (`/list.php?c=list` puis `/filter.php?c=…`), une catégorie par pas de curseur, pour un vrai « tout parcourir ». Tests : nouveau scénario Cypress à 3 pages avec curseurs distincts réellement vérifiés (aucun curseur redemandé) ; nouveaux cas Mocha pour la marche par catégories (première page + curseur, suivi du curseur, arrêt sur la dernière catégorie, page vide au-delà, requête blanche = requête vide). Closes #38 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-05 20:20:43 +02:00
Nicolas	23be1e4d04	fix(admin): ferme le serveur socket.io en fin de suite de test monitoring ... Le hook `after` de admin-monitoring-socket.test.ts appelait seulement `broadcast.stop()` (qui ne fait que couper l'intervalle de sonde) et `prisma.$disconnect()`, mais ne fermait jamais le serveur socket.io ni le `http.Server` en écoute sur le port 0. socket.io garde alors vivants les timers ping d'engine.io et la socket d'écoute ; comme Mocha tourne sans `--exit` (.mocharc.json), ce seul handle en fuite empêche le process de se terminer une fois le dernier test passé. C'est ce qui bloquait le job `test` en CI : « N passing » affiché, puis plusieurs heures d'attente jusqu'au kill du runner (runs #80/#81). Hisse `io` au scope de la suite et le ferme dans `after` via `io.close()` — ce qui déconnecte les sockets restantes, stoppe les timers d'engine.io et ferme le `http.Server` attaché. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-05 19:56:45 +02:00
Nicolas	13d92f8fa8	feat(admin): pousse le monitoring en WebSocket au lieu du polling client ... Le tableau de bord /admin/monitoring fonctionnait en polling côté client (15 s) déclenchant une sonde active côté serveur à chaque appel — deux onglets admin ouverts = deux séries de sondes redondantes. Inverse le mécanisme : le serveur sonde une fois par minute et pousse le résultat aux clients connectés via WebSocket (socket.io, room "monitoring"). Décisions actées avec l'utilisateur : l'endpoint REST disparaît entièrement (plus de repli, 100% WebSocket) ; la sonde tourne en continu dès le démarrage, sans lien avec la présence d'un admin connecté (le plus simple des deux, coût des sondes négligeable). Backend : - ExpressServer (packages/express-tools) expose désormais son http.Server sous-jacent (créé explicitement, plus dans .listen()) — socket.io s'attache au serveur HTTP lui-même, pas à Express/un port. - MonitoringBroadcastService (nouveau) : sonde immédiate au démarrage puis toutes les 60 s (réutilise getMonitoring() tel quel, aucune duplication), diffuse à la room "monitoring", rejoue le dernier résultat en cache à tout nouvel admin qui rejoint (pas d'attente jusqu'à une minute pour un onglet fraîchement ouvert). - requireAdminSocket (nouveau) : middleware de handshake socket.io, équivalent WebSocket de requireAdmin — même vérification (cookie + JWT + tokenVersion), factorisée dans resolveAdminFromToken (require-admin.ts) puisque les deux ne diffèrent que par où ils lisent le cookie brut (un handshake socket.io ne passe pas par cookie-parser). - GET /admin/api/monitoring supprimée (route + service de test associés). - server.ts (pas app.ts) instancie socket.io — les tests supertest n'ont pas besoin d'un serveur WebSocket. Frontend : - MonitoringSocketClient (nouveau, api/monitoring-socket.ts) : wrapper socket.io-client, interface MonitoringSocketClientLike volontairement petite et injectable dans MonitoringPage (prop optionnelle) pour rester testable sans serveur réel. - MonitoringPage : data et connectionState séparés — une coupure de connexion après un premier chargement affiche un badge "reconnexion en cours" sans jamais effacer le dernier board connu (repose sur la reconnexion automatique de socket.io-client). Seul le tout premier chargement affiche l'état plein-écran chargement/erreur. - adminApiClient.getMonitoring() supprimée (plus utilisée). Tests : - Nouveau apps/api/test/admin-monitoring-socket.test.ts : vraie connexion socket.io-client contre un serveur réel démarré dans le test (port 0), authentification avec un admin seedé + cookie signé, vérifie la réception de monitoring:update et le rejet sans cookie admin valide. Les tests heartbeat de l'ancien admin-monitoring.test.ts (route /internal/tech-steps/heartbeat, sans rapport avec ce changement) sont déplacés vers tech-step-worker.routes.test.ts, leur router d'origine. - Nouveau cypress/component/MonitoringPage.cy.tsx : monte la page avec un client factice, vérifie rendu des cartes, badge de reconnexion sans perte du board, états chargement/erreur — pas de test e2e Gherkin contre un vrai WebSocket (aucun mécanisme pour ça dans ce repo, fragile ; le test Mocha ci-dessus est la preuve bout-en-bout serveur). - apps/web/cypress/e2e/admin-monitoring.cy.ts (REST) supprimé, remplacé par le test composant ci-dessus. Vérification : pnpm lint clean, build complet du monorepo clean, suite Cypress e2e complète 27/27 fichiers (114/114 tests), suite composant complète 5/5 fichiers (54/54 tests, dont les 4 nouveaux). Suite Mocha apps/api non exécutable cette session (Postgres/Docker injoignable, comme pour #33) — le nouveau test socket.io n'a donc pas pu être run-vérifié, seulement relu attentivement et vérifié par le lint. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-05 14:44:39 +02:00
Nicolas	ba131bd8c8	fix(admin): isole l'API admin sous /admin/api pour éviter la collision avec les pages front ... Un rafraîchissement (F5) sur /admin/monitoring affichait le JSON brut de l'API au lieu de la page — même chose à craindre pour tout futur /admin/* GET sans segment supplémentaire. Cause : `server.mountRouter("/admin", adminRouter)` (app.ts) montait l'API admin exactement sous /admin, la même racine que les pages /admin/* d'apps/web, servies depuis la même origine/le même process en prod (image Docker unique). Express matche par chemin, sans égard au Accept — `GET /admin/monitoring` (route API) et la page du même nom étaient en conflit direct ; l'API gagnait systématiquement (montée avant serveStaticFrontend), donc chaque F5 sur cette page recevait le JSON de l'API plutôt que index.html. Seule /admin/monitoring collidait réellement aujourd'hui (seul sous-routeur admin à répondre GET sur sa racine bare) mais le mécanisme touche toute future route admin nommée comme sa page — d'où un correctif structurel plutôt qu'un renommage ponctuel. Correctif : l'API admin est montée sous /admin/api (app.ts), jamais bare /admin. Toute la surface admin bouge en conséquence (auth/metrics/monitoring/tech-steps/catalog) ; les pages front (/admin/monitoring, /admin/catalogue, /admin/corrections...) sont inchangées, seul admin-client.ts change de base URL. Mis à jour en cohérence : commentaires JSDoc citant les routes (apps/api + apps/web + packages/shared), specs/backend-architecture.md, specs/batch-cooking-modele.md, les intercepts Cypress (globs + un matcher regex qui avait échappé au premier passage) et les chemins supertest du suite Mocha admin-*.test.ts. Simplifie au passage admin-monitoring.cy.ts : le contournement resourceType ajouté en #32 pour cette même collision n'a plus lieu d'être une fois les chemins distincts (retour à un intercept déclaratif simple) — le bug Cypress/Chrome qu'il avait mis au jour reste noté en commentaire pour référence future. Vérifié : pnpm lint clean ; build api+web clean ; suite e2e complète 28/28 fichiers, 116/116 tests verts (dont les 16 tests admin-*). Suite Mocha apps/api non exécutable cette session (Postgres/Docker injoignable) — chemins mis à jour mécaniquement en cohérence avec le nouveau mount point, à faire tourner en CI/à la prochaine session avec accès DB. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-05 13:48:07 +02:00
Nicolas	5d4ed0dffb	feat(recipes): permet de corriger la température d'un tech-step ... Jusqu'ici, submitTechStepCorrectionSchema (POST /recipes/:id/steps/:stepId/ corrections) acceptait ingredients/utensils pour compléter les métadonnées d'une technique corrigée, mais aucun champ temperatures — StepTechStepTemperature n'était jamais écrit que par toStepTechStepCreateInputs, lors d'un create/update complet de recette. La température ajoutée en #22 n'avait jamais eu son propre circuit de correction manuelle. - packages/shared/src/schemas/recipe.ts : nouveau manualStepTechStepTemperatureInputSchema (celsius/gasMark/qualitative mutuellement exclusifs — exactement un des trois — même span start/end que ingredients/utensils). Le champ temperatures rejoint ingredients/ utensils dans le même lot combiné (les trois voyagent ensemble : dès que l'un est présent, les trois sont résolus, un absent devient [] donc effacé — jamais une fusion partielle catégorie par catégorie). - recipe-tech-step-correction.service.ts : applyManualCorrection écrit désormais StepTechStepTemperature (delete+recreate, même logique "le manuel remplace tout" que les deux autres tables). raw n'est jamais envoyé par le client — dérivé de description.slice(start, end), pour ne pas faire confiance à une copie cliente qui pourrait diverger du texte réel. loadVisibleStepOrThrow retourne désormais le texte complet de la description (pas seulement sa longueur), nécessaire pour cette dérivation. - specs/backend-architecture.md + specs/batch-cooking-modele.md : les deux routes de correction et step_tech_step_temperature n'étaient documentées nulle part — comblé au passage. - Tests Mocha ajoutés (celsius/gasMark/qualitative, rejet si zéro ou plusieurs champs renseignés, remplacement sans accumulation, dérivation de raw, span hors limites). Périmètre : back-end uniquement (voir la maquette proposée précédemment). Le popover de correction (apps/web) ne sera mis à jour que dans une PR suivante, empilée sur celle-ci. Vérifié : pnpm lint + build (shared, api) clean. Mocha non exécuté — pas de Postgres/Docker accessible dans cette session (ni Bash ni PowerShell). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-04 23:53:14 +02:00
Nicolas	ec01fc0107	fix(recipes): persiste les métadonnées de clause des tech-steps à l'édition ... `createRecipeInternal` écrivait, pour chaque technique détectée, ses ingrédients / ustensiles / températures de clause ; `updateRecipe` et le script `backfill-tech-steps.ts` n'écrivaient que le span de la technique. Toute recette ré-enregistrée via l'UI (ou touchée par le backfill) perdait donc silencieusement ces métadonnées — et `cooking-optimizer.ts` ne pouvait plus détecter de conflit de four entre deux préchauffages dès qu'une recette avait été éditée une fois (ni sur les imports antérieurs à la détection des températures, jamais ré-enregistrés). - `toStepTechStepCreateInputs` (nouveau, `lib/recipe-matching/`) : seule source de vérité du payload `techSteps.create`, utilisée par les trois appelants pour qu'ils ne divergent plus. - `backfill-tech-steps.ts` : `createMany` -> `create` par ligne (createMany ne fait pas les écritures imbriquées) + doc à jour. - Rattrapage automatique au déploiement : `model BackfillState` + migration `backfill_state`, script `backfill-runtime.ts` ajouté au CMD Docker après `seed-runtime`. Gardé par un marqueur (tourne une seule fois), n'échoue jamais le boot (une panne du backfill est loggée, le serveur démarre quand même, retente au prochain start). - Test `PATCH /recipes/:id` : une température de clause survit à l'édition. - `reset-db.ts` : `backfill_state` ajouté au TRUNCATE. Vérifié : `tsc --noEmit` + `pnpm --filter api build` + `pnpm lint` OK ; migration = SQL généré par Prisma pour le modèle, à l'identique. Mocha `recipe.test.ts` non lancé (Postgres + intent-service requis, indisponibles ici) — à jouer en CI / sur la machine de dev. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-04 09:08:15 +02:00
Nicolas	85268729e6	feat(cooking-session): regroupement d'étapes sensible aux métadonnées d'action ... L'optimiseur ne mutualisait que le pré-découpage. Il regroupe maintenant aussi les actions SETUP (préchauffage, ébullition) entre recettes, mais seulement quand elles sont compatibles : deux préchauffages ne fusionnent que s'ils visent la même température détectée. Deux préchauffages à des températures différentes restent séparés, ordonnés du plus froid au plus chaud, et la mise en place porte une note « Four requis à N températures — enchaîner … ». Défaut optimiste : deux préchauffages sans température détectée fusionnent quand même (supposés compatibles). - cooking-optimizer.ts : temperatureKey (comparaison exacte, aucune conversion inter-représentations), isPureSetupStep / setupSignature / extractMergedSetup en miroir du chemin merged-prep ; comparableTemp pour l'ordre seul ; detectApplianceTemperatureConflicts → CookingPhaseView.notes - cooking-session.service.ts : `temperatures` dans l'include + mapping - packages/shared : CookingTemperatureView, kind « merged-setup », CookingTaskView.temperatures, CookingPhaseNoteView, CookingPhaseView.notes - web : temperature-label.ts extrait de StepDescription et réutilisé ; taskHeadline gère merged-setup ; phaseNoteText ; bandeau .cooking-phase__note - i18n : cookingSession.task.mergedSetupLabel, cookingSession.note.* - tests : 7 cas Mocha « setup pooling » + test DB cooking-session, cas Cypress mode layout + scénario Gherkin Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-03 12:05:44 +02:00
Nicolas	fd62dbbabe	test(tech-steps): ajoute temperatures aux fixtures StepTechStep ... CI: 7 `deep.equal` sur un `TechStepMatch` / `StepTechStepView` echouaient (l'objet reel a une cle de plus depuis l'ajout de `temperatures`). - tech-step-matcher.test.ts x4 : `temperatures: []`, sauf le cas « Faire mijoter a feu doux » ou « feu doux » [16,24) est une mention qualitative -> `qualitative: "low"`. - recipe-tech-step-correction.test.ts x3 : `temperatures: []` (l'etape fixture « Faire mijoter la sauce. » n'a pas de mention de temperature). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-29 19:59:52 +02:00
Nicolas	189df73b4c	feat(tech-steps): detecte les temperatures dans les etapes ... 3e type de metadonnee de clause, a cote des ingredients et des ustensiles : temperature en °C (« 180°C », « 200 degres », °F converti), numero de thermostat (« th. 6 ») et intensite qualitative (« feu doux/moyen/vif » -> low/medium/high). services/tech-step-intent-service : - `temperature_extraction.py` : `extract_temperatures(text, locale)` pur, a base de regex (independant du modele spaCy et de l'entrainement). - `ProcessResult` / `ProcessResponse` gagnent `temperatures` (ajout additif au contrat ; cle `gas_mark` en snake_case sur le fil). `process()` les extrait meme pour une locale pas encore entrainee. - Tests `test_temperature_extraction.py` (10) ; `test_routes_process.py` : 2 assertions d'egalite stricte gagnent `"temperatures": []`, +1 cas. apps/api : - `IntentServiceTemperature` (mappe `gas_mark` -> `gasMark` a la frontiere). - `TechStepMatch.temperatures` : filtrees par appartenance de span a la clause, meme regle que les ustensiles. - `model StepTechStepTemperature` (aucune FK — la valeur structuree EST la donnee) + migration manuelle `20260829120000_step_tech_step_temperature` (cascade via le TRUNCATE de `step_tech_step`, rien a ajouter a reset-db.ts). Persistance + lecture dans `recipe.service.ts` (`recipeInclude`, `toStepTechStepViews`) et l'include de sequence fraiche du service de correction ; `sources.service.ts` (apercu d'import) les fait transiter. packages/shared : `StepTechStepTemperatureView` + `temperatures` sur `StepTechStepView`. apps/web : - `splitDescriptionSegments` enrobe `splitDescriptionByTechSteps` et redecoupe les segments non-keyword autour des spans de temperature (la logique technique intriquee reste intacte). `?? []` tolere une payload d'avant `temperatures`. - `StepDescription` : surlignage `.step-temperature` + Tooltip via `temperatureLabel` ; i18n `recipes.temperature.*`. - Tests composants +4 (22 verts) ; pas d'UI de correction (v1, comme les ustensiles). Verifie : biome + tsc + `pnpm -r build` ; web 102/103 e2e (l'echec est le flake pre-existant recipe-form.feature, sans rapport) + 49/49 composants ; pytest temperature + routes 15/15. `pnpm --filter api test` (Postgres + intent-service requis) non lance ici. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-29 19:29:03 +02:00
Nicolas	bbd9afe8aa	refactor(admin): fusionne apps/admin-web dans apps/web sous /admin/* ... L'admin etait une 2e app front Vite independante (apps/admin-web, port 5174, Dockerfile nginx, service compose dedie, job CI propre) non demandee. Toute l'UI passe dans apps/web sous le prefixe /admin ; seul le frontend est fusionne, l'authentification admin reste entierement separee. Front (apps/web/src) : - pages -> pages/admin/{login,dashboard,monitoring,corrections,catalog}/, layout -> layouts/AdminLayout.tsx, contexte + garde -> features/admin/. - client API -> api/admin-client.ts : classe AdminApiError (evite la collision avec ApiError), lit VITE_API_URL (plus de VITE_ADMIN_API_URL). - routes /admin/* dans App.tsx, enveloppees d'AdminAuthProvider + RequireAdmin -> le probe GET /admin/auth/me ne tourne que sous /admin. - reutilise l'i18n, lib/zod-errors, services/error-message.service et le theme SCSS de apps/web ; bloc i18n admin.* fusionne dans la locale fr (les cles errors etaient deja toutes presentes). - corrige une race dans CatalogPage (reponse d'un onglet precedent qui ecrasait l'onglet courant, exposee par le double-mount StrictMode) via un ref requestSeq. Auth admin inchangee : table AdminUser, cookie admin_session, ADMIN_JWT_SECRET, script create-admin.ts. Infra : - docker-compose : service admin-web + ADMIN_WEB_PORT supprimes (l'app `app` sert deja le front construit). - ADMIN_CORS_ORIGIN retire (meme origine) : env.ts, app.ts, .env.example. - job CI "Run admin-web E2E tests" supprime ; les specs admin-* tournent dans le job web (apps/web/cypress/e2e/admin-*.{cy.ts,feature}). - apps/api/.env.example : ajout ADMIN_JWT_SECRET / ADMIN_INITIAL_*. - recharts ajoute a apps/web ; pnpm-lock regenere. - specs/backend-architecture.md : section admin mise a jour. Verifie : biome + tsc -b (web/api) + pnpm -r build verts ; Cypress web 102/103 (l'unique echec est le flake pre-existant recipe-form.feature "Preloads ..." de clipping headless, sans rapport) ; 16/16 specs admin ; 45/45 composants. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-29 17:02:29 +02:00
Nicolas	9532ea4e83	fix(tests): corrige 3 suites Mocha DB revelees par leur 1er run sur main ... Ces suites ont ete ecrites pendant le dev des features cooking / admin / hors-catalogue mais jamais executees (pas de Postgres dans ces sessions). Leur 1re execution reelle sur `main` echouait — bugs dans les tests, pas dans le code merge. - reference.test.ts : `GET /reference/ingredients` renvoie desormais `isPlaceholder` (toujours false) et `displayName` (toujours null) depuis la PR #16 (champs de `IngredientView`). L'assertion `to.have.keys([...])` exacte est mise a jour. - cooking-session.test.ts : la fixture "pooling merged-prep" avait 2 recettes symetriques (chop -> simmer) ; apres mise en commun du chop les deux simmer tournent dans l'unique phase de cuisson, donc aucun `background` possible (l'optimiseur est correct, cf. le test pur equivalent). « Tarte » recoit une etape active `mix` de plus pour que son simmer flotte en background pendant que « Soupe » est en hold. - admin-tech-steps.test.ts : une requete supertest ne part qu'a l'`await`/ `.then` ; la 1re requete /retrain concurrente n'etait jamais lancee, donc le verrou process n'etait jamais tenu et la 2e recevait 200 au lieu de 409. Ajout d'un `.then(res => res, err => err)` pour la declencher avant l'attente de 100 ms. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-29 12:00:43 +02:00
Nicolas	16f593d5d0	feat(recipes): permet d'ajouter des ingredients hors-catalogue ... Quand le catalogue seede ne couvre pas un ingredient, l'utilisateur pouvait etre bloque (creation manuelle) ou perdre silencieusement la ligne (import). Une ligne de recette accepte desormais `placeholderName` (texte libre) au lieu de `ingredientId` : l'API cree une ligne `Ingredient` `isPlaceholder` (cle `placeholder:<uuid>`, `displayName`, `createdById`) dans la transaction de la recette, et emet `ingredient.placeholder_created`. Ces lignes sont exclues de `GET /reference/ingredients` et de `ingredient-matcher`. Front : bouton "Ajouter << ... >>" dans l'etat vide de `IngredientPicker` (formulaire + import), badge "a completer" sur la ligne, helper `ingredientLabel` applique partout ou un libelle d'ingredient est rendu. Admin : `/admin/catalog/*` (+ page `apps/admin-web`) liste les placeholders regroupes par nom normalise, "marquer traite" (`reviewedAt`) et purge des orphelins. La promotion en vraie entree catalogue reste manuelle. Migration `ingredient_placeholder` ecrite a la main (Postgres indisponible). Suites Mocha DB-backed ecrites, non executees en session ; test pur `normalizePlaceholderName` + Cypress admin-web/web verts. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-28 23:36:42 +02:00
Nicolas	fcaecb4e07	feat(admin): tri des corrections + declenchement du gate F1/backfill ... PR 5 (derniere) du chantier admin. Remplace le duo CLI list-pending-training-suggestions.ts / retrain-tech-steps.ts par une UI. API (admin-tech-steps.service.ts, routes /admin/tech-steps/*, requireAdmin) : - GET /suggestions : TechStepTrainingSuggestion filtrees, groupees par technique, enrichies du contexte de la correction source. - GET /corrections : corrections brutes filtrables, incluant les suppressions correctedTechStepId:null invisibles ailleurs. - PATCH /suggestions/:id : edite synonymes/phrases et/ou status. - GET /training-data-snippet : bloc training_data.py a coller (lecture seule). - POST /retrain : runTechStepEvalSuite() (gate F1 vs MIN_OVERALL_F1) puis si passe backfillTechSteps() + marquage applied/rejected. Verrou memoire -> 409 RETRAIN_ALREADY_RUNNING. Gate echoue -> 200 gatePassed:false. N'edite pas le .py ni ne redemarre l'intent-service (manuel). Shared : nouveau ErrorCode RETRAIN_ALREADY_RUNNING (4023, + cle i18n apps/web), schemas (list*/update*/retrain*/snippet), types (TrainingSuggestion*/Correction*/RetrainResultView...). Front : CorrectionsPage (onglets Suggestions / Corrections brutes, bandeau caveat permanent, cartes editables + Appliquer/Rejeter, panneau snippet, panneau gate F1). Logique pure corrections.ts. i18n admin.corrections.*. AdminApiClient : 5 methodes. Tests : Mocha admin-tech-steps.test.ts (401 partout, groupement+filtre, PATCH 400/404/ok, corrections incluant removals, snippet, retrain shape + 409 concurrent) ; Cypress corrections.cy.ts (4 verts). Admin-web Cypress 13/13. specs/backend-architecture.md : section tri + retrain. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-28 23:36:31 +02:00
Nicolas	29432e5bf2	feat(admin): monitoring des microservices + heartbeat du worker LLM ... PR 4 du chantier admin. Board de sante temps reel des dependances. - POST /internal/tech-steps/heartbeat (requireInternalWorker) -> recordWorkerHeartbeat : upsert WorkerHeartbeat (cle fixe "tech-step-llm-worker"), lastRunAt/lastResult pour un ping "job". Schema workerHeartbeatSchema dans packages/shared. - services/tech-step-llm-worker : api-client.postHeartbeat (best-effort, ne throw jamais) appele au boot (index.ts), a chaque tick et apres chaque job (scheduler.ts, avec job/ok/counts). - admin-monitoring.service.ts + GET /admin/monitoring (requireAdmin) : sonde active bornee (~2 s) de Postgres (SELECT 1), l'API (uptime/RSS), tech-step-intent-service (/health), et le worker via son heartbeat. Statut up/degraded/down/unknown ; une sonde down ne casse ni les autres ni l'endpoint. Seuils worker : > 8 j degraded, > 21 j down. - MonitoringView / ServiceHealthView dans packages/shared. - Front : MonitoringPage (grille de cartes coloree par statut, re-poll 15 s), logique pure monitoring.ts, i18n admin.monitoring.*, AdminApiClient.getMonitoring. - Tests : Mocha admin-monitoring.test.ts (heartbeat 401/400/upsert job+boot ; GET /admin/monitoring 401, board 4 cibles, worker unknown sans heartbeat puis up apres) ; Cypress monitoring.cy.ts (2 verts). Worker mocha : 6/6 toujours verts. - specs/backend-architecture.md : section monitoring. .gitignore : apps/admin-web/cypress/{screenshots,videos,downloads}. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-28 23:36:31 +02:00
Nicolas	3a416ea955	feat(admin): metriques d'utilisation (derive DB + AnalyticsEvent) ... PR 3 du chantier admin. Tableau de bord metriques : snapshot de compteurs + series temporelles journalieres. Schema (migration admin_metrics) : - AnalyticsEvent (type String libre, actorType/actorId sans FK, context Json, index [type, created_at]) + WorkerHeartbeat (cable en PR 4). - colonnes createdAt @default(now()) sur UserProfile / Recipe / Planning / PlanningItem (lecture admin uniquement ; lignes existantes = timestamp de la migration). Instrumentation (lib/analytics.service.ts, fire-and-forget) : - analytics.recordEvent(type, {actorId?, context?}) : retourne void, insert detache, echec loggue+avale, jamais de latence sur la requete. - points d'appel : user.signup, recipe.created, recipe.imported, planning.item_added, tech_step.correction_submitted, shopping_list.viewed. API : GET /admin/metrics?days= (7-365, defaut 30, requireAdmin) -> admin-metrics.service.ts. bucketByDay pur (zero-remplissage, teste sans base). MetricsView dans packages/shared. Front : DashboardPage (tuiles KPI + un graphe recharts par serie + listes recettes-par-source / evenements), logique pure dans dashboard.ts, i18n admin.dashboard.*. AdminApiClient.getMetrics. reset-db.ts truncate analytics_events + worker_heartbeats. Tests : Mocha admin-metrics.test.ts (bucketByDay pur x2 verts ; snapshot, series zero-remplies, event user.signup fire-and-forget) ; Cypress dashboard.cy.ts (2 verts). specs/backend-architecture.md : section admin. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-28 23:36:31 +02:00
Nicolas	c3d2ac7e8e	feat(admin): fondation auth de l'application d'administration ... Premiere brique de l'app d'admin independante : une surface /admin/* ajoutee a apps/api, avec une authentification totalement distincte de celle des utilisateurs. - Table AdminUser isolee (aucune relation vers UserProfile), migration 20260828120000_admin_user. - lib/admin-jwt.ts : sign/verify d'un JWT admin, secret ADMIN_JWT_SECRET propre (jamais interchangeable avec JWT_SECRET). - middlewares/require-admin.ts : cookie admin_session dedie, re-check tokenVersion, echoue ferme si ADMIN_JWT_SECRET absent (posture requireInternalWorker). res.locals.adminUser type via AdminLocals. - modules/admin/ : admin-auth.{routes,service}.ts (POST /login, POST /logout, GET /me), admin.routes.ts agregateur monte /admin. Pas de signup expose. - lib/safe-admin.ts : mapping AdminUser -> AdminUserView (drop passwordHash + tokenVersion, dates ISO). - scripts/create-admin.ts : creation du 1er admin hors-bande (flags ou ADMIN_INITIAL_*). - CORS : setupCore accepte string[] ; app.ts autorise CORS_ORIGIN + ADMIN_CORS_ORIGIN. - Shared : schemas/admin.ts (adminLoginSchema), types/admin.ts (AdminUserView). - Env : ADMIN_JWT_SECRET (optionnel), ADMIN_COOKIE_NAME, ADMIN_CORS_ORIGIN, ADMIN_INITIAL_* ; .env.example, .env.test.example, docker-compose.yml, ci.yml mis a jour. - reset-db.ts truncate admin_users. - Tests Mocha admin-auth.test.ts : 400 sans body, 401 email inconnu / mauvais mdp, login OK (cookie pose, lastLoginAt, pas de hash/tokenVersion dans la reponse), /me derriere requireAdmin, logout, et un cookie `session` d'utilisateur normal ne donne pas acces a /admin/*. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-28 23:36:29 +02:00
Nicolas	6b60c11408	feat(cooking): endpoint GET /cooking-session (plan de cuisine optimise) ... Module cooking-session : charge le Planning couvrant ?date= (meme requete "plage couvrante" + degradation "jamais null" que /shopping-list), mappe chaque PlanningItem vers l'entree pure de optimizeCookingPlan (ingredients/ unites/techniques/ustensiles resolus via toIngredientView/toUnitView reutilisees de recipe.service), renvoie OptimizedCookingPlanView. - cookingSessionPlanningInclude reprend le sous-arbre steps de recipeInclude. - Route requireAuth, contrat ?date= identique a /shopping-list. - Monte /cooking-session dans app.ts. - Tests d'integration Mocha (401, date invalide, plan vide sans foyer / sans planning, mutualisation d'une decoupe entre 2 recettes planifiees). - specs/batch-cooking-architecture.md : module "Calcul batch-cooking" TODO -> v1 implementee ; nouvelle section dans backend-architecture.md. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-28 19:06:24 +02:00
Nicolas	83a12d474d	feat(cooking): moteur d'optimisation des etapes de batch-cooking ... 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>	2026-08-28 19:06:24 +02:00
kyuno053	eef5db92b5	feat(recipes): permet d'associer ingredients/ustensiles a une correction de technique ... Etend le flux de correction existant (TechStepCorrectionPopover) pour que l'utilisateur associe lui-meme des ingredients (avec quantite/unite) et des ustensiles a la technique qu'il corrige, avec le meme marquage source: "manual" que la technique elle-meme. Backend : - submitTechStepCorrectionSchema (packages/shared) accepte des tableaux ingredients/utensils optionnels, chacun avec son propre span [start,end) selectionne par l'utilisateur. Omis = ne touche pas aux metadonnees existantes ; tableau (meme vide) = remplace tout ce qui existait sur cette occurrence (auto ET manuel precedent - decision validee avec l'utilisateur). - applyManualCorrection (recipe-tech-step-correction.service.ts) ecrit les nouvelles lignes StepTechStepIngredient/StepTechStepUtensil apres avoir vide celles de l'occurrence via deleteMany - meme chemin de code que ce soit une creation ou une mise a jour de la technique. - Nouveaux asserts d'existence (ingredient/unite/ustensile) + validation de span, nouveau code d'erreur UTENSIL_NOT_FOUND. - source ajoute a StepTechStepIngredientView/StepTechStepUtensilView (le calque manquait ce que la colonne DB portait deja). Frontend : - TechStepCorrectionPopover passe d'un clic = soumission immediate a un flux selection-puis-confirmation, avec deux nouvelles sections Ingredients/Ustensiles pre-remplies avec l'existant. - Ajouter un ingredient/ustensile demande une selection de texte dediee dans la description encore visible (StepDescription geree via un nouvel etat pendingSpanRequest/resolvedMetadataSpan) - pas de raccourci sur le span de la correction elle-meme. - Nouveau CatalogSearchPicker.tsx, plus leger que IngredientPicker pour ce contexte de popover, reutilise pour les deux catalogues. - getUtensils() ajoute a apiClient. Tests : nouveaux cas Mocha (attache/remplace/omission/validations) dans recipe-tech-step-correction.test.ts, TechStepCorrectionPopover.cy.tsx etendu avec le nouveau flux, recipes.ts (e2e) ajuste au clic Valider supplementaire. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-26 21:51:45 +02:00
kyuno053	550627919d	feat(recipes): associe ingredients, quantites et ustensiles aux techniques detectees (#75) ... * feat(recipes): associe ingredients, quantites et ustensiles aux techniques detectees Etend le pipeline de detection de techniques (tech-step-matcher.ts) pour resoudre, par clause, les metadonnees qui accompagnent une technique detectee : - Ingredients : nouvelle fonction findIngredientMentions (ingredient-matcher.ts) qui scanne le texte d'une clause contre le catalogue Ingredient existant (reutilise INGREDIENT_LABELS_FR/EN deja utilise par matchIngredientName), avec extraction best-effort de la quantite+unite immediatement avant la mention. - Ustensiles : nouveau catalogue Utensil (Prisma) + second PhraseMatcher cote service Python (intent_service/utensil_vocabulary.py), independant du textcat des techniques (pas d'interpretation necessaire pour un ustensile). POST /v1/process distingue desormais chaque entite via un champ kind (technique|utensil). - Persistance : deux nouvelles tables StepTechStepIngredient/ StepTechStepUtensil, liees a StepTechStep par sa cle composite (stepId, order), peuplees au moment du matching (recipe.service.ts) et exposees via StepTechStepView (packages/shared). Aucune analyse syntaxique ajoutee (le parser spaCy reste exclu du pipeline) : l'association se fait par appartenance a la clause deja calculee par splitIntoClauses. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(recipes): corrige les tests casses par les nouveaux champs ingredients/utensils recipe-tech-step-correction.test.ts asserte StepTechStepView en dur sans les nouveaux champs ingredients/utensils (toujours [] pour une correction manuelle, qui ne repasse jamais par le scan de metadonnees). Retire aussi le nouveau cas de tech-step-matcher.test.ts qui inventait une phrase jamais vue par le corpus reel : verifie en CI que le textcat la classe avec confiance comme caramelize plutot que melt, un artefact du petit corpus BOW plutot qu'un bug du code de matching. L'extraction quantite+unite reste couverte integralement et de facon deterministe par ingredient-matcher.test.ts. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(recipes): equilibre le corpus d'entrainement du textcat a 20 phrases par technique Chaque technique n'avait que 3 a 7 utterances par locale (moyenne ~3.8), un desequilibre reel entre classes qui contribue directement a des classifications confiantes mais fausses sur une formulation jamais vue (constate concretement dans la PR precedente : une phrase inedite pour melt classee comme caramelize avec une confiance elevee). Porte chaque technique a exactement 20 utterances par locale (fr et en) : - Les utterances existantes sont conservees telles quelles, jamais reecrites. - Le complement vient d'augment_utterances.py (nouveau script maintainer, reutilisable pour une future technique sous-alimentee) : enveloppe chaque utterance deja a l'imperatif/infinitif dans une tournure modale grammaticalement valide (il faut/veillez a/make sure to...) plutot que de dupliquer ou d'inventer du texte generique - vraie diversite de surface, vocabulaire distinctif de la technique intact. - tests/test_training_data_balance.py fait respecter l'invariant en CI (20 minimum, meme nombre fr/en) pour toute future modification. _TRAINING_ITERATIONS recalibre de 25 a 10 (locale_pipeline.py) pour compenser les ~2.6x d'exemples par epoque : temps d'entrainement mesure quasi identique a avant (~687s fr+en combines contre ~670s), confiance egale ou meilleure sur les cas deja suivis (simmer 0.31 -> 0.48). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(recipes): remonte _TRAINING_ITERATIONS a 20, la gate F1 de CI etait sous 0.8 a 10 Le premier passage CI de l'equilibrage du corpus (20 utterances/technique) a fait chuter le F1 agrege (tech-step-eval.test.ts) a 0.7999... avec _TRAINING_ITERATIONS=10 : le pari qu'un corpus plus large convergerait en moins d'epoques relatives etait faux a ce niveau de reduction. Remonte a 20 (mesure : ~699s pour la seule locale fr, previsiblement ~1360s pour fr+en combines) - confiance nettement retablie sur les techniques auparavant en echec au spot-check manuel (sweat ~0.99). Consequence directe : le temps de demarrage du service passe d'environ 11 a environ 23 minutes. start_period (docker-compose.yml) et le timeout d'attente /health (ci.yml) releves de 900s a 1800s en consequence. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(recipes): reequilibre le corpus via substitution de synonyme plutot que du remplissage generique Deux tentatives precedentes de porter chaque technique a 20 utterances ont mesurablement degrade le F1 agrege (tech-step-eval.test.ts, 0.80 -> 0.79/0.791) au lieu de l'ameliorer : le generateur reposait surtout sur des tournures modales generiques ("il faut ...", "make sure to ..."), partagees identiquement par les 74 classes - un textcat bag-of-words lit ca comme une separabilite reduite entre classes, pas un padding neutre. augment_utterances.py revu : priorite a la substitution de synonyme (l'un des synonyms propres a la technique en tete d'une utterance existante, remplace par un autre - vocabulaire genuinement distinctif), les tournures modales ne servant plus qu'de complement limite (5 par locale, pas 12). Resultat : 13 a 20 utterances par technique/locale (moyenne ~19.7), contre un forcage uniforme a 20 qui necessitait un remplissage generique disproportionne pour les techniques au vocabulaire propre pauvre (julienne, sweat, bainMarie - precisement celles qui echouaient). Confiance mesuree nettement retablie sur ces techniques (sweat ~0.99, bainMarie ~0.98, julienne ~0.88). tests/test_training_data_balance.py : plancher abaisse a 12 (vise 20, garanti seulement si le vocabulaire propre de la technique le permet sans repasser par le piege ci-dessus) ; suppression de l'exigence fr/en egaux, plus vraie avec cette strategie (le potentiel de substitution differe naturellement entre les deux langues). Suite complete locale : 35/35 verts (22m26s). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * revert(recipes): annule le reequilibrage du corpus d'entrainement du textcat Trois strategies de generation differentes (tournures modales generiques, tournures reduites + substitution de synonyme, substitution de synonyme en priorite) ont ete tentees pour porter chaque technique a 20 utterances par locale. Les trois degradent mesurablement le F1 agrege contre TECH_STEP_EVAL_DATASET (tech-step-eval.test.ts) en dessous du seuil 0.8 : 0.7999 -> 0.791 -> 0.744 (chaque tentative pire que la precedente). tech-step-eval-runner.ts documente explicitement ce seuil comme calibre avec une marge deja tres etroite (0.8 pour un score mesure a 0.815) et previent contre le fait de l'assouplir pour accommoder un classifieur plus faible plutot que de corriger le probleme de fond - assouplir le seuil ou le jeu d'evaluation pour faire passer cette PR irait a l'encontre de cette convention documentee du projet. Revient a l'etat d'avant tout reequilibrage (corpus a 3-7 utterances/ technique, _TRAINING_ITERATIONS=25, timeouts a 900s) - le dernier etat confirme vert en CI sur cette branche. Ameliorer reellement l'equilibre du corpus necessite du contenu redige a la main et verifie technique par technique contre ce meme F1, pas une generation programmatique en bloc. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(recipes): reequilibre le corpus via substitution de synonyme plutot que du remplissage generique Trois tentatives precedentes d'egaliser chaque technique a 20 utterances ont toutes degrade le F1 agrege sous 0.8 (voir le commit revert precedent). Nouvelle strategie, beaucoup plus conservatrice : egalise chaque technique vers le maximum DEJA present dans le corpus (7 en fr, 5 en en, portes par cook/preheat), pas vers un nombre choisi dans l'absolu - +3-4 utterances en moyenne par technique au lieu de +13-17. augment_utterances.py (nouveau, reutilisable) genere le complement en priorite par substitution de synonyme (un des synonyms propres a la technique, en tete d'une utterance existante, remplace par un autre) - avec un garde-fou supplementaire par rapport aux tentatives precedentes : le synonyme de remplacement doit lui aussi etre a l'imperatif/infinitif, pas juste le synonyme d'origine, pour eviter de substituer un groupe nominal/adjectif ("a petit feu", "gros bouillons") a la place d'un verbe et produire une phrase grammaticalement cassee. Tournures modales uniquement en dernier recours pour les techniques dont le vocabulaire n'apparait qu'en milieu de phrase (julienne, brunoise...). Resultat : chaque technique a exactement 7 utterances en fr et 5 en en, sans exception (tests/test_training_data_balance.py fait respecter cet invariant). _TRAINING_ITERATIONS reste a 25 (inchange). start_period/ timeout d'attente /health releves de 900s a 1200s (temps d'entrainement mesure ~930s contre ~670s avant, la marge de securite existante etait devenue trop juste). Suite complete locale : 35/35 verts (14m41s). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * chore: retrigger CI (aucun run genere pour c7116d4, probable incident GitHub Actions) --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-26 19:50:52 +02:00
kyuno053	bf58834aa9	feat(recipes): migre la detection des tech steps de node-nlp vers un microservice Python spaCy ... * feat(recipes): migre la detection des tech steps de node-nlp vers un microservice Python spaCy Remplace TechStepClassifierService's node-nlp (NlpManager) par services/tech-step-intent-service, un microservice FastAPI/spaCy dedie (PhraseMatcher pour le NER par synonymes, textcat pour la classification d'intention). Corpus (TECH_STEP_TRAINING_DATA) toujours possede par apps/api, pousse au service via POST /v1/train a chaque warm-up ; le service ne touche jamais Postgres (meme posture que services/tech-step-llm-worker). Cote apps/api : - intent-service-client.ts : client HTTP vers le nouveau service - tech-step-matcher.ts : delegue NER + intent classification au client, logique pure (splitIntoClauses, seuil/fallback) inchangee - env.ts : INTENT_SERVICE_BASE_URL/INTENT_SERVICE_SECRET (secret requis, service coeur non optionnel) - server.ts : warm-up avec retry/backoff (service Python demarre a part) - scripts/calibrate-tech-step-threshold.ts : recalibration empirique de CONFIDENCE_THRESHOLD contre le jeu d'eval existant - node-nlp retire (package.json, node-nlp.d.ts, model.nlp du .gitignore) docker-compose.yml : nouveau service tech-step-intent-service (pas de port expose, healthcheck, app en depend). CI : job intent-service-test (pytest) + le job test demarre le service en arriere-plan avant la suite Mocha (jamais de mock d'un service interne, cf specs/dev-conventions.md). Verifie : 26/26 tests pytest du service (dont les offsets caracteres exacts de tech-step-matcher.test.ts), lint + build complets du monorepo, smoke test HTTP reel bout en bout. La suite Mocha et docker compose build/up n'ont pas pu etre executes dans cet environnement (pas de Postgres/Docker disponibles ici) — a confirmer via la CI et en local. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(recipes): corrige les matches dupliques et le timeout de warm-up des tests CI Deux bugs reels trouves par la premiere execution CI de la migration node-nlp -> tech-step-intent-service : 1. PhraseMatcher retourne tous les matches y compris chevauchants — un synonyme comme "fondre" litteralement contenu dans "faire fondre" (tous deux synonymes de `melt`) produisait deux candidats separes pour la meme technique, dupliquant son techStepId dans le resultat final. Fixe avec spacy.util.filter_spans (garde le plus long match par position) dans LocalePipeline.process. Test de non-regression ajoute. 2. La suite Mocha construit `app` directement via createApp(), sans jamais passer par server.ts — le warm-up (POST /v1/train fr+en sur le corpus complet) se declenchait donc paresseusement dans le premier test qui appelait le classifieur, depassant le timeout Mocha de 10s par test. Fixe par un root hook plugin Mocha (test-support/mocha-root-hooks.ts, .mocharc.json) qui reset la DB et warm up le classifieur une seule fois avant toute suite, avec son propre timeout de 60s. Verifie : 27/27 tests pytest du service (dont le nouveau test de non-regression), lint + build complets du monorepo. La suite Mocha elle-meme n'a toujours pas pu etre executee dans cet environnement (pas de Postgres disponible ici) — a confirmer via la CI. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * ci(temp): ajoute un run de calibrate-tech-step-threshold.ts pour observation Etape temporaire pour lire le sweep de seuils de confiance contre le vrai service tech-step-intent-service en CI (aucun Postgres/service disponible localement dans cette session) — sera retiree une fois CONFIDENCE_THRESHOLD recalibre dans tech-step-matcher.ts. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(recipes): recalibre CONFIDENCE_THRESHOLD pour le nouveau classifieur spaCy 0.75 (calibre a l'origine contre node-nlp) laissait de vrais verdicts corrects sur des clauses sans ancre NER (rien sur quoi retomber) sous le seuil : melt scorait 0.68 sur "jusqu'a ce que le beurre ait disparu dans la poele" (le cas motivant tout ce pipeline), preheat 0.52 sur "mettre la poele sur feu vif" — tous deux corrects, tous deux rejetes a 0.75. Recalibre a 0.45 : marge confortable au-dessus du bruit (texte anglais via le classifieur francais score ~0.04, indiscernable du hasard sur ~26 classes) et sous les deux cas ci-dessus. Confirme par calibrate-tech-step-threshold.ts contre TECH_STEP_EVAL_DATASET (F1 plafonne a 0.987 des 0.45, reste plat jusqu'a 0.95 — 0.45 est deja le seuil le plus bas qui capture tout le gain disponible). Retire l'etape CI temporaire de calibration (ci.yml) une fois la valeur choisie. Verifie : lint + build complets du monorepo, 27/27 pytest du service, sweep de seuils + verification manuelle contre le corpus reel en local (services Python, sans Postgres) et en CI. La suite Mocha complete reste a confirmer sur ce commit (executee en CI, pas localement — pas de Postgres disponible dans cet environnement). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(recipes): entraine le textcat plus longtemps pour une confiance reelle Cause racine du dernier test Mocha en echec (getAuditBatch flaguait "Faire mijoter a feu doux" comme peu fiable malgre une ancre NER claire) : avec seulement 30 iterations/dropout 0.2, le textcat retournait le bon intent (argmax correct) mais avec une confiance tres basse et compressee (0.2-0.7 sur l'ensemble du corpus reel, y compris des cas evidents) — un vrai probleme de qualite d'entrainement, pas seulement de seuil. 150 iterations / lot de 16 / dropout 0.1 (mesure localement contre le vrai corpus, sans Postgres) : melt ~0.95, preheat ~0.90, jusqu'a ~0.51 pour le cas le plus faible observe (bake), bruit hors-vocabulaire toujours ~0.05. ~110s d'entrainement par locale (~220s pour fr+en au warm-up) — compromis assume et documente (README du service, commentaires du code), contrairement a l'entrainement quasi instantane de node-nlp. Root hook Mocha (mocha-root-hooks.ts) et sa doc mis a jour avec un timeout de 600s pour couvrir cette duree avec marge. Verifie : 27/27 pytest, lint + build complets du monorepo. Suite Mocha a confirmer sur ce commit via CI (source du diagnostic qui a mene a ce fix). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(recipes): journalise chaque input/output du pipeline NLP Ajoute un logging JSON structure (meme convention que LoggerService cote apps/api) a services/tech-step-intent-service : chaque appel POST /v1/process journalise locale/texte en entree et entites/intent/score en sortie, chaque POST /v1/train journalise les uid entraines et les compteurs resultants. Chatter interne de spaCy mis a WARNING pour ne pas noyer ces lignes. Bug trouve et corrige en verifiant les octets bruts d'un log reel (pas juste son affichage terminal) : l'encodage par defaut de sys.stdout sur Windows produisait de vrais octets UTF-8 invalides pour tout texte accentue journalise (le francais des etapes de recette) — corrige par sys.stdout.reconfigure(encoding="utf-8") au demarrage. LOG_LEVEL configurable (INFO par defaut), documente dans le README du service et .env.example. Verifie : 30/30 pytest (3 nouveaux tests sur le formateur JSON), smoke test HTTP reel confirmant au niveau des octets que les caracteres accentues sont preserves, lint complet du monorepo. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(recipes): rapatrie le corpus NLP cote Python et l'enrichit de 48 techniques Changement d'architecture demande par l'utilisateur : le dataset d'entrainement (TECH_STEP_TRAINING_DATA) quitte apps/api pour vivre entierement dans services/tech-step-intent-service (intent_service/training_data.py). Ce service est desormais autonome : il s'entraine lui-meme une seule fois, a son propre demarrage (PipelineRegistry.initialize, dans le lifespan FastAPI), sans plus dependre d'un POST /v1/train pousse par apps/api (route supprimee). apps/api ne connait plus aucune technique/synonyme, uniquement le resultat de POST /v1/process. Corpus enrichi avec les 48 techniques du lexique fourni (Arroser, Appertiser, Braiser, Caraméliser, Confire, Julienne/Brunoise/Mirepoix/ Paysanne, Cuire à blanc/au bain-marie/à l'étouffée, Déglacer variantes, Emulsionner, Glacer, Pocher, Réduire, Suer, Zester, etc.), soit 74 techniques au total (26 + 48). Integration complete bout en bout : - reference-seed-data.ts : 48 nouvelles entrees TECH_STEPS - apps/web/locales/fr/translation.json : libelles francais correspondants - "Mitonner" fondu comme synonyme de simmer (pas une technique distincte, sa propre definition le dit) - "Blanchir un oeuf" (whiskPale) distingue de "Blanchir un legume" (blanch, existant) via des synonymes en phrase complete plutot qu'au mot nu — filter_spans (deja en place) resout la collision par specificite Impact performance mesure : le corpus elargi (74 classes vs 26) rend l'entrainement bien plus lent a nombre d'iterations egal (150 iterations depassait 17 minutes par run de test) — reduit a 40 iterations apres mesures repetees en local (~200s/locale, ~400s pour fr+en combines). docker-compose.yml (healthcheck start_period 600s), CI (timeout curl 600s) et le README du service documentent ce nouveau temps de demarrage. CONFIDENCE_THRESHOLD recalibre a 0.2 par verification manuelle (0.75 puis 0.45 ne tenaient plus compte tenu du nombre de classes) — marque explicitement comme placeholder en attendant une vraie repasse de calibrate-tech-step-threshold.ts (necessite Postgres, indisponible dans cet environnement). Verifie : 28/28 tests pytest du service (suite complete re-ecrite pour s'entrainer une seule fois par session sur le vrai corpus, fixture partagee dans conftest.py), lint + build complets du monorepo. La suite Mocha d'apps/api reste a confirmer via CI (le root hook mocha n'attend plus l'entrainement, seulement CI's propre attente sur /health). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(recipes): corrige l'assertion de taille du catalogue TechStep en dur test/reference.test.ts attendait exactement 26 techniques (l'ancien catalogue) au lieu de deriver la longueur attendue de TECH_STEPS (reference-seed-data.ts) — trouve par la CI apres l'ajout des 48 nouvelles techniques (74 au total). Seul echec du run CI precedent, le service Python (nouveau corpus, self-training) a lui demarre et repondu correctement dans le nouveau delai imparti. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(recipes): entraine le textcat plus longtemps pour une confiance reelle Suite a une revue de code sur locale_pipeline.py, trois ameliorations implementees et verifiees contre le vrai corpus (74 techniques) : - spacy.util.fix_random_seed(_TRAINING_SEED) avant nlp.initialize() — random.Random() ne graine que l'ordre de melange des exemples, pas l'init des poids/dropout internes de thinc. - _DiacriticsNormalizer deplace au-dessus de sa factory @Language.factory — plus d'annotation de type en chaine. - Log explicite (logger.warning) quand train() recoit moins de 2 labels et saute la creation du textcat, plus une clarification de la docstring de process() sur les deux cas menant a intent=None. - Early stopping avec suivi de la perte par epoque, _TRAINING_ITERATIONS restant le plafond. Mesure sur le vrai corpus : ne se declenche jamais dans le budget actuel de 40 iterations (la perte continue de baisser significativement jusqu'au bout) — documente honnetement comme filet de securite pour un futur relevement du plafond, pas un gain de temps aujourd'hui. Deux suggestions de la revue examinees et non retenues, avec justification en commentaire : le risque de desalignement pattern/texte via normalize_text (normalize_text opere par token deja tokenise, jamais sur la chaine brute — pas de risque de segmentation differente) ; passer a attr="LOWER" aurait au contraire regresse l'insensibilite aux accents que attr="NORM" fournit deliberement. Verifie : 28/28 pytest (dont le vrai corpus complet via la fixture partagee), lint du monorepo. Temps d'entrainement mesure stable (~200-230s/locale, dans la marge de bruit deja documentee). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(recipes): entraine le textcat sur les synonymes en plus des utterances Suite a une suggestion de revue de code : le textcat n'apprenait jusqu'ici que sur entry.utterances, jamais sur entry.synonyms (deja utilises pour le PhraseMatcher). Ajouter le mot-cle isole comme exemple positif de sa propre technique ameliore radicalement la confiance sur les cas ancres sans paraphrase entrainee. Mesures sur le vrai corpus (74 techniques) : - 40 iterations + synonymes (749 exemples vs 286 avant) : gain de confiance massif (simmer 0.25->0.60, cook 0.33->0.60, bake 0.34->0.86) mais temps d'entrainement multiplie par 2.6 (~535s/locale, ~17min combine pour fr+en — inacceptable). - 15 iterations + synonymes : retour a un temps raisonnable (~205s) mais qualite pire qu'avant (simmer/cook repassent sous le seuil de confiance) — les exemples supplementaires ne compensent pas la perte d'epoques a ce point. - 25 iterations + synonymes (retenu) : ~336s/locale (~670s combine), meilleur compromis — tous les cas mesures s'ameliorent par rapport a la config precedente (simmer 0.25->0.31, cook 0.33->0.38, bake 0.34->0.62, zest 0.64->0.66, julienne 0.56->0.76, compote 0.76->0.78), bruit hors-vocabulaire toujours negligeable (~0.02). CONFIDENCE_THRESHOLD releve de 0.2 a 0.25 (le cas le plus faible mesure est maintenant 0.31, avec plus de marge qu'avant). docker-compose.yml (start_period 900s) et la CI (timeout 900s) ajustes pour le nouveau temps de demarrage (~11 min pour fr+en combines, contre ~7 min avant). Deux autres pistes de la meme revue examinees et non retenues avec justification : classe __OTHER__/negatifs hors-domaine (le bruit mesure est deja bas, ~0.02, sans le symptome que cette classe corrige) et boost de score post-traitement si le NER confirme l'intention predite (casserait la garantie "score brut, jamais corrige par l'ancre" que services/tech-step-llm-worker's audit de faible confiance depend explicitement d'avoir, voir le commentaire de TechStepClauseClassification dans tech-step-matcher.ts). Verifie : 28/28 pytest (dont le vrai corpus complet, ~10.5 min pour la suite complete), lint + build du monorepo. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-26 09:03:52 +02:00
kyuno053	109dde9c7b	feat(shopping-list): liste de courses agrégée depuis le planning (#73) ... GET /shopping-list?date= (shopping-list.service.ts/.routes.ts) somme les ingrédients de chaque recette planifiée sur la semaine, mis à l'échelle par les portions de chaque créneau (PlanningItem.portions / Recipe.portions), regroupés par paire (ingredientId, unitId) — jamais null contrairement à GET /planning, une semaine vide redescend en items: []. Côté web, ShoppingListPage rend cette liste groupée par rayon (même IngredientCategory que IngredientPicker), triée alphabétiquement en français à l'intérieur d'un rayon (shopping-list.ts, logique pure extraite du composant). WeekNavigator (flèches + calendrier) est extrait de PlanningPage vers features/planning/ pour être partagé entre les deux pages ; ses libellés migrent de planning.* vers common.weekNav.*/ common.calendar.*/common.days.*, plus génériques pour une page qui n'est plus seulement le planning. ComingSoonPage retiré (plus aucun appelant, Liste de courses avait le dernier stub restant). Tests : Mocha (agrégation, mise à l'échelle par portions, unités non fusionnées) + Cucumber (shopping-list.feature : liste vide, groupement/tri, navigation de semaine) + mise à jour de layout.cy.ts/planning-page.cy.ts pour le nouveau rendu. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-22 22:45:06 +02:00
kyuno053	520e539fe6	fix(recipes): active le matching ingredients/unites pour les sources en francais (#72) ... Cause racine du signalement "beaucoup d'ingredients ne sont pas linkes, de meme pour les unites et les quantites" sur Marmiton/750g/Manger Bouger : translateRecipe (recipe-translation.ts) ET previewSourceItem (sources.service.ts) sautaient integralement loadIngredientCatalog/ loadUnitCatalog/translateRecipeIngredients des que locale !== "en" — aucune tentative de matching n'etait jamais faite pour une source francaise, pas un probleme de qualite de matching. Les trois sources ajoutees dans cette session sont toutes locale: "fr". Corrige en trois temps : - packages/shared/src/data/catalog-labels-fr.ts (nouveau) : INGREDIENT_LABELS_FR (554 entrees, copiees depuis apps/web/src/locales/fr/translation.json qui les avait deja pour l'UI — pas une nouvelle redaction), INGREDIENT_LABEL_SYNONYMS_FR (mecanisme existant, pour patcher au cas par cas les libelles dont le phrasage "affichage" ne correspond pas a l'ordre naturel d'un texte de recette — ex. vanillaBean), UNIT_LABELS_FR (17 entrees, redigees a la main comme UNIT_LABELS_EN — abreviations/variantes reellement utilisees en francais : cuillere a soupe/cas/c.a.s...). - ingredient-matcher.ts : stemWord se scinde en stemWordEn/stemWordFr (locale parametrable, defaut "en" pour ne rien casser) — le stemmer anglais appliquait sa regle "es" -> "" a des pluriels francais reguliers ("carottes" -> "carott" au lieu de "carotte"), cassant silencieusement le matching pour la quasi-totalite des ingredients francais dont le singulier se termine par une voyelle. matchUnit est reecrit pour chercher une sous-sequence ordonnee (comme matchIngredientName) plutot qu'une egalite du seul premier mot : un synonyme francais peut etre multi-mots ("cuillere a soupe"), une phrase entiere ne pouvant jamais egaler un seul mot extrait. loadIngredientCatalog/loadUnitCatalog prennent un parametre locale. - recipe-translation.ts/sources.service.ts : suppression du if (locale !== "en") qui court-circuitait tout — les catalogues sont desormais toujours charges avec la locale de la source ; une locale sans table de libelles recoit simplement des catalogues vides (degrade gracieusement, ne plante pas). Tests : 14 nouveaux tests purs (matchIngredientName/matchUnit fr, stemmer, regression), 3 nouveaux tests DB (loadIngredientCatalog/ loadUnitCatalog fr + locale inconnue), 3 nouveaux tests recipe-translation remplacant un test qui figeait l'ancien comportement cassé, 1 nouveau test d'integration HTTP (sources.test.ts) avec un adaptateur factice francais bout en bout. Les tests DB n'ont pas pu etre executes localement (pas de Postgres/Docker dans cet environnement sandbox) — a verifier en CI. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-22 20:34:32 +02:00
kyuno053	88666f0ac5	fix(recipes): corrige la liste vide de sevenFiftyGAdapter quand le filtre est vide (#68) ... L'endpoint IA que list() utilisait pour toute recherche (SEARCH_URL, /genius/query/) répond avec un corps de réponse vide dès que query est vide — vérifié en direct. Résultat : parcourir la source 750g sans filtre ne remontait jamais aucune recette. Corrigé en lisant un endpoint différent quand query est vide/absent : dernieres-recettes.htm, le vrai catalogue paginé "dernières recettes" de 750g.com (pagination réelle via &page=N, contrairement à l'endpoint de recherche). nextCursor suit désormais cette même distinction : toujours null pour une recherche par texte (l'endpoint ne pagine pas), calculé normalement pour le parcours sans filtre (une page sans aucune carte en est le signal de fin, cet endpoint ne renvoyant ni 404 ni redirection une fois la dernière page dépassée). Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-22 20:08:28 +02:00
kyuno053	5ea1026151	feat(recipes): adaptateurs RecipeSourceAdapter pour Marmiton, 750g et Manger Bouger (#67) ... * feat(recipes): ajoute un adaptateur RecipeSourceAdapter pour Marmiton Étend jsonLdRecipeAdapter (json-ld-recipe.ts) plutôt que de dupliquer sa logique : marmitonAdapter délègue fetchDetail/parse directement à l'adaptateur générique JSON-LD (une page recette marmiton.org expose un Recipe schema.org standard), et n'ajoute que ce que l'adaptateur générique ne peut pas offrir — un list() qui lit l'ItemList schema.org embarqué sur la page de résultats de recherche de marmiton.org (pagination via &page=N, fin de résultats détectée via la réponse 404 renvoyée au-delà de la dernière page). extractJsonLdBlocks est exporté depuis json-ld-recipe.ts pour être réutilisé par marmiton.ts sans dupliquer le regex d'extraction des blocs <script type="application/ld+json">. Enregistre marmitonAdapter dans registerAllRecipeSources (sources/index.ts) — contrairement à jsonLdRecipeAdapter lui-même, c'est un adaptateur concret par site, donc une Source household-toggleable légitime. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(recipes): ajoute un adaptateur RecipeSourceAdapter pour 750g Suit le même schéma que marmitonAdapter (construit sur jsonLdRecipeAdapter), avec deux différences propres à 750g.com : - list() n'a pas d'ItemList JSON-LD à lire sur ses résultats de recherche (la recherche du site est un widget client-side) — appelle donc directement le endpoint GET que ce widget interroge lui-même en interne (un « moteur de réponse IA » qui renvoie un lot de recettes pour une requête en texte libre), et scrape les cartes de résultat par regex en associant à chaque lien de recette sa dernière image précédente plutôt qu'un zip naïf par index (des images décoratives sans carte associée existent réellement dans ce fragment). Vérifié en direct : demander une « page 2 » revient toujours vide, donc nextCursor vaut toujours null, comme theMealDbAdapter. - parse() ne délègue pas aussi directement à jsonLdRecipeAdapter.parse que marmitonAdapter — le générateur JSON-LD de 750g.com a deux bugs réels : des caractères de contrôle bruts non échappés dans certaines chaînes JSON (~1 recette sur 3 dans un échantillon vérifié en direct, sinon JSON.parse échoue et jsonLdRecipeAdapter rapporte à tort « aucun Recipe trouvé »), et un texte parfois doublement encodé en entités HTML (ex. un vrai « é » devient &amp;eacute; au lieu de &eacute;). Les deux sont corrigés en pré/post-traitement autour de la même délégation, pas une réimplémentation. Enregistre sevenFiftyGAdapter dans registerAllRecipeSources (sources/index.ts), au même titre que marmitonAdapter. Complète aussi test/sources/sources-index.test.ts, qui ne couvrait encore que TheMealDB malgré l'ajout de Marmiton dans une PR précédente. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(recipes): ajoute un adaptateur RecipeSourceAdapter pour Manger Bouger Suit le même schéma que marmitonAdapter/sevenFiftyGAdapter (construit sur jsonLdRecipeAdapter), avec des différences propres à mangerbouger.fr (« La Fabrique à Menus », Santé publique France) : - list() n'utilise pas de JSON-LD du tout — la page de résultats (une app Next.js) n'embarque aucun ItemList. Elle est cependant rendue côté serveur et expose le même state Redux que le client hydrate, via un <script id="__NEXT_DATA__">, qui contient déjà tout ce dont list() a besoin (slug/nom/image, pagination). Vérifié en direct : ?query=<texte libre> filtre bien côté serveur, et hasMorePages donne un signal de fin de pagination plus propre que le 404 de Marmiton ou l'absence de vraie pagination de 750g. - parse() délègue à jsonLdRecipeAdapter mais corrige deux lacunes réelles et systématiques de son propre JSON-LD (vérifiées sur 9 recettes, 72 étapes) : recipeInstructions[].text est un document Slate.js sérialisé en JSON (pas du texte) plutôt qu'être aplati ; recipeYield est absent partout alors que le nombre de portions existe bien côté site (__NEXT_DATA__) — les deux sont corrigés par un patch structuré (parse → mutation → réécriture) avant délégation, pas une réimplémentation. Enregistre mangerBougerAdapter dans registerAllRecipeSources (sources/index.ts) et complète sources-index.test.ts. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-22 19:01:46 +02:00
kyuno053	92bea914e8	feat(tech-steps): fiabilise la détection des tech steps (corpus + LLM + corrections utilisateur) (#66) ... * feat(tech-steps): fiabilise la detection des tech steps (corpus + LLM + corrections utilisateur) Une seule feature livree en une seule PR, en 5 phases : - Phase 1 : enrichit le corpus NLP (tech-step-training-data.ts) et ajoute un harness d'evaluation (precision/rappel/F1) avec un jeu de test etiquete - la premiere metrique objective de qualite pour ce classifieur. - Phase 2 : schema Prisma (StepTechStepCorrection, TechStepTrainingSuggestion) + endpoints utilisateur (POST/GET corrections, ouverts a tout viewer, pas seulement l'auteur) + endpoints internes /internal/tech-steps/* proteges par secret partage (requireInternalWorker). - Phase 3 : UI de highlight/correction cote web (selection de texte -> association a une technique, ou clic sur un highlight existant pour le corriger/supprimer) - verifiee via Cypress (component + e2e, en Chrome reel). - Phase 4 : worker LLM autonome (services/tech-step-llm-worker, hors du monorepo pnpm comme experiments/llm-tech-step-poc) qui audite les clauses a faible confiance et transforme les corrections utilisateur en suggestions d'entrainement, sans jamais toucher le chemin interactif. - Phase 5 : script retrain-tech-steps.ts (gate de regression F1 + backfill) et list-pending-training-suggestions.ts pour la revue humaine avant application au corpus. Verification effectuee cette session : tsc/biome sur l'ensemble du repo, build complet (pnpm build), suite Cypress complete (component 39/39, e2e 75/76 - le seul echec est preexistant et sans rapport, cote recipe-form.feature/ingredient-picker), tests unitaires du worker (6/6) et son install/typecheck reels contre node-llama-cpp. Les tests Mocha d'apps/api (Phases 1 et 2) n'ont pas pu etre executes dans cette session (pas de Postgres local disponible) - a lancer avant merge. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(tech-steps): calibre le seuil F1 sur une vraie execution et corrige un bug de comptage Docker etant redevenu disponible dans cette session, j'ai pu lancer pour de vrai la suite Mocha d'apps/api (334/334, y compris les tests Phase 1/2 qui n'avaient pu etre executes precedemment) ainsi que les scripts de la Phase 5 contre une vraie base de test. - tech-step-eval-dataset.ts : corrige un vrai bug d'auteur - "Take the plates..." collisionnait avec le synonyme anglais enregistre "plates" (technique plate), invalidant ce cas negatif. Remplace par "dishes". - tech-step-eval-runner.ts : F1 reel mesure = 0.815 (33 TP / 9 FP / 6 FN). Documente ce chiffre et les vraies erreurs de classification decouvertes (ex: "Blanchissez les haricots verts..." classifie a tort comme "peel") - des faiblesses reelles du classifieur que ce harness est cense detecter, pas a masquer en ajustant le jeu de test. - retrain-tech-steps.ts : le script loggait `appliedIds.length`/ `rejectedIds.length` (ce qui a ete demande) au lieu du `count` reel retourne par `updateMany` (ce qui a vraiment ete modifie) - un id inexistant faisait afficher un faux succes. Decouvert en executant le script pour de vrai avec des ids partiellement invalides. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(tech-steps): corrige un span de correction incorrect sur un highlight existant Bug reel trouve en lancant l'application pour de vrai et en cliquant sur un highlight existant : la correction soumise couvrait presque toute la description au lieu du seul mot-cle cliqué (ex: [6, 56) au lieu de [6, 13) pour "mijoter"). Cause : StepDescription.tsx capturait `start` dans un `const` par iteration de `.map()` (correct), mais utilisait `offset` directement (la variable mutable partagee, pas une valeur capturee) pour `end` dans le gestionnaire onClick - une fermeture classique sur variable de boucle encore mutee. Par le temps ou l'utilisateur clique reellement (bien apres la fin du rendu), `offset` contient sa valeur finale (fin de la description entiere), pas celle du segment concerne. Corrige en capturant `end` dans un `const` au meme endroit que `start`. Renforce aussi l'assertion e2e correspondante (recipes.ts) qui ne verifiait auparavant que la requete avait ete faite, jamais son contenu - elle serait passee malgre ce bug. Verifie en conditions reelles : recette creee via l'UI, correction soumise, span persiste verifie directement en base (start=6, end=13, previous=simmer, corrected=grill). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * chore: ignore les telechargements Cypress (artefact de run local) * feat(tech-steps): distingue les corrections manuelles des détections auto Les corrections utilisateur (via TechStepCorrectionPopover) sont désormais écrites directement dans StepTechStep, avec une colonne `source` ("auto" | "manual") qui les distingue des matches du classifieur NLP : - Migration `step_tech_step_source` ajoutant `source` (défaut "auto") - `applyManualCorrection`/`renumberStepTechSteps` dans recipe-tech-step-correction.service.ts : une correction met à jour ou crée l'entrée StepTechStep concernée (source "manual"), la réponse de l'endpoint inclut désormais le techSteps à jour du step (SubmitTechStepCorrectionResult), pas seulement l'audit de correction - backfill-tech-steps.ts préserve les entrées "manual" existantes : seules les entrées "auto" sont recalculées, et un nouveau match auto chevauchant une correction manuelle est ignoré plutôt qu'inséré en doublon — vérifié en base réelle (une correction manuelle survit intacte à un backfill complet) - Le front distingue visuellement les deux (StepDescription.tsx, recipes.scss : `.step-tech-step--manual`, couleur Turmeric au lieu de Basil), avec un tooltip "(correction manuelle)" et un indicateur de découvrabilité de la fonctionnalité dans RecipeDetailPanel Corrige aussi deux bugs trouvés en testant en conditions réelles : - StepDescription.tsx : le clic sur un highlight existant lisait la variable `offset` (mutable, partagée par la boucle) au lieu d'une valeur capturée, envoyant un `end` erroné (fin de la description entière au lieu du span du mot cliqué) - backfill-tech-steps.ts : le garde `import.meta.url === file://${process.argv[1]}` ne matche jamais sur Windows (chemins à antislash), le script ne faisait donc rien en exécution directe ; remplacé par `pathToFileURL(process.argv[1]).href` 335 tests apps/api passants, 40/40 composants Cypress, 75/76 e2e Cypress (1 flake pré-existant sans rapport, non touché ici). * fix(worker): corrige le build Docker de tech-step-llm-worker docker compose build tech-step-llm-worker échouait sur deux problèmes en cascade, tous deux liés à l'isolation volontaire de ce service hors du monorepo pnpm (seul son propre package.json/tsconfig.json est copié dans son contexte de build) : - pnpm install --ignore-workspace --frozen-lockfile échouait (ERR_PNPM_IGNORED_BUILDS) : sans "packageManager" dans son package.json, corepack télécharge le pnpm le plus récent (11.22.0), qui a durci en erreur bloquante ce qui n'était qu'un avertissement sur les builds de dépendances ignorés (esbuild/node-llama-cpp). Le reste du repo est épargné parce que apps/api/Dockerfile copie le package.json racine, qui pinne déjà pnpm@10.12.4 — ce pin ne pouvait pas atteindre ce service isolé. Fixé en pinnant la même version ici. - tsc échouait ensuite (TS5083 puis erreurs en cascade dans les .d.ts de node-llama-cpp) : tsconfig.json de ce service extends le tsconfig.base.json racine (skipLibCheck notamment), jamais copié dans le contexte de build. Fixé en le copiant avant tsconfig.json. Vérifié : `docker compose build tech-step-llm-worker` complet en local. * fix(tech-steps): empêche le contexte d'un match d'avaler une correction manuelle voisine La correction manuelle ne s'affichait pas quand elle portait sur du texte qui n'était pas une technique à l'origine — reproduit en live : une description avec un seul match auto-détecté ("mijoter") voit son contexte de clause s'étendre sur toute la description dès que splitIntoClauses (tech-step-matcher.ts) n'a trouvé qu'un seul candidat NER (le cas courant), même quand ce candidat n'a aucun rapport avec le reste du texte. splitDescriptionByTechSteps avançait alors son curseur jusqu'à la fin de ce contexte large, ce qui faisait purement et simplement disparaître (silencieusement, sans erreur) toute correction manuelle ajoutée plus loin dans la même description — un mot pourtant sans aucun rapport avec la technique auto-détectée. Le contexte d'un match est purement cosmétique (StepDescription.tsx le rend identique à du texte brut depuis que sa mise en valeur dédiée a été désactivée) et ne doit donc jamais coûter son propre highlight à un *autre* match. splitDescriptionByTechSteps distingue maintenant deux notions : le chevauchement entre les spans *keyword* stricts de deux entrées (toujours un vrai conflit, l'entrée la plus tardive est toujours ignorée, comportement inchangé) et le chevauchement du contexte *cosmétique* d'une entrée sur le keyword d'une autre (jamais un vrai conflit désormais : le contexte est simplement rogné pour laisser la place, plutôt que l'entrée voisine entière étant abandonnée). Vérifié en conditions réelles (Docker) : une correction manuelle sur "materiel" dans "Faire mijoter la sauce, puis ranger le materiel." s'affiche maintenant correctement à côté du highlight auto "mijoter", et survit à un rechargement complet de la page. Nouveau test de régression dans highlight-tech-steps.cy.tsx reproduisant exactement ce cas ; les 18 tests du fichier (dont tous les cas de contexte/malformation déjà couverts) passent toujours. --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-22 15:57:57 +02:00
kyuno053	0e0fd81563	feat(api): remplace la détection des tech steps par un pipeline NLP (node-nlp) (#63) ... * feat(api): remplace la détection des tech steps par un pipeline NLP (node-nlp) Le matching par regex ne généralisait jamais au-delà de son propre vocabulaire — une étape décrivant la fonte du beurre comme "jusqu'à ce que le beurre ait disparu dans la poêle" ne contient aucun verbe sur lequel une regex pourrait s'ancrer, alors que le sens est sans ambiguïté. Nouveau pipeline en 3 étapes (TechStepClassifierService, node-nlp 4.27.0 — la 5.x est encore alpha, non retenue) : 1. NER (entités enum) trouve les mentions candidates + leur position exacte, à partir de listes de synonymes (tech-step-training-data.ts) plutôt que de regex écrites à la main. ner.threshold: 1 (exact, après normalisation) — le défaut à 0.8 faisait matcher "faire" (verbe auxiliaire omniprésent) contre "frire" par pure proximité de chaîne. 2. La description est découpée en clauses autour de ces candidats (splitIntoClauses, pure/testable sans modèle). 3. Le NlpManager classe chaque clause individuellement, entraîné sur des phrases qui n'emploient jamais le verbe de la technique — c'est ce qui apporte la compréhension du sens. En dessous de CONFIDENCE_THRESHOLD (0.65, ajusté empiriquement), retombe sur la technique impliquée par l'ancre NER plutôt que d'abandonner un match clairement ancré sur un mot-clé. TechStepMapping (table de regex par technique/locale) supprimée — migration 20260821130000_drop_tech_step_mapping — plus aucune table n'est interrogée à l'exécution, les données de matching vivent en code. TECH_STEPS (reference-seed-data.ts) simplifié en simple liste de uid, les mappings ayant disparu. Deux pièges trouvés en construisant ce pipeline, corrigés à la source : - db/prisma.ts construisait PrismaClient sans importer config/env.ts — un run de test isolé pouvait faire gagner la course au .env interne de Prisma (dev) contre .env.test. Fixé en important config/env.js en tout premier, pour effet de bord. - NlpManager a autoSave/autoLoad: true par défaut — persiste le modèle entraîné dans model.nlp et le recharge au lieu de ré-entraîner au prochain démarrage. Les deux désactivés explicitement (sinon un modèle obsolète masquerait silencieusement toute mise à jour du corpus/seuil) ; model.nlp ajouté au .gitignore en garde-fou. apps/api/src/db/prisma.ts, recipe.service.ts, sources.service.ts et recipe-translation.ts adaptés à la matching async (le classifieur entraîné remplace le couple loadTechStepMappingRules+matchTechStepSpans synchrone) ; server.ts appelle techStepClassifier.warmUp() avant d'accepter du trafic (le tout premier appel réel à NlpManager.process() charge les ressources par langue de node-nlp, plusieurs secondes). Vérifié : tsc --noEmit, biome check (0 erreur), build complet des 6 packages, 308 tests API (dont un test-support/reset-db.ts corrigé — référençait encore tech_step_mapping dans son TRUNCATE). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(api): ajoute la délimitation de contexte aux tech steps et étoffe le vocabulaire du classifieur Deux évolutions du pipeline NLP de détection des tech steps (PR #63) : 1. Délimitation de contexte — en plus du mot-clé qui déclenche un match (start/end), chaque TechStepMatch porte maintenant contextStart/ contextEnd : la clause complète autour du mot-clé (ex : "poêle chaude" comme mot-clé, "Dans une poêle chaude" comme contexte). Persisté sur StepTechStep (colonnes nullables, migration dédiée), exposé via StepTechStepView, et rendu côté web avec un style plus discret que le mot-clé (StepDescription.tsx, .step-tech-step-context). splitIntoClauses coupe désormais sur l'espace le plus proche du milieu de l'écart entre deux candidats plutôt que sur le milieu brut, pour ne jamais couper un mot en deux (findGapSplitPoint). 2. Vocabulaire du classifieur — synonymes et locutions supplémentaires par technique (FR/EN) pour fiabiliser la détection sur des formulations que le corpus initial ne couvrait pas. Plusieurs bugs de fond trouvés et corrigés en cours de route, tous confirmés par la suite de tests complète (309 tests) : - un synonyme multi-mots qui est un préfixe-mot d'un synonyme plus court déjà enregistré pour la même technique fait matcher les deux comme candidats NER distincts et chevauchants, corrompant le découpage en clauses (parfois jusqu'à une mauvaise classification) — retiré partout où ce motif a été repéré (cook, fry, deglaze, simmer, boil, roast, chop, mince, marinate, preheat, bake, plate, coat) ; - "poêlé"/"poêlée" comme synonymes de panFry sont réduits à la même racine que le nom "poêle" par le stemmer français de node-nlp, provoquant un faux positif sur toute mention nue de "poêle" (dont celle de preheat) — retiré ; - "Fouetter les blancs en neige" était mal classé en foldIn (la phrase d'entraînement de foldIn partage la même locution) — corrigé en ajoutant des phrases d'entraînement dédiées à whisk ; - "Émincer les tomates" est passé sous le seuil de confiance vers melt après l'ajout du nouveau vocabulaire ailleurs dans le corpus — corrigé en élargissant les phrases d'entraînement de mince à un autre légume. Le test unitaire de splitIntoClauses avec un point de coupure obsolète (pré-datant findGapSplitPoint) est aussi corrigé. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(api): corrige la découpe des clauses et le seuil de confiance du classifieur de tech steps Trouvé en examinant des vraies recettes déjà en base après le dernier étoffement du vocabulaire : plusieurs étapes bien réelles se faisaient classer sur la mauvaise technique, sans lien avec un mot-clé manquant. - splitIntoClauses coupe désormais sur la limite de phrase (juste après un ".", "!" ou "?") la plus proche du milieu de l'écart entre deux candidats quand il y en a une, plutôt que sur l'espace brut le plus proche du milieu. Une description à deux techniques dans deux phrases distinctes ("Préchauffer le four à 180°C. Dans un saladier, mettre le beurre... et mélanger.") ne coupait qu'au milieu brut, ce qui pouvait trancher en pleine deuxième phrase et envoyer au classifieur une clause tronquée ("...(thermostat 6). Dans un saladier, mettre" sans complément) — assez éloignée des phrases d'entraînement courtes et complètes pour se faire mal classer avec confiance (préchauffer prédit "mix", mélanger prédit "melt"). - CONFIDENCE_THRESHOLD passe de 0.65 à 0.75 : du texte anglais passé dans le classifieur français (qui doit ne rien trouver, garanti par le test d'isolation des locales) scorait 0.69 sur "boil" — du bruit de petit corpus, pas un vrai verdict. Les cas réels que ce seuil sert à faire confiance scorent 0.91 à 1.0 en pratique ; 0.75 sépare proprement le bruit du signal sans rien casser (309 tests toujours verts). - Deux phrases d'entraînement ajoutées à `cook` pour deux clauses réelles mal classées (feu doux + remuant, découvert + laisser cuire) qui n'avaient pourtant pas de mot-clé manquant. Ajoute aussi src/scripts/backfill-tech-steps.ts : la détection ne tourne qu'à la création/modification d'une recette, jamais rétroactivement — ce script recalcule le start/end/contextStart/ contextEnd de chaque étape existante contre le classifieur actuel, pour ne pas avoir à rouvrir et resauvegarder chaque recette à la main après un changement de corpus. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(web): rend le contexte des tech steps réellement visible Le style existant (fond teinté à 6% d'opacité, sans autre indice visuel) était structurellement correct — vérifié en base, l'API et le DOM contenaient bien les spans de contexte — mais imperceptible à l'œil sur ce thème sombre : --color-primary n'est pas assez saturé pour qu'une teinte de quelques % se distingue du fond de la carte. Vérifié en créant une recette test dans le navigateur et en zoomant le texte rendu : littéralement aucune différence visible avant, un rectangle net après. Passe à 10% de fond + une bordure basse pleine à 45% d'opacité comme second indice visuel indépendant, tout en gardant le mot-clé (soulignement pointillé + fond à 14% + curseur + tooltip) nettement plus marqué que son contexte. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(web): retire l'affichage visuel du contexte des tech steps Ne touche que le rendu — le backend continue de calculer et de persister contextStart/contextEnd (tech-step-matcher.ts, StepTechStep), et splitDescriptionByTechSteps continue de découper la description autour du contexte (segments isKeyword: false). StepDescription.tsx rend désormais ces segments comme du texte brut, comme un segment sans technique — plus d'encadré/bordure autour de la clause, seul le mot-clé reste surligné avec sa tooltip. .step-tech-step-context (CSS) retirée, devenue inutilisée. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-22 00:17:39 +02:00
kyuno053	5d63ff9ea9	fix: corrige les bugs ouverts du repo (import TheMealDB, sidebar mobile) + doc (#59) ... * fix(recipes): corrige plusieurs bugs d'import TheMealDB - Les instructions TheMealDB numérotées sur leur propre ligne ("1\n\ntexte...\n\n2\n\ntexte...") créaient des étapes parasites ne contenant qu'un chiffre — filtrées désormais (#52). - Un ingrédient compté sans mot d'unité dans le texte source (ex. "4 Egg Yolks") laissait l'import bloqué sur "Importer" indéfiniment, sans indication visuelle de la ligne en cause — matchUnit retombe maintenant sur l'unité générique "piece" quand une quantité a été extraite, et RecipeImportForm/RecipeFormPage surlignent désormais toute ligne dont l'unité manque, avec un message explicite (#53). - Ajout de INGREDIENT_LABEL_SYNONYMS_EN pour reconnaître des formulations alternatives fréquentes chez les sources anglophones ("vanilla pod" en plus de "vanilla bean") sans élargir INGREDIENT_LABELS_EN à un tableau pour ses ~550 entrées (#54). - Effet de bord découvert en vérifiant #53 de bout en bout : deux lignes source résolues vers le même ingrédient catalogue (ex. "Egg Yolks"/"Eggs" -> "Œuf") faisaient planter la création en 500 (contrainte unique recipe_id+ingredient_id) au lieu d'un 400 propre. createRecipeSchema rejette maintenant les ingredientId en double, et le formulaire d'import surligne les doublons avant même de soumettre. Vérifié de bout en bout dans le navigateur (import réel de la recette "Flan" depuis TheMealDB, jusqu'au planning) en plus des tests ajoutés. Closes #52, #53, #54 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(layout): la sidebar réduite écrasait la barre mobile `isCollapsed` (rail icône seule sur desktop) persiste dans localStorage indépendamment de la largeur de fenêtre — un utilisateur ayant réduit la sidebar sur desktop puis ouvrant la même session sur mobile (ou réduisant la fenêtre sous 640px) gardait `.app-sidebar.collapsed` (spécificité 0,2,0 : width 4.25rem, flex-direction column), qui l'emportait sur la règle mobile `@media (max-width: 640px)` (spécificité 0,1,0) censée passer la sidebar en barre horizontale pleine largeur. Le bloc `&.collapsed` est maintenant scopé sous `@media (min-width: 641px)` — le complément exact du breakpoint mobile — donc il ne s'applique plus du tout en dessous. Vérifié dans le navigateur : sidebar collapsed=true dans localStorage, viewport 375px — la sidebar calcule bien width: 375px / flex-direction: row (barre horizontale pleine largeur) au lieu de 4.25rem/column. Closes #27 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * docs(readme): documente GET /planning?date=, plus /planning/current 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 <noreply@anthropic.com> * docs: met à jour README et specs/ avec l'état réel du code Le code avait beaucoup évolué depuis la dernière mise à jour de la documentation (sources externes, import de recettes, planning en grille, pages de paramètres, thème, tests Cucumber...) sans que README.md/specs/*.md ne suivent. Tour complet du code (backend + frontend) et réécriture : - specs/batch-cooking-modele.md : schéma de données réécrit depuis schema.prisma (foyer/admin/invitation, sources, catalogue ingrédients/unités, techniques détectées, visibilité des recettes). - specs/backend-architecture.md : foyer, préférences/goûts, planning, référence, sources externes (adaptateurs/registre/sync), matching ingrédients/techniques, isolation base de test, suppression de compte. - specs/frontend-architecture.md : routing complet, sidebar/paramètres, thème, planning + picker, catalogue + import, composants UI partagés, tests Cypress+Cucumber. - specs/batch-cooking-architecture.md : module Import passe de TODO à implémenté. - specs/error-handling.md : liste complète des ~19 codes d'erreur. - README.md : réécriture pour refléter tout ce qui précède, plus la note (dangereusement obsolète) sur le partage base de test/dev — le fix existe déjà (apps/api/.env.test), la doc décrivait encore le bug. * feat(ingredients): ajoute jaune/blanc d'oeuf, coriandre en poudre, viandes hachées Complète le catalogue d'ingrédients de référence (seed data) : - jaune d'oeuf / blanc d'oeuf (dairyAndCheese/eggs, aux côtés d'"egg") - coriandre en poudre (condimentsAndSpices/spices, aux côtés de corianderSeeds/freshCilantro déjà présents) - viandes hachées manquantes : veau, porc, agneau (meatAndSeafood/meats, aux côtés de groundBeef déjà présent), dinde et poulet (meatAndSeafood/poultry) Libellés ajoutés dans apps/web/src/locales/fr/translation.json (source d'affichage) et packages/shared/src/data/catalog-labels-en.ts (matching anglais pour l'import de recettes depuis des sources comme TheMealDB). Aucune icône ni régime dédiés : héritent des défauts de leur groupe (EGG/SPICE/MEAT/POULTRY, mêmes dietUids que leurs groupes respectifs). 282 tests apps/api toujours au vert (resetDatabase() reseed le catalogue à chaque test). * fix(i18n): retire le œ ligaturé des libellés français de l'œuf "Œuf"/"Œufs" (ingrédient, sous-catégorie, allergène) et "Jaune/Blanc d'œuf" (ajoutés par #60) s'écrivaient avec le œ ligaturé — remplacé par "oe" (deux lettres) partout où le mot apparaît. Ne touche pas "bœuf" (mot différent, non concerné). Le scénario Cucumber recipe-form.feature qui sélectionne l'ingrédient par son libellé affiché est mis à jour en conséquence. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(recipes): concatène les ingrédients dupliqués à l'import Suite au retour utilisateur sur #53 (follow-up) : au lieu de bloquer l'import et de demander à l'utilisateur de retirer une ligne en double à la main, deux lignes source qui résolvent vers le même ingrédient catalogue sont désormais fusionnées automatiquement, quantité concaténée (sommée), avant même que l'écran de revue ne s'affiche. - mergeDuplicateIngredients (recipe-translation.ts) : même unité des deux côtés -> somme directe. Unité différente mais même UnitType (MASS/VOLUME) -> conversion via toBaseFactor avant de sommer, exprimée dans l'unité de la première ligne. UnitType différent, ou COUNT des deux côtés (une "pincée" n'est pas une fraction fixe d'une "gousse", cf. le commentaire de UnitView) -> jamais fusionnées, laissées en double (createRecipeSchema/RecipeImportForm continuent de les signaler, filet de sécurité déjà en place). Les lignes non résolues (ingredientId: null) ne sont jamais fusionnées entre elles. - rawText concaténé ("100g Sugar + 45g Sugar") pour la traçabilité. - Branché dans previewSourceItem (sources.service.ts), juste après translateRecipeIngredients — c'est le seul endroit où des doublons peuvent apparaître (la création manuelle ne peut pas en produire, IngredientPicker exclut déjà les ingrédients déjà sélectionnés). Vérifié via l'API en local (import réel de "Flan" depuis TheMealDB) : "100g Sugar"/"45g Sugar" -> une seule ligne Sucre, 145g. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * chore(lint): upgrade Biome vers 2.x, active noExplicitAny/noConsole/noFloatingPromises `@biomejs/biome` passe de 1.9.4 à 2.5.9 (config migrée via `biome migrate --write`) — nécessaire pour noFloatingPromises, une règle type-aware apparue en 2.0 (nursery). - noExplicitAny : déjà "recommended", actif depuis toujours, aucun changement. - noConsole (biome.json) : bloque tout `console.*` sauf error/warn/info/ debug/table/assert — équivalent à "pas de console.log" sans interdire les niveaux nommés (voir le nouveau log service dans le prochain commit, qui centralise justement ces appels). - noFloatingPromises (nursery) activé explicitement sous `rules.nursery` sans avoir besoin d'activer le domaine "types" au sens large (ça aurait aussi allumé des dizaines d'autres règles type-aware type noUnresolvedImports/noUnnecessaryConditions, hors scope ici). Le reste du diff, c'est soit du reformatage automatique (import sort, 2.x ordonne différemment de 1.9.4 — `biome check --write --unsafe`), soit les corrections des ~20 promesses flottantes que la nouvelle règle a fait remonter : - La plupart sont des `navigate(...)` non attendus (react-router v7 type `navigate` en `void | Promise<void>`) — préfixés `void navigate(...)`, aucun changement de comportement. - Trois chargements initiaux en useEffect (OnboardingAllergensPage, OnboardingDietPage, OnboardingHouseholdPage, HouseholdSettingsPage) n'avaient jamais de `.catch()` du tout — ajouté (dégradation silencieuse vers un état vide/par défaut, même raisonnement que le `.catch()` déjà présent dans OnboardingSourcesPage). - HouseholdSettingsPage : `loadHouse` était une fonction déclarée à chaque render (donc une référence différente à chaque fois) utilisée comme dépendance de useEffect ET passée en callback à des enfants — le useEffect se re-déclenchait donc à chaque re-render provoqué par son propre fetch, un vrai bug de boucle infinie de requêtes que noFloatingPromises a fait remonter indirectement (via useExhaustiveDependencies). Corrigé avec useCallback([]). - RecipeDetailPanel : une clé de liste `${index}-...}` sur une liste statique (draft.steps, sans id stable — DraftRecipeStepView n'en a pas) — biome-ignore justifié, pas de bug réel. - recipe.test.ts : variable `agent` non utilisée, retirée. Vérifié : `pnpm --filter api test` (295/295), `pnpm lint` et `pnpm build` clean sur tout le repo. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(api): ajoute un log service pour les logs de fonctionnement côté serveur Jusqu'ici, rien ne journalisait quoi que ce soit côté serveur : aucune trace au démarrage à part un console.log ad hoc, et surtout aucune trace des requêtes ni des erreurs gérées par ErrorHandlerService — un 500 en production n'aurait laissé aucune trace exploitable. - LoggerService (apps/api/src/lib/logger.service.ts) — classe (public debug/info/warn/error, private emit), même convention que ErrorHandlerService (packages/error-tools) : instance unique partagée exportée (`export const logger = new LoggerService()`). Émet une ligne JSON structurée par appel (timestamp/level/message + meta), filtrée par seuil selon NODE_ENV (debug complet en dev, warn+ pendant les tests pour ne pas alourdir la sortie de Mocha, info+ en production). Seul endroit du code autorisé à toucher `console` directement (biome-ignore justifié), toujours via une méthode nommée — jamais un console.log nu. - requestLogger (middlewares/request-logger.ts) — une ligne par requête terminée (méthode/chemin/statut/durée), montée en tout premier dans app.ts, avant même setupCore (CORS/JSON/cookies), pour englober tout le pipeline. Niveau déduit du statut (info/warn/error). - errorLogger (middlewares/error-logger.ts) — monté juste avant createErrorMiddleware : réutilise errorHandlerService.handle() (pur/ sans effet de bord) pour classifier l'erreur avant que la vraie réponse ne soit construite, log en warn les 4xx routiniers (validation, 404, 401...) et en error les 5xx/exceptions non prévues (avec la stack). - error-handler.service.ts : retire le `console.error(error)` ad hoc de fromUnknownError — errorLogger voit désormais chaque erreur avant que ce service ne la mappe, donc ce console.error faisait doublon (et loggait en texte brut, pas en JSON structuré). - server.ts : le console.log de démarrage passe par logger.info. Vérifié : pnpm --filter api test (303/303, dont 8 nouveaux tests sur LoggerService), pnpm lint/build clean, testé en live (pnpm dev:api + curl) — logs JSON corrects pour un 200, un 404, un 401. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * style: préfixe tous les membres private/protected par _ Convention demandée par l'utilisateur : `emit` -> `_emit`, sur toutes les classes du repo, pas seulement le nouveau code. `public` reste sans préfixe. - LoggerService (apps/api) : _minSeverity, _emit. - ApiClient (apps/web) : _request (39 sites d'appel mis à jour). - ErrorHandlerService (packages/error-tools) : _fromZodError, _fromHttpError, _fromUnknownError. - ExpressServer (packages/express-tools) : _app, _registeredRoutes. Aucun changement de comportement — pur renommage interne, aucune méthode private/protected n'était appelée depuis l'extérieur de sa classe. Vérifié : pnpm --filter api test (303/303), pnpm lint/build clean sur tout le repo (apps/api, apps/web, packages/*). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * docs(specs): documente les conventions de développement du repo Nouveau specs/dev-conventions.md — jusqu'ici ces règles n'existaient que dans l'historique de commits/PR (classes vs objets littéraux pour la logique de service, préfixe _ sur private/protected, règles Biome actives, log service, tests sans mocks de la DB, conventions git/PR...), rien de centralisé pour un futur contributeur (humain ou Claude Code). Référencé depuis README.md, section "Qualité / Tests". Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * refactor(web): regroupe pages/ par section au lieu d'un dossier à plat pages/ mélangeait 8 fichiers directement à sa racine (LoginPage, SignupPage, PlanningPage+scss, RecipesPage, RecipeFormPage, ImportRecipePage, ShoppingListPage, ComingSoonPage+scss) à côté de deux sous-dossiers déjà groupés (onboarding/, settings/) — incohérent, et difficile à parcourir une fois le nombre de pages monté. Un sous-dossier par section routée, même règle que onboarding/settings existants : - pages/auth/ — LoginPage, SignupPage - pages/planning/ — PlanningPage + planning-page.scss - pages/recipes/ — RecipesPage, RecipeFormPage, ImportRecipePage - pages/shopping-list/ — ShoppingListPage ComingSoonPage (+ .scss) déménage vers components/ui/ — ce n'est pas une page routée elle-même (ShoppingListPage l'enveloppe), c'est un composant UI générique réutilisable, sa place est aux côtés de Dialog/Tooltip/etc., pas dans pages/. Chemins relatifs internes de chaque fichier déplacé mis à jour (un niveau de profondeur en plus), imports dans App.tsx repointés, tri Biome réappliqué. specs/frontend-architecture.md mis à jour (arborescence + références de chemin). Vérifié : pnpm build clean (apps/web, 1952 modules), pnpm lint clean sur tout le repo, testé en live dans le navigateur (login/signup, planning, recettes, nouvelle recette, liste de courses, paramètres) — aucune route cassée. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * refactor(web): regroupe features/recipes/ par sous-domaine au lieu d'un dossier à plat 20 fichiers à plat -> badges/ (DietTagSelect, DietBadges, AllergenBadges, ReproducibleBadge, FavoriteStarButton), ingredients/ (IngredientPicker, IngredientRow, ingredient-icons), steps/ (StepListEditor, StepDescription, highlight-tech-steps), sources/ (RecipeSourcesPanel, SourceItemTable, RecipeImportForm, recipe-import-draft, useEnabledSources). RecipeTable/RecipeTabs/RecipeDetailPanel et recipes.scss restent à la racine (composants transverses aux sous-dossiers, partagés par plusieurs d'entre eux). Chemins relatifs corrigés dans les fichiers déplacés et chez tous leurs importeurs externes (pages/recipes/*, features/planning/ RecipePickerDialog.tsx, features/profile/DislikedIngredientsField.tsx), doc mise à jour (specs/frontend-architecture.md, specs/batch-cooking- modele.md). Vérifié : tsc --noEmit, biome check, build complet, 303 tests API, vérification live navigateur (planning, /recettes, /recettes/nouvelle). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * refactor(api): regroupe lib/ par sous-domaine au lieu d'un dossier à plat 9 fichiers à plat -> recipe-sources/ (recipe-source-adapter, recipe-source- errors, recipe-source-registry) et recipe-matching/ (recipe-translation, ingredient-matcher, tech-step-matcher). jwt.ts, safe-profile.ts et logger.service.ts restent à la racine de lib/ (pas de sous-domaine partagé avec les autres). Chemins relatifs corrigés dans les fichiers déplacés (profondeur +1 vers db/) et chez tous leurs importeurs (modules/sources, modules/recipe, sources/*, db/recipe-source-sync.ts, 12 fichiers de test), doc mise à jour (specs/backend-architecture.md, specs/batch-cooking-architecture.md). Vérifié : tsc --noEmit, biome check, build complet, 303 tests API. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * refactor(api): regroupe test/ par sous-domaine, miroir de src/lib/ 18 fichiers à plat -> recipe-matching/ (ingredient-matcher, recipe- translation, tech-step-matcher — miroir de lib/recipe-matching/), recipe-sources/ (json-ld-recipe, recipe-source, recipe-source-sync, the-meal-db — miroir de lib/recipe-sources/), sources/ (sources, sources-index — module + registration src/sources/index.ts). Les tests par domaine API sans regroupement naturel (auth, health, house, logger.service, planning, preferences, profile, recipe, reference) restent à la racine de test/, un fichier par domaine — même logique que jwt.ts/safe-profile.ts restés à la racine de lib/. Chemins relatifs corrigés (../src/ -> ../../src/, ../test-support/ -> ../../test-support/ dans les fichiers déplacés qui appellent resetDatabase). .mocharc.json ("test/**/*.test.ts") couvre déjà les sous-dossiers, aucun changement de config nécessaire. Vérifié : biome check, 303 tests API. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(convention): impose try/catch autour de chaque await/corps async Nouvelle règle de dev : aucun await nu, et un corps de fonction/méthode async doit intégralement vivre dans un try/catch (pas seulement la ou les lignes qui awaitent). Documentée dans specs/dev-conventions.md avec son périmètre (code applicatif — services/hooks/composants/middlewares — routes *.routes.ts exemptées car déjà couvertes par wrapAsyncHandler ; tests et scripts one-off exemptés aussi). Appliqué rétroactivement à tout le code applicatif qui ne l'était pas déjà : - api : auth/house/profile/preferences/planning/reference/recipe/ sources .service.ts, recipe-source-sync.ts, recipe-translation.ts, ingredient-matcher.ts, tech-step-matcher.ts, json-ld-recipe.ts, the-meal-db.ts — un try/catch par fonction async, rethrow simple (le middleware d'erreur logge déjà tout centralement, voir error-logger.ts) sauf quand un catch avait déjà une logique propre (ex. le retry de createHouse). - web : api/client.ts (_request), AuthContext.tsx, ThemeContext.tsx, AppLayout.tsx (handleLogout), HouseholdSettingsPage.tsx (handleCopy/ handleRemove/handleDelete/handleLeave) — la plupart des handlers de formulaire avaient déjà ce pattern, seuls ceux qui laissaient un await nu ont été corrigés. lint/complexity/noUselessCatch désactivé dans biome.json (interdisait justement le catch-qui-rethrow que cette convention impose). Vérifié : tsc --noEmit (api+web), biome check (0 erreur, repo entier), build complet, 303 tests API, vérification live navigateur (thème, déconnexion, copie du code d'invitation). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(web): corrige l'import cassé de highlight-tech-steps.cy.tsx Oubli lors du regroupement de features/recipes/ par sous-domaine (refactor(web): regroupe features/recipes/...) : le déplacement de highlight-tech-steps.ts vers features/recipes/steps/ n'avait pas été répercuté dans ce test composant Cypress (hors de apps/web/src, donc raté par la recherche de référence externe à l'époque) — faisait planter le job e2e en CI ("Failed to fetch dynamically imported module"). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-21 12:16:22 +02:00
Nicolas	17b6b9151a	fix(api): la garde resetDatabase() accepte aussi la base CI ... DATABASE_URL en CI (ci.yml) pointe vers "batchcooking_ci", pas "batchcooking_test" — la garde ne cherchait que "test" et rejetait donc la base CI légitime, faisant échouer les 282 tests. Accepte "test" ou "ci" désormais ; seul le nom réel de la base de dev ("batchcooking") ne matche toujours ni l'un ni l'autre, ce qui reste le seul cas que cette garde doit effectivement bloquer. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-20 19:59:16 +02:00
Nicolas	61ac2993db	fix(api): isole la base de test de la base de dev ... Incident : lancer `pnpm test` (apps/api) truncait la vraie base de dev locale — `test-support/reset-db.ts`'s `resetDatabase()` fait un `TRUNCATE ... CASCADE` sur quasiment tout le schéma (dont `house`/`house_source`) avant *chaque* test, et `.env`/tests partageaient le même `DATABASE_URL` (un seul fichier `.env`, `NODE_ENV=test` ne changeait rien). Deux lancements du test suite cette session ont ainsi effacé le foyer, le compte et les activations de sources d'un utilisateur en train de tester l'app en local — perte réelle, aucune récupération possible (TRUNCATE, pas de sauvegarde). - `config/env.ts` charge désormais `.env.test` (pas `.env`) quand `NODE_ENV=test` — `.env.test` (local, non commité, comme `.env`) pointe vers une base Postgres séparée (`batchcooking_test`, même serveur/identifiants que la base de dev, juste une base différente). `.env.test.example` documente comment la créer. - `resetDatabase()` refuse maintenant de tourner si `NODE_ENV !== "test"` ou si `DATABASE_URL` ne contient pas "test" — garde-fou supplémentaire si `.env.test` est un jour absent/mal configuré, pour ne plus jamais reproduire cet incident même en cas d'erreur de configuration. - `.gitignore` autorise `.env.test.example` (déjà ignoré via `.env.*`, comme `.env.example` l'est déjà pour `.env`). Vérifié : snapshot de la base de dev (houses/house_sources/users) avant/ après un lancement complet de `pnpm test` — identique, base de dev intacte. 282 tests toujours au vert, contre la nouvelle base de test. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-20 19:51:21 +02:00
Nicolas	e4c8d910d4	feat(recipes): écran de revue et finalisation de l'import (étape 3/4) ... Backend : - `createRecipe` refactorisé en fine enveloppe autour d'un nouvel helper interne `createRecipeInternal`, paramétré par une source d'import optionnelle ; nouvelle fonction exportée `createImportedRecipe` qui réutilise toute la validation ingrédients/unités/diets et le matching des tech steps, sans dupliquer cette logique. - La locale de l'adaptateur source est propagée jusqu'au chargement des `TechStepMapping`, pour que le texte anglais (TheMealDB, etc.) soit matché contre le bon jeu de règles au lieu du défaut français. - Nouvel endpoint `POST /sources/:sourceKey/import/:externalId` — valide le payload via `createRecipeSchema` (même schéma qu'une création manuelle) et persiste une vraie `Recipe` liée à la source (`sourceId`/`externalId`). - Nouveau code d'erreur `RECIPE_ALREADY_IMPORTED` (4022) quand l'item a déjà été importé pour ce foyer. Frontend : - `ImportRecipePage` (nouvelle page, `/recettes/importer/:sourceKey/:externalId`) — pré-remplit le formulaire depuis `previewSourceItem`, en miroir de `RecipeFormPage` (mêmes sous-composants : `IngredientRow`, `IngredientPicker`, `StepListEditor`, `DietTagSelect`). Ajoute une section dédiée aux lignes d'ingrédients non résolues automatiquement : l'utilisateur choisit un ingrédient réel via l'`IngredientPicker` existant ou retire la ligne — aucune recette invalide n'est jamais soumise, le bouton d'import reste désactivé tant qu'il en reste. - `SourceItemPreviewPanel` gagne un lien « Importer cette recette » vers cet écran. Tests : - Mocha (`apps/api/test/sources.test.ts`) : 6 nouveaux tests sur `POST /sources/:sourceKey/import/:externalId` (payload valide, ingrédient/unité inconnus, déjà importé, deux foyers distincts, locale de la source respectée pour les tech steps). 282 tests passent au total, aucune régression. - Cypress : nouveau scénario Gherkin bout-en-bout dans `recipe-sources.feature` (parcourir → prévisualiser → importer → résoudre un ingrédient non reconnu → confirmer → atterrir sur la recette sauvegardée). Steps d'édition d'ingrédients/étapes génériques déplacés de `recipe-form.ts` vers `cypress/support/step_definitions/common.steps.ts`, réutilisables par ce nouveau scénario. Suite : étape 4 (ajouter au planning déclenche l'import si nécessaire). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-20 16:56:06 +02:00
Nicolas	44ef5e071f	feat(recipes): parcourir et prévisualiser les sources externes (étape 1/4) ... Première étape du chantier "onglet Sources" (parcourir toutes les recettes externes des sources activées par le foyer, importées ou non, et déclencher leur import à l'ajout au planning) — celle-ci pose les endpoints backend de lecture seule, rien n'est encore sauvegardé. - RecipeSourceAdapter gagne `locale` (theMealDbAdapter: "en") — nécessaire pour que translateRecipe/matchTechStepSpans sachent contre quel jeu de TechStepMapping/labels d'ingrédients traduire une source donnée. - findImportedExternalIds (recipe-source-sync.ts) devient findImportedRecipeIds : renvoie une Map<externalId, recipeId> au lieu d'un simple Set — son premier vrai appelant (le parcours) a besoin de l'id réel pour naviguer directement vers la recette déjà importée, pas seulement savoir qu'elle l'est. - Nouveau module apps/api/src/modules/sources/ : - GET /sources/:sourceKey/browse — appelle list() de l'adaptateur, flague chaque item alreadyImported/recipeId. Restreint aux sources activées par le foyer courant (HouseSource) ; 404 SOURCE_NOT_FOUND sinon, même si la source existe (même posture que la visibilité des recettes : "pas trouvée" plutôt que "pas autorisée"). - GET /sources/:sourceKey/preview/:externalId — fetchDetail + parse + résolution complète (translateRecipeIngredients, matchTechStepSpans avec spans réels) contre la locale de la source, sans rien sauvegarder. Ingrédients non résolus → null plutôt qu'une erreur. - Nouveaux types partagés (packages/shared/src/types/sources.ts) : BrowsableSourceItemView, RecipeImportDraftView (+ Draft*View). Vérifié en conditions réelles contre TheMealDB (recette "Chicken Handi") : ingrédients résolus avec la bonne quantité/unité (1.2 kg de poulet, 8 gousses d'ail...), non-résolus corrects (huile végétale, piment vert), et chaque étape avec ses techniques détectées et leurs spans exacts (cook/fry/plate/setAside sur la même phrase, etc.). Tests : 276 passing (+8 nouveaux, sources.test.ts). Étape suivante (2/4) : l'UI de parcours (onglet Sources) — voir le plan de session. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-20 15:51:16 +02:00
Nicolas	73206c442b	fix(recipes): la source générique JSON-LD n'apparaît plus comme source ... jsonLdRecipeAdapter était enregistré (et donc synchronisé comme Source sélectionnable par un foyer) au même titre que theMealDbAdapter — mais c'est une structure générique de parsing schema.org destinée à être déclinée par site web scrappé, pas une source qu'on peut raisonnablement « activer » ou « faire confiance » en tant que telle (aucun catalogue à parcourir : list() renvoie toujours vide). registerAllRecipeSources() ne l'enregistre donc plus — elle reste utilisable directement (un futur adapter par site l'utiliserait en interne, ou un futur flux « importer depuis une URL » l'appellerait directement), simplement plus comme Source autonome du registre. Corrige aussi le mock Cypress qui prétendait « mirrorer ce qui est vraiment seedé » avec cette même source — remplacé par un second exemple clairement illustratif (Marmiton), qui ne correspond à aucun adapter réel. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-20 15:10:51 +02:00
Nicolas	d0900ad7fd	feat(recipes): surligne les tech steps détectés dans les étapes, avec tooltip ... Expose côté UI ce que tech-step-matcher.ts détecte déjà à la sauvegarde (Step.techSteps) mais qui restait backend-only : dans le panneau détail d'une recette, les mots exacts ayant déclenché une technique sont surlignés, avec un tooltip (survol/focus clavier) donnant son nom. - tech-step-matcher.ts : matchTechStepSpans(description, mappings) expose désormais {techStepId, start, end} en plus de la simple séquence d'ids (déjà calculé en interne, jusqu'ici jeté). matchTechSteps devient un wrapper fin dessus — aucun changement à ses ~12 tests existants ni à recipe-translation.ts. - StepTechStep gagne start/end (nullable, pas de backfill — même leçon que l'incident de migration ingredient_unit_catalog : NOT NULL sans défaut sur une table déjà peuplée casse le déploiement). Une ligne pré-existante sans span est simplement omise de la réponse API plutôt que de fuiter un null, jusqu'à ce que la recette soit resauvegardée. - recipe.service.ts : createRecipe/updateRecipe persistent start/end ; StepView expose techSteps: { techStep: {id,key}, start, end }[]. Le recalcul complet à chaque édition (ajout/modif/suppression d'étape) était déjà garanti par le delete-then-recreate existant d'updateRecipe — testé explicitement (nouveau test "recomputes techniques from scratch..."). - Frontend : StepDescription.tsx (découpe le texte via highlight-tech-steps.ts, pur et testé) remplace le <p> brut dans RecipeDetailPanel. Nouveau Tooltip.tsx (composants/ui, CSS pur, aucune lib externe — même esprit que Dialog.tsx) : un <button> (focusable nativement, pas de tabIndex sur un <mark> non interactif) affiche le nom de la technique (catalog.techSteps.<key>) au survol/focus. Tests : matchTechStepSpans (spans corrects, chevauchement résolu), recipe.test.ts (forme API + recalcul complet sur modif/ajout/suppression d'étape, avec vérification que les anciennes lignes StepTechStep sont bien supprimées), splitDescriptionByTechSteps (tri, bornes invalides ignorées, chevauchement résiduel ignoré), scénario Cypress recipes.feature (surlignage + tooltip au focus). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-20 14:46:15 +02:00
Nicolas	deec91c5a3	fix(recipes): synchronise les sources en base au démarrage de l'image de prod ... Le conteneur de prod ne peuplait jamais la table Source : seed-runtime.ts (l'entrée seed de l'image Docker, exécutée après `prisma migrate deploy`) n'appelait que seedReferenceData(), jamais registerAllRecipeSources()/ syncRecipeSources() — contrairement à prisma/seed.ts (dev). server.ts enregistre bien les adaptateurs dans son propre registre en mémoire, mais c'est un processus distinct de celui qui lance seed-runtime.js dans la chaîne CMD du Dockerfile ; sans ce sync, GET /reference/sources renvoyait toujours [], et HouseholdSettingsPage masquait silencieusement toute la section sources (sources.length === 0 → return null). C'est ce que l'utilisateur a remarqué : impossible de paramétrer les sources visibles du foyer en prod. Vérifié en local : Source/HouseSource vidées, seed-runtime.js compilé relancé exactement comme le ferait le conteneur (migrate deploy déjà appliqué, puis ce script) → les deux sources (TheMealDB, JSON-LD) sont bien resynchronisées. Ajoute aussi la couverture Cypress du parcours "sources" qui manquait : - onboarding.feature : nouveau scénario où le catalogue de sources n'est pas vide — l'étape /onboarding/sources s'affiche et se soumet, au lieu du seul scénario existant qui la voyait toujours skippée (catalogue vide). - household-settings.feature : nouveaux scénarios pour la section sources de /parametres/foyer — affichage + sauvegarde (autosave incluse) quand des sources existent, et disparition complète de la section quand le catalogue est vide. - Nouvelles steps partagées (reference-data.steps.ts pour le catalogue, household-mutations.steps.ts pour la sélection par foyer). Non exécutés localement : Chromium/Electron headless plante au lancement du process GPU dans cet environnement (limitation documentée du README, reproductible sur main, sans lien avec ce changement) — vérifiés par relecture attentive contre le code source réel (libellés de traduction, routes, formes de requête/réponse) et en suivant le même gabarit que les scénarios existants déjà verts en CI. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-20 13:48:29 +02:00
Nicolas	89722ba790	feat(recipes): matching anglais pour les tech steps et les ingrédients ... - Ajoute une expression régulière anglaise à chacun des 26 TechStepMapping du catalogue (locale "en"), en plus du "fr" existant — les recettes en anglais (TheMealDB, etc.) peuvent désormais matcher leurs étapes. - Nouveau apps/api/src/lib/ingredient-matcher.ts : moteur de matching pur (nom d'ingrédient, unité, quantité) contre les catalogues Ingredient/Unit, à partir de labels anglais écrits à la main (packages/shared/src/data/ catalog-labels-en.ts — 546 INGREDIENT_LABELS_EN + 17 UNIT_LABELS_EN avec synonymes/abréviations). Tokenise et stem naïvement les deux côtés pour tolérer pluriels et mots descriptifs superflus ; la correspondance la plus spécifique (le plus de mots) l'emporte en cas de recoupement. - extractQuantity() : lit un nombre en tête de texte libre (entier, décimal, fraction simple ou nombre mixte) pour déduire la quantité et l'unité quand la source ne les fournit pas séparément. - Étend recipe-translation.ts : translateRecipe(recipe, locale) résout aussi ingredientId/unitId/quantity de chaque ligne d'ingrédient — mais uniquement pour locale "en" (seules langue avec des labels), pour ne pas interroger la base inutilement ni halluciner un match dans une autre langue. - Ajoute cup/ounce/pound au catalogue Unit (toBaseFactor réel), absents jusqu'ici alors que très fréquents dans les recettes anglaises. - Vérifié en conditions réelles contre TheMealDB (Teriyaki Chicken Casserole) : 8/9 ingrédients résolus avec la bonne quantité/unité, le seul raté ("stir-fry vegetables") étant un mélange sans entrée dédiée au catalogue — dégradation gracieuse (unitId/ingredientId: null) comme prévu. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-20 13:10:00 +02:00
Nicolas	8ab652206d	feat(recipes): source générique JSON-LD (schema.org/Recipe) ... Deuxième adaptateur concret, cette fois générique plutôt que lié à un site précis : la plupart des sites de recettes embarquent des données structurées JSON-LD (schema.org/Recipe) pour le SEO/Google Rich Results — un seul adaptateur peut donc couvrir une grande partie des sites, sans scraper le DOM site par site. - apps/api/src/sources/json-ld-recipe.ts : official: false (on lit du HTML arbitraire, pas une API dédiée maintenue par l'éditeur), pas de catalogue à parcourir (list() renvoie toujours vide) — fetchDetail() prend directement une URL comme externalId, prête pour un futur flux "importer depuis une URL". - Extraction JSON-LD par regex (pas de nouvelle dépendance — un tag <script> ne contient jamais de HTML imbriqué, donc pas besoin d'un vrai parseur DOM), tolérante aux blocs multiples et aux JSON malformés (ignorés plutôt que de faire échouer toute la page). Gère les variantes réelles de schema.org : @type en tableau, @graph, recipeInstructions en string/HowToStep[]/HowToSection imbriquées, image en string/ImageObject/tableau, recipeYield en nombre/texte/ tableau. Vérifié contre une vraie page (bbcgoodfood.com, HTML téléchargé + fetch live) : nom, description, image, portions, 8 ingrédients et 2 étapes correctement extraits de bout en bout. 26 nouveaux tests (tous avec fetch stubbé, aucun appel réseau réel dans la suite automatisée). 221 tests passent au total. Build et lint propres. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-20 12:17:49 +02:00
kyuno053	b9f148a674	Merge pull request #39 from kyuno053/feat/recipe-step-translation ... feat(recipes): traduction des étapes d'une recette importée en tech steps	2026-08-20 11:57:45 +02:00