v0.4.7-pre.016

2026-08-05 11:29:43 +02:00
parent 40d831f84d
commit 1d1f57ae78
42 changed files with 493 additions and 1203 deletions
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -18,7 +18,7 @@ members = [
 ]
 [workspace.package]
-version = "0.4.7-pre.15"
+version = "0.4.7-pre.16"
 edition = "2024"
 license = "MIT"
 repository = "https://git.sasedev.com/Sasedev/khadhroony-bot3"
--- a/README.md
+++ b/README.md
@@ -1,18 +1,10 @@
 <!-- file: README.md -->
-<!-- version: 16 -->
+<!-- version: 17 -->
 # Khadhroony Bot3
 `khadhroony-bot3` est un workspace Rust 2024 dédié à l’acquisition, au décodage, à la matérialisation et à l’exécution contrôlée de transactions Solana.
 ## Version en développement
 La version active est `0.4.7`, consacrée à l’achèvement de Metaplex Token Metadata.
 Les contrats de décodage, les comptes, les matérialisations, les 35 opérations officiellement constructibles, l’orchestration généraliste, les scénarios synthétiques et le panneau desktop sont présents. La clôture est repoussée jusqu’à la réalisation des campagnes Devnet des 20 opérations courantes non dépréciées.
 Le registre ElGamal reste une exception indépendante : il est implémenté et validé synthétiquement, mais n’est pas déclaré validé réellement sur Devnet ou Mainnet.
 ## Architecture
 Le workspace contient onze crates :
@@ -27,7 +19,7 @@ Le workspace contient onze crates :
 - `kb-onchain-transport` : transports RPC HTTP et WebSocket ;
 - `kb-store` : contrats de stockage et adaptateur PostgreSQL ;
 - `kb-wallet` : frontière de wallet et signataires ;
- `kb-app-demo-desktop` : application Tauri de démonstration, avec scénarios UI conservés dans le desktop.
+- `kb-app-demo-desktop` : application Tauri de démonstration et validation opérateur.
 Références :
@@ -37,18 +29,28 @@ Références :
 - [`docs/architecture/STORAGE_ARCHITECTURE.md`](docs/architecture/STORAGE_ARCHITECTURE.md) ;
 - [`docs/architecture/SURFACE_CRATE_MATRIX.md`](docs/architecture/SURFACE_CRATE_MATRIX.md).
 ## Capacités principales
 - acquisition HTTP et WebSocket ;
 - stockage PostgreSQL canonique ;
 - extraction Solana Core et replay contextualisé ;
 - décodeurs, matérialisateurs et exécuteurs Solana Core et SPL ;
 - exécution simulation-first avec contrôle des signers, coûts, confirmations et postconditions ;
 - scénarios synthétiques, campagnes réseau réutilisables et panneaux desktop ;
 - couverture Metaplex Token Metadata bornée, avec parcours Devnet représentatifs réellement exécutés.
 Le statut précis d’une version appartient au [`CHANGELOG.md`](CHANGELOG.md), au [`ROADMAP.md`](ROADMAP.md) et aux rapports de validation, pas au présent README généraliste.
 ## Documentation
 - [`RULES.md`](RULES.md) : index des règles ;
- [`ROADMAP.md`](ROADMAP.md) : objectifs par version fonctionnelle ;
+- [`ROADMAP.md`](ROADMAP.md) : trajectoire fonctionnelle ;
- [`CHANGELOG.md`](CHANGELOG.md) : historique des versions fonctionnelles clôturées ;
+- [`CHANGELOG.md`](CHANGELOG.md) : versions fonctionnelles clôturées ;
 - [`docs/README.md`](docs/README.md) : index documentaire ;
- [`prompts/027_v0_4_7_metaplex_token_metadata_completion.md`](prompts/027_v0_4_7_metaplex_token_metadata_completion.md) : prompt actif de `0.4.7`.
+- [`prompts/001.README.md`](prompts/001.README.md) : prompts actifs.
 ## Validation générale
 La validation finale d’une version utilise :
 ```bash
 cargo fmt --all
 cargo check --workspace
--- a/ROADMAP.md
+++ b/ROADMAP.md
@@ -1,196 +1,113 @@
 <!-- file: ROADMAP.md -->
-<!-- version: 26 -->
+<!-- version: 27 -->
 # ROADMAP — khadhroony-bot3
-Le roadmap décrit les objectifs fonctionnels par version mineure. Il ne contient ni prereleases, ni correctifs `fix`, ni journal détaillé des travaux terminés. Les détails opérationnels appartiennent aux `TODO.md` et `CHANGELOG.md` des crates.
+Le roadmap décrit les objectifs fonctionnels par version mineure. Il ne contient ni prereleases, ni correctifs `fix`, ni journal détaillé des travaux terminés.
 ## 0.4.6 — alignement fonctionnel et clôture de la migration principale
-Version clôturée.
+Version clôturée : architecture en onze crates, alignement bot2 `0.4.6`, validations workspace et scénarios applicatifs. Le registre ElGamal reste implémenté et validé synthétiquement sans preuve réseau réelle.
- alignement fonctionnel sur `khadhroony-bot2 0.4.6` ;
+## 0.4.7 — Metaplex Token Metadata
 - consolidation de l’architecture en onze crates ;
 - validation des matrices, registres, bindings TS-RS, tests workspace et scénarios applicatifs ;
 - conservation du registre ElGamal comme exception documentée sans validation réseau réelle ;
 - report des améliorations structurelles de configuration, logging et stockage à `0.5.x`.
-## 0.4.7 — achèvement de Metaplex Token Metadata
+Version en clôture documentaire.
-### Base acquise
+### Périmètre réalisé
- décodeur d’instructions Metaplex Token Metadata ;
+- décodeur d’instructions et de comptes, PDA, owners et variantes historiques ;
- décodeur des comptes et validation des PDA/owners ;
+- matérialisation metadata, administration, lifecycle et risques applicables ;
- matrice contractuelle bornée ;
+- intents typés, builders, exécuteur, préflights, simulation exacte et postconditions ;
- matérialisation metadata déjà substantielle ;
+- intégration généraliste dans `kb-pipeline` ;
- coexistence explicite avec les metadata incorporées de Token-2022.
+- scénarios synthétiques NFT, SFT, fungible, collection et pNFT ;
 - runner Devnet réutilisable et panneau `kb-app-demo-desktop` ;
 - fixtures Rust natives sans dépendance à une CLI externe ;
 - soumissions confirmées de parcours représentatifs `Create`, `UpdateAsUpdateAuthorityV2` et transition immutable.
-### Objectifs
+### Qualification de validation
- auditer la matérialisation migrée et compléter uniquement les projections manquantes ;
+- les opérations structurantes et les parcours représentatifs sont validés réellement sur Devnet ;
- implémenter les intents typés, builders, exécuteur, préflights et postconditions ;
+- les autres opérations exposées restent couvertes par leurs builders, matrices et tests synthétiques ;
- intégrer l’exécution et les validations dans `kb-pipeline` ;
+- les campagnes Devnet spécialisées `Print`, `Burn`, collections avancées, délégations/lock pNFT, rule sets et maintenance sont une dette de validation complémentaire, non un blocant de clôture ;
- ajouter les scénarios synthétiques et les validations automatisées Devnet/Testnet dans `kb-pipeline-demo-scenarios`, en parallèle des scénarios UI conservés dans le desktop ;
+- aucune preuve synthétique ne doit être présentée comme preuve RPC.
 - étendre le CLI uniquement lorsqu’une préparation de fixture dédiée le justifie ;
 - valider le parcours réseau et PostgreSQL de bout en bout lorsque les fixtures sont disponibles.
-### Contraintes
+### Hors périmètre
- ne pas confondre Metaplex Token Metadata, metadata Token-2022, SPL Token Metadata ou Metaplex Core ;
+- metadata incorporées Token-2022 et SPL Token Metadata ;
- utiliser les IDL archivées comme références, jamais comme moteur dynamique de production ;
+- Metaplex Core, Bubblegum et autres programmes Metaplex ;
- conserver le fetch HTTP/IPFS/Arweave hors périmètre de `0.4.7`.
+- fetch HTTP/IPFS/Arweave des URI off-chain.
 ### Critères de sortie
 - exécution simulation-first avec signers, coûts et confirmations exacts ;
 - scénarios synthétiques déterministes et campagnes Devnet réelles dans `kb-pipeline-demo-scenarios` ;
 - scénario Devnet pour chacune des 20 opérations courantes non dépréciées, avec simulation RPC réelle et, lorsque l'opération est réalisable, soumission confirmée et postcondition observée ;
 - démonstrations UI Devnet conservées dans `kb-app-demo-desktop` et raccordées aux mêmes contrats réutilisables ;
 - tests contractuels, unitaires, stateful et replay PostgreSQL idempotent ;
 - statut réseau exact par opération, sans substitution d'une preuve synthétique à une preuve RPC ;
 - opérations remplacées redirigées vers leur remplacement canonique final ;
 - opérations obsolètes encore constructibles exposées comme exécutables dépréciées et soumises à une approbation explicite ;
 - clôture repoussée jusqu'à l'achèvement des campagnes Devnet des opérations courantes.
 ## 0.4.8 — SPL Token Metadata et décision off-chain metadata
 ### Première prerelease
 La première prerelease doit produire un plan et un inventaire fermé avant tout développement fonctionnel. Elle doit prévoir dès le départ des scénarios Devnet réels dans `kb-app-demo-desktop`, en parallèle des tests synthétiques et des campagnes automatisées de `kb-pipeline-demo-scenarios`.
 ### Objectifs
 - auditer `spl-token-metadata-interface` comme surface distincte ;
- séparer explicitement SPL Token Metadata, metadata Token-2022 et Metaplex Token Metadata ;
+- séparer SPL Token Metadata, metadata Token-2022 et Metaplex Token Metadata ;
- implémenter les couches decoder, materializer, executor, pipeline et démonstrations réellement justifiées ;
+- implémenter uniquement les couches decoder, materializer, executor, pipeline et démonstrations justifiées ;
- décider si une nouvelle crate `kb-offchain-transport` doit être créée ;
+- décider si `kb-offchain-transport` doit être créée ;
- si elle est retenue, commencer par un module metadata borné pour HTTP, IPFS et Arweave.
+- si retenue, commencer par un module metadata borné HTTP/IPFS/Arweave.
-### Contraintes du fetch off-chain
+### Contraintes off-chain
 - le contenu externe ne modifie jamais le statut canonique du replay on-chain ;
- timeout, taille, content type, redirections, cache, hash et provenance sont bornés ;
+- timeout, taille, type MIME, redirections, cache, hash et provenance sont bornés ;
 - protection SSRF et interdiction des réseaux locaux ;
 - aucune confiance implicite dans les JSON distants.
-### Critères de sortie
+## 0.5.x — configuration, wallet, stockage et démonstrations
- contrats SPL Token Metadata vérifiés et documentés ;
+- restructurer `kb-config` et séparer le logging si retenu ;
- décision architecturale explicite sur `kb-offchain-transport` ;
+- compléter multi-wallets, import/export, chiffrement, verrouillage, sauvegarde et restauration dans `kb-wallet` ;
- absence de confusion ou fusion silencieuse entre sources metadata.
+- auditer pool, résilience, administration et besoins historiques de `kb-store` ;
 - maintenir les scénarios UI Devnet/Testnet dans le desktop et leurs équivalents automatisés dans `kb-pipeline-demo-scenarios` ;
 - compléter les validations Devnet spécialisées Metaplex Token Metadata reportées de `0.4.7` lorsque leur utilité le justifie.
-## 0.5.x — démonstrations, configuration et wallet
+## 0.6.x — Anchor générique, programmes SPL et Metaplex complémentaires
-### Configuration
+- infrastructure générique Anchor : discriminants, comptes, événements et erreurs ;
-
+- classification et conservation des IDL comme références statiques ;
- scinder `kb-config` en deux fichiers, ou trois si nécessaire ;
+- autres programmes SPL et Metaplex, chacun avec matrices et scénarios Devnet réels représentatifs.
 - alléger la configuration générale ;
 - extraire les blocs dupliqués entre profils, notamment le logging ;
 - conserver un schéma explicite et des exemples utilisateurs cohérents.
 ### Scénarios de démonstration
 - ajouter dans `kb-pipeline-demo-scenarios` des tests automatisés reproduisant en parallèle les scénarios Devnet/Testnet des panneaux desktop ;
 - conserver les scénarios UI Devnet/Testnet dans `kb-app-demo-desktop` ;
 - améliorer le CLI uniquement pour les préparations de fixtures et opérations explicitement justifiées ;
 - compléter les démonstrations des surfaces `0.4.x` et maintenir les adaptateurs Tauri minces.
 ### Wallet
 - compléter réellement `kb-wallet` ;
 - ajouter import, export, multi-wallets et sélection active ;
 - ajouter changement de mot de passe, chiffrement, déchiffrement et verrouillage ;
 - ajouter sauvegarde, restauration, politiques de sécurité et intégration aux profils/signers.
 ## 0.6.x — Anchor, programmes SPL et Metaplex complémentaires
 ### Anchor
 - implémenter une infrastructure générique de décodage des conventions Anchor ;
 - prendre en charge discriminants, comptes, événements et erreurs selon des contrats bornés ;
 - intégrer les conventions Anchor aux décodeurs, exécuteurs et matérialisateurs.
 ### IDL
 - maintenir dès maintenant la classification et le nommage des IDL archivées ;
 - ajouter les IDL de référence au fur et à mesure des protocoles étudiés ;
 - ne jamais charger dynamiquement les IDL ni exécuter arbitrairement leur contenu en production.
 ### Programmes
 - ajouter le reste des programmes SPL ;
 - ajouter le reste des programmes Metaplex ;
 - documenter chaque surface avec matrices, tests et critères de validation.
 ## 0.7.x — Meteora
-1. AMM Meteora : DLMM, DAMM v1, DAMM v2 et autres AMM non launchpad ;
+DLMM, DAMM v1/v2, DBC, vaults et autres programmes vérifiés.
 2. launchpad DBC ;
 3. vaults Meteora ;
 4. autres programmes Meteora identifiés et vérifiés.
-## 0.8.x — Raydium
+## 0.8.x — Pump
-1. AMM et swaps : v4, v3, v2, CPMM, CLMM et stable swap ;
+Pump AMM, Pump.fun, Pump Fees et autres surfaces vérifiées. Auditer `MAyhSmzXzV1pTf7LsNkrNwkWKTo4ougAJ1PPg47MD4e` et l’appartenance de `pumpup_ai`.
 2. LaunchLab ;
 3. Raydium Lock ;
 4. autres programmes Raydium identifiés et vérifiés.
-## 0.9.x — Pump
+## 0.9.x — Raydium
-1. Pump AMM ;
+AMM v4/v3/v2, CPMM, CLMM, stable swap, LaunchLab, Lock et autres surfaces vérifiées.
 2. Pump.fun ;
 3. Pump Fees ;
 4. autres programmes Pump à identifier.
 À auditer avant classement :
 ```text
 MAyhSmzXzV1pTf7LsNkrNwkWKTo4ougAJ1PPg47MD4e
 ```
 Vérifier sa nature, son déploiement et son appartenance réelle à la famille Pump. Vérifier séparément si `pumpup_ai` appartient à cette famille ou constitue un protocole distinct.
 ## 0.10.x — Orca
-1. Whirlpool ;
+Whirlpool, Orca v1/v2, Wavebreak et autres surfaces vérifiées.
 2. Orca v1 ;
 3. Orca v2 ;
 4. Wavebreak ;
 5. autres programmes Orca identifiés et vérifiés.
 ## 0.11.x — Jupiter
- routers et agrégateurs ;
+Routers, agrégateurs, DCA, ordres, perpetuals, lockers et autres surfaces vérifiées.
 - DCA et ordres ;
 - perpetuals et lockers ;
 - autres programmes Jupiter identifiés et vérifiés.
-## 0.12.x — OKX et autres routers
+## 0.12.x — autres routers et protocoles
- routers et autres programmes OKX ;
+OKX et autres routers, puis surfaces complémentaires classées selon leur priorité réelle.
 - autres routers et agrégateurs hors Jupiter ;
 - surfaces de matérialisation, sécurité et exécution associées.
 ## 0.13.x — transports temps réel
- extension WebSocket Helius dans `kb-onchain-transport` ;
+WebSocket Helius, LaserStream, Yellowstone gRPC, continuité, backpressure, reconnexion et métriques.
 - amélioration de LaserStream si pertinente ;
 - Yellowstone gRPC ;
 - autres transports streaming ;
 - reprise, continuité, backpressure, reconnexion et métriques ;
 - vérification et classement du listing historique des Program IDs sans modifier l’archive bot2.
-## 0.14.x — application de trading et orchestration
+## 0.14.x — workers et applications consommatrices
- application de trading ;
+- W1 acquisition temps réel vers les raw ;
- workers et services séparés ;
+- W2 décodage et matérialisation temps réel ;
- orchestration et automatisation ;
+- rattrapage historique séparé ;
- stratégies et exécution contrôlée ;
+- application de contrôle ;
- sécurité opérationnelle ;
+- application de trading et applications de visualisation.
 - séparation stricte entre UI, workers et services.
 ## 0.15.x+ — extensions futures
- nouveaux décodeurs, exécuteurs et matérialisateurs ;
+Nouveaux protocoles, transports, backfills, observabilité, administration et optimisations validées par des contrats bornés.
 - protocoles et transports supplémentaires ;
 - opérations historiques et backfills avancés ;
 - optimisations, observabilité et outils d’administration ;
 - extensions futures validées par des contrats bornés.
--- a/docs/DEVNET_EXECUTION_GUIDE.md
+++ b/docs/DEVNET_EXECUTION_GUIDE.md
@@ -1,5 +1,5 @@
 <!-- file: docs/DEVNET_EXECUTION_GUIDE.md -->
-<!-- version: 22 -->
+<!-- version: 23 -->
 # Guide d’exécution Devnet
@@ -100,7 +100,7 @@ Arrêter avec `Ctrl+C`, puis relancer `T01`.
 ### C01 — Initialiser l’environnement de validation
 ```bash
