v0.1.0-pre.007

docs/SOLANA_INTERFACE_DEPENDENCIES.md

@@ -150,10 +150,11 @@ instruction.
 ### SPL Associated Token Account
 
 Le catalogue workspace déclare `spl-associated-token-account-interface ^2.0` avec la feature
-`borsh`. Cargo a résolu la version `2.0.0` pendant le jalon `0.4.5`. Les crates
-`kb_decoder_spl_associated_token_account` et `kb_executor_spl_associated_token_account` consomment
-réellement l'enum, les builders, le Program ID et le helper officiel de dérivation ; le pipeline et
-la démo consomment ensuite leurs contrats typés sans recopier l'interface.
+`borsh`. Cargo a résolu la version `2.0.0` pendant le jalon bot2 `0.4.5`. Depuis bot3
+`0.1.0-pre.007`, `kb-lib::decoder::spl::associated_token_account` consomme réellement le Program
+ID et le helper officiel de dérivation en production, puis l'enum et les builders dans ses tests
+différentiels. L'ancien exécuteur n'est pas encore porté ; le pipeline et la démo restent donc hors
+de cette tranche.
 
 L'interface publie exactement trois variantes Borsh actuelles : `Create` (`0`),
 `CreateIdempotent` (`1`) et `RecoverNested` (`2`). Le processor accepte aussi historiquement une
@@ -164,10 +165,11 @@ classiques des ATA Token-2022 d'un même wallet et mint.
 
 Le décodeur conserve les comptes, flags, doublons, chemins outer/inner, transactions échouées,
 adresses observées et dérivées, ainsi que les rôles distincts de `RecoverNested`. Les tests
-différentiels comparent les trois builders et les vecteurs PDA au helper officiel. L'exécuteur
-utilise les mêmes builders pour les trois variantes, impose simulation et dry-run par défaut, puis
-laisse au pipeline stateful les contrôles de mint, owner, compte existant, rent, signataires et
-postconditions.
+différentiels comparent les trois builders et les vecteurs PDA au helper officiel. Dans bot2,
+l'exécuteur validé utilisait les mêmes builders pour les trois variantes, imposait simulation et
+dry-run par défaut, puis laissait au pipeline stateful les contrôles de mint, owner, compte
+existant, rent, signataires et postconditions. Cette capacité reste une preuve de référence tant
+que les modules exécuteur et pipeline correspondants ne sont pas portés dans bot3.
 
 Les preuves Devnet du 16 juillet 2026 couvrent `CreateIdempotent` pour SPL Token classique et
 Token-2022, y compris création, réutilisation, replay post-exécution idempotent et ATA Token-2022

docs/SPL_ASSOCIATED_TOKEN_ACCOUNT_MATRIX.json

@@ -1,7 +1,16 @@
 {
   "file": "docs/SPL_ASSOCIATED_TOKEN_ACCOUNT_MATRIX.json",
-  "version": 9,
+  "version": 10,
   "schemaVersion": 1,
+  "bot3Migration": {
+    "target": "kb-lib.decoder.spl.associated_token_account",
+    "status": "ported_pending_operator_cargo_validation",
+    "prerelease": "0.1.0-pre.007",
+    "preservedDifferentialTests": 10,
+    "materializerPorted": false,
+    "executorPorted": false,
+    "pipelinePorted": false
+  },
   "programId": "ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL",
   "systemProgramId": "11111111111111111111111111111111",
   "supportedTokenPrograms": [

docs/TRACING_CONTRACT.md

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