TEST_SENTENCES gagne 2 entrées dérivées (fr-concat-volumetrie,
en-concat-volumetrie) qui concatènent toutes les phrases de base d'une
même locale en un seul step géant, calculées depuis les phrases existantes
(jamais recopiées à la main) — pour isoler l'effet du seul volume de texte
sur la durée de traitement de chaque moteur, indépendamment de la
complexité déjà couverte par les 7 phrases existantes.
Vérifié via bench:nlp : la latence croît nettement avec le volume
(fr-concat ~2200ms vs 300-1100ms pour les phrases individuelles FR).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Étape 1 — retire apps/api/src/scripts/bench-tech-step-classifier.ts
(DB-backed, taxonomie ~26 techniques non comparable terme à terme au LLM).
Étape 2 — reconstruit tout dans experiments/llm-tech-step-poc, entièrement
autonome (aucune dépendance Postgres/apps/api) :
- shared/kitchen-action.ts, shared/test-sentences.ts,
shared/benchmark-harness.ts : types, 7 phrases de test et harness de
mesure/affichage désormais partagés par les trois scripts (plus de
recopie manuelle entre fichiers).
- nlp-tech-step-poc.ts : classifieur node-nlp FRAIS (NER + clauses +
classification), entraîné directement sur la taxonomie à 7 catégories du
LLM plutôt que réutiliser TechStepClassifierService — comparaison terme à
terme, et surtout un score de confiance BRUT jamais masqué (contrairement
au repli silencieux sur l'ancre NER de la version production), condition
nécessaire au pipeline hybride. Corpus qui préfère les synonymes mono-mot
("revenir") aux phrases figées, pour ne pas se faire piéger par les
pronoms clitiques français ("faites-les-revenir").
- hybrid-tech-step-poc.ts : NLP toujours en premier (chemin rapide), LLM en
secours si la confiance NLP passe sous NLP_TRUST_THRESHOLD (0.6, tunable)
ou qu'aucune action n'est trouvée — récapitulatif avec colonnes "moteur"
et "confiance NLP" pour observer les bascules.
- llm-tech-step-poc.ts : inchangé fonctionnellement, migré vers les modules
partagés.
- shared/module-entry.ts (isMainModule) : garde chaque script pour que
l'import de ses classes (par hybrid-tech-step-poc.ts) ne déclenche pas
aussi son propre benchmark comme effet de bord.
pnpm bench / bench:nlp / bench:hybrid. README réécrit en conséquence.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nouveau script apps/api/src/scripts/bench-tech-step-classifier.ts, calqué
sur experiments/llm-tech-step-poc/src/llm-tech-step-poc.ts : mêmes 7
phrases de TEST_SENTENCES (recopiées à l'identique), même structure de
sortie (logs itératifs par répétition, tableau récapitulatif
latence/RSS/nombre de détections), pour que les deux pipelines soient
directement comparables phrase par phrase.
Réutilise techStepClassifier.warmUp() (déjà prévu pour absorber le coût de
l'entraînement + l'init paresseuse de node-nlp) et résout les techStepId en
key lisible pour l'affichage détaillé. Nécessite une base Postgres avec
TechStep seedée (matchTechStepSpans résout ses uid vers de vrais ids).
README du PoC LLM mis à jour : la section "Méthodologie de comparaison"
pointe vers ce script réel plutôt que le snippet REPL manuel qu'elle
suggérait avant.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- LocalLlmStepAnalyzer.warmUp() : force le coût caché du tout premier appel
d'inférence (spin-up threads llama.cpp, cache KV, tokenizer) avant le
benchmark, plutôt que de laisser la première phrase l'absorber — constaté
sur des runs réels (Qwen/Llama) où fr-multi-action montait jusqu'à ~28s
contre ~5s pour ses autres répétitions.
- initialize() et runBenchmark() journalisent maintenant chaque sous-étape
(résolution du modèle, chargement des poids, contexte, grammaire, puis
chaque répétition avec son résultat immédiat) au lieu de rester muets
plusieurs minutes avant le récapitulatif final.
- RECOMMENDED_MODELS / README corrigés suite aux runs réels de l'utilisateur :
Qwen2.5-1.5B s'est montré systématiquement plus rapide que Llama-3.2-1B
sur les deux machines testées, contredisant l'hypothèse a priori du README
("moins de paramètres = plus rapide") — gardé comme résultat empirique
plutôt que corrigé silencieusement.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
pnpm install seul, lancé depuis experiments/llm-tech-step-poc, remonte au
monorepo (pnpm-workspace.yaml) et n'installe rien pour ce dossier hors
workspace — sans erreur visible. --ignore-workspace force pnpm à traiter
le dossier comme un package standalone.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Complète les 3 phrases initiales de TEST_SENTENCES avec 4 cas cherchant
volontairement le point de rupture (au lieu de juste confirmer le cas
courant) : actions simultanées plutôt que séquentielles ("pendant que..."),
action conditionnelle noyée dans des actions fermes, négation explicite
d'action ("sans jamais laisser bouillir"), fin de cuisson par état/test de
résultat plutôt que par durée, et un champ température qui désigne un seuil
de cuisson à cœur plutôt qu'un réglage de feu. README mis à jour (7 phrases,
4 FR + 3 EN).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Fichier TypeScript autonome (hors du workspace pnpm) qui compare le
pipeline node-nlp existant (tech-step-matcher.ts) à un mini LLM instruct
local via node-llama-cpp : sortie JSON strictement contrainte par schéma
(grammaire GBNF, createGrammarForJsonSchema), interfaces RecipeStepAnalysis/
KitchenAction, recommandation de modèle (Qwen2.5-1.5B-Instruct Q4_K_M par
défaut, Llama-3.2-1B-Instruct Q4_K_M en alternative), et un benchmark simple
(performance.now() + delta RSS) sur 3 phrases complexes FR/EN, dont le cas
piège sans verbe littéral déjà documenté dans tech-step-matcher.ts.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
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>
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>
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>
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>
Trois règles style ajoutées à biome.json :
- noNonNullAssertion (warn) : déconseille `valeur!`
- useConsistentArrayType (syntax: shorthand) : impose T[] (déjà la
norme partout dans le repo, aucune réécriture nécessaire)
- useConsistentTypeDefinitions (style: interface) : impose `interface`
pour tout type objet
0 violation sur les 200 fichiers du repo — déjà conforme. Documenté
dans specs/dev-conventions.md (tableau des règles Biome actives).
Corrige aussi la config du poste : node_modules pointait encore vers
Biome 1.9.4 alors que package.json déclare ^2.5.9 depuis le merge de
la #59 (ce checkout n'avait jamais été réinstallé depuis) — pnpm
install corrige, aucun changement de lockfile.
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
* docs(conventions): impose une couverture de tests pour chaque ajout
Trois nouvelles règles dans "## Tests" :
- ajout front autonome (components/ui/*) -> Cypress mode composant
- ajout front non autonome (dépend de son layout/page) -> Cypress
mode layout, spec .cy.ts classique dans cypress/e2e/
- nouvelle fonctionnalité front (parcours utilisateur) -> Cypress e2e,
scénario Gherkin "En tant que... je veux..." (s'ajoute au test
layout, ne le remplace pas)
- ajout back testable -> Mocha + Chai dans apps/api/test/
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* claude.md
---------
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
* 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>
Trois ajustements successifs sur le dialogue de sélection de recette
(RecipePickerDialog), demandés en continu après le premier correctif
de débordement :
1. Dialogue élargi et à hauteur fixe (95vw plafonné à 85rem, 80vh) au
lieu de dépendre du contenu, avec la répartition liste/détail
redéfinie en fractions du dialogue lui-même (3fr/2fr) plutôt qu'en
vw — cette dernière suivait la largeur du viewport, sans rapport
avec la largeur désormais fixe du dialogue.
2. Le formulaire de revue d'import (ex-ImportRecipePage) est extrait
dans un composant partagé, RecipeImportForm — toujours monté en
page autonome (route directe/rechargement), mais désormais aussi
intégré comme une étape du dialogue lui-même quand un item de
source a besoin d'une résolution manuelle, au lieu de naviguer et
perdre le contexte du picker (recherche, filtres, créneau).
3. Cliquer sur une recette dans le dialogue ne fait plus que la
sélectionner/prévisualiser (RecipeDetailPanel, comme /recettes) —
plus de saut automatique vers l'étape suivante. Un nouveau pied de
dialogue (Dialog.tsx gagne une prop ) porte Confirmer/
Fermer : Confirmer agit sur la sélection en cours (recette réelle
→ étape portions existante ; item de source pas encore importé →
import transparent ou formulaire intégré, point 2). Les onglets
réguliers gagnent leur propre paire maître-détail (RecipeTable +
RecipeDetailPanel, showActions=false) sur ce même modèle ; les
onglets source prévisualisent désormais aussi les items déjà
importés en interne (RecipeSourcesPanel), plus de saut direct.
Cypress (planning.feature/planning.ts) mis à jour en conséquence :
sélectionner puis confirmer sont deux étapes distinctes, le clic sur
la ligne ne déclenche plus rien tout seul.
Bug pré-existant trouvé en testant en direct (sans rapport avec ce qui
précède) : l'import d'une recette source plante avec une contrainte
d'unicité Prisma dès que deux lignes d'ingrédient se résolvent au même
ingrédient catalogue — signalé séparément (tâche en arrière-plan), pas
corrigé ici.
Vérifié en direct (navigateur, comptes de test) : sélection sans saut
d'écran, pied de dialogue activé/désactivé correctement, Confirmer sur
un item de source non résolu bascule vers le formulaire intégré,
Fermer ferme bien le dialogue.
pnpm exec tsc -b --force (web) — propre.
pnpm exec biome check — propre.
pnpm --filter web build — propre.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
92vw/75rem -> 95vw/85rem — vérifié en direct, dialogue passe de 1178px à
1216px sur un viewport 1280px.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
.recipes-page__catalog dimensionne son panneau de détail avec
minmax(35vw, 38vw) — une fraction du *viewport*, cohérent sur /recettes
(cette grille occupe quasiment toute la page) mais sans rapport avec ce
dialogue, désormais de largeur fixe (92vw plafonné à 75rem, voir commit
précédent) : à un viewport large, 38vw dépasse largement la largeur réelle
du dialogue et déséquilibre la répartition liste/détail.
Remplacé, sous .recipe-picker-dialog uniquement, par un ratio 3fr/2fr
relatif au dialogue lui-même — la répartition (60/40) reste identique
quelle que soit la largeur de l'écran, vérifié en direct à 1280px et
1600px de large (ratio mesuré 1.50 dans les deux cas).
pnpm --filter web build — propre.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Suite au correctif précédent (débordement du catalogue) : le dialogue lui-
même passe de 56rem/hauteur-au-contenu à 92vw plafonné à 75rem, avec une
hauteur fixe de 80vh (au lieu du simple plafond hérité de Dialog.tsx) —
la zone de navigation garde désormais une taille généreuse et constante
quel que soit l'onglet/la quantité de contenu, plutôt que de dépendre de
ce qui tient à l'écran.
Vérifié en direct (navigateur, 1280×800) : dialogue 1178×640px (92vw ×
80vh), catalogue/tableau/détail correctement bornés à l'intérieur.
pnpm --filter web build — propre.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Le dialogue de sélection de recette (RecipePickerDialog) affichait bien les
données renvoyées par le serveur, mais rien ne s'affichait dans la fenêtre
tant que le nombre d'items dépassait sa hauteur — reproduit en direct via
le compte de test : la tab TheMealDB (25 items, contrairement aux quelques
recettes perso habituelles) rend le bug visible alors qu'il touchait déjà
le tableau simple des autres onglets, juste sans jamais assez de lignes
pour le déclencher.
Cause : .recipes-page__catalog et .recipe-table-wrap se dimensionnent via
flex: 1; min-height: 0, ce qui ne fonctionne que si leur parent est
display: flex — vrai sur /recettes (.recipes-page l'établit), faux dans ce
dialogue où le contenu est monté directement dans .dialog-panel__body
(Dialog.tsx), un simple conteneur en flux bloc. Sans ce contexte, la zone
catalogue grossissait à la taille de son contenu (1499px mesuré en direct
contre 605px de hauteur réellement disponible) au lieu d'être bornée et
scrollable dans ses propres limites.
Correctif scoping .dialog-panel__body en display: flex; flex-direction:
column uniquement sous .recipe-picker-dialog (tous les autres appelants de
Dialog gardent le flux bloc par défaut), plus flex: 1; min-height: 0 sur
.recipe-table-wrap pour qu'il profite du même contexte.
Vérifié en direct (navigateur, compte de test, tab TheMealDB) : la zone
catalogue passe de 1499px à 450px (borné), les lignes redeviennent
visibles/cliquables sans affecter les autres onglets ni l'étape de
confirmation des portions (rendue par un Dialog séparé, sans la classe
recipe-picker-dialog). Tenu aussi en viewport réduit (1024x640).
pnpm exec tsc -b --force (web) — propre.
pnpm --filter web build — propre.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Correction de comportement sur la gestion des recettes de sources
externes — l'implémentation précédente avait dérivé d'une lecture
erronée du besoin :
- Plus aucun bouton d'import nulle part. Parcourir une source
(RecipesPage, hors planning) ne fait plus jamais que prévisualiser
— RecipeDetailPanel n'affiche plus de lien "Importer cette
recette", seulement un bouton icône discret vers la page d'origine
quand la recette en a une (nouveau .recipe-detail-panel__source-link,
même emplacement que l'étoile favori).
- Une recette externe n'est importée dans la base qu'au moment où
quelqu'un l'ajoute effectivement à son planning — jamais avant.
RecipePickerDialog.handleSelectDraftItem est désormais le seul
endroit de toute l'appli qui importe quoi que ce soit : cliquer sur
un item pas encore importé y déclenche une tentative d'import
transparente (POST /sources/.../import puis POST /planning/items),
sans écran intermédiaire, dès que rien ne manque
(tryBuildCompleteImport, nouveau apps/web/src/features/recipes/
recipe-import-draft.ts). Seul un ingrédient non résolu (ou une
erreur réseau) fait encore basculer vers l'écran de revue existant
(ImportRecipePage), pré-rempli, pour compléter ce qui manque.
- RecipeSourcesPanel gagne onSelectDraftItem (remplace planningSlot,
qui n'a plus de raison d'être puisqu'il n'y a plus de lien d'import
à qui le transmettre) : quand ce callback est fourni
(RecipePickerDialog uniquement), un item pas encore importé n'est
plus prévisualisé sur place, il est remonté tel quel à l'appelant.
Tests :
- planning.feature : le scénario existant retire l'étape "je clique
le lien Importer cette recette" (redirection désormais automatique
puisque le draft de test a un ingrédient non résolu) ; nouveau
scénario pour le chemin transparent (draft entièrement résolu,
aucun écran de revue).
- recipe-sources.feature : le scénario qui important depuis /recettes
(hors planning) est supprimé — cette capacité n'existe plus hors
planning. Le scénario de deep-link vérifie maintenant l'absence du
bouton d'import et la présence du lien discret.
- pnpm exec tsc -b --force (web) — propre.
- pnpm exec biome check — propre.
- pnpm --filter web build — propre.
- Cypress non exécutable localement sur cette machine (crash GPU
Electron connu) — scénarios vérifiés par relecture attentive
contre le markup/les clés i18n réels ; CI (GitHub Actions) fera
foi à l'exécution.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nouvelle correction demandée sur cette PR : l'onglet générique
« Sources » (avec un <select> interne quand le foyer en a activé
plusieurs) devient une tab à part entière par source activée — au même
niveau que Favoris/Perso/Foyer/Publique, plus transparent qu'un
sélecteur caché dans un sous-menu.
- `RecipeTabs` accepte désormais `sources: SourceView[]` et rend une
tab par source (icône propre à la source si elle en a une, sinon
l'icône générique `SourcesIcon` ; libellé = le nom réel de la
source, pas une clé i18n). Nouveau type `RecipesPageTab` en
`RecipeTab | "source:<key>"`, avec `sourceTabValue`/
`parseSourceTabValue`/`isSourceTab` comme seul point d'assemblage/
lecture de ce format.
- Nouveau hook partagé `useEnabledSources` (déplacé hors de
`RecipeSourcesPanel`, maintenant utilisé par `RecipesPage` ET
`RecipePickerDialog` pour construire leurs tabs).
- `RecipeSourcesPanel` simplifié : `sourceKey` devient une prop requise
(fournie par la tab elle-même) au lieu d'un état interne avec son
propre sélecteur — plus de `<select>`, plus de message « aucune
source activée » (une tab qui n'existe pas ne peut plus être
cliquée). Remonté via `key={sourceKey}` par l'appelant au changement
de tab, même convention que `RecipePickerDialog`/`CalendarPopover`
ailleurs dans l'app.
- Un bug distinct trouvé en écrivant ce changement : passer tel quel
`initialSelection` (dérivé de l'URL) au panneau nouvellement monté
en changeant directement de tab source à tab source aurait fait
prévisualiser l'ancien item contre la nouvelle source. Gardé en ne
transmettant `initialSelection` que lorsqu'il appartient réellement
à `activeSourceKey`.
Aucun changement backend.
Tests :
- Vérifié manuellement en local (foyer avec TheMealDB activé) :
tab dédiée dans /recettes et dans le sélecteur du planning, parcours
d'un item, aperçu unifié, aucune régression console.
- Cypress : `recipe-sources.feature`/`planning.feature` mis à jour
(« I click the button "Sources" » → « ... "TheMealDB" »), scénario
« aucune source activée » réécrit pour vérifier l'absence de tab
plutôt qu'un message dans un onglet qui n'existe plus.
- `pnpm exec tsc -b --force` (web) — propre.
- `pnpm exec biome check` — propre.
- `pnpm --filter web build` — propre.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
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>
Suite au retour utilisateur sur le plan « onglet Sources » livré
précédemment (#44-#48) : navigation transparente, page recette pour un
item externe, comportement d'ajout au planning déjà importé.
L'onglet « Sources » (RecipesPage) reste un onglet à part (décision
explicite : pas de fusion des listes perso/foyer/publique/externe) —
mais son affichage se comporte désormais « comme si c'était importé » :
- `SourceItemPreviewPanel` est supprimé, fusionné dans
`RecipeDetailPanel` lui-même (nouvel état `"loaded-draft"`) : un item
pas encore importé se voit exactement comme une vraie recette — même
en-tête, même mise en page description/étapes — la seule différence
étant les actions proposées (« Importer cette recette » là où une
vraie recette montre Modifier/Supprimer). La liste brute des
ingrédients et l'indice « non résolu » disparaissent de cette vue :
cette complexité reste réservée à l'écran de revue d'import
(ImportRecipePage), pas à un simple aperçu.
- Un item pas encore importé gagne une vraie URL adressable —
`/recettes/sources/:sourceKey/:externalId` (nouvelle route,
RecipesPage) — au même titre qu'une vraie recette a `/recettes/:id`.
Avant, le sélectionner ne changeait que de l'état React local dans
`RecipeSourcesPanel`, sans URL propre : ni lien direct, ni retour
arrière/rafraîchissement possibles. `RecipeSourcesPanel` gagne
`initialSelection`/`onItemSelected` pour rester piloté par cette URL
sans avoir à connaître le routage lui-même — `RecipePickerDialog`
(qui prévisualise dans une modale sans URL propre) laisse les deux
non renseignés et garde son comportement inchangé.
- `onSelectImportedRecipe` (déjà présent) continue de traiter un item
déjà importé exactement comme une vraie recette — c'est justement ce
qui rend la navigation transparente pour ce cas.
Le troisième point du retour (vérifier si la recette est déjà en base
avant de l'ajouter au planning, ne rien faire si oui, l'importer sinon)
était déjà le comportement de #48 — inchangé ici, aucune régression:
`RecipePickerDialog` résout un item déjà importé vers sa vraie recette
sans ré-import, et n'importe que les items qui ne le sont pas encore.
Aucun changement backend.
Tests :
- Cypress : nouvelle assertion d'URL dans le scénario « Previews a
not-yet-imported item » de recipe-sources.feature, et nouveau
scénario « Deep-links straight to a not-yet-imported item's own
page » — la CI confirmera.
- `pnpm --filter api test` — 282 tests toujours au vert (aucun
changement backend).
- `pnpm exec tsc -b --force` (web) — propre.
- `pnpm exec biome check` — propre.
- `pnpm -r build` — propre.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Retire le dernier volet du scénario (rouvrir le sélecteur, rebrowser la
source, vérifier le badge « déjà importée ») — la CI l'a fait échouer
(le badge n'apparaissait jamais sur le second passage) sans qu'une
relecture du code de RecipePickerDialog/RecipeSourcesPanel/de leurs
mocks stateful n'explique pourquoi à distance, sans accès aux
screenshots Cypress (non remontés en artifact CI). Plutôt que
d'itérer à l'aveugle sur un mock complexe, on retire ce volet : le
comportement qu'il vérifiait (« browse marque bien alreadyImported une
fois la Recipe créée ») est déjà entièrement couvert côté Mocha
(sources.test.ts, étape 1) — cette assertion Cypress était redondante,
pas la seule preuve du comportement.
Le reste du scénario (le vrai objet de cette étape : sélectionner un
item non importé depuis le planning, l'importer en résolvant un
ingrédient, et le voir atterrir dans le bon créneau après le retour
sur "/") est inchangé et n'a jamais été mis en cause par cet échec.
Simplifie `planning.ts` en conséquence : `browsing TheMealDB returns
some items`/`importing the previewed item ...` redeviennent des mocks
statiques (le flag `fishPieImported` qu'ils entretenaient n'a plus de
lecteur), et le step Then devenu mort est retiré.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Dernière étape du plan « onglet Sources » : le sélecteur de recette du
planning (`RecipePickerDialog`) gagne l'onglet « Sources », jusqu'ici
volontairement exclu faute d'écran de revue à qui transmettre un item
choisi (voir étape 3, #47).
- Sélectionner un item déjà importé se comporte exactement comme
choisir cette même recette depuis un onglet normal (résolue via
`GET /recipes/:id`, direction vers l'étape « combien de portions ? »
du dialogue, sans navigation).
- Sélectionner un item pas encore importé bascule vers l'écran de
revue existant (`ImportRecipePage`), avec le créneau du planning
porté par la query string (`?planningDate=&planningWeekDay=&planningMeal=`).
Un import réussi y ajoute alors automatiquement la recette
fraîchement créée à ce créneau (`POST /planning/items`, avec les
portions du formulaire) avant de revenir sur le planning — plutôt que
d'atterrir sur la page de la recette comme le fait un import « classique ».
- `RecipeSourcesPanel`/`SourceItemPreviewPanel` généralisés en
conséquence : la première ne navigue plus elle-même vers la recette
déjà importée (`onSelectImportedRecipe` renvoie l'id, chaque appelant
décide), la seconde propage le créneau optionnel sur son lien
d'import.
Aucun changement backend : `POST /sources/:sourceKey/import/:externalId`
et `POST /planning/items` existaient déjà et suffisent tels quels — une
fois la recette importée, `GET /sources/:sourceKey/browse` la marque
déjà `alreadyImported` automatiquement (logique déjà couverte par
`sources.test.ts`). 282 tests API toujours au vert, aucune régression.
Tests :
- Cypress : nouveau scénario Gherkin bout-en-bout
(`cypress/e2e/planning.feature`/`planning.ts`) — ouvrir le
sélecteur depuis un créneau vide, parcourir Sources, importer un
item non résolu (ingrédient à compléter compris), vérifier que la
requête d'ajout au planning porte bien le bon créneau/les bonnes
portions, que la recette apparaît dans la bonne case de la grille
après le retour sur "/", puis que rebrowser la source la marque
désormais comme déjà importée.
Suite : plan « onglet Sources » terminé (étapes 1 à 4).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Le lien « Importer cette recette » de SourceItemPreviewPanel est un
<Link> (donc un <a>), pas un <button> — le scénario utilisait "I click
the button ..." qui ne cible que button, d'où l'échec en CI
("Expected to find content: 'Importer cette recette' within the
selector: 'button' but never did"). Bascule vers le step générique "I
click the link ..." déjà présent dans common.steps.ts.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
La CI a révélé que la résolution des steps Cucumber n'est pas globale sur
tout cypress/e2e/ comme je le pensais — seuls le fichier/dossier de même
nom que la .feature et cypress/support/step_definitions/ sont cherchés
(voir le message d'erreur de la CI). recipes.ts vit directement dans
cypress/e2e/ (pas dans step_definitions/), donc ses steps ne résolvaient
que pour recipes.feature — recipe-sources.feature qui les réutilisait
plantait avec "Step implementation missing".
- Les steps génériques réellement partagés entre les deux features
(heading du panneau détail, technique surlignée, tooltip) migrent vers
common.steps.ts (step_definitions/, cherché globalement) plutôt que
d'être dupliqués une deuxième fois.
- Les steps propres à un fixture précis (recipe 2's detail, disliked
ingredients, catalogue vide) sont redéclarés localement dans
recipe-sources.ts avec leurs propres données minimales — même
précédent que recipes.cy.ts, qui duplique déjà indépendamment le
fixture omeletteDetail plutôt que de dépendre de recipes.ts.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Deuxième étape du chantier "onglet Sources" : l'UI de parcours, construite
contre les endpoints backend de l'étape 1 (#45). L'onglet désactivé
placeholder de RecipeTabs devient un vrai onglet fonctionnel.
- RecipeTabs.tsx : nouveau type RecipesPageTab (RecipeTab | "sources") —
gardé hors du type partagé RecipeTab puisque l'API n'a pas de
tab=sources à valider. Un prop `tabs` optionnel restreint quels onglets
s'affichent — RecipePickerDialog (choix d'une recette pour un planning)
s'y restreint aux 4 onglets réels, parcourir des sources externes en
plein milieu de ce dialogue n'a pas de sens sans le flux de revue/import.
- Nouveau RecipeSourcesPanel.tsx : contenu de l'onglet "Sources" —
autonome (son propre master-detail), ne partage pas le fetching
RecipeTab de RecipesPage puisqu'il parcourt le catalogue *live* d'une
source (GET /sources/:key/browse), pas la table Recipe sauvegardée.
Sélecteur de source si le foyer en a activé plusieurs ; sélectionner un
item déjà importé navigue directement vers la vraie recette
(SourceItemTable + navigate), un item pas encore importé affiche un
aperçu en lecture seule (SourceItemPreviewPanel, réutilise
StepDescription — les tech steps sont donc déjà surlignés dans
l'aperçu).
- Bug trouvé et corrigé en écrivant le scénario Cypress : cliquer un item
déjà importé changeait l'URL mais restait affiché sur l'onglet Sources
(RecipesPage ne rend RecipeDetailPanel/RecipeTable qu'en dehors de
l'onglet "sources"). RecipeSourcesPanel prend maintenant un callback
`onViewImportedRecipe` pour repasser sur un onglet réel avant de
naviguer.
Tests : nouveau recipe-sources.feature (parcours utilisateur complet —
onglet vide, parcours avec items importés/non importés, aperçu avec
surlignage de technique) ; recipes.cy.ts corrigé (assertion obsolète sur
l'ancien placeholder désactivé). Étape suivante (3/4) : écran de revue
(corriger les ingrédients non résolus) + finalisation de l'import.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
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>
Same class of failure as the household-settings sources scenario earlier
this session: the steps section sits below the detail panel's
header/photo/description, off the fold of .app-content's own scroll — a
bare .should("be.visible") doesn't auto-scroll.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
CI's e2e run confirmed the real cause: SourcesSection renders near the
bottom of /parametres/foyer (after name, invite code, members), inside
.app-content's own scrollable region — a bare `.should("be.visible")`
doesn't auto-scroll (only interaction commands like `.click()`/`.check()`
do), so the checkbox row was still clipped by that container's overflow
when the assertion ran. Adds a dedicated "I scroll to the section" step
and uses it before the sources-section assertions in household-settings.feature.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
