khadhroony-bot3/ROADMAP.md

ROADMAP — khadhroony-bot3

Le roadmap décrit les objectifs fonctionnels par version mineure. Il ne contient ni prereleases, ni correctifs fix, ni journal détaillé des travaux terminés. Les détails opérationnels appartiennent aux TODO.md et CHANGELOG.md des crates.

0.4.6 — alignement fonctionnel et clôture de la migration principale

Version clôturée.

• 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.

0.4.7 — achèvement de Metaplex Token Metadata

Base acquise

• 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

• 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 synthétiques et les validations automatisées Devnet/Testnet dans kb-pipeline-demo-scenarios, en parallèle des scénarios UI conservés dans le desktop ;
• étendre le CLI uniquement lorsqu’une préparation de fixture dédiée le justifie ;
• valider le parcours réseau et PostgreSQL de bout en bout lorsque les fixtures sont disponibles.

Contraintes

• 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

• exécution simulation-first avec signers, coûts et confirmations exacts ;
• scénarios synthétiques déterministes et campagnes Devnet réelles dans kb-pipeline-demo-scenarios ;
• scénario Devnet pour chacune des 20 opérations courantes non dépréciées, avec simulation RPC réelle et, lorsque l'opération est réalisable, soumission confirmée et postcondition observée ;
• démonstrations UI Devnet conservées dans kb-app-demo-desktop et raccordées aux mêmes contrats réutilisables ;
• tests contractuels, unitaires, stateful et replay PostgreSQL idempotent ;
• statut réseau exact par opération, sans substitution d'une preuve synthétique à une preuve RPC ;
• opérations remplacées redirigées vers leur remplacement canonique final ;
• opérations obsolètes encore constructibles exposées comme exécutables dépréciées et soumises à une approbation explicite ;
• clôture repoussée jusqu'à l'achèvement des campagnes Devnet des opérations courantes.

0.4.8 — SPL Token Metadata et décision off-chain metadata

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

Configuration

• scinder kb-config en deux fichiers, ou trois si nécessaire ;
• alléger la configuration générale ;
• extraire les blocs dupliqués entre profils, notamment le logging ;
• conserver un schéma explicite et des exemples utilisateurs cohérents.

Scénarios de démonstration

• ajouter dans kb-pipeline-demo-scenarios des tests automatisés reproduisant en parallèle les scénarios Devnet/Testnet des panneaux desktop ;
• conserver les scénarios UI Devnet/Testnet dans kb-app-demo-desktop ;
• améliorer le CLI uniquement pour les préparations de fixtures et opérations explicitement justifiées ;
• compléter les démonstrations des surfaces 0.4.x et maintenir les adaptateurs Tauri minces.

Wallet

• compléter réellement kb-wallet ;
• ajouter import, export, multi-wallets et sélection active ;
• ajouter changement de mot de passe, chiffrement, déchiffrement et verrouillage ;
• ajouter sauvegarde, restauration, politiques de sécurité et intégration aux profils/signers.

0.6.x — Anchor, programmes SPL et Metaplex complémentaires

Anchor

• implémenter une infrastructure générique de décodage des conventions Anchor ;
• prendre en charge discriminants, comptes, événements et erreurs selon des contrats bornés ;
• intégrer les conventions Anchor aux décodeurs, exécuteurs et matérialisateurs.

IDL

• maintenir dès maintenant la classification et le nommage des IDL archivées ;
• ajouter les IDL de référence au fur et à mesure des protocoles étudiés ;
• ne jamais charger dynamiquement les IDL ni exécuter arbitrairement leur contenu en production.

Programmes

• ajouter le reste des programmes SPL ;
• ajouter le reste des programmes Metaplex ;
• documenter chaque surface avec matrices, tests et critères de validation.

0.7.x — Meteora

1. AMM Meteora : DLMM, DAMM v1, DAMM v2 et autres AMM non launchpad ;
2. launchpad DBC ;
3. vaults Meteora ;
4. autres programmes Meteora identifiés et vérifiés.

0.8.x — Raydium

1. AMM et swaps : v4, v3, v2, CPMM, CLMM et stable swap ;
2. LaunchLab ;
3. Raydium Lock ;
4. autres programmes Raydium identifiés et vérifiés.

0.9.x — Pump

1. Pump AMM ;
2. Pump.fun ;
3. Pump Fees ;
4. autres programmes Pump à identifier.

À auditer avant classement :

MAyhSmzXzV1pTf7LsNkrNwkWKTo4ougAJ1PPg47MD4e

Vérifier sa nature, son déploiement et son appartenance réelle à la famille Pump. Vérifier séparément si pumpup_ai appartient à cette famille ou constitue un protocole distinct.

0.10.x — Orca

1. Whirlpool ;
2. Orca v1 ;
3. Orca v2 ;
4. Wavebreak ;
5. autres programmes Orca identifiés et vérifiés.

0.11.x — Jupiter

• routers et agrégateurs ;
• DCA et ordres ;
• perpetuals et lockers ;
• autres programmes Jupiter identifiés et vérifiés.

0.12.x — OKX et autres routers

• routers et autres programmes OKX ;
• autres routers et agrégateurs hors Jupiter ;
• surfaces de matérialisation, sécurité et exécution associées.

0.13.x — transports temps réel

• extension WebSocket Helius dans kb-onchain-transport ;
• amélioration de LaserStream si pertinente ;
• Yellowstone gRPC ;
• autres transports streaming ;
• reprise, continuité, backpressure, reconnexion et métriques ;
• vérification et classement du listing historique des Program IDs sans modifier l’archive bot2.

0.14.x — application de trading et orchestration

• application de trading ;
• workers et services séparés ;
• orchestration et automatisation ;
• stratégies et exécution contrôlée ;
• sécurité opérationnelle ;
• séparation stricte entre UI, workers et services.

0.15.x+ — extensions futures

• nouveaux décodeurs, exécuteurs et matérialisateurs ;
• protocoles et transports supplémentaires ;
• opérations historiques et backfills avancés ;
• optimisations, observabilité et outils d’administration ;
• extensions futures validées par des contrats bornés.