v0.3.4-pre.004

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: 6 -->
+<!-- version: 7 -->
 
 # 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, toujours sans repository account ni dispatch façade ; `pre.003-fix.001` corrige ensuite uniquement l'ordre alphabétique du bloc `const` de `migration.rs` révélé par `RUST-FMT-104`.
+`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 maintenant le mapping PostgreSQL privé et les deux lectures `get` account, sans write, pagination ni implémentation de capability.
 
 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.3.fix.1
-label = 0.3.4-pre.003-fix.001
+workspace.package.version = 0.3.4-pre.4
+label = 0.3.4-pre.004
 ```
 
 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.
@@ -585,7 +585,7 @@ Aucune ressource SQL, migration, table, contrainte, index, surface runtime ou ca
 
 ### `pre.003` — Contraintes, index et schema compatibility V002
 
-**Statut : réalisé ; corrigé par `pre.003-fix.001`, gate opérateur complet du fix à rejouer.**
+**Statut : réalisé ; corrigé par `pre.003-fix.001`, gate opérateur complet PASS.**
 
 Budget cible : **15-20 min**. V002 est complétée à **32 resources** : deux tables, 29 contraintes (PK/FK incluses) et un index non unique `(slot, pubkey, state_hash)` sans prédicat. Les contraintes matérialisent les bornes backend-agnostic existantes : fixed-width 32/64 bytes, domaines `u64` via `NUMERIC(20,0)`, data `<= 16 MiB`, codes de provenance 1..128 octets/alphabet sûr, timestamps bornés, ordre `observed_at <= received_at` et source payload `<= 64 MiB`.
 
@@ -597,7 +597,7 @@ Gate de base `pre.002-fix.001` fourni le 2026-08-30 : audits Rust/Markdown, `car
 
 #### `pre.003-fix.001` — ordre alphabétique du bloc `const` migration
 
-**Statut : réalisé ; gate opérateur complet du fix à rejouer.**
+**Statut : réalisé ; gate opérateur complet PASS.**
 
 Le gate opérateur de `pre.003` confirme `cargo check --workspace`, Clippy all-targets, `ksp-store-api`, `ksp-store-lib`, `ksp-store-postgres-lib` (45 tests), `ksp-config-lib` et `ksp-store-lib --no-default-features`, mais l'audit Rust détecte une unique violation `RUST-FMT-104` dans `src/migration.rs`. Le correctif déplace seulement `HISTORY_LOAD_SQL` avant `HISTORY_UPDATE_CHECKSUM_SQL` afin de restaurer l'ordre alphabétique du bloc homogène de constantes.
 
@@ -605,9 +605,15 @@ Aucune valeur de constante, requête SQL, ressource V002, checksum, logique de m
 
 ### `pre.004` — Mapping privé et lectures `get`
 
-**Statut : planifié.**
+**Statut : réalisé ; gate opérateur complet à rejouer.**
 
-Budget cible : **15-20 min**. Implémenter le mapping privé state/observation, les lectures `get` et les hostile-row guards. Aucun write account dans cette tranche.
+Budget cible : **15-20 min**. Le module privé `src/raw_account.rs` possède désormais les deux SELECT de lecture et les codecs physiques de `RawAccountState` / `RawAccountObservation`. `PostgresBackend` expose uniquement `get_raw_account_state` et `get_raw_account_observation` avec des modèles `ksp-store-api` ; aucun `tokio_postgres::Row`, SQL ou type physique ne traverse le bridge.
+
+Le mapping revalide les invariants même si PostgreSQL devait contenir une ligne hostile : `pubkey`/owner/hash/key en largeur exacte, signature optionnelle à 64 bytes, `slot`/`lamports`/`rent_epoch`/`write_version` via `NUMERIC(20,0)::text -> u64`, timestamps et source payload size bornés, provenance reconstruite via les constructeurs API et ordre `observed_at <= received_at`. Les bytes account sont admis via `RawAccountState::try_new`, donc data vide reste valide et `> 16 MiB` devient `DataInvalid`.
+
+Le `RawAccountStateReference` reçu par `get` est vérifié contre le réseau mono-backend **avant `pool.get()`**. `RawObservationKey` ne porte pas de réseau ; le réseau de la référence account reconstruite provient exclusivement du backend déjà lié par `ksp_store_identity`.
+
+La tranche reste strictement read-only : aucun `INSERT`, `UPDATE`, `DELETE`, `ON CONFLICT`, `FOR UPDATE`, cursor ou `list_raw_account_states`. Les quatre `impl RawAccount* for PostgresBackend` restent interdits jusqu'à `pre.008`; `pre.005` et `pre.006` possèdent encore les écritures.
 
 ### `pre.005` — Acquisition atomique et idempotence