v0.4.8

CHANGELOG.md

@@ -1,10 +1,61 @@
 <!-- file: CHANGELOG.md -->
-<!-- version: 11 -->
+<!-- version: 12 -->
 
 # CHANGELOG — khadhroony-bot3
 
 Ce changelog décrit les évolutions fonctionnelles globales du projet. Il ne recense pas les prereleases, les correctifs `fix` ni le détail de chaque delta. Ces informations appartiennent aux changelogs des crates concernées.
 
+## 0.4.8 — Solana Program Metadata et complétude Metadata on-chain
+
+### Solana Program Metadata
+
+- implémentation complète de la surface indépendante `ProgM6JCCvbYkfKqJYHePx4xxSUSqJp7rh8Lyv7nk7S` : IDL, modèles, comptes, neuf instructions stables, PDA, décodeur, matérialiseur, exécuteur et pipeline ;
+- replay mainnet de recherche et campagne Devnet réutilisable couvrant les neuf opérations ;
+- intégration desktop dédiée avec préflight, simulation, confirmation, postconditions et preuves structurées.
+
+### Token-2022 Token Metadata
+
+- fermeture des cinq opérations de `spl-token-metadata-interface` dans la surface Token-2022 existante : `Initialize`, `UpdateField`, `Emit`, `RemoveKey` et `UpdateAuthority` ;
+- campagne Devnet complète avec fixture fraîche, return data `Emit`, lectures stateful, replay et matérialisation ;
+- conservation de la frontière stricte entre Token-2022 Token Metadata, Solana Program Metadata et Metaplex Token Metadata.
+
+### Metaplex Token Metadata
+
+- réaudit de la surface courante et qualification des campagnes Create/Mint, collection, Print/Burn, lifecycle pNFT, escrow, maintenance et Use ;
+- fermeture de la matrice Devnet courante à 15 opérations `confirmed`, 5 `unavailable` et 0 `not_run` ;
+- maintien des opérations indisponibles comme probes bornées sans fausse promotion réseau.
+
+### Desktop et cohérence transversale
+
+- finalisation de `demo_execution_metadata` avec trois domaines séparés, campagnes réutilisables, JsonViewer, accordéons de preuves et journal pleine largeur ;
+- centralisation des scénarios réseau réutilisables dans `kb-pipeline-demo-scenarios` plutôt que dans l’adaptateur Tauri ;
+- réconciliation des matrices, registres runtime, exports publics, IDL, TODO et stockage ;
+- confirmation qu’aucune migration PostgreSQL spécialisée Metadata n’est nécessaire.
+
+### Validation et release
+
+- `cargo fmt --all`, `cargo check --workspace`, `cargo clippy --all-targets`, audit Rust du workspace et `cargo test --workspace` validés ;
+- build desktop de release validé par `cargo tauri build`, qui pilote lui-même TypeScript/Vite ;
+- génération validée des bundles `.deb`, `.rpm` et `.AppImage` en version desktop `0.4.8` ;
+- `kb-offchain-transport` et les traitements metadata off-chain restent hors de la chaîne canonique et sont reportés à `0.16.x+`.
+
+## 0.4.7 — Metaplex Token Metadata
+
+### Capacités
+
+- achèvement de la surface Metaplex Token Metadata migrée depuis bot2 ;
+- décodeurs d’instructions et de comptes, PDA, owners, modèles et variantes historiques ;
+- matérialisation metadata, administration, lifecycle et risques applicables ;
+- intents typés, builders, exécuteur, préflight stateful, simulation-first et postconditions ;
+- intégration dans `kb-pipeline`, scénarios synthétiques et runner Devnet réutilisable ;
+- intégration desktop sans fetch HTTP/IPFS/Arweave.
+
+### Validation
+
+- parcours réseau représentatifs Create/Update exécutés sur Devnet ;
+- matrices et tests de couverture fermés pour le milestone `0.4.7` ;
+- campagnes spécialisées complémentaires explicitement reportées puis fermées pendant `0.4.8`.
+
 ## 0.4.6 — alignement fonctionnel de khadhroony-bot3
 
 ### Architecture
@@ -80,7 +131,7 @@ Les sections dont le numéro porte le suffixe `-kbot2` décrivent exclusivement
 
 `khadhroony-bot3` résulte de la migration et de la consolidation de cette base historique dans une nouvelle architecture. Son alignement fonctionnel est clôturé par la version bot3 `0.4.6`.
 
-La version `0.4.7` de `khadhroony-bot3` achèvera Metaplex Token Metadata à partir des décodeurs et matérialisations déjà migrés, en ajoutant notamment l’exécuteur, l’intégration pipeline, les démonstrations et les validations finales.
+Les versions `0.4.7` et `0.4.8` de `khadhroony-bot3` ont ensuite achevé respectivement Metaplex Token Metadata puis les surfaces Metadata on-chain complémentaires, avec exécution, pipeline, scénarios et validations réseau.
 
 Les entrées `0.0.1-kbot2` à `0.4.6-kbot2` décrivent des versions fonctionnelles clôturées de bot2. L’entrée `0.4.7-kbot2` décrit une version interrompue en cours de développement par la migration vers bot3.
 

Cargo.toml

@@ -1,5 +1,5 @@
 # file: Cargo.toml
-# version: 38
+# version: 40
 
 [workspace]
 resolver = "3"
@@ -18,7 +18,7 @@ members = [
 ]
 
 [workspace.package]
-version = "0.4.8-pre.15"
+version = "0.4.8"
 edition = "2024"
 license = "MIT"
 repository = "https://git.sasedev.com/Sasedev/khadhroony-bot3"

README.md

@@ -1,5 +1,5 @@
 <!-- file: README.md -->
-<!-- version: 17 -->
+<!-- version: 18 -->
 
 # Khadhroony Bot3
 
@@ -59,8 +59,16 @@ python3 scripts/audit_rust_workspace_rules.py
 cargo test --workspace
 ```
 
-Lorsque le desktop est concerné :
+Lorsque le desktop est concerné en développement :
 
 ```bash
 cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
 ```
+
+Pour un build desktop de release :
+
+```bash
+cargo tauri build -c kb-app-demo-desktop/tauri.conf.json
+```
+
+Les scripts `npm run dev` et `npm run build` ne sont pas lancés directement : Tauri les pilote via sa configuration.

ROADMAP.md

@@ -1,5 +1,5 @@
 <!-- file: ROADMAP.md -->
-<!-- version: 30 -->
+<!-- version: 33 -->
 
 # ROADMAP — khadhroony-bot3
 
@@ -11,7 +11,7 @@ Version clôturée : architecture en onze crates, alignement bot2 `0.4.6`, valid
 
 ## 0.4.7 — Metaplex Token Metadata
 
-Version en clôture documentaire.
+Version clôturée : surface Metaplex Token Metadata indépendante, bornée et intégrée aux couches de décodage, matérialisation, exécution, pipeline et démonstration.
 
 ### Périmètre réalisé
 
@@ -22,14 +22,9 @@ Version en clôture documentaire.
 - 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.
+- validation réelle de parcours représentatifs sur Devnet.
 
-### Qualification de validation
+Les validations complémentaires de la surface courante ont ensuite été fermées pendant `0.4.8` : la matrice Devnet des 20 opérations courantes contient 15 opérations `confirmed`, 5 `unavailable` et 0 `not_run`. Les matrices historiques de `0.4.7` restent figées à leur milestone.
-
-- les opérations structurantes et les parcours représentatifs sont validés réellement sur Devnet ;
-- les autres opérations exposées restent couvertes par leurs builders, matrices et tests synthétiques ;
-- 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 bloquant de clôture ;
-- aucune preuve synthétique ne doit être présentée comme preuve RPC.
 
 ### Hors périmètre
 
@@ -39,73 +34,204 @@ Version en clôture documentaire.
 
 ## 0.4.8 — Solana Program Metadata et complétude Token-2022
 
-### Première prerelease
+Version clôturée et validée.
 
-La première prerelease produit le plan vivant et l’inventaire fermé avant tout développement fonctionnel. Elle prévoit dès le départ les tests synthétiques, les campagnes réutilisables, les fixtures Rust natives, les panneaux desktop et les preuves Devnet réelles.
+### Périmètre réalisé
 
-### Solana Program Metadata
+- implémentation de la surface indépendante Solana Program Metadata `ProgM6JCCvbYkfKqJYHePx4xxSUSqJp7rh8Lyv7nk7S` : IDL, comptes, neuf instructions stables, PDA, modèles, décodeur, matérialiseur, exécuteur, pipeline, scénarios et desktop ;
+- complétude des cinq opérations Token-2022 Token Metadata de `spl-token-metadata-interface` — `Initialize`, `UpdateField`, `Emit`, `RemoveKey`, `UpdateAuthority` — dans les modules Token-2022 existants, sans créer de Program ID autonome artificiel ;
+- réaudit fonctionnel Metaplex Token Metadata des 20 opérations courantes et fermeture des campagnes spécialisées ;
+- panneau desktop Metadata séparant explicitement Metaplex Token Metadata, Token-2022 Token Metadata et Solana Program Metadata ;
+- réconciliation transversale du stockage, des matrices, registres runtime, exports publics, IDL, TODO et guides ;
+- conservation du store générique de décodage/matérialisation : aucune migration PostgreSQL spécialisée Metadata n’est nécessaire.
 
-- implémenter la surface indépendante `metadata/solana_program_metadata` pour `ProgM6JCCvbYkfKqJYHePx4xxSUSqJp7rh8Lyv7nk7S` ;
+### Qualification réseau
-- auditer l’IDL officielle locale et les sources officielles avant de coder ;
-- couvrir les comptes, instructions, PDA, erreurs, modèles, décodeur, matérialiseur, exécuteur et pipeline justifiés ;
-- préparer une fixture contrôlée, des simulations RPC, des soumissions Devnet sûres, des lectures stateful et des postconditions ;
-- exposer un parcours desktop distinct de Metaplex Token Metadata et de Token-2022.
 
-### Complétude Token-2022 Token Metadata
+- Solana Program Metadata : 9 opérations `confirmed` sur Devnet ;
-
+- Token-2022 Token Metadata : 5 opérations `confirmed` sur Devnet ;
-- traiter `spl-token-metadata-interface` comme une interface sans Program ID autonome imposé ;
+- Metaplex Token Metadata : 15 opérations `confirmed`, 5 `unavailable`, 0 `not_run` sur les 20 opérations courantes ;
-- auditer puis compléter les cinq opérations `Initialize`, `UpdateField`, `RemoveKey`, `UpdateAuthority` et `Emit` dans les modules Token-2022 existants ;
+- desktop Metadata : campagnes des trois domaines validées, avec résultats structurés et journal pleine largeur.
-- ne pas créer de second décodeur de programme pour cette interface ;
-- maintenir une campagne Devnet et un parcours desktop distincts de `ProgM6…`.
 
 ### Décision off-chain
 
 - aucun fetch HTTP, IPFS ou Arweave n’est intégré aux décodeurs canoniques ;
 - les URI restent des données on-chain observées ;
-- `kb-offchain-transport` est reportée à l’horizon `0.15+`, avec les futurs workers et consommateurs qui justifieront ses contraintes de cache, provenance, hash, redirections, MIME, taille, timeout et protection SSRF.
+- `kb-offchain-transport` est reportée à `0.16.x+`, lorsque les workers et consommateurs réels permettront de définir précisément cache, provenance, hash, redirections, MIME, taille, timeout et protection SSRF.
 
-## 0.5.x — configuration, wallet, stockage et démonstrations
+## 0.5.x — consolidation des fondations avant l’extension fonctionnelle
 
-- restructurer `kb-config` et séparer le logging si retenu ;
+La série `0.5.x` existe pour corriger et stabiliser les fondations transversales avant d’empiler les futurs Program IDs et matérialisations métier. L’objectif est d’éviter de devoir modifier tardivement les contrats de configuration, de wallet ou de stockage lorsque Meteora, Raydium, Pump, Orca, Jupiter et les autres protocoles commenceront à dépendre massivement de ces couches.
-- compléter multi-wallets, import/export, chiffrement, verrouillage, sauvegarde et restauration dans `kb-wallet` ;
-- 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 ;
-- exécuter l’audit transversal de complétude des décodeurs, matérialisateurs et exécuteurs déjà livrés : couverture officielle, propriété unique des faits, opérations dangereuses gouvernées par `ExSafetyChecker`, opérations obsolètes constructibles marquées `#[deprecated]` et versions remplacées maintenues en decode-only.
 
