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

Delta v0.2.3-rel.001

Base

Base attendue :

v0.2.3-pre.009

Version Cargo cible :

0.2.3

La candidate pre.009 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, les tests ciblés Transport/Config/Core/Config Desk, cargo test --workspace, les quatre graphes Cargo pour Transport et Config, puis les deux smokes Devnet opt-in.

Objectif

Publier 0.2.3 — HTTP Transactions sans ajouter de capacité fonctionnelle après pre.009.

rel.001 est strictement publicationnelle :

• passage du workspace à la version stable 0.2.3 ;
• clôture [X] de 0.2.3 dans le ROADMAP ;
• ajout de l'entrée stable 0.2.3 au CHANGELOG ;
• clôture du plan 010 et de la matrice validation/006 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/009-V0_2_4_START_PROMPT.md comme point d'ouverture de 0.2.4.

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.3 ajoute exactement 11 wrappers Transactions :

8 Read            / RetrySafe
2 WriteSubmission / NeverAfterDispatch
1 Simulation      / RetrySafe

Avec 0.2.1 et 0.2.2, la surface HTTP typée atteint :

37 wrappers typés courants
52 méthodes HTTP courantes enregistrées
14 méthodes historiques Deprecated / Removed
15 méthodes Blocks/Economics restantes pour 0.2.4

Contrats stabilisés notamment : getFeeForMessage, latest blockhash, prioritization fees, pagination signatures, statuses positionnels, getTransaction moderne + bare encoding legacy deprecated, transaction/version/meta/index lossless, airdrop, soumission signée avec no-resend après dispatch ambigu et simulateTransaction complet.

KSP-TRANSPORT-007 est désormais une règle formelle : un wrapper RPC KSP doit couvrir les possibilités supportées retenues par l'audit — paramètres/options, overloads/formes legacy encore supportés, contraintes déterministes utiles et variantes de réponse pertinentes sans perte. Le réaudit pre.008 conclut les 37/37 wrappers conformes sans remédiation fonctionnelle.

Validation de la candidate

La candidate 0.2.3-pre.009 a confirmé :

cargo fmt --all                         OK
cargo check --workspace                 OK
cargo clippy --workspace --all-targets  OK
cargo test --workspace                  OK

Transport :

182 unit
19 public API
14 release completeness
1 smoke live ignored par défaut

Les tests ciblés Config/Core/Config Desk passent également. Les graphes cargo tree, cargo tree -d, cargo tree -e features et cargo tree -e normal ont été inspectés pour Transport et Config. 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 transitifs/proc-macro, notamment syn 2.x/3.x ; aucune seconde stack HTTP KSP n'est introduite.

Les deux smokes ont ensuite été exécutés explicitement :

Transport pur read-only : Accounts/Tokens/Cluster + trois reads Transactions  1 passed
Config -> Transport -> foundation                                          1 passed

Le smoke Config -> Transport reste une exception transitoire cross-crates et devra migrer vers une future surface d'intégration/orchestration/demo lorsqu'elle existera.

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/010-V0_2_3_HTTP_TRANSACTIONS_PLAN.md
docs/validation/000-README.md
docs/validation/006-V0_2_3_HTTP_TRANSACTIONS.md

La matrice rétroactive docs/validation/005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md, corrigée par l'opérateur avant pre.009, reste inchangée byte-for-byte. Le prompt prompts/009-V0_2_4_START_PROMPT.md reste également inchangé et attend la base stable v0.2.3.

Commit et tag

Identifiant de commit attendu :

v0.2.3-rel.001

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

v0.2.3

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.3-rel.001, puis création du tag v0.2.3. La prochaine session s'ouvre avec prompts/009-V0_2_4_START_PROMPT.md.