-cd ~/Projects/khadhroony-bot3 && set -o pipefail && export KB_DEVNET_PROFILE="local_devnet" && export KB_DEVNET_RPC_URL="https://api.devnet.solana.com" && export KB_DEVNET_VALIDATION_DIR="/tmp/devnet-validation/pre.062-clean" && export KB_DEVNET_WALLET="$PWD/wallets/temporary/local_devnet/local-devnet-operator.json" && mkdir -p "$KB_DEVNET_VALIDATION_DIR" && printf 'Profil     : %s\n' "$KB_DEVNET_PROFILE" && printf 'RPC Devnet : %s\n' "$KB_DEVNET_RPC_URL" && printf 'Preuves    : %s\n' "$KB_DEVNET_VALIDATION_DIR" && printf 'Wallet     : %s\n' "$KB_DEVNET_WALLET"; 
+cd ~/Projects/khadhroony-bot3 && set -o pipefail && export KB_DEVNET_PROFILE="local_devnet" && export KB_DEVNET_RPC_URL="https://api.devnet.solana.com" && export KB_DEVNET_VALIDATION_DIR="/tmp/devnet-validation/current" && export KB_DEVNET_WALLET="$PWD/wallets/temporary/local_devnet/local-devnet-operator.json" && mkdir -p "$KB_DEVNET_VALIDATION_DIR" && printf 'Profil     : %s\n' "$KB_DEVNET_PROFILE" && printf 'RPC Devnet : %s\n' "$KB_DEVNET_RPC_URL" && printf 'Preuves    : %s\n' "$KB_DEVNET_VALIDATION_DIR" && printf 'Wallet     : %s\n' "$KB_DEVNET_WALLET"; 
 ```
 ### C02 — Capturer les versions CLI
@@ -109,7 +109,7 @@ cd ~/Projects/khadhroony-bot3 && set -o pipefail && export KB_DEVNET_PROFILE="lo
 command -v solana && command -v solana-keygen && command -v spl-token && { date --iso-8601=seconds; solana --version; solana-keygen --version; spl-token --version; } | tee "$KB_DEVNET_VALIDATION_DIR/00-cli-versions.txt";
 ```
-La première campagne `pre.062` utilisait `solana-cli 4.0.2`, `solana-keygen 4.0.2` et `spl-token-cli 5.5.0`. Une nouvelle campagne doit capturer ses propres versions.
+Chaque campagne doit capturer les versions exactes des outils externes qu’elle utilise. Les fixtures Rust natives ne doivent pas dépendre implicitement de la configuration globale d’une CLI.
 ### C03 — Vérifier l’identité du réseau
@@ -758,7 +758,7 @@ puis `50b`, `50c`, etc., avant chaque appel à `C07`.
 ## 11. Scénario S06 — Registre ElGamal — reporté
-### Statut de `0.1.0-pre.062`
+### Statut de la campagne de référence historique
 Le registre ElGamal reste implémenté mais **non validé sur Devnet** dans cette campagne. Ce report ne remet pas en cause les validations S01 à S05.
--- a/docs/IDEA_REMINDERS.md
+++ b/docs/IDEA_REMINDERS.md
@@ -1,94 +1,45 @@
 <!-- file: docs/IDEA_REMINDERS.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 # Rappels d’idées
-Ce document regroupe les améliorations utiles mais non bloquantes pour la clôture de la migration et pour la reprise du développement fonctionnel.
+Ce document conserve les idées utiles qui ne constituent pas encore des engagements de version. Les orientations déjà intégrées au ROADMAP ne sont pas répétées comme propositions ouvertes.
 ## Application desktop
- Ajouter une autocomplétion Token lorsque des tables de référence fiables existeront.
+- autocomplétion Token et Pool lorsque des tables de référence fiables existeront ;
- Ajouter une autocomplétion Pool lorsque des tables de référence fiables existeront.
+- pagination SQL/IPC côté serveur avant l’exploitation de volumes massifs ;
- Introduire une pagination SQL/IPC côté serveur avant l’exploitation de volumes massifs.
+- résolution configurable du chemin de base de `kb-store` ;
- Étudier une résolution configurable du chemin de base utilisé par `kb-store`.
+- sélection indépendante du profil de logging ;
- Séparer à terme la configuration du logging dans un fichier JSON dédié avec son propre schéma et ses propres profils de logging.
+- protection systématique contre les doubles déclenchements des actions réseau ;
- Permettre de sélectionner et changer un profil de logging indépendamment du profil applicatif actif, afin que les fenêtres Devnet puissent écrire dans des routes ou fichiers distincts sans changer le profil général de l’application.
+- affichage explicite des preuves de matérialisation après confirmation.
 ## Pipeline et PostgreSQL
- Dimensionner dynamiquement la concurrence Decode replay en fonction du pool PostgreSQL disponible.
+- dimensionnement dynamique de la concurrence Decode replay selon le pool ;
- Ajouter un retry borné et observable pour les erreurs transitoires de pool PostgreSQL.
+- retry borné et observable des erreurs transitoires ;
- Conserver dans les résumés des compteurs distincts pour les échecs fonctionnels, les erreurs de traitement ou de stockage, les entrées récupérées après retry et les échecs finaux.
+- compteurs séparés pour erreurs fonctionnelles, traitement, stockage, reprises et échecs finaux ;
- Étudier une persistance dédiée des erreurs transitoires qui surviennent avant qu’une ligne de ledger puisse être écrite.
+- persistance éventuelle des erreurs survenant avant l’écriture du ledger.
 ## Metadata et validation réseau
 - compléter ultérieurement les validations Devnet spécialisées Metaplex Token Metadata : Print, Burn, collections avancées, pNFT delegate/lock/unlock/revoke/transfer et rule sets ;
 - maintenir une distinction stricte entre validation synthétique, simulation RPC et soumission confirmée ;
 - prévoir les scénarios Devnet desktop dès la planification de chaque nouvelle surface, pas après l’implémentation ;
 - étudier `kb-offchain-transport` sans coupler le fetch distant au replay canonique.
 ## Documentation et outils
- Refaire les scripts Python d’audit après stabilisation définitive de la structure, des targets et de la nomenclature.
+- refaire les scripts Python d’audit après stabilisation définitive de la nomenclature ;
- Maintenir un inventaire des IDL actives avec leur source, leur version ou commit, leur Program ID et les surfaces qui les utilisent.
+- maintenir un inventaire des IDL avec source, version/commit, Program ID et surfaces utilisatrices ;
 - rescanner les archives bot2 et bobobot avant de déclarer le registre Program IDs complet.
-## Transport off-chain des metadata
+## Workers et applications
- Évaluer une crate `kb-offchain-transport` générale après le pipeline metadata : fetch HTTP(S)/IPFS/Arweave, prix SOL/USD-EUR-CHF, APIs Jupiter et autres fournisseurs non Solana RPC.
+L’orientation W1/W2, rattrapage historique, application de contrôle et applications consommatrices est désormais intégrée au ROADMAP. Les points encore ouverts sont :
 - Décider séparément si cette crate accepte uniquement des lectures ou aussi des opérations off-chain authentifiées/mutables, avec contrats de sécurité distincts.
 - Borner tailles, types MIME, redirections, délais et schémas HTTP(S)/IPFS/Arweave.
 - Ne pas coupler le fetch off-chain au décodage déterministe ni au replay canonique on-chain.
-## Registre Program IDs, IDL et surfaces implémentées
+- mécanisme de notification fiable entre acquisition, stockage et décodage ;
-
+- ownership et idempotence entre W2 et le rattrapage historique ;
- Analyser `olddocs/archivekbobobot/docs/SOLSCAN_ACCOUNT_SOURCE_MATRIX.md` et les documents équivalents de bot2.
+- configuration à chaud et reprise après erreur ;
- Construire un registre croisé contenant au minimum Program ID, protocole, source vérifiée, présence d’IDL, provenance de l’IDL et chemin local.
+- métriques, files d’attente et contrats d’administration ;
- Comparer ce registre avec les constantes de `kb-program-ids`.
+- frontière entre événements temps réel et historiques OHLC.
 - Comparer chaque entrée avec les décodeurs, exécuteurs et matérialisateurs réellement présents dans `kb-lib`.
 - Distinguer les IDL provenant de Solscan, Solana Explorer, dépôts Git officiels ou autres sources vérifiées.
 - Ne pas déclarer l’inventaire complet avant le rescan des archives bot2 et bobobot.
 ## Architecture future des workers et applications
 Cette proposition doit être étudiée avant intégration au ROADMAP définitif.
 ### Worker W1 — acquisition temps réel
 - Binaire long-running utilisant `kb-onchain-transport`.
 - Écoute configurable de Program IDs, logs, comptes ou autres filtres.
 - Support progressif WebSocket, gRPC et recours HTTP/RPC lorsque nécessaire.
 - Écriture des signatures et transactions raw dans `kb-store`.
 - Modification à chaud des abonnements.
 - Notification fiable de l’arrivée de nouvelles données raw.
 - Arrêt uniquement sur demande explicite ou erreur fatale contrôlée.
 ### Worker W2 — décodage et matérialisation temps réel
 - Binaire recevant ou détectant les notifications de nouveaux raw.
 - Exécution des décodeurs et matérialisateurs activés.
 - Configuration à chaud des surfaces actives.
 - Notification après décodage et matérialisation.
 - Traitement uniquement des données reçues pendant son activité ; aucun rattrapage implicite des périodes d’arrêt.
 ### Application de rattrapage historique
 - Application ou binaire séparé, éventuellement Tauri.
 - Réutilisation des capacités Core extraction, decode replay et matérialisation.
 - Traitement des raw non pris en charge en temps réel par W2.
 - Coordination explicite pour éviter la concurrence ou la double prise en charge avec W2.
 - Backfill ciblé pour combler des périodes manquantes.
 - Décodage et matérialisation configurables comme dans W2.
 ### Pilotage W1/W2
 - Application de contrôle permettant de modifier à chaud les filtres d’acquisition, décodeurs et matérialisateurs.
 - Diagnostics, état des workers, files d’attente, erreurs et métriques.
 - Contrats d’administration séparés des contrats de données.
 ### Applications consommatrices
 - Application de trading consommant les événements temps réel de W2 et l’historique de `kb-store`.
 - Filtrage d’événements tels que nouveaux tokens, nouvelles paires, prix, migrations launchpad vers AMM, burns et changements de liquidité.
 - Construction d’historiques et OHLC depuis les matérialisations stockées.
 - Application non trading utilisant la même combinaison temps réel et historique pour visualiser les autres matérialisations.
 ### Principe de déploiement progressif
 - W1 doit pouvoir continuer à acquérir les raw pendant le développement de nouveaux décodeurs.
 - W2 et les applications peuvent être redémarrés pour charger de nouvelles surfaces.
 - Le rattrapage historique doit traiter les périodes non couvertes sans perturber le flux temps réel.
 - Les frontières de notification, ownership de traitement, idempotence et reprise doivent être définies avant implémentation.
--- a/docs/README.md
+++ b/docs/README.md
@@ -1,5 +1,5 @@
 <!-- file: docs/README.md -->
-<!-- version: 11 -->
+<!-- version: 12 -->
 # Documentation active de Khadhroony Bot3
@@ -43,19 +43,16 @@ Modèles documentaires non génératifs :
 Ces audits seront archivés sous `olddocs/archivekbot3/` lorsqu’ils auront été remplacés par des documents normatifs ou des rapports de clôture.
-## 5. Documents techniques actifs à reclasser
+## 5. Documents techniques actifs
-Les documents suivants restent actifs mais seront reclassés progressivement après correction de leurs références :
+- [`DEVNET_EXECUTION_GUIDE.md`](DEVNET_EXECUTION_GUIDE.md) ;
 - [`IDL_AUDIT.md`](IDL_AUDIT.md) ;
 - [`IDL_TO_KB_LIB_NOMENCLATURE.md`](IDL_TO_KB_LIB_NOMENCLATURE.md) ;
 - [`MISSING_PROGRAM_IDLS.md`](MISSING_PROGRAM_IDLS.md) ;
 - [`OPERATION_NAMING_CONVENTION.md`](OPERATION_NAMING_CONVENTION.md) ;
 - [`IDEA_REMINDERS.md`](IDEA_REMINDERS.md).
