# 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 : ```text 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 : ```text 0.2.10 — OrbitFlare Yellowstone gRPC ``` La première tranche est : ```text 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 : ```text 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` : ```text 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 : ```text 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 : ```text 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 : ```text 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 : ```text 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` : ```text 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 : ```bash python3 scripts/audit_markdown_tables.py ``` Après toute modification Rust : ```bash 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 : ```text 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 : ```text 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 : ```text 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 : ```text 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 : ```text 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 : ```text 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 : ```text 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 : ```text 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 : ```text 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 : ```text 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 : ```text 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 : ```text 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 : ```text 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 : ```text 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 : ```text 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 ```text 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 : ```text 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 : ```text 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 : ```text 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 : ```text 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 : ```text 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 : ```text 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 : ```text 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` : ```text 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` : ```text 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 ```text 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 : ```text 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 : ```text 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 : ```text 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 : ```text 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 : ```text 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 : ```bash 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 : ```text 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 : ```text 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 : ```text 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 à : ```text 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 : ```text 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 : ```text 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 : ```text 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 : ```text 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 : ```text 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` : ```text 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 : ```text 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 : ```text 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 : ```text deltas/0.2.10/pre.001.md ... deltas/0.2.10/pre.NNN-fix.MMM.md deltas/0.2.10/rel.001.md ``` Commits : ```text v0.2.10-pre.001 v0.2.10-pre.001-fix.001 ... v0.2.10-rel.001 ``` Archives : ```text 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 : ```text v0.2.10 ``` Les deltas publiés sont immuables. La fermeture respecte `docs/rules/PROMPT_STRUCTURE.md` et `docs/rules/VERSION_WORKFLOW.md` : ```text 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 : ```bash cargo fmt --all python3 scripts/audit_rust_workspace_rules.py cargo check --workspace cargo clippy --workspace --all-targets ``` Après Markdown avec tableaux : ```bash python3 scripts/audit_markdown_tables.py ``` Tests ciblés selon scope : ```bash 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 : ```bash cargo test --workspace ``` Si le graphe change : ```bash 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 : ```text 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 ```text 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 : ```text 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 : ```text 0.2.11 — Helius LaserStream gRPC ``` Elle devra réauditer indépendamment : ```text 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 : ```text 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` : 1. confirmer la base stable `v0.2.9` ou l'archive stable autoritaire ; 2. vérifier `workspace.package.version = 0.2.9` et `deltas/0.2.9/rel.001.md` ; 3. lire les règles dans l'ordre de la section 3, y compris les règles de tableaux Markdown ; 4. relire plan `016`, validation `012`, README/USAGE Transport et Config V3 ; 5. exécuter la baseline avant modification ; 6. réauditer immédiatement OrbitFlare docs, `llms.txt`, Yellowstone docs, CLI et SDKs provider ; 7. réauditer l'upstream Yellowstone courant ; 8. dresser la matrice endpoint/network/region/auth/capabilities/heartbeat ; 9. distinguer Customer API, RPC license, data-plane gRPC, IP whitelist et éventuel `X_TOKEN` ; 10. déterminer si OrbitFlare nécessite réellement une façade/policy KSP spécifique ; 11. déterminer si un ping périodique proactif est requis et où il doit être owned ; 12. auditer limites, quotas et from_slot/replay provider ; 13. brainstormer sécurité, lifecycle, reconnect et blocage live ; 14. dimensionner la release et recalibrer le forecast ; 15. créer plan, validation et `deltas/0.2.10/pre.001.md` ; 16. auditer les tableaux Markdown modifiés ; 17. exécuter les gates disponibles ; 18. **ne pas ajouter un SDK OrbitFlare, un second client gRPC, un header secret ou un heartbeat provider en production avant que le gate `pre.001` ait 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.