34 KiB
Prompt de démarrage 0.2.10 — OrbitFlare Yellowstone gRPC
1. Identité de la release et base exacte requise
La base attendue est exclusivement la release stable :
v0.2.9
Ne pas ouvrir 0.2.10 depuis une prerelease 0.2.9-pre.*, depuis une archive intermédiaire ou depuis un souvenir de session.
Si une archive opérateur de v0.2.9 est fournie au démarrage, cette archive réelle devient la première autorité devant les snippets, anciens prompts, anciens ZIP et mémoire de conversation. Toute divergence avec le présent prompt déclenche un audit explicite ; elle ne se résout jamais par supposition.
La release à ouvrir est :
0.2.10 — OrbitFlare Yellowstone gRPC
La première tranche est :
0.2.10-pre.001
pre.001 est obligatoirement une tranche lecture + audit externe actuel + comparaison avec le moteur KSP 0.2.9 + brainstorming + threat model + sizing + planification. Elle ne doit pas commencer par une façade OrbitFlare lourde, un nouveau client gRPC, une copie de SDK provider ou un heartbeat provider codé avant que les divergences réelles soient établies.
À l'ouverture, vérifier au minimum :
git describe / tag stable si metadata Git disponible
workspace.package.version = 0.2.9
deltas/0.2.9/rel.001.md présent
prompts/015-V0_2_10_START_PROMPT.md présent
État fonctionnel attendu depuis v0.2.9 :
HTTP Solana 52/52 current typed
HTTP historiques 14/14 Deprecated/Removed
KSP-TRANSPORT-007 appliqué
WebSocket Solana standard 9 familles / 18 opérations
Helius LaserStream WebSocket façade provider + transaction + slotsUpdates
Yellowstone moteur N1 Tonic/Protobuf privé KSP
Yellowstone standard N2 provider-neutral
Yellowstone unary 7 méthodes standard retenues
Yellowstone Subscribe accounts/slots/transactions/status/blocks/meta/entry
Yellowstone updates 9 variantes standard retenues
Yellowstone lifecycle bidi/backpressure/half-close/shutdown bornés
Yellowstone reconnect/replay KSP-owned, prudent, non lossless
PublicNode N3 Mainnet + Testnet validés sur le standard N2
PublicNode auth metadata secrète x-token via Config
PublicNode live Subscribe -> Slot 2/2 PASS
Config Transport V1 HTTP + V2 WS + V3 gRPC backward-readable
Config -> Transport autorisé
Transport -> Config/env interdit
provider et protocol axes distincts dans Config V3
2. Mission et résultat attendu
0.2.10 doit ajouter OrbitFlare comme provider Yellowstone gRPC en réutilisant le moteur et le contrat Solana standard livrés dans 0.2.9.
La release n'a pas pour mission de réécrire Yellowstone, de remplacer yellowstone-grpc-proto, de créer un second actor gRPC ou d'importer le SDK OrbitFlare comme propriétaire du contrat KSP.
Résultat attendu à la clôture :
capabilities OrbitFlare réellement auditées
endpoint/network/region semantics documentées
mode d'auth gRPC réellement confirmé
policy ping/keepalive OrbitFlare réellement confirmée
façade provider uniquement si une divergence justifie son existence
sinon profil/capability provider réutilisant directement le standard N2
Config V3 OrbitFlare sans secret hardcodé
lifecycle provider compatible avec le moteur N1
smoke live opt-in architecture-safe si credentials/whitelist disponibles
non-régressions Yellowstone standard + PublicNode + HTTP + WS + Helius WS
README/USAGE et matrice de compliance synchronisés
Le principe directeur est :
pas de duplication quand OrbitFlare est standard
extension KSP provider seulement pour une divergence démontrée
Si l'audit montre qu'OrbitFlare ne nécessite qu'un endpoint descriptif et une configuration externe d'IP whitelist, la release doit rester petite. Si au contraire un heartbeat périodique, une auth metadata, des restrictions de méthodes ou des capacités propres sont nécessaires, ces divergences doivent être modélisées explicitement et testées.
3. Sources de vérité internes obligatoires — ordre de lecture
3.1 Entrées et règles globales
Lire d'abord :
RULES.md
docs/000-README.md
docs/rules/RULES_GENERAL.md
docs/rules/RULES_KSP.md
docs/rules/RULES_RUST.md
docs/rules/RULES_DEPENDENCIES.md
docs/rules/RULES_DOCUMENTATION.md
docs/rules/FILE_CONTRACTS.md
docs/rules/VERSION_WORKFLOW.md
docs/rules/PROMPT_STRUCTURE.md
Rappels directement applicables :
Rust 2024
unsafe / unwrap / expect / panic interdits en production
? interdit en production
retours explicites
clippy::implicit_return deny
missing_docs warn
unreachable_pub deny
unsafe_code forbid
pas de pub mod
reexports crate-root explicites
tests unitaires sous unit_tests/
integration tests sous tests/
visibilité jamais élargie uniquement pour tester
ksp-logging-lib propriétaire du tracing
ksp-config-lib propriétaire config/env/secrets
Transport ne lit jamais std::env pour KSP_*
Règle documentaire acquise en 0.2.9-pre.012 :
aucun pipe littéral ou échappé dans une cellule de tableau Markdown
colonnes alignées sur le contenu le plus large
une seule marge d'espace autour du contenu maximal
lignes séparatrices dimensionnées exactement
réalignement complet de tout tableau touché
Pour les Markdown modifiés, exécuter :
python3 scripts/audit_markdown_tables.py <fichiers-markdown-modifiés>
Après toute modification Rust :
cargo fmt --all
python3 scripts/audit_rust_workspace_rules.py
cargo check --workspace
cargo clippy --workspace --all-targets
Une commande non exécutée n'est jamais déclarée réussie.
3.2 Architecture à préserver
Lire ensuite :
docs/architecture/000-README.md
docs/architecture/002-LAYERS_AND_DEPENDENCIES.md
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
Frontières acquises :
ksp-onchain-transport-lib possède HTTP + WS + Yellowstone gRPC
Config -> Transport autorisé
Transport -X-> Config / Store / Program
provider adapters Yellowstone restent dans Transport tant qu'aucune frontière distincte n'est justifiée
un provider ne possède jamais le contrat Solana standard
applications/workers ne dépendent pas directement de Tonic/Prost/Yellowstone provider SDK
3.3 Séquence fonctionnelle et héritage direct 0.2.9
Lire :
docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
docs/plans/007-V0_2_0_SERIES_PLANNING.md
docs/plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md
docs/plans/014-V0_2_7_ONCHAIN_WEBSOCKET_PLAN.md
docs/plans/015-V0_2_8_HELIUS_LASERSTREAM_WEBSOCKET_PLAN.md
docs/plans/016-V0_2_9_YELLOWSTONE_GRPC_PLAN.md
docs/validation/007-V0_2_4_HTTP_FINAL_COMPLIANCE.md
docs/validation/010-V0_2_7_ONCHAIN_WEBSOCKET.md
docs/validation/011-V0_2_8_HELIUS_LASERSTREAM_WEBSOCKET.md
docs/validation/012-V0_2_9_YELLOWSTONE_GRPC.md
deltas/0.2.9/rel.001.md
Le plan 016 et la validation 012 sont la source interne principale pour les décisions Yellowstone qui ont supersédé les hypothèses du prompt 0.2.9.
3.4 Code réel à réauditer
Inspecter au minimum :
Cargo.toml
crates/ksp-onchain-transport-lib/Cargo.toml
crates/ksp-onchain-transport-lib/README.md
crates/ksp-onchain-transport-lib/USAGE.md
crates/ksp-onchain-transport-lib/src/lib.rs
crates/ksp-onchain-transport-lib/src/grpc_settings.rs
crates/ksp-onchain-transport-lib/src/grpc_channel.rs
crates/ksp-onchain-transport-lib/src/grpc_unary.rs
crates/ksp-onchain-transport-lib/src/grpc_subscribe.rs
crates/ksp-onchain-transport-lib/src/grpc_stream.rs
crates/ksp-onchain-transport-lib/tests/public_api.rs
crates/ksp-onchain-transport-lib/tests/release_completeness.rs
crates/ksp-onchain-transport-lib/tests/yellowstone_publicnode_smoke.rs
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
Ne pas concevoir OrbitFlare à partir de documentation provider seule sans vérifier les contrats KSP réels à réutiliser.
3.5 Références historiques utiles
Relire :
prompts/012-V0_2_7_START_PROMPT.md
prompts/013-V0_2_8_START_PROMPT.md
prompts/014-V0_2_9_START_PROMPT.md
014 est historique : son forecast initial a été recalibré pendant 0.2.9. Les plans/deltas stabilisés de 0.2.9 priment pour l'état final.
4. Sources externes normatives à réauditer en pre.001
La fraîcheur est obligatoire. OrbitFlare et Yellowstone sont actifs et leurs endpoints, auth modes et SDKs peuvent évoluer.
4.1 OrbitFlare primaire
Relire depuis l'état courant :
https://docs.orbitflare.com/llms.txt
https://docs.orbitflare.com/welcome
https://docs.orbitflare.com/data-streaming/yellowstone
https://docs.orbitflare.com/data-streaming/yellowstone-slot-block-monitoring
https://docs.orbitflare.com/cli
https://docs.orbitflare.com/api-documentation/welcome
https://orbitflare.com/products/solana-grpc
https://github.com/orbitflare/orbit-cli
https://github.com/orbitflare/orbitflare-sdk-rs
https://github.com/orbitflare/orbitflare-sdk-go
Les SDKs OrbitFlare servent de référence de comportement provider, pas de dépendance automatique de KSP.
4.2 Yellowstone primaire
Réaditer aussi :
https://github.com/rpcpool/yellowstone-grpc
https://github.com/rpcpool/yellowstone-grpc/blob/master/README.md
https://github.com/rpcpool/yellowstone-grpc/blob/master/CHANGELOG.md
https://github.com/rpcpool/yellowstone-grpc/releases
https://github.com/rpcpool/yellowstone-grpc/blob/master/yellowstone-grpc-proto/proto/geyser.proto
https://github.com/rpcpool/yellowstone-grpc/blob/master/yellowstone-grpc-proto/proto/solana-storage.proto
https://github.com/rpcpool/yellowstone-grpc/blob/master/LICENSING.md
https://crates.io/crates/yellowstone-grpc-proto
Vérifier si une évolution du standard entre v0.2.9 et l'ouverture de 0.2.10 change réellement le contrat OrbitFlare à implémenter.
4.3 Snapshot informatif au 2026-08-24 — ne pas figer
La documentation OrbitFlare observée lors de la préparation du prompt indique notamment :
Yellowstone = stream gRPC bidirectionnel
familles documentées = accounts, transactions, slots, blocks, entries
endpoint régional exemple = http://ams.rpc.orbitflare.com:10000
endpoint Devnet CLI = http://devnet.rpc.orbitflare.com:10000
endpoint dashboard = source réelle à utiliser pour le compte opérateur
ping recommandé docs Yellowstone = toutes les 30 s
produit = recommandation ping 15–30 s
Deux familles de documentation auth ne doivent pas être fusionnées arbitrairement :
Customer API X-ORBIT-KEY / Bearer selon version
RPC HTTP license/API key selon endpoint
CLI / SDK Yellowstone documentation récente indique IP whitelisting pour gRPC/Jetstream
exemples Yellowstone TS montrent aussi un X_TOKEN avec endpoint dédié
Cette divergence apparente est un gate pre.001, pas une décision déjà prise.
Autre point important : la documentation OrbitFlare recommande un ping client périodique pour éviter les timeouts de load balancer. Le moteur KSP 0.2.9 répond déjà aux SubscribeUpdate::Ping serveur, mais pre.001 doit déterminer si OrbitFlare exige en plus une émission périodique proactive. Ne pas ajouter un timer provider avant ce verdict.
5. État validé à préserver depuis v0.2.9
5.1 Moteur Yellowstone N1
Conserver :
YellowstoneGrpcEndpointUrl
YellowstoneGrpcEndpointSettings
YellowstoneGrpcSessionSettings
YellowstoneGrpcReconnectSettings
YellowstoneGrpcMetadataEntry
YellowstoneGrpcChannel
YellowstoneGrpcUnaryClient
YellowstoneGrpcSession
YellowstoneGrpcSessionSnapshot
Le raw client Tonic reste privé.
5.2 Standard Solana N2
Conserver la couverture stabilisée :
Subscribe
SubscribeReplayInfo
Ping
GetLatestBlockhash
GetBlockHeight
GetSlot
IsBlockhashValid
GetVersion
accounts
slots
transactions
transactions_status
blocks
blocks_meta
entry
commitment
accounts_data_slice
ping
from_slot
9 variantes SubscribeUpdate
SubscribeDeshred reste hors standard KSP N2 initial et ne doit pas entrer dans 0.2.10 simplement parce qu'OrbitFlare propose d'autres produits streaming.
5.3 Lifecycle N1/N2
Conserver :
un stream bidi standard par session
mutation request sur le même stream
Ping/Pong standard
queues bornées
oversize inbound/outbound borné
half-close et close bornés
reconnect budget borné
replay depuis last observed slot prudent
gap/duplicate observables
aucune promesse exactly-once/lossless
Une policy OrbitFlare supplémentaire doit s'ajouter sans casser ces garanties.
5.4 PublicNode N3
PublicNode constitue le premier témoin provider et réutilise directement le standard N2 avec un provider descriptif. Les faits stabilisés à préserver sont :
Mainnet endpoint = https://solana-yellowstone-grpc.publicnode.com:443
Testnet endpoint = https://solana-testnet-yellowstone-grpc.publicnode.com:443
auth wire = metadata x-token secrète
Config secret = deux variables KSP_SECRET_* distinctes
live gate = Subscribe -> Slot, Mainnet PASS + Testnet PASS
Le même personal token opérateur a été validé sur les deux réseaux ; les deux variables Config restent distinctes uniquement pour conserver de la flexibilité opérationnelle. Ne pas transformer ce constat en règle générale sur la portée des tokens PublicNode.
Les essais live ont aussi montré qu'un endpoint provider peut restreindre certaines unary indépendamment du streaming. Une unary standard disponible dans N2 n'est donc pas une garantie d'entitlement chez chaque provider.
OrbitFlare ne reçoit une façade publique spécifique que si pre.001 démontre qu'un comportement doit être exposé au consumer KSP.
5.5 Config V3
Conserver :
V1 HTTP backward-readable
V2 HTTP+WS backward-readable
V3 HTTP+WS+gRPC
protocol = solana_yellowstone
provider séparé du protocol
metadata et secret_metadata séparées
Config propriétaire de la provenance env/secrets
Transport ne lit pas env
5.6 HTTP, WS, Helius
Aucun changement OrbitFlare gRPC ne justifie une régression :
HTTP 52 current + 14 historical
Standard WS 18/18
Helius LaserStream WebSocket existant
no-resend write submission HTTP
firewall dépendances
6. Décisions acquises — ne pas redébattre sans contradiction réelle
0.2.10 = OrbitFlare Yellowstone gRPC
moteur N1 et standard N2 restent dans ksp-onchain-transport-lib
aucun nouveau ksp-grpc-lib
aucun second client Tonic parallèle
aucune dépendance OrbitFlare SDK requise par défaut
provider != protocol
Config -> Transport seulement
credentials restent Config-owned
Jetstream hors scope
Shredstream hors scope
SubscribeDeshred hors scope sauf reclassification standard explicite, ce qui serait un split
Helius LaserStream gRPC reste 0.2.11
7. Questions réellement ouvertes à trancher pendant pre.001
7.1 Auth OrbitFlare gRPC
Réconcilier les sources :
IP whitelist
endpoint/dashboard service-specific
X_TOKEN dans exemples Yellowstone
X-ORBIT-KEY Customer API
license key RPC HTTP
éventuelle auth mode API Key configurable dans dashboard
Décider précisément ce qui voyage sur le data-plane Yellowstone et ce qui appartient uniquement au control-plane Customer API/dashboard.
Ne jamais envoyer X-ORBIT-KEY ou un license key dans metadata Yellowstone sans preuve provider.
7.2 Endpoints et transport security
Auditer :
mainnet region endpoints
Devnet endpoint
Testnet réellement supporté ou non
port 10000
http vs https
endpoint dédié *.grpc.orbitflare.com observé dans exemples
endpoint dashboard comme source autoritative opérateur
http:// dans une URL Tonic signifie canal HTTP/2 non TLS côté KSP actuel. Ne pas affirmer que « gRPC négocie sa propre sécurité » comme équivalent TLS sans vérifier le comportement réel du service OrbitFlare et du moteur KSP.
7.3 Capabilities standard
Vérifier réellement sur OrbitFlare :
Subscribe
SubscribeReplayInfo
Ping unary
GetLatestBlockhash
GetBlockHeight
GetSlot
IsBlockhashValid
GetVersion
from_slot/replay
all N2 filter fields
all N2 update variants
compressed/cuckoo fields retenus en 0.2.9
Une documentation qui ne mentionne qu'un subset ne prouve ni support complet ni absence. Utiliser docs + SDKs + smoke/fixtures quand disponible.
7.4 Heartbeat provider
Trancher :
réponse aux pings serveur suffisante ?
ping SubscribeRequest périodique requis ?
intervalle 30 s normatif ou recommandation ?
intervalle 15–30 s provider-owned ?
missed-pong policy nécessaire ?
interaction avec reconnect KSP existant ?
Si une émission proactive est requise, préférer une policy provider explicite dans le même actor/session plutôt qu'un task/socket parallèle.
7.5 Limits et quotas
Auditer sans recopier aveuglément :
connexions simultanées
subscription count
filter count
account include/exclude/required
message sizes
bandwidth
RPS unary éventuels
archive/from_slot retention
rate-limit/status semantics
plan shared vs dedicated
Les quotas commerciaux variables ne deviennent pas automatiquement des bornes du contrat standard KSP.
7.6 Config
Décider :
profil orbitflare_mainnet ?
profil orbitflare_devnet ?
provider = orbitflare
protocol = solana_yellowstone
endpoint public vs secret
secret metadata seulement si data-plane l'exige
region descriptive ou portée dans endpoint seulement
heartbeat policy dans endpoint/session ou capability provider ?
Ne pas incrémenter automatiquement format_version si V3 sait déjà exprimer le besoin.
7.7 Smoke live
Décider une stratégie qui n'exige pas :
secret versionné
Transport -> env
provider SDK dans executable
smoke cross-crates placé dans Config
Si OrbitFlare exige IP whitelist ou credential opérateur indisponible, un smoke peut être operator-only. Documenter la limite au lieu d'inventer un endpoint ou un secret.
8. Objectifs et livrables de 0.2.10
Sous réserve du sizing pre.001 :
1. plan OrbitFlare Yellowstone dédié
2. validation/compliance OrbitFlare dédiée
3. matrice endpoint/auth/capabilities/lifecycle
4. preuve de réutilisation N1/N2 sans duplication
5. provider descriptor/capability si nécessaire
6. heartbeat provider si réellement nécessaire
7. Config V3 OrbitFlare si shape confirmée
8. tests déterministes provider policy
9. tests adversariaux/redaction
10. smoke live opt-in si architecture-safe
11. non-régressions PublicNode + Yellowstone standard
12. README/USAGE synchronisés
13. graphes dépendances si modifiés
14. prompt 0.2.11 Helius LaserStream gRPC
Documents normalement attendus après pre.001 :
docs/plans/017-V0_2_10_ORBITFLARE_YELLOWSTONE_GRPC_PLAN.md
docs/validation/013-V0_2_10_ORBITFLARE_YELLOWSTONE_GRPC.md
deltas/0.2.10/pre.001.md
Les indices sont ajustés seulement si la base stable contient déjà un document occupant ces numéros.
9. Hors périmètre explicite
Jetstream OrbitFlare
Shredstream OrbitFlare
Dedicated node orchestration
Customer API billing/account management
achat de plan / paiement
OrbitFlare CLI integration
OrbitFlare SDK comme API publique KSP
Helius LaserStream gRPC
Triton provider adapter
ERPC adapter
Chainstack adapter
Shyft adapter
SubscribeDeshred / pré-exécution
Store/materialization/workers
prix offchain
Wallet/Wallet Desk
Interface/Program
Une information provider utile à l'audit peut être lue sans faire entrer son produit correspondant dans le scope.
10. Contraintes sécurité, ressources, lifecycle et API
10.1 Credentials
Threat model minimum :
X-ORBIT-KEY utilisé au mauvais plan
license key RPC injecté dans gRPC sans preuve
X_TOKEN loggé ou exposé en Debug
endpoint dashboard sensible
metadata secret recopiée dans Status/context
IP whitelist confondue avec absence d'auth
Exigences :
aucun secret dans Debug/Display/KspError/log/snapshot
Config reste propriétaire des valeurs KSP_SECRET_*
Transport reçoit uniquement des settings résolus
control-plane OrbitFlare absent du runtime Transport sauf décision future distincte
10.2 Heartbeat et tasks
Interdit :
second actor gRPC uniquement pour OrbitFlare
task heartbeat détaché sans ownership/close
queue non bornée de pings
heartbeat continu après close/reconnect
Si policy proactive :
actor-owned
intervalle borné
cancellation au close
auto-rearm après reconnect seulement si session active
aucun payload secret
preuve déterministe avec fixture locale/paused time si possible
10.3 Errors et observabilité
Conserver les codes KSP et snapshots safe. Une erreur OrbitFlare peut être classifiée provider-specific uniquement si cela apporte un comportement exploitable ; ne pas copier un message remote arbitraire.
10.4 API publique
Favoriser :
réutilisation YellowstoneGrpcSession
réutilisation YellowstoneGrpcEndpointSettings
provider descriptor orbitflare
petite policy/provider facade seulement si divergence
aucun raw Tonic escape hatch
11. Première mission 0.2.10-pre.001 — gate obligatoire
11.1 Baseline stable avant modification
Exécuter :
cargo fmt --all
python3 scripts/audit_rust_workspace_rules.py
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test --workspace
cargo tree -p ksp-onchain-transport-lib
cargo tree -p ksp-onchain-transport-lib --duplicates
Enregistrer :
workspace.package.version
état complet tests
versions Yellowstone/Tonic/Prost directes
doublons principaux
état Config V3
état PublicNode smoke/documentation
11.2 Audit OrbitFlare actuel
Produire une matrice exhaustive couvrant au minimum :
source
endpoint
network/region
transport security
mode auth/control-plane/data-plane
service/method
support documenté
support vérifié si smoke possible
restriction provider
quota/limit si pertinent
policy ping/keepalive
reconnect/failover annoncé
mapping vers contrat KSP existant
extension KSP requise oui/non
preuve/test prévu
11.3 Audit auth contradictoire
Le gate ne peut pas être positif tant que les rôles de ces éléments ne sont pas distingués :
X-ORBIT-KEY
license key
X_TOKEN
IP whitelist
endpoint dashboard
Si les sources restent contradictoires, documenter ce qui est prouvé, ce qui est provider/account dependent et ce qui reste unknown. Ne pas choisir arbitrairement un header.
11.4 Audit heartbeat
Comparer le runtime KSP à :
Yellowstone upstream : serveur Ping + réponse client possible
OrbitFlare docs : ping client périodique recommandé
OrbitFlare SDK courant : active ping/pong possible
Décider si le moteur N1 nécessite une extension générique de keepalive configurable ou une policy OrbitFlare spécifique. Éviter de transformer une recommandation provider en comportement global standard sans besoin.
11.5 Audit architecture
Décider :
pas de façade OrbitFlare si simple profil suffit
sinon nom et responsabilité exacte de la façade/policy
ownership du heartbeat
Config V3 shape
provider capabilities
error mapping
logging target
smoke ownership
11.6 Threat model
Brainstormer au minimum :
secret metadata leak
wrong auth channel
endpoint leak
load balancer idle close
ping flood
missed pong
reconnect storm
IP whitelist mismatch
region failover qui change de node/fork
from_slot retention insuffisante
provider method unavailable
status remote arbitraire
quota/rate limit
plain HTTP endpoint exposé hors réseau attendu
11.7 Sizing et forecast recalibré
Avant implémentation lourde, écrire :
surface OrbitFlare exacte retenue
surface standard réutilisée sans code
extensions réellement nécessaires
Config changes exacts
nombre prévisionnel de prereleases
objectif de chaque tranche
preuves/gates par tranche
budget nominal 15–20 min par tranche
critères de split
11.8 Documents de sortie du gate
Créer/mettre à jour au minimum :
docs/plans/017-V0_2_10_ORBITFLARE_YELLOWSTONE_GRPC_PLAN.md
docs/validation/013-V0_2_10_ORBITFLARE_YELLOWSTONE_GRPC.md
deltas/0.2.10/pre.001.md
Puis auditer les tableaux Markdown touchés avec scripts/audit_markdown_tables.py.
Critères de sortie de pre.001
Gate positif seulement si :
base stable v0.2.9 confirmée
baseline opérateur enregistrée
sources OrbitFlare actuelles relues
sources Yellowstone actuelles relues
endpoint formats réconciliés
auth control-plane/data-plane classifiée
IP whitelist classifiée
X_TOKEN classifié
heartbeat périodique classifié
capabilities standard auditées
from_slot/replay audités côté provider
limits/quotas utiles audités
architecture réutilise N1/N2
Config V3 shape décidée ou explicitement reportée
smoke ownership décidé
threat model écrit
release dimensionnée
forecast recalibré
critères de split écrits
aucun SDK/client provider lourd ajouté prématurément
12. Prévision souple initiale des prereleases
Prévision de départ, obligatoirement recalibrée par pre.001 :
pre.001 audit OrbitFlare actuel + auth/endpoints/capabilities/heartbeat + architecture + threat model + sizing
preuve : plan + validation + matrice + forecast recalibré ; pas de code provider lourd avant gate
pre.002 provider descriptor/capabilities et settings/policy minimale réellement nécessaire
preuve : aucune duplication N1/N2 + tests provider-neutral/provider-specific exacts
pre.003 heartbeat/auth/lifecycle OrbitFlare seulement si divergence confirmée
preuve : fixture déterministe + cancellation/reconnect + redaction + aucun second actor
pre.004 Config V3 OrbitFlare + profils retenus + déterministe/adversarial/compliance
preuve : provenance secret correcte + standard N2 réutilisé + non-régressions ciblées
pre.005 gate technique/live final si applicable
preuve : smoke OrbitFlare opt-in ou bloc externe qualifié + workspace + graphes Cargo finaux
pre.006 réconciliation documentaire finale
preuve : plan + validation + README/USAGE + références durables synchronisés, aucun runtime modifié
pre.007 préparation de publication minimale
preuve : prompt 0.2.11 + CHANGELOG.md + ROADMAP.md uniquement, hors Cargo.toml/delta mécaniques
rel.001 publication stable stricte, sans rattrapage technique ou documentaire
Règles :
chaque tranche vise nominalement 15–20 min de travail effectif
pre.001 peut fusionner/scinder/déplacer/ajouter des prereleases de développement
si OrbitFlare est purement standard, réduire les tranches intermédiaires
si auth/heartbeat implique une extension moteur importante, scinder avant implémentation
le gate technique/live final peut être omis si aucun smoke/live n'est pertinent
réconciliation documentaire et préparation de publication restent toujours deux prereleases distinctes
la dernière prerelease ne finalise que prompt suivant + CHANGELOG + ROADMAP, hors Cargo.toml/delta mécaniques
un fix reste local à la responsabilité de sa prerelease
un défaut découvert dans un couloir antérieur ouvre une nouvelle prerelease dédiée puis rejoue les couloirs suivants
rel.001 ne sert jamais de tranche de rattrapage
le numéro final n'est jamais un critère de clôture
13. Versionnement, deltas, commits, archives et tags
Convention :
0.2.10-pre.001 -> Cargo 0.2.10-pre.1
0.2.10-pre.002 -> Cargo 0.2.10-pre.2
0.2.10-pre.NNN-fix.MMM -> Cargo 0.2.10-pre.N.fix.M si changement technique
0.2.10-rel.001 -> Cargo 0.2.10
Deltas :
deltas/0.2.10/pre.001.md
...
deltas/0.2.10/pre.NNN-fix.MMM.md
deltas/0.2.10/rel.001.md
Commits :
v0.2.10-pre.001
v0.2.10-pre.001-fix.001
...
v0.2.10-rel.001
Archives :
ksp-general-0.2.10-pre.001.zip
ksp-general-0.2.10-pre.NNN-fix.MMM.zip
ksp-general-0.2.10-rel.001.zip
Aucun tag Git prerelease. Le tag stable attendu est uniquement :
v0.2.10
Les deltas publiés sont immuables.
La fermeture respecte docs/rules/PROMPT_STRUCTURE.md et docs/rules/VERSION_WORKFLOW.md :
gate technique/live final éventuel
-> réconciliation documentaire finale
-> préparation de publication minimale
-> rel.001
La dernière prerelease avant rel.001 ne modifie fonctionnellement que le prompt suivant, CHANGELOG.md et ROADMAP.md, en plus de Cargo.toml et de son delta mécanique.
14. Validation opérateur et application
Après Rust :
cargo fmt --all
python3 scripts/audit_rust_workspace_rules.py
cargo check --workspace
cargo clippy --workspace --all-targets
Après Markdown avec tableaux :
python3 scripts/audit_markdown_tables.py <fichiers-markdown-modifiés>
Tests ciblés selon scope :
cargo test -p ksp-onchain-transport-lib
cargo test -p ksp-config-lib
cargo test -p ksp-core-lib --test workspace_dependencies
À la fermeture d'une prerelease technique :
cargo test --workspace
Si le graphe change :
cargo tree -p ksp-onchain-transport-lib
cargo tree -p ksp-onchain-transport-lib --duplicates
cargo tree --duplicates
Inspecter explicitement toute nouvelle dépendance provider ou nouvelle version de :
yellowstone-grpc-proto
tonic / tonic-prost
prost / prost-types
tower / hyper / http / bytes
rustls
tokio
Ne pas ajouter orbitflare-sdk-* sans justification forte et audit licence/features/transitifs.
15. Tests attendus selon le scope retenu
provider descriptor/capability
endpoint format
Config provider/protocol separation
secret provenance
metadata auth si réellement utilisée
heartbeat interval bounds si ajouté
heartbeat actor ownership
heartbeat close cancellation
heartbeat reconnect rearm
remote Status safe mapping
provider unsupported capability
reconnect/from_slot behavior
live smoke opt-in
PublicNode regression
standard Yellowstone regression
HTTP/WS/Helius regressions
public API
release completeness
dependency firewall
Markdown table audit
Aucun build Tauri n'est requis par défaut pour cette release Transport pure si aucune application n'est modifiée.
16. Critères de clôture de 0.2.10
La release peut devenir stable seulement si :
OrbitFlare current docs réauditées
auth data-plane réellement classifiée
endpoint/network/region semantics classifiées
heartbeat provider réellement classifié
aucun secret dans logs/errors/debug
aucun second moteur/client gRPC
aucune duplication arbitraire N1/N2
capabilities OrbitFlare explicites
Config V3 cohérente si modifiée
smoke live exécuté ou bloc externe précisément documenté
PublicNode Yellowstone non régressé
standard Yellowstone non régressé
HTTP 52+14 non régressé
Standard WS 18/18 non régressé
Helius WS non régressé
firewall dépendances vert
workspace complet vert
README/USAGE synchronisés dans la prerelease documentaire dédiée
matrice OrbitFlare fermée avant la prerelease de publication
prompt 0.2.11 préparé uniquement dans la dernière prerelease
CHANGELOG/ROADMAP finalisés uniquement dans la dernière prerelease
aucun rattrapage technique/documentaire dans rel.001
Le numéro de prerelease n'est jamais un critère de clôture. Les numéros de la prévision peuvent dériver, mais l'ordre des couloirs de fermeture ne dérive pas.
17. Release/session suivante envisagée
La release suivante active est :
0.2.11 — Helius LaserStream gRPC
Elle devra réauditer indépendamment :
endpoint/auth Helius gRPC
capabilities Yellowstone supportées
éventuelles extensions provider
replay/from_slot
heartbeat/lifecycle
Config V3
smoke provider
Ne pas anticiper Helius gRPC dans 0.2.10.
Après 0.2.11, la séquence active prévoit :
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
18. Instruction d'ouverture
Au début de la session 0.2.10 :
- confirmer la base stable
v0.2.9ou l'archive stable autoritaire ; - vérifier
workspace.package.version = 0.2.9etdeltas/0.2.9/rel.001.md; - lire les règles dans l'ordre de la section 3, y compris les règles de tableaux Markdown ;
- relire plan
016, validation012, README/USAGE Transport et Config V3 ; - exécuter la baseline avant modification ;
- réauditer immédiatement OrbitFlare docs,
llms.txt, Yellowstone docs, CLI et SDKs provider ; - réauditer l'upstream Yellowstone courant ;
- dresser la matrice endpoint/network/region/auth/capabilities/heartbeat ;
- distinguer Customer API, RPC license, data-plane gRPC, IP whitelist et éventuel
X_TOKEN; - déterminer si OrbitFlare nécessite réellement une façade/policy KSP spécifique ;
- déterminer si un ping périodique proactif est requis et où il doit être owned ;
- auditer limites, quotas et from_slot/replay provider ;
- brainstormer sécurité, lifecycle, reconnect et blocage live ;
- dimensionner la release et recalibrer le forecast ;
- créer plan, validation et
deltas/0.2.10/pre.001.md; - auditer les tableaux Markdown modifiés ;
- exécuter les gates disponibles ;
- ne pas ajouter un SDK OrbitFlare, un second client gRPC, un header secret ou un heartbeat provider en production avant que le gate
pre.001ait démontré leur nécessité et leur ownership.
La première réponse de travail de la nouvelle session doit être un audit/sizing OrbitFlare 0.2.10-pre.001 complet, pas une implémentation provider prématurée.