v0.4.7-pre.016
This commit is contained in:
203
ROADMAP.md
203
ROADMAP.md
@@ -1,196 +1,113 @@
|
||||
<!-- file: ROADMAP.md -->
|
||||
<!-- version: 26 -->
|
||||
<!-- version: 27 -->
|
||||
|
||||
# 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.
|
||||
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.
|
||||
|
||||
## 0.4.6 — alignement fonctionnel et clôture de la migration principale
|
||||
|
||||
Version clôturée.
|
||||
Version clôturée : architecture en onze crates, alignement bot2 `0.4.6`, validations workspace et scénarios applicatifs. Le registre ElGamal reste implémenté et validé synthétiquement sans preuve réseau réelle.
|
||||
|
||||
- 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 — Metaplex Token Metadata
|
||||
|
||||
## 0.4.7 — achèvement de Metaplex Token Metadata
|
||||
Version en clôture documentaire.
|
||||
|
||||
### Base acquise
|
||||
### Périmètre réalisé
|
||||
|
||||
- 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.
|
||||
- décodeur d’instructions et de comptes, PDA, owners et variantes historiques ;
|
||||
- matérialisation metadata, administration, lifecycle et risques applicables ;
|
||||
- intents typés, builders, exécuteur, préflights, simulation exacte et postconditions ;
|
||||
- intégration généraliste dans `kb-pipeline` ;
|
||||
- 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.
|
||||
|
||||
### Objectifs
|
||||
### Qualification de validation
|
||||
|
||||
- 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.
|
||||
- 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 blocant de clôture ;
|
||||
- aucune preuve synthétique ne doit être présentée comme preuve RPC.
|
||||
|
||||
### Contraintes
|
||||
### Hors périmètre
|
||||
|
||||
- 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.
|
||||
- metadata incorporées Token-2022 et SPL Token Metadata ;
|
||||
- Metaplex Core, Bubblegum et autres programmes Metaplex ;
|
||||
- fetch HTTP/IPFS/Arweave des URI off-chain.
|
||||
|
||||
## 0.4.8 — SPL Token Metadata et décision off-chain metadata
|
||||
|
||||
### Première prerelease
|
||||
|
||||
La première prerelease doit produire un plan et un inventaire fermé avant tout développement fonctionnel. Elle doit prévoir dès le départ des scénarios Devnet réels dans `kb-app-demo-desktop`, en parallèle des tests synthétiques et des campagnes automatisées de `kb-pipeline-demo-scenarios`.
|
||||
|
||||
### 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.
|
||||
- séparer SPL Token Metadata, metadata Token-2022 et Metaplex Token Metadata ;
|
||||
- implémenter uniquement les couches decoder, materializer, executor, pipeline et démonstrations justifiées ;
|
||||
- décider si `kb-offchain-transport` doit être créée ;
|
||||
- si retenue, commencer par un module metadata borné HTTP/IPFS/Arweave.
|
||||
|
||||
### Contraintes du fetch off-chain
|
||||
### Contraintes 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 ;
|
||||
- timeout, taille, type MIME, 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
|
||||
## 0.5.x — configuration, wallet, stockage et démonstrations
|
||||
|
||||
- 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.
|
||||
- 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.
|
||||
|
||||
## 0.5.x — démonstrations, configuration et wallet
|
||||
## 0.6.x — Anchor générique, programmes SPL et Metaplex complémentaires
|
||||
|
||||
### 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.
|
||||
- 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.
|
||||
|
||||
## 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.
|
||||
DLMM, DAMM v1/v2, DBC, vaults et autres programmes vérifiés.
|
||||
|
||||
## 0.8.x — Raydium
|
||||
## 0.8.x — Pump
|
||||
|
||||
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.
|
||||
Pump AMM, Pump.fun, Pump Fees et autres surfaces vérifiées. Auditer `MAyhSmzXzV1pTf7LsNkrNwkWKTo4ougAJ1PPg47MD4e` et l’appartenance de `pumpup_ai`.
|
||||
|
||||
## 0.9.x — Pump
|
||||
## 0.9.x — Raydium
|
||||
|
||||
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.
|
||||
AMM v4/v3/v2, CPMM, CLMM, stable swap, LaunchLab, Lock et autres surfaces vérifiées.
|
||||
|
||||
## 0.10.x — Orca
|
||||
|
||||
1. Whirlpool ;
|
||||
2. Orca v1 ;
|
||||
3. Orca v2 ;
|
||||
4. Wavebreak ;
|
||||
5. autres programmes Orca identifiés et vérifiés.
|
||||
Whirlpool, Orca v1/v2, Wavebreak et autres surfaces vérifiées.
|
||||
|
||||
## 0.11.x — Jupiter
|
||||
|
||||
- routers et agrégateurs ;
|
||||
- DCA et ordres ;
|
||||
- perpetuals et lockers ;
|
||||
- autres programmes Jupiter identifiés et vérifiés.
|
||||
Routers, agrégateurs, DCA, ordres, perpetuals, lockers et autres surfaces vérifiées.
|
||||
|
||||
## 0.12.x — OKX et autres routers
|
||||
## 0.12.x — autres routers et protocoles
|
||||
|
||||
- routers et autres programmes OKX ;
|
||||
- autres routers et agrégateurs hors Jupiter ;
|
||||
- surfaces de matérialisation, sécurité et exécution associées.
|
||||
OKX et autres routers, puis surfaces complémentaires classées selon leur priorité réelle.
|
||||
|
||||
## 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.
|
||||
WebSocket Helius, LaserStream, Yellowstone gRPC, continuité, backpressure, reconnexion et métriques.
|
||||
|
||||
## 0.14.x — application de trading et orchestration
|
||||
## 0.14.x — workers et applications consommatrices
|
||||
|
||||
- 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.
|
||||
- W1 acquisition temps réel vers les raw ;
|
||||
- W2 décodage et matérialisation temps réel ;
|
||||
- rattrapage historique séparé ;
|
||||
- application de contrôle ;
|
||||
- application de trading et applications de visualisation.
|
||||
|
||||
## 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.
|
||||
|
||||
Nouveaux protocoles, transports, backfills, observabilité, administration et optimisations validées par des contrats bornés.
|
||||
|
||||
Reference in New Issue
Block a user