# Delta `v0.2.2-rel.001` ## Base Base attendue : ```text v0.2.2-pre.007-fix.002 ``` Version Cargo cible : ```text 0.2.2 ``` La candidate corrigée a été validée localement par l'opérateur le 2026-08-18 avec `cargo fmt --all`, `cargo check --workspace`, `cargo clippy --workspace --all-targets`, `cargo test -p ksp-onchain-transport-lib`, `cargo test --workspace` et les deux smokes Devnet opt-in. ## Objectif Publier `0.2.2 — HTTP Accounts + Tokens + Cluster` sans ajouter de capacité fonctionnelle après `pre.007-fix.002`. `rel.001` est strictement publicationnelle : - passage du workspace à la version stable `0.2.2` ; - clôture `[X]` de `0.2.2` dans le ROADMAP ; - ajout de l'entrée stable `0.2.2` au CHANGELOG ; - clôture du plan `009` et de la matrice `validation/004` avec les preuves opérateur ; - synchronisation des index, de l'inventaire composant et des README/USAGE Transport vers le statut stable ; - conservation du prompt `prompts/008-V0_2_3_START_PROMPT.md` comme point d'ouverture de `0.2.3`. Aucun fichier Rust de production, aucune API publique, aucune configuration runtime, aucune dépendance et aucune feature Cargo ne changent dans cette livraison. ## Surface stable publiée `0.2.2` ajoute exactement 22 wrappers typés : ```text Accounts : 5 Tokens : 5 Cluster : 12 ``` Avec les quatre wrappers foundation de `0.2.1`, la surface typée HTTP atteint : ```text 26 wrappers typed 52 méthodes HTTP courantes enregistrées 14 méthodes historiques Deprecated / Removed partition restante : 11 Transactions + 15 Blocks/Economics ``` Les 22 descriptors `0.2.2` restent `Read / RetrySafe` et utilisent tous le flux central `descriptor -> execute_standard_rpc -> pool/admission -> executor HTTP`. Contrats stabilisés notamment : Account legacy/encoded/`jsonParsed`, comptes absents `null`, Program Accounts bare/contextualisés, Token selector `Mint | ProgramId`, `TokenAmount.uiAmount` nullable, `ClusterNode.clientId` optionnel, epoch/snapshot nullable, leader schedule nullable et Vote Accounts avec `inflationRewardsCommissionBps` optionnel. Limites locales publiées : ```text getMultipleAccounts <= 100 getProgramAccounts <= 4 filtres memcmp raw <= 128 octets getSlotLeaders 1..=5000 ``` ## Validation de la candidate La candidate `0.2.2-pre.007-fix.002` a confirmé : ```text cargo fmt --all OK cargo check --workspace OK cargo clippy --workspace --all-targets OK, sans warning cargo test -p ksp-onchain-transport-lib OK cargo test --workspace OK ``` Transport : ```text 127 unit 13 public API 7 release completeness 1 smoke live ignored par défaut ``` Les deux smokes ont ensuite été exécutés explicitement : ```text Transport pur : settings programmatiques -> Accounts/Tokens/Cluster 1 passed Config -> Transport -> foundation 1 passed ``` Le smoke Transport utilise `getAccountInfo`, `getTokenAccountsByOwner` sous sa forme Devnet documentée complète, `getEpochInfo` et `getVoteAccounts`. Il appartient à Transport parce qu'il construit ses settings programmatiquement. Le smoke Config -> Transport reste une exception transitoire cross-crates et doit migrer vers une future surface d'intégration/orchestration/demo lorsqu'elle existera. Les graphes Cargo Transport/Config ont été inspectés pendant la candidate. Les fixes du smoke n'ont ajouté ni dépendance ni feature. La frontière reste : ```text ksp-config-lib -> ksp-onchain-transport-lib ksp-onchain-transport-lib -X-> ksp-config-lib Transport -X-> Store/Program/tracing direct ``` Les doublons observés restent limités à `syn` 2.x/3.x dans les chaînes transitive/proc-macro ; aucune seconde stack HTTP/Tokio KSP n'est introduite. ## Documentation de clôture Mises à jour : ```text CHANGELOG.md ROADMAP.md crates/ksp-onchain-transport-lib/README.md crates/ksp-onchain-transport-lib/USAGE.md docs/000-README.md docs/architecture/004-COMPONENT_INVENTORY.md docs/plans/000-README.md docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md docs/plans/009-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER_PLAN.md docs/validation/000-README.md docs/validation/004-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER.md ``` Le prompt `prompts/008-V0_2_3_START_PROMPT.md` était déjà livré en `pre.007` et reste inchangé ; il attend comme base le tag stable `v0.2.2`. ## Commit et tag Identifiant de commit attendu : ```text v0.2.2-rel.001 ``` Le tag stable ne doit être créé qu'après application et validation de ce delta : ```text v0.2.2 ``` ## Validation finale après application Comme `rel.001` ne modifie aucun code de production et ne change que le signal de version et la documentation, la gate finale reste : ```bash cargo fmt --all cargo check --workspace cargo clippy --workspace --all-targets cargo test --workspace ``` Après succès : commit `v0.2.2-rel.001`, puis création du tag `v0.2.2`.