v0.3.4-pre.003

This commit is contained in:
2026-08-30 21:37:02 +02:00
parent dfa3723a7f
commit a704a5722e
37 changed files with 1088 additions and 75 deletions

View File

@@ -1,11 +1,11 @@
<!-- file: docs/plans/025-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT_PLAN.md -->
<!-- version: 4 -->
<!-- version: 5 -->
# 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` matérialise uniquement la fondation physique V002 : registry logique, deux tables, deux clés primaires et la FK observation -> state. Aucun repository account, aucun dispatch façade, aucun index métier et aucune contrainte de domaine complète ne sont ouverts dans cette tranche.
`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.
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.1
label = 0.3.4-pre.001
workspace.package.version = 0.3.4-pre.3
label = 0.3.4-pre.003
```
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.
@@ -569,7 +569,7 @@ Remplacement du sizing tabulaire par des sous-sections éditables avec statut ex
### `pre.002` — Registry V002 et tables minimales
**Statut : réalisé ; corrigé par `pre.002-fix.001`, gate opérateur du correctif à rejouer.**
**Statut : réalisé ; corrigé par `pre.002-fix.001`, gate opérateur complet PASS.**
Budget cible : **15-20 min**. V002 `raw_account_state` est enregistrée avec exactement cinq resources : deux tables, les PK `(pubkey, slot, state_hash)` / `(observation_key)` et la FK composite observation -> state. Aucun repository account ni dispatch façade n'est ajouté.
@@ -577,7 +577,7 @@ Le checksum resources calculable sur cet état intermédiaire est `30ac87496f1bb
#### `pre.002-fix.001` — correction des canaris V002
**Statut : livré ; gate opérateur à rejouer.**
**Statut : réalisé ; gate opérateur complet PASS.**
Le gate opérateur de `pre.002` compile le workspace et passe Clippy, Store API, Store façade, Config et `--no-default-features`, mais révèle deux canaris backend obsolètes. Le premier construisait encore un historique « futur » en version 2 alors que V002 occupe désormais cette version ; il est recalibré avec V002 valide suivie d'une version 3 inconnue. Le second comparait la FK V002 à une chaîne SQL sensible aux retours à la ligne ; il normalise désormais uniquement les espaces avant de vérifier le contrat physique.
@@ -585,9 +585,15 @@ Aucune ressource SQL, migration, table, contrainte, index, surface runtime ou ca
### `pre.003` — Contraintes, index et schema compatibility V002
**Statut : planifié.**
**Statut : réalisé ; gate opérateur à rejouer.**
Budget cible : **15-20 min**. Compléter les contraintes physiques, l'index de navigation, la schema compatibility et figer le checksum V002 final, sans avancer les repositories. Cette tranche doit traiter explicitement la transition depuis l'état V002 intermédiaire de `pre.002` avant toute utilisation live persistante.
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`.
Le checksum V002 final est `ff21605ed45f7ab4c0f92bbb692700b4118a9488b04d50a31d259ac59bdb550e`. La transition depuis le checksum provisoire `30ac87496f1bb3805d816660891d7eab2127c599a636eb40c17ade5926311f55` est acceptée **uniquement** sous `schema_update=update_if_needed` : le moteur répare/valide d'abord les resources V002 manquantes, vérifie la compatibilité externe puis remplace atomiquement le checksum d'historique dans la même transaction. `schema_update=disabled` conserve un mismatch sûr et tout checksum inconnu reste rejeté.
Le probe d'adoption reconnaît désormais aussi les deux tables V002. Aucun `src/raw_account.rs`, aucune implémentation `RawAccount*` et aucun dispatch Store ne sont ouverts dans cette tranche.
Gate de base `pre.002-fix.001` fourni le 2026-08-30 : audits Rust/Markdown, `cargo check --workspace`, Clippy all-targets, suites `ksp-store-api`, `ksp-store-lib`, `ksp-store-postgres-lib`, `ksp-config-lib` et `ksp-store-lib --no-default-features` sont tous PASS.
### `pre.004` — Mapping privé et lectures `get`

View File