- `DEVNET_EXECUTION_GUIDE.md` ;
+Les idées ne rejoignent un `TODO.md` qu’après confirmation, attribution et reformulation en tâche vérifiable.
 - `PRE_062_DEVNET_VALIDATION_REPORT.md` ;
 - `IDL_AUDIT.md` ;
 - `IDL_TO_KB_LIB_NOMENCLATURE.md` ;
 - `MISSING_PROGRAM_IDLS.md` ;
 - `OPERATION_NAMING_CONVENTION.md` ;
 - `IDEA_REMINDERS.md`.
 Les idées de `IDEA_REMINDERS.md` ne doivent rejoindre un `TODO.md` de crate qu’après confirmation, attribution et reformulation en tâche vérifiable.
 ## 6. Matrices contractuelles
@@ -91,10 +88,10 @@ Les onze crates possèdent désormais `README.md`, `TODO.md`, `USAGE.md` et `CHA
 - [Extraction Core, replay et matérialisation](guides/REPLAY_CORE_EXTRACTION_AND_MATERIALIZATION.md)
 - [PostgreSQL et stockage](guides/POSTGRES_STORAGE.md)
 - [Validation Devnet](guides/DEVNET_VALIDATION.md)
- [`validation/PRE_062_DEVNET_VALIDATION_REPORT.md`](validation/PRE_062_DEVNET_VALIDATION_REPORT.md) ;
+- [Validation Metaplex Token Metadata 0.4.7](validation/V0_4_7_METAPLEX_TOKEN_METADATA_VALIDATION_REPORT.md)
 - [`validation/WEBSOCKET_MAINNET_RESEARCH_VALIDATION_REPORT.md`](validation/WEBSOCKET_MAINNET_RESEARCH_VALIDATION_REPORT.md) ;
 - [`validation/MAINNET_RESEARCH_BACKFILL_VALIDATION_SCENARIO.md`](validation/MAINNET_RESEARCH_BACKFILL_VALIDATION_SCENARIO.md) ;
 ## Prompt de reprise
- [`0.4.7 — achèvement de Metaplex Token Metadata`](../prompts/027_v0_4_7_metaplex_token_metadata_completion.md).
+- [`Prompt actif 0.4.8`](../prompts/028_v0_4_8_spl_token_metadata_and_offchain_decision.md).
--- a/docs/guides/DEVNET_VALIDATION.md
+++ b/docs/guides/DEVNET_VALIDATION.md
@@ -1,5 +1,5 @@
 <!-- file: docs/guides/DEVNET_VALIDATION.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 # Guide de validation Devnet
@@ -59,14 +59,14 @@ Le registre ElGamal ne doit pas être déclaré validé sur Devnet ou Mainnet sa
 ## Références
- `docs/PRE_062_DEVNET_VALIDATION_REPORT.md` ;
+- `docs/validation/V0_4_7_METAPLEX_TOKEN_METADATA_VALIDATION_REPORT.md` ;
 - `docs/DEVNET_EXECUTION_GUIDE.md` ;
 - `kb-pipeline-demo-scenarios/USAGE.md` ;
 - `kb-app-demo-desktop/USAGE.md`.
 ## Metaplex Token Metadata
-Les scénarios Metadata utilisent un profil Devnet existant, le runner de `kb-pipeline-demo-scenarios` et le panneau `demo_execution_metadata`. Les PDA dérivables ne doivent pas être saisis manuellement. Une fixture `Create` prépare le mint et dérive les PDA canoniques.
+Les scénarios Metadata utilisent un profil Devnet existant, le runner de `kb-pipeline-demo-scenarios` et le panneau `demo_execution_metadata`. Les PDA dérivables ne doivent pas être saisis manuellement. Chaque parcours prépare sa fixture et dérive automatiquement les PDA et comptes de postcondition nécessaires à l’étape courante.
 Une liste de profils vide est une erreur de configuration ou de raccordement et doit être signalée explicitement. Une validation réseau exige une simulation RPC réelle ; une soumission exige en plus confirmation opérateur, signature, confirmation et postconditions observées.
--- a/docs/plans/V0_4_7_METAPLEX_TOKEN_METADATA_COMPLETION_PLAN.md
+++ b/docs/plans/V0_4_7_METAPLEX_TOKEN_METADATA_COMPLETION_PLAN.md
@@ -1,680 +0,0 @@
 <!-- file: docs/plans/V0_4_7_METAPLEX_TOKEN_METADATA_COMPLETION_PLAN.md -->
 <!-- version: 14 -->
 # Plan `0.4.7` — achèvement de Metaplex Token Metadata
 ## 1. Statut du document
 Ce document constitue le livrable de planification de `0.4.7-pre.001`.
 Il est temporaire et normatif pendant le développement de `0.4.7`. Il devra être mis à jour lorsque les preuves techniques imposent un changement d’ordre ou de périmètre, puis archivé sous `olddocs/archivekbot3/` pendant la prerelease finale après transfert de ses informations durables vers les documents actifs appropriés.
 Aucune capacité fonctionnelle Metaplex nouvelle n’est introduite par cette prerelease. Le correctif `pre.001-delta-fix-001` intègre la relecture systématique de tous les documents actifs sous `docs/` et aligne ce plan sur leurs règles transversales.
 ## 2. Conclusion de l’audit initial
 La reprise part de la base bot3 complète migrée depuis bot2. La migration elle-même n’est pas partielle.
 La surface existante ne doit pas être réimplémentée :
 - le Program ID canonique est enregistré ;
 - le décodeur d’instructions est enregistré au runtime ;
 - les 58 discriminants publics `0..57` sont inventoriés dans la matrice active ;
 - les instructions actuelles et historiques sont distinguées ;
 - les principales familles de comptes Metaplex sont décodées avec validation d’owner, PDA, seeds, longueurs et suffixes ;
 - un modèle canonique de comptes actifs, expérimentaux et historiques existe ;
 - la matérialisation de l’état metadata principal et des comptes canoniques existe déjà ;
 - la séparation avec les metadata incorporées de Token-2022 est explicite ;
 - l’exécuteur est enregistré mais reste réservé : support `Maybe`, zéro instruction construite et payload `reserved_executor` ;
 - aucune orchestration stateful Metaplex dédiée n’est encore présente dans `kb-pipeline` ;
 - aucun scénario CLI Metaplex réutilisable ni panneau desktop d’exécution Metaplex n’est encore présent.
 La version `0.4.7` doit donc achever la surface autour de l’existant, pas recommencer le décodeur ou les projections déjà prouvées.
 ## 3. Frontière fermée de la version
 ### 3.1 Inclus
 - audit de propriété des faits matérialisés ;
 - complétion ciblée des faits metadata, admin, lifecycle et risk/compliance réellement absents ;
 - classification exécutable, decode-only ou non supportée de chaque instruction ;
 - intents typés et builders de toutes les opérations officiellement constructibles, non obsolètes et non remplacées ;
 - préflight borné, politique de confirmation, simulation obligatoire et plafonds de dépense ;
 - lectures stateful et corrélations de comptes Metaplex ;
 - postconditions et postvalidation ;
 - intégration replay et matérialisation idempotente ;
 - scénarios UI Devnet/Testnet dans le desktop, fixtures et validations automatisées parallèles dans `kb-pipeline-demo-scenarios` ;
 - adaptateurs Tauri et panneaux strictement nécessaires ;
 - documentation et clôture de version.
 ### 3.2 Exclus
 - JSON off-chain référencé par URI ;
 - fetch HTTP, IPFS ou Arweave ;
 - création de `kb-offchain-transport` ;
 - SPL Token Metadata ;
 - Metaplex Core ;
 - Metaplex Bubblegum au-delà des frontières explicitement nécessaires pour classer une instruction bridge ;
 - réécriture des décodeurs ou comptes déjà couverts sans écart démontré ;
 - validation réseau déclarée lorsque les fixtures ou autorités nécessaires ne sont pas disponibles.
 Les sujets off-chain et SPL Token Metadata restent affectés à `0.4.8`.
 ## 4. Inventaire de la base réutilisable
 ### 4.1 Instructions
 La matrice active inventorie 58 instructions :
 - 41 actuelles ;
 - 15 historiques ;
 - 1 historique dépréciée ;
 - 1 bridge actuelle liée à Bubblegum.
 Les familles déjà décodées comprennent notamment :
 - création et mise à jour metadata V1, V2, V3 et wrappers modernes ;
 - vérification, dévérification et administration de collections ;
 - collections dimensionnées ;
 - autorités d’usage et utilisation ;
 - signature de créateur et primary sale ;
 - normalisation, token standard et unverification de créateur ;
 - master editions, printed editions et conversions historiques ;
 - délégation, révocation, transfert, burn, lock, unlock et fermeture ;
 - freeze/thaw historiques ;
 - escrow et collect ;
 - wrappers modernes `Create`, `Mint`, `Print`, `Update`, `Use`, `Verify` et `Unverify` ;
 - migration, resize et gaps historiques finaux.
 Le statut `decode: unspecified` encore présent dans certaines entrées de matrice est un défaut documentaire de classification, pas une preuve d’absence automatique dans le code. Il devra être résolu par confrontation entre matrice, registre du décodeur et tests avant toute modification fonctionnelle.
 ### 4.2 Comptes
 Les familles déjà couvertes comprennent :
 - Metadata ;
 - Edition et Master Edition ;
 - Edition Marker ;
 - Token Record programmable ;
 - Metadata Delegate Record et Holder Delegate Record ;
 - Collection Authority Record et Use Authority Record ;
 - Token Owned Escrow ;
 - Reservation List historique.
 Le modèle canonique porte déjà :
 - identité et Program ID ;
 - provenance ;
 - lifecycle actif, expérimental ou historique ;
 - politique de matérialisation ;
 - politique d’exécution candidate ou interdite pour l’historique.
 ### 4.3 Matérialisation
 Les fonctions existantes matérialisent déjà :
 - les metadata incorporées Token-2022 sous le domaine distinct `spl_token_2022_embedded_metadata` ;
 - l’état Metadata Metaplex sous le domaine `metaplex_token_metadata` ;
 - les autres snapshots canoniques de comptes Metaplex ;
 - une surface de risque metadata dédiée existe mais reste à auditer pour sa couverture réelle.
 L’audit de `0.4.7` doit produire une table de propriété unique par fait avant d’ajouter une projection.
 ### 4.4 Exécution
 L’exécuteur `ExMetadataMetaplexTokenMetadataExecutor` existe mais est réservé :
 - il reconnaît le Program ID ;
 - il retourne `Maybe` pour cette surface ;
 - il ne construit aucune instruction ;
 - il ne possède pas encore d’intents, de builders, de préflight ou de postconditions Metaplex.
 ### 4.5 Pipeline et applications
 L’extraction Core, le replay générique, le stockage canonique et la matérialisation générique sont réutilisables.
 Les manques Metaplex spécifiques sont :
 - contrat de lecture stateful ;
 - corrélation mint/metadata/edition/token record/collection/authority/rule set ;
 - orchestration de préparation et d’exécution ;
 - postvalidation ;
 - diagnostics structurés ;
 - scénarios Devnet/Testnet et CLI ;
 - adaptateurs et panneaux desktop.
 ## 5. Liste fermée des manques réels
 Le développement fonctionnel de `0.4.7` est limité aux éléments suivants.
 ### 5.1 Contrat de couverture
 1. Résoudre chaque statut de matrice incomplet ou ancien.
 2. Attribuer à chaque instruction un statut exact :
   - `executable_current` ;
   - `decode_only_historical` ;
   - `decode_only_bridge_boundary` ;
   - `unsupported_with_reason` ;
   - `executable_deprecated` ;
   - `decode_only_replaced`.
 3. Attribuer à chaque instruction exécutable : builder officiel, comptes, signers, préconditions, confirmation et postconditions.
 4. Maintenir l’inventaire exhaustif `0..57`.
 ### 5.2 Matérialisation
 1. Produire la table de propriété des faits.
 2. Vérifier la couverture de : nom, symbole, URI, seller fee, créateurs, collection, uses, token standard, mutabilité et programmable config.
 3. Vérifier la couverture de : update authority, collection authority, delegates et changements d’autorité.
 4. Vérifier la couverture lifecycle : création, mise à jour, vérification, édition, burn, lock/unlock et transitions prouvées.
 5. Vérifier la couverture risk/compliance : royalties, créateurs non vérifiés, mutabilité, rule sets et délégations sensibles.
 6. Ajouter uniquement les faits absents et stables.
 7. Ajouter les tests de non-fusion avec Token-2022 metadata.
 ### 5.3 Exécuteur
 1. Définir les intents typés.
 2. Définir les builders à partir de `mpl-token-metadata` officiel pour toute opération officiellement constructible, non obsolète et non remplacée.
 3. Vérifier l’ordre des comptes et les signers exacts.
 4. Calculer les coûts contrôlables et plafonds de dépense.
 5. Rendre la simulation obligatoire avant soumission.
 6. Définir les confirmations opérateur sensibles.
 7. Interdire explicitement l’exécution des variantes historiques, obsolètes ou remplacées lorsque leur reconstruction n’est plus légitime.
 8. Remplacer le support `Maybe` réservé par une décision déterministe fondée sur l’intent.
 9. Interdire tout `Unsupported(reason)` motivé seulement par une priorité, un report ou une opération non retenue.
 ### 5.4 Stateful, préflight et postconditions
 1. Lire les comptes nécessaires avec bornes de taille et owner exact.
 2. Recalculer les PDA et seeds.
 3. Vérifier les relations mint, metadata, edition, token account, collection et authority.
 4. Vérifier mutabilité, vérification, délégation, token standard et programmable config.
 5. Vérifier les rule sets et comptes d’autorisation lorsqu’ils s’appliquent.
 6. Définir les cas `not_applicable` au lieu de masquer une absence de preuve.
 7. Relire l’état après confirmation et vérifier les postconditions opérationnelles.
 ### 5.5 Pipeline généraliste
 `kb-pipeline` doit rester utilisable depuis toute application, service, worker, CLI ou test, sans hypothèse propre à Devnet/Testnet.
 1. Ajouter les DTO et résultats Metaplex strictement nécessaires.
 2. Ajouter la corrélation stateful.
 3. Ajouter la préparation et l’orchestration d’exécution.
 4. Ajouter la postvalidation.
 5. Raccorder les observations au replay et à la matérialisation idempotente.
 6. Fournir des diagnostics stables pour scénarios et desktop.
 ### 5.6 Scénarios Devnet/Testnet et desktop
 Les scénarios UI Devnet/Testnet restent dans `kb-app-demo-desktop`. `kb-pipeline-demo-scenarios` fournit en parallèle les fixtures, aides de campagne et tests automatisés capables de reproduire les mêmes parcours à partir des APIs généralistes de `kb-pipeline`.
 1. Conserver et compléter dans le desktop les scénarios UI simulation-only par défaut.
 2. Ajouter dans `kb-pipeline-demo-scenarios`, lorsque cela apporte une preuve utile à `0.4.7`, des tests automatisés Metaplex équivalents aux parcours desktop ; cette pratique doit ensuite être généralisée pendant la série `0.5.x`.
 3. Ajouter les fixtures synthétiques et fixtures réseau disponibles.
 4. Produire des résultats structurés et preuves de postcondition communs ou comparables entre tests automatisés et démonstrations UI.
 5. N'étendre `kb-pipeline-demo-scenarios-cli` que lorsqu'une préparation de fixture exige réellement une commande dédiée ; ne pas en faire implicitement le lanceur général de tous les scénarios.
 6. Ajouter uniquement les commandes Tauri et panneaux nécessaires, tout en conservant dans le desktop les états et séquences propres à l'expérience UI.
 7. Maintenir les primitives et orchestrations généralistes hors du desktop, dans `kb-pipeline` ou la crate métier propriétaire.
 ## 6. Choix structurants
 ### 6.1 Granularité des intents
 **Option A — un intent par instruction Metaplex**
 - fidélité maximale au SDK ;
 - surface publique volumineuse ;
 - duplication probable entre instructions historiques et wrappers modernes.
 **Option B — intents métier canoniques compilés vers une instruction actuelle**
 - API plus stable ;
 - meilleure séparation entre intention et génération SDK ;
 - nécessite une table explicite de résolution et empêche de choisir arbitrairement une variante historique.
 **Option C — intents hybrides**
 - intents métier pour les opérations communes ;
 - intents spécialisés pour les opérations Metaplex sans équivalent métier simple ;
 - complexité intermédiaire.
 **Recommandation : Option C.** Elle correspond à l’architecture d’exécution existante, limite l’exposition des détails historiques et conserve les opérations programmables spécifiques.
 ### 6.2 Périmètre exécutable initial
 **Option A — toutes les instructions actuelles en une seule campagne**
 - couverture maximale immédiate ;
 - risque élevé de validation superficielle et de prereleases trop larges.
 **Option B — noyau sûr puis extensions par familles**
 - commence par create/update et opérations administratives dont les contrats sont les plus directement vérifiables ;
 - ajoute ensuite collections, délégations, programmable NFT, éditions, uses et escrow ;
 - permet une validation stateful progressive.
 **Option C — uniquement les wrappers modernes**
 - surface plus petite ;
 - couverture insuffisante de plusieurs opérations actuelles sans wrapper moderne complet.
 **Recommandation : Option B.** Aucune famille ne devient exécutable avant preuve complète de ses comptes, signers, préflight et postconditions.
 ### 6.3 Propriété des faits matérialisés
 **Option A — un matérialiseur Metaplex monolithique**
 - simple à appeler ;
 - mélange metadata, administration, lifecycle et risque.
 **Option B — propriété par domaine fonctionnel existant**
 - metadata possède les attributs descriptifs ;
 - admin possède autorités et délégations ;
 - lifecycle possède les transitions prouvées ;
 - risk/compliance possède uniquement les signaux dérivés ;
 - exige une table anti-duplication.
 **Recommandation : Option B.** Elle respecte la règle de propriétaire unique et les frontières déjà utilisées par le workspace.
 ### 6.4 Rule sets programmables
 **Option A — accepter un rule set opaque et transmettre les comptes fournis**
 - mise en œuvre rapide ;
 - ne prouve pas l’autorisation et affaiblit le fail-closed.
 **Option B — limiter l’envoi programmable aux rule sets et authorization data vérifiables**
 - cohérent avec simulation-first et préflight strict ;
 - le builder universel reste présent lorsqu’il est officiellement constructible ; l’envoi peut rester interdit faute de preuve stateful suffisante.
 **Recommandation : Option B.** Une opération programmable officiellement constructible conserve son builder, mais sa préparation ou son envoi échoue explicitement lorsque le rule set ou les données d’autorisation ne peuvent pas être vérifiés. Cette limite ne doit pas être confondue avec une absence d’implémentation de l’exécuteur.
 ### 6.5 Validation réseau
 **Option A — exiger Devnet pour toute opération exécutable**
 - preuve forte ;
 - peut bloquer les opérations nécessitant des actifs, autorités ou rule sets indisponibles.
 **Option B — niveaux de preuve distincts**
 - builder parity et tests synthétiques obligatoires ;
 - simulation réseau lorsque les comptes existent ;
 - envoi et postcondition uniquement avec fixture contrôlée ;
 - statut réseau exact consigné par opération.
 **Décision révisée : validation Devnet obligatoire pour la surface courante.** Les niveaux de preuve restent distincts, mais `0.4.7` ne peut plus être clôturée tant que les opérations `executable_current` n'ont pas été exercées sur Devnet par des scénarios réels. Les opérations `executable_deprecated` restent hors campagne réseau obligatoire et ne sont exécutées que dans une campagne séparée, volontaire et explicitement approuvée. Une impossibilité réseau démontrée doit être documentée opération par opération et ne peut pas être remplacée par une preuve synthétique.
 ## 7. Ordonnancement proposé par prerelease
 La numérotation ci-dessous est un plan fermé initial. Elle peut être regroupée uniquement si deux lots restent cohérents et si le plan est mis à jour avant livraison.
 ### `0.4.7-pre.001` — planification et inventaire
 **Travaux**
 - audit de la base migrée ;
 - inventaire instructions, comptes, matérialisations, exécuteur, pipeline et applications ;
 - liste fermée des manques ;
 - options architecturales et recommandations ;
 - plan par prerelease.
 **Acceptation**
 - aucun code fonctionnel Metaplex ajouté ;
 - plan accepté avant `pre.002` ;
 - confirmation qu’aucune capacité existante ne sera réimplémentée sans écart prouvé.
 ### `0.4.7-pre.002` — contrat de couverture et propriété des faits
 **Dépendance** : acceptation de `pre.001`.
 **Travaux**
 - corriger les statuts incomplets de la matrice ;
 - classer les 58 instructions ;
 - produire la table instruction → builder/comptes/signers/préflight/postconditions ;
 - produire la table fait → propriétaire unique ;
 - compléter uniquement les projections stables manquantes et leurs tests.
 **Acceptation**
 - matrice exhaustive et sans statut ambigu ;
 - aucune duplication silencieuse avec Token-2022 ;
 - tests de matérialisation et d’idempotence ciblés validés.
 ### `0.4.7-pre.003` — fondations de l’exécuteur et noyau metadata
 **Dépendance** : matrice et propriété des faits stabilisées.
 **Travaux**
 - intents communs, enveloppe d’exécution et politiques de coût ;
 - builders des wrappers courants `Create` (42) et `Update` (50), sans reconstruire les anciennes instructions remplacées ;
 - signers, comptes, PDA et mutabilité ;
 - simulation obligatoire ;
 - postconditions de création et mise à jour.
 **Acceptation**
 - parity tests avec builders officiels ;
 - erreurs fail-closed avant signature ;
 - variantes historiques rejetées explicitement.
 ### `0.4.7-pre.004` — collections, créateurs et autorités — implémentée, validation locale requise
 **Travaux**
 - wrappers courants `Verify` et `Unverify` pour collections et créateurs ;
 - wrapper courant `Delegate`/`Revoke` pour les autorités de collection lorsque la variante correspondante est prouvée ;
 - aucune reconstruction de `SignMetadata`, des instructions sized collection historiques ni de `UpdatePrimarySaleHappenedViaToken` ;
 - confirmations opérateur et postconditions.
 **Acceptation**
 - autorités et records corrélés statefully ;
 - transitions de vérification prouvées ;
 - mauvais owners, PDA, authority et collection rejetés.
 ### `0.4.7-pre.005` — programmable NFTs et délégations — réalisée
 **Travaux**
 - delegate/revoke ;
 - transfer, burn, lock, unlock et close accounts officiellement constructibles ;
 - token records, programmable config, rule sets et authorization data ;
 - politique de confirmation renforcée.
 **Acceptation**
 - aucune transmission opaque de rule set non vérifié ;
 - simulation et postconditions par opération ;
 - builders présents pour toute opération officiellement constructible ; préparation ou envoi refusé avec une raison stable lorsque les préconditions stateful ne sont pas prouvables.
 ### `0.4.7-pre.006` — editions, use, escrow et opérations restantes — réalisée
 **Travaux**
 - master edition et printed edition actuelles ;
 - use authority et utilization ;
 - escrow et collect ;
 - create/mint/print/update/use/verify/unverify wrappers restants ;
 - resize/migrate et toute autre opération restante lorsque leurs contrats officiels permettent une construction exacte ;
 - classification définitive des instructions historiques et bridge.
 **Acceptation**
 - la surface `kb-lib` est fermée pour les 58 instructions : chaque opération officiellement constructible courante ou obsolète possède un intent et un builder ; seules les versions remplacées et la frontière Bubblegum restent sans builder ;
 - les opérations obsolètes encore officiellement constructibles sont exécutables sous `#[deprecated]` et approbation opérateur explicite ; les versions remplacées ne sont pas réexposées ;
 - aucun `Unsupported(reason)` ne masque une opération simplement non réalisée ou reportée ;
 - contrats d’edition marker et supply bornés ;
 - frontières Bubblegum explicites ;
 - `pre.007` ne doit normalement plus ajouter de builder Metaplex, sauf correction d’un écart démontré dans la matrice.
 ### `0.4.7-pre.007` — intégration au pipeline généraliste stateful
 **Dépendance** : intents et familles exécutables stabilisés.
 **Travaux**
 - lectures stateful bornées ;
 - corrélation des comptes ;
 - préparation, simulation, confirmation, soumission et postvalidation ;
 - diagnostics structurés ;
 - replay et matérialisation idempotente.
 **Acceptation**
 - résultats déterministes et exploitables depuis toute application, service, worker, CLI ou test, sans dépendance aux scénarios de démonstration ;
 - tests de conflits Metaplex/Token-2022 ;
 - replay PostgreSQL idempotent.
 ### `0.4.7-pre.008` — fixtures et validations automatisées Devnet/Testnet
 **Travaux**
 - fixtures NFT, SFT, fungible, collection et pNFT ;
 - scénarios synthétiques de démonstration ;
 - aides de préparation des campagnes Devnet/Testnet ;
 - tests automatisés Metaplex reproduisant, lorsque pertinent pour `0.4.7`, les parcours destinés au desktop ;
 - simulation-only par défaut dans les tests et campagnes ;
 - extension ciblée du CLI uniquement si une fixture Metaplex ne peut pas être préparée proprement autrement ;
 - résultats et preuves de postcondition.
 **Acceptation**
 - couverture automatisée parallèle disponible pour les parcours Metaplex retenus, sans suppression ni migration des scénarios UI du desktop ;
 - tests et campagnes fondés exclusivement sur les APIs généralistes de `kb-pipeline` et les contrats métier propriétaires ;
 - aucune soumission réelle automatique sans garde-fou explicite adapté aux tests réseau ;
 - statuts de validation réseau exacts.
 ### `0.4.7-pre.009` — desktop
 **Dépendance** : APIs généralistes et contrats de fixtures stabilisés.
 **Travaux**
 - conservation et achèvement des scénarios UI Devnet/Testnet dans le desktop ;
 - adaptateurs Tauri minces autour des APIs généralistes ;
 - panneaux nécessaires ;
 - affichage préflight, simulation, confirmation et postconditions ;
 - aucun déplacement de logique métier vers l’application.
 **Acceptation**
 - audits Tauri/frontend validés ;
 - fonctionnement manuel des parcours retenus ;
 - réouverture et état applicatif cohérents.
 ### `0.4.7-pre.010` — corpus et validations croisées — réalisée, validation locale requise
 **Travaux**
 - outer et CPI ;
 - succès et échec transactionnel ;
 - Program ID, owner, PDA, comptes, payload, suffixe et discriminant invalides ;
 - corpus NFT/SFT/fungible/collection/pNFT ;
 - simulations, envois disponibles et postconditions ;
 - rapports de validation.
 **Acceptation**
 - aucune validation réseau surdéclarée ;
 - matrice, tests, rapports et runtime alignés ;
 - écarts résiduels fermés ou reportés explicitement.
 ### `0.4.7-pre.011` — infrastructure et premières campagnes Devnet réelles
 **Dépendance** : exécuteur, pipeline, fixtures synthétiques et desktop stabilisés.
 **Travaux**
 - rouvrir la version après le rejet de la clôture prématurée ;
 - produire une liste machine-readable fermée des 20 opérations `executable_current` ;
 - définir pour chacune la fixture, les autorités, les fonds, les comptes préexistants, les effets attendus et la stratégie de nettoyage ;
 - ajouter les primitives réutilisables de préparation de fixtures Devnet dans `kb-pipeline-demo-scenarios` ;
 - exécuter réellement sur Devnet un premier lot cohérent couvrant au minimum création, mise à jour, vérification et révocation de vérification ;
 - enregistrer endpoint/cluster, signature, slot, logs de simulation, résultat de soumission, états avant/après et postconditions ;
 - interdire qu'un résultat synthétique puisse satisfaire un contrat de preuve réseau.
 **Acceptation**
 - le profil et la base Devnet sont chargés et vérifiés ;
 - chaque scénario du premier lot effectue au minimum une simulation RPC réelle ;
 - les scénarios mutateurs retenus effectuent une soumission réelle après garde-fou explicite ;
 - les preuves sont persistées dans des résultats structurés et réutilisables ;
 - aucune opération dépréciée n'est exécutée automatiquement.
 ### `0.4.7-pre.012` — couverture Devnet des opérations courantes restantes
 **Travaux**
 - compléter les campagnes automatisées pour toutes les opérations `executable_current` restantes ;
 - couvrir les familles metadata, collections/créateurs, délégations, programmable NFT, éditions, uses, escrow et maintenance de comptes lorsque leurs préconditions sont disponibles ;
 - créer ou réutiliser des fixtures NFT, SFT, fungible, collection et pNFT ;
 - tester les échecs attendus : mauvaise autorité, mauvais PDA, owner invalide, rule set incohérent, comptes manquants et plafond de dépense ;
 - conserver simulation-only par défaut, avec soumission activée uniquement par une option explicite de campagne ;
 - consigner toute impossibilité Devnet démontrée avec cause externe précise, tentative reproductible et preuve associée.
 **Acceptation**
 - les 20 opérations `executable_current` ont chacune un scénario Devnet réel ;
 - chaque opération possède une simulation RPC observée ou une impossibilité réseau démontrée et documentée ;
 - chaque opération mutatrice réalisable possède au moins une soumission confirmée et une postcondition stateful observée ;
 - les résultats ne dépendent pas du desktop et utilisent exclusivement les APIs généralistes de `kb-pipeline`.
 ### `0.4.7-pre.013` — démonstrations desktop Devnet et validation croisée finale
 **Travaux**
 - raccorder le panneau Metadata aux scénarios réseau réutilisables, sans déplacer leur logique métier dans Tauri ;
 - conserver les scénarios UI dans `kb-app-demo-desktop` et les tests automatisés parallèles dans `kb-pipeline-demo-scenarios` ;
 - afficher profil, cluster, base, wallet, fixture, mode simulation/soumission, signature, slot, logs et postconditions ;
 - permettre l'exécution manuelle des opérations courantes retenues depuis le desktop avec confirmation opérateur ;
 - comparer les résultats automatisés et desktop sur les mêmes contrats de preuve ;
 - exécuter les validations croisées outer/CPI, succès/échec et replay PostgreSQL idempotent.
 **Acceptation**
 - le mode Devnet déclenche réellement les appels RPC et ne se limite jamais à changer un JSON frontend ;
 - les scénarios desktop et automatisés produisent des preuves compatibles ;
 - les 20 opérations courantes ont un statut réseau final exact ;
 - les opérations dépréciées restent clairement séparées et désactivées par défaut.
 ### `0.4.7-pre.014` — clôture
 **Travaux**
 - aucune nouvelle surface majeure ;
 - tests finaux et audits de conformité ;
 - documentation générale et des crates ;
 - nettoyage des TODO, outils temporaires et références obsolètes ;
 - archivage du présent plan et des rapports devenus historiques ;
 - préparation seulement à ce stade du prompt `0.4.8`, avec prerelease initiale de planification et prerelease finale de clôture ;
 - livraison finale.
 **Acceptation**
 - commandes de validation finales réussies ;
 - preuves Devnet des opérations courantes alignées avec code, matrices, registres, bindings et documentation ;
 - aucun cas `executable_current` laissé avec un statut réseau ambigu ;
 - archive finale conforme aux règles du workspace.
 ## 8. Dépendances et ordre critique
 L’ordre critique est :
 1. classification exhaustive ;
 2. propriété des faits ;
 3. intents et builders ;
 4. préflight et postconditions ;
 5. pipeline stateful ;
 6. fixtures et validations automatisées Devnet/Testnet ;
 7. scénarios UI desktop ;
 8. campagnes Devnet réelles automatisées ;
 9. démonstrations desktop Devnet et validation croisée finale ;
 10. clôture.
 Le desktop ne doit pas précéder la stabilisation des APIs généralistes et des contrats de fixtures. `kb-pipeline-demo-scenarios` ne doit pas absorber une orchestration généraliste ni remplacer les scénarios UI du desktop. Le pipeline ne doit pas autoriser la préparation ou l’envoi d’une opération avant stabilisation de son intent et de son contrat stateful. Une instruction ne doit pas être déclarée envoyable uniquement parce qu’un builder SDK existe, mais tout builder officiellement constructible doit être implémenté dans `kb-lib` sauf statut historique, obsolète ou remplacé documenté.
 ## 9. Critères globaux d’acceptation
 `0.4.7` est fonctionnellement achevée lorsque :
 - les 58 instructions sont classées sans ambiguïté ;
 - les comptes pris en charge conservent owners, PDA, seeds, bornes et variantes historiques ;
 - les faits matérialisés ont un propriétaire unique ;
 - toutes les opérations officiellement constructibles, non obsolètes et non remplacées possèdent intents, builders et contrats exacts ; leurs signers, coûts, préflight, simulation, confirmation et postconditions sont appliqués dès qu’ils sont pertinents ;
 - les opérations historiques sont decode-only ;
 - le pipeline généraliste expose des résultats structurés et idempotents sans dépendance à un cluster de démonstration ;
 - les scénarios UI Devnet/Testnet restent disponibles dans le desktop ;
 - les parcours retenus disposent en parallèle d’une couverture automatisée dans `kb-pipeline-demo-scenarios` lorsque cette preuve est nécessaire à `0.4.7` ;
 - le desktop reste propriétaire de ses états et séquences UI, sans absorber les primitives généralistes ;
 - les conflits entre sources metadata restent explicites ;
 - le fetch off-chain est absent ;
 - chaque validation réseau est déclarée selon la preuve réellement obtenue.
 ## 10. Validations prévues
 Pendant chaque prerelease :
 ```bash
 cargo fmt --all
 cargo check --workspace
 cargo clippy --all-targets
 python3 scripts/audit_rust_workspace_rules.py
 ```
 Les tests ciblés des crates modifiées sont obligatoires avant livraison du delta.
 À la clôture :
 ```bash
 cargo fmt --all
 cargo check --workspace
 cargo clippy --all-targets
 python3 scripts/audit_rust_workspace_rules.py
 cargo test --workspace
 ```
 Si le desktop est modifié :
 ```bash
 cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
 ```
 ## 11. Décisions requises avant `pre.002`
 Le développement fonctionnel peut commencer après acceptation des recommandations suivantes :
 1. intents hybrides, métier lorsque possible et spécialisés lorsque nécessaire ;
 2. activation progressive par familles, avec fermeture exhaustive de toute la surface exécutable à la fin de `pre.006` ;
 3. propriété des faits par domaines metadata/admin/lifecycle/risk ;
 4. rule sets programmables fail-closed ;
 5. niveaux de preuve distincts pour les validations synthétiques, simulation réseau et envoi réel ;
 6. séquence de prereleases `pre.002` à `pre.014` décrite ci-dessus, la clôture étant repoussée à `pre.014`.
 ## État de `0.4.7-pre.007`
 - lectures stateful bornées dans `kb-pipeline` ;
 - préflight généraliste lié aux plans `kb-lib` ;
 - orchestration simulation-first, résolution des signers et postconditions explicites ;
 - aucune dépendance vers `kb-pipeline-demo-scenarios` ;
 - les fixtures et campagnes réseau restent réservées à `pre.008`.
 ## État de `0.4.7-pre.008`
 - inventaire synthétique fermé pour NFT, SFT, fungible, collection et pNFT ;
 - matrice automatisée de validation Metaplex avec preuves bornées ;
 - aucune soumission automatique ;
 - CLI inchangé faute de besoin démontré pour une fixture Metaplex dédiée ;
 - scénarios UI du desktop conservés pour `pre.009`.
 ## État de `0.4.7-pre.009`
 - fenêtre desktop Metaplex dédiée ;
 - adaptateurs Tauri limités aux contrats de scénarios ;
 - affichage des exigences de préflight, simulation-first et postconditions ;
 - scénario sélectionné restauré à la réouverture ;
 - aucune logique métier dupliquée et aucune soumission automatique.
 ## État de `0.4.7-pre.011`
 - matrice fermée des 20 opérations courantes ;
 - runner Devnet réel générique avec simulation RPC, soumission contrôlée, confirmation et lectures stateful avant/après ;
 - premier lot attribué à `Create`, `Update`, `Verify` et `Unverify` ;
 - preuves réseau encore `not_run` jusqu’aux exécutions locales et à la validation des postconditions métier ;
 - opérations dépréciées refusées dans les campagnes automatiques.
 ## État de `0.4.7-pre.012`
 - le runner RPC réutilisable accepte les 20 opérations `executable_current` ;
 - la matrice ne contient plus aucune opération au statut `planned` ;
 - un test opt-in permet de fournir l’intent typé et les lectures stateful par JSON ;
 - les statuts réseau restent `not_run` jusqu’aux campagnes locales avec fixtures ;
 - la préparation des fixtures et la collecte des preuves observées restent obligatoires avant `pre.013`.
