Commit graph

4 commits

Author SHA1 Message Date
766d48eaa5 feat(recipes): préférences de sources par foyer + distinction officielle/non-officielle
Répond à deux besoins : permettre à chaque foyer de choisir quelles
sources apparaissent dans ses onglets de recettes, et distinguer les
sources à API officielle des sources scrapées.

- RecipeSourceAdapter.official (booléen, sans défaut — chaque
  adaptateur doit le déclarer explicitement) synchronisé sur
  Source.official par syncRecipeSources.
- HouseSource : table de jointure opt-in (House <-> Source) — aucune
  ligne = source masquée. Un foyer nouvellement créé ne voit aucune
  source tant qu'il ne les active pas explicitement.
- GET /reference/sources (catalogue des sources implémentées, avec le
  flag officiel).
- GET/PATCH /house/current/sources (lecture/remplacement complet des
  sources activées par le foyer courant).
- recipe.service.ts : sourceVisibilityWhere() filtre désormais TOUS
  les onglets (perso/foyer/publique/favoris) — une recette sans
  source reste toujours visible ; une recette importée ne l'est que
  si sa source est activée pour le foyer du viewer. Un viewer sans
  foyer ne voit aucune recette sourcée.

Côté web :
- Nouvelle étape /onboarding/sources dans le wizard d'inscription,
  atteinte uniquement si un foyer vient d'être créé/rejoint (sinon on
  saute direct aux allergènes) ; s'auto-saute aussi si aucune source
  n'est encore implémentée (catalogue vide aujourd'hui).
- Nouvelle section « Sources de recettes » dans /parametres/foyer
  (masquée dans les mêmes conditions), avec sauvegarde à la volée
  (même pattern que les autres préférences hot-saved).
- SourceSelect (features/house/), grille de cases à cocher avec badge
  officiel/non-officielle, sur le même principe qu'AllergySelect.

172 tests backend passent (dont 25 nouveaux). Build et lint propres.
Vérifié manuellement en navigateur : le parcours d'onboarding saute
bien l'étape sources (catalogue vide) et affiche « 4 sur 4 » quand un
foyer a été créé ; la section paramètres reste invisible tant
qu'aucune source n'existe.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-20 09:22:54 +02:00
60ca850042 Web: parcours d'inscription réordonné — régime, foyer (optionnel), allergènes (step 7/8)
- Ordre: régime (1) → foyer (2) → allergènes (3), au lieu de
  foyer → régime → allergènes
- L'étape foyer est désormais optionnelle: créer, rejoindre par code
  d'invitation, ou passer (aucun foyer n'est créé au signup)
2026-08-17 10:48:31 +02:00
8f25e53f11 Web: allergies/intolérances séparées + hot saving sur /foyer (step 8/8)
Retour fonctionnel : allergies et intolérances doivent être distinguées
dans l'UI, et /foyer doit sauvegarder à la volée plutôt que via des
boutons "Enregistrer".

- AllergySelect prend un `legend` en prop au lieu d'un libellé interne
  fixe — le même composant est rendu deux fois par chaque page
  consommatrice (HouseholdPage, OnboardingAllergensPage), une fois par
  `kind` (ALLERGY / INTOLERANCE), la sélection restant une seule liste
  d'IDs partagée.
- HouseholdPage : suppression des boutons "Enregistrer", autosave
  déclenché depuis le handler onChange de chaque champ (jamais un
  useEffect générique sur la valeur — se déclencherait aussi au
  chargement initial, sans distinction propre "chargé" vs "modifié").
  Nom du foyer et allergènes/intolérances debouncés (600ms/500ms),
  régime sauvegardé immédiatement (sélection discrète). Validation
  client (nom vide) empêche l'autosave plutôt que de déclencher un
  aller-retour API voué à l'échec.
- i18n : household.form.allergiesLabel devient "Allergies" (au lieu de
  "Allergies & intolérances"), nouvelle clé intolerancesLabel, save/
  saved remplacés par saving/saved (plus de bouton à libeller).
- Cypress (household.cy.ts réécrit, onboarding.cy.ts mis à jour) +
  specs/frontend-architecture.md + README.md.

Vérifié dans le navigateur : wizard d'inscription affiche bien les
deux groupes (12 allergies / 2 intolérances) ; /foyer sans aucun
bouton, chaque section sauvegarde automatiquement (vérifié en base
après édition du nom du foyer et du régime) ; compte de test nettoyé.

Clôt le retour fonctionnel sur la feature profil/foyer/régime/
allergènes (8 commits au total sur cette PR).
2026-08-17 00:09:09 +02:00
7bc81f51fb Web: wizard d'inscription (foyer/régime/allergènes) (step 4/6)
- SignupPage: après signup(), navigate("/onboarding/foyer") au lieu de
  "/" — la home reste inchangée, seule la destination change.
- pages/onboarding/: 3 routes top-level RequireAuth-gated (PAS nichées
  sous AppLayout — wizard plein écran sans sidebar, même langage visuel
  que /login|/signup) :
  - /onboarding/foyer — HouseNameField, préremplie avec le nom
    auto-généré du foyer (continuer sans éditer = skip implicite).
  - /onboarding/regime — DietSelect, valeur initiale depuis
    useAuth().user.dietId (pas de fetch supplémentaire nécessaire).
  - /onboarding/allergenes — AllergySelect, termine sur navigate("/").
- Bug trouvé et corrigé en testant dans le navigateur : RedirectIfAuthenticated
  redirigeait vers "/" en course avec le navigate() explicite de
  SignupPage — `user` devient non-null (via signup()) pendant que
  SignupPage est encore monté sous ce guard, qui réagit et redirige
  avant que le navigate("/onboarding/foyer") ne prenne effet. Latent
  depuis le début (invisible avant car l'ancien SignupPage naviguait
  aussi vers "/", donc les deux redirections concordaient). Fix : la
  décision de redirection est verrouillée une seule fois, au moment où
  la vérification initiale (`isLoading`) se termine, plutôt que
  réévaluée à chaque changement de `user`.

Vérifié de bout en bout dans le navigateur (inscription → 3 étapes →
home), données confirmées en base (foyer renommé, régime + 2 allergènes
enregistrés), puis nettoyage des comptes de test.
2026-08-16 23:31:59 +02:00