-## 0.6.x — Anchor générique, programmes SPL et Metaplex complémentaires
+### 0.5.0 — cadrage et plan de restructuration
 
-- infrastructure générique Anchor : discriminants, comptes, événements et erreurs ;
+- auditer l’état réel de `kb-config`, `kb-logging`, `kb-wallet`, `kb-store`, `kb-pipeline-demo-scenarios` et `kb-app-demo-desktop` ;
-- classification et conservation des IDL comme références statiques ;
+- inventorier les contrats publics, schémas, migrations, dépendances et couplages avant refactor ;
-- autres programmes SPL et Metaplex, chacun avec matrices et scénarios Devnet réels représentatifs.
+- produire le plan détaillé de la série `0.5.x` et borner les migrations nécessaires ;
+- ne pas introduire de nouvelle surface protocolaire importante pendant ce cadrage.
+
+### 0.5.1 — `kb-config` et configuration sûre
+
+- restructurer `kb-config` par responsabilités cohérentes ;
+- créer au minimum des schémas de validation distincts pour la configuration générale et la configuration logging lorsque l’audit confirme cette frontière ;
+- ajouter d’autres schémas spécialisés seulement lorsqu’ils réduisent réellement le couplage ;
+- revoir les profils, valeurs par défaut, validations croisées, erreurs et résolutions de variables d’environnement ;
+- traiter explicitement les secrets issus de `.env` et des variables d’environnement ;
+- camoufler/redacter les secrets dans logs, diagnostics, UI, erreurs et payloads sérialisés ;
+- empêcher qu’une configuration résolue expose involontairement un secret en clair ;
+- garder exemples, schémas JSON, bindings et documentation synchronisés.
+
+### 0.5.2 — `kb-wallet`
+
+- auditer et normaliser les frontières identité, secret, déverrouillage et signature ;
+- consolider les besoins multi-wallets et multi-profils ;
+- revoir import/export, chiffrement, verrouillage, sauvegarde et restauration lorsque ces capacités sont retenues ;
+- empêcher toute fuite de secret vers la configuration, les logs, Tauri ou les DTO publics ;
+- conserver une API de signature réutilisable par les futurs exécuteurs sans couplage à un protocole particulier.
+
+### 0.5.3 — audit et normalisation de `kb-store`
+
+- auditer DTO, entités, repositories, migrations, index, requêtes, idempotence et provenance ;
+- vérifier les champs temporels et séparer explicitement le temps blockchain du temps de persistance ;
+- distinguer notamment slot, block time ou timestamp de transaction des timestamps d’insertion et de mise à jour en base ;
+- normaliser la structure de `kb-store` avant l’arrivée des matérialisations trading ;
+- préparer les index et contrats nécessaires aux faits de création de pools, liquidité, réserves, swaps, évolution de prix et séries temporelles ;
+- préparer le terrain pour routing, multi-pools et analyse croisée sans introduire prématurément des tables spécifiques à un DEX ;
+- permettre des extractions et analyses efficaces pour les futurs consommateurs de trading et de recherche historique.
+
+### 0.5.4 — scénarios, exécuteurs et validations
+
+- auditer les scénarios encore déclarés ou assemblés directement dans `kb-app-demo-desktop` ;
+- déplacer toute logique de scénario réutilisable vers `kb-pipeline-demo-scenarios` et laisser le desktop comme adaptateur UI/Tauri ;
+- comparer les décodeurs existants aux exécuteurs disponibles et identifier les exécuteurs réellement manquants ;
+- comparer les exécuteurs aux scénarios synthétiques, campagnes Devnet/Testnet et validations existantes ;
+- identifier les capacités présentes dans le desktop sans scénario réutilisable ;
+- classer chaque absence comme à implémenter, decode-only, deprecated, unavailable, non applicable ou explicitement reportée.
+
+## 0.6.x — infrastructure Anchor générique et prérequis prioritaires
+
+La série `0.6.x` prépare directement l’accélération sur les protocoles suivants. Elle ne cherche pas à terminer immédiatement toute la couverture Solana.
+
+- implémenter un décodeur Anchor générique réutilisable : discriminants d’instructions et de comptes, événements, erreurs, conventions IDL, bornes et diagnostics ;
+- définir la stratégie générique de matérialisation des informations Anchor communes lorsque cela apporte une valeur stable ;
+- conserver et classifier les IDL comme références statiques sans transformer automatiquement une IDL en vérité runtime ;
+- implémenter uniquement les programmes/interfaces SPL ou autres prérequis dont Meteora, Raydium, Pump, Orca, Jupiter ou les couches de trading suivantes ont réellement besoin ;
+- reporter à `0.15.x` les programmes SPL non prioritaires, les compléments Metaplex non nécessaires à court terme et, plus généralement, les autres Program IDs déjà recensés ou découverts ultérieurement qui ne bloquent pas la séquence trading prioritaire.
+
+Le report vers `0.15.x` est un choix d’ordre de développement, pas une réduction du périmètre de `kb-lib`. L’objectif à long terme reste de décoder et matérialiser le maximum de Program IDs Solana utiles, qu’ils soient liés ou non au trading.
 
 ## 0.7.x — Meteora
 
-DLMM, DAMM v1/v2, DBC, vaults et autres programmes vérifiés.
+### 0.7.0 — cadrage Meteora
 
-## 0.8.x — Pump
+- inventorier les Program IDs, IDL, comptes, instructions, événements et dépendances communes ;
+- vérifier les primitives Anchor/SPL nécessaires avant code ;
+- fixer les matrices de couverture et les scénarios réseau possibles.
 
-Pump AMM, Pump.fun, Pump Fees et autres surfaces vérifiées. Auditer `MAyhSmzXzV1pTf7LsNkrNwkWKTo4ougAJ1PPg47MD4e` et l’appartenance de `pumpup_ai`.
+### 0.7.1 — DLMM decode + materialize
 
-## 0.9.x — Raydium
+Décoder la surface DLMM prioritaire et produire les matérialisations stables nécessaires au suivi des pools, positions, liquidité, swaps et évolutions de prix observables.
 
-AMM v4/v3/v2, CPMM, CLMM, stable swap, LaunchLab, Lock et autres surfaces vérifiées.
+### 0.7.2 — DLMM executor + scénarios
+
+Ajouter les exécuteurs justifiés et les scénarios Devnet/Testnet lorsque le programme et les fixtures le permettent, sans inventer de validation réseau impossible.
+
+### 0.7.3 — DAMM v1 decode + materialize
+
+Décoder DAMM v1 et matérialiser les faits de pool/trading utiles selon les mêmes frontières que DLMM.
+
+### 0.7.4 — DAMM v1 executor + scénarios
+
+Ajouter les exécuteurs et campagnes réseau sûres et représentatives lorsque disponibles.
+
+### 0.7.5 — DAMM v2 decode + materialize
+
+Décoder DAMM v2 et matérialiser ses faits stables sans réutiliser artificiellement les contrats DAMM v1 lorsqu’ils diffèrent.
+
+### 0.7.6 — DAMM v2 executor + scénarios
+
+Ajouter les exécuteurs et scénarios Devnet/Testnet réellement justifiés.
+
+### 0.7.7 — DBC decode + materialize
+
+Décoder Dynamic Bonding Curve et matérialiser création, progression, liquidité, migrations et faits de prix réellement observables.
+
+### 0.7.8 — DBC executor + scénarios
+
+Ajouter les exécuteurs et scénarios réseau possibles avec les mêmes règles simulation-first et postconditions.
+
+### 0.7.9 — Vault et audit des autres programmes Meteora
+
+- couvrir Meteora Vault selon la valeur des comptes/instructions réellement utilisés ;
+- auditer les autres Program IDs Meteora découverts pendant les versions précédentes ;
+- classer chaque surface restante comme prioritaire, reportée, decode-only ou non applicable avant de clôturer `0.7.x`.
+
+## 0.8.x — Raydium
+
+Appliquer la même discipline que pour Meteora : cadrage, puis pour chaque surface prioritaire une version decode + materialize suivie d’une version executor + scénarios lorsque l’exécution réseau est possible.
+
+### 0.8.0 — cadrage Raydium
+
+- inventorier Program IDs, IDL, générations actives/historiques, comptes, instructions et dépendances ;
+- confirmer l’ordre des surfaces à partir de leur valeur trading réelle et de leur disponibilité réseau ;
+- définir les matrices et fixtures réutilisables avant implémentation.
+
+### 0.8.1 — AMM v4 decode + materialize
+
+Décoder AMM v4 et matérialiser les faits stables de pools, réserves, swaps, liquidité et prix observables.
+
+### 0.8.2 — AMM v4 executor + scénarios
+
+Ajouter les exécuteurs justifiés et les scénarios Devnet/Testnet lorsque les opérations peuvent être exécutées de manière sûre et reproductible.
+
+### 0.8.3 — CPMM decode + materialize
+
+Décoder CPMM et matérialiser ses faits de pool et de trading sans le confondre avec les générations AMM historiques.
+
+### 0.8.4 — CPMM executor + scénarios
+
+Ajouter les exécuteurs et campagnes réseau représentatives lorsque disponibles.
+
+### 0.8.5 — CLMM decode + materialize
+
+Décoder CLMM et matérialiser pools concentrés, positions, liquidité, ticks et faits de prix nécessaires aux analyses futures.
+
+### 0.8.6 — CLMM executor + scénarios
+
+Ajouter les exécuteurs justifiés et les scénarios réseau avec postconditions observables.
+
+### 0.8.7 — LaunchLab decode + materialize
+
+Décoder LaunchLab et matérialiser les faits de lancement, progression et transition vers les pools lorsqu’ils sont observables on-chain.
+
+### 0.8.8 — LaunchLab executor + scénarios
+
+Ajouter les exécuteurs et scénarios réellement disponibles sans inventer de fixture ou de preuve réseau.
+
+### 0.8.9 — Stable Swap, Lock, legacy et audit des autres programmes Raydium
+
+- couvrir les surfaces encore pertinentes après audit ;
+- maintenir les générations remplacées en decode-only lorsque leur exécution n’est plus justifiée ;
+- auditer les autres Program IDs Raydium découverts et classer explicitement leur priorité ou leur report.
+
+## 0.9.x — Pump
+
+Prioriser les surfaces Pump utiles au cycle de vie d’un token et au trading : Pump.fun, Pump AMM, Pump Fees et autres Program IDs vérifiés. Commencer par un audit de la famille, puis alterner decode + materialize et executor + scénarios comme pour Meteora/Raydium. Auditer notamment les Program IDs déjà recensés dont l’appartenance ou la fonction exacte reste à confirmer avant implémentation.
 
 ## 0.10.x — Orca
 
