v0.2.9-pre.002-fix.001

docs/plans/016-V0_2_9_YELLOWSTONE_GRPC_PLAN.md

@@ -1,9 +1,9 @@
 <!-- file: docs/plans/016-V0_2_9_YELLOWSTONE_GRPC_PLAN.md -->
-<!-- version: 5 -->
+<!-- version: 6 -->
 
 # Plan `0.2.9` — moteur Yellowstone gRPC + standard Solana + PublicNode
 
-> **Statut : `0.2.9-pre.002` — première matérialisation N1 préparée : dépendances Yellowstone/Tonic minimales, settings runtime bornés, error mapping initial et channel Tonic lazy privé. Les gates Cargo restent à exécuter par l’opérateur avant commit. `0.2.9` reste bornée à un moteur client Yellowstone partagé, une façade Solana Yellowstone standard et une première intégration concrète PublicNode. Seuls OrbitFlare puis Helius LaserStream gRPC sont actuellement planifiés comme releases provider suivantes ; les autres providers restent en TODO/IDEAS sans numéro réservé. Chaque prerelease vise 15–20 minutes de travail effectif et la release complète doit rester clôturable dans une seule session de chat.**
+> **Statut : `0.2.9-pre.002-fix.001` — correctif technique du premier gate opérateur : le channel lazy est conservé comme état N1 de production, `prepare()` refuse proprement l’absence de runtime Tokio au lieu de laisser Tonic paniquer, et les canaries Clippy/runtime sont corrigés. Les gates Cargo doivent être réexécutés après ce fix avant commit. `0.2.9` reste bornée à un moteur client Yellowstone partagé, une façade Solana Yellowstone standard et une première intégration concrète PublicNode. Seuls OrbitFlare puis Helius LaserStream gRPC sont actuellement planifiés comme releases provider suivantes ; les autres providers restent en TODO/IDEAS sans numéro réservé. Chaque prerelease vise 15–20 minutes de travail effectif et la release complète doit rester clôturable dans une seule session de chat.**
 
 ## 1. Objet, base et état d'ouverture
 
@@ -549,6 +549,8 @@ futures-util                   dépendance existante inchangée
 
 Le choix est volontairement plus étroit que le forecast initial : `pre.002` matérialise les messages wire publiés et le channel HTTP/2 lazy, mais **pas encore le client RPC généré, TLS, metadata ou compression**. Les éventuelles features/dependencies supplémentaires doivent être justifiées par `pre.003` et vérifiées par `cargo tree`; elles ne sont pas activées par anticipation.
 
+Le premier gate opérateur de `pre.002` confirme l'alignement de versions utile : Tonic 0.14.6 réutilise `http` 1.5, `hyper` 1.11, `hyper-util` 0.1, `tower` 0.5 et `bytes` 1.12 déjà présents ; `yellowstone-grpc-proto` unifie `solana-pubkey` en 4.3.0. Les occurrences Prost 0.14.4 visibles dans `cargo tree --duplicates` correspondent aux contextes runtime/build de la même version, notamment `prost-build`/`tonic-prost-build`, et ne constituent pas une seconde génération de version à corriger.
+
 ### C. proto/génération KSP minimale bornée
 
 Avantage : contrôle maximum du code généré.
@@ -895,8 +897,8 @@ Prévision courante :
 pre.001  DONE — audit upstream/service/proto + providers gratuits + licences/deps + architecture + threat model + sizing
          budget : 15–20 min nominal ; preuve : plan + matrice + stratégie B + forecast recalibré
 
-pre.002  IMPLEMENTED — moteur Yellowstone : proto/dependencies + settings/errors + channel minimal
-         budget : 15–20 min ; preuve locale : audit statique KSP clean + redaction/API canaries ajoutés ; compile/tests/cargo tree = gate opérateur
+pre.002  FIX.001 CANDIDATE — moteur Yellowstone : proto/dependencies + settings/errors + channel minimal
+         budget : 15–20 min ; premier gate : fmt/audit/check PASS, Clippy/test ont révélé return implicite + runtime Tokio ; fix appliqué ; cargo tree inspecté
 
 pre.003  moteur Yellowstone : TLS/metadata générique + fixture locale + 7 unary RPCs
          budget : 15–20 min ; preuve : connect/TLS/timeouts/Status safe + wire unary exact