--- a/docs/validation/V0_4_7_METAPLEX_TOKEN_METADATA_VALIDATION_REPORT.md
+++ b/docs/validation/V0_4_7_METAPLEX_TOKEN_METADATA_VALIDATION_REPORT.md
@@ -0,0 +1,44 @@
 <!-- file: docs/validation/V0_4_7_METAPLEX_TOKEN_METADATA_VALIDATION_REPORT.md -->
 <!-- version: 1 -->
 # Validation fonctionnelle — Metaplex Token Metadata 0.4.7
 ## Périmètre
 La version couvre le décodage d’instructions et de comptes, les PDA et owners, les matérialisations, les builders et l’exécuteur, l’orchestration stateful, les scénarios synthétiques et le runner Devnet desktop.
 ## Validations réseau observées
 Des parcours représentatifs ont été exécutés avec :
 - préparation Rust native du mint SPL ;
 - simulation RPC exacte ;
 - soumission explicitement confirmée ;
 - confirmation Devnet ;
 - lectures de postcondition ;
 - matérialisation optionnelle.
 Les opérations observées comprennent `Create`, `UpdateAsUpdateAuthorityV2` et la transition vers des metadata immutables, notamment sur les parcours NFT et fungible.
 ## Qualification des autres opérations
 Les autres opérations exposées par l’exécuteur restent validées par leurs builders, matrices, tests unitaires, tests stateful et scénarios synthétiques. Leur validation Devnet spécialisée est reportée lorsque les fixtures nécessitent des chaînes de comptes supplémentaires : édition imprimée, burn, collection parent/membre, token records pNFT, délégations et rule sets.
 Ce report ne doit pas être interprété comme une preuve réseau. Les statuts de validation doivent continuer à distinguer synthétique, simulé, soumis, non applicable et indisponible.
 ## Limites
 - aucun fetch HTTP/IPFS/Arweave ;
 - aucune fusion avec SPL Token Metadata ou metadata Token-2022 ;
 - aucune déclaration de validation réseau du registre ElGamal.
 ## Contrôles de clôture
 ```bash
 cargo fmt --all
 cargo check --workspace
 cargo clippy --all-targets
 python3 scripts/audit_rust_workspace_rules.py
 cargo test --workspace
 cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
 ```
