v0.3.4-pre.009

docs/plans/025-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT_PLAN.md

@@ -1,11 +1,11 @@
 <!-- file: docs/plans/025-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT_PLAN.md -->
-<!-- version: 14 -->
+<!-- version: 15 -->
 
 # Plan `0.3.4` — Store/PostgreSQL `RawAccountState` + complétude RAW
 
 ## 1. Statut de la release
 
-`0.3.4-pre.001` a figé le design. `0.3.4-pre.002` a matérialisé la fondation physique V002 minimale puis `pre.002-fix.001` a corrigé deux canaris sans toucher au SQL. `0.3.4-pre.003` complète V002 avec les contraintes de domaine, l'index de navigation, la compatibilité de schéma et le checksum final ; `pre.003-fix.001` corrige uniquement l'ordre alphabétique du bloc `const` de `migration.rs` et son gate opérateur complet est PASS. `0.3.4-pre.004` ouvre le mapping PostgreSQL privé et les deux lectures `get` account ; `pre.004-fix.001` corrige uniquement leur conformité au profil Clippy KSP et un canari inutilisé. `pre.005` ajoute l'acquisition atomique, `pre.006` l'observation supplémentaire, `pre.007` la pagination/cursor account et `pre.007-fix.001` réconcilie ses canaris ; le gate opérateur complet du fix est PASS. `pre.008` ouvre les quatre capabilities account sur `PostgresBackend` puis leur dispatch dans `Store`, pour porter l'inventaire RAW à 10/10 sans nouveau SQL ; son gate initial isole uniquement un déplacement erroné de variable dans un canari et `pre.008-fix.001` le corrige sans toucher à la surface fonctionnelle.
+`0.3.4-pre.001` a figé le design. `0.3.4-pre.002` a matérialisé la fondation physique V002 minimale puis `pre.002-fix.001` a corrigé deux canaris sans toucher au SQL. `0.3.4-pre.003` complète V002 avec les contraintes de domaine, l'index de navigation, la compatibilité de schéma et le checksum final ; `pre.003-fix.001` corrige uniquement l'ordre alphabétique du bloc `const` de `migration.rs` et son gate opérateur complet est PASS. `0.3.4-pre.004` ouvre le mapping PostgreSQL privé et les deux lectures `get` account ; `pre.004-fix.001` corrige uniquement leur conformité au profil Clippy KSP et un canari inutilisé. `pre.005` ajoute l'acquisition atomique, `pre.006` l'observation supplémentaire, `pre.007` la pagination/cursor account et `pre.007-fix.001` réconcilie ses canaris ; le gate opérateur complet du fix est PASS. `pre.008` ouvre les quatre capabilities account sur `PostgresBackend` puis leur dispatch dans `Store`, pour porter l'inventaire RAW à 10/10 sans nouveau SQL ; `pre.008-fix.001` corrige son unique canari mal réconcilié et son gate opérateur complet est PASS. `pre.009` ajoute la preuve PostgreSQL live account et réconcilie l'isolation du live RawTransaction avec le schéma V002 complet.
 
 Base canonique auditée :
 
@@ -17,11 +17,11 @@ workspace.package.version = 0.3.3
 Version de travail de cette prerelease :
 
 ```text
-workspace.package.version = 0.3.4-pre.8.fix.1
-label = 0.3.4-pre.008-fix.001
+workspace.package.version = 0.3.4-pre.9
+label = 0.3.4-pre.009
 ```
 
-Décision de scope : `ksp-store-api` reste inchangée. L'audit n'a révélé aucun gap backend-agnostic bloquant ; la difficulté restante est exclusivement l'implémentation physique PostgreSQL et son dispatch par la façade.
+Décision de scope : `ksp-store-api` reste inchangée. L'inventaire backend/façade est désormais 10/10 ; les tranches restantes portent uniquement sur la preuve PostgreSQL réelle, le hardening cross-family, le gate final et la réconciliation documentaire.
 
 ## 2. Invariants hérités et frontières
 
@@ -681,15 +681,19 @@ Les canaris historiques sont transformés pour vérifier l'emplacement des impl
 
 #### `pre.008-fix.001` — Réconciliation du canari `dependency_boundary`
 
-**Statut : réalisé ; gate opérateur complet à rejouer.**
+**Statut : réalisé ; gate opérateur complet PASS.**
 
 Fix strictement borné à `tests/dependency_boundary.rs` : la déclaration `runtime = include_str!("../src/runtime.rs")` est restaurée dans le canari d'ownership `pre.005` qui l'utilise encore pour interdire l'environnement et le SQL physique dans `runtime.rs`, puis retirée du canari V002 `pre.003` où `pre.008` ne l'utilise plus. Aucune assertion de fond, capability, façade, runtime métier, SQL ou migration n'est modifiée.
 
 ### `pre.009` — Preuve PostgreSQL live account
 
-**Statut : planifié.**
+**Statut : réalisé ; gate opérateur standard à rejouer, live opt-in à exécuter sur URI dédiée.**
 
-Budget cible : **15-20 min**. Ajouter la preuve PostgreSQL réelle, ignored/opt-in, couvrant `RawAccountState` et sa coexistence avec la verticale `RawTransaction` existante.
+Budget cible : **15-20 min**. La preuve réelle est matérialisée dans `tests/postgres_raw_account_live.rs`, ignored/opt-in et alimentée exclusivement par une URI dédiée lue depuis stdin sans écho. Elle refuse tout schéma KSP déjà présent, exige PostgreSQL >= 15, ouvre/ferme/re-ouvre le backend V002, vérifie la réparation de l'index account selon `schema_autoupdate`, puis nettoie uniquement le schéma qu'elle a prouvé absent avant démarrage.
+
+La matrice live couvre : domaine `u64::MAX`, data vide et borne exacte 16 MiB, acquisition atomique, idempotence exacte, conflit de contenu sous même référence, deux `state_hash` distincts au même `(pubkey, slot)`, collision de clé observation avec rollback du state nouvellement inséré, observation supplémentaire et `ReferenceNotFound`, round-trip des metadata Yellowstone, pagination ASC/DESC filtrée/non filtrée, cursor `KSPA` hostile/cross-query et rejet cross-family `KSPT`, concurrence identique/divergente, cancellation réelle via `JoinHandle::abort()` pendant un conflit d'observation verrouillé, puis reopen.
+
+La coexistence cross-family est prouvée dans le même schéma : une acquisition account et une acquisition `RawTransaction` peuvent utiliser la même `RawObservationKey` dans leurs tables familiales distinctes, restent lisibles indépendamment et survivent au reopen. Le live `RawTransaction` existant est également réconcilié pour considérer les deux tables V002 account dans son probe et son cleanup d'isolation ; aucune logique métier RawTransaction n'est modifiée.
 
 ### `pre.010` — Hardening et complétude cross-family