v0.3.3-pre.002

docs/plans/024-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/024-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION_PLAN.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Plan `0.3.3` — Store/PostgreSQL RawTransaction vertical slice
 
@@ -17,13 +17,19 @@ Base canonique auditée :
 v0.3.2
 ```
 
-Première tranche :
+Première tranche validée :
 
 ```text
 0.3.3-pre.001 — audit, threat model, physical design, sizing et planning
 ```
 
-`pre.001` est volontairement une tranche de conception. Elle ne crée ni migration métier `V001`, ni repository PostgreSQL métier, ni dispatch RAW dans `ksp-store-lib`.
+Tranche technique courante :
+
+```text
+0.3.3-pre.002 — moteur de migrations multi-version
+```
+
+`pre.001` est restée volontairement une tranche de conception. Son gate opérateur est vert. `pre.002` généralise uniquement le moteur de migrations PostgreSQL ; elle ne crée toujours ni migration métier `V001`, ni repository PostgreSQL métier, ni dispatch RAW dans `ksp-store-lib`.
 
 ## 2. Sources et autorité
 
@@ -1007,6 +1013,18 @@ L'audit montre que le moteur de migration `0.3.2` doit être généralisé avant
 - préparer le hook atomique de binding réseau ;
 - ajouter les tests du moteur sans créer encore de repository métier.
 
+Statut matérialisé en `pre.002` :
+
+- registre embedded privé ordonné, actuellement limité à V000 ;
+- version courante dérivée du dernier élément du registre plutôt que d'une constante V000 dédiée ;
+- historique validé comme préfixe exact et immuable du registre ;
+- migrations pending appliquées séquentiellement dans la transaction déjà protégée par advisory lock ;
+- `auto_migrate = false` refuse tout préfixe incomplet par `migration_pending` ;
+- hook de migration exécuté pour les versions déjà appliquées à chaque ouverture et, pour une nouvelle version, après son SQL mais avant insertion de l'historique et commit ;
+- `RawNetworkId` est déjà transmis jusqu'au hook afin que `pre.003` puisse binder V001 atomiquement sans déplacer la frontière transactionnelle ;
+- V000 conserve strictement son SQL et son checksum historique ;
+- aucun fichier V001 ni objet `ksp_store_identity` n'est encore créé.
+
 ### `0.3.3-pre.003` — V001 physique + binding réseau
 
 - créer V001 ;

docs/validation/020-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/validation/020-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Validation `0.3.3` — Store/PostgreSQL RawTransaction vertical slice
 
@@ -11,7 +11,7 @@ Cette validation accompagne :
 0.3.3 — Store/PostgreSQL RawTransaction vertical slice
 ```
 
-Elle démarre en `0.3.3-pre.001` comme matrice de preuve. Les lignes non encore implémentées restent explicitement `À FAIRE`; elles ne sont pas présentées comme acquises.
+Elle démarre en `0.3.3-pre.001` comme matrice de preuve. Le gate opérateur de `pre.001` est vert. Les lignes non encore implémentées restent explicitement `À FAIRE`; elles ne sont pas présentées comme acquises.
 
 ## 2. Baseline stable
 
@@ -434,21 +434,33 @@ SQLSTATE et texte PostgreSQL ne font pas partie du contrat public.
 
 ### 17.1 Multi-version
 
-Preuves nécessaires avant V001 :
+Preuves acquises en `pre.002` avant création réelle de V001 :
 
-- V000 reste checksum-identique ;
-- registre embedded ordonné `[V000, V001]` ;
-- historique vide -> bootstrap correct ;
+- V000 reste byte-identique et conserve le checksum `d29068b8c13b9dc0cc9ef6aaadd0fa12d41e0fe4c56541a1118c4bfc846a1450` ;
+- le registre embedded privé est ordonné et commence à V000 ;
+- le moteur valide un historique comme préfixe exact du registre ;
+- un registre synthétique `[V000, V001]` prouve qu'un historique V000 seul retourne l'index pending V001 sans être classé mismatch ;
+- nom/checksum divergent, historique vide avec metadata existante ou trou de préfixe -> mismatch ;
+- version supérieure au registre connu -> schema newer, sans down migration ;
+- `auto_migrate = false` refuse un registre incomplet par `migration_pending` ;
+- les migrations pending sont appliquées dans l'ordre sous la transaction et l'advisory lock déjà acquis ;
+- chaque migration vérifie encore la forme de la metadata avant d'insérer sa ligne d'historique.
+
+Preuves différées à `pre.003` après création de la vraie V001 :
+
+- registre réel `[V000, V001]` ;
 - V000 seule + auto migrate -> V001 appliquée ;
-- V000 seule + auto migrate disabled -> pending/non-ready ;
 - V001 checksum divergent -> mismatch ;
-- version > V001 -> schema newer ;
-- ligne de migration manquante/divergente -> mismatch ;
-- deux open concurrents -> advisory lock, historique unique.
+- binding réseau réel dans le hook ;
+- inventaire/checksum exact de V001.
+
+La concurrence PostgreSQL réelle du moteur reste couverte par la preuve foundation acquise en `0.3.2`; la vertical slice métier recevra sa propre preuve live en `pre.009`.
 
 ### 17.2 Binding réseau atomique
 
-L'identité réseau doit être créée/validée avant commit du bootstrap V001. Un crash ne doit pas pouvoir laisser V001 « appliquée » avec une base prête mais sans identité exploitable.
+`pre.002` prépare la frontière sans créer l'identité : `RawNetworkId` est transmis au moteur et chaque migration possède un hook privé exécuté sous la même transaction/advisory lock. Deux contextes sont distingués : `AppliedNow` pour une migration qui vient d'être exécutée et `Existing` pour une migration déjà présente dans l'historique lors d'une réouverture. V000 déclare explicitement le hook neutre.
+
+`pre.003` ajoutera le hook V001 réel : en contexte `AppliedNow`, il créera puis validera `ksp_store_identity` avant insertion de l'historique V001 ; en contexte `Existing`, il validera strictement l'identité existante sans la recréer si elle a disparu. Un échec du binding fera donc rollback du SQL V001 et de son historique lors d'une première application, et une réouverture d'une base V001 incohérente échouera avant exposition du backend prêt.
 
 ## 18. Boundaries
 
@@ -500,9 +512,11 @@ cap 500/1000 dans Store pagination
 
 ### `pre.002`
 
-- migration registry multi-version ;
-- tests V000 conservés ;
-- préparation binding.
+- migration registry multi-version : PASS statique ;
+- V000/checksum conservés : PASS ;
+- validation préfixe/mismatch/newer : PASS unit design + canaris source ;
+- préparation hook binding réseau transactionnel : PASS ;
+- aucune V001 métier créée : PASS.
 
 ### `pre.003`
 
@@ -560,7 +574,7 @@ cap 500/1000 dans Store pagination
 
 - publication stable.
 
-## 22. Gate courant `pre.001`
+## 22. Gate courant `pre.002`
 
 ```bash
 cargo fmt --all