-Whirlpool, Orca v1/v2, Wavebreak et autres surfaces vérifiées.
+Prioriser Whirlpool, puis auditer Orca v1/v2, Wavebreak et les autres surfaces vérifiées. Conserver la séparation decode + materialize / executor + scénarios et ne maintenir les générations historiques en exécution que lorsqu’elles sont encore réellement utilisables.
 
 ## 0.11.x — Jupiter
 
-Routers, agrégateurs, DCA, ordres, perpetuals, lockers et autres surfaces vérifiées.
+Prioriser les surfaces nécessaires au routing et au trading : routers/agrégateurs, DCA, ordres, perpetuals, lockers et autres Program IDs vérifiés. Séparer les contrats de routing, de marché et de gestion afin de ne pas concentrer Jupiter dans un seul module monolithique.
 
-## 0.12.x — autres routers et protocoles
+## 0.12.x — autres protocoles trading prioritaires
 
-OKX et autres routers, puis surfaces complémentaires classées selon leur priorité réelle.
+Traiter les autres Program IDs ayant une valeur directe pour le trading, le routing, les launchpads, la liquidité ou les dépendances nécessaires aux consommateurs trading. Leur ordre précis doit être décidé à partir des Program IDs réellement recensés à ce stade, et non figé artificiellement plusieurs versions à l’avance.
 
 ## 0.13.x — transports temps réel
 
-WebSocket Helius, LaserStream, Yellowstone gRPC, continuité, backpressure, reconnexion et métriques.
+WebSocket Helius, LaserStream, Yellowstone gRPC, continuité, backpressure, reconnexion, métriques et sélection de transport selon les rôles configurés.
 
 ## 0.14.x — workers et applications consommatrices
 
@@ -115,7 +241,19 @@ WebSocket Helius, LaserStream, Yellowstone gRPC, continuité, backpressure, reco
 - application de contrôle ;
 - application de trading et applications de visualisation.
 
-## 0.15.x+ — extensions futures
+## 0.15.x — reprise de la couverture généraliste différée
 
-- nouveaux protocoles, transports, backfills, observabilité, administration et optimisations validées par des contrats bornés ;
+Reprendre les Program IDs volontairement différés pour accélérer la séquence trading :
+
+- programmes et interfaces SPL non prioritaires ;
+- compléments Metaplex qui n’étaient pas nécessaires aux versions précédentes ;
+- Program IDs non-trading déjà recensés ou découverts au fil des audits ;
+- Program IDs trading secondaires qui n’étaient pas bloquants ;
+- autres surfaces Solana dont le décodage/matérialisation apporte une valeur durable.
+
+Cette phase réaffirme la vocation généraliste de `kb-lib` : la priorité trading des versions précédentes ne transforme pas la bibliothèque en moteur exclusivement DEX.
+
+## 0.16.x+ — extensions futures et off-chain
+
+- nouveaux protocoles, transports, backfills, observabilité, administration et optimisations validés par des contrats bornés ;
 - étudier puis créer `kb-offchain-transport` seulement lorsqu’un consommateur réel le justifie, avec premiers modules metadata HTTP(S), IPFS et Arweave, cache et provenance bornés, hash, contrôle des redirections, limites MIME/taille/timeout et protection SSRF IPv4/IPv6.

docs/IDL_AUDIT.md

@@ -1,5 +1,5 @@
 <!-- file: docs/IDL_AUDIT.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 
 # Audit des IDL v3
 
@@ -10,13 +10,13 @@
 
 ## Audit ciblé Solana Program Metadata — `0.4.8-pre.002`
 
-La copie officielle `metadata.ProgM6JCCvbYkfKqJYHePx4xxSUSqJp7rh8Lyv7nk7S.solana_program_metadata.V0_0_0.from_github_solana_program.json` a été réauditée contre l’IDL Codama publiée par `solana-program/program-metadata`. Le Program ID, la version déclarée `0.0.0`, les trois PDA, les deux comptes, les neuf instructions, les types et les cinq erreurs concordent. Le JSON local reste inchangé et conserve l’empreinte inventoriée. Voir `audits/V0_4_8_PRE_002_METADATA_CONTRACT_AUDIT.md`.
+La copie officielle `metadata.ProgM6JCCvbYkfKqJYHePx4xxSUSqJp7rh8Lyv7nk7S.solana_program_metadata.V0_0_0.from_github_solana_program.json` a été réauditée contre l’IDL Codama publiée par `solana-program/program-metadata`. Le Program ID, la version déclarée `0.0.0`, les trois PDA, les deux comptes, les neuf instructions, les types et les cinq erreurs concordent. Le JSON local reste inchangé et conserve l’empreinte inventoriée. Voir `../olddocs/archivekbot3/docs/audits/V0_4_8_PRE_002_METADATA_CONTRACT_AUDIT.md`.
 
 ## Réconciliation runtime Solana Program Metadata — `0.4.8-pre.005`
 
 L’IDL conserve exactement neuf instructions et reste inchangée. L’audit des tags stables `program@v1.0.0` et `program@v1.0.1` confirme le même inventaire `0..8`. Le processeur actuel accepte toutefois quelques formes supplémentaires par rapport au client Codama : `SetData` peut omettre `data_source` et préserver les données existantes, tandis que `SetImmutable`, `Trim` et `Close` ignorent un suffixe wire. Ces formes sont couvertes comme compatibilité runtime, sans modifier ni réécrire l’IDL.
 
-Le tag `5` a porté le nom de travail `WithdrawExcessLamports` avant la première release stable, puis a été remplacé par `Trim` sur le même discriminant. Il ne constitue pas une instruction historique distincte dans l’inventaire IDL. Voir `audits/V0_4_8_PRE_005_SOLANA_PROGRAM_METADATA_INSTRUCTION_HISTORY_AUDIT.md`.
+Le tag `5` a porté le nom de travail `WithdrawExcessLamports` avant la première release stable, puis a été remplacé par `Trim` sur le même discriminant. Il ne constitue pas une instruction historique distincte dans l’inventaire IDL. Voir `../olddocs/archivekbot3/docs/audits/V0_4_8_PRE_005_SOLANA_PROGRAM_METADATA_INSTRUCTION_HISTORY_AUDIT.md`.
 
 ## Inventaire
 

docs/README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/README.md -->
-<!-- version: 24 -->
+<!-- version: 26 -->
 
 # Documentation active de Khadhroony Bot3
 
@@ -7,7 +7,7 @@
 
 Ce répertoire contient la documentation active, normative ou opérationnelle de `khadhroony-bot3`.
 
-La documentation historique de `khadhroony-bot2` est conservée sous `olddocs/archivekbot2/`. Elle ne doit être ni déplacée vers `docs/`, ni considérée comme normative. Tout nouveau document bot3 est réécrit après lecture du code, des tests, des matrices et des sources historiques pertinentes.
+La documentation historique est conservée sous `olddocs/`. Les documents archivés ne doivent pas être considérés seuls comme normatifs ; les règles, guides, matrices et rapports finaux actifs décrivent l’état courant.
 
 ## 2. Architecture
 
@@ -27,7 +27,8 @@ Règles spécialisées :
 - [`rules/RULES_GENERAL.md`](rules/RULES_GENERAL.md) ;
 - [`rules/RULES_RUST.md`](rules/RULES_RUST.md) ;
 - [`rules/RULES_SPECIFIC_KHADHROONY.md`](rules/RULES_SPECIFIC_KHADHROONY.md) ;
-- [`rules/CRATE_DOCUMENTATION_RULES.md`](rules/CRATE_DOCUMENTATION_RULES.md).
+- [`rules/CRATE_DOCUMENTATION_RULES.md`](rules/CRATE_DOCUMENTATION_RULES.md) ;
+- [`rules/VERSION_DEVELOPMENT_LIFECYCLE.md`](rules/VERSION_DEVELOPMENT_LIFECYCLE.md).
 
 Modèles documentaires non génératifs :
 
@@ -39,17 +40,10 @@ Modèles documentaires non génératifs :
 ## 4. Audits et décisions actifs
 
 - [`audits/V0_4_7_PRE_016_DOCUMENTATION_AND_HEADERS_AUDIT.md`](audits/V0_4_7_PRE_016_DOCUMENTATION_AND_HEADERS_AUDIT.md) ;
-- [`audits/V0_4_8_PRE_002_METADATA_CONTRACT_AUDIT.md`](audits/V0_4_8_PRE_002_METADATA_CONTRACT_AUDIT.md) ;
-- [`audits/V0_4_8_PRE_007_METAPLEX_MATERIALIZER_STRUCTURE_AUDIT.md`](audits/V0_4_8_PRE_007_METAPLEX_MATERIALIZER_STRUCTURE_AUDIT.md) ;
-- [`audits/V0_4_8_PRE_007_MATERIALIZER_CONVENTION_AUDIT.md`](audits/V0_4_8_PRE_007_MATERIALIZER_CONVENTION_AUDIT.md) ;
-- [`audits/V0_4_8_PRE_008_METADATA_SOLANA_PROGRAM_PIPELINE_AUDIT.md`](audits/V0_4_8_PRE_008_METADATA_SOLANA_PROGRAM_PIPELINE_AUDIT.md) ;
-- [`audits/V0_4_8_PRE_008_METADATA_AND_PIPELINE_NOMENCLATURE_AUDIT.md`](audits/V0_4_8_PRE_008_METADATA_AND_PIPELINE_NOMENCLATURE_AUDIT.md) ;
-- [`audits/V0_4_8_PRE_008_SOLANA_PROGRAM_METADATA_HISTORICAL_REPLAY_FIX.md`](audits/V0_4_8_PRE_008_SOLANA_PROGRAM_METADATA_HISTORICAL_REPLAY_FIX.md) ;
-- [`audits/V0_4_8_PRE_009_METADATA_SOLANA_PROGRAM_DEVNET_SCENARIOS_AUDIT.md`](audits/V0_4_8_PRE_009_METADATA_SOLANA_PROGRAM_DEVNET_SCENARIOS_AUDIT.md) ;
 - [`decisions/DOCUMENT_ARCHIVE_SELECTION_POLICY.md`](decisions/DOCUMENT_ARCHIVE_SELECTION_POLICY.md) ;
 - [`decisions/WINCODE_COMPATIBILITY_POLICY.md`](decisions/WINCODE_COMPATIBILITY_POLICY.md).
 
