v0.2.4-pre.009

This commit is contained in:
2026-08-18 22:43:09 +02:00
parent 7e84522787
commit e6772c109d
18 changed files with 1891 additions and 49 deletions

View File

@@ -1,5 +1,5 @@
<!-- file: docs/000-README.md -->
<!-- version: 31 -->
<!-- version: 32 -->
# Documentation KSP
@@ -51,7 +51,8 @@ docs/
│ ├── 003-V0_2_1_ONCHAIN_HTTP.md
│ ├── 004-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER.md
│ ├── 005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md
── 006-V0_2_3_HTTP_TRANSACTIONS.md
── 006-V0_2_3_HTTP_TRANSACTIONS.md
│ └── 007-V0_2_4_HTTP_FINAL_COMPLIANCE.md
└── rules/
├── FILE_CONTRACTS.md
├── PROMPT_STRUCTURE.md
@@ -68,7 +69,7 @@ D'autres sous-répertoires seront ajoutés uniquement lorsque leur rôle aura é
## Documents de planification
Le plan historique de la phase fondatrice clôturée est conservé dans [`plans/001-V0_0_3_PLAN.md`](plans/001-V0_0_3_PLAN.md). La séquence active des premières releases fonctionnelles est définie dans [`plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`](plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md). Le plan détaillé de la release stable `0.1.1` est conservé comme historique clôturé dans [`plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md`](plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.2` est conservé comme historique clôturé dans [`plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md`](plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.3 — Configuration foundation` est conservé comme historique clôturé dans [`plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.4 — ksp-app-config-desk` est conservé comme historique clôturé dans [`plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md`](plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md), avec sa matrice finale [`validation/001-V0_1_4_CONFIG_DESKTOP.md`](validation/001-V0_1_4_CONFIG_DESKTOP.md). Son prompt d'ouverture historique reste [`../prompts/004-V0_1_4_START_PROMPT.md`](../prompts/004-V0_1_4_START_PROMPT.md). La release stable `0.2.0` clôt l'audit de bot3 et le découpage de la série. Son plan directeur est conservé comme historique clôturé dans [`plans/007-V0_2_0_SERIES_PLANNING.md`](plans/007-V0_2_0_SERIES_PLANNING.md), avec sa matrice finale [`validation/002-V0_2_0_SERIES_PLANNING.md`](validation/002-V0_2_0_SERIES_PLANNING.md). La release stable `0.2.1 — HTTP Solana foundation` a été ouverte par [`../prompts/006-V0_2_1_START_PROMPT.md`](../prompts/006-V0_2_1_START_PROMPT.md). Son gate de sizing et sa matrice exhaustive sont conservés dans [`plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md`](plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md), avec la validation finale [`validation/003-V0_2_1_ONCHAIN_HTTP.md`](validation/003-V0_2_1_ONCHAIN_HTTP.md), README/USAGE Transport et le smoke Devnet opt-in de composition Config -> Transport. Le prompt [`../prompts/007-V0_2_2_START_PROMPT.md`](../prompts/007-V0_2_2_START_PROMPT.md) a ouvert la release stable `0.2.2 — HTTP Accounts + Tokens + Cluster`. Son plan clôturé [`plans/009-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER_PLAN.md`](plans/009-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER_PLAN.md) conserve l'audit et l'implémentation des 22 wrappers typés, tandis que [`validation/004-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER.md`](validation/004-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER.md) enregistre les validations déterministes, les graphes Cargo et les deux smokes Devnet passés avant publication. Le prompt [`../prompts/008-V0_2_3_START_PROMPT.md`](../prompts/008-V0_2_3_START_PROMPT.md) a ouvert la release stable `0.2.3 — HTTP Transactions`. Son plan clôturé [`plans/010-V0_2_3_HTTP_TRANSACTIONS_PLAN.md`](plans/010-V0_2_3_HTTP_TRANSACTIONS_PLAN.md) conserve l'audit et l'implémentation des 11 wrappers ; le réaudit [`validation/005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md`](validation/005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md) confirme la complétude des 37 wrappers HTTP typés et [`validation/006-V0_2_3_HTTP_TRANSACTIONS.md`](validation/006-V0_2_3_HTTP_TRANSACTIONS.md) enregistre les validations finales, graphes Cargo et deux smokes Devnet passés avant publication. Le prompt [`../prompts/009-V0_2_4_START_PROMPT.md`](../prompts/009-V0_2_4_START_PROMPT.md) ouvre `0.2.4 — HTTP Blocks + Economics + compliance HTTP finale`. Son plan actif [`plans/011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md`](plans/011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md), établi par `0.2.4-pre.001`, fixe les 15 wrappers restants, la baseline Agave stable `v4.2.1`, le gate de sizing positif et la compliance finale `52/52 + 14/14`.
Le plan historique de la phase fondatrice clôturée est conservé dans [`plans/001-V0_0_3_PLAN.md`](plans/001-V0_0_3_PLAN.md). La séquence active des premières releases fonctionnelles est définie dans [`plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`](plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md). Le plan détaillé de la release stable `0.1.1` est conservé comme historique clôturé dans [`plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md`](plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.2` est conservé comme historique clôturé dans [`plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md`](plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.3 — Configuration foundation` est conservé comme historique clôturé dans [`plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.4 — ksp-app-config-desk` est conservé comme historique clôturé dans [`plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md`](plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md), avec sa matrice finale [`validation/001-V0_1_4_CONFIG_DESKTOP.md`](validation/001-V0_1_4_CONFIG_DESKTOP.md). Son prompt d'ouverture historique reste [`../prompts/004-V0_1_4_START_PROMPT.md`](../prompts/004-V0_1_4_START_PROMPT.md). La release stable `0.2.0` clôt l'audit de bot3 et le découpage de la série. Son plan directeur est conservé comme historique clôturé dans [`plans/007-V0_2_0_SERIES_PLANNING.md`](plans/007-V0_2_0_SERIES_PLANNING.md), avec sa matrice finale [`validation/002-V0_2_0_SERIES_PLANNING.md`](validation/002-V0_2_0_SERIES_PLANNING.md). La release stable `0.2.1 — HTTP Solana foundation` a été ouverte par [`../prompts/006-V0_2_1_START_PROMPT.md`](../prompts/006-V0_2_1_START_PROMPT.md). Son gate de sizing et sa matrice exhaustive sont conservés dans [`plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md`](plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md), avec la validation finale [`validation/003-V0_2_1_ONCHAIN_HTTP.md`](validation/003-V0_2_1_ONCHAIN_HTTP.md), README/USAGE Transport et le smoke Devnet opt-in de composition Config -> Transport. Le prompt [`../prompts/007-V0_2_2_START_PROMPT.md`](../prompts/007-V0_2_2_START_PROMPT.md) a ouvert la release stable `0.2.2 — HTTP Accounts + Tokens + Cluster`. Son plan clôturé [`plans/009-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER_PLAN.md`](plans/009-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER_PLAN.md) conserve l'audit et l'implémentation des 22 wrappers typés, tandis que [`validation/004-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER.md`](validation/004-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER.md) enregistre les validations déterministes, les graphes Cargo et les deux smokes Devnet passés avant publication. Le prompt [`../prompts/008-V0_2_3_START_PROMPT.md`](../prompts/008-V0_2_3_START_PROMPT.md) a ouvert la release stable `0.2.3 — HTTP Transactions`. Son plan clôturé [`plans/010-V0_2_3_HTTP_TRANSACTIONS_PLAN.md`](plans/010-V0_2_3_HTTP_TRANSACTIONS_PLAN.md) conserve l'audit et l'implémentation des 11 wrappers ; le réaudit [`validation/005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md`](validation/005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md) confirme la complétude des 37 wrappers HTTP typés et [`validation/006-V0_2_3_HTTP_TRANSACTIONS.md`](validation/006-V0_2_3_HTTP_TRANSACTIONS.md) enregistre les validations finales, graphes Cargo et deux smokes Devnet passés avant publication. Le prompt [`../prompts/009-V0_2_4_START_PROMPT.md`](../prompts/009-V0_2_4_START_PROMPT.md) ouvre `0.2.4 — HTTP Blocks + Economics + compliance HTTP finale`. Son plan [`plans/011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md`](plans/011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md), établi par `0.2.4-pre.001`, est amené en candidate par `pre.009` après implémentation des 15 wrappers et compliance `52/52 + 14/14`; la matrice [`validation/007-V0_2_4_HTTP_FINAL_COMPLIANCE.md`](validation/007-V0_2_4_HTTP_FINAL_COMPLIANCE.md) porte la preuve finale candidate. Le prompt [`../prompts/010-V0_2_5_START_PROMPT.md`](../prompts/010-V0_2_5_START_PROMPT.md) prépare `0.2.5 — Wallet foundation` après publication stable de `0.2.4`.
`IDEAS.md` conserve les pistes et questions qui ne sont pas encore des engagements du roadmap ni des décisions architecturales.

View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/004-COMPONENT_INVENTORY.md -->
<!-- version: 12 -->
<!-- version: 13 -->
# Inventaire initial des composants KSP
@@ -23,7 +23,7 @@ Ce document maintient l'inventaire synthétique des composants retenus ou presse
| Logging | `ksp-logging-lib` | lib | Stable | `0.1.2` | façade unique tracing KSP |
| Config | `ksp-config-lib` | lib | Stable | `0.1.3` | documents, profils, env et persistence Config |
| Config Desk | `ksp-app-config-desk` | app | Stable | `0.1.4` | validation/management Config |
| On-chain HTTP | `ksp-onchain-transport-lib` | lib | Stable | `0.2.1` | foundation HTTP + 37 wrappers typés stables après 0.2.3 |
| On-chain HTTP | `ksp-onchain-transport-lib` | lib | Stable | `0.2.1` | foundation stable + candidate HTTP typed 52/52 en 0.2.4 |
| Wallet | `ksp-wallet-lib` | lib | Retenu | `0.2.5` | `.kspwallet`, secrets, signature, import/export |
| Wallet Desk | `ksp-app-wallet-desk` | app | Retenu | `0.2.6` | Wallet + Config composite + HTTP/balance |
| Standard WS | `ksp-onchain-transport-lib` | lib | Retenu | `0.2.7` | WebSocket Solana complet, sessions/subscriptions |
@@ -78,7 +78,7 @@ ksp-data-api
## Transport
`ksp-onchain-transport-lib` doit couvrir l'intégralité des opérations documentées de la surface ciblée par chaque release. `0.2.1` stabilise la foundation HTTP et quatre wrappers typés canari. `0.2.2` stabilise 22 wrappers Accounts/Tokens/Cluster supplémentaires. `0.2.3` stabilise les 11 Transactions et porte la surface typed à 37 méthodes ; les 15 méthodes Blocks/Economics restent affectées à `0.2.4`, qui exécutera aussi la compliance finale de la surface 52 current + 14 historiques. Les statuts deprecated/obsolete encore fonctionnels et unstable/experimental restent exposés avec warning runtime KSP.
`ksp-onchain-transport-lib` doit couvrir l'intégralité des opérations documentées de la surface ciblée par chaque release. `0.2.1` stabilise la foundation HTTP et quatre wrappers typés canari, `0.2.2` ajoute 22 wrappers Accounts/Tokens/Cluster et `0.2.3` stabilise les 11 Transactions. La candidate `0.2.4-pre.009` ajoute les 10 Blocks + 5 Economics et atteint 52/52 méthodes HTTP courantes typées, avec 14/14 historiques Deprecated/Removed conservées pour compliance. Les statuts deprecated/obsolete encore fonctionnels et unstable/experimental restent exposés avec warning runtime KSP.
La Config standard Transport appartient à `ksp-config-lib`, qui adapte vers les settings publics du transport ; le transport ne dépend jamais de Config.

View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/000-README.md -->
<!-- version: 38 -->
<!-- version: 39 -->
# Plans KSP
@@ -19,7 +19,7 @@ Un plan décrit le périmètre, les décisions déjà acquises, les questions ou
- [`008-V0_2_1_ONCHAIN_HTTP_PLAN.md`](008-V0_2_1_ONCHAIN_HTTP_PLAN.md) — plan de `0.2.1`, établi par `0.2.1-pre.001`, recalibré par `pre.001-fix.001` et amené en clôture candidate par `pre.007`; il conserve l'inventaire 52 méthodes HTTP courantes + 14 Deprecated historiques, le design Transport/Config et le split de couverture typée sur `0.2.1``0.2.4`.
- [`009-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER_PLAN.md`](009-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER_PLAN.md) — plan clôturé de la release stable `0.2.2`, établi par `pre.001`, corrigé après réaudit Agave v4.2.1 puis exécuté jusqu'à `pre.007-fix.002`; il couvre les 22 wrappers Accounts/Tokens/Cluster, le smoke Transport opt-in et la préparation de `0.2.3`.
- [`010-V0_2_3_HTTP_TRANSACTIONS_PLAN.md`](010-V0_2_3_HTTP_TRANSACTIONS_PLAN.md) — plan historique clôturé de la release stable `0.2.3 — HTTP Transactions`, ouvert par `pre.001`, exécuté jusqu'à `pre.009` puis publié par `rel.001`; il couvre les 11 méthodes, la classification `8 Read / 2 WriteSubmission / 1 Simulation`, `KSP-TRANSPORT-007`, le no-resend et la préparation de `0.2.4`.
- [`011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md`](011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md) — plan actif de `0.2.4`, ouvert par `pre.001`; il fixe les 10 Blocks + 5 Economics, les overloads/legacy, les wires réutilisables, les limites runtime et la compliance finale `52/52 + 14/14` sous `KSP-TRANSPORT-007`.
- [`011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md`](011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md) — plan de `0.2.4`, ouvert par `pre.001` et amené en clôture candidate par `pre.009`; il couvre les 10 Blocks + 5 Economics, les overloads/legacy, les wires/runtime sensibles et la compliance finale `52/52 + 14/14` sous `KSP-TRANSPORT-007`.
Le `pre.001` de chaque release fonctionnelle peut introduire son propre plan détaillé lorsque la release s'ouvre.

View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
<!-- version: 40 -->
<!-- version: 41 -->
# Séquence des releases fonctionnelles KSP
@@ -394,7 +394,7 @@ Chaque `pre.001` réaudite la documentation officielle actuelle. Les méthodes D
`0.2.3-pre.001` réaudite le 2026-08-18 la catégorie Transactions contre la documentation Solana actuelle et Agave v4.2.1 : les 11 méthodes prévues restent exactes, la classification `8 Read / RetrySafe`, `2 WriteSubmission / NeverAfterDispatch` et `1 Simulation / RetrySafe` reste correcte, et le gate de sizing est positif. `pre.002``pre.007` livrent ensuite les primitives wire puis les 11 wrappers, `pre.008` réaudite rétroactivement `KSP-TRANSPORT-007` sur les 37 wrappers HTTP typés sans remédiation fonctionnelle, et `pre.009` prépare la candidate finale avec documentation, smoke Transport read-only étendu et prompt `0.2.4`. `0.2.3-rel.001` publie cette surface stable après validation du workspace, des graphes Cargo Transport/Config et des deux smokes Devnet. Aucun `base64`, `bs58`, `wincode` ni client RPC Solana supplémentaire n'est ajouté : les payloads sérialisés restent opaques dans Transport tant qu'un besoin de décodage local n'est pas démontré. Le plan détaillé clôturé est `docs/plans/010-V0_2_3_HTTP_TRANSACTIONS_PLAN.md`.
`0.2.4-pre.001` réaudite le même jour l'inventaire HTTP officiel et la baseline runtime actuelle : les 15 méthodes réservées restent exactement 10 Blocks + 5 Economics, la navigation Deprecated reste à 14 historiques et Agave stable `v4.2.1` confirme les overloads/limites/extensions sensibles (`getBlock` legacy, `getBlocks`, plafond 500_000, performance samples 720, `commissionBps`). Le gate de sizing est positif sans split de release. Le plan actif `docs/plans/011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md` prévoit des tranches dédiées à `getBlock`, `getBlockProduction`, `getInflationReward`, puis une compliance finale `52/52 current + 14/14 historical` sous `KSP-TRANSPORT-007` avant `0.2.5 — Wallet foundation`.
`0.2.4-pre.001` réaudite le même jour l'inventaire HTTP officiel et la baseline runtime actuelle : les 15 méthodes réservées restent exactement 10 Blocks + 5 Economics, la navigation Deprecated reste à 14 historiques et Agave stable `v4.2.1` confirme les overloads/limites/extensions sensibles (`getBlock` legacy, `getBlocks`, plafond 500_000, performance samples 720, `commissionBps`). Le gate de sizing est positif sans split de release. `pre.002``pre.008` livrent ensuite les DTOs/wires et les 15 wrappers ; `pre.008-fix.001` corrige uniquement la conformité Clippy. `pre.009` réaudite l'index officiel et les SIMDs HTTP sensibles, confirme l'égalité exacte des ensembles 52 current + 14 Deprecated avec le registre, ajoute les canaries de wrapper/compliance globales, étend le smoke Transport aux familles Blocks/Economics, synchronise la documentation et prépare `0.2.5 — Wallet foundation`. Le plan détaillé est `docs/plans/011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md`.
## `0.2.5` — Wallet foundation

View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md -->
<!-- version: 5 -->
<!-- version: 6 -->
# Plan `0.2.4` — HTTP Blocks + Economics + compliance HTTP finale
@@ -18,6 +18,8 @@ Ce plan ouvre `0.2.4` par `0.2.4-pre.001` sur la base stable attendue `v0.2.3`.
La mission de `0.2.4` est strictement de compléter les **10 Blocks + 5 Economics** déjà affectées à `V0_2_4`, puis de fermer la compliance HTTP globale **52/52 current + 14/14 historical** sous la règle `KSP-TRANSPORT-007`.
`0.2.4-pre.009` amène ce plan au statut **candidate de clôture** : les 15/15 wrappers `V0_2_4` sont implémentés, l'inventaire officiel final reste 52 current + 14 Deprecated, les deux ensembles correspondent exactement au registre KSP et la matrice durable de clôture est `docs/validation/007-V0_2_4_HTTP_FINAL_COMPLIANCE.md`. Le statut stable reste réservé à `rel.001`.
## Gate de sizing `pre.001`
Question obligatoire :
@@ -427,13 +429,65 @@ historical Deprecated/Removed == 14/14
KSP-TRANSPORT-007 audited current == 52/52
```
La compliance `KSP-TRANSPORT-007` des 37 wrappers de `0.2.1``0.2.3` reste acquise par `docs/validation/005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md`; la clôture `0.2.4` vérifie qu'aucune régression n'a été introduite et applique la même règle aux 15 nouveaux wrappers. Le réaudit final inclut explicitement l'état des SIMD susceptibles de modifier la surface HTTP ou sa sémantique observable, au minimum SIMD-0180, SIMD-0298, SIMD-0301, SIMD-0307, SIMD-0385, SIMD-0490, SIMD-0550 et SIMD-0553, afin qu'une évolution devenue stable pendant la session ne soit pas oubliée. Il réaudite aussi l'inventaire officiel lui-même afin de détecter d'éventuels nouveaux endpoints issus de SIMD-0180 ou d'une autre évolution d'interface.
La compliance `KSP-TRANSPORT-007` des 37 wrappers de `0.2.1``0.2.3` reste acquise par `docs/validation/005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md`; la clôture `0.2.4` vérifie qu'aucune régression n'a été introduite et applique la même règle aux 15 nouveaux wrappers. Le réaudit final inclut explicitement les extensions wire déjà acquises SIMD-0118 et SIMD-0291, puis l'état des SIMD susceptibles de modifier la surface HTTP ou sa sémantique observable, au minimum SIMD-0180, SIMD-0298, SIMD-0301, SIMD-0307, SIMD-0385, SIMD-0490, SIMD-0550 et SIMD-0553, afin qu'une évolution devenue stable pendant la session ne soit pas oubliée. Il réaudite aussi l'inventaire officiel lui-même afin de détecter d'éventuels nouveaux endpoints issus de SIMD-0180 ou d'une autre évolution d'interface.
## Réaudit final `pre.009`
Le réaudit du **18 août 2026** confirme l'index HTTP officiel actuel sans recalibrage :
```text
Solana current HTTP exact names == KSP current registry exact names == 52
Solana Deprecated exact names == KSP historical exact names == 14
missing == 0
extra == 0
```
La navigation officielle actuelle ne contient aucun nouvel endpoint HTTP issu de SIMD-0180.
État final de la watchlist prospective :
```text
SIMD-0180 Review
SIMD-0298 Idea
SIMD-0301 PR closed / unmerged
SIMD-0307 Review
SIMD-0385 Review
SIMD-0490 Review
SIMD-0550 Review
SIMD-0553 Draft
```
Extensions SIMD déjà matérialisées dans le wire stable et réauditées à la clôture :
```text
SIMD-0118 Activated -> numRewardPartitions préservé en omitted/null/value
SIMD-0291 Review -> commission et commissionBps préservés indépendamment
```
Le statut `Review` de SIMD-0291 ne retire pas le champ déjà exposé par Agave `v4.2.1` : `KSP-TRANSPORT-007` impose de conserver ce wire réellement livré. SIMD-0118 est `Activated` et confirme définitivement que `numRewardPartitions` fait partie des extensions de bloc à ne pas aplatir ni synthétiser.
Conséquences :
- aucun changement anticipé de `getLeaderSchedule` pour SIMD-0180 ;
- aucun `footer`, `bankHash` ou `parentBankHash` spéculatif dans `getBlock` ;
- `SolanaTransactionVersion::Number(u8)` reste générique ;
- minimum de délégation et inflation restent des valeurs runtime ;
- SIMD-0553 ne crée aucun nouveau contrat HTTP stable dans la baseline auditée.
La preuve typed finale est doublée :
```text
public API canary -> référence les 52 wrappers current + 2 wrappers legacy séparés
release canary -> fige noms exacts 52 + 14 et partition 4/22/11/15
```
La matrice complète est conservée dans `docs/validation/007-V0_2_4_HTTP_FINAL_COMPLIANCE.md`.
## Smokes live
Les smokes restent opt-in et secondaires par rapport aux fixtures locales.
Le smoke Transport pur peut être étendu uniquement avec quelques reads robustes, par exemple `getBlockHeight`, `getFirstAvailableBlock`, `minimumLedgerSlot`, `getInflationRate` ou `getStakeMinimumDelegation`. Éviter un `getBlock` dépendant d'un slot fixe ou tout scénario fragile lié à des récompenses d'un epoch précis.
`pre.009` étend le smoke Transport pur avec `getBlockHeight`, `getInflationRate` et `getStakeMinimumDelegation`. Ces reads restent robustes : aucun slot historique fixe, aucun compte reward spécifique et aucune valeur économique codée en dur. Éviter un `getBlock` dépendant d'un slot fixe ou tout scénario fragile lié à des récompenses d'un epoch précis.
Le smoke historique Config -> Transport reste une exception transitoire de composition et ne devient pas la destination générale des futurs scénarios cross-crates.
@@ -452,7 +506,7 @@ pre.006 réaudit SIMD-0298/0307 + getBlock moderne + bare encoding legacy + tra
pre.007 réaudit SIMD-0490/0550 + Economics simples : getInflationGovernor, getInflationRate,
getStakeMinimumDelegation, getSupply
pre.008 réaudit commitment runtime + getInflationReward + null positionnels + commissionBps SIMD-0291 + invariants
pre.009 réaudit SIMD HTTP (0180/0298/0301/0307/0385/0490/0550/0553 minimum)
pre.009 réaudit SIMD HTTP (0118/0180/0291/0298/0301/0307/0385/0490/0550/0553 minimum)
+ réaudit inventaire officiel + compliance finale 52/52 + 14/14
+ KSP-TRANSPORT-007 + docs + smokes + graphes + prompt 0.2.5 — Wallet foundation
rel.001 publication strictement publicationnelle
@@ -490,6 +544,6 @@ réécriture des deltas historiques
## Questions ouvertes
Aucune question bloquante pour `pre.002`.
Aucune question bloquante pour la candidate `pre.009`.
Les noms Rust exacts des DTOs peuvent encore être ajustés pendant l'implémentation. En revanche, les formes RPC, overloads, distinctions wire et limites fixées dans ce plan ne doivent pas être réduits pour simplifier l'API KSP.
Les choix fonctionnels et wire de `0.2.4` sont désormais figés pour cette release. Toute nouvelle évolution officielle détectée après cette candidate appartient à une release ultérieure, sauf défaut de conformité démontré nécessitant un fix avant publication.

View File

@@ -1,5 +1,5 @@
<!-- file: docs/validation/000-README.md -->
<!-- version: 9 -->
<!-- version: 10 -->
# Validations KSP
@@ -16,3 +16,4 @@ Documents :
- [`005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md`](005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md) — réaudit rétroactif de complétude `KSP-TRANSPORT-007` des 37 wrappers HTTP typés livrés de `0.2.1` à `0.2.3-pre.007`, avec preuves Solana/Agave et verdict méthode par méthode.
- [`006-V0_2_3_HTTP_TRANSACTIONS.md`](006-V0_2_3_HTTP_TRANSACTIONS.md) — matrice finale validée de `0.2.3`, 11 wrappers Transactions, sécurité write/simulation, réaudit 52+14, `KSP-TRANSPORT-007` 37/37, graphes Cargo et deux smokes Devnet passés avant publication stable.
- [`007-V0_2_4_HTTP_FINAL_COMPLIANCE.md`](007-V0_2_4_HTTP_FINAL_COMPLIANCE.md) — matrice candidate de clôture `0.2.4`, inventaire exact 52 current + 14 Deprecated, preuve typed 52/52, audit SIMD final, `KSP-TRANSPORT-007`, smokes et gates de graphes/publication.

View File

@@ -0,0 +1,429 @@
<!-- file: docs/validation/007-V0_2_4_HTTP_FINAL_COMPLIANCE.md -->
<!-- version: 1 -->
# Validation candidate `0.2.4` — HTTP Blocks + Economics + compliance finale
## Objet
Cette matrice porte la preuve de clôture candidate de `0.2.4 — HTTP Blocks + Economics + compliance HTTP finale`.
Elle complète les validations historiques :
- [`003-V0_2_1_ONCHAIN_HTTP.md`](003-V0_2_1_ONCHAIN_HTTP.md) — foundation HTTP et registre initial ;
- [`004-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER.md`](004-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER.md) — 22 wrappers Accounts/Tokens/Cluster ;
- [`005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md`](005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md) — réaudit `KSP-TRANSPORT-007` des 37 wrappers acquis avant `0.2.4` ;
- [`006-V0_2_3_HTTP_TRANSACTIONS.md`](006-V0_2_3_HTTP_TRANSACTIONS.md) — 11 wrappers Transactions et clôture stable `0.2.3`.
`0.2.4-pre.009` n'ajoute pas de nouvelle méthode RPC métier. Il agrège les preuves de complétude, étend le smoke live aux familles nouvellement livrées, synchronise la documentation et prépare `0.2.5`.
`0.2.4-rel.001` reste strictement publicationnelle après validation opérateur complète de cette candidate.
## Base opérateur validée
La base `0.2.4-pre.008-fix.001` a été validée le **18 août 2026** avec :
```text
cargo fmt --all OK
cargo check --workspace OK
cargo clippy --workspace --all-targets OK
Transport
240 unit passed
26 public API passed
21 release completeness passed
1 smoke live ignored par défaut
0 failure
```
Le fix ne modifie pas le contrat `getInflationReward`; il ajoute uniquement le `return` explicite exigé par la policy Clippy workspace.
## Réaudit officiel final — inventaire HTTP
Dernier contrôle effectué le **18 août 2026** contre l'index HTTP Solana courant :
```text
https://solana.com/docs/rpc/http
```
L'index contient toujours exactement **52 méthodes HTTP courantes**.
La navigation Deprecated officielle, visible depuis les pages sous :
```text
https://solana.com/docs/rpc/deprecated/
```
contient toujours exactement **14 méthodes historiques**.
Le rapprochement a été réalisé sur les **noms exacts**, pas uniquement sur les compteurs :
```text
official current names == KSP current registry names == 52/52
official deprecated names == KSP historical registry names == 14/14
missing == 0
extra == 0
```
Aucun nouvel endpoint HTTP issu de SIMD-0180 ou d'une autre évolution d'interface n'apparaît dans l'index officiel actuel.
## Baseline Agave et audit SIMD final
La baseline runtime conservée pour le contrat de cette release reste **Agave `v4.2.1`**, déjà auditée depuis `pre.001`.
Le calendrier public Agave v4.2 observé le 18 août 2026 montre que le rollout v4.2 est encore en cours : Devnet a été livré en juillet/août et les étapes Mainnet-beta d'adoption générale/activation sont positionnées en août. Cette situation ne justifie pas de remplacer rétroactivement la baseline wire de la release sans différence stable démontrée.
Audit final minimal imposé par le plan :
| SIMD | Statut observé le 2026-08-18 | Conséquence HTTP KSP |
|---------------------------------------------------|------------------------------|-------------------------------------------------------------------------------------------------------------------|
| `0180` Vote Account Address Keyed Leader Schedule | Review | aucune nouvelle méthode HTTP officielle ; ne pas changer `getLeaderSchedule` par anticipation |
| `0298` Bank Hash in Block Footer | Idea | aucun `bankHash` ajouté au wire stable `getBlock` |
| `0301` parent bank hash | PR fermé, non mergé | aucun `parentBankHash` spéculatif |
| `0307` Add Block Footer | Review | aucun `footer` ajouté à `SolanaGetBlockConfig`/`SolanaConfirmedBlock` tant que la baseline stable ne l'expose pas |
| `0385` Transaction V1 | Review | conserver `SolanaTransactionVersion::Number(u8)` générique et la canary version `1` |
| `0490` Stake v5 | Review | `getStakeMinimumDelegation` reflète uniquement la valeur runtime ; aucun minimum local codé en dur |
| `0550` Double Disinflation Rate | Review | `getInflationGovernor`/`getInflationRate` reflètent les valeurs runtime ; aucune formule locale |
| `0553` Base Inclusion and Resource-based Fee | Draft | changement économique/consensus à surveiller ; aucun nouveau wrapper ou champ HTTP stable ajouté |
Extensions wire déjà acquises et réauditées explicitement : **SIMD-0118** et **SIMD-0291**.
| SIMD | Statut observé le 2026-08-18 | Contrat déjà matérialisé dans KSP |
|-----------------------------------------------|------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------|
| `0118` Partitioned Epoch Rewards Distribution | Activated | `getBlock.numRewardPartitions` reste lossless : omission, `null` et valeur sont distincts ; KSP ne synthétise jamais `0` |
| `0291` Commission Rate in Basis Points | Review | `commission` et `commissionBps` restent indépendants dans les rewards de bloc et d'inflation ; les sous-arbres transaction restent lossless |
Le statut documentaire `Review` de SIMD-0291 ne justifie pas de supprimer un champ déjà livré par Agave `v4.2.1`. Inversement, KSP ne déduit jamais `commissionBps` depuis `commission`, ni l'inverse.
Sources SIMD :
```text
https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0118-partitioned-epoch-reward-distribution.md
https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0180-vote-account-leader-schedule.md
https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0291-commission-rate-in-basis-points.md
https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0298-bank-hash-in-block-footer.md
https://github.com/solana-foundation/solana-improvement-documents/pull/301
https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0307-add-block-footer.md
https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0385-transaction-v1.md
https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0490-upgrade-stake-to-v5.md
https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0550-double-disinflation.md
https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0553-resource-fee-burn.md
```
## Compliance des 52 méthodes courantes
La canary `public_v0_2_4_pre_009_all_52_current_typed_wrappers_and_legacy_forms_are_available_from_crate_root` référence directement chaque méthode Rust publique ci-dessous. Une méthode ne compte donc pas comme typed-complete uniquement parce qu'un descriptor ou l'exécuteur raw existe.
| Méthode RPC | Catégorie | Release typed | Classe | Wrapper public |
|-------------------------------------|--------------|---------------|--------------------------------------|------------------------------------------|
| `getAccountInfo` | Accounts | `0.2.2` | Read / RetrySafe | `get_account_info` |
| `getBalance` | Accounts | `0.2.1` | Read / RetrySafe | `get_balance` |
| `getLargestAccounts` | Accounts | `0.2.2` | Read / RetrySafe | `get_largest_accounts` |
| `getMinimumBalanceForRentExemption` | Accounts | `0.2.2` | Read / RetrySafe | `get_minimum_balance_for_rent_exemption` |
| `getMultipleAccounts` | Accounts | `0.2.2` | Read / RetrySafe | `get_multiple_accounts` |
| `getProgramAccounts` | Accounts | `0.2.2` | Read / RetrySafe | `get_program_accounts` |
| `getTokenAccountBalance` | Tokens | `0.2.2` | Read / RetrySafe | `get_token_account_balance` |
| `getTokenAccountsByDelegate` | Tokens | `0.2.2` | Read / RetrySafe | `get_token_accounts_by_delegate` |
| `getTokenAccountsByOwner` | Tokens | `0.2.2` | Read / RetrySafe | `get_token_accounts_by_owner` |
| `getTokenLargestAccounts` | Tokens | `0.2.2` | Read / RetrySafe | `get_token_largest_accounts` |
| `getTokenSupply` | Tokens | `0.2.2` | Read / RetrySafe | `get_token_supply` |
| `getFeeForMessage` | Transactions | `0.2.3` | Read / RetrySafe | `get_fee_for_message` |
| `getLatestBlockhash` | Transactions | `0.2.3` | Read / RetrySafe | `get_latest_blockhash` |
| `getRecentPrioritizationFees` | Transactions | `0.2.3` | Read / RetrySafe | `get_recent_prioritization_fees` |
| `getSignaturesForAddress` | Transactions | `0.2.3` | Read / RetrySafe | `get_signatures_for_address` |
| `getSignatureStatuses` | Transactions | `0.2.3` | Read / RetrySafe | `get_signature_statuses` |
| `getTransaction` | Transactions | `0.2.3` | Read / RetrySafe | `get_transaction` + legacy |
| `getTransactionCount` | Transactions | `0.2.3` | Read / RetrySafe | `get_transaction_count` |
| `isBlockhashValid` | Transactions | `0.2.3` | Read / RetrySafe | `is_blockhash_valid` |
| `requestAirdrop` | Transactions | `0.2.3` | WriteSubmission / NeverAfterDispatch | `request_airdrop` |
| `sendTransaction` | Transactions | `0.2.3` | WriteSubmission / NeverAfterDispatch | `send_transaction` |
| `simulateTransaction` | Transactions | `0.2.3` | Simulation / RetrySafe | `simulate_transaction` |
| `getBlock` | Blocks | `0.2.4` | Read / RetrySafe | `get_block` + legacy |
| `getBlockCommitment` | Blocks | `0.2.4` | Read / RetrySafe | `get_block_commitment` |
| `getBlockHeight` | Blocks | `0.2.4` | Read / RetrySafe | `get_block_height` |
| `getBlockProduction` | Blocks | `0.2.4` | Read / RetrySafe | `get_block_production` |
| `getBlocks` | Blocks | `0.2.4` | Read / RetrySafe | `get_blocks` |
| `getBlocksWithLimit` | Blocks | `0.2.4` | Read / RetrySafe | `get_blocks_with_limit` |
| `getBlockTime` | Blocks | `0.2.4` | Read / RetrySafe | `get_block_time` |
| `getFirstAvailableBlock` | Blocks | `0.2.4` | Read / RetrySafe | `get_first_available_block` |
| `getRecentPerformanceSamples` | Blocks | `0.2.4` | Read / RetrySafe | `get_recent_performance_samples` |
| `minimumLedgerSlot` | Blocks | `0.2.4` | Read / RetrySafe | `minimum_ledger_slot` |
| `getClusterNodes` | Cluster | `0.2.2` | Read / RetrySafe | `get_cluster_nodes` |
| `getEpochInfo` | Cluster | `0.2.2` | Read / RetrySafe | `get_epoch_info` |
| `getEpochSchedule` | Cluster | `0.2.2` | Read / RetrySafe | `get_epoch_schedule` |
| `getGenesisHash` | Cluster | `0.2.1` | Read / RetrySafe | `get_genesis_hash` |
| `getHealth` | Cluster | `0.2.1` | Read / RetrySafe | `get_health` |
| `getHighestSnapshotSlot` | Cluster | `0.2.2` | Read / RetrySafe | `get_highest_snapshot_slot` |
| `getIdentity` | Cluster | `0.2.2` | Read / RetrySafe | `get_identity` |
| `getLeaderSchedule` | Cluster | `0.2.2` | Read / RetrySafe | `get_leader_schedule` |
| `getMaxRetransmitSlot` | Cluster | `0.2.2` | Read / RetrySafe | `get_max_retransmit_slot` |
| `getMaxShredInsertSlot` | Cluster | `0.2.2` | Read / RetrySafe | `get_max_shred_insert_slot` |
| `getSlot` | Cluster | `0.2.2` | Read / RetrySafe | `get_slot` |
| `getSlotLeader` | Cluster | `0.2.2` | Read / RetrySafe | `get_slot_leader` |
| `getSlotLeaders` | Cluster | `0.2.2` | Read / RetrySafe | `get_slot_leaders` |
| `getVersion` | Cluster | `0.2.1` | Read / RetrySafe | `get_version` |
| `getVoteAccounts` | Cluster | `0.2.2` | Read / RetrySafe | `get_vote_accounts` |
| `getInflationGovernor` | Economics | `0.2.4` | Read / RetrySafe | `get_inflation_governor` |
| `getInflationRate` | Economics | `0.2.4` | Read / RetrySafe | `get_inflation_rate` |
| `getInflationReward` | Economics | `0.2.4` | Read / RetrySafe | `get_inflation_reward` |
| `getStakeMinimumDelegation` | Economics | `0.2.4` | Read / RetrySafe | `get_stake_minimum_delegation` |
| `getSupply` | Economics | `0.2.4` | Read / RetrySafe | `get_supply` |
Les deux formes legacy encore supportées sont couvertes séparément et marquées deprecated :
```text
getTransaction -> HttpTransportPool::get_transaction_legacy
getBlock -> HttpTransportPool::get_block_legacy
```
Partition exacte :
```text
0.2.1 foundation 4
0.2.2 Accounts/Tokens/Cluster 22
0.2.3 Transactions 11
0.2.4 Blocks/Economics 15
--------------------------------
total 52
```
Classification globale attendue :
```text
Read / RetrySafe
Simulation / RetrySafe
WriteSubmission / NeverAfterDispatch
```
Les seules write submissions actuelles restent `requestAirdrop` et `sendTransaction`; aucune classe `NeverAfterDispatch` n'est affaiblie par `0.2.4`.
## Compliance des 14 historiques
Les 14 entrées restent découvrables pour audit/compliance mais sont `Deprecated / Removed / NotApplicable` et ne sont pas envoyées au réseau :
| Méthode historique | Documentation | Runtime KSP | Remplacement/aide |
|-------------------------------------|---------------|-------------|-------------------------------------|
| `confirmTransaction` | Deprecated | Removed | getSignatureStatuses |
| `getConfirmedBlock` | Deprecated | Removed | getBlock |
| `getConfirmedBlocks` | Deprecated | Removed | getBlocks |
| `getConfirmedBlocksWithLimit` | Deprecated | Removed | getBlocksWithLimit |
| `getConfirmedSignaturesForAddress2` | Deprecated | Removed | getSignaturesForAddress |
| `getConfirmedTransaction` | Deprecated | Removed | getTransaction |
| `getFeeCalculatorForBlockhash` | Deprecated | Removed | isBlockhashValid / getFeeForMessage |
| `getFeeRateGovernor` | Deprecated | Removed | getFeeForMessage |
| `getFees` | Deprecated | Removed | getFeeForMessage |
| `getRecentBlockhash` | Deprecated | Removed | getLatestBlockhash |
| `getSignatureConfirmation` | Deprecated | Removed | getSignatureStatuses |
| `getSignatureStatus` | Deprecated | Removed | getSignatureStatuses |
| `getSnapshotSlot` | Deprecated | Removed | getHighestSnapshotSlot |
| `getStakeActivation` | Deprecated | Removed | aucun remplacement direct |
La canary `release_v0_2_4_pre_009_final_http_inventory_and_coverage_partition_are_exact` fige simultanément :
```text
52 noms current exacts
14 noms historiques exacts
4 / 22 / 11 / 15 par HttpRpcCoverageRelease
Supported pour les 52 current
Deprecated + Removed + NotApplicable pour les 14 historiques
RetrySafe pour Read/Simulation current
NeverAfterDispatch pour WriteSubmission current
```
## `KSP-TRANSPORT-007` — preuve globale 52/52
Le réaudit `0.2.3` a déjà conclu **37/37 conformes** avant l'ouverture de `0.2.4`.
Les 15 nouveaux wrappers appliquent la même règle sans réduction de contrat.
### Blocks — 10/10
Points de sensibilité couverts :
- `getBlock` moderne + bare encoding legacy deprecated ;
- encodings `binary/base58/base64/json/jsonParsed` réellement supportés par la baseline ;
- `transactionDetails = full/signatures/none/accounts` ;
- `maxSupportedTransactionVersion` et version numérique générique, y compris canary `1` ;
- distinction résultat `null` / erreurs RPC ;
- `transactions`, `signatures`, `rewards`, `numRewardPartitions` avec préservation des états wire pertinents ;
- `commission` nullable + `commissionBps` indépendant ;
- `getBlocks` avec ses quatre overloads exacts et `RpcContextConfig` complet ;
- `getBlocksWithLimit(0)` valide et plafond 500000 ;
- `getRecentPerformanceSamples <= 720` et ancien wire sans `numNonVoteTransactions` ;
- `getBlockProduction` identity/range/context sans restriction de commitment inventée ;
- wrappers sans config exactement en `params: []`.
### Economics — 5/5
Points de sensibilité couverts :
- aucune formule d'inflation locale ;
- aucun minimum de délégation codé en dur ;
- `getSupply` conserve `excludeNonCirculatingAccountsList` omis/false/true ;
- `getInflationReward` conserve ordre, doublons, `null` positionnels et cardinalité ;
- aucun plafond d'adresses inventé pour `getInflationReward` ;
- `epoch`, `commitment`, `minContextSlot` transmis ;
- `getInflationReward` rejette `processed` avant I/O car la voie runtime exige au moins `confirmed` ;
- `commission` nullable et `commissionBps` présent/omis/null indépendants ;
- erreurs RPC de contexte/rewards period conservées comme erreurs applicatives distantes.
Verdict candidate :
```text
KSP-TRANSPORT-007 current wrappers == 52/52
remédiation fonctionnelle finale == aucune
```
## Smoke Devnet Transport pur
Le smoke Transport reste opt-in, programmatique et read-only :
```text
settings programmatiques
-> getAccountInfo
-> getTokenAccountsByOwner
-> getEpochInfo
-> getVoteAccounts
-> getLatestBlockhash
-> isBlockhashValid
-> getTransactionCount
-> getBlockHeight
-> getInflationRate
-> getStakeMinimumDelegation
```
Les trois derniers appels ajoutent une traversée live représentative des familles Blocks/Economics sans dépendre d'un slot historique particulier, d'un compte reward spécifique ou d'une valeur économique codée en dur.
Commande :
```bash
cargo test -p ksp-onchain-transport-lib --test transport_devnet_smoke -- --ignored --nocapture
```
Le smoke historique de composition reste séparé et transitoire :
```bash
cargo test -p ksp-config-lib --test transport_devnet_smoke -- --ignored --nocapture
```
Il ne devient pas un modèle de placement des futurs smokes cross-crates.
## Frontières et graphes Cargo
Frontière attendue :
```text
ksp-config-lib -> ksp-onchain-transport-lib
ksp-onchain-transport-lib -> ksp-core-lib
ksp-onchain-transport-lib -> ksp-logging-lib
ksp-onchain-transport-lib -X-> ksp-config-lib
ksp-onchain-transport-lib -X-> Store
ksp-onchain-transport-lib -X-> Program
ksp-onchain-transport-lib -X-> tracing direct
```
`0.2.4` n'ajoute aucune dépendance externe au `Cargo.toml` de Transport.
Graphes à inspecter sur 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
```
Interprétation importante : `tracing` peut apparaître **transitivement** sous `ksp-logging-lib`, ce qui est conforme à l'architecture. L'interdit porte sur une dépendance **directe** de `ksp-onchain-transport-lib` vers `tracing`. Les graphes doivent donc être lus par chaîne de dépendances et non validés par la simple présence/absence du nom `tracing` dans l'arbre complet.
Les canaries workspace de dépendances restent des règles globales et ne sont pas déplacées dans Transport.
## Gate candidate `0.2.4-pre.009`
Validation déterministe immédiate attendue :
```bash
cargo fmt --all
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test -p ksp-onchain-transport-lib
```
Compteurs Transport attendus après les deux nouvelles canaries finales :
```text
240 unit
27 public API
22 release completeness
1 smoke live ignored par défaut
```
Gate de clôture avant `rel.001` :
```bash
cargo test -p ksp-config-lib
cargo test -p ksp-core-lib
cargo test -p ksp-app-config-desk
cargo test --workspace
```
Puis inspection des huit graphes Cargo ci-dessus et exécution explicite des deux smokes Devnet.
Les résultats opérateur de `pre.009` seront enregistrés ici pendant `rel.001`; ils ne sont pas anticipés dans la candidate.
## Documentation et prochaine release
La candidate synchronise :
```text
ROADMAP.md
README/USAGE Transport
inventaire composant
séquence fonctionnelle
plan 011
index docs/plans/validation/prompts
```
Le prompt suivant est :
```text
prompts/010-V0_2_5_START_PROMPT.md
0.2.5 — Wallet foundation
```
Il conserve notamment les frontières déjà décidées :
```text
ksp-wallet-lib
.kspwallet
protection des secrets
signature
import/export extensible
changement de mot de passe
atomicité/no-clobber
Wallet -X-> Config
Wallet -X-> Transport
Wallet -X-> execution policy
WalletPolicy hors Wallet
```
## Publication `rel.001`
Après validation opérateur complète :
```text
workspace.package.version -> 0.2.4
ROADMAP : 0.2.4 -> [X]
CHANGELOG : synthèse stable 0.2.4
plan 011 / validation 007 : preuves finales opérateur + statut stable
README/USAGE/inventaires : candidate -> stable
deltas/0.2.4/rel.001.md
commit : v0.2.4-rel.001
tag stable : v0.2.4
```
Aucun wrapper, DTO, comportement runtime, dependency ou feature Cargo ne doit être ajouté pendant `rel.001`.