docs(collapse) : ADR 0016 persistance UI par-profil + guide utilisateur + architecture #291

New issue

Open

opened 2026-07-16 00:26:33 +00:00 by maximus · 0 comments

maximus commented

2026-07-16 00:26:33 +00:00

Owner

Refs: spec-decisions-collapse-multi-niveaux.md + spec-plan-collapse-multi-niveaux.md (plan v2)

Depends on

#288, #289, #290 (documenter le comportement final une fois les 3 issues fusionnees — evite de rediger la doc 3 fois a moitie)

Contexte

Le CLAUDE.md du projet impose deux mises a jour doc que ni Max ni le plan initial n'avaient verbalisees :

Guide utilisateur — tout changement affectant l'usage de l'app (le guide a deja des sections « 8. Budget » et « 9. Rapports », et documente deja un pattern de repli pour le Bilan).
ADR — toute decision technique structurante. Faire migrer l'etat UI de localStorage vers user_preferences en est une : elle pose le precedent « etat UI par-profil → base du profil ; etat UI machine → localStorage ».

Travail a faire

Creer docs/adr/0016-persistance-etat-ui-par-profil.md (prochain numero libre — 0011..0015 pris) : Context / Decision / Consequences / Date + status: accepted.
- Decision : l'etat UI specifique a un profil (repli des categories) vit dans user_preferences (base SQLite du profil), pas dans localStorage.
- Rationale : deleteProfile detruit la base mais ne purge aucun localStorage → une cle par-profil en localStorage serait un residu survivant a la suppression, revelant quelles categories un profil (potentiellement PIN-protege) a explorees. Incompatible privacy-first.
- Consequence : hydratation asynchrone (acceptable — defaut « tout replie » = pas de flash) ; l'etat UI machine-globale (theme, position des sous-totaux, mode de periode Cartes) reste en localStorage. Tracer la frontiere.
docs/guide-utilisateur.md — section 8 (Budget) et section 9 (Rapports) : documenter le repli a chaque niveau, le defaut « tout replie », le bouton « Tout deplier / Tout replier », la memorisation par profil.
Cles i18n docs.* correspondantes dans src/i18n/locales/{fr,en}.json (le guide est bilingue).
docs/architecture.md — la table des hooks / la ligne user_preferences : noter que useCollapsibleGroups persiste desormais l'etat de repli par profil.

Fichiers concernes

docs/adr/0016-persistance-etat-ui-par-profil.md (cree)
docs/guide-utilisateur.md
docs/architecture.md
src/i18n/locales/{fr,en}.json (cles docs.*)
CHANGELOG.md, CHANGELOG.fr.md (si une entree docs est jugee utile — sinon s'abstenir)

Tests

Aucun (documentation). Verifier que les cles i18n docs.* ajoutees existent dans les deux langues (regle projet).

Review caveats

🟡 Frontiere localStorage vs user_preferences : l'ADR doit l'enoncer clairement, sinon le prochain etat UI par-profil repartira en localStorage par defaut.

Decisions prises en planification

Doc groupee en une issue dediee (tranche avec Max) plutot que repartie dans A/B/C : le comportement final n'est stable qu'apres fusion des trois, et A/B/C ecriraient dans les MEMES fichiers (guide + locales) → conflits garantis.

Criteres d'acceptation

docs/adr/0016-*.md cree, status: accepted, avec la frontiere localStorage/user_preferences explicite
docs/guide-utilisateur.md sections 8 et 9 decrivent le repli multi-niveaux
Cles docs.* presentes en FR et EN
docs/architecture.md reflete la persistance par profil de l'etat de repli

Spec source

spec-plan-collapse-multi-niveaux.md (v2)

Refs: `spec-decisions-collapse-multi-niveaux.md` + `spec-plan-collapse-multi-niveaux.md` (plan **v2**) ## Depends on - #288, #289, #290 (documenter le comportement **final** une fois les 3 issues fusionnees — evite de rediger la doc 3 fois a moitie) ## Contexte Le `CLAUDE.md` du projet impose deux mises a jour doc que ni Max ni le plan initial n'avaient verbalisees : - **Guide utilisateur** — tout changement affectant l'usage de l'app (le guide a deja des sections « 8. Budget » et « 9. Rapports », et documente deja un pattern de repli pour le Bilan). - **ADR** — toute decision technique structurante. Faire migrer l'etat UI de `localStorage` vers `user_preferences` en est une : elle pose le precedent « etat UI **par-profil** → base du profil ; etat UI **machine** → localStorage ». ## Travail a faire - [ ] **Creer `docs/adr/0016-persistance-etat-ui-par-profil.md`** (prochain numero libre — 0011..0015 pris) : Context / Decision / Consequences / Date + status: accepted. - Decision : l'etat UI **specifique a un profil** (repli des categories) vit dans `user_preferences` (base SQLite du profil), pas dans `localStorage`. - Rationale : `deleteProfile` detruit la base mais ne purge aucun `localStorage` → une cle par-profil en localStorage serait un **residu** survivant a la suppression, revelant quelles categories un profil (potentiellement PIN-protege) a explorees. Incompatible privacy-first. - Consequence : hydratation **asynchrone** (acceptable — defaut « tout replie » = pas de flash) ; l'etat UI **machine-globale** (theme, position des sous-totaux, mode de periode Cartes) reste en `localStorage`. Tracer la frontiere. - [ ] **`docs/guide-utilisateur.md`** — section 8 (Budget) et section 9 (Rapports) : documenter le repli a chaque niveau, le defaut « tout replie », le bouton « Tout deplier / Tout replier », la memorisation par profil. - [ ] **Cles i18n `docs.*`** correspondantes dans `src/i18n/locales/{fr,en}.json` (le guide est bilingue). - [ ] **`docs/architecture.md`** — la table des hooks / la ligne `user_preferences` : noter que `useCollapsibleGroups` persiste desormais l'etat de repli par profil. ## Fichiers concernes - `docs/adr/0016-persistance-etat-ui-par-profil.md` (**cree**) - `docs/guide-utilisateur.md` - `docs/architecture.md` - `src/i18n/locales/{fr,en}.json` (cles `docs.*`) - `CHANGELOG.md`, `CHANGELOG.fr.md` (si une entree docs est jugee utile — sinon s'abstenir) ## Tests Aucun (documentation). Verifier que les cles i18n `docs.*` ajoutees existent dans **les deux** langues (regle projet). ## Review caveats - 🟡 **Frontiere localStorage vs user_preferences** : l'ADR doit l'enoncer clairement, sinon le prochain etat UI par-profil repartira en localStorage par defaut. ## Decisions prises en planification - Doc groupee en une issue dediee (tranche avec Max) plutot que repartie dans A/B/C : le comportement final n'est stable qu'apres fusion des trois, et A/B/C ecriraient dans les MEMES fichiers (guide + locales) → conflits garantis. ## Criteres d'acceptation - [ ] `docs/adr/0016-*.md` cree, status: accepted, avec la frontiere localStorage/user_preferences explicite - [ ] `docs/guide-utilisateur.md` sections 8 et 9 decrivent le repli multi-niveaux - [ ] Cles `docs.*` presentes en FR **et** EN - [ ] `docs/architecture.md` reflete la persistance par profil de l'etat de repli ## Spec source spec-plan-collapse-multi-niveaux.md (v2)