--- a/kb-app-demo-desktop/CHANGELOG.md
+++ b/kb-app-demo-desktop/CHANGELOG.md
@@ -1,9 +1,15 @@
 <!-- file: kb-app-demo-desktop/CHANGELOG.md -->
-<!-- version: 23 -->
+<!-- version: 24 -->
 # CHANGELOG — kb-app-demo-desktop
-## 0.4.7-pre.15
+## 0.4.7-pre.016
 - généralise README et USAGE sans classement par prerelease ;
 - nettoie le TODO et reporte les validations Devnet spécialisées ;
 - archive les rapports de travail `0.4.7` au profit du rapport consolidé.
 ## 0.4.7-pre.015
 - expose l’étape NFT « rendre les metadata immutables » dans le runner cohérent ;
 - prépare cette étape depuis le contexte confirmé de l’étape précédente ;
 - maintient les lectures de postcondition et la matérialisation sur le PDA metadata.
@@ -28,27 +34,29 @@
 - rend la matérialisation utilisable sans saisie manuelle des comptes de postcondition ;
 - expose uniquement le parcours Devnet NFT actuellement entièrement préparé (`create` puis `update`).
-### 0.4.7-pre.13 fix-011
+### 0.4.7-pre.013-fix-011
 - remplace la préparation Metaplex fondée sur `solana-keygen`, `solana` et `spl-token` par une transaction Rust native ;
 - crée le mint par `SystemCreateAccount` puis `SPL Token InitializeMint2` dans un même message simulé, signé et confirmé ;
 - utilise explicitement le wallet du profil comme mint authority et freeze authority ;
 - conserve le keypair du mint dans `kb-wallet` sans exposer ni déléguer ses secrets à une CLI externe.
-### 0.4.7-pre.013-fix.009
+## 0.4.7-pre.013-fix-009
 - affiche les parcours, fixtures et états Metaplex dans le panneau Devnet ;
 - ajoute l’option de matérialisation des snapshots confirmés ;
 - expose le nombre de projections produites dans les résultats.
-## 0.4.7-pre.13-fix.008 — les fixtures `Create` utilisent un nouveau mint à freeze authority active, valident owner/layout/décimales/supply/autorités avant simulation et empêchent la réutilisation d’un intent précédent lorsqu’aucun modèle nommé n’existe.
+## 0.4.7-pre.013-fix-008 — les fixtures `Create` utilisent un nouveau mint à freeze authority active, valident owner/layout/décimales/supply/autorités avant simulation et empêchent la réutilisation d’un intent précédent lorsqu’aucun modèle nommé n’existe.
-## 0.4.7-pre.13-fix.005 — alignement du panneau Metadata sur les paramètres communs Devnet, boutons simulation/soumission séparés et correction du contrat dry-run après simulation.-fix.4
+## 0.4.7-pre.013-fix-005
 - alignement du panneau Metadata sur les paramètres communs Devnet, boutons simulation/soumission séparés et correction du contrat dry-run après simulation ;
 - correction de l’initialisation du panneau Metadata : ajout des contrôles HTML du journal attendus par le TypeScript ;
 - ajout d’un test de contrat empêchant la disparition des sélecteurs de profil, scénario, opération et journal.
-## 0.4.7-pre.13-fix.002
+## 0.4.7-pre.013-fix-002
 - Ajout du guide intégré, du journal d’exécution et de titres explicites pour les résultats JSON Metaplex.
 - Ajout d’un préparateur idempotent de fixture `Create` : mint SPL classique Devnet, PDA metadata et master edition dérivés, intent JSON prêt à simuler.
--- a/kb-app-demo-desktop/README.md
+++ b/kb-app-demo-desktop/README.md
@@ -1,5 +1,5 @@
 <!-- file: kb-app-demo-desktop/README.md -->
-<!-- version: 6 -->
+<!-- version: 7 -->
 # kb-app-demo-desktop
@@ -21,7 +21,7 @@ Les commandes Tauri sont des adaptateurs minces. La logique réutilisable appart
 Les scénarios UI Devnet/Testnet restent dans le desktop. Des tests automatisés parallèles peuvent reproduire les mêmes parcours dans `kb-pipeline-demo-scenarios`, sans migration ou suppression des scénarios UI.
-## Statut Metaplex `0.4.7`
+## Exécution Metaplex Token Metadata
 Le panneau conserve les scénarios synthétiques et appelle directement le runner réutilisable de `kb-pipeline-demo-scenarios` pour les opérations Metaplex courantes. La simulation RPC est réelle ; la soumission exige deux autorisations distinctes dans la requête desktop.
@@ -30,5 +30,3 @@ Le panneau conserve les scénarios synthétiques et appelle directement le runne
 - [Guide d’utilisation](USAGE.md)
 - [Travaux restant à réaliser](TODO.md)
 - [Historique des changements](CHANGELOG.md)
 - Le parcours Metaplex desktop fournit un guide intégré, un journal, des résultats JSON titrés et un préparateur de fixture `Create`.
--- a/kb-app-demo-desktop/TODO.md
+++ b/kb-app-demo-desktop/TODO.md
@@ -1,22 +1,20 @@
 <!-- file: kb-app-demo-desktop/TODO.md -->
-<!-- version: 7 -->
+<!-- version: 8 -->
 # TODO — kb-app-demo-desktop
-## `0.4.7-pre.013` — démonstrations Metadata Devnet
+## Évolutions générales
- [x] Commandes Tauri - raccorder les campagnes Metaplex Devnet réutilisables sans dupliquer leur logique.
+- [ ] Documentation — maintenir un guide opérateur complet des fenêtres et effets réseau.
- [x] Interface - permettre simulation et soumission explicitement confirmée pour les opérations courantes disponibles.
+- [ ] Sécurité — réévaluer les capabilities lors de chaque nouvelle fenêtre ou commande sensible.
- [x] Contexte - afficher profil, cluster, base, wallet, mode, signature, slot et preuves de postcondition.
+- [ ] UX — empêcher les doubles déclenchements pendant une préparation, simulation ou soumission active.
- [x] Cohérence - conserver en parallèle les scénarios synthétiques et empêcher qu’ils soient présentés comme preuves réseau.
+- [ ] Observabilité — afficher explicitement les comptes relus et les projections matérialisées.
 - [ ] Validation manuelle - exécuter les parcours disponibles et confirmer la cohérence préflight, simulation, confirmation, soumission et postconditions.
-## Versions ultérieures
+## Validation Devnet complémentaire Metaplex Token Metadata
- [ ] Documentation - produire un guide opérateur complet des fenêtres et effets réseau.
+- [ ] Ajouter les parcours spécialisés Print/Burn, collection avancée et pNFT uniquement lorsque leurs fixtures réutilisables sont disponibles.
- [ ] Sécurité - réévaluer les capabilities Tauri lors de l’ajout d’une nouvelle fenêtre ou commande sensible.
+- [ ] Conserver simulation et soumission comme actions distinctes avec confirmation opérateur.
 ## Report conditionnel — registre ElGamal
- [ ] Registre ElGamal - confirmer le déploiement réseau et la disponibilité des preuves avant de rendre le panneau exécutable.
+- [ ] Confirmer le déploiement et les preuves réseau avant de rendre le panneau exécutable.
 - [ ] Registre ElGamal - raccorder un handler uniquement après validation d’un scénario réutilisable hors desktop.
