4.8 KiB
Delta 0.2.9-pre.001-fix.001 — sizing/session + architecture provider Yellowstone
1. Base requise
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 :
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 :
budget nominal = 15–20 minutes maximum de travail effectif
et le gate global :
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 :
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 :
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 :
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
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é
deltas/0.2.9/pre.001-fix.001.md
6. Fichiers non modifiés intentionnellement
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 :
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
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