khadhroony-solana-project/docs/validation/004-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER.md

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 :

v0.2.2-pre.006-fix.001

L'opérateur a validé cette base le 2026-08-18 avec :

cargo fmt --all
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test -p ksp-onchain-transport-lib

Résultats Transport communiqués :

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é :

https://solana.com/docs/rpc/http
https://solana.com/docs/rpc/deprecated/confirmtransaction

La matrice reste :

52 méthodes HTTP courantes
14 méthodes historiques Deprecated

Répartition courante utile à cette release :

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 :

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 :

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<u64> ;
• comptes absents sous null ;
• getProgramAccounts bare vs contextualisé ;
• TokenAmount.amount et uiAmountString comme chaînes exactes ;
• TokenAmount.uiAmount: Option<f64> ;
• selector Token exclusif Mint | ProgramId ;
• ClusterNode.clientId: Option<String> ;
• EpochInfo.transactionCount: Option<u64> ;
• SnapshotSlotInfo.incremental: Option<u64> ;
• getLeaderSchedule -> Option<schedule> ;
• VoteAccountInfo.inflationRewardsCommissionBps: Option<u16> ;
• triplets epochCredits sans interprétation métier.

Limites locales figées :

getMultipleAccounts <= 100
getProgramAccounts  <= 4 filtres
memcmp raw          <= 128 octets
getSlotLeaders      1..=5000

Canaries de complétude

tests/release_completeness.rs protège :

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 :

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 :

crates/ksp-onchain-transport-lib/tests/transport_devnet_smoke.rs

Il construit HttpTransportSettings programmatiquement, sans Config ni environnement :

https://api.devnet.solana.com
  -> getAccountInfo(System Program)
  -> getTokenAccountsByOwner(owner ordinaire documenté, selector programId = SPL Token, finalized/jsonParsed)
  -> getEpochInfo
  -> getVoteAccounts

Exécution explicite :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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.