-Ces audits seront archivés sous `olddocs/archivekbot3/` lorsqu’ils auront été remplacés par des documents normatifs ou des rapports de clôture.
+Les audits et rapports de travail `0.4.8-pre.*` sont archivés sous `../olddocs/archivekbot3/`. Leur contenu reste disponible pour la traçabilité mais n’est plus un index actif.
 
 ## 5. Documents techniques actifs
 
@@ -70,11 +64,11 @@ Les matrices canoniques sont conservées sous :
 test-fixtures/contract-matrices/
 ```
 
-Elles peuvent être chargées directement par les tests unitaires ou d’intégration. Elles ne doivent pas être dupliquées sous `docs/`. Les documents actifs peuvent les référencer et expliquer leur rôle.
+Elles peuvent être chargées directement par les tests unitaires ou d’intégration. Elles ne doivent pas être dupliquées sous `docs/`.
 
 ## 7. Documentation par crate
 
-Les onze crates possèdent désormais `README.md`, `TODO.md`, `USAGE.md` et `CHANGELOG.md` :
+Les onze crates possèdent `README.md`, `TODO.md`, `USAGE.md` et `CHANGELOG.md` :
 
 - [`kb-core`](../kb-core/README.md) ;
 - [`kb-config`](../kb-config/README.md) ;
@@ -88,39 +82,30 @@ Les onze crates possèdent désormais `README.md`, `TODO.md`, `USAGE.md` et `CHA
 - [`kb-wallet`](../kb-wallet/README.md) ;
 - [`kb-app-demo-desktop`](../kb-app-demo-desktop/README.md).
 
-## Guides
+## 8. Guides
 
-- [Configuration](guides/CONFIGURATION.md)
+- [Configuration](guides/CONFIGURATION.md) ;
-- [Logging et tracing](guides/LOGGING.md)
+- [Logging et tracing](guides/LOGGING.md) ;
-- [RPC, backfill et WebSocket](guides/RPC_BACKFILL_AND_WEBSOCKET.md)
+- [RPC, backfill et WebSocket](guides/RPC_BACKFILL_AND_WEBSOCKET.md) ;
-- [Extraction Core, replay et matérialisation](guides/REPLAY_CORE_EXTRACTION_AND_MATERIALIZATION.md)
+- [Extraction Core, replay et matérialisation](guides/REPLAY_CORE_EXTRACTION_AND_MATERIALIZATION.md) ;
-- [PostgreSQL et stockage](guides/POSTGRES_STORAGE.md)
+- [PostgreSQL et stockage](guides/POSTGRES_STORAGE.md) ;
-- [Validation Devnet](guides/DEVNET_VALIDATION.md)
+- [Validation Devnet](guides/DEVNET_VALIDATION.md).
-- [Validation Metaplex Token Metadata 0.4.7](validation/V0_4_7_METAPLEX_TOKEN_METADATA_VALIDATION_REPORT.md)
+
+## 9. Rapports de validation actifs
+
+- [Validation Metaplex Token Metadata 0.4.7](validation/V0_4_7_METAPLEX_TOKEN_METADATA_VALIDATION_REPORT.md) ;
+- [Validation Metadata on-chain et clôture 0.4.8](validation/V0_4_8_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) ;
+- [`validation/MAINNET_RESEARCH_BACKFILL_VALIDATION_SCENARIO.md`](validation/MAINNET_RESEARCH_BACKFILL_VALIDATION_SCENARIO.md).
-- [`validation/V0_4_8_PRE_008_SOLANA_PROGRAM_METADATA_MAINNET_REPLAY_REPORT.md`](validation/V0_4_8_PRE_008_SOLANA_PROGRAM_METADATA_MAINNET_REPLAY_REPORT.md) ;
-- [`validation/V0_4_8_PRE_010_SOLANA_PROGRAM_METADATA_DEVNET_VALIDATION_REPORT.md`](validation/V0_4_8_PRE_010_SOLANA_PROGRAM_METADATA_DEVNET_VALIDATION_REPORT.md) — preuve de deux campagnes Devnet complètes couvrant les neuf opérations Solana Program Metadata ;
-- [`validation/V0_4_8_PRE_012_TOKEN_2022_METADATA_DEVNET_VALIDATION_REPORT.md`](validation/V0_4_8_PRE_012_TOKEN_2022_METADATA_DEVNET_VALIDATION_REPORT.md) — preuve Devnet des cinq opérations Token-2022 Token Metadata ;
-- [`validation/V0_4_8_PRE_013_METAPLEX_FINAL_VALIDATION_REPORT.md`](validation/V0_4_8_PRE_013_METAPLEX_FINAL_VALIDATION_REPORT.md) — clôture de la matrice Metaplex à 15 `confirmed`, 5 `unavailable`, 0 `not_run` ;
-- [`validation/V0_4_8_PRE_014_DESKTOP_METADATA_VALIDATION_REPORT.md`](validation/V0_4_8_PRE_014_DESKTOP_METADATA_VALIDATION_REPORT.md) — validation des trois domaines Metadata dans le desktop ;
 
-## Audits actifs
+Les preuves détaillées de `0.4.8-pre.*` restent accessibles sous `../olddocs/archivekbot3/docs/validation/` et dans `validation/evidence/v0.4.8/`.
 
-- [`Audit contractuel 0.4.8-pre.002 — metadata`](audits/V0_4_8_PRE_002_METADATA_CONTRACT_AUDIT.md) ;
+## 10. Plans de version actifs
-- [`Audit 0.4.8-pre.005 — instructions et historique Solana Program Metadata`](audits/V0_4_8_PRE_005_SOLANA_PROGRAM_METADATA_INSTRUCTION_HISTORY_AUDIT.md) ;
-- [`Audit 0.4.8-pre.007 — structure du matérialiseur Metaplex Token Metadata`](audits/V0_4_8_PRE_007_METAPLEX_MATERIALIZER_STRUCTURE_AUDIT.md) ;
-- [`Audit 0.4.8-pre.007 — conventions et structure de tous les matérialisateurs`](audits/V0_4_8_PRE_007_MATERIALIZER_CONVENTION_AUDIT.md) ;
-- [`Audit 0.4.8-pre.008 — pipeline Solana Program Metadata`](audits/V0_4_8_PRE_008_METADATA_SOLANA_PROGRAM_PIPELINE_AUDIT.md) ;
-- [`Correctif 0.4.8-pre.008 — replay historique Solana Program Metadata`](audits/V0_4_8_PRE_008_SOLANA_PROGRAM_METADATA_HISTORICAL_REPLAY_FIX.md) ;
-- [`Audit 0.4.8-pre.009 — scénarios Devnet Solana Program Metadata`](audits/V0_4_8_PRE_009_METADATA_SOLANA_PROGRAM_DEVNET_SCENARIOS_AUDIT.md) ;
-- [`Audit 0.4.8-pre.011 — complétude Token-2022 Token Metadata`](audits/V0_4_8_PRE_011_TOKEN_2022_METADATA_COMPLETENESS_AUDIT.md) ;
-- [`Audit transversal 0.4.8-pre.015 — Metadata`](audits/V0_4_8_PRE_015_METADATA_TRANSVERSAL_RECONCILIATION_AUDIT.md).
 
-## Plans de version actifs
+Aucun plan de version temporaire n’est actif après la clôture de `0.4.8`. Le plan `0.4.8` est archivé sous `../olddocs/archivekbot3/docs/plans/`.
 
-- [`Plan 0.4.8 — Solana Program Metadata et complétude Token-2022`](plans/V0_4_8_SOLANA_PROGRAM_METADATA_AND_TOKEN_2022_COMPLETENESS_PLAN.md).
+Le prochain plan sera créé pendant la première prerelease de `0.5.0`, après audit et brainstorming.
 
-## Prompt de reprise
+## 11. Prompt de reprise
 
-- [`Prompt actif 0.4.8`](../prompts/028_v0_4_8_spl_token_metadata_and_offchain_decision.md).
+- [`Prompt actif 0.5.0`](../prompts/029_v0_5_0_foundation_restructuring_plan.md).

docs/rules/RULES_SPECIFIC_KHADHROONY.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_SPECIFIC_KHADHROONY.md -->
-<!-- version: 10 -->
+<!-- version: 11 -->
 
 # Règles spécifiques à `khadhroony-bot3`
 
