khadhroony-solana-project/deltas/0.2.2/rel.001.md

Delta v0.2.2-rel.001

Base

Base attendue :

v0.2.2-pre.007-fix.002

Version Cargo cible :

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 :

Accounts : 5
Tokens   : 5
Cluster  : 12

Avec les quatre wrappers foundation de 0.2.1, la surface typée HTTP atteint :

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 :

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

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 :

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 :

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 :

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 :

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 :

v0.2.2-rel.001

Le tag stable ne doit être créé qu'après application et validation de ce delta :

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 :

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.