v0.2.7-pre.014-fix.001

This commit is contained in:
2026-08-23 11:28:01 +02:00
parent 5aa7b45840
commit 307711f873
2 changed files with 430 additions and 29 deletions

View File

@@ -0,0 +1,279 @@
<!-- file: deltas/0.2.7/pre.014-fix.001.md -->
<!-- version: 1 -->
# Delta `0.2.7-pre.014-fix.001` — complétude du prompt de démarrage `0.2.8`
## 1. Base requise
Base directe attendue :
```text
0.2.7-pre.014
workspace.package.version = 0.2.7-pre.14
```
Ce correctif intervient **avant `0.2.7-rel.001`** et corrige uniquement le prompt de reprise de la release suivante.
La livraison est :
```text
0.2.7-pre.014-fix.001
commit = v0.2.7-pre.014-fix.001
tag = aucun
```
## 2. Nature du fix et signal Cargo
Le fix est **strictement documentaire** :
```text
aucun fichier Rust
aucun Cargo.toml
aucune configuration runtime
aucun schema
aucune dépendance
aucun comportement HTTP/WebSocket
```
Conformément à `VERSION_WORKFLOW.md`, la version Cargo de la base directe est conservée :
```text
workspace.package.version = 0.2.7-pre.14
```
Le prompt modifié incrémente son header :
```text
prompts/013-V0_2_8_START_PROMPT.md
version: 1 -> 2
```
## 3. Diagnostic
Le prompt produit par `pre.014` contenait déjà une section :
```text
## 12. Prévision souple initiale des prereleases
```
avec un forecast nominal `pre.001 -> pre.007`.
Le défaut n'est donc pas l'absence littérale du forecast, mais sa **granularité et son niveau de prescription insuffisants** par rapport :
```text
docs/rules/PROMPT_STRUCTURE.md
aux prompts de démarrage récents
au mode de travail réellement appliqué pendant 0.2.7
```
Le `0.2.7-pre.001` avait notamment recalibré son forecast jusqu'à `pre.014` et rendu explicites :
```text
le sizing avant implémentation
le budget nominal d'environ 1520 minutes par tranche
la possibilité de scinder toute tranche trop large
l'insertion libre de fixes
le fait que le dernier numéro prévu n'est jamais une deadline
```
Le prompt `0.2.8` regroupait encore trop de responsabilités dans `pre.002` à `pre.007`, ce qui pouvait faire perdre cette discipline au démarrage de la nouvelle session.
## 4. Renforcement de la structure du prompt
Le prompt `0.2.8` version 2 renforce la reprise stable :
- interdit explicitement l'ouverture depuis une prerelease `0.2.7-pre.*` ou un ZIP intermédiaire ;
- conserve l'archive stable `v0.2.7` fournie par l'opérateur comme première autorité ;
- exige la vérification du signal Cargo stable et du delta `rel.001`.
L'ordre de lecture est complété avec :
```text
docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md
docs/validation/005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md
docs/IDEAS.md
.env.example
```
Ces ajouts servent respectivement à préserver :
```text
les frontières app/service/smoke
la règle KSP-TRANSPORT-007
les travaux explicitement différés, dont le metering
la discipline d'inventaire Config/env pour les futurs credentials Helius
```
## 5. Baseline `pre.001` rendue explicite
Le gate d'ouverture doit désormais enregistrer avant modification, lorsque l'environnement le permet :
```bash
cargo fmt --all
python3 scripts/audit_rust_workspace_rules.py
cargo check --workspace
cargo clippy --workspace --all-targets
cargo tree -p ksp-onchain-transport-lib
cargo tree -p ksp-onchain-transport-lib --duplicates
```
Une commande indisponible ou non exécutée ne peut jamais être déclarée verte.
Le résultat de cette baseline doit vivre dans le plan/delta `pre.001`, comme cela a été pratiqué pendant `0.2.7`.
## 6. Sizing et forecast corrigés
`pre.001` doit désormais produire pour chaque tranche prévue :
```text
objectif précis
principaux contrats/fichiers attendus
preuves/tests/gates attendus
budget nominal <= environ 1520 minutes
critères de split
```
Le forecast initial passe de sept prereleases très agrégées à onze tranches nominales :
```text
pre.001 audit + matrice + architecture + threat model + dependencies + sizing
pre.002 provider/protocol settings + capability model + secrets/redaction
pre.003 Config V2 provider + mapping Config -> Transport
pre.004 transactionSubscribe/unsubscribe params/filters/options
pre.005 transaction notifications + reconnect/resubscribe/races
pre.006 account/program extensions Helius retenues
pre.007 heartbeat/idle + lifecycle/shutdown
pre.008 capability failures + limits/backpressure/adversarial
pre.009 compliance provider + non-régressions 18/18 et 52/14
pre.010 smoke live sûr + dependency audit + README/USAGE
pre.011 workspace final + docs/matrice/indexes + prompt 0.2.9
rel.001 publication stable
```
Chaque ligne du prompt contient maintenant également la preuve/gate principal attendu.
Ce forecast reste **souple** :
```text
pre.001 doit le recalibrer
une tranche > 1520 min doit normalement être scindée
des tranches peuvent être fusionnées si l'audit réduit réellement la surface
des fixes peuvent être insérés librement
pre.011 n'est pas une deadline
aucun numéro de prerelease ne vaut critère de clôture
```
## 7. Versionnement et archives d'échange
Le prompt précise maintenant les noms usuels :
```text
ksp-general-0.2.8-pre.001.zip
ksp-general-0.2.8-pre.NNN-fix.MMM.zip
ksp-general-0.2.8-rel.001.zip
```
L'overlay reste minimal et conserve les chemins depuis la racine du workspace.
## 8. Critères de clôture renforcés
La clôture `0.2.8` reste pilotée par les gates fonctionnels et de compliance, jamais par le forecast.
Le prompt précise désormais :
```text
si les gates ne sont pas verts à pre.011 -> continuer avec pre.012+ ou fixes
forecast réalisé ou explicitement recalibré sans dette silencieuse
rel.001 seulement après fermeture réelle de la matrice et du workspace
```
## 9. Fichiers
Modifié :
```text
prompts/013-V0_2_8_START_PROMPT.md
```
Ajouté :
```text
deltas/0.2.7/pre.014-fix.001.md
```
Volontairement inchangés :
```text
Cargo.toml
ROADMAP.md
CHANGELOG.md
docs/plans/014-V0_2_7_ONCHAIN_WEBSOCKET_PLAN.md
docs/validation/010-V0_2_7_ONCHAIN_WEBSOCKET.md
prompts/000-README.md
crates/**
config/**
```
Le delta `pre.014.md` publié n'est jamais réécrit.
## 10. Runtime / API
Aucun contrat runtime ne change.
Les acquis restent exactement ceux de `pre.014` :
```text
HTTP 52 current + 14 historical
WebSocket Solana standard 18/18
WsSession/WsSubscription lifecycle inchangé
Config V2 inchangé
dependency graph inchangé
comptages de tests inchangés
```
## 11. Validation opérateur
Le fix n'introduit aucun Rust ni aucune configuration exécutable.
Contrôle documentaire minimal :
```bash
python3 scripts/audit_rust_workspace_rules.py
```
Comme cette livraison devient la base directe de `rel.001`, il est recommandé de rejouer le gate final complet avant clôture :
```bash
cargo fmt --all
python3 scripts/audit_rust_workspace_rules.py
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test -p ksp-onchain-transport-lib
cargo test --workspace
```
Comptages attendus inchangés par rapport à `pre.014` :
```text
Transport unit tests = 309
Transport public API tests = 36
Transport release completeness = 24
Transport WebSocket live smoke = 1 ignored par défaut
Config unit tests = 109
Core workspace dependency tests = 3
```
Aucun smoke live ni `cargo tree` supplémentaire n'est requis par ce fix documentaire si la base appliquée est exactement `pre.014` et que le graphe n'a pas changé.
## 12. Suite
Si `0.2.7-pre.014-fix.001` est appliqué et le gate final reste vert, la suite est :
```text
0.2.7-rel.001
Cargo = 0.2.7
commit = v0.2.7-rel.001
tag stable = v0.2.7
```
`rel.001` devra publier la synthèse stable, fermer le statut du plan/matrice et conserver `prompts/013-V0_2_8_START_PROMPT.md` version 2 comme prompt autoritaire de la session suivante.

