v0.3.2-pre.007

This commit is contained in:
2026-08-29 21:40:57 +02:00
parent c4f56d9e85
commit e39cf656b2
19 changed files with 849 additions and 53 deletions

View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/023-V0_3_2_STORE_POSTGRES_FOUNDATION_PLAN.md -->
<!-- version: 8 -->
<!-- version: 9 -->
# Plan `0.3.2` — Store/PostgreSQL runtime foundation
@@ -563,7 +563,7 @@ ops futures ont besoin d'un diagnostic safe sans pool leak
close doit être observable sans exposer le backend
```
Surface candidate dans `ksp-store-lib` :
Surface matérialisée dans `ksp-store-lib` par `pre.007` :
```text
StoreHealthState
@@ -574,17 +574,24 @@ StoreRuntimeSnapshot
Projection sûre seulement :
```text
backend kind
state
pool size/available sous forme de compteurs bornés
schema/migration version courante
pending migration count
last safe error code éventuel
StoreRuntimeSnapshot
backend kind
network logique
pool capacity/size/available/waiting bornés
StoreHealthSnapshot
Ready | NotReady
runtime snapshot
migration version observée éventuelle
pending migration count
last safe ErrorCode éventuel
```
Interdits : URI, host, username, database name si sensible, SQL, nom physique de relation, server error string, pool/client handles.
`Store::runtime_snapshot()` est synchrone et ne réalise aucun I/O. `Store::health().await` est un probe borné : acquisition Deadpool sous deadline, `SELECT 1`, puis lecture interne de la version maximale de `ksp_store_schema_migrations`. Un échec ne renvoie jamais le texte PostgreSQL ; il produit `NotReady` et un code KSP déjà classifié. La deadline du probe réutilise le `wait_timeout` du pool, avec un fallback interne borné uniquement si le pool ne fournit pas ce paramètre.
Le backend PostgreSQL peut utiliser `SELECT 1` et une introspection minimale interne, puis mapper son résultat vers la projection portable.
Interdits : URI, host, username, database name si sensible, SQL, nom physique de relation dans la projection publique, server error string, pool/client handles.
Le probe ne vérifie pas toute l'intégrité checksum à chaque appel : `Store::open` reste propriétaire de la vérification complète bootstrap/history avant de rendre une instance. Le health relit la disponibilité et la version de schéma comme diagnostic léger.
## 12. Config `std.store`
@@ -984,7 +991,7 @@ Le gate opérateur de `pre.005-fix.001` est vert : audits, workspace check/Clipp
### `pre.006` — Migration/bootstrap foundation
Statut : matérialisé par `0.3.2-pre.006`, gate Cargo opérateur à exécuter.
Statut : matérialisé par `0.3.2-pre.006`, gate opérateur vert.
La tranche introduit un moteur privé `ksp-store-postgres-lib` sans crate de migration externe :
@@ -1011,7 +1018,21 @@ Avec les quatre codes PostgreSQL ajoutés en `pre.005` puis les trois codes migr
### `pre.007` — Composition end-to-end + health
Fermer `StoreSettings -> Store -> PostgresBackend`, health/readiness portable, close et mapping diagnostics.
Statut : matérialisé par `0.3.2-pre.007`, gate Cargo opérateur requis.
La façade ferme la projection runtime/health sans exposer de type physique :
```text
Store::runtime_snapshot() -> StoreRuntimeSnapshot
Store::health().await -> StoreHealthSnapshot
StoreHealthState = Ready | NotReady
ERROR_CODE_POSTGRES_HEALTH_FAILED = store.postgres_health_failed
```
Le backend ajoute uniquement deux DTO bridge safe (`PostgresBackendRuntimeSnapshot`, `PostgresBackendHealthSnapshot`). Les compteurs `max_size/size/available/waiting` sont saturés en `u32`. Le probe est borné, exécute seulement une disponibilité légère et la lecture de version de migration, puis mappe tout échec vers une classification backend statique sans source externe. `Store::open` ne change pas de sémantique : il ne rend une instance qu'après connexion physique et bootstrap/history vérifiés. Aucun SQL métier RAW n'est introduit.
Avec `StoreHealthState`, `StoreRuntimeSnapshot`, `StoreHealthSnapshot` et `ERROR_CODE_POSTGRES_HEALTH_FAILED`, la façade atteint désormais 84 exports crate-root : 60 réexports `ksp-store-api` et 24 éléments runtime Store.
### `pre.008` — PostgreSQL integration réelle