Migrations de données

Contexte Pré-v1

L’application possède actuellement 0 utilisateur actif.

Nous pouvons donc corriger avant v1 des noms, routes et structures qui seraient beaucoup plus coûteux après adoption.

Cela ne signifie pas « tout reset ».

Deux catégories

Nettoyage sans contrat externe

Peut être fait directement avant v1 après mise à jour des références/tests :

• routes legacy ;
• labels UI ;
• noms internes non publiés ;
• tables/données de démonstration dont la suppression est validée ;
• package names dans un chantier dédié.

Migration de données réelles du runtime

Pour ledger, générations, blobs, connecteurs, auth et autres données utiles :

Expand → Backfill → Verify → Switch → Contract

Même avec 0 user, nous conservons cette discipline lorsque les données servent à valider le moteur.

Prisma

Le repo app utilise des migrations Prisma committées.

• jamais prisma db push comme stratégie de migration ;
• jamais de reset aveugle d’une base partagée ;
• conserver les IDs lorsqu’ils ont une valeur métier ;
• vérifier le drift.

Brain legacy

BrainEntry peut être remplacé avant v1, mais le mapping vers Memory doit être explicite et testable afin de préserver les fixtures, sources et apprentissages utiles.