: non nécessaire en 0.2.8 ``` Une nouvelle preuve normative peut rouvrir un point et insérer une tranche ; aucun report ne doit disparaître silencieusement. ## 12. Critères de split et de clôture Créer une tranche/fix supplémentaire si : - l'extraction du chemin physique de `WsSession` révèle un problème générique indépendant ; - une des six familles Helius dites communes diverge réellement du standard ; - plusieurs formes de notification transaction demandent des contrats séparés ; - Helius modifie sa surface normative pendant la release ; - le smoke live impose une intégration non disponible ; - un gate final reste rouge après `pre.011`. La release ne passe stable que si : ```text surface Helius rapprochée source par source façades protocolaires séparées moteur WsSession/actor unique unsupported Helius absent de la façade publique transaction extension sans pollution des DTOs standard standard WS 18/18 non régressé HTTP 52/14 non régressé Config -> Transport uniquement credentials redacted heartbeat borné/testé si implémenté reconnect/resubscribe/backpressure/shutdown bornés aucune promesse replay/lossless WebSocket aucune nouvelle dépendance injustifiée workspace complet vert README/USAGE synchronisés validation finale fermée prompt 0.2.9 prêt ``` ## 13. Checkpoints `pre.004`, fixes et préparation `pre.005` Le checkpoint `pre.003` est fermé par preuve opérateur : ```text cargo fmt --all OK python3 scripts/audit_rust_workspace_rules.py clean cargo check --workspace OK cargo clippy --workspace --all-targets OK cargo test -p ksp-onchain-transport-lib OK cargo test --workspace OK ``` Les preuves spécifiques `pre.003` sont acquises : fixture Helius 6/6, 38 tests public API, 26 release-completeness et 4 doctests `compile_fail`, tous verts. `pre.004` prépare uniquement : ```text WsProtocolKind Config mapping helius_laserstream -> HeliusLaserStream JSON Schema V2 kind accepte solana_standard + helius_laserstream fixture Config Helius mainnet + profil Helius devnet séparé, interpolation d'api-key example Config profils Helius mainnet/devnet explicites et séparés secret KSP_SECRET_HELIUS_API_KEY safe projection / Debug credential Helius redacted Config -> Transport endpoint typé HeliusLaserStream canonical std.transport.json inchangé, standard-only transactionSubscribe toujours absent heartbeat toujours absent new dependency aucune ``` Le premier checkpoint opérateur `pre.004` reçu le 2026-08-23 donne : ```text cargo fmt --all OK python3 scripts/audit_rust_workspace_rules.py clean cargo check --workspace OK cargo clippy --workspace --all-targets OK cargo test -p ksp-config-lib FAIL 109/110 cargo test -p ksp-onchain-transport-lib OK 314 unit + 38 public + 26 completeness + 4 doctests cargo test --workspace FAIL sur le même test Config ``` L'unique échec opérateur compare `safe_value` à `********` alors que le résolveur produit correctement `wss://mainnet.helius-rpc.com/?api-key=********`. Les canaris historiques Config prouvent déjà ce contrat de redaction segmentaire pour les chaînes composées. La revue du fix a aussi identifié que `pre.004` ne matérialisait déterministiquement que mainnet alors que le contrat Helius WebSocket couvre mainnet et devnet. `pre.004-fix.001` corrige donc l'attente du test **et** ajoute un profil/fixture Devnet Helius séparé, sans modifier le résolveur, le schema, le mapping protocol ou le runtime Transport. Le checkpoint opérateur de `pre.004-fix.001` reçu le 2026-08-23 confirme : ```text cargo fmt --all OK python3 scripts/audit_rust_workspace_rules.py clean cargo check --workspace OK cargo clippy --workspace --all-targets OK cargo test -p ksp-config-lib FAIL 109/110 cargo test -p ksp-onchain-transport-lib OK 314 unit + 38 public + 26 completeness + 4 doctests ``` Le nouvel échec est strictement dans le canari Helius Config : ```text provenance observée = 2 segments provenance attendue = 1 segment ``` Pour une URL composée `littéral + ${KSP_SECRET_HELIUS_API_KEY}`, le contrat Config enregistre correctement deux provenances ordonnées : `DocumentLiteral`, puis `EnvironmentProcess(KSP_SECRET_HELIUS_API_KEY)`. `pre.004-fix.002` corrige seulement cette attente pour mainnet et devnet ; aucune donnée Config ni logique runtime n'est modifiée. Le checkpoint opérateur reçu après `pre.004-fix.002` ferme cette tranche : ```text cargo fmt --all OK python3 scripts/audit_rust_workspace_rules.py clean cargo check --workspace OK cargo clippy --workspace --all-targets OK cargo test -p ksp-config-lib OK 110/110 + ownership/public API cargo test -p ksp-onchain-transport-lib OK 314 unit + 38 public + 26 completeness + 4 doctests cargo test --workspace OK ``` Les profils Helius mainnet/devnet, la redaction segmentaire, la provenance composée, le mapping Config -> Transport et l'absence de nouvelle dépendance sont donc acquis avant `pre.005`. `pre.005` prépare maintenant : ```text HeliusTransactionSubscribeFilter vote/failed/signature/accountInclude/accountExclude/accountRequired/tokenAccounts HeliusTokenAccountsFilter none / balanceChanged / all HeliusTransactionSubscribeOptions commitment/encoding/transactionDetails/showRewards/maxSupportedTransactionVersion HeliusTransactionSubscribeRequest validation déterministe + params exacts accountInclude/Exclude/Required <= 50_000 chacun transactionDetails accounts/full maxSupportedTransactionVersion obligatoire transactionSubscribe ack remote id numérique décodé en interne transactionUnsubscribe méthode/params/résultat bool exacts Debug filtre/request signature et valeurs d'adresses non rendues actor/socket chemin physique existant réutilisé dans fixture locale live transaction handle volontairement absent jusqu'à pre.006 transactionNotification toujours hors scope pre.005 heartbeat toujours hors scope pre.005 new dependency aucune ``` La séparation `pre.005` / `pre.006` est normative : publier dès maintenant un `transaction_subscribe()` public sans registry de notification/reconnect produirait un handle transitoire qui perdrait les notifications. Le contrat public de requête est donc stable dès `pre.005`, tandis que l'abonnement live est ajouté atomiquement avec l'actor integration en `pre.006`. ### Checkpoint `pre.005` et correctif `pre.005-fix.001` Le premier checkpoint opérateur de `pre.005` a donné : ```text cargo fmt --all OK python3 scripts/audit_rust_workspace_rules.py clean mais incomplet pour la règle test/private cargo check --workspace OK avec 5 warnings unused pub(crate) reexports cargo clippy --workspace --all-targets FAIL — 4 comparaisons Vec / Value cargo test -p ksp-onchain-transport-lib FAIL — mêmes 4 erreurs de type ``` Le correctif ne change ni le contrat Helius public ni le wire. Il applique la règle de visibilité KSP : un helper utilisé seulement par son module et son sous-module de tests reste strictement privé ; le test l'appelle via `super::Item`. Les éléments `pub` et `pub(crate)` restent réexportés et consommés via `crate::Item`. Les helpers transaction wire de `pre.005` ne deviendront `pub(crate)` qu'en `pre.006` si l'actor les consomme réellement. Le script `audit_rust_export_completeness.py` est étendu pour détecter dans les `unit_tests/` séparés les accès non qualifiés aux items privés du parent et les accès non canoniques aux items visibles. ### Checkpoint `pre.005-fix.001` et correctif `pre.005-fix.002` Le checkpoint opérateur après `fix.001` confirme que les erreurs `Vec`/`Value` sont corrigées et que les tests Transport passent (`322` unit, `39` public API, `27` release completeness, `4` doctests). Il révèle toutefois neuf warnings `dead_code` pendant `cargo check`, `clippy` et la compilation des tests : deux sérialiseurs privés, cinq helpers de contrôle subscribe/unsubscribe et le helper d'insertion de listes. Ces éléments ne sont pas encore consommés par un chemin de production en `pre.005`; leur seul consommateur légitime est le sous-module `unit_tests` rattaché au module propriétaire. `fix.002` applique donc `RUST-API-008` : ils restent strictement privés et sont placés sous `#[cfg(test)]`. Le contrat public typed et ses validations restent compilés en production. Aucune visibilité n'est élargie, aucun `#[allow(dead_code)]` n'est ajouté et le wire préparé reste couvert par les mêmes canaris. Leur promotion éventuelle en code de production est différée à `pre.006`, exactement au moment où l'actor WebSocket les consommera réellement ; si cette promotion exige `pub(crate)`, elle suivra alors la façade crate-root et les appels `crate::Item`. ## 14. Fermeture `pre.005` et préparation `pre.006` Le checkpoint opérateur reçu après `pre.005-fix.002` ferme entièrement la tranche transaction-request : ```text cargo fmt --all OK python3 scripts/audit_rust_workspace_rules.py clean cargo check --workspace OK, sans warning cargo clippy --workspace --all-targets OK, sans warning cargo test -p ksp-onchain-transport-lib OK 322 unit + 39 public API + 27 completeness + 4 doctests cargo test --workspace OK ``` `pre.006` promeut uniquement les helpers désormais réellement consommés par le chemin live. Ils restent strictement privés dans leur module lorsque leur consommation est locale ; aucun élargissement de visibilité n'est effectué pour les tests. Les tests continuent d'accéder aux privés du parent via `super::Item`, tandis que les types publics passent par la façade crate-root `crate::Item`. La tranche ajoute : ```text WsSubscriptionKind::HeliusTransaction subscribe method transactionSubscribe unsubscribe method transactionUnsubscribe notification method transactionNotification HeliusLaserStreamWsSession::transaction_subscribe(request) -> WsSubscription HeliusTransactionNotification Full transaction + signature + slot + transactionIndex Signature signature + slot + transactionIndex + champs optionnels conservés Unknown payload provider futur/none conservé sans faire tomber la souscription ``` Le variant `Unknown` est volontairement borné à la valeur `result` de `transactionNotification` : KSP ne publie ni l'enveloppe JSON-RPC complète ni l'identifiant remote de subscription. Le remote ID reste propriété exclusive de l'actor et peut donc être remappé après reconnexion sans changer l'identité locale du handle. Les canaris locaux `pre.006` doivent prouver ensemble : ```text [ ] requête live exacte via HeliusLaserStreamWsSession::transaction_subscribe [ ] transactionNotification Full décodée par le handle public [ ] formes Signature et Unknown préservées [ ] transactionUnsubscribe utilise le remote ID courant [ ] reconnexion renvoie le même params transactionSubscribe [ ] remote ID 41 -> 99 remappé sans changer WsSubscriptionId [ ] notification tardive après demande unsubscribe ignorée [ ] overflow transaction échoue seulement la souscription lente [ ] cleanup overflow appelle transactionUnsubscribe [ ] une souscription Helius root saine continue de recevoir ses notifications [ ] standard 9 familles / 18 opérations non régressées [ ] aucun heartbeat ajouté avant pre.007 [ ] aucun second actor/socket/registry/queue [ ] aucune nouvelle dépendance ``` Hors scope inchangé : heartbeat/idle (`pre.007`), adversarial provider/security élargi (`pre.008`), smoke Helius live (`pre.010`) et LaserStream gRPC. ## 15. Fermeture `pre.006` et préparation `pre.007` Checkpoint opérateur `0.2.8-pre.006` reçu le 2026-08-23 : ```text [x] cargo fmt --all [x] python3 scripts/audit_rust_workspace_rules.py = clean [x] cargo check --workspace = sans warning [x] cargo clippy --workspace --all-targets = sans warning [x] cargo test -p ksp-onchain-transport-lib = 325 unit + 40 public API + 28 completeness + 4 doctests [x] cargo test --workspace = vert ``` Le lifecycle Helius transaction est donc fermé : `transactionNotification`, handle live, remap remote ID, resubscribe, unsubscribe tardif et backpressure ciblée sont acquis sans second actor/socket. `pre.007` n'ajoute aucune surface publique générique de heartbeat. La policy reste possédée par le protocole Helius LaserStream WebSocket dans `WsSession` : ```text protocole actif WsProtocolKind::HeliusLaserStream uniquement intervalle nominal 60 s wire WebSocket Ping control frame vide état d'émission Active uniquement succès prochain deadline = now + 60 s reconnect réussi deadline réarmé depuis la nouvelle connexion write timeout/failure WsActorIoOutcome::Failed -> reconnect borné existant close/shutdown branche shutdown prioritaire, timer abandonné SolanaStandard aucun heartbeat provider ``` Aucun champ `heartbeat_*` n'est ajouté à `WsSessionSettings` ou Config en `0.2.8`. La cadence Helius est une policy interne provider-owned, comme décidé à l'audit d'ouverture. Pour rendre les canaris de timer déterministes sans réduire la cadence de production, `tokio` active uniquement la feature de dev/test `test-util`; aucune nouvelle dépendance runtime n'est ajoutée. Canaris locaux `pre.007` préparés : ```text [ ] policy Helius-only + intervalle exact 60 s [ ] premier Ping après 60 s, puis réarmement périodique [ ] SolanaStandard n'émet aucun Ping provider même après plusieurs intervalles [ ] close avant deadline n'émet aucun heartbeat [ ] write failure du Ping produit le même outcome Failed utilisé par le reconnect [ ] reconnect réussi réarme le heartbeat depuis la nouvelle connexion, sans Ping immédiat [ ] shutdown/backoff existant reste interruptible [ ] aucune modification du lifecycle transaction pre.006 ``` Comptages attendus après ajout des canaris : ```text Transport unit 331 Transport public API 40 release completeness 29 doctests compile-fail 4 ``` Le heartbeat Helius reste un mécanisme de maintien de connexion ; il n'introduit aucune promesse de replay WebSocket ni de livraison lossless. ## 16. Checkpoint `pre.007` et préparation `pre.007-fix.001` Checkpoint opérateur `0.2.8-pre.007` reçu le 2026-08-23 : ```text [x] cargo fmt --all [x] python3 scripts/audit_rust_workspace_rules.py = clean [x] cargo check --workspace = sans warning [!] cargo clippy --workspace --all-targets unit_tests/ws_session.rs: yield_runtime_steps() termine sans `return;` explicite [!] cargo test -p ksp-onchain-transport-lib 329/331 unit passent ; 2 canaris heartbeat échouent [ ] cargo test --workspace — non retenu tant que le gate Transport n'est pas vert ``` Les quatre autres preuves heartbeat importantes passent déjà : policy Helius-only/60 s, absence de heartbeat standard, erreur d'écriture mappée vers le reconnect existant, et réarmement après reconnexion. Le défaut observé est donc borné au harness de test, pas au chemin runtime `ws_session.rs`. Cause exacte des deux canaris : ```text helius_heartbeat_sends_ping_at_sixty_seconds_and_rearms l'horloge pausée est avancée avant d'avoir garanti un premier poll de l'actor ; le sleep_until heartbeat peut donc être armé seulement après l'avance. helius_explicit_close_cancels_heartbeat_before_deadline après close, le serveur fixture termine et le sender d'observation est détruit ; try_recv() peut légitimement rendre Disconnected au lieu de Empty. ``` `fix.001` ne touche pas le runtime heartbeat. Il modifie uniquement le canari : ```text - `yield_runtime_steps()` termine par `return;` explicite ; - après `tokio::time::pause()`, l'actor reçoit plusieurs yields avant la première avance ; - le test close prouve d'abord `Empty` à t=30 s avant close ; - après close, il exige seulement qu'aucun `Ok(())` Ping n'ait été observé, donc `Empty` et `Disconnected` sont tous deux acceptables. ``` La constante 60 s, la frame Ping, le branch actor, le reconnect, Config et `WsSessionSettings` restent byte-for-byte hors du fix. `pre.008` reste bloqué jusqu'au replay vert de `pre.007-fix.001`. ## 17. Replay `pre.007-fix.001` et préparation `pre.007-fix.002` Checkpoint opérateur `0.2.8-pre.7.fix.1` reçu le 2026-08-23 : ```text [x] cargo fmt --all [x] python3 scripts/audit_rust_workspace_rules.py = clean / 0 candidate [x] cargo check --workspace = vert, sans warning [x] cargo clippy --workspace --all-targets = vert, sans warning [!] cargo test -p ksp-onchain-transport-lib = 330/331 unit ; 1 seul échec heartbeat périodique [ ] cargo test --workspace — bloqué tant que Transport n'est pas vert ``` Le `fix.001` a donc bien corrigé : ```text [x] `clippy::implicit_return` dans yield_runtime_steps [x] close avant deadline : aucun Ping puis Empty/Disconnected acceptés après fermeture [x] policy Helius-only + 60 s [x] absence de heartbeat standard [x] write failure -> reconnect [x] réarmement après reconnect ``` Échec restant : ```text helius_heartbeat_sends_ping_at_sixty_seconds_and_rearms le timer est expiré à t=60 s, mais l'observation traverse encore plusieurs tâches : actor -> écriture socket -> lecture serveur fixture -> ping_tx -> ping_rx. Un `try_recv()` après un nombre fixe faible de yields reste donc une course scheduler. ``` `fix.002` reste test-only et ne modifie pas `src/ws_session.rs`. Il ajoute un helper d'observation bornée qui : ```text - tente `try_recv()` ; - si Empty, cède explicitement au scheduler ; - répète au maximum 256 tours ; - échoue immédiatement si le canal est Disconnected ; - n'appelle ni `advance()`, ni `sleep()`, ni `timeout()` pendant cette attente. ``` Ainsi, le test peut laisser la propagation async finir **sans faire avancer l'horloge Tokio au-delà de t=60 s / t=120 s**. Le canari continue donc de vérifier la vraie cadence nominale, et ne peut pas réussir grâce à un heartbeat ultérieur. Le runtime reste byte-for-byte hors du fix : cadence 60 s, Ping control frame, actor unique, reconnect, shutdown, Config et lifecycle transaction inchangés. `pre.008` reste bloqué jusqu'au replay entièrement vert de `pre.007-fix.002`. ## 18. Replay `pre.007-fix.002` et préparation `pre.007-fix.003` Checkpoint opérateur `0.2.8-pre.7.fix.2` reçu le 2026-08-23 : ```text [x] cargo fmt --all [x] python3 scripts/audit_rust_workspace_rules.py = clean / 0 candidate [x] cargo check --workspace = vert, sans warning [x] cargo clippy --workspace --all-targets = vert, sans warning [!] cargo test -p ksp-onchain-transport-lib = 330/331 unit ; même unique canari périodique [ ] cargo test --workspace — non retenu tant que Transport n'est pas vert ``` Le `fix.002` démontre que le problème n'est pas un simple manque de tours scheduler : même 256 `yield_now()` bornés ne rendent pas le Ping observable par la fixture TCP locale. La revue du runtime montre en parallèle que : ```text - le deadline heartbeat est construit par `next_helius_heartbeat_deadline()` ; - la branche `sleep_until(heartbeat_deadline)` est bien présente dans le `tokio::select!` de l'actor ; - un succès de `send_helius_heartbeat()` réarme à `now + 60 s` ; - le canari reconnect actor réel continue de prouver un Ping après le réarmement de connexion. ``` Diagnostic affiné : sous horloge Tokio pausée, `yield_now()` garantit une cession au scheduler mais **ne garantit pas à lui seul un tour du driver I/O OS**. Le chemin d'observation TCP : ```text actor -> websocket.send(Ping) -> socket loopback -> reactor I/O -> fixture websocket.next() -> channel ``` peut donc rester invisible au `try_recv()` malgré un timer actor expiré et une écriture déjà engagée. `fix.003` reste test-only côté Rust et conserve `src/ws_session.rs` byte-identical. Le canari périodique : ```text - garde l'horloge virtuelle pausée pour prouver l'absence avant le deadline ; - avance exactement jusqu'au deadline nominal ; - reprend ensuite le temps réel uniquement pendant une fenêtre I/O bornée <= 1 s pour laisser le reactor TCP propager le Ping ; - repause immédiatement l'horloge après observation ; - compense le temps réel consommé avant le contrôle du second intervalle afin de rester strictement avant le second deadline ; - franchit ensuite le second deadline avant une nouvelle fenêtre I/O bornée. ``` Cette fenêtre réelle ne peut pas masquer un heartbeat manquant : elle ne dure qu'une seconde au maximum, très inférieure à l'intervalle provider-owned de 60 s, et n'est ouverte qu'après franchissement du deadline virtuel attendu. Le runtime, Config, `WsSessionSettings`, le lifecycle transaction et la cadence 60 s restent inchangés. `pre.008` reste bloqué jusqu'au replay entièrement vert de `pre.007-fix.003`. ## 19. Replay `pre.007-fix.003` et préparation `pre.007-fix.004` Checkpoint opérateur `0.2.8-pre.7.fix.3` reçu le 2026-08-23 : ```text [x] cargo fmt --all [x] python3 scripts/audit_rust_workspace_rules.py = clean / 0 candidate [x] cargo check --workspace = vert, sans warning [x] cargo clippy --workspace --all-targets = vert, sans warning [x] cargo test -p ksp-onchain-transport-lib = 331/331 unit + 40 API + 29 completeness + 4 doctests [!] cargo test --workspace = échec unique dans ksp-core-lib/tests/workspace_dependencies.rs ``` Le heartbeat `pre.007` est donc fonctionnellement fermé côté Transport. L'échec workspace est indépendant du runtime : ```text transport_manifest_preserves_ksp_dependency_firewall attendu historique : tokio dev features = ["net", "rt"] manifest courant : tokio dev features = ["io-util", "net", "rt", "test-util"] ``` `pre.007` a légitimement ajouté `test-util` pour `tokio::time::pause/advance` et `io-util` pour les fixtures WebSocket de test. Le canari workspace, resté textuellement figé sur l'ancien ensemble, n'a pas été mis à jour dans le delta d'origine. `fix.004` corrige uniquement cette incohérence de validation : ```text - aucune modification de crates/ksp-onchain-transport-lib/Cargo.toml ; - aucune modification de src/ws_session.rs ni des canaris heartbeat ; - mise à jour du canari dependency-firewall vers l'ensemble dev exact courant ["io-util", "net", "rt", "test-util"] ; - aucune nouvelle dépendance ni feature. ``` `pre.008` reste bloqué jusqu'au replay workspace vert de `pre.007-fix.004`. ## 20. Fermeture `pre.007` et préparation `pre.008` Checkpoint opérateur `0.2.8-pre.7.fix.4` reçu le 2026-08-23 : ```text [x] cargo fmt --all [x] python3 scripts/audit_rust_workspace_rules.py = clean / 0 candidate [x] cargo check --workspace = vert, sans warning [x] cargo clippy --workspace --all-targets = vert, sans warning [x] cargo test -p ksp-onchain-transport-lib = 331 unit + 40 API + 29 completeness + 4 doctests [x] cargo test --workspace = vert ``` La tranche heartbeat et ses quatre fixes sont donc fermés. `pre.008` ne rouvre ni cadence, ni Config, ni lifecycle transaction nominal. Ré-audit Helius du 2026-08-23 : ```text transactionSubscribe supporté sur endpoints WSS unifiés mainnet/devnet accountInclude/accountExclude/accountRequired 50 000 adresses max chacune transactionUnsubscribe ID distant numérique + bool de réponse blockSubscribe non supporté Helius slotsUpdatesSubscribe non supporté Helius voteSubscribe non supporté Helius ``` Le runtime partagé possède déjà les mécanismes de bornage : `max_message_size_bytes`, `max_frame_size_bytes`, queues de notifications bornées, reconnect fini, remapping remote/local et isolation de logical subscription. Le travail `pre.008` porte donc principalement sur des canaris adversariaux Helius et sur un défaut de diagnostic identifié pendant la revue : les notifications Helius publiques dérivaient encore `Debug` sur leur payload brut. Décisions `pre.008` : ```text 1. HeliusFullTransactionNotification::Debug - transaction brute omise - signature omise - slot/index seulement conservés comme métadonnées sûres 2. HeliusTransactionSignatureNotification::Debug - signature/memo/err/confirmation value omis - états omitted/null/value seulement pour les champs wire optionnels 3. HeliusTransactionNotification::Unknown - payload serde_json::Value toujours accessible via la variante - Debug rend uniquement 4. provider JSON-RPC application error - ERROR_CODE_RPC_APPLICATION_ERROR - rpc_code + method sûrs seulement - message/data arbitraires provider absents du KspError - session physique reste Active et accepte une subscription saine ensuite 5. notification method mismatch - remote ID Helius lié à transactionNotification recevant une autre méthode - seule la logical transaction subscription échoue - cleanup transactionUnsubscribe best-effort - autre subscription saine et session physique restent actives 6. oversized provider payload - max frame/message partagé appliqué avant JSON provider - reconnect borné du même actor - connexion de remplacement reste utilisable 7. capability inverse - Helius garde compile-fail block/slotsUpdates/vote - SolanaStandard ajoute compile-fail transactionSubscribe ``` Aucune nouvelle dépendance, aucun nouveau socket/actor, aucune extension Config, aucune lecture d'environnement Transport. Les garanties `pre.006` de queue overflow transaction + root restent la preuve provider-specific de backpressure ciblée ; `pre.008` ne duplique pas ce test inutilement. Gate attendu après application : ```text Transport unit 335 Transport public API 40 release completeness 30 Transport doctests 5 workspace vert warnings 0 ``` `pre.009` reste bloqué jusqu'au replay intégralement vert de `pre.008`. ## 21. Fermeture `pre.008` et préparation `pre.009` Checkpoint opérateur `0.2.8-pre.8` reçu le 2026-08-23 : ```text [x] cargo fmt --all [x] python3 scripts/audit_rust_workspace_rules.py = clean / 0 candidate [x] cargo check --workspace = vert, sans warning [x] cargo clippy --workspace --all-targets = vert, sans warning [x] Transport unit = 335/335 [x] Transport public API = 40/40 [x] release completeness = 30/30 [x] Transport doctests = 5/5 [x] cargo test --workspace = vert ``` Verdict : **`pre.008` DONE.** Le réaudit final de conformité Helius révèle une évolution normative depuis `pre.001`. L'overview LaserStream WebSocket courant affirme désormais le support du jeu complet des méthodes standard. Les pages spécifiques permettent de résoudre la divergence sans extrapolation : ```text blockSubscribe page spécifique = explicitement non supporté Helius voteSubscribe page spécifique = explicitement non supporté Helius slotsUpdatesSubscribe page spécifique = unstable, documenté sur endpoints Helius, sans interdiction provider slotsUpdatesUnsubscribe = documenté avec subscriptionId + bool ``` Décision `pre.009` : ```text Helius standard actuel retenu = account/logs/program/root/signature/slot/slotsUpdates Helius extension = transaction Helius absent = block/vote SolanaStandard = 9 familles / 18 opérations inchangées HTTP = 52 current + 14 historical inchangés ``` La tranche ajoute uniquement la façade Helius `slots_updates_subscribe()` en réutilisant `WsSubscriptionKind::SlotsUpdates`, `SolanaSlotUpdate`, le triplet wire standard et le lifecycle actor déjà existant. Elle retire le compile-fail Helius correspondant, conserve ceux de block/vote et garde le compile-fail inverse `SolanaStandard -X-> transactionSubscribe`. Canaris de fermeture prévus : ```text Transport unit 335 Transport public API 41 release completeness 33 Transport doctests 4 workspace vert warnings 0 ``` Les trois nouveaux canaris `release_completeness` verrouillent : ```text 1. HTTP 52/14 + Standard WebSocket 9 familles / 18 méthodes ; 2. Helius = 7 familles standard + transaction, avec block/vote toujours absents ; 3. Config -> Transport, KSP_SECRET_HELIUS_API_KEY et dependency firewall sans reverse dependency. ``` Aucune nouvelle dépendance, aucun nouveau DTO Helius pour `slotsUpdates`, aucun second socket/actor et aucune modification Config ne sont nécessaires. Le point « enhanced accountSubscribe » reste reporté : l'overview parle de filtres avancés, mais la page API spécifique ne publie toujours pas de wire provider-specific supplémentaire assez précis pour une API typed ; KSP ne devine donc aucun champ. `pre.010` reste réservé au smoke Helius live opt-in si une stratégie credential-safe est disponible, à README/USAGE et au `cargo tree` final. ## 22. Fermeture `pre.009` et préparation `pre.010` Checkpoint opérateur `0.2.8-pre.9` reçu le 2026-08-23 : ```text [x] cargo fmt --all [x] python3 scripts/audit_rust_workspace_rules.py = clean / 0 candidate [x] cargo check --workspace = vert, sans warning [x] cargo clippy --workspace --all-targets = vert, sans warning [x] Transport unit = 335/335 [x] Transport public API = 41/41 [x] release completeness = 33/33 [x] Transport doctests = 4/4 [x] cargo test --workspace = vert ``` Verdict : **`pre.009` DONE.** Le réaudit Helius courant confirme les endpoints unifiés `wss://mainnet.helius-rpc.com/?api-key=...` et `wss://devnet.helius-rpc.com/?api-key=...`, le heartbeat recommandé par Ping chaque minute, `slotSubscribe` sur ces endpoints et `transactionSubscribe` comme extension Helius. La stratégie de smoke durable est néanmoins contrainte par l’architecture KSP : ```text Transport -X-> Config / environnement Config ne doit pas devenir la destination générale des futurs smokes cross-crates KSP_SECRET_HELIUS_API_KEY appartient exclusivement à Config ``` Décision `pre.010` : **aucun nouveau smoke Helius live committé dans Transport ou Config**. La future surface KSP d’intégration/orchestration dédiée devra porter le scénario `Config helius_devnet -> HeliusLaserStreamWsSession -> slotSubscribe -> notification -> unsubscribe -> close`. `transactionSubscribe` pourra rester un smoke opt-in supplémentaire dépendant des droits provider, jamais un gate réseau stable. Livraison `pre.010` : ```text - README Transport synchronisé avec la surface Helius finale 7 standard + transaction - USAGE Transport documente Config -> façade Helius, heartbeat et limites d’ownership - release completeness verrouille l’absence de lecture secret/env dans le smoke Transport - aucun nouveau test Helius live dans Config - aucune nouvelle dépendance - cargo tree final requis de l’opérateur ``` Gate attendu : ```text Transport unit 335 Transport public API 41 release completeness 34 Transport doctests 4 workspace vert warnings 0 ``` Audit graphe à joindre au checkpoint opérateur : ```bash cargo tree -p ksp-onchain-transport-lib cargo tree -p ksp-onchain-transport-lib --duplicates cargo tree --duplicates ``` `pre.011` reste bloqué jusqu’au gate complet et à l’inspection de ces graphes. ## 23. Fermeture `pre.010` et préparation `pre.011` ### 23.1 Gate opérateur `0.2.8-pre.10` Le checkpoint opérateur du 23 août 2026 est intégralement vert : ```text [x] cargo fmt --all [x] python3 scripts/audit_rust_workspace_rules.py General Rust rule audit: clean Rust export completeness audit: 0 candidate(s) KSP workspace Rust rule audit: clean [x] cargo check --workspace [x] cargo clippy --workspace --all-targets [x] Transport unit = 335/335 [x] Transport public API = 41/41 [x] release completeness = 34/34 [x] Transport doctests = 4/4 [x] cargo test --workspace [x] cargo tree -p ksp-onchain-transport-lib [x] cargo tree -p ksp-onchain-transport-lib --duplicates [x] cargo tree --duplicates ``` Le graphe Transport direct reste centré sur les dépendances déjà acquises (`futures-util`, `reqwest`, `serde`, `serde_json`, `tokio`, `tokio-tungstenite`, Core et Logging). Aucun SDK Helius/gRPC ni dépendance Config inverse n'apparaît. Doublons ciblés Transport observés : ```text syn 2.x / 3.x webpki-roots 0.26.x / 1.x ``` Ils sont transitifs et non bloquants. Le graphe workspace complet expose d'autres duplications transitives provenant principalement de Tauri/GTK, JSON Schema et des stacks crypto Wallet/Solana ; aucune dérive nouvelle propre à `0.2.8` n'est identifiée. Verdict : **`pre.010` DONE.** ### 23.2 Clôture documentaire `pre.011` `pre.011` ne doit ajouter aucune capacité runtime Helius. Sa mission est : ```text workspace.package.version = 0.2.8-pre.11 fermer le plan et la matrice au niveau candidate synchroniser les index documentaires devenus obsolètes créer prompts/014-V0_2_9_START_PROMPT.md conserver ROADMAP/CHANGELOG pour la publication stable rel.001 rejouer le gate workspace final ``` Le prompt `0.2.9` est construit conformément à `docs/rules/PROMPT_STRUCTURE.md` et comparé aux prompts `0.2.5`–`0.2.8`. Il conserve notamment : ```text base stable exacte et archive opérateur autoritaire ordre de lecture interne obligatoire sources externes Yellowstone à réauditer état HTTP/WS/Helius à préserver frontières Config/Transport/provider-neutral questions ouvertes dependencies/proto/licence/lifecycle première mission pre.001 audit/brainstorming/sizing obligatoire prévision souple initiale détaillée et recalibrable workflow version/delta/commit/archive/tag validation Rust/cargo tree/smoke critères de clôture instruction d'ouverture interdisant le client lourd avant gate ``` Le réaudit préparatoire Yellowstone du 23 août 2026 confirme que l'upstream évolue rapidement (`Subscribe`, unary RPCs, replay, filtres enrichis et extensions deshred). Le prompt n'en fait aucun pin : il impose à `0.2.9-pre.001` de réauditer release, proto, crates, MSRV, features et licences avant de choisir les dépendances. Critères `pre.011` : ```text [x] workspace.package.version = 0.2.8-pre.11 [x] aucun code runtime Helius modifié [x] aucune nouvelle dépendance [x] prompt 0.2.9 autonome présent [x] prompt suit les 16 rubriques normatives de PROMPT_STRUCTURE [x] forecast 0.2.9 visible, détaillé et explicitement souple [x] prompt impose audit licence/dependencies avant Yellowstone/Tonic/Prost [x] prompt distingue Yellowstone standard des providers et de deshred/pré-exécution [x] docs/000, plans/000, validation/000, prompts/000 et séquence fonctionnelle synchronisés [x] ROADMAP non marqué stable avant rel.001 [x] CHANGELOG non utilisé comme journal de prerelease [x] cargo fmt --all [x] audit Rust workspace clean [x] cargo check --workspace sans warning [x] cargo clippy --workspace --all-targets sans warning [x] cargo test -p ksp-onchain-transport-lib [x] cargo test --workspace ``` Si ce gate est vert, la prochaine livraison est `0.2.8-rel.001`; aucune `pre.012` n'est nécessaire sauf défaut réel. ## 24. Candidate `pre.011` validée et publication stable `rel.001` Le checkpoint opérateur du 23 août 2026 ferme la candidate : ```text [x] cargo fmt --all [x] python3 scripts/audit_rust_workspace_rules.py General Rust rule audit: clean Rust export completeness audit: 0 candidate(s) KSP workspace Rust rule audit: clean [x] cargo check --workspace [x] cargo clippy --workspace --all-targets [x] Transport unit = 335/335 [x] Transport public API = 41/41 [x] release completeness = 34/34 [x] Transport doctests = 4/4 [x] cargo test --workspace ``` Les `cargo tree` finaux ont déjà été exécutés et enregistrés en `pre.010`; `pre.011` n’a modifié aucune dépendance. Aucun fichier sous `crates/` n’a été modifié par la candidate documentaire. Verdict : **`pre.011` DONE ; aucune `pre.012` nécessaire.** `0.2.8-rel.001` publie ensuite la surface candidate sans nouvelle capacité runtime : ```text workspace.package.version = 0.2.8 Helius WS = Stable HTTP = 52 current + 14 historical Solana Standard WS = 9 familles / 18 opérations Helius = 7 familles standard + transaction block/vote Helius = absents heartbeat = Ping control frame / 60 s / Helius only Config = V2 helius_laserstream + secret redacted smoke live provider = reporté vers intégration/orchestration prochain prompt = prompts/014-V0_2_9_START_PROMPT.md ``` La publication stable ne change ni source Rust, ni Config runtime, ni dépendance. `ROADMAP.md`, `CHANGELOG.md`, les index et l’inventaire composants sont synchronisés uniquement au niveau stable.