@@ -266,8 +266,11 @@ Les `program_id` connus doivent être définis une seule fois dans `kb-program-i
 ## Validation frontend Tauri
 
 - Pour `kb-app-demo-desktop`, ne jamais exécuter `npm run build`, `npm --prefix kb-app-demo-desktop run build` ni une commande équivalente de build frontend autonome.
-- L’installation manuelle d’une dépendance frontend est limitée aux commandes npm d’ajout nécessaires, notamment `npm i -D <package>` pour une dépendance de développement ; `node_modules/` et `package-lock.json` restent locaux, générés et non livrables.
+- Les commandes npm manuelles sont limitées à l’installation explicite de dépendances nécessaires, notamment `npm i` et `npm i -D <package>` ; `node_modules/` et `package-lock.json` restent locaux, générés et non livrables.
 - La validation frontend de développement est réalisée uniquement par `cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json`, qui démarre et pilote Vite selon la configuration Tauri.
+- La validation frontend de release est réalisée uniquement par `cargo tauri build -c kb-app-demo-desktop/tauri.conf.json` ; Tauri déclenche alors son `beforeBuildCommand` et pilote TypeScript/Vite.
+- Lorsque Vite utilise `root: 'frontend'`, son `build.outDir` et le `frontendDist` Tauri doivent résoudre explicitement vers le même répertoire physique. Pour la configuration `0.4.8`, `../../dist` côté Vite et `../dist` côté Tauri désignent le `dist` situé à la racine du workspace.
+- Le répertoire `dist/` est généré localement et ne doit jamais être inclus dans un delta source.
 
 ## Architecture `khadhroony-bot3`
 

docs/validation/V0_4_8_METADATA_VALIDATION_REPORT.md

@@ -0,0 +1,117 @@
+<!-- file: docs/validation/V0_4_8_METADATA_VALIDATION_REPORT.md -->
+<!-- version: 3 -->
+
+# Validation fonctionnelle — Metadata on-chain et clôture 0.4.8
+
+## Périmètre
+
+La version `0.4.8` ferme trois domaines Metadata on-chain strictement séparés :
+
+- Solana Program Metadata `ProgM6JCCvbYkfKqJYHePx4xxSUSqJp7rh8Lyv7nk7S` ;
+- Token-2022 Token Metadata via `spl-token-metadata-interface` ;
+- Metaplex Token Metadata `metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s`.
+
+Elle couvre les contrats on-chain, décodeurs, matérialisateurs, exécuteurs lorsque applicables, orchestration stateful, scénarios réutilisables et validation desktop.
+
+## Qualification réseau
+
+### Solana Program Metadata
+
+Les neuf opérations stables sont `confirmed` sur Devnet avec simulation, soumission, confirmation, lectures stateful, replay canonique et matérialisation.
+
+### Token-2022 Token Metadata
+
+Les cinq opérations de l’interface sont `confirmed` sur Devnet :
+
+- `Initialize` ;
+- `UpdateField` ;
+- `Emit` ;
+- `RemoveKey` ;
+- `UpdateAuthority`.
+
+### Metaplex Token Metadata
+
+La matrice Devnet courante des vingt opérations est close :
+
+- 15 `confirmed` ;
+- 5 `unavailable` ;
+- 0 `not_run`.
+
+Les cinq opérations indisponibles restent explicitement bornées par les observations runtime documentées pendant `0.4.8-pre.013` ; elles ne sont jamais promues depuis une validation synthétique.
+
+## Desktop Metadata
+
+`kb-app-demo-desktop` sépare les trois domaines Metadata et appelle les scénarios réutilisables de `kb-pipeline-demo-scenarios`.
+
+La validation finale couvre notamment :
+
+- synchronisation du profil Devnet ;
+- campagnes spécialisées Metaplex ;
+- campagne Token-2022 Token Metadata ;
+- campagne Solana Program Metadata ;
+- JsonViewer pour les résultats structurés ;
+- accordéons de préflight, simulation/confirmation et postconditions/preuves ;
+- carte des exigences dans la colonne de résultats ;
+- journal d’exécution sur toute la largeur.
+
+## Conformité finale du workspace
+
+La campagne finale du 9 août 2026 est conforme :
+
+- `cargo fmt --all` réussi ;
+- `cargo check --workspace` réussi ;
+- `cargo clippy --all-targets` réussi sans warning ;
+- `python3 scripts/audit_rust_workspace_rules.py` : audit Rust général propre, export completeness à zéro candidat et audit Khadhroony propre ;
+- `cargo test --workspace` réussi sur toutes les crates, tous les tests d’intégration et toutes les doctests.
+
+Les principales cibles unitaires observées comprennent :
+
+- `kb-app-demo-desktop` : 144 tests ;
+- `kb-config` : 46 tests ;
+- `kb-core` : 2 tests ;
+- `kb-lib` : 706 tests, plus 9 tests d’intégration ;
+- `kb-logging` : 17 tests ;
+- `kb-onchain-transport` : 118 tests ;
+- `kb-pipeline` : 109 tests, plus 3 tests d’intégration Metadata ;
+- `kb-pipeline-demo-scenarios` : 105 tests bibliothèque, 1 test CLI et 1 test API externe ;
+- `kb-program-ids` : 6 tests ;
+- `kb-store` : 84 tests ;
+- `kb-wallet` : 6 tests.
+
+## Build desktop de release
+
+La validation frontend n’est pas exécutée par un `npm run build` autonome.
+
+La commande de release utilisée est :
+
+```bash
+cargo tauri build -c kb-app-demo-desktop/tauri.conf.json
+```
+
+Tauri déclenche le `beforeBuildCommand`, qui exécute TypeScript puis Vite. La configuration validée utilise :
+
+- `root: 'frontend'` et `build.outDir: '../../dist'` côté Vite ;
+- `frontendDist: '../dist'` côté Tauri.
+
+Ces deux chemins convergent vers le même répertoire `dist` à la racine du workspace.
+
+Le build de release a produit avec succès :
+
+- `Khadhroony Bot3 Demo Desktop_0.4.8_amd64.deb` ;
+- `Khadhroony Bot3 Demo Desktop-0.4.8-1.x86_64.rpm` ;
+- `Khadhroony Bot3 Demo Desktop_0.4.8_amd64.AppImage`.
+
+## Limites et reports
+
+- aucun fetch HTTP/IPFS/Arweave n’est intégré au replay canonique ;
+- la couverture généraliste différée — programmes/interfaces SPL non prioritaires, compléments Metaplex et autres Program IDs non bloquants pour la séquence trading prioritaire — est reportée à `0.15.x` ;
+- `kb-offchain-transport` est reportée à `0.16.x+` après repriorisation du ROADMAP ;
+- le registre ElGamal reste sans preuve réseau réelle disponible.
+
+## Traçabilité
+
+Les audits, rapports de prerelease et le plan de travail `0.4.8` sont archivés sous `olddocs/archivekbot3/`. Ils conservent la chronologie détaillée mais ne sont plus normatifs.
+
+## Statut
+
+**Version fonctionnelle `0.4.8` clôturée et validée.**

docs/validation/evidence/v0.4.8/pre.008/mainnet/README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/validation/evidence/v0.4.8/pre.008/mainnet/README.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Preuve mainnet `0.4.8-pre.008`
 
@@ -13,6 +13,6 @@ Ce répertoire conserve la preuve binaire de la campagne historique ayant valid
 - usage : preuve documentaire et diagnostic reproductible ;
 - chargement applicatif : aucun.
 
-L’archive ne doit pas être extraite dans l’arbre source. Elle est référencée par le rapport `docs/validation/V0_4_8_PRE_008_SOLANA_PROGRAM_METADATA_MAINNET_REPLAY_REPORT.md`.
+L’archive ne doit pas être extraite dans l’arbre source. Elle est référencée par le rapport `olddocs/archivekbot3/docs/validation/V0_4_8_PRE_008_SOLANA_PROGRAM_METADATA_MAINNET_REPLAY_REPORT.md`.
 
 Un contrôle avant archivage n’a trouvé ni fichier de wallet, ni keypair, ni `.env`, ni marqueur d’URL ou d’autorisation dans les contenus textuels. Cette vérification ne remplace pas une revue humaine avant publication hors du dépôt privé.

docs/validation/evidence/v0.4.8/pre.010/devnet/README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/validation/evidence/v0.4.8/pre.010/devnet/README.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Preuve Devnet `0.4.8-pre.010`
 
@@ -14,4 +14,4 @@ L’archive a été renommée lors de son intégration : son nom source contenai
 
 Cette preuve est documentaire. Aucun test, runner ou composant runtime ne la charge.
 
-Le rapport associé est [`V0_4_8_PRE_010_SOLANA_PROGRAM_METADATA_DEVNET_VALIDATION_REPORT.md`](../../../../V0_4_8_PRE_010_SOLANA_PROGRAM_METADATA_DEVNET_VALIDATION_REPORT.md).
+Le rapport associé est `olddocs/archivekbot3/docs/validation/V0_4_8_PRE_010_SOLANA_PROGRAM_METADATA_DEVNET_VALIDATION_REPORT.md`.

kb-app-demo-desktop/CHANGELOG.md

@@ -1,8 +1,15 @@
 <!-- file: kb-app-demo-desktop/CHANGELOG.md -->
-<!-- version: 38 -->
+<!-- version: 39 -->
 
 # CHANGELOG — kb-app-demo-desktop
 
+## 0.4.8-pre.016
+
+- corrige la sortie de build Vite pour tenir compte de `root: 'frontend'` : `build.outDir` pointe vers `../../dist` et la page `demo_execution_metadata.html` est référencée sous son nom réel ;
+- aligne `tauri.conf.json` sur le même répertoire physique avec `frontendDist: '../dist'` ;
+- confirme la règle de validation : aucun `npm run build` autonome, le build frontend est déclenché par `cargo tauri build` via `beforeBuildCommand` ;
+- valide le build release complet et la génération des bundles `.deb`, `.rpm` et `.AppImage` en version desktop `0.4.8`.
+
 ## 0.4.8-pre.014
 
 - `pre.014-delta-fix-004` clôture la finalisation desktop Metadata après validation de `fix-003` : formatage, `cargo check --workspace`, Clippy sans warning, audit workspace et 144 tests desktop sont propres ; la disposition finale des trois accordéons de résultats, de la carte **Exigences** et du journal pleine largeur est validée visuellement ;

kb-app-demo-desktop/USAGE.md

@@ -1,5 +1,5 @@
 <!-- file: kb-app-demo-desktop/USAGE.md -->
-<!-- version: 13 -->
+<!-- version: 14 -->
 
 # Utilisation de kb-app-demo-desktop
 
@@ -17,6 +17,16 @@ cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
 
 Le binaire applique un verrou d’instance locale. Une deuxième instance doit échouer proprement.
 
+## Construire la release desktop
+
+Depuis la racine du workspace :
+
+```bash
+cargo tauri build -c kb-app-demo-desktop/tauri.conf.json
+```
+
+Ne pas lancer `npm run build` directement. Tauri exécute le `beforeBuildCommand` configuré, puis consomme le même répertoire `dist` que Vite. Les commandes npm manuelles sont réservées à l’installation explicite de dépendances nécessaires.
+
 ## API Rust publique
 
 La bibliothèque expose uniquement `run()` :

kb-app-demo-desktop/tauri.conf.json

@@ -7,7 +7,7 @@
         "beforeDevCommand": "npm run dev",
         "devUrl": "http://localhost:1420",
         "beforeBuildCommand": "npm run build",
-        "frontendDist": "./dist"
+        "frontendDist": "../dist"
     },
     "app": {
         "windows": [

kb-app-demo-desktop/vite.config.ts

@@ -1,5 +1,5 @@
 // file: kb-app-demo-desktop/vite.config.ts
-// version: 8
+// version: 9
 
 import { defineConfig, normalizePath } from "vite";
 import { NodePackageImporter } from "sass-embedded";
@@ -17,7 +17,7 @@ export default defineConfig(() => ({
     root: 'frontend', // Set this to your frontend directory
     publicDir: 'public',
     build: {
-        outDir: './dist', // Output directory for the build
+        outDir: '../../dist', // Output directory for the build
         emptyOutDir: true,
         rollupOptions: {
             input: {
@@ -35,7 +35,7 @@ export default defineConfig(() => ({
                 "demo_sql_replay_candidates": normalizePath(resolve(__dirname, 'frontend/demo_sql_replay_candidates.html')),
                 "demo_execution_solana_core": normalizePath(resolve(__dirname, 'frontend/demo_execution_solana_core.html')),
                 "demo_execution_spl": normalizePath(resolve(__dirname, 'frontend/demo_execution_spl.html')),
-                "demo_execution_metatdata": normalizePath(resolve(__dirname, 'frontend/demo_execution_metatdata.html')),
+                "demo_execution_metatdata": normalizePath(resolve(__dirname, 'frontend/demo_execution_metadata.html')),
             },
             output: {
                 entryFileNames: 'js/[name]-[hash].js',

kb-lib/README.md

@@ -1,5 +1,5 @@
 <!-- file: kb-lib/README.md -->
-<!-- version: 27 -->
+<!-- version: 28 -->
 
 # kb-lib
 
@@ -48,7 +48,7 @@ L’arbre `src/materializer` suit un contrat homogène :
 - une identité runtime `kb-lib.materializer.*` distincte du `processorName` persisté `materializer.*` ;
 - des coquilles réservées réellement inactives sur les deux contrats legacy et contextuel.
 
-L’inventaire audité comprend 25 composants nommés : onze matérialisateurs actifs et quatorze coquilles réservées. Les composants metadata Metaplex Token Metadata, Solana Program Metadata et Token-2022 possèdent chacun un type spécialisé, une identité propre et leurs APIs de snapshots lorsque leur état on-chain l’exige. Le détail est consigné dans [l’audit de convention des matérialisateurs](../docs/audits/V0_4_8_PRE_007_MATERIALIZER_CONVENTION_AUDIT.md).
+L’inventaire audité comprend 25 composants nommés : onze matérialisateurs actifs et quatorze coquilles réservées. Les composants metadata Metaplex Token Metadata, Solana Program Metadata et Token-2022 possèdent chacun un type spécialisé, une identité propre et leurs APIs de snapshots lorsque leur état on-chain l’exige. Le détail est consigné dans [l’audit de convention des matérialisateurs](../olddocs/archivekbot3/docs/audits/V0_4_8_PRE_007_MATERIALIZER_CONVENTION_AUDIT.md).
 
 ## Responsabilités
 
@@ -102,6 +102,6 @@ Le registre ElGamal n’est pas déclaré validé réellement sur réseau.
 - [Matrice des instructions Solana Program Metadata](../test-fixtures/contract-matrices/SOLANA_PROGRAM_METADATA_INSTRUCTION_MATRIX.json)
 - [Matrice de matérialisation Solana Program Metadata](../test-fixtures/contract-matrices/SOLANA_PROGRAM_METADATA_MATERIALIZATION_MATRIX.json)
 - [Matrice d’exécution Solana Program Metadata](../test-fixtures/contract-matrices/SOLANA_PROGRAM_METADATA_EXECUTOR_MATRIX.json)
-- [Audit de l’inventaire et de l’historique des instructions](../docs/audits/V0_4_8_PRE_005_SOLANA_PROGRAM_METADATA_INSTRUCTION_HISTORY_AUDIT.md)
+- [Audit de l’inventaire et de l’historique des instructions](../olddocs/archivekbot3/docs/audits/V0_4_8_PRE_005_SOLANA_PROGRAM_METADATA_INSTRUCTION_HISTORY_AUDIT.md)
 
 - complétude d’exécution des cinq instructions Token-2022 Token Metadata, y compris `UpdateAuthority` et `Emit` ;

kb-pipeline-demo-scenarios/USAGE.md

@@ -1,5 +1,5 @@
 <!-- file: kb-pipeline-demo-scenarios/USAGE.md -->
-<!-- version: 25 -->
+<!-- version: 26 -->
 
 # Utilisation de kb-pipeline-demo-scenarios
 
@@ -115,7 +115,7 @@ cargo test -p kb-pipeline-demo-scenarios optional_devnet_token_2022_metadata_cam
 
 `KB_DEVNET_PROFILE` peut sélectionner explicitement le profil Devnet et `KB_DEVNET_CONFIG_PATH` peut remplacer `config/example.config.json`. Le profil doit utiliser un wallet persistant, autoriser les soumissions Devnet et respecter les plafonds de dépense et de frais.
 
-La sortie `TOKEN_2022_METADATA_FIXTURE` conserve le mint et la signature de préparation. Chaque ligne `TOKEN_2022_METADATA_STEP` conserve l’opération, la signature, le slot, la postcondition, le nombre de matérialisations et, pour `Emit`, la taille du `returnData`. La campagne de référence de `pre.012` a été exécutée avec succès et ses preuves sont conservées dans `SPL_TOKEN_2022_METADATA_DEVNET_VALIDATION_MATRIX.json` et dans le rapport `V0_4_8_PRE_012_TOKEN_2022_METADATA_DEVNET_VALIDATION_REPORT.md`. Une nouvelle exécution produit de nouvelles transactions et ne remplace ces preuves qu’après validation explicite.
+La sortie `TOKEN_2022_METADATA_FIXTURE` conserve le mint et la signature de préparation. Chaque ligne `TOKEN_2022_METADATA_STEP` conserve l’opération, la signature, le slot, la postcondition, le nombre de matérialisations et, pour `Emit`, la taille du `returnData`. La campagne de référence de `pre.012` a été exécutée avec succès et ses preuves sont conservées dans `SPL_TOKEN_2022_METADATA_DEVNET_VALIDATION_MATRIX.json` et dans le rapport `docs/validation/V0_4_8_METADATA_VALIDATION_REPORT.md` ; le rapport détaillé `pre.012` est archivé sous `olddocs/archivekbot3/docs/validation/`. Une nouvelle exécution produit de nouvelles transactions et ne remplace ces preuves qu’après validation explicite.
 
 ## Charger la matrice de validation Token-2022
 
@@ -293,6 +293,7 @@ fn load_metaplex_devnet_contract(
 ```
 
 La matrice ne transforme jamais une implémentation disponible en validation réseau. Les valeurs restent `not_run` jusqu’à l’observation d’une simulation ou d’une confirmation réelle.
