v0.4.7-pre.016

This commit is contained in:
2026-08-05 11:29:43 +02:00
parent 40d831f84d
commit 1d1f57ae78
42 changed files with 493 additions and 1203 deletions

View File

@@ -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 larchitecture 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 dinstructions 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 dinstructions 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 lexé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 lorsquune 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 lappartenance 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 larchive 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 dadministration ;
- extensions futures validées par des contrats bornés.
Nouveaux protocoles, transports, backfills, observabilité, administration et optimisations validées par des contrats bornés.