--- a/kb-app-demo-desktop/USAGE.md
+++ b/kb-app-demo-desktop/USAGE.md
@@ -1,5 +1,5 @@
 <!-- file: kb-app-demo-desktop/USAGE.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 # Utilisation de kb-app-demo-desktop
@@ -267,7 +267,7 @@ Toute nouvelle fenêtre ou commande sensible doit être auditée avant ajout de
 - tests de journalisation frontend ;
 - test du verrou d’état applicatif et de la séquence splash.
-La base validée de `pre.062` contient 117 tests pour cette crate.
+Le nombre de tests évolue avec les surfaces raccordées ; la référence de validation est la dernière exécution réussie de `cargo test -p kb-app-demo-desktop`.
 ## Limites durables
@@ -287,7 +287,7 @@ Depuis la fenêtre principale, choisir **Exécution Devnet → Exécution Metada
 Un contrat marqué Devnet n’est pas, à lui seul, une exécution réseau. Les champs `networkExecutionPerformed` et `networkEvidenceCollected` doivent rester faux tant qu’aucun appel RPC réel et aucune preuve correspondante n’ont été produits.
-Les commandes de simulation et de soumission Metaplex seront documentées ici après leur raccordement effectif pendant `0.4.7-pre.013`.
+Le panneau distingue préparation de l’étape, simulation exacte et soumission explicitement confirmée. Les lectures de postcondition et la matérialisation sont dérivées du scénario préparé.
 ### Préparation de la fixture Metaplex `Create`
--- a/kb-lib/CHANGELOG.md
+++ b/kb-lib/CHANGELOG.md
@@ -1,8 +1,13 @@
 <!-- file: kb-lib/CHANGELOG.md -->
-<!-- version: 15 -->
+<!-- version: 16 -->
 # CHANGELOG — kb-lib
 ## 0.4.7-pre.016 — clôture documentaire Metaplex
 - généralise la documentation d’usage de la surface Metaplex ;
 - reporte explicitement les validations Devnet spécialisées sans dégrader le statut des builders et tests existants.
 ## 0.4.7-pre.011 — réouverture des validations réseau
 ### Documentation
--- a/kb-lib/TODO.md
+++ b/kb-lib/TODO.md
@@ -1,5 +1,5 @@
 <!-- file: kb-lib/TODO.md -->
-<!-- version: 11 -->
+<!-- version: 12 -->
 # TODO — kb-lib
@@ -22,3 +22,8 @@
 - [ ] Surfaces - remplacer les décodeurs et exécuteurs réservés selon le ROADMAP.
 - [ ] Documentation - documenter chaque nouvelle famille publique lors de son activation.
 - [ ] Anchor - implémenter l’infrastructure générique des conventions Anchor dans la série `0.6.x`.
 ## Validation réseau complémentaire Metaplex Token Metadata
 - [ ] Réauditer les opérations spécialisées après disponibilité des fixtures Devnet Print/Burn, collection et pNFT.
 - [ ] Conserver les états synthétique, simulé, soumis, non applicable et indisponible distincts dans les matrices.
--- a/kb-pipeline-demo-scenarios/CHANGELOG.md
+++ b/kb-pipeline-demo-scenarios/CHANGELOG.md
@@ -1,9 +1,15 @@
 <!-- file: kb-pipeline-demo-scenarios/CHANGELOG.md -->
-<!-- version: 26 -->
+<!-- version: 27 -->
 # CHANGELOG — kb-pipeline-demo-scenarios
-## 0.4.7-pre.15
+## 0.4.7-pre.016
 - généralise README et USAGE autour des groupes fonctionnels ;
 - nettoie le TODO et conserve les fixtures Devnet spécialisées comme dette explicite ;
 - qualifie séparément builders disponibles et preuves réseau observées.
 ## 0.4.7-pre.015
 - étend le parcours NFT Devnet à une troisième étape `UpdateAsUpdateAuthorityV2` qui rend les metadata immutables ;
 - distingue l’édition maître créée par `Create` des futures fixtures d’édition imprimée ;
 - conserve `Print` et `Burn` comme étapes ultérieures tant que leurs comptes SPL et édition ne sont pas préparés de bout en bout.
@@ -35,7 +41,7 @@
 - convertit la clé du mint en `MdPubkey` pour `getAccountInfo` ;
 - supprime l’avertissement du paramètre de rent conservé dans le contrat de politique.
-## 0.4.7-pre.13 fix-011
+## 0.4.7-pre.013-fix-011
 - remplace la préparation Metaplex fondée sur `solana-keygen`, `solana` et `spl-token` par une transaction Rust native ;
 - crée le mint par `SystemCreateAccount` puis `SPL Token InitializeMint2` dans un même message simulé, signé et confirmé ;
--- a/kb-pipeline-demo-scenarios/README.md
+++ b/kb-pipeline-demo-scenarios/README.md
@@ -1,5 +1,5 @@
 <!-- file: kb-pipeline-demo-scenarios/README.md -->
-<!-- version: 6 -->
+<!-- version: 7 -->
 # kb-pipeline-demo-scenarios
@@ -19,7 +19,7 @@ La crate contient :
 - fournir des tests automatisés parallèles aux démonstrations UI, sans déplacer les scénarios UI hors du desktop ;
 - conserver la séparation entre preuve synthétique, simulation RPC, soumission confirmée et postcondition stateful.
-La crate couvre déjà les scénarios Solana Core et SPL historiques ainsi que le corpus synthétique Metaplex pour NFT, SFT, token fongible, collection et pNFT. Un exécuteur Devnet réel et réutilisable est disponible pour les opérations Metaplex courantes pilotées par un seul wallet de profil. Il réalise le contrôle du genesis hash, les lectures stateful bornées, le préflight, la simulation RPC exacte et, après confirmation explicite, la soumission, la confirmation et les lectures avant/après. Le runner Devnet couvre désormais les 20 opérations courantes. Les fixtures concrètes, les exécutions observées et les preuves réseau restent à fournir opération par opération avant la clôture.
+La crate couvre déjà les scénarios Solana Core et SPL historiques ainsi que le corpus synthétique Metaplex pour NFT, SFT, token fongible, collection et pNFT. Un exécuteur Devnet réel et réutilisable est disponible pour les opérations Metaplex courantes pilotées par un seul wallet de profil. Il réalise le contrôle du genesis hash, les lectures stateful bornées, le préflight, la simulation RPC exacte et, après confirmation explicite, la soumission, la confirmation et les lectures avant/après. Le runner Devnet sait construire les opérations courantes, tandis que les parcours réellement préparés fournissent leurs fixtures, preuves RPC et postconditions. Les validations spécialisées restent qualifiées séparément au lieu d’être déduites de la seule présence d’un builder.
 ## Binaire CLI
--- a/kb-pipeline-demo-scenarios/TODO.md
+++ b/kb-pipeline-demo-scenarios/TODO.md
@@ -1,31 +1,21 @@
 <!-- file: kb-pipeline-demo-scenarios/TODO.md -->
-<!-- version: 8 -->
+<!-- version: 9 -->
 # TODO — kb-pipeline-demo-scenarios
-## `0.4.7-pre.011` — infrastructure et premier lot Devnet Metaplex
+## Validation Devnet complémentaire Metaplex Token Metadata
- [ ] Fixtures - préparer des fixtures Devnet réutilisables pour les familles d’actifs nécessaires.
+- [ ] Préparer les fixtures d’édition imprimée et de burn NFT.
- [x] Exécution réseau - raccorder les intents Metaplex courants au transport RPC réel et au pipeline généraliste.
+- [ ] Préparer les fixtures collection parent/membre pour verify, unverify et set-and-verify.
- [x] Contrat de preuves - exposer cluster, genesis hash, simulation exacte, signature, confirmation et états stateful avant/après dans le résultat structuré.
+- [ ] Préparer les token accounts, token records, delegates et rule sets des parcours pNFT.
- [ ] Preuves observées - exécuter les campagnes locales et reporter les valeurs RPC effectivement observées dans la matrice.
+- [ ] Qualifier chaque opération spécialisée comme simulée, soumise, non applicable ou indisponible.
 - [ ] Premier lot - préparer puis valider sur Devnet `Create`, `Update`, `Verify` et `Unverify` avec le wallet de profil et les fixtures requises.
-## `0.4.7-pre.012` — couverture Devnet restante
+## Évolutions générales
- [x] Couverture - fournir un runner réel commun et un contrat de campagne pour chacune des 20 opérations `executable_current`.
+- [ ] Ajouter au CLI uniquement les préparations de fixtures explicitement justifiées.
- [ ] Soumission - soumettre et confirmer les opérations réalisables avec les fixtures disponibles.
+- [ ] Améliorer la réutilisation, le nettoyage et la validation des fixtures publiques.
- [ ] Non-exécutabilité - documenter par opération toute impossibilité Devnet avec une cause technique et des préconditions vérifiées.
+- [ ] Maintenir un guide opérateur des campagnes et de leurs effets réseau.
 - [x] Tests - empêcher toute promotion d’un résultat synthétique en preuve réseau.
 ## Versions ultérieures
 - [ ] CLI - ajouter uniquement les commandes de préparation de fixtures explicitement justifiées.
 - [ ] Fixtures - améliorer la réutilisation, le nettoyage et la validation des fixtures publiques.
 - [ ] Documentation - maintenir un guide opérateur des campagnes et de leurs effets réseau.
 ## Report conditionnel — registre ElGamal
- [ ] Registre ElGamal - créer un scénario exécutable uniquement après confirmation du déploiement et disponibilité des preuves requises.
+- [ ] Créer un scénario exécutable uniquement après confirmation du déploiement et disponibilité des preuves requises.
 - Metaplex NFT Devnet — préparer les comptes SPL et PDA nécessaires aux étapes `Print` puis `Burn` après le parcours immuable de `pre.015`.
--- a/kb-pipeline-demo-scenarios/USAGE.md
+++ b/kb-pipeline-demo-scenarios/USAGE.md
@@ -1,5 +1,5 @@
 <!-- file: kb-pipeline-demo-scenarios/USAGE.md -->
-<!-- version: 8 -->
+<!-- version: 9 -->
 # Utilisation de kb-pipeline-demo-scenarios
@@ -268,7 +268,7 @@ where
 Pour une soumission, l’appelant doit définir `submit = true` et `operator_confirmed = true`. Les opérations dépréciées sont refusées par cette API automatique. Les lectures `preflight_reads` et `postcondition_reads` doivent décrire les comptes Metadata, Edition, Token Record ou Collection nécessaires au scénario.
-## Charger la matrice des 20 opérations courantes
+## Charger la matrice des opérations courantes
 ```rust
 fn load_metaplex_devnet_contract(
@@ -307,7 +307,7 @@ let operations =
    kb_pipeline_demo_scenarios::metaplex_token_metadata_current_operation_names();
 ```
-Les quatre premières campagnes disposent de modèles JSON structurés :
+Les opérations disposant d’un modèle générique peuvent être inspectées ainsi :
 ```rust
 fn verify_template() -> kb_core::Result<String> {
--- a/kb-pipeline/CHANGELOG.md
+++ b/kb-pipeline/CHANGELOG.md
@@ -1,8 +1,13 @@
 <!-- file: kb-pipeline/CHANGELOG.md -->
-<!-- version: 14 -->
+<!-- version: 15 -->
 # CHANGELOG — kb-pipeline
 ## 0.4.7-pre.016 — clôture documentaire Metaplex
 - aligne la documentation du pipeline sur la qualification finale des preuves réseau ;
 - reporte les futures postconditions spécialisées sans introduire de branche Metaplex dans l’orchestration généraliste.
 ## 0.4.7-pre.011 — réouverture des validations réseau
 ### Documentation
--- a/kb-pipeline/TODO.md
+++ b/kb-pipeline/TODO.md
@@ -1,5 +1,5 @@
 <!-- file: kb-pipeline/TODO.md -->
-<!-- version: 10 -->
+<!-- version: 11 -->
 # TODO — kb-pipeline
@@ -17,3 +17,7 @@
 - [ ] Réseau - confirmer l’existence et le déploiement du programme avant toute campagne réelle.
 - [ ] Intégration - compléter uniquement les couches justifiées par un scénario réellement exécutable.
 ## Validation réseau complémentaire Metaplex Token Metadata
 - [ ] Raccorder les postconditions et matérialisations des futures fixtures Print/Burn, collection et pNFT sans spécialiser le pipeline généraliste.
--- a/olddocs/archivekbot3/docs/plans/V0_4_7_METAPLEX_TOKEN_METADATA_COMPLETION_PLAN.md
+++ b/olddocs/archivekbot3/docs/plans/V0_4_7_METAPLEX_TOKEN_METADATA_COMPLETION_PLAN.md
@@ -1,5 +1,5 @@
-<!-- file: olddocs/archivekbot3/docs/plans/V0_4_7_METAPLEX_TOKEN_METADATA_COMPLETION_PLAN.md -->
+<!-- file: docs/plans/V0_4_7_METAPLEX_TOKEN_METADATA_COMPLETION_PLAN.md -->
-<!-- version: 11 -->
+<!-- version: 14 -->
 # Plan `0.4.7` — achèvement de Metaplex Token Metadata
@@ -304,7 +304,7 @@ Les scénarios UI Devnet/Testnet restent dans `kb-app-demo-desktop`. `kb-pipelin
 - envoi et postcondition uniquement avec fixture contrôlée ;
 - statut réseau exact consigné par opération.
-**Recommandation : Option B.** La version peut clôturer avec certaines opérations validées synthétiquement seulement, à condition que ce statut soit explicite et que leur exécution publique soit limitée en conséquence.
+**Décision révisée : validation Devnet obligatoire pour la surface courante.** Les niveaux de preuve restent distincts, mais `0.4.7` ne peut plus être clôturée tant que les opérations `executable_current` n'ont pas été exercées sur Devnet par des scénarios réels. Les opérations `executable_deprecated` restent hors campagne réseau obligatoire et ne sont exécutées que dans une campagne séparée, volontaire et explicitement approuvée. Une impossibilité réseau démontrée doit être documentée opération par opération et ne peut pas être remplacée par une preuve synthétique.
 ## 7. Ordonnancement proposé par prerelease
@@ -484,7 +484,65 @@ La numérotation ci-dessous est un plan fermé initial. Elle peut être regroup
 - matrice, tests, rapports et runtime alignés ;
 - écarts résiduels fermés ou reportés explicitement.
