140 lines
4.8 KiB
Markdown
140 lines
4.8 KiB
Markdown
<!-- file: deltas/0.2.9/pre.001-fix.001.md -->
|
||
<!-- version: 1 -->
|
||
|
||
# Delta `0.2.9-pre.001-fix.001` — sizing/session + architecture provider Yellowstone
|
||
|
||
## 1. Base requise
|
||
|
||
```text
|
||
0.2.9-pre.001
|
||
workspace.package.version = 0.2.9-pre.1
|
||
```
|
||
|
||
Ce correctif est **documentaire uniquement**. Conformément à `VER-ID-008`, il ne modifie pas `workspace.package.version`.
|
||
|
||
## 2. Motif du correctif
|
||
|
||
La première livraison `pre.001` contenait bien une mention générale du budget `15–20 minutes`, mais elle ne rendait pas assez visible le contrat normatif complet de `PROMPT_STRUCTURE.md` :
|
||
|
||
```text
|
||
une prerelease estimée > 15–20 min doit être scindée
|
||
une release concrète doit rester ouvrable et clôturable dans une seule session de chat
|
||
```
|
||
|
||
Elle traitait aussi PublicNode et OrbitFlare principalement comme des environnements de smoke derrière un seul backend Yellowstone provider-neutral. Cette représentation ne reprenait pas suffisamment la séparation déjà validée pour WebSocket entre moteur partagé, protocole standard et adaptation provider.
|
||
|
||
## 3. Décisions corrigées
|
||
|
||
### 3.1 Dimensionnement
|
||
|
||
Le forecast `0.2.9` affiche désormais explicitement pour **chaque prerelease** :
|
||
|
||
```text
|
||
budget nominal = 15–20 minutes maximum de travail effectif
|
||
```
|
||
|
||
et le gate global :
|
||
|
||
```text
|
||
0.2.9 complète <= une session de chat
|
||
```
|
||
|
||
Si une tranche dépasse ce budget ou si la clôture de la release dans la session devient incertaine, le scope est scindé avant implémentation lourde supplémentaire.
|
||
|
||
Le forecast est recalibré à **11 prereleases prévues** avant `rel.001`, soit environ `165–220 minutes` de travail effectif nominal hors temps d'attente des commandes.
|
||
|
||
### 3.2 Architecture Yellowstone
|
||
|
||
`0.2.9` distingue désormais trois niveaux dans `ksp-onchain-transport-lib` :
|
||
|
||
```text
|
||
N1 moteur client Yellowstone gRPC partagé
|
||
N2 façade Solana Yellowstone standard
|
||
N3 première intégration provider PublicNode / Allnodes-backed
|
||
```
|
||
|
||
Le moteur reste Yellowstone-specific ; KSP ne crée pas une abstraction gRPC universelle ni un serveur/plugin Geyser.
|
||
|
||
La règle provider est :
|
||
|
||
```text
|
||
aucun second actor/channel/stream par provider
|
||
aucune façade spécialisée vide
|
||
façade/type provider public uniquement si une différence réelle de contrat le justifie
|
||
```
|
||
|
||
PublicNode devient donc la **première intégration concrète** de `0.2.9`, avec Mainnet et Testnet comme cibles live opt-in. Il réutilise le moteur et le wire standard.
|
||
|
||
### 3.3 Releases providers suivantes
|
||
|
||
La séquence fonctionnelle est recalibrée :
|
||
|
||
```text
|
||
0.2.9 moteur Yellowstone + Solana standard + PublicNode
|
||
0.2.10 OrbitFlare Yellowstone gRPC
|
||
0.2.11 Helius LaserStream gRPC
|
||
0.2.12 eRPC Yellowstone gRPC, conditionnel après réaudit accès/capabilities
|
||
0.2.13 off-chain price transport
|
||
0.2.14 Price Desk + intégration prix Wallet Desk
|
||
0.2.15 interface/wire foundation
|
||
0.2.16 program-api foundation
|
||
```
|
||
|
||
Chaque future release provider réutilise `0.2.9`. Si le gate d'un provider montre qu'il ne diffère que par une URL interchangeable, il ne doit pas provoquer une façade artificielle ; son scope peut être réduit/fusionné avant implémentation.
|
||
|
||
### 3.4 Rust/toolchain
|
||
|
||
Les numéros de versions Rust upstream/MSRV ne sont plus suivis comme information de planification ordinaire.
|
||
|
||
KSP utilise la **Rust stable courante de l'opérateur**. Le seul gate utile est que les dépendances sélectionnées compilent avec cette stable. Un minimum Rust d'une dépendance n'est documenté que s'il devient un blocage réel.
|
||
|
||
## 4. Fichiers modifiés
|
||
|
||
```text
|
||
docs/plans/016-V0_2_9_YELLOWSTONE_GRPC_PLAN.md
|
||
docs/validation/012-V0_2_9_YELLOWSTONE_GRPC.md
|
||
docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
|
||
ROADMAP.md
|
||
```
|
||
|
||
## 5. Fichier ajouté
|
||
|
||
```text
|
||
deltas/0.2.9/pre.001-fix.001.md
|
||
```
|
||
|
||
## 6. Fichiers non modifiés intentionnellement
|
||
|
||
```text
|
||
Cargo.toml
|
||
prompts/014-V0_2_9_START_PROMPT.md
|
||
crates/**
|
||
config/**
|
||
.env.example
|
||
```
|
||
|
||
Le prompt `014` reste l'autorité historique ayant ouvert `pre.001`; le présent fix trace le recalibrage résultant du gate et devient l'état de planification courant.
|
||
|
||
## 7. Validation
|
||
|
||
À exécuter pour le correctif documentaire :
|
||
|
||
```bash
|
||
python3 scripts/audit_rust_workspace_rules.py
|
||
```
|
||
|
||
Aucun `cargo check/clippy/test` supplémentaire n'est requis par le contenu du fix puisqu'aucun artefact code/build/runtime/config n'est modifié ; la baseline technique reste celle enregistrée par `pre.001`.
|
||
|
||
## 8. État de sortie
|
||
|
||
```text
|
||
forecast visible et conforme à PROMPT_STRUCTURE.md
|
||
15–20 min max par prerelease explicités
|
||
release <= une session explicitée
|
||
moteur Yellowstone séparé de la façade standard
|
||
PublicNode promu de smoke à première intégration provider
|
||
OrbitFlare/Helius/eRPC reportés dans des releases dédiées
|
||
séquence prix/interface/program décalée en conséquence
|
||
aucun changement runtime/dependency
|
||
```
|