khadhroony-solana-project/prompts/015-V0_2_10_START_PROMPT.md

<!-- file: prompts/015-V0_2_10_START_PROMPT.md -->
<!-- version: 2 -->

# 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 <fichiers-markdown-modifiés>
```

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 <fichiers-markdown-modifiés>
```

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.