194 lines
7.5 KiB
Markdown
194 lines
7.5 KiB
Markdown
<!-- file: ROADMAP.md -->
|
||
<!-- version: 25 -->
|
||
|
||
# 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 ;
|
||
- intégration pipeline et démonstrations complètes ;
|
||
- tests contractuels, unitaires et stateful ;
|
||
- limites réseau documentées ;
|
||
- 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.
|
||
|
||
## 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 :
|
||
|
||
```text
|
||
MAyhSmzXzV1pTf7LsNkrNwkWKTo4ougAJ1PPg47MD4e
|
||
```
|
||
|
||
Vérifier sa nature, son déploiement et son appartenance réelle à la famille Pump. Vérifier séparément si `pumpup_ai` appartient à cette famille ou constitue un protocole distinct.
|
||
|
||
## 0.10.x — Orca
|
||
|
||
1. Whirlpool ;
|
||
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.
|
||
|