v0.3.3-pre.003

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: 2 -->
+<!-- version: 3 -->
 
 # Plan `0.3.3` — Store/PostgreSQL RawTransaction vertical slice
 
@@ -23,13 +23,20 @@ Première tranche validée :
 0.3.3-pre.001 — audit, threat model, physical design, sizing et planning
 ```
 
-Tranche technique courante :
+Tranches techniques validées :
 
 ```text
+0.3.3-pre.001 — audit, threat model, physical design, sizing et planning
 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`.
+Tranche technique courante :
+
+```text
+0.3.3-pre.003 — V001 physique + binding réseau
+```
+
+Les gates opérateur de `pre.001` et `pre.002` sont verts. `pre.003` matérialise le schéma physique V001 et le binding mono-réseau atomique, mais n'ouvre encore ni repository PostgreSQL métier, ni capability RAW, ni dispatch dans `ksp-store-lib`.
 
 ## 2. Sources et autorité
 
@@ -1033,6 +1040,17 @@ Statut matérialisé en `pre.002` :
 - tests de checksum/inventory/bounds ;
 - matérialiser `store.postgres_retention_compaction_unsupported`, sans modifier les contrats stables sauf preuve nouvelle d'un blocage réel.
 
+Statut matérialisé en `pre.003` :
+
+- registre réel `[V000, V001]`, version courante `1` ;
+- V000 reste byte-identique avec son checksum historique ;
+- V001 est embarquée sous `migrations/V001__raw_transaction.sql` avec checksum SHA-256 `6fe57ed0313d2ed295280dd6e49f6d86695d4e4effee2724a25e36db1ea17761` ;
+- V001 crée exactement `ksp_store_identity`, `ksp_raw_transactions`, `ksp_raw_transaction_observations`, `ksp_raw_transaction_archive_payloads` et l'index partiel `(slot, signature)` hors `purged` ;
+- `slot` reste `NUMERIC(20,0)` et toutes les bornes physiques suivent les invariants `ksp-store-api` sans narrowing ;
+- le hook V001 crée puis valide l'identité en `AppliedNow`, et valide seulement en `Existing` ; absence, forme invalide ou réseau différent deviennent un `MigrationMismatch` sûr sans rendre la valeur persistée ;
+- `store.postgres_retention_compaction_unsupported` est réservé par valeur dans le backend et la façade, sans reverse dependency ;
+- aucune capability/repository `RawTransaction*` n'est encore implémentée.
+
 ### `0.3.3-pre.004` — mapping et lectures
 
 - codecs SQL privés ;

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: 2 -->
+<!-- version: 3 -->
 
 # 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. 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.
+Elle démarre en `0.3.3-pre.001` comme matrice de preuve. Les gates opérateur de `pre.001` et `pre.002` sont verts. Les lignes non encore implémentées restent explicitement `À FAIRE`; elles ne sont pas présentées comme acquises.
 
 ## 2. Baseline stable
 
@@ -176,7 +176,7 @@ ksp_raw_transaction_observations
 ksp_raw_transaction_archive_payloads
 ```
 
-Statut `pre.001` : **design seulement**. Aucun de ces objets V001 n'est encore créé.
+Statut `pre.003` : **matérialisé dans V001**. Les quatre tables ci-dessus sont créées par la migration embedded `V001__raw_transaction.sql`; aucune capability/repository ne les consomme encore.
 
 ### 5.2 Indexes
 
@@ -355,7 +355,7 @@ Archived
 Purged
 ```
 
-`Compacted` reste un état logique API connu, explicitement optionnel depuis le plan `0.3.1`, mais non représenté mensongèrement par PostgreSQL `0.3.3`.
+`Compacted` reste un état logique API connu, explicitement optionnel depuis le plan `0.3.1`, mais non représenté mensongèrement par PostgreSQL `0.3.3`. Le code `store.postgres_retention_compaction_unsupported` est matérialisé dès `pre.003` dans `ksp-store-postgres-lib` et `ksp-store-lib` avec la même valeur KSP ; son usage opérationnel par les transitions sera branché en `pre.007`.
 
 ### 14.2 Matrice
 
@@ -446,21 +446,23 @@ Preuves acquises en `pre.002` avant création réelle de V001 :
 - 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 :
+Preuves matérialisées en `pre.003` avec la vraie V001 :
 
-- registre réel `[V000, V001]` ;
-- V000 seule + auto migrate -> V001 appliquée ;
-- V001 checksum divergent -> mismatch ;
-- binding réseau réel dans le hook ;
-- inventaire/checksum exact de V001.
+- registre réel `[V000, V001]` et version courante dérivée `1` ;
+- historique V000 seul reconnu comme préfixe exact avec V001 pending ;
+- historique V000+V001 exact reconnu comme complet ;
+- checksum V001 figé à `6fe57ed0313d2ed295280dd6e49f6d86695d4e4effee2724a25e36db1ea17761` ;
+- binding réseau réel branché dans le hook `StoreIdentity` ;
+- inventaire physique exact : identity, canonical, observations, archive, index partiel ;
+- bornes SQL statiquement alignées sur `u64`, `u32`, `RawTimestamp`, payload 16 MiB et source payload 64 MiB.
 
-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`.
+L'application V000 -> V001, le rollback réel du hook, la réouverture même/autre réseau et la divergence de checksum sur PostgreSQL réel restent à prouver dans le gate live dédié `pre.009`; ils ne sont pas déclarés PASS dans cette tranche.
 
 ### 17.2 Binding réseau atomique
 
 `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.
+`pre.003` branche le hook V001 réel : en contexte `AppliedNow`, il insère la singleton puis relit/valide `ksp_store_identity` avant insertion de l'historique V001 ; en contexte `Existing`, il relit/valide strictement l'identité sans jamais la recréer. Une absence, un nombre de lignes inattendu, une forme invalide ou un réseau différent sont classés `MigrationMismatch` avec phase statique et sans rendre le réseau stocké. L'atomicité PostgreSQL réelle de ce chemin sera prouvée dans `pre.009`.
 
 ## 18. Boundaries
 
@@ -520,9 +522,11 @@ cap 500/1000 dans Store pagination
 
 ### `pre.003`
 
-- V001 + tables/constraints/indexes ;
-- binding réseau ;
-- checksum/inventory tests.
+- V001 + tables/constraints/indexes : PASS statique ;
+- binding réseau hook `AppliedNow`/`Existing` : PASS statique ;
+- checksum/inventory/bounds tests : PASS statique ;
+- code `postgres_retention_compaction_unsupported` backend + façade : PASS ;
+- preuve PostgreSQL réelle V001 : différée à `pre.009`.
 
 ### `pre.004`