v0.2.7-pre.014-fix.001
This commit is contained in:
279
deltas/0.2.7/pre.014-fix.001.md
Normal file
279
deltas/0.2.7/pre.014-fix.001.md
Normal 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 15–20 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 15–20 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 > 15–20 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.
|
||||
@@ -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 15–20 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 15–20 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 > 15–20 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 15–20 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 15–20 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.
|
||||
|
||||
Reference in New Issue
Block a user