-### `0.4.7-pre.011` — clôture
+### `0.4.7-pre.011` — infrastructure et premières campagnes Devnet réelles
 **Dépendance** : exécuteur, pipeline, fixtures synthétiques et desktop stabilisés.
 **Travaux**
 - rouvrir la version après le rejet de la clôture prématurée ;
 - produire une liste machine-readable fermée des 20 opérations `executable_current` ;
 - définir pour chacune la fixture, les autorités, les fonds, les comptes préexistants, les effets attendus et la stratégie de nettoyage ;
 - ajouter les primitives réutilisables de préparation de fixtures Devnet dans `kb-pipeline-demo-scenarios` ;
 - exécuter réellement sur Devnet un premier lot cohérent couvrant au minimum création, mise à jour, vérification et révocation de vérification ;
 - enregistrer endpoint/cluster, signature, slot, logs de simulation, résultat de soumission, états avant/après et postconditions ;
 - interdire qu'un résultat synthétique puisse satisfaire un contrat de preuve réseau.
 **Acceptation**
 - le profil et la base Devnet sont chargés et vérifiés ;
 - chaque scénario du premier lot effectue au minimum une simulation RPC réelle ;
 - les scénarios mutateurs retenus effectuent une soumission réelle après garde-fou explicite ;
 - les preuves sont persistées dans des résultats structurés et réutilisables ;
 - aucune opération dépréciée n'est exécutée automatiquement.
 ### `0.4.7-pre.012` — couverture Devnet des opérations courantes restantes
 **Travaux**
 - compléter les campagnes automatisées pour toutes les opérations `executable_current` restantes ;
 - couvrir les familles metadata, collections/créateurs, délégations, programmable NFT, éditions, uses, escrow et maintenance de comptes lorsque leurs préconditions sont disponibles ;
 - créer ou réutiliser des fixtures NFT, SFT, fungible, collection et pNFT ;
 - tester les échecs attendus : mauvaise autorité, mauvais PDA, owner invalide, rule set incohérent, comptes manquants et plafond de dépense ;
 - conserver simulation-only par défaut, avec soumission activée uniquement par une option explicite de campagne ;
 - consigner toute impossibilité Devnet démontrée avec cause externe précise, tentative reproductible et preuve associée.
 **Acceptation**
 - les 20 opérations `executable_current` ont chacune un scénario Devnet réel ;
 - chaque opération possède une simulation RPC observée ou une impossibilité réseau démontrée et documentée ;
 - chaque opération mutatrice réalisable possède au moins une soumission confirmée et une postcondition stateful observée ;
 - les résultats ne dépendent pas du desktop et utilisent exclusivement les APIs généralistes de `kb-pipeline`.
 ### `0.4.7-pre.013` — démonstrations desktop Devnet et validation croisée finale
 **Travaux**
 - raccorder le panneau Metadata aux scénarios réseau réutilisables, sans déplacer leur logique métier dans Tauri ;
 - conserver les scénarios UI dans `kb-app-demo-desktop` et les tests automatisés parallèles dans `kb-pipeline-demo-scenarios` ;
 - afficher profil, cluster, base, wallet, fixture, mode simulation/soumission, signature, slot, logs et postconditions ;
 - permettre l'exécution manuelle des opérations courantes retenues depuis le desktop avec confirmation opérateur ;
 - comparer les résultats automatisés et desktop sur les mêmes contrats de preuve ;
 - exécuter les validations croisées outer/CPI, succès/échec et replay PostgreSQL idempotent.
 **Acceptation**
 - le mode Devnet déclenche réellement les appels RPC et ne se limite jamais à changer un JSON frontend ;
 - les scénarios desktop et automatisés produisent des preuves compatibles ;
 - les 20 opérations courantes ont un statut réseau final exact ;
 - les opérations dépréciées restent clairement séparées et désactivées par défaut.
 ### `0.4.7-pre.014` — clôture
 **Travaux**
@@ -493,13 +551,14 @@ La numérotation ci-dessous est un plan fermé initial. Elle peut être regroup
 - documentation générale et des crates ;
 - nettoyage des TODO, outils temporaires et références obsolètes ;
 - archivage du présent plan et des rapports devenus historiques ;
- prompt `0.4.8` avec prerelease initiale de planification et prerelease finale de clôture ;
+- préparation seulement à ce stade du prompt `0.4.8`, avec prerelease initiale de planification et prerelease finale de clôture ;
 - livraison finale.
 **Acceptation**
 - commandes de validation finales réussies ;
- code, matrices, registres, bindings et documentation alignés ;
+- preuves Devnet des opérations courantes alignées avec code, matrices, registres, bindings et documentation ;
 - aucun cas `executable_current` laissé avec un statut réseau ambigu ;
 - archive finale conforme aux règles du workspace.
 ## 8. Dépendances et ordre critique
@@ -513,8 +572,9 @@ L’ordre critique est :
 5. pipeline stateful ;
 6. fixtures et validations automatisées Devnet/Testnet ;
 7. scénarios UI desktop ;
-8. validation croisée ;
+8. campagnes Devnet réelles automatisées ;
-9. clôture.
+9. démonstrations desktop Devnet et validation croisée finale ;
 10. clôture.
 Le desktop ne doit pas précéder la stabilisation des APIs généralistes et des contrats de fixtures. `kb-pipeline-demo-scenarios` ne doit pas absorber une orchestration généraliste ni remplacer les scénarios UI du desktop. Le pipeline ne doit pas autoriser la préparation ou l’envoi d’une opération avant stabilisation de son intent et de son contrat stateful. Une instruction ne doit pas être déclarée envoyable uniquement parce qu’un builder SDK existe, mais tout builder officiellement constructible doit être implémenté dans `kb-lib` sauf statut historique, obsolète ou remplacé documenté.
@@ -573,7 +633,7 @@ Le développement fonctionnel peut commencer après acceptation des recommandati
 3. propriété des faits par domaines metadata/admin/lifecycle/risk ;
 4. rule sets programmables fail-closed ;
 5. niveaux de preuve distincts pour les validations synthétiques, simulation réseau et envoi réel ;
-6. séquence de prereleases `pre.002` à `pre.011` décrite ci-dessus.
+6. séquence de prereleases `pre.002` à `pre.014` décrite ci-dessus, la clôture étant repoussée à `pre.014`.
 ## État de `0.4.7-pre.007`
@@ -601,3 +661,20 @@ Le développement fonctionnel peut commencer après acceptation des recommandati
 - affichage des exigences de préflight, simulation-first et postconditions ;
 - scénario sélectionné restauré à la réouverture ;
 - aucune logique métier dupliquée et aucune soumission automatique.
 ## État de `0.4.7-pre.011`
 - matrice fermée des 20 opérations courantes ;
 - runner Devnet réel générique avec simulation RPC, soumission contrôlée, confirmation et lectures stateful avant/après ;
 - premier lot attribué à `Create`, `Update`, `Verify` et `Unverify` ;
 - preuves réseau encore `not_run` jusqu’aux exécutions locales et à la validation des postconditions métier ;
 - opérations dépréciées refusées dans les campagnes automatiques.
 ## État de `0.4.7-pre.012`
 - le runner RPC réutilisable accepte les 20 opérations `executable_current` ;
 - la matrice ne contient plus aucune opération au statut `planned` ;
 - un test opt-in permet de fournir l’intent typé et les lectures stateful par JSON ;
 - les statuts réseau restent `not_run` jusqu’aux campagnes locales avec fixtures ;
 - la préparation des fixtures et la collecte des preuves observées restent obligatoires avant `pre.013`.
--- a/olddocs/archivekbot3/docs/validation/PRE_062_DEVNET_VALIDATION_REPORT.md
+++ b/olddocs/archivekbot3/docs/validation/PRE_062_DEVNET_VALIDATION_REPORT.md
--- a/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_002_METAPLEX_COVERAGE_AND_FACT_OWNERSHIP.md
+++ b/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_002_METAPLEX_COVERAGE_AND_FACT_OWNERSHIP.md
--- a/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_003_METAPLEX_EXECUTOR_FOUNDATIONS.md
+++ b/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_003_METAPLEX_EXECUTOR_FOUNDATIONS.md
--- a/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_004_METAPLEX_COLLECTIONS_CREATORS_AUTHORITIES.md
+++ b/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_004_METAPLEX_COLLECTIONS_CREATORS_AUTHORITIES.md
--- a/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_006_METAPLEX_EXECUTOR_CLOSURE.md
+++ b/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_006_METAPLEX_EXECUTOR_CLOSURE.md
--- a/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_007_METAPLEX_PIPELINE_GENERALISTE.md
+++ b/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_007_METAPLEX_PIPELINE_GENERALISTE.md
--- a/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_008_METAPLEX_SYNTHETIC_AND_NETWORK_VALIDATION.md
+++ b/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_008_METAPLEX_SYNTHETIC_AND_NETWORK_VALIDATION.md
--- a/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_009_METAPLEX_DESKTOP.md
+++ b/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_009_METAPLEX_DESKTOP.md
--- a/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_010_METAPLEX_CROSS_VALIDATION.md
+++ b/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_010_METAPLEX_CROSS_VALIDATION.md
--- a/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_011_DEVNET_REOPENING.md
+++ b/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_011_DEVNET_REOPENING.md
--- a/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_011_DOCUMENTATION_REORGANIZATION.md
+++ b/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_011_DOCUMENTATION_REORGANIZATION.md
--- a/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_011_METAPLEX_DEVNET_INFRASTRUCTURE.md
+++ b/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_011_METAPLEX_DEVNET_INFRASTRUCTURE.md
--- a/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_012_METAPLEX_DEVNET_RUNNER_COVERAGE.md
+++ b/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_012_METAPLEX_DEVNET_RUNNER_COVERAGE.md
--- a/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_013_METAPLEX_DESKTOP_DEVNET_EXECUTION.md
+++ b/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_013_METAPLEX_DESKTOP_DEVNET_EXECUTION.md
--- a/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_014_METAPLEX_COHERENT_DEVNET_JOURNEYS.md
+++ b/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_014_METAPLEX_COHERENT_DEVNET_JOURNEYS.md
--- a/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_015_METAPLEX_NFT_LIFECYCLE.md
+++ b/olddocs/archivekbot3/docs/validation/V0_4_7_PRE_015_METAPLEX_NFT_LIFECYCLE.md
--- a/olddocs/archivekbot3/prompts/027_v0_4_7_metaplex_token_metadata_completion.md
+++ b/olddocs/archivekbot3/prompts/027_v0_4_7_metaplex_token_metadata_completion.md
@@ -1,4 +1,4 @@
-<!-- file: olddocs/archivekbot3/prompts/027_v0_4_7_metaplex_token_metadata_completion.md -->
+<!-- file: prompts/027_v0_4_7_metaplex_token_metadata_completion.md -->
 <!-- version: 2 -->
 # Prompt de session — `0.4.7` Achèvement de Metaplex Token Metadata
--- a/prompts/001.README.md
+++ b/prompts/001.README.md
@@ -1,8 +1,8 @@
 <!-- file: prompts/001.README.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 # Prompts actifs