+
 ## Exécuter une opération Metaplex courante depuis un JSON typé
 
 Le runner Devnet commun accepte toute variante non dépréciée de `ExMetaplexTokenMetadataOperation`. Le test opt-in peut être lancé avec :
@@ -472,6 +473,27 @@ Le bundle qualifiant de `pre.013` confirme `Update` et conserve les refus runtim
 
 Le bilan courant de la matrice Devnet Metaplex est **15 `confirmed`, 5 `unavailable`, 0 `not_run`**. Les campagnes restent réexécutables pour diagnostiquer une régression ou un changement de runtime, mais ne constituent plus des tâches ouvertes de `pre.013`.
 
+### Preuve machine-readable `Create -> Mint`
+
+À partir de `pre.013-delta-fix-012`, une campagne réussie imprime en plus une ligne unique `METAPLEX_CREATE_MINT_EVIDENCE`. Elle contient les deux objets `create` et `mint` avec le cluster, le genesis hash, le slot RPC de simulation, le nombre de logs, le message hash exact, le fee estimé, la signature, le statut/slot de confirmation, les nombres de snapshots et matérialisations ainsi que les drapeaux canonical/Core/replay/idempotence. Cette ligne est la forme à conserver pour les futures promotions de matrice.
+
+Les cinq familles NFT, SFT, fungible, collection et pNFT sont confirmées. `Create` et `Mint` disposent chacune de cinq bundles `familyEvidence`; le pNFT prouve en plus la création du Token Record et l’état ATA `Initialized(1) -> Frozen(2)`.
+
+## Probe Devnet Metaplex `Use`
+
+La surface courante `Use` est classée `unavailable` sur Devnet : la simulation exacte du discriminant 51 retourne `InvalidInstructionData` et aucune transaction n'est soumise. Le test opt-in reste utile comme contrôle de non-régression du runtime :
+
+```bash
+KB_DEVNET_METAPLEX_USE_PROBE_TEST=1 \
+KB_DEVNET_METAPLEX_OPERATOR_CONFIRMED=1 \
+KB_POSTGRES_TEST_URL='postgres://solana:solana@localhost:5432/solana_test' \
+cargo test -p kb-pipeline-demo-scenarios \
+  optional_devnet_metaplex_use_probe_from_env \
+  -- --nocapture
+```
+
+Une simulation négative est retournée comme résultat uniquement lorsque `submit=false`. Elle ne peut jamais autoriser une signature ou une soumission.
+
 ## Solana Program Metadata
 
 L’inventaire fermé est exposé par :
@@ -521,23 +543,3 @@ where
 Cet appel crée des comptes et soumet onze transactions réelles au minimum : deux transferts de préfinancement et neuf opérations `ProgM6…`. Il ne doit jamais être déclenché implicitement par une ouverture de fenêtre ou une simple demande de simulation.
 
 La matrice `SOLANA_PROGRAM_METADATA_DEVNET_VALIDATION_MATRIX.json` est fermée à neuf opérations `confirmed` depuis `0.4.8-pre.010`. Les deux parcours conservent leurs signatures, simulations, postconditions et preuves matérialisées ; `Close` utilise une preuve `account_absence`, car un compte absent ne produit pas de snapshot matérialisé. Une réexécution n’est nécessaire qu’en cas de régression ou de changement du runtime Devnet.
-### Preuve machine-readable `Create -> Mint`
-
-À partir de `pre.013-delta-fix-012`, une campagne réussie imprime en plus une ligne unique `METAPLEX_CREATE_MINT_EVIDENCE`. Elle contient les deux objets `create` et `mint` avec le cluster, le genesis hash, le slot RPC de simulation, le nombre de logs, le message hash exact, le fee estimé, la signature, le statut/slot de confirmation, les nombres de snapshots et matérialisations ainsi que les drapeaux canonical/Core/replay/idempotence. Cette ligne est la forme à conserver pour les futures promotions de matrice.
-
-Les cinq familles NFT, SFT, fungible, collection et pNFT sont confirmées. `Create` et `Mint` disposent chacune de cinq bundles `familyEvidence`; le pNFT prouve en plus la création du Token Record et l’état ATA `Initialized(1) -> Frozen(2)`.
-
-## Probe Devnet Metaplex `Use`
-
-La surface courante `Use` est classée `unavailable` sur Devnet : la simulation exacte du discriminant 51 retourne `InvalidInstructionData` et aucune transaction n'est soumise. Le test opt-in reste utile comme contrôle de non-régression du runtime :
-
-```bash
-KB_DEVNET_METAPLEX_USE_PROBE_TEST=1 \
-KB_DEVNET_METAPLEX_OPERATOR_CONFIRMED=1 \
-KB_POSTGRES_TEST_URL='postgres://solana:solana@localhost:5432/solana_test' \
-cargo test -p kb-pipeline-demo-scenarios \
-  optional_devnet_metaplex_use_probe_from_env \
-  -- --nocapture
-```
-
-Une simulation négative est retournée comme résultat uniquement lorsque `submit=false`. Elle ne peut jamais autoriser une signature ou une soumission.

olddocs/archivekbot3/001.README.md

@@ -1,5 +1,5 @@
 <!-- file: olddocs/archivekbot3/001.README.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Archive documentaire de khadhroony-bot3
 
@@ -28,3 +28,7 @@ Les audits, guides et checklist temporaires utilisés pour clôturer la migratio
 ## Clôture 0.4.7
 
 Le plan, le prompt de session et les rapports de prerelease de Metaplex Token Metadata sont archivés sous `docs/plans/`, `docs/validation/` et `prompts/`. Le rapport final actif reste sous `docs/validation/` jusqu’à la publication.
+
+## Clôture 0.4.8
+
+Le plan `0.4.8`, le prompt de session `028`, les audits `V0_4_8_PRE_*` et les rapports de validation de prerelease sont archivés sous `docs/plans/`, `docs/audits/`, `docs/validation/` et `prompts/`. Le rapport fonctionnel final `0.4.8` reste actif sous `docs/validation/`.

olddocs/archivekbot3/docs/audits/V0_4_8_PRE_010_METADATA_SOLANA_PROGRAM_DESKTOP_INTEGRATION_AUDIT.md

@@ -1,5 +1,5 @@
 <!-- file: docs/audits/V0_4_8_PRE_010_METADATA_SOLANA_PROGRAM_DESKTOP_INTEGRATION_AUDIT.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 
 # Audit `0.4.8-pre.010` — structure Metadata et exécution Devnet
 
