v0.1.0-pre.006

docs/SOLANA_INTERFACE_DEPENDENCIES.md

@@ -1,5 +1,5 @@
 <!-- file: docs/SOLANA_INTERFACE_DEPENDENCIES.md -->
-<!-- version: 28 -->
+<!-- version: 29 -->
 
 # Dépendances d’interfaces Solana et SPL
 
@@ -29,6 +29,15 @@ Une déclaration à la racine ne justifie pas une dépendance inutilisée dans u
 
 Le workspace reste épinglé sur `wincode ^0.5`. Les crates Solana modulaires actuellement utilisées avec la feature `wincode` publient leurs implémentations `SchemaRead`/`SchemaWrite` contre `wincode 0.5.x`. Ces traits sont nominalement distincts de ceux de `wincode 0.6.x` : une dépendance directe migrée seule vers `0.6` ne peut donc ni désérialiser `solana_nonce::versions::Versions`, ni sérialiser `solana_transaction::Transaction`. Cargo peut charger les deux versions simultanément, mais les implémentations de traits ne sont pas interchangeables et l’orphan rule interdit de les réimplémenter localement pour ces types externes.
 
+Le catalogue `[workspace.dependencies]` ne gouverne que les dépendances réellement consommées par
+les crates membres ; il ne peut pas contraindre à lui seul une branche transitive compatible avec
+plusieurs versions. Ajouter `solana-wincode-varint` comme dépendance inutilisée de `kb-lib` serait
+contraire aux règles du workspace. Comme bot3 est un workspace applicatif, son `Cargo.lock`
+versionné constitue le verrou reproductible de cette branche : il doit résoudre exactement
+`solana-wincode-varint 1.0.0` et `wincode 0.5.5`. L’audit
+`scripts/audit_khadhroony_workspace_rules.py` vérifie le manifeste et ces deux versions avant les
+contrôles Cargo.
+
 La migration vers `wincode 0.6` doit attendre que l’ensemble des crates Solana consommées migre de façon cohérente. Une double dépendance aliasée n’est acceptable que pour des types propres au workspace ; tous les appels portant sur des types Solana doivent utiliser la même version `0.5.x` que celle employée par leurs crates d’origine. Avant toute migration, vérifier avec `cargo tree -d` et `cargo tree -i wincode@<version>`.
 
 
@@ -269,4 +278,3 @@ Le catalogue workspace déclare `mpl-token-metadata ^5.1` avec la seule feature
 Le dépôt officiel `metaplex-foundation/mpl-token-metadata` confirme le Program ID `metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s`. L’IDL officiel audité porte la version `1.14.0` et le blob `5df4a24f62c2743125be096cc174680790c92c18`; l’inventaire Rust généré des instructions porte le blob `3c42eec629f82e44ba690a7c4bd2177cc78f1d49`.
 
 `kb_decoder_metadata_metaplex_token_metadata` implémente désormais `InstructionDecoder` pour `CreateMetadataAccountV3` et `UpdateMetadataAccountV2`. Les arguments sont lus avec les types Borsh officiels et projetés avec la feature `serde`; les payloads, chaînes, créateurs, frais, comptes et suffixes sont bornés. L’enregistrement dans le registre runtime reste différé jusqu’à validation de ce premier groupe. Les metadata Token-2022 incorporées, Metaplex Core, Bubblegum et le JSON externe restent des provenances ou composants distincts.
-