feat(categories): v1 IPC seed + i18n keys + migration v8 (#115) #125

Merged

maximus merged 1 commit from issue-115-seed-v1-i18n into main

2026-04-19 20:51:17 +00:00

maximus commented

2026-04-19 20:42:53 +00:00

Owner

Fixes #115

Livraison 1 du milestone spec-refonte-seed-categories-ipc.

Changements

Migration SQL v8 (additive uniquement) :
- ALTER TABLE categories ADD COLUMN i18n_key TEXT
- INSERT OR IGNORE user_preferences.categories_schema_version='v2' pour tagger les profils existants
consolidated_schema.sql réécrit avec le seed v1 IPC complet et categories_schema_version='v1' par défaut (nouveaux profils)
src/data/categoryTaxonomyV1.json livré comme source de vérité TS (sera consommé par #116)
Namespace i18n categoriesSeed.* ajouté FR/EN (150 entrées chacune)
Renderers CategoryTree et CategoryCombobox utilisent i18n_key avec fallback name (catégories utilisateur restent littérales)
Types CategoryTreeNode et CategoryRow gagnent le champ i18n_key bout-en-bout

Vérifications

cargo check + cargo test → 34 passed
npm run build (tsc + vite) → OK
npm test → 133 passed
Migration v8 strictement additive, ne modifie aucune migration existante
Profils v2 existants : aucun changement de contenu, uniquement tagués categories_schema_version='v2'

Dépendances aval

#116 (categoryTaxonomyService) consommera categoryTaxonomyV1.json
#121 (page migration) lira categories_schema_version pour décider d'afficher la migration
#117 (page Guide) utilisera le JSON pour afficher l'arbre

Fixes #115 Livraison 1 du milestone spec-refonte-seed-categories-ipc. ## Changements - **Migration SQL v8** (additive uniquement) : - `ALTER TABLE categories ADD COLUMN i18n_key TEXT` - `INSERT OR IGNORE user_preferences.categories_schema_version='v2'` pour tagger les profils existants - **consolidated_schema.sql** réécrit avec le seed v1 IPC complet et `categories_schema_version='v1'` par défaut (nouveaux profils) - **src/data/categoryTaxonomyV1.json** livré comme source de vérité TS (sera consommé par #116) - **Namespace i18n** `categoriesSeed.*` ajouté FR/EN (150 entrées chacune) - **Renderers** `CategoryTree` et `CategoryCombobox` utilisent `i18n_key` avec fallback `name` (catégories utilisateur restent littérales) - **Types** `CategoryTreeNode` et `CategoryRow` gagnent le champ `i18n_key` bout-en-bout ## Vérifications - `cargo check` + `cargo test` → 34 passed - `npm run build` (tsc + vite) → OK - `npm test` → 133 passed - Migration v8 strictement additive, ne modifie aucune migration existante - Profils v2 existants : aucun changement de contenu, uniquement tagués `categories_schema_version='v2'` ## Dépendances aval - #116 (categoryTaxonomyService) consommera `categoryTaxonomyV1.json` - #121 (page migration) lira `categories_schema_version` pour décider d'afficher la migration - #117 (page Guide) utilisera le JSON pour afficher l'arbre

maximus added 1 commit 2026-04-19 20:42:55 +00:00

feat(categories): add v1 IPC seed, i18n keys, and migration v8 (#115 )

PR Check / rust (push) Successful in 22m29s

Details

PR Check / frontend (push) Successful in 2m18s

Details

PR Check / rust (pull_request) Successful in 22m39s

Details

PR Check / frontend (pull_request) Successful in 2m18s

Details

bd992f2f94

Livraison 1 du milestone spec-refonte-seed-categories-ipc. Applies the
new v1 IPC (Indice des prix à la consommation) taxonomy to freshly
created profiles while leaving existing v2 profiles untouched until the
migration wizard (upcoming issue #121) prompts them to move.

- Migration v8 (additive only):
    - ALTER TABLE categories ADD COLUMN i18n_key TEXT
    - INSERT OR IGNORE user_preferences.categories_schema_version=v2
      (existing profiles tagged as v2 for later migration)
- consolidated_schema.sql rewritten with the full v1 seed and
  categories_schema_version='v1' default for brand-new profiles
- src/data/categoryTaxonomyV1.json bundled as the TS-side source of
  truth (consumed by #116 categoryTaxonomyService next)
- categoriesSeed.* i18n namespace (FR/EN) — 150 entries each
- CategoryTree and CategoryCombobox fall back to the raw `name` when
  i18n_key is null (user-created categories stay literal)
- CategoryTreeNode and CategoryRow gain the i18n_key field end-to-end

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

maximus commented

2026-04-19 20:46:55 +00:00

Author

Owner

Review verdict : APPROVE

Livraison 1 propre et alignée avec le plan. Les 13 fichiers touchés sont cohérents de bout en bout.

Sécurité

Aucun secret ni token dans le diff, aucune surface d'injection (tous les INSERTs SQL du seed sont des littéraux, pas d'entrée utilisateur).
Migration v8 strictement additive (ALTER TABLE ADD COLUMN nullable + INSERT OR IGNORE).

Correctness

Migration v8 ne modifie aucune migration existante (règle .claude/rules/sql-migrations.md respectée).
Pour les profils EXISTANTS : seule la migration v8 s'exécute → colonne i18n_key ajoutée (NULL partout) + categories_schema_version='v2' via INSERT OR IGNORE. Aucun changement de contenu, conforme au plan.
Pour les NOUVEAUX profils : migrations v1-v8 appliquent d'abord le seed v2 historique, puis CONSOLIDATED_SCHEMA fait DELETE FROM keywords; UPDATE transactions SET category_id=NULL; DELETE FROM categories; avant d'insérer le seed v1 dans la plage d'IDs 1000+. INSERT OR REPLACE categories_schema_version='v1' supplante le v2 posé par la migration. Logique correcte.
Renderers (CategoryTree, CategoryCombobox) font t(i18n_key, { defaultValue: name }) — les catégories utilisateur sans i18n_key affichent toujours leur nom littéral.
CategoryTreeNode et CategoryRow propagent le champ i18n_key bout en bout depuis la base jusqu'au rendu.

Qualité

Aucune chaîne UI en dur — tout passe par le namespace categoriesSeed.*.
Pas de any, pas de code mort. Build TSC + Vite OK. 133 tests vitest + 34 tests cargo passent.
Commit message en anglais, format conventionnel, référence l'issue.

Observations non-bloquantes (pour QA #123)

Léger décalage entre le nombre d'entrées i18n_key dans consolidated_schema.sql (151) et le nombre de feuilles du namespace categoriesSeed.* (150 FR/EN). Le fallback defaultValue: name masque l'erreur à l'UI, mais ça vaut une vérif d'appariement au moment du QA — 1 clé orpheline quelque part dans le seed.
src/data/categoryTaxonomyV1.json est livré mais pas encore consommé — c'est voulu (#116 l'utilisera). Le fichier échappe désormais au .gitignore via l'exception !src/data/.

Livrables aval débloqués

#116 (categoryTaxonomyService) peut consommer categoryTaxonomyV1.json
#117 (page Guide) peut afficher l'arbre v1
#119 (categoryMappingService) connaît maintenant les IDs cibles 1000+
#121 (page migration) peut lire categories_schema_version pour décider d'afficher l'invite

## Review verdict : APPROVE Livraison 1 propre et alignée avec le plan. Les 13 fichiers touchés sont cohérents de bout en bout. ### Sécurité - Aucun secret ni token dans le diff, aucune surface d'injection (tous les INSERTs SQL du seed sont des littéraux, pas d'entrée utilisateur). - Migration v8 strictement additive (ALTER TABLE ADD COLUMN nullable + INSERT OR IGNORE). ### Correctness - Migration v8 ne modifie aucune migration existante (règle `.claude/rules/sql-migrations.md` respectée). - Pour les profils EXISTANTS : seule la migration v8 s'exécute → colonne `i18n_key` ajoutée (NULL partout) + `categories_schema_version='v2'` via INSERT OR IGNORE. Aucun changement de contenu, conforme au plan. - Pour les NOUVEAUX profils : migrations v1-v8 appliquent d'abord le seed v2 historique, puis `CONSOLIDATED_SCHEMA` fait `DELETE FROM keywords; UPDATE transactions SET category_id=NULL; DELETE FROM categories;` avant d'insérer le seed v1 dans la plage d'IDs 1000+. `INSERT OR REPLACE categories_schema_version='v1'` supplante le `v2` posé par la migration. Logique correcte. - Renderers (`CategoryTree`, `CategoryCombobox`) font `t(i18n_key, { defaultValue: name })` — les catégories utilisateur sans `i18n_key` affichent toujours leur nom littéral. - `CategoryTreeNode` et `CategoryRow` propagent le champ `i18n_key` bout en bout depuis la base jusqu'au rendu. ### Qualité - Aucune chaîne UI en dur — tout passe par le namespace `categoriesSeed.*`. - Pas de `any`, pas de code mort. Build TSC + Vite OK. 133 tests vitest + 34 tests cargo passent. - Commit message en anglais, format conventionnel, référence l'issue. ### Observations non-bloquantes (pour QA #123) 1. Léger décalage entre le nombre d'entrées `i18n_key` dans `consolidated_schema.sql` (151) et le nombre de feuilles du namespace `categoriesSeed.*` (150 FR/EN). Le fallback `defaultValue: name` masque l'erreur à l'UI, mais ça vaut une vérif d'appariement au moment du QA — 1 clé orpheline quelque part dans le seed. 2. `src/data/categoryTaxonomyV1.json` est livré mais pas encore consommé — c'est voulu (#116 l'utilisera). Le fichier échappe désormais au `.gitignore` via l'exception `!src/data/`. ### Livrables aval débloqués - #116 (categoryTaxonomyService) peut consommer `categoryTaxonomyV1.json` - #117 (page Guide) peut afficher l'arbre v1 - #119 (categoryMappingService) connaît maintenant les IDs cibles 1000+ - #121 (page migration) peut lire `categories_schema_version` pour décider d'afficher l'invite