9 commits

Author	SHA1	Message	Date
Nicolas	c4c2c2ae39	fix(planning): la grille remplit l'écran, une case ne grandit plus (#110) ... `table.planning-grid` a `height: 100%` mais des hauteurs de ligne pilotées par le contenu : un créneau avec plusieurs recettes étirait son `<td>`, donc toute la ligne (les autres cases gagnant la même hauteur morte sous `vertical-align: top`), puis la table débordait de `.planning-grid-wrapper` en scroll vertical. - `tbody tr { height: 1px }` : les cinq lignes se partagent la hauteur du wrapper à parts égales (une hauteur de ligne est un minimum que le navigateur étire pour absorber la hauteur restante de la table), au lieu d'être aussi hautes que la colonne la plus chargée. - `.meal-cell__recipes` : `max-height: 8.5rem; overflow-y: auto` — au-delà d'une poignée de recettes la liste scrolle dans la case. Cap en `rem` et pas en `%` : les hauteurs en pourcentage sur un `<td>` ne se résolvent pas de façon fiable selon le moteur. `.add-recipe-btn` (frère flex hors de cette boîte) reste épinglé juste en dessous. - `min-width: 62rem` laissé tel quel : les 7 colonnes ont besoin d'un plancher pour rester lisibles, et le scroll horizontal dessous est couvert par `layout.cy.ts`. Le breakpoint phone (vue `PlanningDayView`) n'est pas concerné. Closes #110 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-08 01:36:21 +02:00
Nicolas	642b37ebec	fix(planning): affiche les recettes du picker sur mobile (#111) ... Sur téléphone, le dialogue d'ajout d'une recette au planning devenait plein écran mais `.recipe-picker-dialog` gardait un `height: 80vh` figé. Dans cette colonne flex de hauteur bornée, le bloc `.recipe-picker__filters` (rendu pour les 4 onglets non-source) consommait toute la place et `.recipes-page__catalog` (`flex: 1`) s'effondrait à ~0 : la table des recettes était dans le DOM mais dans un scrollport de hauteur nulle, donc les onglets Favoris / Perso / Foyer / Publique paraissaient vides. Sous le breakpoint phone : le dialogue passe vraiment plein écran (comme tout autre `Dialog`), `.recipe-picker__filters` ne se laisse plus compresser, et le catalogue prend sa hauteur de contenu — c'est `.dialog-panel__body` qui scrolle. Closes #111 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-08 01:18:17 +02:00
Nicolas	964269d3f3	feat(planning): vue mobile dédiée "un jour à la fois" pour la grille (#88) ... La grille planning (7 colonnes × 5 repas, min-width: 62rem) était le principal écran inaccessible sur téléphone : sous ce seuil elle ne se réorganisait pas, elle scrollait juste horizontalement — un tableau desktop rétréci, pas un vrai écran mobile. Sous le breakpoint phone (useIsMobileViewport()), PlanningPage bascule désormais entièrement sur PlanningDayView : un sélecteur de jour (jour précédent/suivant, borné au lundi/dimanche de la semaine affichée, pas de bouclage vers la semaine adjacente — ça reste le rôle des flèches du WeekNavigator) suivi des 5 repas du jour sélectionné, empilés en cartes. Le contenu de chaque case (pastilles de recettes + bouton "+") est mutualisé entre les deux layouts via une fonction non-hook partagée, mealCellBody, appelée aussi bien par MealCell (<td>, grille desktop) que par le nouveau MealCellRow (<div>, vue jour) — même logique de drop-target @dnd-kit (useDroppable) des deux côtés, donc le glisser- déposer d'un reste continue de fonctionner à l'identique sur mobile. Mise à jour de layout.cy.ts : son test #39 "la grille reste scrollable horizontalement sur phone" décrivait un comportement désormais remplacé par ce ticket — réécrit pour vérifier la bascule vers la vue jour au lieu du scroll horizontal. Closes #88 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-07 16:27:46 +02:00
Nicolas	a3701acae4	fix(planning): popovers flottants surs sur mobile ... Ticket #87 du chantier UI mobile & tablette. LeftoversBasket et WeekNavigator's CalendarPopover etaient tous les deux des popovers a largeur fixe (18-20rem), ancres right: 0, sans aucune gestion de bord d'ecran - sur un telephone etroit ils pouvaient deborder hors du viewport. Les deux sont declenches depuis l'en-tete du planning, un ecran central de l'usage quotidien - tres probablement la cause concrete derriere le retour terrain "je n'ai pas acces a tous les boutons" sur mobile qui a lance ce chantier. Les deux basculent desormais sur BottomSheet (ticket #91) sous le breakpoint phone via useIsMobileViewport() - meme contenu, juste une autre enveloppe (le popover flottant + son ecouteur de clic exterieur manuel restent inchanges sur desktop). Le clic-exterieur devient un no-op propre sur mobile plutot qu'un ecouteur qui ne fait jamais rien (le ref ne s'attache a rien dans la branche BottomSheet). Nouvelle cle i18n common.calendar.title ("Choisir une semaine") pour le titre de la feuille - pas de raccourci en decoupant une autre cle interpolee. Verifie en local : tsc -b --force, biome check, build de prod, suite Cypress e2e complete (142/142, 2 nouveaux tests phone dans leftovers-basket.cy.ts et planning-page.cy.ts) et composants (63/63). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-07 12:48:39 +02:00
Nicolas	e8ac2d1629	feat(cooking): page /cuisiner + bouton "Commencer a cuisiner" ... - Bouton "Commencer a cuisiner" dans l'en-tete du planning, actif seulement quand la semaine affichee contient >= 1 recette ; navigue vers /cuisiner?date=<semaine>. - Page CookingSessionPage (/cuisiner) : consomme GET /cooking-session, rend les phases (mise en place / cuisson / dressage), les taches mutualisees avec badge "Mutualise" + ingredients/ustensiles resolus, et la bande "Pendant ce temps" pour les cuissons de fond. Semaine lue depuis ?date=, WeekNavigator en fallback ; recalcul a chaque visite (comme la liste de courses). - Logique pure extraite dans cooking-session.ts (composition des libelles, formatage des quantites). - i18n : bloc cookingSession.* + planning.startCooking. - apiClient.getCookingPlanForWeek. - Tests Cypress : cooking-session-page.cy.ts (layout, 3 cas), cooking-session .feature (parcours planning -> /cuisiner), assertions bouton dans planning-page.cy.ts ; step generique "button should be disabled" mutualise. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-28 19:06:24 +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
Nicolas	c29648e293	fix(ci): corrige lint/tests cassés par la migration portions ... - Dialog.tsx : remplace le div role="dialog" par un <dialog> natif (showModal) — corrige lint/a11y/useSemanticElements, récupère gratuitement le piège de focus et l'Échap natifs. Le clic extérieur est rebranché en imperative addEventListener pour éviter lint/a11y/useKeyWithClickEvents sur un élément non interactif. - RecipePickerDialog.tsx : retire l'autoFocus (lint/a11y/noAutofocus), ordre des imports/formatage corrigés par `biome check --write`. - apps/api/test/planning.test.ts, apps/api/test/recipe.test.ts : les fixtures qui créent un `PlanningItem` directement via Prisma n'avaient pas le nouveau champ `portions` requis. - apps/web/cypress/e2e/planning-page.cy.ts : ajoute `portions` aux items mockés pour rester fidèle au contrat `PlanningItemView`. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-19 14:56:50 +02:00
kyuno053	f1fefc1f38	refactor: sépare les tests Cypress en parcours utilisateur / layout / composants (#25) ... * chore: point de départ pour le refactor des tests Cypress Sépare les tests Cypress en trois catégories, comme discuté : 1. Parcours utilisateur (cypress/e2e/) — scénarios Gherkin/Cucumber, pilotés par @badeball/cypress-cucumber-preprocessor@22.2.0 (validé sur experiment/cucumber-cypress, mergée). Ex. "En tant qu'utilisateur, je peux créer un compte". 2. Layout applicatif (nouveau dossier à définir) — specs Cypress classiques (pas de Gherkin), cy.visit() sur une vraie page, mais centrées sur la disposition/visibilité des éléments, indépendamment d'un parcours utilisateur scripté. 3. Composants génériques (cypress/component/, nouveau) — vrai Component Testing Cypress, composant React monté isolément (pas de routeur, pas de backend). Composants concernés aujourd'hui : components/ui/{Checkbox,Radio,Dialog}.tsx. Premier pas : mise en place de l'infra Component Testing (config + devServer Vite + adapter React 18), validée sur un composant simple avant de construire le reste. * feat(web): infra Cypress Component Testing, premier test sur CheckboxOption Étape 1 du refactor (voir PR) : met en place le vrai mode Component Testing de Cypress, séparé de l'e2e — monte un composant React isolé (pas de routeur, pas de backend), pour tester les composants génériques (components/ui/) indépendamment de tout parcours utilisateur. - cypress.config.ts : nouveau bloc `component` (devServer Vite, réutilise vite.config.ts de l'appli — même plugin React, même Sass). Le hook GPU-disable est factorisé (`disableGpu`) puisque e2e et component ont chacun leur propre `setupNodeEvents`, pas de config partagée par défaut. - cypress/support/component.ts + component-index.html : fichiers de support standards Cypress CT — importe le vrai global.scss de l'appli (les composants génériques sont stylés via lui, pas de CSS scopé à eux). - cypress/component/CheckboxOption.cy.tsx : 4 scénarios sur components/ui/Checkbox.tsx (rendu du label, reflet du prop `checked` sur l'input natif + la classe `is-selected`, callback `onChange` avec la valeur inversée, comportement contrôlé via un wrapper avec état). Dépendance ajoutée, épinglée : @cypress/vite-dev-server@5.2.1 (dernière version sans peer dependency cypress >=14 — 6.0.3+ l'exige explicitement, on est sur cypress@13.17.0). Testé en local jusqu'au mur GPU/Electron habituel (config + devServer Vite chargent sans erreur) — l'exécution réelle du montage reste à vérifier via la CI. * ci: exécute les tests de composants Cypress Sans ça, `cypress/component/CheckboxOption.cy.tsx` (commit précédent) ne tournait jamais en CI : `pnpm --filter web e2e` lance `cypress run` sans `--component`, donc uniquement la suite e2e par défaut. - apps/web/package.json : nouveau script `cy:run:component` - ci.yml : étape dédiée après `pnpm --filter web e2e`, sans start-server-and-test (Cypress lance son propre dev server Vite en interne pour le component testing, pas besoin d'attendre l'appli comme pour l'e2e) * test(web): refactor user journeys into Cucumber scenarios Convertit les parcours utilisateur (goal-driven, "en tant que X je peux Y") en scénarios Gherkin, en réutilisant l'infra Cucumber déjà validée par le smoke test (PR #24). Retire le smoke test jetable maintenant superflu. 8 fichiers .feature ajoutés, chacun avec son fichier de step definitions au même basename (convention de découverte du préprocesseur — voir login-smoke.ts) : - auth.feature : inscription (succès, erreur validation, email déjà pris), connexion (succès, identifiants invalides), déconnexion - onboarding.feature : les 3 scénarios déjà couverts (wizard complet, étapes sautées, rejoindre un foyer pendant l'onboarding) — dépend de household-settings.ts et preferences.ts pour ses steps de création/rejoint de foyer et de sélection de régime/allergies - household-settings.feature : créer un foyer, rejoindre par code d'invitation, renommer (autosave), retirer un membre, supprimer le foyer, quitter le foyer - account.feature : suppression de compte (mauvais mot de passe, succès, annulation) - recipe-form.feature : les 4 scénarios déjà couverts inchangés (ajout d'ingrédient + création, régression crypto.randomUUID, exclusion/ réinclusion d'ingrédient, préchargement + édition d'une recette existante) - recipes.feature : bascule favori, suppression d'une recette - preferences.feature : autosave du régime, autosave des allergies - user-preferences.feature : changement de thème (autosave) En contrepartie, les anciens .cy.ts perdent uniquement les it() migrés vers Gherkin — les scénarios de layout/affichage pur (catalogue de recettes, tabs, recherche, panneau de détail, sidebar, planning grid, etc.) restent en Cypress classique, conformément au découpage "parcours utilisateur (Cucumber) vs layout (Cypress pur)" déjà en place pour les component tests. auth.cy.ts, onboarding.cy.ts et recipe-form.cy.ts sont supprimés : 100% de leur contenu a migré. Les commentaires "voir auth.cy.ts pour la justification" désormais obsolètes (fichier supprimé) sont remplacés par une explication autonome du mock cy.intercept. Vérifié statiquement : les 246 steps Gherkin des 8 .feature résolvent chacun vers exactement une définition (0 non résolu, 0 ambigu) et `pnpm exec biome check` est propre sur tout cypress/. Reste à confirmer en CI que les scénarios passent réellement (pas seulement qu'ils se résolvent). * fix(web): fix cross-feature step discovery and slash-alternation bug La CI de la refonte précédente (commit aaace15) a échoué : la découverte par défaut du préprocesseur ne charge, pour un fichier `foo.feature`, QUE `foo.ts` (co-localisé, même basename) et `cypress/support/step_definitions/**` — pas les autres `.ts` du dossier `cypress/e2e/`. onboarding.feature référençait donc des steps qui ne vivaient que dans preferences.ts, household-settings.ts et auth.ts, introuvables lors de son propre run. Déplace les steps réellement partagés entre plusieurs .feature vers cypress/support/step_definitions/ (chargé pour toutes les features) : - reference-data.steps.ts : mocks des listes de référence régimes/ allergies (options ou vides) — partagé entre auth.feature et onboarding.feature - household-mutations.steps.ts : création/adhésion à un foyer et leurs assertions — partagé entre household-settings.feature et onboarding.feature - profile-mutations.steps.ts : sélection du régime, mise à jour des allergies et leur assertion — partagé entre preferences.feature et onboarding.feature Les définitions d'origine sont retirées de auth.ts/household- settings.ts/onboarding.ts/preferences.ts pour éviter un step "Ambiguous" (chargé deux fois pour la feature qui les définissait déjà elle-même). Corrige aussi un second bug distinct révélé par la même CI : "the ingredient/diet catalog is available" (recipe-form.feature) contient un "/" non échappé — en syntaxe Cucumber Expression, "/" hors d'un paramètre {..} signifie une alternative de texte ("ingredient" OU "diet catalog is available"), jamais le caractère littéral. Le texte du .feature ne pouvait donc jamais matcher. Renommé sans "/" : "the ingredient and diet catalog is available". Le script de vérification statique utilisé pour valider aaace15 avant push donnait une fausse confiance : il regroupait tous les steps de tous les fichiers comme disponibles globalement pour chaque feature, sans respecter ce scoping réel. Réécrit pour ne charger, par feature, que son fichier co-localisé + step_definitions/ — et pour détecter les patterns contenant un "/" non échappé. Résultat : toujours 246 steps, 0 non résolu, 0 ambigu, 0 pattern à slash non échappé, cette fois avec un modèle de résolution fidèle au comportement réel du préprocesseur. * test(web): cover every CheckboxOption/RadioOption behavior Complète les component tests des deux seuls composants UI génériques committés (Dialog.tsx est un WIP non commité d'une autre fonctionnalité en cours — hors scope ici) pour couvrir tout leur comportement, pas seulement le cas heureux. CheckboxOption — 4 tests existants (rendu, checked/is-selected, onChange au clic depuis unchecked, contrôlé) complétés par : - onChange(false) au clic depuis l'état checked (symétrique du test existant, qui ne couvrait que checked=false → true) - fusion du className de l'appelant avec is-selected, dans les deux sens (juste className, className+is-selected) - class="" (chaîne vide, pas "false"/"null") quand aucun className n'est passé et que checked=false — pin le comportement exact du `.filter(Boolean).join(" ")` - le clic sur le texte du label (pas seulement l'input) déclenche aussi onChange — comportement natif du HTML dont la "carte sélectionnable" de global.scss dépend entièrement - le span .check-mark est aria-hidden RadioOption — aucun test avant ce commit. Ajouté en couvrant en plus ce qui distingue vraiment un radio d'un checkbox : - name/value posés sur l'input natif - onChange(value) au clic depuis unchecked - AUCUN onChange au clic sur un radio déjà checked (contrairement à un checkbox, un radio natif ne réémet pas `change` si l'état ne change pas réellement) - clic sur le label, className/is-selected, aria-hidden — mêmes scénarios que CheckboxOption - comportement de groupe mutuellement exclusif : 3 RadioOption partageant `name="theme"` (mirroring UserPreferencesPage), un seul sélectionné à la fois, y compris via `input:checked` natif du navigateur Non exécutable en local (limitation GPU/sandbox Electron documentée dans le README, pré-existante) — à vérifier en CI. * test(web): add layout/style regression suite for the app shell Troisième catégorie du découpage des tests (parcours via Cucumber, composants génériques via Component Testing, et maintenant layout pur — indépendant de tout parcours utilisateur). Cypress classique, pas de Gherkin : ce fichier teste la structure/l'apparence du shell (AppLayout) lui-même, pas le contenu d'une page donnée. Couvre spécifiquement les 4 axes demandés : - Positionnement : la sidebar garde une largeur fixe (240px déplié, 68px replié) plaquée au coin haut-gauche, sur n'importe quelle page. - Scroll : régression directe pour #21 — `.app-layout` reste borné exactement à la hauteur du viewport (overflow: hidden), et une page plus haute que le viewport scrolle uniquement dans `.app-content` (via un spacer synthétique de 3000px injecté après le mount, pour rester indépendant du contenu réel d'une page donnée) sans jamais déplacer la sidebar ni scroller le document lui-même. - Largeur des pages : autre régression directe pour #21 — le planning et le catalogue de recettes remplissent toute la largeur disponible de `.app-content`, tandis que la page "Liste de courses" et les pages de paramètres restent centrées avec un espace égal de chaque côté (le bug original : collées à gauche avec un grand vide à droite). - Breakpoint responsive (< 640px) : la sidebar bascule en barre horizontale pleine largeur, masque le bouton collapse/la version, et garde chaque lien de nav pleinement lisible (icône + label, avec scroll horizontal) plutôt que de les écraser en pastilles de ~16px sans texte — un mode de régression explicitement documenté en commentaire dans AppLayout.scss mais jusqu'ici non testé. - Thème de couleur : va au-delà de l'attribut `data-theme` déjà couvert par user-preferences.cy.ts — vérifie les vraies valeurs de couleur calculées (`getComputedStyle`) sur la sidebar, le lien de nav actif et le fond de page, en clair et en sombre, confirmant que la cascade CSS des tokens (_theme.scss) atteint réellement le rendu, pas seulement que le JS pose le bon attribut. Non exécutable en local (limitation GPU/sandbox Electron documentée dans le README, pré-existante) — à vérifier en CI.	2026-08-19 14:31:17 +02:00
Nicolas	9d4de338e3	Tests: couverture Cypress pour la grille de planning (step 4/4) ... - home-planning.cy.ts → planning-page.cy.ts : nav sidebar reprise telle quelle, nouveaux cas pour la grille (case vide, recettes placées dans les bonnes cases, colonne du jour courant, navigation semaine précédente/suivante, popover calendrier) - cy.clock fige "aujourd'hui" (2026-08-17, un lundi) pour des assertions de date déterministes ; cy.viewport élargi (desktop-only, cf. décision produit) pour que les 7 colonnes tiennent sans scroll horizontal lors des assertions de visibilité	2026-08-17 14:19:39 +02:00