# Validation finale `0.2.2` — HTTP Accounts + Tokens + Cluster ## Statut Cette matrice clôt la release stable `0.2.2`. Les preuves opérateur finales ont été enregistrées sur la candidate corrigée `0.2.2-pre.007-fix.002` avant `0.2.2-rel.001`. Base fonctionnelle validée avant `pre.007` : ```text v0.2.2-pre.006-fix.001 ``` L'opérateur a validé cette base le 2026-08-18 avec : ```bash cargo fmt --all cargo check --workspace cargo clippy --workspace --all-targets cargo test -p ksp-onchain-transport-lib ``` Résultats Transport communiqués : ```text 127 unit tests passed 13 public API tests passed 6 release completeness passed 0 warning clippy signalé ``` ## Réaudit officiel final Le 2026-08-18, l'index officiel courant a été revérifié : ```text https://solana.com/docs/rpc/http https://solana.com/docs/rpc/deprecated/confirmtransaction ``` La matrice reste : ```text 52 méthodes HTTP courantes 14 méthodes historiques Deprecated ``` Répartition courante utile à cette release : ```text Accounts : 6 = getBalance acquis en 0.2.1 + 5 en 0.2.2 Tokens : 5 = 5 en 0.2.2 Cluster : 15 = getGenesisHash/getHealth/getVersion acquis en 0.2.1 + 12 en 0.2.2 ``` Aucune méthode `0.2.2` n'est reclassée Deprecated/Unstable. Les 22 descriptors restent `Stable / Supported / Read / RetrySafe`. ## Surface typée stable `0.2.2` ajoute exactement : ```text Accounts : 5 Tokens : 5 Cluster : 12 Total : 22 ``` Avec les quatre canaris de `0.2.1`, Transport expose donc 26 wrappers typed dans la release stable. Les partitions futures restent intactes : ```text 0.2.3 Transactions : 11 0.2.4 Blocks + Economics : 15 ``` L'API raw `execute_standard_rpc()` reste disponible mais ne compte pas comme couverture typed d'une méthode future. ## Contrats wire à préserver La release stable conserve notamment : - `Account.data` legacy / encoded / `jsonParsed` sans décodage Program ; - `Account.space: Option` ; - comptes absents sous `null` ; - `getProgramAccounts` bare vs contextualisé ; - `TokenAmount.amount` et `uiAmountString` comme chaînes exactes ; - `TokenAmount.uiAmount: Option` ; - selector Token exclusif `Mint | ProgramId` ; - `ClusterNode.clientId: Option` ; - `EpochInfo.transactionCount: Option` ; - `SnapshotSlotInfo.incremental: Option` ; - `getLeaderSchedule -> Option` ; - `VoteAccountInfo.inflationRewardsCommissionBps: Option` ; - triplets `epochCredits` sans interprétation métier. Limites locales figées : ```text getMultipleAccounts <= 100 getProgramAccounts <= 4 filtres memcmp raw <= 128 octets getSlotLeaders 1..=5000 ``` ## Canaries de complétude `tests/release_completeness.rs` protège : ```text current == 52 historical == 14 partition == 4 / 22 / 11 / 15 0.2.1 exact == 4 canaris foundation 0.2.2 exact == 22 Accounts/Tokens/Cluster 0.2.3 count == 11 sans avancement typed prématuré 0.2.4 count == 15 sans avancement typed prématuré historical => Deprecated + Removed + Historical + NotApplicable ``` La suite stable confirmée est : ```text 127 unit tests 13 public API tests 7 release completeness tests 1 smoke Transport live ignored par défaut ``` ## Smoke Devnet Transport pur Nouveau test : ```text crates/ksp-onchain-transport-lib/tests/transport_devnet_smoke.rs ``` Il construit `HttpTransportSettings` programmatiquement, sans Config ni environnement : ```text https://api.devnet.solana.com -> getAccountInfo(System Program) -> getTokenAccountsByOwner(owner ordinaire documenté, selector programId = SPL Token, finalized/jsonParsed) -> getEpochInfo -> getVoteAccounts ``` Exécution explicite : ```bash cargo test -p ksp-onchain-transport-lib --test transport_devnet_smoke -- --ignored --nocapture ``` Le test est `ignored` par défaut. Sa branche Token ne dépend plus d'un mint d'exemple : elle utilise un owner Pubkey ordinaire de l'exemple RPC public, le selector `programId` canonique et une config explicite `finalized/jsonParsed`. Elle accepte naturellement une liste vide et vérifie seulement qu'un appel Token structurellement documenté atteint Devnet. Un incident réseau/rate-limit doit être analysé séparément ; le smoke ne remplace jamais les fixtures HTTP locales. Correction `pre.007-fix.001` : lors de la première passe opérateur de `pre.007`, `getTokenSupply` sur le mint d'exemple de la documentation a échoué avec le code RPC `-32602`. Le smoke Config -> Transport, lui, a réussi. La branche Token est donc volontairement passée à `getTokenAccountsByOwner` avec selector `programId`, qui ne requiert aucun mint mutable pour prouver la traversée live du wrapper Token. Correction `pre.007-fix.002` : lors de la passe suivante, `getTokenAccountsByOwner(System Program, { programId })` sans config explicite a échoué avec RPC `-32600`, tandis que `fmt`, `check`, `clippy`, les tests Transport, le workspace et le smoke Config -> Transport étaient verts. Le smoke Transport utilise désormais la forme complète documentée `owner ordinaire + { programId } + { commitment: finalized, encoding: jsonParsed }`. Ce changement reste limité au scénario live et ne redéfinit pas l'optionalité de la config dans le wrapper. ## Smoke de composition Config -> Transport Le smoke historique `0.2.1` reste disponible : ```bash cargo test -p ksp-config-lib --test transport_devnet_smoke -- --ignored --nocapture ``` Il valide `Config -> profil devnet_public -> Transport -> quatre canaris foundation`. Ownership : ce smoke cross-crates est transitoire. `ksp-config-lib` ne doit pas devenir la destination générale des smokes `Config + autre crate`; il migrera vers une future surface d'intégration/orchestration/demo appropriée. ## Dépendances, sécurité et logging La release stable n'introduit : ```text aucune dépendance externe nouvelle aucune dépendance Transport -> Config/Store/Program aucun tracing direct hors ksp-logging-lib aucun client HTTP parallèle ``` Les invariants de sécurité `0.2.1` restent obligatoires : URL/provider credentials absents des diagnostics ordinaires, `reqwest::Error::without_url()` avant exposition comme source, aucune réponse/body massif journalisé par défaut. La baseline Logging Transport reste `info` dans la publication stable. ## Documentation stable Sont synchronisés : ```text crates/ksp-onchain-transport-lib/README.md crates/ksp-onchain-transport-lib/USAGE.md docs/architecture/004-COMPONENT_INVENTORY.md docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md docs/plans/009-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER_PLAN.md ROADMAP.md prompts/008-V0_2_3_START_PROMPT.md ``` `0.2.2-rel.001` ajoute l'entrée stable au `CHANGELOG.md` sans modifier la surface fonctionnelle. ## Validations finales opérateur observées Sur `0.2.2-pre.007-fix.002`, l'opérateur a exécuté le 2026-08-18 : ```bash cargo fmt --all cargo check --workspace cargo clippy --workspace --all-targets cargo test -p ksp-onchain-transport-lib cargo test --workspace cargo test -p ksp-onchain-transport-lib --test transport_devnet_smoke -- --ignored --nocapture cargo test -p ksp-config-lib --test transport_devnet_smoke -- --ignored --nocapture ``` Résultats : ```text fmt/check/clippy : succès, aucun warning Clippy Transport unit : 127 passed Transport public : 13 passed release canaries : 7 passed workspace : succès Transport smoke : 1 passed; 0 failed Config smoke : 1 passed; 0 failed ``` Les suites normales conservent les smokes réseau sous `#[ignore]`; leur exécution explicite ci-dessus constitue la preuve live de clôture. Les graphes suivants ont été inspectés pendant la candidate : ```bash cargo tree -p ksp-onchain-transport-lib cargo tree -p ksp-onchain-transport-lib -d cargo tree -p ksp-onchain-transport-lib -e features cargo tree -p ksp-onchain-transport-lib -e normal cargo tree -p ksp-config-lib cargo tree -p ksp-config-lib -d cargo tree -p ksp-config-lib -e features cargo tree -p ksp-config-lib -e normal ``` Les fixes `pre.007-fix.001` et `pre.007-fix.002` n'ajoutent ni dépendance ni feature. Le graphe reste conforme au firewall : Config peut dépendre de Transport, Transport ne dépend pas de Config/Store/Program et n'importe pas `tracing` directement. Les doublons constatés sur les graphes inspectés restent ceux de `syn` 2.x/3.x dans les chaînes transitive/proc-macro ; aucune stack HTTP/Tokio KSP concurrente n'est introduite. ## Publication `rel.001` `0.2.2-rel.001` reste strictement publicationnelle : ```text workspace.package.version -> 0.2.2 ROADMAP : 0.2.2 -> [X] CHANGELOG : synthèse stable 0.2.2 plan 009 / validation 004 : clôturés avec preuves opérateur deltas/0.2.2/rel.001.md commit v0.2.2-rel.001 tag stable v0.2.2 après validation du commit ``` Aucune nouvelle méthode HTTP, aucun nouveau DTO et aucun nouveau comportement runtime n'apparaissent dans `rel.001`.