v0.3.4-pre.009

This commit is contained in:
2026-08-30 23:39:43 +02:00
parent b756da5149
commit 13687ec2fe
7 changed files with 1555 additions and 19 deletions

View File

@@ -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``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éde.**
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

View File

@@ -1,11 +1,11 @@
<!-- file: docs/validation/021-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT.md -->
<!-- version: 13 -->
<!-- version: 14 -->
# Validation `0.3.4` — Store/PostgreSQL `RawAccountState` + complétude RAW
## 1. Portée
Cette matrice est ouverte par `0.3.4-pre.001`. `0.3.4-pre.002` matérialise la fondation V002 minimale et `pre.002-fix.001` corrige deux canaris sans modifier le SQL ; son gate opérateur complet est PASS. `0.3.4-pre.003` complète les contraintes de domaine, l'index de navigation, la compatibilité externe et le checksum V002 final ; `pre.003-fix.001` corrige uniquement l'ordre alphabétique du bloc `const` et son gate opérateur complet est PASS. `pre.004` à `pre.007` matérialisent successivement mapping/read, writes, observation supplémentaire et pagination account ; `pre.007-fix.001` clôt son gate opérateur en PASS. `pre.008` ouvre les quatre capabilities account dans `PostgresBackend` et `Store`, portant l'inventaire RAW statique à 10/10 ; son gate initial échoue uniquement sur un canari `dependency_boundary` mal réconcilié et `pre.008-fix.001` corrige ce déplacement de variable sans toucher à la verticale. La preuve PostgreSQL live reste réservée à `pre.009`.
Cette matrice est ouverte par `0.3.4-pre.001`. `0.3.4-pre.002` matérialise la fondation V002 minimale et `pre.002-fix.001` corrige deux canaris sans modifier le SQL ; son gate opérateur complet est PASS. `0.3.4-pre.003` complète les contraintes de domaine, l'index de navigation, la compatibilité externe et le checksum V002 final ; `pre.003-fix.001` corrige uniquement l'ordre alphabétique du bloc `const` et son gate opérateur complet est PASS. `pre.004` à `pre.007` matérialisent successivement mapping/read, writes, observation supplémentaire et pagination account ; `pre.007-fix.001` clôt son gate opérateur en PASS. `pre.008` ouvre les quatre capabilities account dans `PostgresBackend` et `Store`, portant l'inventaire RAW statique à 10/10 ; `pre.008-fix.001` corrige son unique canari mal réconcilié et son gate opérateur complet est PASS. `pre.009` matérialise la preuve PostgreSQL live account, la concurrence/cancellation réelle et la coexistence RawTransaction sans modifier les migrations.
Base :
@@ -278,8 +278,8 @@ Le test live account devra être opt-in/ignored, URI stdin, sans environnement n
| pre.005 | acquisition atomique state+observation + idempotence/conflict | PASS |
| pre.006 | observation supplémentaire + races/cancellation unitaires | PASS |
| pre.007 | list RawAccountStateQuery + keyset cursor V1 account | PASS |
| pre.008 | 4 impl backend + 4 dispatch Store + conformance 10/10 | CURRENT |
| pre.009 | preuve PostgreSQL live account + coexistence RawTransaction | PLANNED |
| pre.008 | 4 impl backend + 4 dispatch Store + conformance 10/10 | PASS |
| pre.009 | preuve PostgreSQL live account + coexistence RawTransaction | CURRENT |
| pre.010 | hardening/completeness cross-family + canaries ownership | PLANNED |
| pre.011 | gate technique final + replay live ciblé + graphes | PLANNED |
| pre.012 | réconciliation docs finale sans rouvrir le code | PLANNED |
@@ -599,4 +599,63 @@ let runtime = include_str!("../src/runtime.rs");
vers le canari qui le consomme effectivement. Les assertions de placement 10/10 restent inchangées : les implémentations account demeurent uniques dans `runtime.rs`, absentes de `raw_account.rs`, et les couches migration/schema restent sans capability métier. Aucun fichier de production, SQL runtime ou migration V000/V001/V002 n'est modifié.
Le checksum V002 reste `ff21605ed45f7ab4c0f92bbb692700b4118a9488b04d50a31d259ac59bdb550e`. Le gate opérateur complet doit être rejoué sur `0.3.4-pre.8.fix.1`.
Le checksum V002 reste `ff21605ed45f7ab4c0f92bbb692700b4118a9488b04d50a31d259ac59bdb550e`. Le gate opérateur complet du 2026-08-30 sur `0.3.4-pre.8.fix.1` est **PASS** : audits Rust/Markdown, workspace check, Clippy all-targets, Store API, Store façade, backend PostgreSQL (63 tests unitaires + 13 dependency + 7 hardening + 13 public), Config et `--no-default-features` sont verts.
## 28. Verdict `pre.009`
Preuve PostgreSQL live `RawAccountState` : **matérialisée ; gate opérateur standard et exécution live opt-in à rejouer**.
Nouveau test :
```text
crates/ksp-store-postgres-lib/tests/postgres_raw_account_live.rs
#[ignore = "opt-in real PostgreSQL RawAccountState proof; reads one dedicated URI from stdin"]
```
Invariants d'exploitation :
```text
URI dédiée lue depuis stdin uniquement
aucune lecture d'environnement
aucun affichage de l'URI
refus si une table KSP managée existe déjà
PostgreSQL >= 15
cleanup uniquement après preuve d'absence initiale
reopen health migration_version = 2
```
Matrice matérialisée :
| Scénario | Preuve `pre.009` |
|--------------------------------------------|--------------------------------------|
| bootstrap/reopen V002 | oui |
| schema_autoupdate index account | oui |
| slot/lamports/rent_epoch/write_version u64 | oui, `u64::MAX` |
| data account vide | oui |
| data account 16 MiB exact | oui |
| acquisition insert/idempotence | oui |
| même référence / contenu divergent | `Conflict` |
| même pubkey+slot / hashes distincts | oui |
| collision observation + rollback state | oui |
| observation supplémentaire identique | `AlreadyPresent` |
| observation supplémentaire divergente | `Conflict` |
| référence state absente | `ReferenceNotFound` |
| metadata Yellowstone | round-trip exact |
| pagination ASC/DESC | oui |
| filtre pubkey | oui |
| cursor cross-query / digest hostile | `QueryInvalid` |
| cursor cross-family `KSPT` | `QueryInvalid` |
| concurrence identique | Inserted + AlreadyPresent |
| concurrence divergente | Inserted + Conflict |
| cancellation réelle | `JoinHandle::abort()` + state absent |
| coexistence RawTransaction | oui |
| cleanup isolation | oui |
Le test `postgres_raw_transaction_live.rs` est ajusté uniquement sur son inventaire de schéma managé : il probe et supprime désormais aussi `ksp_raw_account_states` et `ksp_raw_account_observations`, nécessaires depuis V002. Aucun scénario métier RawTransaction n'est modifié.
Les migrations V000/V001/V002 restent byte-inchangées ; le checksum V002 reste :
```text
ff21605ed45f7ab4c0f92bbb692700b4118a9488b04d50a31d259ac59bdb550e
```