4.0 KiB
Delta 0.2.9-pre.001-fix.002 — provider divergence + waitlist Yellowstone
1. Base requise
0.2.9-pre.001-fix.001
workspace.package.version = 0.2.9-pre.1
Ce correctif est documentaire uniquement. Conformément au workflow de version, il ne modifie pas workspace.package.version.
2. Motif du correctif
Le cadrage pre.001-fix.001 avait correctement séparé :
N1 moteur Yellowstone partagé
N2 façade Solana Yellowstone standard
N3 intégration provider
mais la formulation « sans duplication du moteur ni du wire standard » pouvait être comprise comme une hypothèse d'équivalence wire/capabilities entre Yellowstone upstream et tous les providers.
Cette hypothèse n'est pas acceptable : un provider peut implémenter seulement un sous-ensemble du standard, imposer des limites/auth/lifecycle différents ou proposer des extensions propres.
Le correctif ferme aussi la liste des providers à implémenter à court terme :
0.2.9 PublicNode
0.2.10 OrbitFlare
0.2.11 Helius LaserStream gRPC
Les autres providers ne reçoivent plus de numéro de release réservé.
3. Décisions corrigées
3.1 Règle N1 / N2 / N3
N1 = moteur client Yellowstone unique
N2 = contrat Solana Yellowstone standard KSP
N3 = adaptation provider
Invariant N1 :
aucun second actor/channel/stream moteur par provider
Règle N2/N3 :
réutiliser N2 lorsqu'une capacité provider est réellement compatible
restreindre explicitement N2 lorsqu'une capacité standard est absente/non supportée
ajouter une extension typed N3 lorsqu'un provider étend le protocole/wire
porter en N3 les différences auth/metadata/compression/keepalive/replay/from_slot/limites/lifecycle
ne jamais présumer une équivalence provider/standard sans preuve
Une divergence réelle n'est donc ni dupliquée arbitrairement ni masquée derrière le standard.
3.2 Providers actuellement planifiés
0.2.9 moteur Yellowstone + standard Solana + PublicNode
0.2.10 OrbitFlare Yellowstone gRPC
0.2.11 Helius LaserStream gRPC
Chaque release provider commence par un delta audit avec Yellowstone upstream courant et ne matérialise que ses différences réelles.
3.3 Providers en attente
Les providers suivants sont retirés de la séquence numérotée :
TODO eRPC
TODO Triton
TODO Alchemy
TODO QuickNode
TODO Chainstack
IDEAS Tatum
IDEAS Shyft
IDEAS Solinfra
IDEAS NodeFlare
IDEAS autres providers
Aucun Config profile, type public, dépendance, smoke ou forecast n'est préparé pour eux tant qu'une décision explicite d'implémentation n'est pas prise.
3.4 Séquence fonctionnelle libérée
La suppression de la réservation 0.2.12 eRPC ramène la suite active à :
0.2.12 off-chain price transport
0.2.13 Price Desk + intégration prix Wallet Desk
0.2.14 interface/wire foundation
0.2.15 program-api foundation
4. Fichiers modifiés
ROADMAP.md
docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
docs/plans/016-V0_2_9_YELLOWSTONE_GRPC_PLAN.md
docs/validation/012-V0_2_9_YELLOWSTONE_GRPC.md
5. Fichier ajouté
deltas/0.2.9/pre.001-fix.002.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 d'ouverture ; le plan et les deltas successifs enregistrent les décisions prises pendant le gate.
7. Validation
Correctif documentaire :
python3 scripts/audit_rust_workspace_rules.py
Aucun cargo check/clippy/test supplémentaire n'est requis par ce correctif tant qu'aucun artefact code/build/runtime/config n'est modifié.
8. État de sortie
N1 moteur unique explicite
N2 standard non présumé universel
N3 peut réutiliser/restreindre/étendre
PublicNode/OrbitFlare/Helius seuls providers planifiés
reste des providers en TODO/IDEAS non numérotés
off-chain price revient en 0.2.12
aucun changement runtime/dependency