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.
-

docs/SPL_TOKEN_MATRIX.json

@@ -1,8 +1,14 @@
 {
   "file": "docs/SPL_TOKEN_MATRIX.json",
-  "version": 3,
+  "version": 4,
   "schemaVersion": 2,
   "programId": "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA",
+  "bot3Migration": {
+    "milestone": "0.1.0-pre.006",
+    "component": "kb-lib.decoder.spl.token",
+    "status": "decoder_ported_validation_pending",
+    "scope": "decoder_only"
+  },
   "interface": {
     "workspaceConstraint": "^3.0",
     "expectedResolvedVersion": "3.0.0",

docs/TRACING_CONTRACT.md

@@ -1,5 +1,5 @@
 <!-- file: docs/TRACING_CONTRACT.md -->
-<!-- version: 14 -->
+<!-- version: 15 -->
 
 # Contrat de tracing par crate et composant
 
@@ -58,6 +58,7 @@ Les targets déjà migrés vers les noms canoniques bot3 sont :
 ```text
 kb-lib.decoder.solana.core
 kb-lib.decoder.spl.memo
+kb-lib.decoder.spl.token
 kb-logging
 kb-store
 ```