200 commits

Author	SHA1	Message	Date
kyuno	4f553147ed	Merge pull request '[UI mobile] La landing page met en avant le téléchargement sur mobile' (#101) from feat/mobile-landing-download into main	2026-09-07 17:40:20 +02:00
kyuno	c82f0969a8	Merge pull request '[UI mobile] Onglet "Paramètres d'application"' (#100) from feat/mobile-app-settings into main	2026-09-07 17:40:02 +02:00
kyuno	8d1c4a7f0b	Merge pull request '[UI mobile] Liste de courses et catalogue de recettes : renforcement mobile' (#99) from feat/mobile-shopping-recipes into main	2026-09-07 17:39:53 +02:00
kyuno	f0f5e9f344	Merge pull request '[UI mobile] Session de cuisine : passe mobile' (#98) from feat/mobile-cooking-session into main	2026-09-07 17:39:42 +02:00
Nicolas	615e320be1	feat(landing): met en avant le téléchargement/ouverture de l'appli sur mobile (#85) ... Sur un vrai navigateur mobile Android (isAndroidPhoneBrowser(), déjà utilisé par le ticket #84), la ligne de CTA de la landing page affiche désormais "Ouvrir dans l'application" comme action PRIMAIRE — plus utile qu'un compte web puisque l'expérience web n'est de toute façon pas optimisée mobile (au cœur de ce chantier), et un visiteur avec l'appli déjà installée peut s'inscrire/se connecter depuis l'appli elle-même. "Créer un compte"/"Se connecter" sont rétrogradés en actions secondaires plutôt que masqués : certains visiteurs préfèrent sciemment le web. Le clic déclenche attemptOpenNativeApp (tentative d'ouverture du scheme, repli automatique après le délai) plutôt que d'afficher un second lien séparé — remplace .landing__mobile-link, ne le duplique pas. Sur desktop, comportement inchangé (CTA "Créer un compte" toujours primaire) sauf le lien Android discret, qui pointe maintenant vers /telecharger (page de repli du ticket #84) au lieu du lien direct /mobile/download — un seul point d'entrée "obtenir l'appli" pour tout le site plutôt que deux mécanismes légèrement différents à maintenir en synchro. Couverture Cypress : landing.feature étendu avec un nouveau scénario mobile (UA Android spoofée via onBeforeLoad, même chaîne que le test unitaire existant d'isAndroidPhoneBrowser dans mobile-app-redirect.cy.tsx) — vérifie l'affichage du bouton et la rétrogradation de Créer un compte/Se connecter, SANS jamais cliquer le bouton réel (son onClick appellerait un vrai window.location.href vers un scheme personnalisé, qui bloque indéfiniment le runner Cypress/ Electron — piège déjà documenté, la fonction elle-même est déjà testée unitairement avec un stub injecté). Le scénario desktop existant est mis à jour pour le nouveau href /telecharger. Suite complète : biome check, tsc -b --force, build, 145/145 e2e, 71/71 composants — tous verts. Closes #85 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-07 17:34:44 +02:00
Nicolas	e1589e63d0	feat(settings): onglet "Paramètres d'application" (#86) ... Nouvelle route /parametres/application + entrée dans SETTINGS_ITEMS (desktop et sheet mobile, un seul tableau partagé). Thème et "rejouer un tutoriel" restent inchangés dans /parametres/preferences-utilisateur (décision explicite du chantier). Le contenu affiché diffère réellement selon la plateforme, pas par simple choix cosmétique — chaque moitié de la page est inerte sur l'autre plateforme, pas juste hors-sujet : - Version installée + "Vérifier les mises à jour" (natif seulement) : useAppUpdateCheck (déjà utilisé par la bannière silencieuse existante) gagne un checkNow() qui relance la même comparaison sans attendre le throttle de 6h, réutilisant la logique existante plutôt que de la dupliquer (fetchLatestVersionResult extraite en fonction partagée). Nouveau hook useInstalledVersion (App.getInfo() natif, __APP_VERSION__ web). - "Toujours rester sur le site web" (web seulement, tout appareil) : pilote STAY_ON_WEB_PREFERENCE_KEY (déjà exporté par mobile-app-redirect.ts, ticket #84). Volontairement masqué côté natif : le WebView Capacitor tourne sur sa propre origine https://localhost, un localStorage totalement séparé de celui du vrai site web que lit attemptOpenNativeApp — modifier la préférence depuis l'app ne changerait donc jamais rien pour un visiteur mobile réel. Documenté explicitement dans le commentaire de la page pour ne pas réintroduire ce contrôle-fantôme plus tard. Couverture Cypress : nouveau app-settings-page.cy.ts (contenu web, persistance du toggle après reload) ; sidebar.cy.ts étendu pour couvrir le nouveau lien. Le déclenchement natif réel (App.getInfo(), l'appel réseau de checkNow) n'a pas de point d'entrée testable depuis un run Cypress web — même posture déjà acceptée pour useAppUpdateCheck/ UpdateBanner, la logique de comparaison pure reste couverte par version-compare.cy.tsx (inchangé). Suite complète : biome check, tsc -b --force, build, 146/146 e2e, 71/71 composants — tous verts. Closes #86 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-07 17:19:36 +02:00
Nicolas	7d1a69cf12	fix(mobile): renforce le catalogue de recettes et la liste de courses sur mobile (#90) ... Deux correctifs, regroupés en un seul ticket comme prévu : - Catalogue de recettes (`recipes.scss`) : `.recipe-table-wrap` n'avait aucun garde-fou de scroll horizontal, contrairement à la grille planning — sur un viewport étroit, les 4 colonnes (photo/nom/ allergènes/régimes) se compressaient au lieu de scroller. Ajout d'`overflow-x: auto` sur le wrapper + `min-width: 36rem` sur la table (échelle réduite par rapport aux 62rem de la grille planning : 4 colonnes plus étroites, pas 7). Partagé par le catalogue complet ET par `RecipePickerDialog`, qui hérite du même correctif au passage. - Liste de courses (`shopping-list-page.scss`) : audit dédié — la page n'a en réalité aucune case à cocher ni bouton de suppression (elle est volontairement en lecture seule, voir le commentaire de ShoppingListPage.tsx), contrairement à ce que supposait le ticket d'origine ; rien à agrandir comme cible tactile de ce côté. La structure ne déborde déjà pas non plus (`&-name` a déjà flex:1/ min-width:0). Amélioration retenue à la place : une ligne un peu plus aérée et une icône plus grande sous le breakpoint phone, pour une lecture plus confortable en faisant les courses (liste tenue d'une main, coups d'œil répétés). Couverture Cypress : nouveau describe "Recipe catalog (phone)" dans recipes.cy.ts (garde-fou de scroll horizontal effectivement actif) ; nouveau fichier shopping-list-page.cy.ts, spec layout simple (pas Gherkin, cette page n'a pas encore ce type de fichier) pour le padding de ligne. Suite complète : biome check, tsc -b --force, build, 146/146 e2e, 71/71 composants (un skip ponctuel de TechStepCorrectionPopover en run groupé, reconfirmé 10/10 isolément — flake local sans lien avec ce ticket) — tous verts. Closes #90 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-07 17:02:48 +02:00
Nicolas	2b5ae6722a	fix(cooking-session): premier passage responsive dédié à l'écran de cuisine (#89) ... cooking-session-page.scss n'avait encore aucune règle @media. Audit dédié à cet écran (minuteur inexistant sur cette page — rien à faire de ce côté, liste d'étapes, actions) : - Bug d'overflow réel dans l'onglet Recettes : `.cooking-recipes__name` n'avait aucune borne dans sa ligne flex (contrairement au `.recipe-chip__name` équivalent côté planning) — un nom de recette long pouvait repousser le badge de portions et le chevron hors de la case (silencieusement coupés par le `overflow: hidden` de la carte parente). Corrigé avec le même traitement flex:1/min-width:0/ ellipsis que son équivalent. - Cibles tactiles sous le breakpoint phone : les cartes de tâches (`. cooking-task`, l'action principale et répétée de tout l'onglet Plan), les nœuds du stepper, les onglets, la ligne de l'onglet Recettes et les boutons Précédent/Suivant passent tous à --space-md pour dépasser confortablement les 48dp minimums d'Android (l'app est Android-only) même dans le pire cas (une tâche à une seule ligne, sans ustensiles). - Piège rencontré : surcharger `.cooking-task` par un simple sélecteur de classe ne fonctionnait pas silencieusement — la règle globale partagée `label:has(> input[type="checkbox"])` (global.scss) a une spécificité CSS plus élevée qu'il n'y paraît (l'argument de :has() compte comme un élément + un attribut). Corrigé en réutilisant le même niveau d'imbrication que `.cooking-phase__tasks .cooking-task --done` juste au-dessus dans le même fichier, qui contournait déjà ce problème pour la même raison. Couverture Cypress : nouveau describe "Cooking session page (phone)" dans cooking-session-page.cy.ts (2 tests — padding effectivement appliqué + troncature du nom de recette sans pousser le badge hors champ). Suite complète : biome check, tsc -b --force, build, 146/146 e2e, 71/71 composants — tous verts. Closes #89 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-07 16:49:08 +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
kyuno	23bc19b482	Merge pull request 'test(cypress): convention de viewports téléphone/tablette' (#94) from feat/mobile-cypress-viewports into main	2026-09-07 16:02:24 +02:00
kyuno	0ff94c61ca	Merge pull request 'fix(planning): popovers flottants sûrs sur mobile' (#95) from feat/mobile-popovers-safe into main	2026-09-07 15:46:09 +02:00
Nicolas	0447c68b69	merge: rapatrie le correctif de serialisation CI (#96)	2026-09-07 14:31:05 +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	967be6df4a	test(cypress): convention de viewports telephone/tablette ... Ticket #83 du chantier UI mobile & tablette. Le repo n'avait aucun override de viewportWidth/Height ni pour e2e ni pour les tests de composants - tout tournait a la taille par defaut, jamais un vrai telephone/une vraie tablette. - cypress/support/viewports.ts : PHONE_VIEWPORT (390x844) et TABLET_VIEWPORT (900x1200), tailles Android reelles plutot que les presets iPhone/iPad de Cypress (appli Android uniquement) - dans les bandes de _breakpoints.scss ($phone/$tablet du ticket #91), pas collees au pixel de bordure. Commande cy.setViewport("phone" | "tablet") (pas de surcharge du cy.viewport natif). Importe par support/e2e.ts et support/component.ts, disponible dans les deux modes. - layout.cy.ts : les cy.viewport(...) en dur pour du telephone (deux tests ajoutes par #91, plus les deux plus anciens du passage #39) et le test "au-dessus du point de rupture telephone" migrent vers la commande partagee - ce dernier passe a un vrai viewport tablette (900px, dans la bande 641-1024) plutot qu'un 1000x700 arbitraire, prouvant au passage que le preset tablette fonctionne. - Nouveau cypress/component/Dialog.cy.tsx : premier test de Dialog en isolation (jusqu'ici seulement couvert indirectement via RecipePickerDialog) - verifie le plein-ecran sur telephone du ticket #91, qui n'avait pas encore son propre test, et prouve au passage que cy.setViewport fonctionne en mode composant. Trouvaille en verifiant : le mode composant de Cypress a son propre viewport par defaut, plus petit que celui du mode e2e (1000x660) - deja sous le seuil telephone. Le premier essai du test "desktop" de Dialog echouait pour cette raison (le CSS plein-ecran s'appliquait sans meme appeler setViewport). Corrige en fixant un viewport large explicite pour ce cas plutot que de compter sur un defaut implicite - note ajoutee a dev-environment-gotchas pour la prochaine fois. Verifie en local : tsc -b --force, biome check, build de prod, suite Cypress e2e complete (140/140) et composants (65/65, incluant les 2 nouveaux tests de Dialog.cy.tsx). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-07 12:32:36 +02:00
Nicolas	d6cf4aa63d	feat(mobile): redirection vers l'appli + page de telechargement ... Ticket #84 du chantier UI mobile & tablette. Aucune infra de deep-link n'existait (verifie en amont : pas de scheme personnalise, pas d'App Links, pas d'assetlinks.json, pas de listener appUrlOpen). - lib/mobile-app-redirect.ts : attemptOpenNativeApp() (pattern "smart app banner" classique - tente le scheme batchcooking://, bascule sur onFallback si la page est toujours visible passe un court delai) et isAndroidPhoneBrowser() (UA Android+Mobile, deliberement distinct de useIsMobileViewport() - une question de plateforme, pas de largeur). Respecte une preference "rester sur le web" (localStorage, cle exportee pour que l'onglet Parametres d'application - ticket #86 - la reutilise) sans jamais forcer la redirection. - AndroidManifest.xml : nouvel intent-filter additif (scheme batchcooking, sans toucher au filtre MAIN/LAUNCHER existant). - Nouvelle page /telecharger (publique, hors RequireAuth - un visiteur deja connecte sur le web mais sans l'appli sur cet appareil a une raison legitime d'y atterrir) : lien direct vers le proxy existant ${API_BASE_URL}/mobile/download (rien a changer cote API), bouton "reessayer d'ouvrir l'appli". Deliberement pas de changement sur la landing page ici (lien discret actuel laisse tel quel) - c'est le ticket #85, separe pour rester petit/revuable. Verifie en local : tsc -b --force, biome check, build de prod, suite Cypress e2e complete (141/141 sur cette branche - #91 n'est pas encore merge, layout.cy.ts y est donc encore dans son etat pre-#91) et composants (69/69, incluant le nouveau mobile-app-redirect.cy.tsx). Note technique : le premier essai de test du composant tentait un vrai window.location.href vers le scheme personnalise depuis Cypress/ Electron, ce qui bloquait le runner indefiniment (protocole inconnu mal gere par Electron) - corrige en rendant ce seul appel injectable (openAppUrl, reserve aux tests) sans toucher au comportement reel. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-07 12:20:16 +02:00
Nicolas	0fd4928efc	feat(layout): socle UI mobile - nav, feuille et dialogs plein ecran ... Fondation du chantier UI mobile & tablette (#91) : jusqu'ici, toute adaptation mobile de ce repo etait du CSS pur sur le meme DOM (aucun composant ne branchait son JSX selon la largeur/plateforme). Ce ticket introduit le premier vrai branchement, et les primitifs que les 8 tickets suivants du chantier reutiliseront. - useIsMobileViewport() (apps/web/src/lib/) : point de verite unique, base sur matchMedia, live (reagit a un resize/une rotation). - _breakpoints.scss : $phone/$tablet Sass + mixins phone/phone-up/ tablet-down, remplacant les nombres magiques 640/1024 repetes en dur dans 6 fichiers (AppLayout, landing, recipes, recipe-picker-dialog, planning-page, dialog, tours-page). Les deux occurrences de 860px (landing hero, tours-page) sont deliberement laissees telles quelles - un collapse de grille 2 colonnes qui n'a rien a voir avec le breakpoint tablette du catalogue recettes, les unifier aurait change un comportement visuel reel sans raison. - useNativeDialogBehavior : mecanique (showModal/close event/clic exterieur) extraite de Dialog.tsx, partagee avec le nouveau BottomSheet.tsx (feuille mobile plein-largeur, meme fondation <dialog> natif que Dialog, juste ancree en bas). - AppLayout : sur telephone, la sidebar n'est plus reflow-ee en CSS en barre horizontale (l'ancien traitement) - elle est remplacee par une vraie barre d'onglets basse (Planning/Recettes/Liste de courses + Plus), le "Plus" ouvrant une BottomSheet combinant Parametres et Compte (deux dropdowns flottants separes cote desktop -> un seul point d'entree mobile, IA plus simple, un seul emplacement d'onglet). - dialog.scss : vrai plein-ecran (bord a bord, sans arrondi) sous le breakpoint phone au lieu d'une marge simplement reduite. Verifie en local : pnpm --filter web exec tsc -b --force, biome check, pnpm --filter web build, suite Cypress e2e complete (140/140) et composants (63/63) - y compris layout.cy.ts, reecrit pour tester la nouvelle barre basse (l'ancien test de la barre horizontale n'a plus de sens, ce traitement n'existe plus). Closes #91 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-07 12:03:43 +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
kyuno	8315f737d4	Merge pull request 'fix(auth): la déconnexion retombe sur / plutôt que /login' (#79) from fix/logout-redirect-landing into main	2026-09-07 00:25:04 +02:00
Nicolas	21cd8f014d	fix(auth): la deconnexion retombe sur / plutot que /login ... RequireAuth.tsx affiche deja la LandingPage publique pour un visiteur deconnecte exactement sur / (issue #41) — seul handleLogout naviguait encore explicitement vers /login. Change juste la destination de navigate() ; aucun autre changement necessaire. Scenario Cypress mis a jour en consequence (le pas existant "the URL should be the home page" suffit, pas besoin d'un nouveau pas). Verifie en local, suite complete : pnpm lint, pnpm --filter web build, pnpm run e2e (139/139, apres avoir nettoye un process vite zombie sur le port 5173 laisse par une precedente invocation cypress dans cette meme session — voir dev-environment-gotchas pour le detail). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-06 23:59:18 +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	29bd413de3	fix(mobile): corrige les liens vers /releases/latest/download ... Verifie en conditions reelles apres le premier vrai succes de bout en bout de release.yml (v0.2.0, Release Forgejo #12 avec batchcooking.apk attache) : Forgejo, contrairement a GitHub, n'implemente pas le raccourci /releases/latest/download/<fichier>. Seul /releases/latest lui-meme resout (redirige vers la page de la release) : /releases/latest/download/batchcooking.apk -> 404 /releases/latest -> 303 vers /releases/tag/v0.2.0 (OK) /releases/download/v0.2.0/batchcooking.apk -> 200 (OK, mais pas "latest") Corrige les deux endroits qui presumaient le raccourci GitHub (issue #65 et #66, deja mergees) pour pointer vers /releases/latest tout court : un clic de plus via la page de release Forgejo pour atteindre le fichier, mais un lien qui resout toujours plutot qu'un raccourci qui 404 en permanence. Met a jour le test Cypress de la page d'accueil et le commentaire de release.yml en consequence. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-06 22:03:14 +02:00
Nicolas	854d795c5d	fix(release): corrige release.yml pour Forgejo et y attache un APK signe ... release.yml datait d'avant la migration vers Forgejo et n'avait jamais ete reteste : refs d'action bares (actions/checkout@v4, softprops/action-gh- release@v2) sans le prefixe URL complet qu'exige ce runner self-hosted (meme contrainte deja rencontree et documentee dans ci.yml). Ajoute aussi ce que #65 attendait reellement : un job build-android-apk (meme recette que le job build-android de ci.yml, issue #64) qui construit et signe l'APK, deduit versionName/versionCode du tag pousse (vX.Y.Z -> versionName X.Y.Z, versionCode majeur*10000+mineur*100+correctif) et l'attache a la Release Forgejo sous un nom de fichier stable (batchcooking.apk) via softprops/action-gh-release. C'est ce nom stable qui permet a /releases/latest/download/batchcooking.apk (page d'accueil, #65) de toujours pointer vers la derniere release sans jamais changer de lien. build.gradle : versionCode/versionName deviennent surchargeables via -PandroidVersionCode/-PandroidVersionName (defaut inchange : 1 / "1.0" pour tout build qui ne passe pas ces proprietes, comme le job build-android existant de ci.yml sur un simple push main). Duplique le job de build Android plutot que de factoriser en workflow_call reutilisable — le support des workflows reutilisables sur ce runner Forgejo/act self-hoste n'est pas verifie, et cette recette de ~15 lignes est deja eprouvee telle quelle dans ci.yml ; pas la peine de risquer une nouvelle surprise de compatibilite pour economiser un peu de duplication. Non teste de bout en bout dans cette PR : release.yml ne se declenche que sur un vrai tag pousse (jamais sur une simple branche/PR), et pousser un tag ici declencherait potentiellement un vrai redeploiement Portainer en production si PORTAINER_WEBHOOK_URL est deja configure — a tester deliberement avec l'utilisateur, pas par un tag de test improvise. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-06 18:57:33 +02:00
kyuno	644164b25a	Merge pull request 'feat(landing): lien de téléchargement de l'app Android (#65)' (#68) from feat/landing-apk-download into main	2026-09-06 16:18:09 +02:00
Nicolas	9c6feab064	fix(ci): corrige le bit exécutable de gradlew et le fiabilise en CI ... Le tout premier run réel du job build-android (après le merge de #64) échouait avec './gradlew: Permission denied' — gradlew était suivi par git en 100644 (non exécutable) au lieu de 100755, probablement perdu au commit initial du projet Android natif (#63) sur cette machine Windows. Corrige le mode suivi par git (git update-index --chmod=+x) et ajoute un chmod +x défensif juste avant l'exécution dans ci.yml, puisque ce bit n'a aucun sens sous Windows et peut être reperdu silencieusement par un futur commit sur cette machine. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-06 15:09:21 +02:00
kyuno	c0a07e8adc	Merge pull request 'feat(ci): build, teste et empaquette un APK Android signé sur chaque push main' (#67) from feat/mobile-ci-android-apk into main	2026-09-06 14:44:35 +02:00
Nicolas	5d4d6be2dc	feat(mobile): vérification automatique de mise à jour de version ... Réutilise l'API Releases de Forgejo (publique, sans authentification) comme source de vérité pour "quelle est la dernière version" — zéro nouvel endpoint backend : useAppUpdateCheck compare App.getInfo().version (@capacitor/app, nouvelle dépendance) au tag_name de GET .../releases/latest, et pointe "Mettre à jour" vers l'URL stable de téléchargement (issue #65). Comparaison de version en logique pure (version-compare.ts), séparée du hook effectful — testée isolément via un test de composant Cypress (version-compare.cy.tsx, même patron que highlight-tech-steps.cy.tsx : aucun montage, juste describe/it/expect sur des fonctions pures). Natif uniquement (Capacitor.isNativePlatform()) : @capacitor/app et @capacitor/preferences restent en import dynamique dans le hook, jamais dans le bundle web (même patron que capacitor-token-store.ts) — vérifié dans le build (deux petits chunks séparés, pas dans le bundle principal). Vérification au démarrage à froid + à la reprise depuis l'arrière-plan (appStateChange), avec un throttle de 6h et une mémorisation de la version déjà rejetée dans @capacitor/preferences pour ne jamais re-harceler sur la même version. Bannière discrète (pas une Dialog modale), bouton "Mettre à jour" ouvrant le lien de téléchargement dans le navigateur système plutôt qu'un flux PackageInstaller in-app. Vérifié : pnpm lint, pnpm --filter web build, le test de composant (9/9), et layout/smoke/planning-page e2e (18/18, la bannière étant un no-op sur le web ne devait rien casser — confirmé). Closes #66 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-06 10:52:35 +02:00
Nicolas	76a99f0e77	feat(ci): build, teste et empaquette un APK Android signé sur chaque push main ... Nouveau job build-android dans ci.yml, gardé par needs: sur les 5 jobs existants (lint/test/intent-service-test/build/e2e) et limité à main via if: github.ref == 'refs/heads/main' — c'est ce qui garantit que l'APK n'est empaqueté qu'une fois la suite de tests existante verte, pas juste construit en parallèle d'elle. APK signé avec un vrai keystore de release (jamais généré par la CI — Android refuse une mise à jour signée par une clé différente de celle déjà installée) : ajoute signingConfigs.release à build.gradle, lu depuis l'environnement (ANDROID_KEYSTORE_PATH/_PASSWORD, ANDROID_KEY_ALIAS/_PASSWORD), jamais codé en dur. *.jks/*.keystore désormais réellement ignorés par git (étaient commentés dans le .gitignore généré par Capacitor). README : documente les 5 secrets Forgejo requis et la génération du keystore. Aucune suite de tests instrumentés Android n'existe (zéro code natif au-delà de la coquille Capacitor) — "testée" est satisfait par le gate sur la suite existante, pas par une suite native à inventer. Risque documenté, pas résolu par avance : aucun build Android n'a jamais tourné sur ce runner Forgejo auto-hébergé, contrairement aux 4 autres jobs. Closes #64 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-06 10:27:55 +02:00
Nicolas	503781c95f	feat(landing): lien de téléchargement de l'app Android (#65) ... Sur la page vitrine `/`, sous la rangée de CTA du hero (pas un 3e bouton : un compte reste nécessaire quelle que soit la plateforme), un lien discret vers l'APK Android + une ligne d'aide. - Cible : l'asset `batchcooking.apk` de la dernière release taguée Forgejo (`/releases/latest/download/…`, nom de fichier stable) — pas un artefact de CI. 404 tant que #64 + la correction de release.yml ne sont pas faits : état transitoire assumé, ce ticket n'ajoute que le lien. - `mobileHint` : rappel honnête que c'est un .apk à sideloader, pas une distribution Play Store. - i18n `landing.hero.mobileDownload` / `mobileHint` ; style discret dans landing-page.scss ; scénario Cypress de plus (présence + href du lien). Vérifs : `pnpm build` + `pnpm lint` OK. `landing.feature` non lancé en local (le hoist `tslib` de `@cypress/vite-dev-server` dans ce node_modules est cassé par un `pnpm install --force` interrompu + un verrou concurrent sur `@esbuild/win32-x64` ; `pnpm-lock.yaml` inchangé, la CI n'est pas affectée) → couvert par le job `e2e` de la CI. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-06 10:26:50 +02:00
Nicolas	fd5841d045	feat(mobile): ajoute le projet natif Android Capacitor (#39) ... Dernière étape du portage mobile #39 : génère et versionne le projet natif Android (`npx cap add android`) que les phases 1 à 3 (jeton Bearer, passe responsive, plomberie web) préparaient déjà. - `apps/web/android/` — projet natif Capacitor 8.5. Permission `INTERNET` présente par défaut, `applicationId` = `fr.kyuno.batchcooking`. - Thème natif aligné sur la palette « Mise en Place » (`_theme.scss`) : `colors.xml` redéfinit `colorPrimary`/`Dark`/`Accent` (basilic/vermillon) par-dessus les défauts Material de la lib capacitor-android ; barre de statut basilic foncé, fond de fenêtre « porcelaine » pour ne pas flasher blanc au démarrage à froid ; `postSplashScreenTheme` pour la transition. - Icône adaptative + splash (clair et sombre, toutes densités) générés depuis `apps/web/assets/logo.svg` (monogramme « bC », géométrie seule, pas de `<text>`) via `@capacitor/assets` ; sources et commande de régénération documentées dans `apps/web/assets/README.md`. `@capacitor/assets` n'est pas ajouté aux dépendances (il tire `sharp`, hors `onlyBuiltDependencies`) — lancé via `npx`. - `.gitignore` racine : ignore `/.idea/` (Android Studio ouvre désormais le dépôt comme projet). `biome.json` : exclut `apps/web/android` du lint. - README : section « Application mobile (Android) » (prérequis + flux de build `build:capacitor` → `cap sync` → Android Studio). Le bundle web copié sous `android/app/src/main/assets/public/` reste git-ignoré (régénéré par `pnpm build:capacitor && npx cap sync android`). Build de l'APK + test sur appareil : à finir dans Android Studio — la CI self-hosted ne build pas Android. Vérifs : `pnpm build` + `pnpm lint` OK ; `npx cap sync android` OK ; tous les XML natifs bien formés. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-06 09:32:24 +02:00
Nicolas	8e55f3d3f9	fix(recipes): rend StepDescription tolérant à un techSteps absent ... StepDescription faisait `useState(techSteps)` puis `liveTechSteps.flatMap(...)` : quand la prop `techSteps` arrivait `undefined`, `.flatMap` levait `TypeError: Cannot read properties of undefined (reading 'flatMap')`, remontée par Cypress comme une erreur applicative non capturée. Observé de façon intermittente sur le parcours « modifier une recette » : après enregistrement, `RecipeFormPage` navigue vers `/recettes/:id`, dont le détail se rendait parfois avant que `techSteps` ne soit peuplé. - `StepDescription` : `techSteps` devient optionnel et `liveTechSteps` retombe sur `[]` (dans le `useState` et le `useEffect` de resync), pour que tous les consommateurs (`.flatMap`, `splitDescriptionSegments`, `findTechStepForTemperature`, lookup `activeStepTechStep`) aient toujours un vrai tableau — même posture « tolérer la donnée manquante, ne pas planter » que le reste du composant. - `recipe-form.ts` : le mock de la recette 7 envoyait une étape sans `techSteps`, contrairement au vrai `StepView` et à tous les autres mocks de la suite — corrigé en `techSteps: []`. - `recipes.cy.ts` : nouveau test de non-régression déterministe — un payload d'étape sans `techSteps` doit rendre la description en texte brut. Vérifié qu'il échoue bien (`flatMap` undefined) sans le correctif du composant. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-06 09:04:36 +02:00
Nicolas	b39105ac27	feat(web): page admin de CRUD des didacticiels (#44) ... L'UI par-dessus l'API `/admin/api/tours*`. Nouvelle entrée `/admin/didacticiels` dans `AdminLayout` (i18n `admin.nav.tours`), route sous `RequireAdmin`+`AdminLayout` dans `App.tsx`. `ToursPage.tsx` : liste des scénarios à gauche (nom, état activé/désactivé, nombre d'étapes) ; à droite l'éditeur du scénario sélectionné — - renommer, activer/désactiver ; - éditer la liste d'étapes (route, cible via `<select>` alimenté par `GET /tours/targets`, titre, contenu), réordonner (↑/↓), ajouter, retirer ; - « Enregistrer » → un seul `PATCH /:id` qui remplace tout (name/enabled + étapes rénumérotées `order` = index), erreurs API affichées telles quelles ; - « Supprimer le scénario » (confirmation `window.confirm`) ; - « Nouveau scénario » → formulaire clé + nom → `POST /`. `admin-client.ts` gagne `getTourScenarios` / `getTourTargets` / `createTourScenario` / `updateTourScenario` / `deleteTourScenario`. Tests Cypress (`admin-tours.cy.ts`, 4) : liste (activés + désactivés, nombre d'étapes) ; édition nom + réordonnancement d'étapes → un seul PATCH avec la liste complète réordonnée ; création → POST `{key,name}` ; suppression après confirmation → DELETE. 4/4 en local ; `pnpm build` + `pnpm lint` verts. Closes #44 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-06 06:53:38 +02:00
Nicolas	38fcf03417	feat(web): moteur de tutoriel guidé driver.js (#42) ... Consomme le socle backend de #42/#44 (`GET /reference/tours`, `GET/POST /profile/tours`). Deux tours : orientation générale (auto sur `/`) et correction des métadonnées de recette (auto à l'ouverture du premier popover de correction). - Dépendance `driver.js` (~5 ko, MIT, zéro dépendance). - `features/tour/tour-engine.ts` : wrapper vanilla autour de `driver.js` — gère ce que la lib ne fait pas seule : la navigation React Router entre étapes situées sur des routes différentes, et un `onFinish` unique (`"completed"` seulement si on atteint la fin, `"skipped"` pour la croix / Échap / clic sur l'overlay). - `features/tour/TourContext.tsx` : `TourProvider` (charge scénarios + progression, keyed sur `user?.id` comme `ThemeContext`) et `useTour()` (`startTour(key)` / `isTourCompleted(key)` / `tours` / `isReady`). `isReady` est **calculé au render** contre l'id utilisateur chargé — pas stocké — pour qu'un changement de `user` le repasse à `false` immédiatement, avant qu'un effet enfant (l'auto-déclenchement) ne tourne sur des données de complétion périmées. - `main.tsx` : `<TourProvider>` sous `ThemeProvider`. - Attributs `data-tour-*` : liens de nav (`AppLayout`), grille / bouton `+` du 1er créneau / bouton Cuisiner (`PlanningPage`), page liste de courses (`ShoppingListPage`), description d'étape + section technique du popover (`StepDescription` / `TechStepCorrectionPopover`). - Déclenchement auto : tour `general` sur `/` (`PlanningPage`, ref-gardé), tour `techStepMetadata` à `activeCorrection` non-null (`StepDescription`). - Section « Revoir un tutoriel » dans `/parametres/preferences-utilisateur` — un `map` sur `tours`, un bouton « Revoir » par scénario. - `tour.scss` re-skinne le popover `driver.js` sur les tokens du thème. - i18n `tour.*` (chrome uniquement : boutons du popover, section « Revoir » ; le contenu des étapes vient de la base). Tests Cypress (`tour.feature`, 5 scénarios) : auto-démarrage + élément surligné pour un nouveau venu ; « Terminé » → complétion enregistrée `skipped:false` ; croix → `skipped:true` ; un tour déjà vu ne se relance pas ; « Revoir » le relance depuis les paramètres. Vérifié 5/5 en local. `pnpm build` + `pnpm lint` verts. Refs #42 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-06 06:17: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	da7b077098	feat(web): page vitrine publique à la racine (#41) ... Un visiteur déconnecté sur `/` voit désormais une vraie page de présentation avant qu'on lui demande de se connecter, au lieu d'être renvoyé directement vers `/login`. - `RequireAuth.tsx` devient sensible au chemin : dans sa branche `!user`, `pathname === "/"` rend `<LandingPage />` ; toutes les autres routes protégées redirigent vers `/login` exactement comme avant. Aucun changement de la table de routes — `/` reste `<PlanningPage>` niché sous `RequireAuth`+`AppLayout`, et `AppLayout` (donc la sidebar) ne monte jamais pour la vitrine. - `pages/landing/LandingPage.tsx` + `landing-page.scss` : hero (accroche + illustration SVG dessinée à la main dans le langage de `lucide-react`, zéro dépendance ni asset externe) + deux CTA, grille de 4 fonctionnalités (icônes lucide), section « aperçu », CTA final. Copie entièrement sous le namespace i18n `landing.*`. - `index.html` : favicon SVG (monogramme « bC ») + `<meta description>` — `/` est maintenant une page publique partageable. - Les 3 captures d'écran réelles de la section « aperçu » sont servies statiquement depuis `public/landing/` (un fichier manquant retombe sur son `alt`, ne casse pas le build) ; elles restent à produire par un humain avec l'app lancée sur des données réelles — cf. `public/landing/README.md`. - Tests Cypress `landing.feature` : vitrine visible déconnecté sur `/`, CTA vers `/login` et `/signup`, autre route protégée toujours redirigée, visiteur connecté voit bien le planning. `smoke.cy.ts` mis à jour pour tester la redirection depuis `/recettes` (puisque `/` ne redirige plus). Closes #41 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-06 04:33:41 +02:00
Nicolas	ff36cefcde	feat(web): plomberie web pour la coquille Capacitor Android (#39 phase 2) ... Tout ce qui est vérifiable en CI de la phase 2 du portage mobile. La génération du projet natif (`npx cap add android`), le build de l'APK et le test sur appareil restent une étape manuelle (pas d'Android Studio ici) — cf. le corps de l'issue #39. - Dépendances : `@capacitor/core`, `@capacitor/android`, `@capacitor/preferences` (+ `@capacitor/cli` en dev), toutes en 8.5.x. - `capacitor.config.ts` : `appId` `fr.kyuno.batchcooking`, `webDir: "dist"`. - `apps/web/src/api/capacitor-token-store.ts` : implémentation `TokenStore` adossée à `@capacitor/preferences`, branchée via `setTokenStore()` (le point d'injection posé en phase 1). Importée dynamiquement dans `main.tsx` uniquement quand `Capacitor.isNativePlatform()` — le bundle web ne charge jamais `@capacitor/preferences` (vérifié : chunk séparé de 0,5 ko jamais requis côté navigateur). - `main.tsx` : `HashRouter` en natif (le bundle packagé sert `dist/` depuis l'origine locale de la WebView, sans réécriture des liens profonds vers `index.html`), `BrowserRouter` inchangé sur le web ; bootstrap async pour poser le token store avant le premier rendu. - `build:capacitor` (`vite build --mode capacitor`) + `.env.capacitor.example` : le build packagé a besoin de l'URL absolue de l'API en dur (pas de "même origine que la page" possible). Vérifié : `pnpm build` + `pnpm lint` verts ; Cypress smoke/layout/sidebar 14/14 en local (le refactor du bootstrap et le choix de routeur ne cassent rien côté web). Refs #39 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-06 03:56:15 +02:00
Nicolas	a8d86c7099	feat(web): passe responsive téléphone pour le contenu des pages (#39 phase 3) ... Réutilise la philosophie déjà en place pour la sidebar (défilement horizontal plutôt que compression illisible) au lieu d'un nouveau patron par page. Tout est strictement additif sous 640px — le rendu desktop est inchangé. - `AppLayout.scss` : `.app-content` passe de `--space-xl` (32px) à `--space-md` (16px) sous 640px — 64px de largeur utile récupérés sur un écran de ~375px. - `planning-page.scss` : la grille 7 jours défile déjà horizontalement (`overflow: auto` + `min-width: 62rem`) ; ce qui casse au tactile, c'est le `✕` de suppression d'une recette (`opacity: 0` hors survol) — épinglé visible + cible tactile agrandie sous 640px, idem le bouton « + ». - `dialog.scss` : `.dialog-panel` garde une gouttière latérale et gagne en hauteur utile sous 640px (le `--space-2xl` vertical est trop cher sur un écran court). - `recipe-picker-dialog.scss` : le split 2 colonnes forcé du catalogue (plus spécifique que le `@media` de recipes.scss) repasse à une colonne sous 640px. Tests : `layout.cy.ts` gagne un bloc « page content under 640px » — padding de `.app-content`, grille sur son propre scroll sans déborder la page, `✕` visible au tactile. 10/10 en local. Refs #39 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-06 03:24:13 +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	1bc9304cdc	feat(planning): glisser-déposer un reste sur un autre créneau ... Dernière PR (4/4) du chantier « gestion des restes » (issue #34). `@dnd-kit/core` (+ `@dnd-kit/utilities`) — première et seule utilisation de DnD de l'app. `PlanningPage` monte un `<DndContext>` (Mouse + Touch + Keyboard sensors, distance d'activation 5px pour ne pas voler le clic « Jeter ») autour de la grille et du panier. - `LeftoversBasket` : chaque ligne a une poignée `⠿` `useDraggable` — le nœud draggable est la poignée elle-même (petite), pas toute la `<li>`, pour qu'une détection de collision au pointeur (`pointerWithin`, repli `closestCenter` pour le clavier) résolve proprement vers la seule case sous le curseur. `data` porte `sourceItemId`/`recipeName`/`available`. - `MealCell` : `useDroppable` (`data: { date, weekDay, meal }`), surbrillance `--drop-over` au survol. Un item « restes » (`sourceItem !== null`) porte un badge ♻️ sur sa pastille. - Au drop, `onDragEnd` ouvre `LeftoverAssignDialog` (quantité, défaut = disponible, plafonné) → `POST /planning/items/leftover` (`apiClient.assignLeftover`) → nouvel item patché dans `planning.items`. Tests : `planning-leftovers.feature` (Gherkin) — parcours complet drag → confirmation quantité → pastille ♻️ visible → compteur du panier à jour ; + jet d'un reste depuis le panier. Le drag est piloté par événements souris bruts (mousedown poignée → mousemove ×2 → mouseup cible). Vérifié localement : 2/2, et aucune régression sur `leftovers-basket.cy.ts` / `planning-page.cy.ts` / `planning.feature`. i18n : `planning.leftovers.*` (badge, poignée, dialogue). Docs : `frontend-architecture.md`. Closes #34 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-06 00:47:49 +02:00
Nicolas	8278878898	feat(planning): panier des restes dans l'en-tête (lecture seule + jeter) ... PR 3/4 du chantier « gestion des restes » (issue #34). `LeftoversBasket` (`features/planning/`) : une icône 🧺 avec badge de compte dans l'en-tête du planning, à côté de `WeekNavigator`. Ouvre un popover listant les restes encore disponibles de la semaine affichée — même patron montage conditionnel + fermeture au `mousedown` extérieur que `CalendarPopover`. Les lignes sont dérivées à chaque rendu de `planning.items` par `collectLeftoverLines` (`leftovers-basket.ts`, pur) : chaque item « frais » (`sourceItem === null`) dont `computeAvailableLeftover` est `> 0`, le `leftoverUses` étant reconstitué depuis le tableau plat (les items « restes » qui pointent vers lui) — aucun aller-retour API en plus. Chaque ligne : recette, jour/repas d'origine, portions restantes, bouton « Jeter » → `PATCH /planning/items/:id/discard-leftover` (`apiClient. discardLeftover`), la réponse est patchée dans `planning.items` par id (`handleLeftoverDiscarded`). État vide quand rien ne reste. Le glisser-déposer d'un reste sur un autre créneau arrive en PR 4. Tests : `leftovers-basket.cy.ts` (mode layout) — badge de compte, ouverture / fermeture au clic extérieur, contenu d'une ligne, état vide, « Jeter » qui appelle le PATCH et retire la ligne. Vérifié localement, 3/3. i18n : `planning.leftovers.*`. Docs : `frontend-architecture.md`. Réf #34 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-06 00:16:00 +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	bc077b770e	fix(recipes): garde le popover de correction ouvert pendant la sélection d'un span ... Depuis la refonte #29-#32, attacher un ingrédient/ustensile/température à une correction de technique demande de surligner le passage concerné dans la description. Mais le `<p>` de la description est un frère du popover dans le DOM, et le listener « clic extérieur » du popover (`mousedown` hors de son propre DOM → `onClose`) fermait le popover dès le `mousedown` qui démarre ce glisser-sélectionner — avant même le `mouseup`. Le `mouseup` ouvrait alors un nouveau popover vierge pour le texte sélectionné, traité comme une toute nouvelle proposition de technique (la technique choisie et les métadonnées déjà ajoutées étaient perdues). `TechStepCorrectionPopover` accepte désormais un prop optionnel `descriptionContainerRef` (le `containerRef` que `StepDescription` a déjà) : un `mousedown` à l'intérieur n'est plus un clic extérieur. `StepDescription` pilote déjà explicitement chaque interaction dans la description (`setActiveCorrection`/`setResolvedMetadataSpan`), donc retirer cette fermeture concurrente ne perd rien ; un clic vraiment ailleurs ferme toujours le popover. Comble aussi le trou de couverture que `TechStepCorrectionPopover.cy.tsx` prétendait déjà délégué à un scénario e2e inexistant : nouveau test dans `recipes.cy.ts` avec une vraie sélection de texte (Range/Selection sur les nœuds `data-offset`, séquence mousedown→mouseup réelle) — vérifié qu'il échoue sans le correctif. Closes #36 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-05 21:01:22 +02:00
Nicolas	1cd886cb8a	test(recipes): fiabilise le scénario 3 pages (scroll réel + log de curseurs) ... Le scénario échouait en CI sur deux points de fragilité, pas sur le fond : 1. `IntersectionObserver` ne se redéclenche qu'à une *transition* d'intersection — avec des pages courtes la sentinelle restait visible en continu et seule la 2e page se chargeait. Les pages font maintenant 15 éléments (la liste déborde son conteneur) et chaque page suivante est tirée par un `scrollTo("bottom")` explicite, répété 5 fois. 2. Une fois la liste débordante, `should("be.visible")` sur un élément sorti du conteneur `overflow:auto` échoue (même classe de bug que #1) — l'assertion "3e page chargée" fait maintenant `.scrollIntoView()` avant. L'assertion anti-boucle porte sur le journal des curseurs demandés (tolérance 2× pour le double-effet React StrictMode du serveur e2e), pas sur un `Set.size` strict. Vérifié localement : 7/7 avec le correctif, "Page 3 Item 1" jamais chargée sans lui. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-05 20:45:58 +02:00
Nicolas	c842fbb348	test(recipes): pilote le scroll dans le scénario 3 pages des sources ... Le scénario ajouté supposait que l'IntersectionObserver se redéclenchait tout seul avec une liste courte — faux : il ne se déclenche qu'à une *transition* d'intersection. Les pages font maintenant 15 éléments (la liste déborde son conteneur, la sentinelle démarre sous la ligne de flottaison) et chaque page suivante est demandée via un `scrollTo("bottom")` explicite, qui produit une vraie transition. Avec l'ancien code bugué, la sentinelle stale rappelle « cursor-2 » au 2e scroll : « Page 3 Item 1 » n'apparaît jamais et un curseur est redemandé — les deux assertions échouent. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-05 20:32:49 +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