v0.2.1-pre.002

docs/plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # `0.2.1-pre.001` — plan `ksp-onchain-transport-lib` HTTP Solana foundation
 
@@ -696,18 +696,17 @@ Audit du 2026-08-17 :
 - `serde` / `serde_json` sont déjà des dépendances workspace `^1.0` ;
 - bot3 utilisait également `base64` et `bs58`, à différer jusqu'au premier besoin d'encoding explicite.
 
-Décision de principe pour `pre.002` :
+Décision concrétisée par `pre.002` :
 
 ```text
-reqwest = ^0.13, features minimales async/json/TLS à revérifier dans le manifest officiel avant ajout
+reqwest = ^0.13, default-features = false au workspace
 serde.workspace = true
 serde_json.workspace = true
-tokio.workspace = true (+ feature sync si Semaphore retenu)
 ksp-core-lib path/workspace
 ksp-logging-lib path/workspace
 ```
 
-`reqwest` `0.13` utilise un backend TLS rustls par défaut dans la génération actuelle ; la sélection exacte `default-features`/features doit être lue depuis le manifest/docs de la version réellement ajoutée, puis justifiée dans le delta.
+`pre.002` utilise `reqwest` uniquement pour le parsing/validation robuste de `HttpEndpointUrl`; aucune requête réseau n'est encore créée. Conformément à `RUST-DEP-001` / `RUST-DEP-003`, aucune feature TLS/JSON/client ni dépendance Tokio locale n'est activée par anticipation. Les features réellement nécessaires au client async sont décidées et ajoutées dans `pre.003`, lorsque le chemin de compilation HTTP existe. Le même principe reporte `tokio` à la première tranche qui utilise effectivement ses primitives runtime/sync.
 
 Ne pas ajouter :
 
@@ -859,7 +858,7 @@ La release peut devenir stable seulement si :
 | Tranche   | Objectif                                                                                                             |
 |-----------|----------------------------------------------------------------------------------------------------------------------|
 | `pre.001` | audit KSP + bot3 + docs officielles, matrice 52+14, architecture, split et sizing                                    |
-| `pre.002` | crate/workspace, codes erreur, settings/validation, JSON-RPC, descriptors/status, base Logging                       |
+| `pre.002` | **réalisé** : crate/workspace, codes erreur, settings/validation, JSON-RPC, descriptors/status, base Logging         |
 | `pre.003` | endpoint client + pool logique + rôles/capabilities + priorité/fairness/fallback + snapshots sûrs                    |
 | `pre.004` | RPS/burst/concurrence/cooldown + timeout + retry/backoff + classification retry/no-resend                            |
 | `pre.005` | méthodes canari `getHealth`, `getVersion`, `getGenesisHash`, `getBalance` + fixtures déterministes                   |
@@ -868,6 +867,23 @@ La release peut devenir stable seulement si :
 
 Ce découpage est révisable si une tranche dépasse le budget ; la release réduite, contrairement au scope initial, reste raisonnablement clôturable dans la session.
 
+### 22.1 État après `0.2.1-pre.002`
+
+`pre.002` matérialise la fondation sans ouvrir le client/pool de `pre.003` :
+
+- nouvelle crate `ksp-onchain-transport-lib`, membre du workspace, `workspace.package.version = 0.2.1-pre.2` ;
+- dépendances directes : `ksp-core-lib`, `ksp-logging-lib`, `serde`, `serde_json`, `reqwest` sans features par défaut ; aucune dépendance Config/Store/Program/`tracing` directe ;
+- settings runtime publics : URL redacted, provider/cluster/role/request-kind ouverts, endpoints/rôles/limites/retry et validation structurelle ;
+- douze codes d'erreur `onchain_transport` réservés/stabilisés selon la stratégie du §14 ;
+- JSON-RPC HTTP KSP : request numérique KSP, sérialisation, parse success/error, validation `jsonrpc = 2.0`, id exact et exclusivité `result`/`error`, avec `null` résultat préservé ;
+- `Debug` des requests/réponses n'expose pas les params, résultats ou payloads d'erreur distants par défaut ;
+- registre central exact de 52 méthodes current + 14 historiques, avec catégorie, request kind, statut documentaire/runtime, forme legacy, operation kind, retry class, remplacement et release de couverture ;
+- `getTransaction` et `getBlock` portent explicitement `StableWithDeprecatedLegacy`; `sendTransaction` et `requestAirdrop` portent `WriteSubmission / NeverAfterDispatch`;
+- contrôle central `ensure_runtime_supported()` : warning KSP pour surfaces non stables supportées, warning + `method_removed` pour les historiques supprimées ;
+- 40 tests Rust ajoutés (unitaires + intégration), dont redaction, invariants JSON-RPC, matrice 4/22/11/15 et canary de firewall du manifest.
+
+Les éléments suivants restent volontairement à `pre.003+` : construction `reqwest::Client`, clients logiques, pool, sélection/rôles/fallback, Tokio runtime/sync, TLS, rate limiting, concurrence et retry effectif.
+
 ## 23. Séquence `0.2.x` recalibrée
 
 ```text