v0.4.6

ROADMAP.md

@@ -1,5 +1,5 @@
 <!-- file: ROADMAP.md -->
-<!-- version: 22 -->
+<!-- version: 23 -->
 
 # ROADMAP — khadhroony-bot3
 
@@ -7,60 +7,67 @@ Le roadmap décrit les objectifs fonctionnels par version mineure. Il ne contien
 
 ## 0.4.6 — alignement fonctionnel et clôture de la migration principale
 
-### Objectifs
+Version clôturée.
 
-- formaliser l’équivalence largement atteinte avec khadhroony-bot2 `0.4.6` ;
-- documenter précisément les écarts résiduels ;
-- valider les renommages, consolidations et nouvelles frontières de crates ;
-- fermer la migration structurelle principale ;
-- décider du réalignement officiel du versionnement et du premier numéro fonctionnel publié après la transition `0.1.0-mig-from-kbot2`.
+- alignement fonctionnel sur `khadhroony-bot2 0.4.6` ;
+- consolidation de l’architecture en onze crates ;
+- validation des matrices, registres, bindings TS-RS, tests workspace et scénarios applicatifs ;
+- conservation du registre ElGamal comme exception documentée sans validation réseau réelle ;
+- report des améliorations structurelles de configuration, logging et stockage à `0.5.x`.
 
-### Lots
+## 0.4.7 — achèvement de Metaplex Token Metadata
 
-- refonte de la documentation générale et des règles ;
-- reconstruction des changelogs et du roadmap ;
-- documentation complète des 11 crates ;
-- reconstruction des prompts bot3 ;
-- audit ciblé `docs/V0_4_6_ALIGNMENT_AUDIT.md` ;
-- traitement ou documentation explicite des exceptions restantes.
+### Base acquise
 
-### Critères de sortie
-
-- chaque crate possède `README.md`, `TODO.md`, `USAGE.md` et `CHANGELOG.md` ;
-- les versions, noms de crates et binaires sont cohérents ;
-- les tests et validations déjà réalisés sont synthétisés sans nouvel audit complet des protocoles ;
-- le statut de `kb-wallet`, `kb-config`, `kb-pipeline-demo-scenarios`, ElGamal et des transports est explicite ;
-- l’audit conclut `READY_FOR_0_4_6` ou `READY_WITH_DOCUMENTED_EXCEPTIONS` ;
-- le changelog général n’ajoute l’entrée de réalignement qu’au dernier prerelease ou correctif précédant le commit de la version fonctionnelle retenue.
-
-## 0.4.7 — Metaplex Token Metadata complet et clôture de 0.4.x
-
-### Positionnement de version
-
-- le premier numéro fonctionnel après la migration pourra être `0.4.6+` ou une étape préparatoire de la famille `0.4.7`, selon la conclusion de l’audit d’alignement ;
-- l’entrée générale correspondante ne sera ajoutée au changelog qu’au moment de finaliser cette version ;
-- la version finale `0.4.7` doit inclure la surface Metaplex Token Metadata complète, et non le seul décodeur déjà migré.
+- décodeur d’instructions Metaplex Token Metadata ;
+- décodeur des comptes et validation des PDA/owners ;
+- matrice contractuelle bornée ;
+- matérialisation metadata déjà substantielle ;
+- coexistence explicite avec les metadata incorporées de Token-2022.
 
 ### Objectifs
 
-- terminer Metaplex Token Metadata commencé dans bot2 et dont le décodeur a déjà été migré dans bot3 ;
-- vérifier et compléter décodeurs de comptes et instructions ;
-- ajouter les matérialisateurs, exécuteurs, préflights et validations nécessaires ;
-- finaliser les éléments résiduels du noyau historique ;
-- préparer les démonstrations complètes de la série `0.5.x`.
+- auditer la matérialisation migrée et compléter uniquement les projections manquantes ;
+- implémenter les intents typés, builders, exécuteur, préflights et postconditions ;
+- intégrer l’exécution et les validations dans `kb-pipeline` ;
+- ajouter les scénarios réutilisables, le CLI et les panneaux desktop ;
+- valider le parcours réseau et PostgreSQL de bout en bout lorsque les fixtures sont disponibles.
 
 ### Contraintes
 
-- ne pas confondre Metaplex Token Metadata avec les metadata incorporées de Token-2022 ou Metaplex Core ;
-- utiliser les IDL archivées comme références de conception, jamais comme moteur dynamique de production ;
-- conserver les matrices exécutables sous `test-fixtures/contract-matrices/`.
+- ne pas confondre Metaplex Token Metadata, metadata Token-2022, SPL Token Metadata ou Metaplex Core ;
+- utiliser les IDL archivées comme références, jamais comme moteur dynamique de production ;
+- conserver le fetch HTTP/IPFS/Arweave hors périmètre de `0.4.7`.
 
 ### Critères de sortie
 
-- couverture fonctionnelle bornée et documentée ;
-- tests contractuels et unitaires complets ;
-- limites et validations réseau explicites ;
-- aucune surface partiellement annoncée comme terminée.
+- exécution simulation-first avec signers, coûts et confirmations exacts ;
+- intégration pipeline et démonstrations complètes ;
+- tests contractuels, unitaires et stateful ;
+- limites réseau et opérations historiques decode-only documentées.
+
+## 0.4.8 — SPL Token Metadata et décision off-chain metadata
+
+### Objectifs
+
+- auditer `spl-token-metadata-interface` comme surface distincte ;
+- séparer explicitement SPL Token Metadata, metadata Token-2022 et Metaplex Token Metadata ;
+- implémenter les couches decoder, materializer, executor, pipeline et démonstrations réellement justifiées ;
+- décider si une nouvelle crate `kb-offchain-transport` doit être créée ;
+- si elle est retenue, commencer par un module metadata borné pour HTTP, IPFS et Arweave.
+
+### Contraintes du fetch off-chain
+
+- le contenu externe ne modifie jamais le statut canonique du replay on-chain ;
+- timeout, taille, content type, redirections, cache, hash et provenance sont bornés ;
+- protection SSRF et interdiction des réseaux locaux ;
+- aucune confiance implicite dans les JSON distants.
+
+### Critères de sortie
+
+- contrats SPL Token Metadata vérifiés et documentés ;
+- décision architecturale explicite sur `kb-offchain-transport` ;
+- absence de confusion ou fusion silencieuse entre sources metadata.
 
 ## 0.5.x — démonstrations, configuration et wallet