View File

@@ -1,5 +1,5 @@
<!-- file: prompts/013-V0_2_8_START_PROMPT.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Prompt de démarrage `0.2.8` — Helius LaserStream WebSocket
@@ -28,6 +28,16 @@ prompts/013-V0_2_8_START_PROMPT.md
Si une archive complète du workspace `v0.2.7` est fournie au démarrage de session, **cette archive est autoritaire** par rapport aux souvenirs, snippets, copies de prereleases ou artefacts antérieurs. Vérifier l'état réel avant toute modification.
Ne pas ouvrir `0.2.8` depuis :
```text
0.2.7-pre.*
0.2.7-pre.*-fix.*
un ZIP intermédiaire
une reconstruction depuis mémoire de conversation
une ancienne copie du prompt 0.2.8
```
Signal Cargo initial attendu :
```text
@@ -100,6 +110,7 @@ docs/architecture/003-COMPONENT_CONTRACTS.md
docs/architecture/004-COMPONENT_INVENTORY.md
docs/architecture/005-DEPENDENCY_GRAPH.md
docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md
docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md
```
Points d'attention :
@@ -110,6 +121,7 @@ Config adapte vers Transport, jamais l'inverse
Store/RAW persistence n'appartient pas à Transport
Program decode/materialization n'appartient pas à Transport
un provider WebSocket ne doit pas créer un second moteur session/subscription
les smokes cross-crates ne doivent pas être déplacés opportunistement dans Config
```
### 3.3 Séquence fonctionnelle et héritage Transport
@@ -122,12 +134,15 @@ docs/plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md
docs/plans/014-V0_2_7_ONCHAIN_WEBSOCKET_PLAN.md
docs/validation/003-V0_2_1_ONCHAIN_HTTP.md
docs/validation/005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md
docs/validation/007-V0_2_4_HTTP_FINAL_COMPLIANCE.md
docs/validation/010-V0_2_7_ONCHAIN_WEBSOCKET.md
```
`docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md` porte la numérotation courante. Les anciens plans restent historiques et ne doivent pas réintroduire une numérotation dépassée.
`KSP-TRANSPORT-007` reste applicable : une extension provider ciblée ne compte comme complète que si toutes les possibilités supportées retenues par l'audit sont représentées sans perte injustifiée.
### 3.4 Contrats publics réels à réauditer
Inspecter directement :
@@ -144,6 +159,7 @@ crates/ksp-config-lib/src/transport.rs
crates/ksp-config-lib/unit_tests/transport.rs
config/std.transport.json
config/schemas/std.transport.schema.json
.env.example
```
En particulier, vérifier les contrats réels de :
@@ -169,10 +185,13 @@ Lire obligatoirement :
deltas/0.2.7/rel.001.md
docs/plans/014-V0_2_7_ONCHAIN_WEBSOCKET_PLAN.md
docs/validation/010-V0_2_7_ONCHAIN_WEBSOCKET.md
docs/IDEAS.md
```
Le but est de reprendre exactement le moteur final, les limitations documentées et les preuves de clôture, pas de rouvrir les décisions standard déjà validées.
`docs/IDEAS.md` est lu uniquement pour éviter de réintroduire dans `0.2.8` des travaux explicitement différés, notamment le metering/provider billing.
---
## 4. Sources externes normatives à réauditer en `pre.001`
@@ -589,16 +608,35 @@ La première tranche est **audit + brainstorming + sizing**, pas une tranche d'i
Elle doit exécuter dans l'ordre :
### 11.1 Reprise de la base
### 11.1 Reprise de la base et baseline avant modification
```text
vérifier base/tag v0.2.7 ou archive stable autoritaire
vérifier Cargo = 0.2.7
lire les règles obligatoires
lire plan + validation + rel.001 de 0.2.7
inventorier le code WsSession/WsSubscription/Config réellement publié
vérifier l'état Cargo et le graphe actuel
```
Avant toute modification, exécuter lorsque l'environnement le permet :
```bash
cargo fmt --all
python3 scripts/audit_rust_workspace_rules.py
cargo check --workspace
cargo clippy --workspace --all-targets
```
Puis inspecter au minimum :
```bash
cargo tree -p ksp-onchain-transport-lib
cargo tree -p ksp-onchain-transport-lib --duplicates
```
Ne jamais déclarer une commande réussie si elle n'a pas réellement été exécutée. Si l'environnement de préparation ne fournit pas Cargo/rustfmt, enregistrer explicitement cette impossibilité dans le plan/delta et laisser le gate compilé à l'opérateur.
### 11.2 Audit Helius officiel actuel
Construire une matrice contenant au minimum :
@@ -690,21 +728,41 @@ data gaps après reconnect
mismatch standard method support
```
### 11.6 Sizing
### 11.6 Sizing et prévision souple obligatoire
Produire :
Produire avant implémentation lourde :
```text
liste exacte des capacités à implémenter
questions reportées
nombre estimé de prereleases
budget de chaque tranche <= environ 1520 minutes de travail effectif
ordre des tranches
validations associées
risques de split
objectif précis de chaque tranche
principaux contrats/fichiers touchés attendus
preuves/tests/gates attendus pour chaque tranche
budget nominal de chaque tranche <= environ 1520 minutes de travail effectif
risques et critères de split
```
Si la surface Helius actuelle est plus large que prévu et menace la règle « une release concrète clôturable dans une session », **scinder avant implémentation lourde**.
La prévision initiale de la section 12 est **un forecast de départ**, pas un engagement. `pre.001` doit la recalibrer à partir de l'audit réel et recopier le forecast recalibré dans :
```text
docs/plans/015-V0_2_8_HELIUS_LASERSTREAM_WEBSOCKET_PLAN.md
deltas/0.2.8/pre.001.md
```
Règles de granularité :
```text
une tranche ne doit pas masquer plusieurs sous-problèmes indépendants
une tranche estimée > 1520 min doit normalement être scindée
une nouvelle ambiguïté normative peut créer une tranche supplémentaire
un fix peut être inséré après n'importe quelle prerelease
le dernier numéro de prerelease prévu n'est jamais une deadline
la release ne doit jamais être fermée artificiellement pour respecter le forecast initial
```
Si la surface Helius actuelle est plus large que prévu et menace la règle « une release concrète clôturable dans une session », **scinder fonctionnellement la release avant implémentation lourde**.
### 11.7 Documents de sortie du gate
@@ -724,6 +782,7 @@ Le gate est positif seulement si :
```text
base stable confirmée
baseline avant modification enregistrée
sources Helius actuelles réauditées
surface exacte inventoriée
terminologie provider clarifiée
@@ -733,31 +792,70 @@ Config shape décidée
strategy de credentials sûre
strategy de tests/smoke décidée
aucune nouvelle dépendance non justifiée
release dimensionnée et forecast recalibré
release dimensionnée
forecast initial recalibré avec budget/gates par tranche
risques de split explicitement documentés
```
---
## 12. Prévision souple initiale des prereleases
Prévision de départ, à recalibrer après `pre.001` :
Prévision de départ, **obligatoirement recalibrée après `pre.001`** :
```text
pre.001 audit Helius actuel + matrice + architecture + threat model + sizing
pre.002 protocol/provider settings + Config V2 extension + capability model
pre.003 transactionSubscribe/unsubscribe + DTOs/filters/options + fixtures
pre.004 extensions account/program et autres filtres Helius retenus + fixtures
pre.005 heartbeat/idle/reconnect/capability failures + adversarial lifecycle tests
pre.006 compliance provider + non-régressions standard/HTTP + smoke strategy + dependency audit + docs
pre.007 validation workspace finale + documentation/indexes + prompt 0.2.9
pre.001 audit Helius actuel + matrice + architecture + threat model + dependencies + sizing
preuve : plan initial + matrice compliance + forecast recalibré ; aucun runtime provider lourd
pre.002 descriptor/protocol/provider settings + capability model + secrets/redaction contracts
preuve : settings/API canaries + tests de validation/redaction ; pas encore de Config provider persistée
pre.003 extension Config V2 provider-specific + mapping Config -> Transport + fixtures/schema
preuve : backward V1/V2 + fixtures provider + rejection unknown/invalid + aucune dépendance inverse
pre.004 transactionSubscribe/unsubscribe : paramètres, filtres, options et serialization exacts
preuve : fixtures request/ack/error + limites déterministes avant I/O + API typed
pre.005 transaction notifications typed + unsubscribe/reconnect/resubscribe/races
preuve : notification wire + late notification + remapping remote/local + backpressure ciblée
pre.006 extensions account/program Helius retenues : notifyOn/tokenAccounts/autres capacités auditées
preuve : wire exact + cardinalités + isolation stricte des DTOs Solana standard
pre.007 heartbeat/idle provider + timers + interaction reconnect/control frames/shutdown
preuve : tests temporels locaux déterministes + cancellation bornée + aucun secret/log payload
pre.008 capability failures + provider errors + limites/backpressure/adversarial lifecycle
preuve : mismatch standard/provider + payload oversized + queue overflow + session isolation
pre.009 compliance Helius finale + non-régressions Solana standard 18/18 + HTTP 52/14 + Config/API canaries
preuve : matrice rapprochée + release-completeness + tests Transport/Config ciblés
pre.010 smoke Helius live opt-in si stratégie sûre + audit dependency graph/duplicates + README/USAGE
preuve : smoke sans secret versionné + cargo tree analysé + documentation durable version-neutral
pre.011 validation workspace finale + fermeture plan/matrice/indexes + prompt 0.2.9
preuve : workspace final vert + docs cohérentes + prompt suivant autonome
rel.001 publication stable stricte
```
Cette prévision est **souple**. Des tranches ou fixes peuvent être insérés si l'audit réel le justifie. La fermeture ne doit jamais être forcée pour respecter `pre.007`.
Cette prévision est **souple** :
```text
chaque tranche vise environ 1520 minutes de travail effectif
pre.001 peut fusionner, scinder, déplacer ou ajouter des tranches selon l'audit réel
des fixes peuvent être insérés à tout moment
pre.011 n'est pas une deadline
aucun numéro de prerelease ne vaut critère de clôture
seuls les gates de la section 15 autorisent rel.001
```
Le plan `0.2.8` doit conserver le forecast recalibré courant. Les deltas décrivent la progression détaillée ; `ROADMAP.md` ne sert pas de changelog de prereleases.
---
## 13. Versionnement, deltas, commits et tags
## 13. Versionnement, deltas, commits, archives et tags
Convention de livraison :
@@ -789,6 +887,16 @@ v0.2.8-pre.001-fix.001
v0.2.8-rel.001
```
Archives d'échange usuelles :
```text
ksp-general-0.2.8-pre.001.zip
ksp-general-0.2.8-pre.NNN-fix.MMM.zip
ksp-general-0.2.8-rel.001.zip
```
Une archive delta doit contenir uniquement les fichiers ajoutés/modifiés de la livraison et conserver leurs chemins depuis la racine du workspace.
Aucun tag Git pour les prereleases.
Après validation de `rel.001` :
@@ -816,6 +924,14 @@ Tout fichier modifié incrémente son header `version:` selon les règles KSP.
L'assistant prépare normalement un overlay minimal ne contenant que les fichiers ajoutés/modifiés de la livraison.
Chaque delta doit distinguer :
```text
validations réellement exécutées
validations impossibles dans l'environnement de préparation
validations opérateur requises
```
Après application d'une prerelease Rust :
```bash
@@ -912,9 +1028,12 @@ fixtures déterministes vertes
workspace complet vert
README/USAGE synchronisés et version-neutral
matrice finale de validation fermée
forecast réalisé ou explicitement recalibré sans dette silencieuse
prompt 0.2.9 préparé
```
Le numéro de la dernière prerelease n'est jamais un critère de clôture. Si les gates ne sont pas verts à `pre.011`, continuer avec `pre.012+` ou des fixes.
`CHANGELOG.md` et le statut stable du ROADMAP ne sont finalisés qu'à la publication `rel.001`.
---
@@ -938,14 +1057,17 @@ Le prompt `0.2.9` devra imposer un nouvel audit normatif de la surface Yellowsto
Au début de la nouvelle session `0.2.8` :
1. vérifier que la base est réellement `v0.2.7` ou l'archive stable autoritaire fournie ;
2. lire les sources internes obligatoires dans l'ordre indiqué ;
3. relire `deltas/0.2.7/rel.001.md`, le plan et la matrice finale WebSocket standard ;
4. inspecter le code public/réel de `WsSession`, `WsSubscription`, `WsProtocolKind` et Config V2 ;
5. réauditer immédiatement la documentation officielle Helius LaserStream WebSocket du jour ;
6. produire la matrice standard/supporté/extension/non-supporté ;
7. brainstormer provider credentials, heartbeat, capabilities, reconnect et tests ;
8. dimensionner/recalibrer la release et écrire `pre.001` ;
9. exécuter les validations de gate disponibles ;
10. **ne pas commencer `transactionSubscribe`, modifier Config ou ajouter une dépendance avant que ce gate soit cohérent**.
2. vérifier `workspace.package.version = 0.2.7` et la présence de `deltas/0.2.7/rel.001.md` ;
3. lire les sources internes obligatoires dans l'ordre indiqué ;
4. relire le plan, la matrice finale WebSocket standard, `KSP-TRANSPORT-007` et les différés pertinents ;
5. inspecter le code public/réel de `WsSession`, `WsSubscription`, `WsProtocolKind` et Config V2 ;
6. exécuter/enregistrer la baseline disponible avant modification ;
7. réauditer immédiatement la documentation officielle Helius LaserStream WebSocket du jour ;
8. produire la matrice standard/supporté/extension/non-supporté ;
9. brainstormer provider credentials, heartbeat, capabilities, reconnect et tests ;
10. dimensionner la release par tranches d'environ 1520 minutes et **recalibrer explicitement la prévision souple de la section 12** ;
11. écrire le plan, la matrice et `deltas/0.2.8/pre.001.md` avec ce forecast recalibré ;
12. exécuter les validations de gate disponibles ;
13. **ne pas commencer `transactionSubscribe`, modifier Config ou ajouter une dépendance avant que ce gate soit cohérent**.
La première réponse de travail doit donc être un **audit/sizing `0.2.8-pre.001`**, pas une implémentation prématurée.
La première réponse de travail doit donc être un **audit/sizing `0.2.8-pre.001` avec forecast recalibré**, pas une implémentation prématurée.