-Ce répertoire contient uniquement les prompts nécessaires aux prochaines versions fonctionnelles. Les prompts utilisés pendant la migration bot3 sont archivés sous `olddocs/archivekbot3/prompts/`.
+Ce répertoire contient uniquement les prompts nécessaires aux prochaines versions fonctionnelles. Les prompts clôturés sont archivés sous `olddocs/archivekbot3/prompts/`.
- [`027_v0_4_7_metaplex_token_metadata_completion.md`](027_v0_4_7_metaplex_token_metadata_completion.md) : reprise après `0.4.6` et achèvement de Metaplex Token Metadata.
+- [`028_v0_4_8_spl_token_metadata_and_offchain_decision.md`](028_v0_4_8_spl_token_metadata_and_offchain_decision.md) : planification de SPL Token Metadata et décision sur le transport off-chain.
--- a/prompts/027_v0_4_7_metaplex_token_metadata_completion.md
+++ b/prompts/027_v0_4_7_metaplex_token_metadata_completion.md
@@ -1,193 +0,0 @@
 <!-- file: prompts/027_v0_4_7_metaplex_token_metadata_completion.md -->
 <!-- version: 2 -->
 # Prompt de session — `0.4.7` Achèvement de Metaplex Token Metadata
 ## 1. Mission
 Reprendre `khadhroony-bot3` après la clôture validée de `0.4.6` et achever la surface Metaplex Token Metadata partiellement développée dans bot2. Tout ce qui avait été réalisé dans bot2 a été migré dans bot3 ; la reprise doit donc partir de cette base migrée complète, sans présenter la migration comme partielle.
 Le travail ne consiste pas à recommencer le décodeur ni les matérialisations déjà présentes. Il doit partir de l’état réel du code, établir un plan de travail fermé, puis compléter l’exécuteur, les contrats stateful, le pipeline, les scénarios réutilisables, le CLI, le desktop et les validations finales.
 Program ID canonique :
 ```text
 metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s
 ```
 ## 2. Base validée `0.4.6`
 La base comprend :
 - architecture bot3 consolidée en onze crates ;
 - Solana Core, SPL Memo, SPL Token classique, ATA et Token-2022 ;
 - transports HTTP/WebSocket, stockage PostgreSQL, extraction Core et replay ;
 - exécution simulation-first, confirmations, signers et postvalidation ;
 - décodeur Metaplex Token Metadata d’instructions ;
 - décodeur des comptes Metaplex avec owners, PDA, seeds, bornes et variantes historiques ;
 - matrice `test-fixtures/contract-matrices/METAPLEX_TOKEN_METADATA_MATRIX.json` ;
 - matérialisation metadata déjà substantielle ;
 - coexistence explicite avec les metadata incorporées de Token-2022 ;
 - workspace, matrices, registres et bindings TS-RS validés.
 Exception conservée : le registre ElGamal n’est pas déclaré validé réellement sur réseau. Cette exception ne doit pas être mêlée au jalon Metaplex.
 ## 3. Lectures obligatoires
 1. `RULES.md`, `README.md`, `ROADMAP.md`, `CHANGELOG.md` et ce prompt ;
 2. `kb-lib/README.md`, `kb-lib/USAGE.md`, `kb-lib/TODO.md` ;
 3. `kb-pipeline/README.md`, `kb-pipeline-demo-scenarios/README.md` et `kb-app-demo-desktop/README.md` ;
 4. la matrice Metaplex active et les tests existants ;
 5. l’IDL archivée `idls/metadata.metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s.metaplex_token_metadata.V1_14_0.from_github_mpl-token-metadata.json` ;
 6. le prompt historique `olddocs/archivekbot2/prompts/026_v0_4_7_metaplex_token_metadata.md`, uniquement comme source historique à confronter au code bot3 actuel.
 ## 4. Première prerelease — plan de travail et brainstorming
 La première prerelease de `0.4.7` est consacrée exclusivement à la préparation du développement. Elle ne doit pas introduire l’exécuteur, le pipeline Metaplex ou les démonstrations finales.
 Elle doit :
 - relire le code, les matrices, les tests, les documents actifs et les sources officielles retenues ;
 - inventorier les instructions et comptes déjà décodés ;
 - inventorier les projections metadata, admin, lifecycle et risk/compliance déjà présentes ;
 - identifier les opérations actuelles, historiques decode-only et non supportées ;
 - distinguer les travaux certains, les choix d’architecture et les questions encore ouvertes ;
 - proposer plusieurs options lorsque des choix structurants existent ;
 - produire un plan de travail ordonné par prerelease, avec dépendances, critères d’acceptation et validations prévues ;
 - établir une liste fermée des manques réels ;
 - confirmer explicitement qu’aucune capacité déjà couverte ne sera réimplémentée.
 Cette première prerelease doit aboutir à un plan accepté avant le commencement du développement fonctionnel.
 ## 5. Frontière fonctionnelle
 Metaplex Token Metadata reste distinct de :
 - metadata incorporées de Token-2022 ;
 - SPL Token Metadata, prévu en `0.4.8` ;
 - Metaplex Core ;
 - JSON off-chain référencé par URI.
 Le fetch HTTP/IPFS/Arweave et la création éventuelle de `kb-offchain-transport` sont hors périmètre de `0.4.7`. Cette décision sera étudiée en `0.4.8` avec SPL Token Metadata.
 ## 6. Matérialisation
 Auditer les projections existantes et compléter uniquement les faits stables manquants :
 - metadata : nom, symbole, URI, seller fee, créateurs, collection, uses, token standard, mutabilité et programmable config ;
 - admin : update authority, collection authority, delegates et changements d’autorité ;
 - lifecycle : création, mise à jour, vérification, édition, burn, lock/unlock et transitions prouvées ;
 - risk/compliance : royalties, mutabilité, créateurs non vérifiés, rule sets et délégations sensibles.
 Chaque fait doit avoir un propriétaire unique. Ne jamais fusionner silencieusement metadata Metaplex et metadata Token-2022.
 ## 7. Exécution
 Implémenter dans `kb-lib` :
 - intents typés ;
 - builders validés contre les interfaces officielles ;
 - liste exacte des signers et comptes ;
 - coûts et plafonds de dépense ;
 - dry-run par défaut et simulation obligatoire ;
 - confirmation opérateur dédiée pour burn, changement d’autorité, verify/unverify, delegate/revoke, lock/unlock ;
 - classification explicite des opérations historiques decode-only.
 ## 8. Préflight et postconditions
 Vérifier selon l’opération :
 - owner et Program ID ;
 - PDA et seeds ;
 - mint, metadata, edition, token account, collection et authority ;
 - état de mutabilité, vérification, délégation, token standard et programmable config ;
 - cohérence des rule sets et comptes d’autorisation ;
 - postconditions stateful après soumission.
 Tout écart doit échouer avant signature ou être classé explicitement non applicable.
 ## 9. Pipeline
 Intégrer dans `kb-pipeline` :
 - lectures stateful bornées ;
 - préparation et orchestration d’exécution ;
 - corrélation des comptes Metaplex ;
 - postvalidation ;
 - insertion canonique, extraction Core, replay et matérialisation idempotente ;
 - diagnostics stables et résultats exploitables par les scénarios.
 ## 10. Scénarios et démonstrations
 Ajouter dans `kb-pipeline-demo-scenarios` :
 - scénarios simulation-only par défaut ;
 - CLI pour les opérations retenues ;
 - fixtures synthétiques et, si possible, réseau ;
 - résultats structurés et preuves de postcondition.
 Ajouter dans `kb-app-demo-desktop` uniquement les adaptateurs Tauri et panneaux nécessaires. La logique fonctionnelle doit rester dans les crates réutilisables.
 ## 11. Corpus et validations
 Couvrir au minimum :
 - NFT, SFT, token fongible, collection et programmable NFT ;
 - outer et CPI ;
 - transactions réussies et échouées ;
 - mauvais Program ID, owner, PDA, comptes, payload tronqué, suffixe et discriminant inconnu ;
 - conflits entre metadata Metaplex et metadata Token-2022 ;
 - replay PostgreSQL idempotent ;
 - simulation, confirmation, envoi et postconditions pour les opérations exécutables.
 Ne pas déclarer une validation réseau si les fixtures ou préconditions ne sont pas disponibles.
 ## 12. Documentation pendant le développement
 Mettre à jour au fil des prereleases uniquement les documents nécessaires pour refléter les décisions et contrats réellement introduits :
 - les quatre documents des crates modifiées ;
 - la matrice Metaplex active ;
 - la documentation des opérations supportées, decode-only et non supportées ;
 - les rapports de validation propres aux capacités effectivement testées.
 La mise à jour générale de clôture appartient à la dernière prerelease.
 ## 13. Dernière prerelease — clôture de `0.4.7`
 La dernière prerelease doit être réservée à la clôture de la version. Elle ne doit pas introduire une nouvelle surface fonctionnelle majeure.
 Elle doit obligatoirement :
 - exécuter les tests finaux, les audits de conformité et les validations applicatives nécessaires ;
 - vérifier l’alignement entre code, matrices, registres, bindings TS-RS et documentation ;
 - mettre à jour définitivement `README.md`, `ROADMAP.md` et `CHANGELOG.md` ;
 - mettre à jour les `README.md`, `TODO.md`, `USAGE.md` et `CHANGELOG.md` des crates concernées ;
 - retirer des TODO les tâches terminées et transférer les travaux reportés vers la version correcte ;
 - archiver les prompts, plans, rapports ou documents de travail devenus historiques ;
 - supprimer les outils temporaires, fichiers de validation et références obsolètes qui ne doivent pas rester dans la version publiée ;
 - préparer le prompt complet de la session `0.4.8 — SPL Token Metadata et décision off-chain metadata` ;
 - vérifier que ce prompt commence lui aussi par une prerelease de planification et se termine par une prerelease de clôture ;
 - préparer la livraison finale de `0.4.7` selon les règles du workspace.
 ## 14. Validation finale
 Exécuter :
 ```bash
 cargo fmt --all
 cargo check --workspace
 cargo clippy --all-targets
 python3 scripts/audit_rust_workspace_rules.py
 cargo test --workspace
 ```
 Si le desktop est modifié, valider avec :
 ```bash
 cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
 ```
 ## 15. Livraisons
 Après l’archive complète de départ, livrer uniquement des ZIP delta contenant `delta.md`, sans SHA-256. Les correctifs d’une même prerelease utilisent `-delta-fix-XXX.zip`, avec une numérotation recommençant à `fix-001` pour chaque nouvelle prerelease.
--- a/prompts/028_v0_4_8_spl_token_metadata_and_offchain_decision.md
+++ b/prompts/028_v0_4_8_spl_token_metadata_and_offchain_decision.md
@@ -0,0 +1,156 @@
 <!-- file: prompts/028_v0_4_8_spl_token_metadata_and_offchain_decision.md -->
 <!-- version: 2 -->
 # Prompt de session — 0.4.8 SPL Token Metadata et décision off-chain
 ## Mission
 Reprendre `khadhroony-bot3` après la clôture de `0.4.7` et étudier SPL Token Metadata comme surface distincte de Metaplex Token Metadata et des metadata incorporées Token-2022.
 La session doit commencer par une planification complète et structurée, puis conserver une planification vivante pendant tout le développement. Le plan initial doit couvrir l’ensemble de la version, mais il peut être corrigé, enrichi, réordonné ou regrouper des phases lorsque l’état réel du code le justifie.
 ## Exigences de départ obligatoires
 Avant toute proposition d’architecture, modification de code ou création de delta :
 1. lire les documents racine actifs, notamment `README.md`, `ROADMAP.md`, `RULES.md` et les documents auxquels ils renvoient ;
 2. lire intégralement les règles et normes actives du projet :
   - `docs/rules/RULES_GENERAL.md` ;
   - `docs/rules/RULES_RUST.md` ;
   - `docs/rules/RULES_SPECIFIC_KHADHROONY.md` ;
   - `docs/rules/CRATE_DOCUMENTATION_RULES.md` ;
   - `docs/rules/VERSION_DEVELOPMENT_LIFECYCLE.md` ;
 3. relever et appliquer les conventions portant notamment sur :
   - Rust 2024 et les restrictions du workspace ;
   - visibilité, exports publics, imports et documentation Rust ;
   - interdictions `unsafe`, `unwrap`, `expect`, `panic` et règles Tauri spécifiques ;
   - entêtes `file:` et `version:` ;
   - incrémentation des versions locales des fichiers modifiés ;
   - lignes vides, fins de fichier et organisation des modules ;
   - emplacement attendu de chaque type de code, test, fixture, IDL et document ;
   - format, contenu et rôle de `README.md`, `USAGE.md`, `TODO.md`, `CHANGELOG.md`, rapports, guides, prompts et archives ;
   - documents à mettre à jour selon la nature de chaque modification ;
   - ordre antéchronologique des changelogs et limitation de chaque changelog à son propre périmètre ;
   - politique des prereleases, deltas, correctifs et archivages ;
 4. inspecter les `README.md`, `USAGE.md`, `TODO.md` et `CHANGELOG.md` des crates directement concernées avant de les modifier ;
 5. inspecter les audits, matrices, IDL, rapports de validation et archives pertinentes sans modifier les archives historiques ;
 6. vérifier l’état réel du workspace avant d’utiliser une hypothèse issue d’une ancienne session ou d’un ancien document.
 Une règle découverte en cours de session doit être intégrée immédiatement au travail courant ; elle ne doit pas être reportée à la clôture.
 ## Première prerelease obligatoire
 La première prerelease est consacrée au plan et au brainstorming. Avant le code, elle doit :
 - inventorier les programmes, Program ID, interfaces, comptes, instructions, builders et sources officielles ;
 - distinguer précisément SPL Token Metadata, Solana Program Metadata, Metaplex Token Metadata et les metadata incorporées Token-2022 ;
 - identifier ce qui existe déjà dans `kb-program-ids`, `kb-lib`, `kb-pipeline`, `kb-pipeline-demo-scenarios`, `kb-app-demo-desktop`, `kb-store`, les matrices et les documents ;
 - fixer le périmètre decoder/materializer/executor/pipeline/desktop ;
 - décider les fixtures et scénarios réseau nécessaires ;
 - découper les prereleases et définir leurs critères d’acceptation ;
 - décider séparément le périmètre éventuel de `kb-offchain-transport` ;
 - préciser les documents, changelogs, TODO, matrices et rapports à maintenir pendant chaque phase.
 Le plan doit couvrir la version complète dès le départ, y compris les scénarios Devnet réels. Il reste toutefois souple : des étapes peuvent être ajoutées, déplacées, fusionnées ou séparées si les découvertes techniques l’exigent.
 L’objectif opérationnel est de conserver des deltas petits et testables, dont la préparation reste généralement compatible avec une livraison toutes les 10 à 15 minutes de travail effectif. Une phase trop large doit être divisée ; des phases devenues artificiellement petites peuvent être regroupées.
 ## Scénarios Devnet réels obligatoirement prévus
 L’erreur à ne pas reproduire depuis `0.4.7` est de ne pas avoir prévu les scénarios réels dans la planification initiale.
 Pour chaque capacité exécutable retenue, le plan doit prévoir dès le départ, puis maintenir pendant le développement :
 1. tests contractuels et synthétiques ;
 2. campagne réutilisable dans `kb-pipeline-demo-scenarios` lorsque cela apporte une validation automatisable ;
 3. panneau ou parcours réel dans `kb-app-demo-desktop` ;
 4. fixture Devnet reproductible et préparée par les APIs Rust du workspace lorsque cela est approprié ;
 5. simulation RPC du message exact ;
 6. soumission confirmée lorsque l’opération est sûre et réalisable ;
 7. lectures stateful, postconditions et matérialisation observables ;
 8. état de validation explicite : synthétique, simulé Devnet, soumis Devnet, non applicable, indisponible ou reporté avec justification.
 La mise en œuvre peut évoluer pendant la version, mais les scénarios réels ne doivent jamais disparaître du plan. Une surface ne doit pas être annoncée comme validée réseau sans preuve d’exécution réelle observée.
 ## Audit et gestion des IDL
 Avant le code :
 1. vérifier si une IDL officielle existe pour la surface SPL Metadata visée ;
 2. examiner l’IDL déjà présente :
   `idls/metadata.ProgM6JCCvbYkfKqJYHePx4xxSUSqJp7rh8Lyv7nk7S.solana_program_metadata.V0_0_0.from_github_solana_program.json` ;
 3. déterminer, depuis les sources officielles, si cette IDL correspond exactement au programme et au contrat étudiés ;
 4. ne pas assimiler deux surfaces seulement parce que leurs noms contiennent « metadata ».
 Lorsqu’une IDL officielle pertinente est trouvée :
 - conserver une copie brute et non réécrite sous `idls/` ;
 - appliquer la convention de nommage documentée dans `idls/001.README.md` ;
 - encoder la provenance et la version dans le nom ;
 - vérifier le Program ID déclaré, la validité JSON et l’empreinte ;
 - mettre à jour au minimum :
  - `idls/001.README.md` ;
  - `docs/IDL_AUDIT.md` ;
  - `docs/IDL_TO_KB_LIB_NOMENCLATURE.md` ;
  - `docs/MISSING_PROGRAM_IDLS.md` si le statut « manquante » change ;
  - les documents de classification ou de surface IDL concernés ;
 - mettre à jour les compteurs, inventaires, provenance, nomenclature cible et décisions architecturales associées ;
 - ne jamais inventer une version ou une provenance absente de la source.
 Si aucune IDL officielle exploitable n’existe, documenter cette absence et utiliser les crates/interfaces officielles comme source de vérité sans fabriquer d’IDL.
 ## Frontières
 - SPL Token Metadata reste distinct de Metaplex Token Metadata ;
 - Solana Program Metadata doit être identifié exactement avant d’être assimilé ou non à SPL Token Metadata ;
 - les metadata incorporées Token-2022 gardent leur propre contrat ;
 - le fetch off-chain n’est pas incorporé au décodeur canonique ;
 - les IDL et interfaces archivées restent des références statiques ;
 - les archives sous `olddocs/` ne doivent pas être modifiées hors opération d’archivage explicitement prévue.
 ## Décision `kb-offchain-transport`
 Étudier une crate dédiée pour HTTP(S), IPFS et Arweave avec : timeout, taille, type MIME, redirections, cache, hash, provenance, protection SSRF et interdiction des réseaux locaux. Le contenu distant ne modifie jamais le statut canonique du replay on-chain.
 Cette décision doit rester séparée de l’implémentation canonique on-chain. Elle peut être reportée à une version suivante si son périmètre rend `0.4.8` trop large.
 ## Discipline documentaire pendant la version
 À chaque delta :
 - mettre à jour uniquement les documents rendus faux ou incomplets par les modifications du delta ;
 - conserver les `README.md` et `USAGE.md` généralistes, structurés par fonction ou groupe, jamais comme journaux de prerelease ;
 - réserver les détails chronologiques aux changelogs et rapports de validation ;
 - supprimer des TODO les tâches réellement terminées ;
 - ajouter seulement des TODO explicites, encore actionnables et placés dans le bon périmètre ;
 - maintenir les changelogs du plus récent au plus ancien et limiter chaque entrée aux changements de son emplacement ;
 - réconcilier les matrices, guides, rapports, nomenclatures et documents IDL avec le code livré ;
 - archiver les documents de travail devenus historiques plutôt que de les laisser parmi les documents actifs.
 ## Dernière prerelease obligatoire
 La dernière prerelease doit être réservée à :
 - validations finales et conformité ;
 - documentation générale et par crate ;
 - nettoyage des TODO ;
 - mise à jour du ROADMAP et des changelogs ;
 - réconciliation des documents IDL ;
 - archivage du plan, des rapports intermédiaires et du prompt de session ;
 - préparation du prompt suivant ;
 - préparation de la release finale.
 La dernière prerelease ne doit pas servir à découvrir tardivement des scénarios Devnet qui n’auraient jamais été planifiés.
 ## Contrôles finaux
 ```bash
 cargo fmt --all
 cargo check --workspace
 cargo clippy --all-targets
 python3 scripts/audit_rust_workspace_rules.py
 cargo test --workspace
 cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
 ```
 Les validations Devnet doivent être exécutées selon les parcours documentés dans `kb-app-demo-desktop`, avec conservation des signatures, résultats de simulation, confirmations, postconditions et preuves de matérialisation pertinentes.