v0.3.4-pre.001-fix.001
This commit is contained in:
139
deltas/0.3.4/pre.001-fix.001.md
Normal file
139
deltas/0.3.4/pre.001-fix.001.md
Normal file
@@ -0,0 +1,139 @@
|
||||
<!-- file: deltas/0.3.4/pre.001-fix.001.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta `0.3.4-pre.001-fix.001` — forecast souple éditable
|
||||
|
||||
## 1. Base requise
|
||||
|
||||
Base directe attendue :
|
||||
|
||||
```text
|
||||
0.3.4-pre.001
|
||||
workspace.package.version = 0.3.4-pre.1
|
||||
```
|
||||
|
||||
Le gate opérateur de `pre.001` du 30 août 2026 est entièrement propre : audits Rust/Markdown, `cargo check --workspace`, Clippy, tests ciblés Store/Config et `cargo check -p ksp-store-lib --no-default-features` passent.
|
||||
|
||||
## 2. Motif du correctif
|
||||
|
||||
Le sizing recalibré de `docs/plans/025-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT_PLAN.md` était présenté sous forme de tableau. Cette forme décrit correctement le forecast mais ne permet pas d'insérer proprement l'historique des correctifs sous la prerelease concernée.
|
||||
|
||||
Le projet possède déjà une convention documentaire adaptée : chaque prerelease du forecast est une sous-section `### pre.NNN` et chaque correctif éventuel est une sous-sous-section `#### pre.NNN-fix.MMM` placée directement sous sa tranche.
|
||||
|
||||
## 3. Correction
|
||||
|
||||
La section `Sizing recalibré` devient un forecast souple éditable :
|
||||
|
||||
```text
|
||||
## Sizing recalibré — prereleases souples
|
||||
### pre.NNN — objet
|
||||
#### pre.NNN-fix.MMM — correctif éventuel
|
||||
```
|
||||
|
||||
Chaque tranche expose désormais :
|
||||
|
||||
- un statut modifiable ;
|
||||
- son budget cible ;
|
||||
- sa responsabilité technique principale ;
|
||||
- un emplacement naturel pour les fixes successifs.
|
||||
|
||||
Le découpage `pre.001` à `pre.013` puis `rel.001`, les budgets et les responsabilités techniques restent inchangés. Le correctif ajoute seulement la hiérarchie documentaire nécessaire à l'historique futur.
|
||||
|
||||
`pre.001-fix.001` est lui-même enregistré sous `pre.001` dans ce forecast.
|
||||
|
||||
## 4. Version Cargo inchangée
|
||||
|
||||
Ce correctif est strictement documentaire. Conformément à `VER-ID-008` :
|
||||
|
||||
```text
|
||||
workspace.package.version = 0.3.4-pre.1
|
||||
```
|
||||
|
||||
`Cargo.toml` n'est pas modifié.
|
||||
|
||||
## 5. Fichiers ajoutés
|
||||
|
||||
```text
|
||||
deltas/0.3.4/pre.001-fix.001.md
|
||||
```
|
||||
|
||||
## 6. Fichiers modifiés
|
||||
|
||||
```text
|
||||
docs/plans/025-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT_PLAN.md
|
||||
```
|
||||
|
||||
Le header documentaire du plan passe de `version: 1` à `version: 2` parce que ce fichier est réellement modifié.
|
||||
|
||||
## 7. Fichiers non modifiés
|
||||
|
||||
En particulier :
|
||||
|
||||
```text
|
||||
Cargo.toml
|
||||
src/**
|
||||
tests/**
|
||||
config/**
|
||||
migrations/**
|
||||
docs/validation/021-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT.md
|
||||
deltas/0.3.4/pre.001.md
|
||||
```
|
||||
|
||||
Le delta historique `pre.001.md` reste immuable ; le correctif est tracé uniquement dans le nouveau delta `pre.001-fix.001.md` et dans le forecast du plan.
|
||||
|
||||
## 8. Invariants techniques
|
||||
|
||||
Aucun changement n'est apporté au design V002 figé par `pre.001` :
|
||||
|
||||
```text
|
||||
2 tables seulement
|
||||
PK state = (pubkey, slot, state_hash)
|
||||
BYTEA pour les bytes/fixed-width
|
||||
NUMERIC(20,0) pour les u64 non bornés à i64
|
||||
atomicité state + observation
|
||||
idempotence par comparaison exacte
|
||||
pagination keyset (slot, pubkey, state_hash)
|
||||
cursor account V1 KSPA distinct de KSPT
|
||||
10 capabilities RAW finales = 6 transaction + 4 account
|
||||
```
|
||||
|
||||
## 9. Gate opérateur hérité
|
||||
|
||||
Le gate exécuté sur `0.3.4-pre.001` avant ce correctif documentaire est PASS :
|
||||
|
||||
```text
|
||||
General Rust rule audit: clean
|
||||
Rust export completeness audit: 0 candidate(s)
|
||||
KSP workspace Rust rule audit: clean
|
||||
Markdown table audit: clean (240 table(s), 134 file(s))
|
||||
cargo check --workspace: PASS
|
||||
cargo clippy --workspace --all-targets: PASS
|
||||
cargo test -p ksp-store-api: PASS
|
||||
cargo test -p ksp-store-lib: PASS
|
||||
cargo test -p ksp-store-postgres-lib: PASS
|
||||
cargo test -p ksp-config-lib: PASS
|
||||
cargo check -p ksp-store-lib --no-default-features: PASS
|
||||
```
|
||||
|
||||
Comme le fix ne touche ni code, ni build, ni runtime, ni config, ni migration, aucun nouveau live PostgreSQL n'est requis. L'audit Markdown doit simplement rester propre après la restructuration du plan.
|
||||
|
||||
## 10. Validation post-fix
|
||||
|
||||
Les audits statiques applicables ont été rejoués après la restructuration :
|
||||
|
||||
```text
|
||||
General Rust rule audit: clean
|
||||
Rust export completeness audit: 0 candidate(s)
|
||||
KSP workspace Rust rule audit: clean
|
||||
Markdown table audit: clean (239 table(s), 135 file(s))
|
||||
```
|
||||
|
||||
La diminution d'une table correspond exactement au remplacement du tableau de sizing par des sous-sections ; le fichier delta supplémentaire porte le nombre de fichiers Markdown audités à 135.
|
||||
|
||||
Contrôles de scope :
|
||||
|
||||
```text
|
||||
Cargo.toml : byte-identique à pre.001
|
||||
validation 021 : byte-identique à pre.001
|
||||
deltas/0.3.4/pre.001.md : byte-identique à pre.001
|
||||
```
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/plans/025-V0_3_4_STORE_POSTGRES_RAW_ACCOUNT_PLAN.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Plan `0.3.4` — Store/PostgreSQL `RawAccountState` + complétude RAW
|
||||
|
||||
@@ -547,26 +547,103 @@ La façade doit continuer de n'exposer que les modèles/capabilities backend-agn
|
||||
|
||||
La conformance finale doit aussi démontrer que l'ajout account ne modifie pas les six comportements transaction : lecture/write/observation/list/retention/force-rehydrate restent couverts par leurs suites existantes.
|
||||
|
||||
## 17. Sizing recalibré
|
||||
## 17. Sizing recalibré — prereleases souples
|
||||
|
||||
Le forecast initial du prompt concentrait migration et schema compatibility dans une seule tranche, ainsi que write+concurrence. Ces lots sont séparés pour rester dans la cible opérateur `~15-20 min/pre`.
|
||||
Chaque tranche technique vise **environ 15 à 20 minutes de travail effectif** lorsque le sujet s'y prête. Cette durée est une cible de granularité et non une durée maximale : compilation, diagnostic, live PostgreSQL ou difficulté réelle peuvent légitimement prolonger une tranche.
|
||||
|
||||
| Tranche | Objet | Budget | Note |
|
||||
|---------|-------------------------------------------------------------------|-----------|----------------------------------------|
|
||||
| pre.001 | audit, kbot3, threat model, V002 design, sizing, plan/validation | 15-20 min | cette tranche |
|
||||
| pre.002 | V002 registry + deux tables + PK/FK de base, sans repository | 15-20 min | split du forecast initial |
|
||||
| pre.003 | contraintes complètes, index, schema compatibility, checksum V002 | 15-20 min | split du forecast initial |
|
||||
| pre.004 | mapping privé state/observation + get reads + hostile rows | 15-20 min | pas de write |
|
||||
| pre.005 | acquisition atomique state+observation + idempotence/conflict | 15-20 min | write principal |
|
||||
| pre.006 | observation supplémentaire + races/cancellation unitaires | 15-20 min | concurrence isolée |
|
||||
| pre.007 | list RawAccountStateQuery + keyset cursor V1 account | 15-20 min | navigation uniquement |
|
||||
| pre.008 | 4 impl backend + 4 dispatch Store + conformance 10/10 | 15-20 min | frontières cross-crate |
|
||||
| pre.009 | preuve PostgreSQL live account + coexistence RawTransaction | 15-20 min | ignored/opt-in |
|
||||
| pre.010 | hardening/completeness cross-family + canaries ownership | 15-20 min | sécurité/completude |
|
||||
| pre.011 | gate technique final + replay live ciblé + graphes | 15-20 min | avant docs finale |
|
||||
| pre.012 | réconciliation docs finale sans rouvrir le code | 10-15 min | README/USAGE/plan/validation si requis |
|
||||
| pre.013 | publication prep minimale + prompt 0.3.5 | 10-15 min | lane publication |
|
||||
| rel.001 | stabilisation/tag après gate opérateur | 5-10 min | aucun scope nouveau |
|
||||
Le forecast reste volontairement souple. Une tranche peut être scindée, fusionnée ou réordonnée par delta si la réalité technique l'exige, à condition de préserver les responsabilités de clôture. Le nombre de prereleases prévu n'impose ni une session de conversation par tranche, ni une clôture artificielle sur le numéro initialement prévu.
|
||||
|
||||
Chaque prerelease possède un statut directement modifiable. Lorsqu'un correctif d'une tranche est nécessaire, il est ajouté sous la prerelease concernée avec un titre `#### pre.NNN-fix.MMM`, ce qui conserve l'historique de progression et permet d'ajouter des fixes sans transformer le forecast en tableau.
|
||||
|
||||
### `pre.001` — Audit, kbot3, threat model et design V002
|
||||
|
||||
**Statut : réalisé ; gate opérateur complet PASS.**
|
||||
|
||||
Budget cible : **15-20 min**. Audit de la base `v0.3.3`, étude ciblée kbot3, threat model, design physique V002, sizing et création du plan/de la validation. Aucun SQL V002, aucune table account et aucun repository account ne sont avancés dans cette tranche.
|
||||
|
||||
#### `pre.001-fix.001` — Forecast souple éditable et hiérarchie des fixes
|
||||
|
||||
**Statut : réalisé ; correctif documentaire uniquement.**
|
||||
|
||||
Remplacement du sizing tabulaire par des sous-sections éditables avec statut explicite. Les futurs correctifs peuvent être insérés sous leur prerelease avec un titre `####`, sans modifier le découpage technique, le scope fonctionnel ni les responsabilités de clôture de `0.3.4`. Conformément à `VER-ID-008`, ce correctif documentaire ne modifie pas `workspace.package.version`, qui reste `0.3.4-pre.1`.
|
||||
|
||||
### `pre.002` — Registry V002 et tables minimales
|
||||
|
||||
**Statut : planifié.**
|
||||
|
||||
Budget cible : **15-20 min**. Ajouter le registry V002 et les deux tables `RawAccountState`/observation avec PK/FK de base, sans repository account ni dispatch façade.
|
||||
|
||||
### `pre.003` — Contraintes, index et schema compatibility V002
|
||||
|
||||
**Statut : planifié.**
|
||||
|
||||
Budget cible : **15-20 min**. Compléter les contraintes physiques, l'index de navigation, la schema compatibility et le checksum V002, sans avancer les repositories.
|
||||
|
||||
### `pre.004` — Mapping privé et lectures `get`
|
||||
|
||||
**Statut : planifié.**
|
||||
|
||||
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.
|
||||
|
||||
### `pre.005` — Acquisition atomique et idempotence
|
||||
|
||||
**Statut : planifié.**
|
||||
|
||||
Budget cible : **15-20 min**. Implémenter l'acquisition atomique state+observation, l'idempotence exacte et la classification des conflits.
|
||||
|
||||
### `pre.006` — Observation supplémentaire et concurrence unitaire
|
||||
|
||||
**Statut : planifié.**
|
||||
|
||||
Budget cible : **15-20 min**. Ajouter l'observation supplémentaire et isoler les scénarios de race/cancellation unitaires sans élargir la surface de navigation.
|
||||
|
||||
### `pre.007` — Liste account et cursor keyset V1
|
||||
|
||||
**Statut : planifié.**
|
||||
|
||||
Budget cible : **15-20 min**. Implémenter `RawAccountStateQuery`, la navigation keyset et le cursor V1 account `KSPA`, sans policy de batch/priorité.
|
||||
|
||||
### `pre.008` — Implémentations backend, dispatch Store et conformance 10/10
|
||||
|
||||
**Statut : planifié.**
|
||||
|
||||
Budget cible : **15-20 min**. Ouvrir les quatre capabilities account dans `PostgresBackend` et `Store`, puis faire évoluer les canaries vers l'inventaire RAW complet de dix capabilities.
|
||||
|
||||
### `pre.009` — Preuve PostgreSQL live account
|
||||
|
||||
**Statut : planifié.**
|
||||
|
||||
Budget cible : **15-20 min**. Ajouter la preuve PostgreSQL réelle, ignored/opt-in, couvrant `RawAccountState` et sa coexistence avec la verticale `RawTransaction` existante.
|
||||
|
||||
### `pre.010` — Hardening et complétude cross-family
|
||||
|
||||
**Statut : planifié.**
|
||||
|
||||
Budget cible : **15-20 min**. Fermer les canaries de sécurité, ownership et complétude cross-family sans ajouter de nouveau scope métier.
|
||||
|
||||
### `pre.011` — Gate technique final
|
||||
|
||||
**Statut : planifié.**
|
||||
|
||||
Budget cible : **15-20 min**. Rejouer le gate technique final, le live ciblé et les graphes de dépendances nécessaires avant toute réconciliation documentaire finale.
|
||||
|
||||
### `pre.012` — Réconciliation documentaire finale
|
||||
|
||||
**Statut : planifié.**
|
||||
|
||||
Budget cible : **10-15 min**. Réconcilier les documents durables requis avec la surface effectivement validée, sans rouvrir le code fonctionnel ni préparer la publication.
|
||||
|
||||
### `pre.013` — Préparation de publication minimale
|
||||
|
||||
**Statut : planifié.**
|
||||
|
||||
Budget cible : **10-15 min**. Dernière prerelease : prompt `0.3.5`, `CHANGELOG.md` et `ROADMAP.md` uniquement hors mécanique Cargo/delta, conformément au couloir de publication.
|
||||
|
||||
### `rel.001` — Stabilisation et tag `v0.3.4`
|
||||
|
||||
**Statut : planifié.**
|
||||
|
||||
Budget cible : **5-10 min**. Stabilisation/tag après gate opérateur final, sans absorption de nouveau scope fonctionnel ou documentaire.
|
||||
|
||||
## 18. Hors scope explicite
|
||||
|
||||
|
||||
Reference in New Issue
Block a user