@@ -126,4 +126,3 @@ Initialize -> SetData -> SetImmutable
 ```
 
 Le profil public Devnet de l’exemple est également abaissé à `3 r/s` pour les lectures et `1 r/s` pour les transactions. Les anciens fichiers de configuration locaux doivent être ajustés manuellement.
-

olddocs/archivekbot3/docs/audits/V0_4_8_PRE_015_METADATA_TRANSVERSAL_RECONCILIATION_AUDIT.md

@@ -33,7 +33,7 @@ Metaplex Token Metadata, Token-2022 Token Metadata et Solana Program Metadata n
 Les matrices actives restent cohérentes entre elles :
 
 | Matrice | Inventaire |
-|----------------------|------------------------------------:|
+|---|---:|
 | comptes | 3 entrées |
 | instructions stables | 9 |
 | exécuteur | 9 opérations |

olddocs/archivekbot3/docs/plans/V0_4_8_SOLANA_PROGRAM_METADATA_AND_TOKEN_2022_COMPLETENESS_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/V0_4_8_SOLANA_PROGRAM_METADATA_AND_TOKEN_2022_COMPLETENESS_PLAN.md -->
-<!-- version: 62 -->
+<!-- version: 64 -->
 
 # Plan `0.4.8` — Solana Program Metadata et complétude Token-2022
 
@@ -16,7 +16,7 @@ Il doit être maintenu pendant chaque prerelease, puis archivé pendant la derni
 ### 2.1 Surfaces strictement distinctes
 
 | Surface                           | Program ID ou frontière                                            | Rôle dans `0.4.8`                                                               |
-|-----------------------------------|--------------------------------------------------------------------|----------------------------------------------------------------------------------------------------|
+|-----------------------------------|--------------------------------------------------------------------|---------------------------------------------------------------------------------|
 | Metaplex Token Metadata           | `metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s`                      | surface héritée de `0.4.7`, réauditée et qualifiée à 15 `confirmed` / 5 `unavailable` en `pre.013` |
 | Token-2022 Token Metadata         | programme Token-2022 `TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb` | complétude livrée en `pre.011` et validée sur Devnet en `pre.012`                |
 | `spl-token-metadata-interface`    | interface sans Program ID autonome imposé                          | source contractuelle des instructions metadata implémentées par Token-2022      |
@@ -519,7 +519,7 @@ La validation locale du correctif `fix-001` confirme `cargo fmt --all`, `cargo c
 
 La dernière passe ne relève plus de divergence fonctionnelle entre stockage, matrices courantes, registres runtime, exports, IDL, TODO et documentation opérationnelle. Les occurrences `not_run` restantes sont confinées aux matrices et rapports historiques dont le milestone est volontairement figé. Les documents de release de niveau workspace — transformation finale du ROADMAP et mise à jour du CHANGELOG général — restent explicitement réservés à `pre.016`, conformément au cycle de clôture. `pre.015` est donc clôturée sans migration de stockage ni nouvelle campagne Devnet.
 
-### `0.4.8-pre.016` — clôture obligatoire
+### `0.4.8-pre.016` — clôture obligatoire — terminée et validée
 
 Réservée à :
 
@@ -534,6 +534,16 @@ Réservée à :
 
 Aucune nouvelle campagne Devnet fondamentale ne doit être découverte pendant cette phase.
 
+#### `pre.016-delta` — ouverture de la conformité finale
+
+Le workspace passe à `0.4.8-pre.16` sans modifier les versions desktop `0.4.8`. Le ROADMAP reçoit les décisions durables de `0.4.7` et `0.4.8`, tandis que le CHANGELOG général reste inchangé jusqu’à la validation finale explicite.
+
+La campagne de conformité finale doit couvrir au minimum : formatage, compilation workspace, Clippy tous targets, audit des règles, tests de tout le workspace et build frontend. Le build Tauri de release est également requis pour vérifier l’assemblage final du desktop. Aucun statut réseau ne doit être rouvert en l’absence de régression.
+
+La campagne finale du 9 août 2026 valide `cargo fmt --all`, `cargo check --workspace`, `cargo clippy --all-targets`, l’audit complet des règles et `cargo test --workspace`. Le build de release est exécuté par `cargo tauri build -c kb-app-demo-desktop/tauri.conf.json`, qui déclenche lui-même TypeScript/Vite et produit les bundles `.deb`, `.rpm` et `.AppImage`. Aucun `npm run build` autonome ne fait partie du protocole de validation.
+
+Le dernier correctif de `pre.016` met à jour le CHANGELOG général, finalise le ROADMAP, prépare le prompt `0.5.0`, archive les audits/rapports de prerelease, le prompt `0.4.8` et le présent plan, puis corrige les références actives. `pre.016` est donc clôturée sans nouvelle fonctionnalité ni nouvelle campagne Devnet.
+
 ## 8. Discipline documentaire par delta
 
 Chaque delta doit :
@@ -565,5 +575,5 @@ 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
+cargo tauri build -c kb-app-demo-desktop/tauri.conf.json
 ```

olddocs/archivekbot3/docs/validation/V0_4_8_PRE_013_METAPLEX_PNFT_LIFECYCLE_DEVNET_VALIDATION_REPORT.md

@@ -1,5 +1,5 @@
 <!-- file: docs/validation/V0_4_8_PRE_013_METAPLEX_PNFT_LIFECYCLE_DEVNET_VALIDATION_REPORT.md -->
-<!-- version: 7 -->
+<!-- version: 8 -->
 
 # Validation Devnet `0.4.8-pre.013` — cycle pNFT delegates
 
@@ -199,4 +199,3 @@ destination TokenRecord         = Unlocked / no delegate
 ```
 
 Cette preuve ferme le lot pNFT et autorise la promotion des cinq opérations canoniques `Delegate`, `Revoke`, `Lock`, `Unlock` et `Transfer` sur la famille `programmable_nft`. La matrice Devnet passe ainsi de 6/20 à 11/20 opérations confirmées.
-

olddocs/archivekbot3/docs/validation/V0_4_8_PRE_016_FINAL_CONFORMITY_VALIDATION_REPORT.md

@@ -0,0 +1,82 @@
+<!-- file: docs/validation/V0_4_8_PRE_016_FINAL_CONFORMITY_VALIDATION_REPORT.md -->
+<!-- version: 2 -->
+
+# Validation finale de conformité `0.4.8-pre.016`
+
+## 1. Objet
+
+Ce rapport pilote la dernière prerelease de `0.4.8`. Il ne rouvre aucune fonctionnalité ni campagne réseau déjà qualifiée ; il vérifie que le workspace, le frontend, la documentation et les livrables de release sont cohérents avant la clôture de `0.4.8`.
+
+## 2. Base validée avant ouverture
+
+La base `0.4.8-pre.015` est clôturée avec :
+
+- `cargo fmt --all` réussi ;
+- `cargo check --workspace` réussi ;
+- `cargo clippy --all-targets` réussi sans warning ;
+- audit général, exports et workspace propres ;
+- `kb-pipeline` : 109 tests unitaires et trois tests d’API Metadata externes réussis ;
+- `kb-lib` : 706 tests unitaires et neuf tests d’intégration réussis ;
+- `kb-pipeline-demo-scenarios` : 105 tests unitaires, 1 test CLI et 1 test API externe réussis ;
+- réconciliation Metadata sans divergence fonctionnelle restante.
+
+## 3. Campagne finale à exécuter
+
+Depuis la racine du workspace :
+
+```bash
+cargo fmt --all
+cargo check --workspace
+cargo clippy --all-targets
+python3 scripts/audit_rust_workspace_rules.py
+cargo test --workspace
+```
+
+Le frontend de release ne doit pas être construit par une commande npm autonome. La validation TypeScript/Vite et l’assemblage desktop sont exécutés ensemble par Tauri :
+
+```bash
+cargo tauri build -c kb-app-demo-desktop/tauri.conf.json
+```
+
+Tauri déclenche lui-même le `beforeBuildCommand` configuré dans `kb-app-demo-desktop/tauri.conf.json`.
+
+## 4. Critères d’acceptation
+
+La campagne finale est qualifiée uniquement si :
+
+- aucun échec de compilation, Clippy ou audit n’est présent ;
+- tous les tests workspace réussissent ;
+- TypeScript et Vite construisent le frontend sans erreur ;
+- le build Tauri de release termine correctement ;
+- aucune nouvelle divergence de matrice, export, registre runtime ou documentation n’est découverte ;
+- aucune campagne Devnet n’est rejouée sans régression motivant ce rerun.
+
+## 5. Travaux documentaires après validation
+
+Après réception des résultats verts, la clôture doit encore :
+
+- mettre à jour le CHANGELOG général uniquement avec des versions fonctionnelles clôturées ;
+- passer le ROADMAP de `0.4.8` de « en clôture finale » à « version clôturée » ;
+- réconcilier une dernière fois README, USAGE, TODO et changelogs des crates concernées ;
+- préparer le prompt de la prochaine session/version ;
+- archiver le plan temporaire `0.4.8` sous `olddocs/archivekbot3/` après transfert de ses informations durables ;
+- retirer ou corriger les références actives vers le plan archivé ;
+- préparer la livraison finale de `0.4.8`.
+
+## 6. Résultats observés
+
+La campagne finale du 9 août 2026 est conforme :
+
+- `cargo fmt --all` réussi ;
+- `cargo check --workspace` réussi ;
+- `cargo clippy --all-targets` réussi sans warning ;
+- audit général Rust, exports et règles Khadhroony propre ;
+- `cargo test --workspace` réussi sur toutes les crates et cibles d’intégration ;
+- `cargo tauri build -c kb-app-demo-desktop/tauri.conf.json` réussi ;
+- le `beforeBuildCommand` Tauri a exécuté TypeScript et Vite sans erreur ;
+- Vite a produit le frontend dans le `dist` commun du workspace ;
+- Tauri a produit les bundles `.deb`, `.rpm` et `.AppImage` en version desktop `0.4.8`.
+
+## 7. Statut
+
+**Campagne finale de conformité validée.**

prompts/001.README.md

@@ -1,8 +1,8 @@
 <!-- file: prompts/001.README.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Prompts actifs
 
 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/`.
 
-- [`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.
+- [`029_v0_5_0_foundation_restructuring_plan.md`](029_v0_5_0_foundation_restructuring_plan.md) : cadrage de la fondation `0.5.x`, planification des restructurations configuration, wallet, store et scénarios.

prompts/029_v0_5_0_foundation_restructuring_plan.md

