v0.4.8

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 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.
+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.
 
 ### 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` ;
-- 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.
+### Qualification réseau
 
-### Complétude Token-2022 Token Metadata
-
-- traiter `spl-token-metadata-interface` comme une interface sans Program ID autonome imposé ;
-- auditer puis compléter les cinq opérations `Initialize`, `UpdateField`, `RemoveKey`, `UpdateAuthority` et `Emit` dans les modules Token-2022 existants ;
-- ne pas créer de second décodeur de programme pour cette interface ;
-- maintenir une campagne Devnet et un parcours desktop distincts de `ProgM6…`.
+- Solana Program Metadata : 9 opérations `confirmed` sur Devnet ;
+- Token-2022 Token Metadata : 5 opérations `confirmed` sur Devnet ;
+- Metaplex Token Metadata : 15 opérations `confirmed`, 5 `unavailable`, 0 `not_run` sur les 20 opérations courantes ;
+- desktop Metadata : campagnes des trois domaines validées, avec résultats structurés et journal pleine largeur.
 
 ### 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 ;
-- 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.
+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.
 
-## 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 ;
-- classification et conservation des IDL comme références statiques ;
-- autres programmes SPL et Metaplex, chacun avec matrices et scénarios Devnet réels représentatifs.
+- auditer l’état réel de `kb-config`, `kb-logging`, `kb-wallet`, `kb-store`, `kb-pipeline-demo-scenarios` et `kb-app-demo-desktop` ;
+- inventorier les contrats publics, schémas, migrations, dépendances et couplages avant refactor ;
+- 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.