v0.3.4-pre.010

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: 15 -->
+<!-- version: 16 -->
 
 # 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 ; `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.
+`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 ; son gate standard et son live account sur PostgreSQL 17 sont PASS. `pre.010` ferme le hardening et la complétude cross-family sans modifier le runtime ou les migrations.
 
 Base canonique auditée :
 
@@ -17,8 +17,8 @@ workspace.package.version = 0.3.3
 Version de travail de cette prerelease :
 
 ```text
-workspace.package.version = 0.3.4-pre.9
-label = 0.3.4-pre.009
+workspace.package.version = 0.3.4-pre.10
+label = 0.3.4-pre.010
 ```
 
 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.
@@ -687,7 +687,7 @@ Fix strictement borné à `tests/dependency_boundary.rs` : la déclaration `runt
 
 ### `pre.009` — Preuve PostgreSQL live account
 
-**Statut : réalisé ; gate opérateur standard à rejouer, live opt-in à exécuter sur URI dédiée.**
+**Statut : réalisé ; gate opérateur standard PASS et live account PASS sur PostgreSQL 17.**
 
 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.
 
@@ -697,9 +697,15 @@ La coexistence cross-family est prouvée dans le même schéma : une acquisition
 
 ### `pre.010` — Hardening et complétude cross-family
 
-**Statut : planifié.**
+**Statut : réalisé ; gate opérateur complet à rejouer.**
 
-Budget cible : **15-20 min**. Fermer les canaries de sécurité, ownership et complétude cross-family sans ajouter de nouveau scope métier.
+Budget cible : **15-20 min**. La tranche n'ajoute aucun runtime, SQL, migration, capability ou type public. Elle ferme les canaris de sécurité, ownership et complétude cross-family autour de la surface effectivement validée.
+
+Les canaris backend figent désormais explicitement : surface SQL account non destructive et keyset-only ; cursor `KSPA` distinct du cursor transaction `KSPT` ; V002 exactement 32 resources (2 tables, 2 PK, 1 FK state-local, 26 CHECK, 1 index non filtré) ; absence totale de table/FK/registry transaction dans V002 ; `transaction_signature` account reste une metadata fixed-width sans FK vers `ksp_raw_transactions`.
+
+Les canaris façade comparent directement les noms des dix traits RAW implémentés par `Store` et `PostgresBackend`, imposent l'égalité exacte des deux ensembles et interdisent toute apparition implicite de retention/delete/compaction account. Les inventaires publics, dépendances, guards réseau, erreurs sûres, absence d'environnement/SQL physique dans la façade et placement des implémentations backend restent couverts par les canaris hérités.
+
+`ksp-store-api`, tous les fichiers `src/`, les tests live et les migrations V000/V001/V002 restent byte-inchangés par cette tranche.
 
 ### `pre.011` — Gate technique final