@@ -0,0 +1,234 @@
+<!-- file: prompts/029_v0_5_0_foundation_restructuring_plan.md -->
+<!-- version: 1 -->
+
+# Prompt de session — 0.5.0 cadrage de la fondation `0.5.x`
+
+## Mission
+
+Reprendre `khadhroony-bot3` après la clôture validée de `0.4.8` et préparer la série `0.5.x` consacrée à la fondation du workspace avant l’ouverture des grands programmes Anchor/DEX.
+
+`0.5.0` doit commencer par un audit et un plan complet. Il ne faut pas lancer immédiatement une restructuration de `kb-config`, `kb-wallet` ou `kb-store` sans avoir vérifié les frontières actuelles, les contrats publics, les schémas, les tests et les dépendances du workspace.
+
+La trajectoire cible est :
+
+- `0.5.1` : restructuration de `kb-config` et contrats de configuration ;
+- `0.5.2` : restructuration de `kb-wallet` ;
+- `0.5.3` : audit et normalisation de `kb-store` en préparation des matérialisations trading/routing ;
+- `0.5.4` : centralisation des scénarios dans `kb-pipeline-demo-scenarios` et audit des exécuteurs/validations manquants.
+
+La première prerelease de `0.5.0` doit produire le plan temporaire de la version et le découpage détaillé des prereleases avant tout changement structurel important.
+
+## Base validée à préserver
+
+La release `0.4.8` ferme :
+
+- Solana Program Metadata comme surface indépendante, avec neuf opérations confirmées sur Devnet ;
+- les cinq opérations Token-2022 Token Metadata confirmées sur Devnet ;
+- la matrice courante Metaplex Token Metadata à 15 `confirmed`, 5 `unavailable`, 0 `not_run` ;
+- les scénarios Metadata réutilisables dans `kb-pipeline-demo-scenarios` et leur intégration desktop ;
+- la réconciliation des matrices, exports, registres runtime, IDL, stockage générique et documentation Metadata ;
+- la validation finale du workspace par formatage, check, Clippy, audit et `cargo test --workspace` ;
+- le build desktop de release par `cargo tauri build`, produisant les bundles Linux prévus.
+
+Le registre ElGamal reste une exception connue : implémenté et validé synthétiquement, sans preuve réseau réelle disponible. Ne pas convertir cette exception en tâche implicite de `0.5.0` sans nouvelle possibilité de validation.
+
+## Lectures obligatoires avant toute proposition
+
+1. `README.md`, `ROADMAP.md`, `CHANGELOG.md`, `RULES.md` et ce prompt ;
+2. toutes les règles actives sous `docs/rules/`, en particulier :
+   - `RULES_GENERAL.md` ;
+   - `RULES_RUST.md` ;
+   - `RULES_SPECIFIC_KHADHROONY.md` ;
+   - `CRATE_DOCUMENTATION_RULES.md` ;
+   - `VERSION_DEVELOPMENT_LIFECYCLE.md` ;
+3. `README.md`, `USAGE.md`, `TODO.md` et `CHANGELOG.md` de chaque crate directement concernée ;
+4. les documents d’architecture et de stockage actifs ;
+5. les schémas, exemples de configuration, migrations SQL, matrices contractuelles et tests existants ;
+6. les prompts archivés `027` et `028` uniquement comme références de méthode et d’historique, jamais comme source prioritaire sur le code actuel.
+
+Avant de modifier un contrat public, vérifier son usage réel dans les onze crates et les tests d’API externe.
+
+## Règles de développement à conserver
+
+- Rust 2024 ;
+- aucune utilisation de `unsafe`, `unwrap`, `expect` ou `panic` dans le code de production ;
+- imports réservés aux traits nécessaires, chemins explicites pour les autres symboles ;
+- respect des en-têtes `file:` / `version:` et incrément des versions locales des fichiers modifiés ;
+- documentation Rust en anglais, documentation Markdown en français ;
+- aucune ligne vide interne artificielle dans les fonctions Rust et exactement une newline en fin de fichier ;
+- aucune logique métier nouvelle dans `kb-app-demo-desktop` lorsqu’elle peut résider dans une crate réutilisable ;
+- les commandes Tauri restent des adaptateurs minces et n’utilisent ni `?` ni unwrap ;
+- les archives sous `olddocs/` ne sont jamais réécrites hors opération d’archivage explicitement demandée.
+
+## Règle frontend/Tauri obligatoire
+
+Ne jamais lancer directement :
+
+```text
+npm run dev
+npm run build
+npm --prefix kb-app-demo-desktop run build
+```
+
+Les commandes npm manuelles sont limitées à l’installation explicite de dépendances nécessaires, notamment `npm i` et `npm i -D`.
+
+Le développement desktop est piloté par :
+
+```bash
+cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
+```
+
+Le build de release est piloté par :
+
+```bash
+cargo tauri build -c kb-app-demo-desktop/tauri.conf.json
+```
+
+Tauri déclenche lui-même les scripts frontend configurés. Le `dist` Vite et `frontendDist` Tauri doivent continuer à désigner le même répertoire de sortie du workspace.
+
+## Première prerelease obligatoire de `0.5.0`
+
+La première prerelease est exclusivement consacrée au plan et au brainstorming. Elle doit :
+
+- inventorier les responsabilités et couplages de `kb-config`, `kb-logging`, `kb-wallet`, `kb-store`, `kb-pipeline-demo-scenarios` et `kb-app-demo-desktop` ;
+- identifier les contrats publics et formats persistés qui ne peuvent pas être modifiés sans migration ;
+- comparer le code aux README/USAGE/TODO/changelogs et supprimer les hypothèses obsolètes du plan ;
+- établir les problèmes réels et les priorités ;
+- proposer un découpage de prereleases bornées pour atteindre les objectifs de `0.5.0` ;
+- préciser ce qui appartient réellement à `0.5.0` et ce qui doit rester réservé à `0.5.1` à `0.5.4` ;
+- définir les tests, audits, migrations et validations nécessaires avant code ;
+- créer un plan temporaire sous `docs/plans/`, à archiver lors de la dernière prerelease de `0.5.0`.
+
+La planification doit être validée avant toute restructuration importante.
+
+## Axe `0.5.1` — `kb-config`
+
+Le plan doit préparer une version dédiée qui :
+
+- restructure `kb-config` par responsabilités cohérentes ;
+- sépare au minimum le schéma de configuration générale du schéma de logging si l’audit confirme cette frontière ;
+- autorise d’autres schémas spécialisés uniquement lorsqu’ils réduisent réellement le couplage ;
+- audite les profils, valeurs par défaut, validations croisées et erreurs ;
+- audite la résolution des variables d’environnement et `.env` ;
+- introduit un camouflage systématique des secrets dans logs, diagnostics, UI, sérialisation et erreurs ;
+- interdit qu’un secret résolu soit renvoyé en clair par un payload de configuration ;
+- garde les exemples, schémas JSON, TS-RS et documentation alignés.
+
+## Axe `0.5.2` — `kb-wallet`
+
+Préparer :
+
+- l’audit des types de wallets et signers existants ;
+- la séparation identité / secret / déverrouillage / signature ;
+- les besoins multi-wallets et multi-profils ;
+- import/export, chiffrement, sauvegarde/restauration et verrouillage lorsque ces capacités sont retenues ;
+- des frontières strictes empêchant la fuite de secrets vers config, logs ou Tauri ;
+- des scénarios réutilisables lorsque des validations opérateur sont nécessaires.
+
+## Axe `0.5.3` — `kb-store`
+
+Préparer un audit de fond avant migration :
+
+- contrats DTO, entités, repositories, migrations, index et requêtes ;
+- timestamps on-chain et timestamps de persistance séparés explicitement ;
+- distinction entre slot, block time ou temps de transaction et temps d’insertion/mise à jour en base ;
+- provenance et idempotence ;
+- normalisation de la structure du store ;
+- champs et index nécessaires aux futures matérialisations trading/routing/multi-pools ;
+- interrogation efficace de la création de pools, actifs, liquidité, réserves, prix observés, swaps et séries temporelles ;
+- possibilité d’analyser plusieurs pools et routes sans couplage prématuré à Meteora, Raydium, Pump, Orca ou Jupiter.
+
+Aucune table trading spécifique ne doit être inventée avant d’avoir défini les faits stables produits par les matérialisateurs futurs.
+
+## Axe `0.5.4` — scénarios et complétude des exécuteurs
+
+Préparer un audit transversal qui :
+
+- détecte les scénarios encore assemblés directement dans `kb-app-demo-desktop` ;
+- déplace leur logique réutilisable vers `kb-pipeline-demo-scenarios` ;
+- laisse le desktop comme adaptateur UI/Tauri uniquement ;
+- compare les décodeurs aux exécuteurs disponibles ;
+- identifie les exécuteurs manquants réellement justifiés ;
+- compare les exécuteurs aux scénarios et validations réseau existants ;
+- identifie les capacités présentes dans le desktop sans scénario réutilisable ;
+- classe chaque manque comme à implémenter, decode-only, deprecated, unavailable, non applicable ou reporté.
+
+## Suite du ROADMAP à respecter
+
+Après `0.5.x` :
+
+- `0.6.x` : infrastructure Anchor générique et seulement les programmes SPL apportant une valeur directe aux DEX suivants ;
+- `0.7.x` : Meteora avec alternance decode/materialize puis executor/scénarios ;
+- `0.8.x` : Raydium selon la même discipline ;
+- `0.9.x` : Pump ;
+- `0.10.x` : Orca ;
+- `0.11.x` : Jupiter ;
+- `0.12.x` : autres routers/protocoles prioritaires ;
+- `0.13.x` : transports temps réel ;
+- `0.14.x` : workers et applications consommatrices ;
+- `0.15.x` : programmes SPL et Metaplex complémentaires reportés ;
+- `0.16.x+` : extensions futures et éventuel `kb-offchain-transport`.
+
+Ne pas réintroduire en `0.6.x` une couverture exhaustive des programmes SPL ou Metaplex qui a été explicitement reportée.
+
+## Discipline des scénarios et validations
+
+Pour toute nouvelle capacité exécutable :
+
+1. tests contractuels et synthétiques ;
+2. logique de scénario réutilisable dans `kb-pipeline-demo-scenarios` ;
+3. simulation RPC exacte ;
+4. soumission Devnet/Testnet lorsque sûre et disponible ;
+5. postconditions et matérialisation observables ;
+6. panneau desktop seulement comme adaptateur opérateur ;
+7. statut de qualification explicite et jamais promu depuis une preuve synthétique seule.
+
+Les scénarios déjà qualifiés ne doivent pas être rejoués automatiquement à chaque refactor si aucune frontière qu’ils couvrent n’a changé.
+
+## Documentation et deltas
+
+À chaque prerelease ou correctif :
+
+- mettre à jour uniquement les documents rendus faux ou incomplets ;
+- conserver les README/USAGE généralistes ;
+- utiliser les changelogs pour la chronologie ;
+- supprimer les TODO terminés ;
+- maintenir le plan temporaire de la version ;
+- livrer uniquement un ZIP delta avec `delta.md` ;
+- ne jamais livrer `Cargo.lock`, les lockfiles frontend, `node_modules`, `dist`, `target` ou les bindings générés sans nécessité explicite ;
+- ne jamais fournir de SHA/checksum dans la réponse de livraison ;
+- recommencer la numérotation `fix-001` à chaque nouvelle prerelease.
+
+## Dernière prerelease obligatoire
+
+La dernière prerelease de `0.5.0` devra :
+
+- exécuter les validations finales ;
+- corriger les écarts résiduels ;
+- finaliser README, ROADMAP, changelogs, TODO et guides concernés ;
+- transférer les décisions durables du plan vers les documents normatifs ;
+- archiver le plan et le prompt de session terminés sous `olddocs/archivekbot3/` ;
+- préparer le prompt de la session suivante ;
+- préparer la release finale sans introduire une nouvelle fonctionnalité structurelle majeure.
+
+## Contrôles de référence
+
+```bash
+cargo fmt --all
+cargo check --workspace
+cargo clippy --all-targets
+python3 scripts/audit_rust_workspace_rules.py
+cargo test --workspace
+```
+
+Lorsque le desktop doit être validé :
+
+```bash
+cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
+```
+
+Pour une validation de release desktop :
+
+```bash
+cargo tauri build -c kb-app-demo-desktop/tauri.conf.json
+```