@@ -1,11 +1,11 @@
<!-- file: docs/validation/021-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT.md -->
<!-- version: 3 -->
<!-- version: 4 -->
# 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 uniquement la fondation V002 : registry, deux tables et PK/FK de base. Son gate opérateur révèle deux canaris unitaires obsolètes sans défaut de migration ; `0.3.4-pre.002-fix.001` les corrige sans modifier les resources SQL. Les contraintes de domaine, l'index, la compatibilité externe complète, les repositories et les quatre capabilities account restent volontairement pending.
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. Les repositories et les quatre capabilities account restent volontairement pending.
Base :
@@ -272,8 +272,8 @@ Le test live account devra être opt-in/ignored, URI stdin, sans environnement n
| Tranche | Objet | État |
|---------|-------------------------------------------------------------------|---------|
| pre.001 | audit, kbot3, threat model, V002 design, sizing, plan/validation | DONE |
| pre.002 | V002 registry + deux tables + PK/FK de base, sans repository | FIX.001 |
| pre.003 | contraintes complètes, index, schema compatibility, checksum V002 | PLANNED |
| pre.002 | V002 registry + deux tables + PK/FK de base, sans repository | PASS |
| pre.003 | contraintes complètes, index, schema compatibility, checksum V002 | GATE |
| pre.004 | mapping privé state/observation + get reads + hostile rows | PLANNED |
| pre.005 | acquisition atomique state+observation + idempotence/conflict | PLANNED |
| pre.006 | observation supplémentaire + races/cancellation unitaires | PLANNED |
@@ -350,4 +350,35 @@ Invariants du correctif :
- aucun module repository account, dispatch Store ou implémentation `RawAccount*` ouvert ;
- `workspace.package.version = 0.3.4-pre.2.fix.1` conformément à `VER-ID-007/010`, car des sources Rust de tests sont modifiées.
Gate opérateur du correctif : **À REJOUER**.
Gate opérateur du correctif du 2026-08-30 : **PASS complet** — audits Rust/Markdown, workspace check, Clippy all-targets, Store API, Store façade, backend PostgreSQL, Config et `--no-default-features` sont verts.
## 19. Verdict `pre.003`
V002 finale : **PASS statique / gate Cargo opérateur à rejouer**.
Inventaire final :
```text
V002 resources = 32
tables = 2
constraints = 29 (2 PK + 1 FK + 26 CHECK)
indexes = 1
final checksum = ff21605ed45f7ab4c0f92bbb692700b4118a9488b04d50a31d259ac59bdb550e
provisional pre.002= 30ac87496f1bb3805d816660891d7eab2127c599a636eb40c17ade5926311f55
```
Contraintes matérialisées : exactitude fixed-width des identités/hash/signature, domaines `u64` en `NUMERIC(20,0)`, data account `<= 16 MiB`, provenance logique 1..128 octets/alphabet sûr, origin fermé aux cinq variantes API, timestamps `0..MAX_RAW_UNIX_MILLIS`, `observed_at <= received_at`, hash source 32 bytes et source size `<= 64 MiB`. `is_startup` reste un booléen nullable sans contrainte artificielle.
L'unique index métier V002 est non unique et non filtré :
```text
(slot, pubkey, state_hash)
```
Aucun index owner/provider/method/time/status n'est ajouté.
Compatibilité de prerelease : le checksum provisoire V002 de `pre.002` n'est accepté que lorsque `schema_update=update_if_needed`. Dans ce cas, les resources manquantes sont matérialisées et vérifiées, la compatibilité externe V002 est contrôlée, puis l'entrée d'historique est mise à jour atomiquement vers le checksum final. Avec `schema_update=disabled`, le checksum provisoire est rejeté ; tout checksum non explicitement connu reste `MigrationMismatch`.
Le probe d'adoption couvre V001 + V002. V000/V001 et leurs checksums restent inchangés. Aucune surface repository/runtime account n'est ouverte : `src/raw_account.rs` absent, aucune implémentation `RawAccount*` et aucun dispatch Store.
Audits exécutables dans l'environnement d'assemblage : Rust rules **PASS** ; audit Markdown à rejouer après cette mise à jour documentaire. Les commandes Cargo ne sont pas disponibles dans cet environnement et restent donc explicitement à rejouer par l'opérateur.