v0.1.0-pre.068
This commit is contained in:
268
CHANGELOG.md
268
CHANGELOG.md
@@ -1,146 +1,206 @@
|
|||||||
<!-- file: CHANGELOG.md -->
|
<!-- file: CHANGELOG.md -->
|
||||||
<!-- version: 7 -->
|
<!-- version: 10 -->
|
||||||
|
|
||||||
# CHANGELOG
|
# CHANGELOG — khadhroony-bot3
|
||||||
|
|
||||||
## 0.1.0-pre.062
|
Ce changelog décrit les évolutions fonctionnelles globales du projet. Il ne recense pas les prereleases, les correctifs `fix` ni le détail de chaque delta. Ces informations appartiennent aux changelogs des crates concernées.
|
||||||
|
|
||||||
- clôture la première campagne Devnet complète du desktop après migration Bot3 ;
|
## 0.1.0-mig-from-kbot2 — transition architecturale vers khadhroony-bot3
|
||||||
- valide Solana Core System Transfer, SPL Memo v4, ATA classique, ATA Token-2022 et SPL Token classique ;
|
|
||||||
- valide les huit scénarios publics Token-2022 : `MintToChecked`, `TransferChecked`, `ApproveChecked`, `Revoke`, `BurnChecked`, `FreezeAccount`, `ThawAccount` et `CloseAccount` ;
|
|
||||||
- confirme pour chaque scénario applicatif l’insertion canonique, l’extraction Core, le replay de décodage, la matérialisation et l’idempotence ;
|
|
||||||
- ajoute le générateur idempotent `prepare-token-2022-fixture` dans le binaire distinct `kb-pipeline-demo-scenarios-cli` ;
|
|
||||||
- corrige le chargement des quatre montants bruts Token-2022 depuis `fixture.env` ;
|
|
||||||
- conserve le registre ElGamal comme implémenté mais non validé sur Devnet, faute de fixture de contexte de preuve et de raccordement fonctionnel du panneau desktop ;
|
|
||||||
- ajoute `docs/PRE_062_DEVNET_VALIDATION_REPORT.md` comme preuve de clôture bornée avant la refonte documentaire générale.
|
|
||||||
|
|
||||||
## 0.1.0-pre.054
|
Cette entrée de transition regroupe la migration structurelle et fonctionnelle commencée depuis `khadhroony-bot2`. Elle identifie la campagne `0.1.0-pre.*` de bot3 sans constituer une version fonctionnelle équivalente à bot2 `0.1.0` ni un alignement officiel sur `0.4.6`.
|
||||||
|
|
||||||
- stabilise le desktop après le portage complet des fenêtres Bot2 ;
|
### Architecture
|
||||||
- charge `.env` avant la configuration et fournit `.env.example` pour Helius ;
|
|
||||||
- corrige l'inventaire Metaplex Token Metadata ;
|
|
||||||
- normalise les exports TS-RS Token-2022 sous `kb_lib` ;
|
|
||||||
- retire les routes de logs héritées de crates supprimées ;
|
|
||||||
- restaure les tables SQL pleine largeur et les afficheurs JSON/logs bornés ;
|
|
||||||
- initialise le schéma PostgreSQL dans le splash et ferme la session WS à la fermeture globale.
|
|
||||||
## 0.1.0-pre.031
|
|
||||||
|
|
||||||
## 0.1.0-pre.037
|
- consolidation de plus de 250 crates historiques en 11 crates de workspace ;
|
||||||
|
- regroupement des modèles, décodeurs, exécuteurs et matérialisateurs dans `kb-lib` ;
|
||||||
|
- consolidation du stockage dans `kb-store` ;
|
||||||
|
- renommage de `kb-rpc` en `kb-onchain-transport` ;
|
||||||
|
- migration du pipeline dans `kb-pipeline` ;
|
||||||
|
- extraction des scénarios de démonstration dans `kb-pipeline-demo-scenarios` ;
|
||||||
|
- maintien de `kb-app-demo-desktop` comme crate mixte bibliothèque et binaire ;
|
||||||
|
- migration et renommage du portefeuille en `kb-wallet`.
|
||||||
|
|
||||||
- Migration de la préparation stateful des opérations Solana natives dans `kb-pipeline`.
|
### Normes
|
||||||
|
|
||||||
- Migration complète de l’orchestration HTTP `backfill` dans `kb-pipeline`.
|
- adoption de Rust 2024 et des règles strictes du workspace bot3 ;
|
||||||
- Conservation des sources explicites et historiques par adresse, des directions `before`/`after`, de la pagination bornée, des retries et de la reprise déterministe.
|
- interdiction des paniques implicites et des erreurs opaques dans le code de production ;
|
||||||
- Adaptation aux façades `kb-onchain-transport`, `kb-store` et `kb-lib`.
|
- normalisation des exports publics, des en-têtes de fichiers, du tracing et des conventions de modules ;
|
||||||
- Conservation des 14 tests bot2, dont les deux tests async d’annulation coopérative.
|
- ajout d’audits automatiques des règles Rust, des exports et des contraintes Khadhroony ;
|
||||||
|
- adoption d’un contrat documentaire par crate fondé sur `README.md`, `TODO.md`, `USAGE.md` et `CHANGELOG.md`.
|
||||||
|
|
||||||
|
### Migration fonctionnelle
|
||||||
|
|
||||||
## 0.1.0-pre.030
|
- migration du stockage canonique, des observations, de l’extraction Core et du replay ;
|
||||||
|
- migration des transports HTTP, WebSocket, acquisition canonique, soumission et confirmation ;
|
||||||
|
- migration des décodeurs, matérialisateurs et exécuteurs Solana Core et SPL jusqu’à un périmètre proche de bot2 `0.4.6` ;
|
||||||
|
- migration du décodeur Metaplex Token Metadata commencé pendant bot2 `0.4.7` ;
|
||||||
|
- migration des préflights et orchestrations stateful Token-2022 ;
|
||||||
|
- conservation de Memo v1 et v3 en décodage uniquement et de Memo v4 comme génération exécutable.
|
||||||
|
|
||||||
- Migration du replay contextuel de décodage dans `kb-pipeline`.
|
### Validation
|
||||||
- Conservation de la sélection bornée, du dispatch déterministe, du ledger, du force replay et de la matérialisation optionnelle.
|
|
||||||
- Adaptation aux façades consolidées `kb-lib` et `kb-store`.
|
|
||||||
- Conservation des 19 tests de l’ancienne implémentation bot2.
|
|
||||||
|
|
||||||
|
- validation du workspace, des audits et des tests ciblés pendant les prereleases `0.1.0-pre.*` ;
|
||||||
|
- validation Devnet de Solana Core System Transfer, Memo v4, ATA classique, ATA Token-2022, SPL Token classique et huit opérations Token-2022 ;
|
||||||
|
- validation des parcours de simulation, confirmation opérateur, envoi, insertion canonique, extraction Core, replay, matérialisation et idempotence pour les scénarios couverts ;
|
||||||
|
- registre ElGamal non déclaré validé, faute de fixture de preuve, de raccordement desktop fonctionnel et de confirmation de déploiement réseau.
|
||||||
|
|
||||||
## 0.1.0-pre.029
|
# Historique fonctionnel de khadhroony-bot2
|
||||||
|
|
||||||
- Migration initiale de `kb-pipeline` : primitives de planification et extraction canonique Solana vers les tables core.
|
Les sections dont le numéro porte le suffixe `-kbot2` décrivent exclusivement les versions et travaux réalisés dans `khadhroony-bot2`. Elles constituent l’historique fonctionnel du projet d’origine et ne représentent pas des versions publiées de `khadhroony-bot3`.
|
||||||
- Adaptation aux façades `kb-lib`, `kb-store` et `kb-onchain-transport`.
|
|
||||||
- Normalisation du target de tracing `kb-pipeline` et ajout d’un test de configuration.
|
|
||||||
|
|
||||||
|
`khadhroony-bot3` résulte de la migration et de la consolidation de cette base historique dans une nouvelle architecture. Son futur alignement de version sera décidé après la clôture de l’audit `0.4.6`.
|
||||||
|
|
||||||
## 0.1.0-pre.024
|
La future version fonctionnelle `0.4.7` de `khadhroony-bot3` devra réunir :
|
||||||
|
|
||||||
- Première tranche fonctionnelle de `kb-onchain-transport`.
|
- la clôture des écarts résiduels de migration ;
|
||||||
- Migration des contrats JSON-RPC, des rôles d’endpoints, des clients et pools HTTP, des validateurs et des méthodes HTTP Solana standard.
|
- les capacités historiques de bot2 nécessaires à l’alignement ;
|
||||||
- Migration des adaptateurs RPC d’exécution communs vers les types consolidés de `kb-lib`.
|
- les travaux Metaplex Token Metadata déjà réalisés puis migrés ;
|
||||||
- WebSocket, acquisition canonique de transactions et soumission/confirmation réseau restent planifiés pour les tranches suivantes.
|
- l’achèvement des éléments de l’objectif `0.4.7-kbot2` restés incomplets, notamment l’exécuteur, l’intégration au pipeline, les démonstrations et les validations finales.
|
||||||
|
|
||||||
## 0.1.0-pre.023
|
Les entrées `0.0.1-kbot2` à `0.4.6-kbot2` décrivent des versions fonctionnelles clôturées de bot2. L’entrée `0.4.7-kbot2` décrit une version interrompue en cours de développement par la migration vers bot3.
|
||||||
|
|
||||||
- Renommage structurel de `kb-rpc` en `kb-onchain-transport`.
|
## 0.4.7-kbot2 — Metaplex Token Metadata interrompu par la migration bot3
|
||||||
- Renommage de l’identifiant Rust en `kb_onchain_transport`.
|
|
||||||
- Mise à jour du workspace, des dépendances de `kb-pipeline` et `kb-app-demo`, du lockfile, des routes de logs et des documents actifs.
|
|
||||||
- Réservation de `kb-offchain-transport` pour une éventuelle future acquisition HTTP/IPFS/Arweave hors chaîne.
|
|
||||||
- Aucun portage fonctionnel RPC dans cette tranche.
|
|
||||||
|
|
||||||
## 0.1.0-pre.022
|
Cette section décrit l’objectif `0.4.7` commencé dans `khadhroony-bot2` après la clôture de `0.4.6-kbot2`. Cet objectif a été interrompu avant sa finalisation afin de réaliser la migration architecturale vers `khadhroony-bot3`.
|
||||||
|
|
||||||
- Migration de `kb_execution_solana` dans `kb-lib::executor::solana::transaction`.
|
- implémentation du décodeur Metaplex Token Metadata dans bot2 ;
|
||||||
- Conservation de l’assemblage legacy et durable nonce, de la preuve de simulation et de la signature contrôlée.
|
- implémentation de la matérialisation associée dans bot2 ;
|
||||||
- Validation utilisateur de 625 tests `kb-lib`, Clippy et du workspace.
|
- interruption volontaire du développement de cette surface afin de réaliser la migration architecturale vers `khadhroony-bot3` ;
|
||||||
|
- reprise du décodeur pendant la migration vers bot3 ;
|
||||||
|
- exécuteur, intégration complète au pipeline, scénarios de démonstration et validations finales reportés vers l’objectif fonctionnel `0.4.7` de `khadhroony-bot3`.
|
||||||
|
|
||||||
## 0.1.0-pre.021
|
## 0.4.6-kbot2 — Token-2022, extensions et registre ElGamal
|
||||||
|
|
||||||
- Migration complète de l’exécuteur SPL Token classique.
|
- couverture bornée de Token-2022, de ses extensions et des interfaces externes associées ;
|
||||||
- Adaptation aux modèles et à la safety consolidés de `kb-lib`.
|
- préflight, orchestration de preuves, corrélation stateful, validation et matérialisation ;
|
||||||
- Validation utilisateur de 613 tests `kb-lib`, 41 tests `kb-config`, 17 tests `kb-logging`, Clippy et du workspace.
|
- intégration du registre ElGamal avec validation synthétique et garde-fous fail-closed ;
|
||||||
|
- absence de validation réelle du registre ElGamal sur Devnet ou Mainnet.
|
||||||
|
|
||||||
## 0.1.0-pre.016
|
## 0.4.5-kbot2 — SPL Associated Token Account
|
||||||
|
|
||||||
- Portage fonctionnel complet de `kb_execution_safety` dans `kb-lib`.
|
- décodage et exécution des créations ATA classiques et Token-2022 ;
|
||||||
- Exposition des décisions, violations, évaluations et du checker sous les noms `ExSafety*`.
|
- vérification des PDA, de l’ordre des seeds et des contrats officiels ;
|
||||||
- Portage fonctionnel de l’exécuteur SPL Memo et de ses contrats `ExSplMemo*`.
|
- intégration aux matérialisateurs et au pipeline de validation.
|
||||||
- Conservation des générations v1/v3 en decode-only et de l’exécution v4 par le builder officiel.
|
|
||||||
- Conservation des limites de payload, de signers, des politiques de simulation et des validations post-exécution.
|
|
||||||
- Réduction de l’inventaire réservé de 103 à 102 exécuteurs.
|
|
||||||
|
|
||||||
## 0.1.0-pre.015
|
## 0.4.4-kbot2 — SPL Token classique
|
||||||
|
|
||||||
- Portage fonctionnel complet de l’exécuteur Solana Core dans `kb-lib`.
|
- couverture des instructions SPL Token classiques, y compris opérations checked, multisig, native token et batch borné ;
|
||||||
- Conservation des 109 opérations validées dans bot2 sur 18 surfaces natives.
|
- matérialisation des comptes, autorités, délégations, risques et changements administratifs ;
|
||||||
- Préfixage bot3 des contrats publics avec `ExSolanaCore*` et `EX_SOLANA_CORE_*`.
|
- exécution typée, préflight, simulation-first et validation des signers.
|
||||||
- Conservation des deux contrats `ExApiTypedInstructionExecutor` et `ExApiInstructionExecutor`.
|
|
||||||
- Regroupement canonique des réexports : bloc `pub use`, puis bloc `pub(crate) use`.
|
|
||||||
- Réduction de l’inventaire réservé de 104 à 103 exécuteurs.
|
|
||||||
|
|
||||||
## 0.1.0-pre.014
|
## 0.4.3-kbot2 — SPL Memo v1, v3 et v4
|
||||||
|
|
||||||
- Vérification de la parité exacte des contrats publics `ExApi*` avec `kb_execution_api` de bot2.
|
- décodage borné des trois générations ;
|
||||||
- Extension du test aval au contrat d’exécution typé et au plan préparé.
|
- matérialisation des annotations transactionnelles ;
|
||||||
- Remplacement des 104 marqueurs temporaires par des squelettes `Ex*Executor`.
|
- exécution limitée à Memo v4 ;
|
||||||
- Rattachement des squelettes à leurs Program IDs enregistrés, sans dépendance vers les décodeurs.
|
- validation Devnet de Memo v4.
|
||||||
- Garantie d’inactivité par support `Maybe` et plans réservés à zéro instruction.
|
|
||||||
- Extension de l’audit et ajout d’un test central sur les 104 frontières.
|
|
||||||
|
|
||||||
## 0.1.0-pre.013
|
## 0.4.2-kbot2 — exécution native et RPC Solana standard
|
||||||
|
|
||||||
- Remplacement des 14 marqueurs temporaires de matérialisation par des squelettes `Mt*Materializer`.
|
- infrastructure d’exécution Solana Core ;
|
||||||
- Conservation du contrat historique `MtMaterializer` et ajout du contrat bot3 `MtApiEventMaterializer`.
|
- couverture des programmes natifs, loaders, précompiles et opérations supportées ;
|
||||||
- Réexports publics exclusivement depuis la façade `kb_lib`.
|
- simulation, soumission, confirmation et politiques de sécurité ;
|
||||||
- Alignement de l’audit des réexports sur l’ordre naturel produit par `rustfmt`.
|
- matrice d’exécution native et contrats de transaction legacy ou durable nonce.
|
||||||
|
|
||||||
## 0.1.0-pre.001
|
## 0.4.1-kbot2 — programmes Solana natifs
|
||||||
|
|
||||||
- Renommage de `kb_wallet` en `kb-wallet`.
|
- décodage des programmes natifs, loaders, Compute Budget, Address Lookup Table, Stake, Vote et précompiles ;
|
||||||
- Restauration de `kb-core/src/error.rs` et `kb-core/src/module.rs`.
|
- matérialisations lifecycle, administration, compliance et staking ;
|
||||||
- Réduction de `kb-core/src/lib.rs` à la déclaration des modules et aux réexports documentés.
|
- extraction et replay contextualisés.
|
||||||
|
|
||||||
## 0.1.0-pre.000
|
## 0.4.0-kbot2 — infrastructure de décodage et matérialisation
|
||||||
|
|
||||||
- Création du workspace consolidé `khadhroony-bot3`.
|
- contrats communs de décodeurs, support, compatibilité et replay ;
|
||||||
- Ajout de `kb-lib` pour les décodeurs, exécuteurs et matérialisateurs.
|
- ledger de traitement et matérialisation optionnelle ;
|
||||||
- Fusion architecturale prévue des stores dans `kb-store`.
|
- matrices contractuelles exécutables et tests de couverture.
|
||||||
- Conservation du workspace précédent comme référence de migration non compilée.
|
|
||||||
|
|
||||||
## 0.1.0-pre.002
|
## 0.3.4-kbot2 — extraction Core et clôture de la fondation transactionnelle
|
||||||
|
|
||||||
- Portage des modèles partagés de `kb_model` dans `kb-lib::model`.
|
- extraction des transactions canoniques vers les tables Core ;
|
||||||
- Portage des contrats complets de `kb_decoder_api` dans `kb-lib::decoder::api`.
|
- replay déterministe et traitement idempotent ;
|
||||||
- Portage des contrats complets de `kb_materializer_api` dans `kb-lib::materializer::api`.
|
- ledger de progression et reprise bornée.
|
||||||
- Portage des contrats complets de `kb_execution_api` dans `kb-lib::executor::api`.
|
|
||||||
- Ajout du contrat neutre `MdCoreInstructionReplayInput` dans `kb-lib` pour éviter une dépendance cyclique avec `kb-store`.
|
|
||||||
- `kb-lib/src/lib.rs` reste une façade de modules et de réexports.
|
|
||||||
|
|
||||||
## 0.1.0-pre.010
|
## 0.3.3-kbot2 — backfill HTTP
|
||||||
|
|
||||||
- Portage des matérialisateurs natifs lifecycle, administration, compliance et staking.
|
- acquisition historique gratuite par adresse et signatures ;
|
||||||
- Conservation de leurs 50 tests historiques et ajout du premier test aval de matérialisation.
|
- pagination, retries, annulation coopérative et reprise déterministe ;
|
||||||
|
- démonstration applicative du backfill.
|
||||||
|
|
||||||
## 0.1.0-pre.033
|
## 0.3.2-kbot2 — contrat canonique et adaptateur HTTP
|
||||||
|
|
||||||
- Migre les lectures stateful Token-2022 et ElGamal Registry dans `kb-pipeline`.
|
- définition d’une transaction Solana canonique indépendante du fournisseur ;
|
||||||
- Migre le préflight Token-2022 borné et ses validations croisées.
|
- conversions explicites depuis les réponses RPC ;
|
||||||
- Conserve les 16 tests bot2 associés sans réduction fonctionnelle.
|
- conservation sans perte des données nécessaires au replay.
|
||||||
- Normalise les noms de fichiers, modules et symboles internes sur `token2022`.
|
|
||||||
|
## 0.3.1-kbot2 — transaction canonique et observations
|
||||||
|
|
||||||
|
- séparation entre payload canonique et observations d’acquisition ;
|
||||||
|
- migration du schéma PostgreSQL vers les tables raw, observations et Core actives ;
|
||||||
|
- suppression de la duplication durable des payloads complets.
|
||||||
|
|
||||||
|
## 0.3.0-kbot2 — cadrage des sources temps réel
|
||||||
|
|
||||||
|
- étude d’un nœud Agave local ;
|
||||||
|
- abandon temporaire comme source légère en raison du coût matériel ;
|
||||||
|
- réorientation vers des transports interchangeables.
|
||||||
|
|
||||||
|
## 0.2.5-kbot2 — diagnostics PostgreSQL
|
||||||
|
|
||||||
|
- fenêtres de diagnostic du backend, du schéma et des tables raw/Core ;
|
||||||
|
- initialisation contrôlée du schéma au démarrage ;
|
||||||
|
- diagnostics strictement read-only.
|
||||||
|
|
||||||
|
## 0.2.4-kbot2 — stockage Core Solana
|
||||||
|
|
||||||
|
- tables Core normalisées ;
|
||||||
|
- construction des entrées de replay instruction-level ;
|
||||||
|
- migrations et initialisation idempotentes.
|
||||||
|
|
||||||
|
## 0.2.3-kbot2 — stockage brut Solana
|
||||||
|
|
||||||
|
- stockage idempotent des transactions et notifications brutes ;
|
||||||
|
- index minimaux et cycle de vie initial des données.
|
||||||
|
|
||||||
|
## 0.2.2-kbot2 — infrastructure PostgreSQL
|
||||||
|
|
||||||
|
- connexion, migrations, healthcheck et conventions de schéma ;
|
||||||
|
- tests PostgreSQL réels optionnels.
|
||||||
|
|
||||||
|
## 0.2.1-kbot2 — contrats de stockage
|
||||||
|
|
||||||
|
- DTO, entités et repositories du stockage ;
|
||||||
|
- contrats de replay instruction-level.
|
||||||
|
|
||||||
|
## 0.2.0-kbot2 — conventions SQL et base de données
|
||||||
|
|
||||||
|
- séparation des contrats de stockage et de l’implémentation PostgreSQL ;
|
||||||
|
- règles de nommage, migrations et erreurs structurées.
|
||||||
|
|
||||||
|
## 0.1.3-kbot2 — transports Solana initiaux
|
||||||
|
|
||||||
|
- clients HTTP et WebSocket Solana standard ;
|
||||||
|
- rôles d’endpoints, pools et configuration des sources.
|
||||||
|
|
||||||
|
## 0.1.2-kbot2 — intégration configuration, logging et desktop
|
||||||
|
|
||||||
|
- liaison de la configuration typée et du logging à l’application Tauri ;
|
||||||
|
- première démonstration intégrée.
|
||||||
|
|
||||||
|
## 0.1.1-kbot2 — configuration typée
|
||||||
|
|
||||||
|
- profils validés, schéma JSON et chargement structuré ;
|
||||||
|
- gestion explicite des erreurs de configuration.
|
||||||
|
|
||||||
|
## 0.1.0-kbot2 — logging structuré
|
||||||
|
|
||||||
|
- infrastructure de logging et tracing ;
|
||||||
|
- configuration des targets et sorties.
|
||||||
|
|
||||||
|
## 0.0.2-kbot2 — squelette stabilisé
|
||||||
|
|
||||||
|
- conventions initiales du workspace et premières crates ;
|
||||||
|
- validation du build de base.
|
||||||
|
|
||||||
|
## 0.0.1-kbot2 — création du projet
|
||||||
|
|
||||||
|
- création du workspace initial khadhroony-bot2.
|
||||||
|
|||||||
510
ROADMAP.md
510
ROADMAP.md
@@ -1,362 +1,182 @@
|
|||||||
<!-- file: ROADMAP.md -->
|
<!-- file: ROADMAP.md -->
|
||||||
<!-- version: 20 -->
|
<!-- version: 22 -->
|
||||||
|
|
||||||
# ROADMAP — khadhroony-bot3
|
# ROADMAP — khadhroony-bot3
|
||||||
|
|
||||||
## Séquence fonctionnelle après clôture de la migration
|
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.
|
||||||
|
|
||||||
Cette séquence reprend la logique du roadmap historique tout en l’adaptant aux frontières Bot3. Elle prévaut sur les formulations anciennes encore présentes plus bas.
|
|
||||||
|
|
||||||
### A. Clôture desktop et guide opérateur
|
|
||||||
|
|
||||||
- [ ] Terminer l’audit HTML, JSON viewers, textareas, tables responsives et contrôles Copier/Effacer.
|
|
||||||
- [x] Créer le guide Devnet avant la campagne de tests, puis le corriger pendant chaque validation réelle.
|
|
||||||
- [x] Valider sur Devnet Solana Core, Memo v4, SPL Token classique, ATA classique, ATA Token-2022 et les huit opérations publiques Token-2022.
|
|
||||||
- [ ] Valider le registre ElGamal après ajout d’une fixture de contexte `PubkeyValidity` et raccordement fonctionnel du panneau desktop ; report explicite de `pre.062`.
|
|
||||||
- [x] Vérifier simulation, envoi, confirmation, replay post-exécution et matérialisation depuis les fenêtres desktop pour les scénarios exécutables de `pre.062`, hors registre ElGamal reporté.
|
|
||||||
|
|
||||||
### B. Socle metadata général
|
|
||||||
|
|
||||||
- [ ] Créer un pipeline metadata générique commun aux metadata on-chain SPL et Metaplex.
|
|
||||||
- [ ] Définir les contrats de lecture d’état, préflight, exécution, validation post-exécution et replay.
|
|
||||||
- [ ] Ajouter une fenêtre desktop spécialisée `demo_execution_metadata` pour sélectionner la famille metadata, le scénario, les comptes et le mode simulation/envoi.
|
|
||||||
- [ ] Garder les adapters Tauri minces et placer les scénarios Devnet dans `kb-pipeline-demo-scenarios`.
|
|
||||||
|
|
||||||
### C. SPL Token Metadata incorporées à Token-2022
|
|
||||||
|
|
||||||
Cette étape précède le programme Metaplex Token Metadata, conformément à la progression SPL du roadmap historique.
|
|
||||||
|
|
||||||
- [ ] Fermer la couverture de `spl-token-metadata-interface` et des metadata TLV incorporées à Token-2022.
|
|
||||||
- [ ] Compléter l’exécuteur des opérations metadata incorporées supportées.
|
|
||||||
- [ ] Ajouter préflight, sécurité, simulation-first, validation post-exécution et matérialisation.
|
|
||||||
- [ ] Ajouter les scénarios Devnet dans la fenêtre `demo_execution_metadata`.
|
|
||||||
- [ ] Vérifier la coexistence sans confusion avec Metaplex Token Metadata.
|
|
||||||
|
|
||||||
### D. Programme Metaplex Token Metadata
|
|
||||||
|
|
||||||
- [ ] Fermer définitivement le décodeur et les matérialisateurs à partir de l’IDL locale, des interfaces officielles et de fixtures réelles.
|
|
||||||
- [ ] Implémenter les intents et builders exécutables, avec inventaire explicite des variantes decode-only.
|
|
||||||
- [ ] Raccorder l’exécuteur au pipeline metadata général.
|
|
||||||
- [ ] Ajouter les scénarios Devnet Metaplex dans `demo_execution_metadata`.
|
|
||||||
- [ ] Valider replay et matérialisation après chaque transaction.
|
|
||||||
|
|
||||||
### E. Transport off-chain général
|
|
||||||
|
|
||||||
- [ ] Décider après le socle metadata de la création de `kb-offchain-transport`.
|
|
||||||
- [ ] Définir cette crate comme une façade générale des lectures réseau non Solana RPC, et non comme une crate limitée aux metadata.
|
|
||||||
- [ ] Prévoir des modules séparés pour les URI de metadata HTTP(S)/IPFS/Arweave, les prix et taux de référence SOL/USD, SOL/EUR et SOL/CHF, les APIs Jupiter et les futurs fournisseurs off-chain.
|
|
||||||
- [ ] Définir des contrats communs de timeout, retry borné, cache, validation de taille/type, provenance, fraîcheur et diagnostics.
|
|
||||||
- [ ] Décider séparément si certaines actions off-chain mutables ou authentifiées sont admises ; ne pas mélanger lecture publique, exécution distante et exécution on-chain.
|
|
||||||
- [ ] Ne jamais intégrer les lectures off-chain dans les décodeurs déterministes ni dans le replay canonique on-chain.
|
|
||||||
|
|
||||||
### F. Reprise protocolaire
|
|
||||||
|
|
||||||
- [ ] Stabiliser ensuite le socle Anchor/IDL.
|
|
||||||
- [ ] Reprendre Pump.fun, puis Raydium, Meteora, Jupiter et les autres AMM/launchpads selon les priorités du roadmap historique.
|
|
||||||
|
|
||||||
|
|
||||||
## 0.1.0 — Consolidation du workspace
|
|
||||||
|
|
||||||
- [x] Créer les dix crates initiales du workspace avec le nom canonique `kb-wallet`.
|
|
||||||
- [x] Regrouper les contrats decoder/executor/materializer dans `kb-lib`.
|
|
||||||
- [x] Générer l’arborescence des modules à partir des anciennes crates.
|
|
||||||
- [x] Conserver une copie de référence complète de `khadhroony-bot2`.
|
|
||||||
- [x] Restaurer l’architecture modulaire de `kb-core` à partir de `kb_core`, avec `lib.rs` limité aux modules et réexports.
|
|
||||||
- [x] Porter exactement les contrats publics de `kb_decoder_api`.
|
|
||||||
- [x] Porter exactement les contrats publics des APIs d’exécution et de matérialisation.
|
|
||||||
- [x] Porter les modèles de `kb_model` vers `kb-lib`.
|
|
||||||
- [x] Porter les décodeurs Solana core, SPL et Metaplex déjà implémentés dans bot2.
|
|
||||||
- [x] Porter leurs matérialisateurs déjà implémentés dans bot2.
|
|
||||||
- [ ] Porter leurs exécuteurs.
|
|
||||||
- [x] Fusionner `kb_store_core` et `kb_store_pg` dans `kb-store`.
|
|
||||||
- [ ] Migrer `kb-onchain-transport` depuis l’ancienne `kb_rpc`.
|
|
||||||
- [x] Renommer structurellement la crate.
|
|
||||||
- [x] Porter les contrats JSON-RPC, rôles d’endpoints, validation, clients/pools HTTP et méthodes HTTP standard.
|
|
||||||
- [ ] Porter WebSocket, sessions et pools d’abonnements.
|
|
||||||
- [ ] Porter l’acquisition canonique `getTransaction` et `getSignaturesForAddress`.
|
|
||||||
- [ ] Porter simulation, envoi et confirmation réseau complets.
|
|
||||||
- [ ] Adapter `kb-pipeline` aux nouveaux chemins publics.
|
|
||||||
- [ ] Adapter `kb-app-demo` et rétablir les validations fonctionnelles.
|
|
||||||
- [ ] Créer ultérieurement une crate off-chain générale pour les lectures HTTP/IPFS/Arweave, prix, APIs de protocoles et autres sources non Solana RPC, séparée des décodeurs, matérialisateurs et du replay canonique on-chain.
|
|
||||||
- [ ] Réorganiser les chemins d’export TS‑RS de `kb-lib` dans une tranche dédiée, en conservant `../frontend/ts/bindings/` comme préfixe de base.
|
|
||||||
- [ ] Auditer rétrospectivement la couverture historique des décodeurs et matérialisateurs.
|
|
||||||
|
|
||||||
### 0.1.0-pre.002 — Contrats fondamentaux consolidés
|
|
||||||
|
|
||||||
- [x] Porter les modèles partagés de `kb_model` dans `kb-lib`.
|
|
||||||
- [x] Porter les contrats publics de décodage dans `kb-lib::decoder::api`.
|
|
||||||
- [x] Porter les contrats publics de matérialisation dans `kb-lib::materializer::api`.
|
|
||||||
- [x] Porter les contrats publics d'exécution dans `kb-lib::executor::api`.
|
|
||||||
- [x] Maintenir `lib.rs` comme façade sans implémentation métier.
|
|
||||||
- [x] Valider le workspace avec Cargo sur la machine de développement.
|
|
||||||
|
|
||||||
### 0.1.0-pre.003 — Réécriture de `kb-store`
|
|
||||||
|
|
||||||
- [x] Remplacer le scaffold par une architecture intégrée contrats/adaptateurs.
|
|
||||||
- [x] Porter les DTO, entités, traits et validations store-neutral.
|
|
||||||
- [x] Porter l’adaptateur PostgreSQL, ses requêtes, diagnostics et initialisations idempotentes.
|
|
||||||
- [x] Conserver `MdCoreInstructionReplayInput` dans `kb-lib` et le réexporter depuis `kb-store`.
|
|
||||||
- [x] Supprimer la dépendance directe de `kb-store` vers `kb-config`.
|
|
||||||
- [x] Adapter les règles bot2 devenues incompatibles avec l’architecture bot3.
|
|
||||||
- [x] Valider `cargo check`, les 84 tests et Clippy pour `kb-store`, puis `cargo check --workspace`.
|
|
||||||
- [ ] Valider `cargo test --workspace` et `cargo clippy --workspace --all-targets`.
|
|
||||||
- [x] Valider les 84 tests PostgreSQL réels avec `KB_POSTGRES_TEST_URL`.
|
|
||||||
|
|
||||||
### 0.1.0-pre.004 — Décodeur Solana Core dans `kb-lib`
|
|
||||||
|
|
||||||
- [x] Remplacer le scaffold `kb-lib::decoder::solana::core` par le décodeur maximal validé de bot2.
|
|
||||||
- [x] Conserver les 18 surfaces natives, leurs 121 déclarations de couverture et leurs tests.
|
|
||||||
- [x] Adapter les contrats vers les réexports de `kb-lib` sans dépendance vers `kb-store`.
|
|
||||||
- [x] Préfixer les symboles internes afin d’éviter les collisions avec les futurs décodeurs fusionnés.
|
|
||||||
- [x] Déclarer le target hiérarchique `kb-lib.decoder.solana.core`.
|
|
||||||
- [x] Valider `cargo check -p kb-lib`, les 169 tests de `kb-lib` et les deux audits Rust.
|
|
||||||
- [ ] Valider Clippy et l’ensemble du workspace sur la machine de développement.
|
|
||||||
- [x] Poursuivre avec SPL Memo après validation.
|
|
||||||
|
|
||||||
### 0.1.0-pre.005 — Décodeur SPL Memo dans `kb-lib`
|
|
||||||
|
|
||||||
- [x] Remplacer le scaffold `kb-lib::decoder::spl::memo` par le décodeur validé de bot2.
|
|
||||||
- [x] Conserver les générations v1, v3 et v4, leurs règles distinctes et les 9 tests.
|
|
||||||
- [x] Ajouter les trois Program IDs canoniques dans `kb-program-ids` sans les classer comme natifs.
|
|
||||||
- [x] Préserver le payload borné, le SHA-256, les comptes ordonnés et les statuts non commités.
|
|
||||||
- [x] Porter la matrice machine-readable `docs/SPL_MEMO_MATRIX.json`.
|
|
||||||
- [x] Valider `kb-program-ids`, `kb-lib` et le workspace avec Cargo sur la machine de développement.
|
|
||||||
- [x] Poursuivre avec SPL Token classique après validation.
|
|
||||||
|
|
||||||
### 0.1.0-pre.006 — Décodeur SPL Token classique dans `kb-lib`
|
|
||||||
|
|
||||||
- [x] Remplacer le scaffold `kb-lib::decoder::spl::token` par le décodeur maximal validé de bot2.
|
|
||||||
- [x] Conserver les 28 tags publiés par `spl-token-interface 3.0.0` et les huit tests différentiels.
|
|
||||||
- [x] Préserver montants bruts, comptes ordonnés, autorités simple/multisig, suffixes et statuts non commités.
|
|
||||||
- [x] Conserver les bornes de `Batch`, ses chemins enfants et le refus des batches imbriqués.
|
|
||||||
- [x] Porter le target de tracing vers `kb-lib.decoder.spl.token`.
|
|
||||||
- [x] Rendre la contrainte `wincode 0.5.5` et `solana-wincode-varint 1.0.0` vérifiable par l’audit workspace.
|
|
||||||
- [x] Valider `kb-program-ids`, `kb-lib`, Clippy et le workspace avec Cargo sur la machine de développement.
|
|
||||||
- [x] Poursuivre avec le décodeur SPL Associated Token Account après validation.
|
|
||||||
|
|
||||||
### 0.1.0-pre.007 — Décodeur SPL Associated Token Account dans `kb-lib`
|
|
||||||
|
|
||||||
- [x] Remplacer le scaffold `kb-lib::decoder::spl::associated_token_account` par le décodeur exact validé de bot2.
|
|
||||||
- [x] Conserver `Create`, `CreateIdempotent`, `RecoverNested` et la forme historique `Create` à payload vide.
|
|
||||||
- [x] Préserver l’ordre des comptes, les flags, doublons, chemins outer/inner et statuts non commités.
|
|
||||||
- [x] Valider les PDA canoniques `[wallet, token_program, mint]` sans remplacer les adresses observées.
|
|
||||||
- [x] Distinguer explicitement SPL Token classique et Token‑2022 sans décoder leurs états ni extensions.
|
|
||||||
- [x] Conserver les dix tests différentiels et la matrice machine-readable ATA.
|
|
||||||
- [x] Porter le target de tracing vers `kb-lib.decoder.spl.associated_token_account`.
|
|
||||||
- [x] Valider `kb-program-ids`, les 196 tests de `kb-lib`, Clippy et le workspace avec Cargo sur la machine de développement.
|
|
||||||
- [x] Poursuivre avec les décodeurs Token‑2022 et registre ElGamal après validation.
|
|
||||||
|
|
||||||
### 0.1.0-pre.008 — Décodeurs Token‑2022 et registre ElGamal dans `kb-lib`
|
|
||||||
|
|
||||||
- [x] Remplacer les scaffolds `token2022` et `elgamal_registry` par les décodeurs exacts validés de bot2.
|
|
||||||
- [x] Conserver les 48 enveloppes Token‑2022, les sous-instructions d’extensions identifiables et les interfaces Metadata/Group incorporées.
|
|
||||||
- [x] Porter le parseur borné des états Mint, Account et Multisig avec leurs entrées TLV ordonnées.
|
|
||||||
- [x] Maintenir le registre ElGamal comme programme indépendant avec ses deux instructions et son état de compte exact de 64 octets.
|
|
||||||
- [x] Ajouter le Program ID du registre ElGamal à `kb-program-ids` sans le classer comme surface native.
|
|
||||||
- [x] Déplacer `ProgramIdEntry` et les fonctions du registre dans `kb-program-ids/src/programs.rs`, avec `lib.rs` limité aux réexports.
|
|
||||||
- [x] Porter les targets de tracing vers `kb-lib.decoder.spl.token2022` et `kb-lib.decoder.spl.elgamal_registry`.
|
|
||||||
- [x] Conserver les 55 tests Token‑2022/ElGamal et leurs matrices machine-readable.
|
|
||||||
- [x] Valider `kb-program-ids`, les 251 tests de `kb-lib`, Clippy et le workspace avec Cargo sur la machine de développement.
|
|
||||||
- [x] Poursuivre avec le décodeur Metaplex Token Metadata après validation.
|
|
||||||
|
|
||||||
### 0.1.0-pre.009 — Décodeur Metaplex Token Metadata dans `kb-lib`
|
|
||||||
|
|
||||||
- [x] Remplacer le scaffold `kb-lib::decoder::metadata::metaplex_token_metadata` par le décodeur maximal validé de bot2.
|
|
||||||
- [x] Conserver l’inventaire exhaustif des 58 discriminateurs d’instructions `0..=57`, y compris les variantes historiques.
|
|
||||||
- [x] Conserver l’inventaire exhaustif des 15 variantes de comptes `Key 0..=14`, avec rejet explicite de `Uninitialized`.
|
|
||||||
- [x] Porter les parseurs bornés de Metadata, Edition, Master Edition, Edition Marker, Token Record, records d’autorité et de délégation, escrow et Reservation List.
|
|
||||||
- [x] Préserver les validations d’owner, de PDA, de bump, de longueur, de suffixe, de comptes ordonnés et de provenance.
|
|
||||||
- [x] Maintenir les layouts historiques matérialisables avec lifecycle explicite mais définitivement non exécutables.
|
|
||||||
- [x] Ajouter le Program ID Metaplex Token Metadata à `kb-program-ids` sans le classer comme surface native.
|
|
||||||
- [x] Porter le target de tracing vers `kb-lib.decoder.metadata.metaplex_token_metadata`.
|
|
||||||
- [x] Conserver les 69 tests Metaplex et la matrice machine-readable exhaustive.
|
|
||||||
- [x] Valider `kb-program-ids`, les 320 tests de `kb-lib`, Clippy et le workspace avec Cargo sur la machine de développement.
|
|
||||||
- [x] Poursuivre avec les matérialisateurs après validation du port des décodeurs prioritaires.
|
|
||||||
|
|
||||||
### 0.1.0-pre.010 — Matérialisateurs Solana natifs dans `kb-lib`
|
|
||||||
|
|
||||||
- [x] Porter `MtLifecycleMaterializer`, `MtAdminMaterializer`, `MtComplianceAuditMaterializer` et `MtStakingMaterializer` dans les modules consolidés de `kb-lib`.
|
|
||||||
- [x] Conserver leurs 50 tests de projections natives, de politique de transaction et d’idempotence.
|
|
||||||
- [x] Réexporter les types concrets et les fonctions stateful publiques depuis la façade de `kb-lib`.
|
|
||||||
- [x] Ajouter un test d’intégration aval prouvant qu’un futur crate externe peut implémenter `MtApiEventMaterializer` avec la seule API publique.
|
|
||||||
- [x] Porter les targets vers `kb-lib.materializer.admin`, `kb-lib.materializer.compliance`, `kb-lib.materializer.lifecycle` et `kb-lib.materializer.staking`.
|
|
||||||
- [x] Conserver les identités de processor historiques afin de préserver les clés de replay et d’idempotence existantes.
|
|
||||||
- [x] Ajouter la règle d’ordre et d’absence de ligne vide interne dans les blocs de réexports publics.
|
|
||||||
- [x] Valider les 370 tests unitaires et le test d’intégration de `kb-lib`, Clippy et le workspace avec Cargo sur la machine de développement.
|
|
||||||
- [x] Poursuivre avec les matérialisateurs Memo, SPL Token, ATA, Token‑2022, registre ElGamal et Metaplex.
|
|
||||||
|
|
||||||
### 0.1.0-pre.011 — Matérialisateurs SPL et Metaplex dans `kb-lib`
|
|
||||||
|
|
||||||
- [x] Porter `MtTransactionAnnotationMaterializer`, `MtTokenAccountsMaterializer`, `MtFeesMaterializer`, `MtRiskMaterializer` et `MtMetadataMaterializer`.
|
|
||||||
- [x] Conserver leurs 45 tests historiques, en plus des 370 tests unitaires déjà validés.
|
|
||||||
- [x] Réexporter à la racine les cinq types concrets, les fonctions de snapshots Token‑2022/Metaplex et les types canoniques Metaplex nécessaires à leurs signatures publiques.
|
|
||||||
- [x] Rendre privée toute l’arborescence `kb-lib::materializer` et interdire mécaniquement tout nouveau `pub mod` dans cette frontière.
|
|
||||||
- [x] Étendre les tests aval aux trois contrats d’extension publics : `DcApiProtocolDecoder`, `MtApiEventMaterializer` et `ExApiInstructionExecutor`.
|
|
||||||
- [x] Étendre l’audit aux lignes vides internes des blocs homogènes `pub use` et `pub(crate) use`.
|
|
||||||
- [x] Porter les targets de risque, comptes Token et annotations vers `kb-lib.materializer.risk`, `kb-lib.materializer.token` et `kb-lib.materializer.transaction` dans les trois profils.
|
|
||||||
- [x] Maintenir le fetch HTTP/IPFS/Arweave hors de `kb-lib`, dans une future crate off-chain dédiée.
|
|
||||||
- [x] Normaliser les symboles fusionnés avec les préfixes `DC`, `MT`, `EX` et `MD`, sans alias de réexport.
|
|
||||||
- [x] Restaurer les 98 scaffolds de décodeurs avec des constantes `DC_*` uniques et réellement référencées.
|
|
||||||
- [x] Étendre l’audit aux façades privées, aux réexports transitifs `self::`, aux alias interdits et à la complétude des APIs externes.
|
|
||||||
- [ ] Valider les 415 tests unitaires et les trois tests d’intégration de `kb-lib`, Clippy et le workspace avec Cargo sur la machine de développement.
|
|
||||||
|
|
||||||
### 0.1.0-pre.012 — Squelettes des décodeurs réservés
|
|
||||||
|
|
||||||
- [x] Remplacer les 98 frontières `LEGACY_CRATE`/`MIGRATION_STATUS` par des types `Dc*Decoder` concrets.
|
|
||||||
- [x] Implémenter `DcApiProtocolDecoder` avec une compatibilité `Maybe` et un résultat vide sans faux événement.
|
|
||||||
- [x] Conserver Anchor sans Program ID statique et rattacher les 97 autres squelettes à une surface exacte.
|
|
||||||
- [x] Ajouter les 97 Program IDs correspondants à `kb-program-ids` et porter le registre total à 130 entrées uniques.
|
|
||||||
- [x] Exposer tous les types exclusivement par la façade `kb-lib/src/lib.rs`.
|
|
||||||
- [x] Supprimer `DC_MIGRATION_BOUNDARIES`, `*_LEGACY_CRATE` et `*_MIGRATION_STATUS` de l’arborescence des décodeurs.
|
|
||||||
- [x] Ajouter un test central de contrat pour les 98 squelettes et étendre l’audit contre le retour des marqueurs temporaires.
|
|
||||||
- [x] Valider le nouveau test unitaire, les 130 Program IDs, Clippy et le workspace avec Cargo sur la machine de développement.
|
|
||||||
- [x] Vérifier puis restaurer les squelettes des familles de matérialisation encore vides.
|
|
||||||
- [ ] Passer ensuite à l’API des exécuteurs, à leurs squelettes puis au port des exécuteurs déjà implémentés dans bot2.
|
|
||||||
|
|
||||||
### 0.1.0-pre.013 — Squelettes des matérialisateurs réservés
|
|
||||||
|
|
||||||
- [x] Remplacer les 14 frontières `LEGACY_CRATE`/`MIGRATION_STATUS` par des types `Mt*Materializer` concrets.
|
|
||||||
- [x] Conserver le contrat historique `MtMaterializer` et implémenter le contrat bot3 `MtApiEventMaterializer`.
|
|
||||||
- [x] Maintenir les squelettes inactifs : aucune famille acceptée et résultat API `Ignored`.
|
|
||||||
- [x] Préserver la famille de sortie historique pour les appels directs via l’ancien contrat.
|
|
||||||
- [x] Exposer les 14 types uniquement depuis la façade `kb-lib/src/lib.rs`.
|
|
||||||
- [x] Étendre le test aval et l’audit contre le retour des marqueurs temporaires.
|
|
||||||
- [x] Aligner `RUST023` sur l’ordre naturel produit par `rustfmt`.
|
|
||||||
- [x] Valider les deux nouveaux tests unitaires, le test aval, Clippy et le workspace avec Cargo sur la machine de développement.
|
|
||||||
- [x] Vérifier la parité de l’API des exécuteurs avant de restaurer leurs squelettes.
|
|
||||||
|
|
||||||
### 0.1.0-pre.014 — API et squelettes des exécuteurs
|
|
||||||
|
|
||||||
- [x] Vérifier la parité exacte des contrats `ExApi*` avec `kb_execution_api` de bot2.
|
|
||||||
- [x] Étendre le test aval au contrat `ExApiTypedInstructionExecutor` et au plan typé public.
|
|
||||||
- [x] Remplacer les 104 frontières `LEGACY_CRATE`/`MIGRATION_STATUS` par des types `Ex*Executor` concrets.
|
|
||||||
- [x] Rattacher chaque squelette à ses Program IDs enregistrés sans dépendre des décodeurs.
|
|
||||||
- [x] Maintenir les squelettes inactifs : support `Maybe` et plan explicite à zéro instruction.
|
|
||||||
- [x] Exposer les 104 types uniquement depuis la façade `kb-lib/src/lib.rs`.
|
|
||||||
- [x] Ajouter un test central couvrant les 104 squelettes et étendre l’audit contre le retour des marqueurs temporaires.
|
|
||||||
- [x] Valider le nouveau test unitaire, le test aval, Clippy et le workspace avec Cargo sur la machine de développement.
|
|
||||||
- [x] Porter ensuite l’exécuteur Solana Core déjà validé dans bot2.
|
|
||||||
|
|
||||||
### 0.1.0-pre.015 — Exécuteur Solana Core
|
|
||||||
|
|
||||||
- [x] Porter les 109 opérations typées de `kb_executor_solana_core`.
|
|
||||||
- [x] Couvrir System, Compute Budget, Address Lookup Table, précompiles, Config, Feature, Slashing, ZK ElGamal, Stake, Vote et Loaders v3/v4.
|
|
||||||
- [x] Conserver les surfaces historiques non exécutables en refus explicite.
|
|
||||||
- [x] Préfixer les types publics `ExSolanaCore*` et les constantes `EX_SOLANA_CORE_*`.
|
|
||||||
- [x] Préserver le pont JSON historique et le contrat de plan préparé typé.
|
|
||||||
- [x] Étendre le test aval à une construction Compute Budget réelle.
|
|
||||||
- [x] Réduire les frontières réservées à 103 et adapter l’audit.
|
|
||||||
- [x] Imposer les blocs `pub use` puis `pub(crate) use`, séparés par une ligne vide.
|
|
||||||
- [x] Valider les 507 tests unitaires, les trois tests d’intégration, Clippy et le workspace avec Cargo sur la machine de développement.
|
|
||||||
- [x] Porter ensuite les exécuteurs SPL déjà validés dans bot2.
|
|
||||||
|
|
||||||
### 0.1.0-pre.016 — Safety d’exécution et exécuteur SPL Memo
|
|
||||||
|
|
||||||
- [x] Porter `kb_execution_safety` dans `kb-lib` sous les contrats `ExSafety*`.
|
|
||||||
- [x] Conserver les décisions `Deny`, `RequireConfirmation` et `Allow`, avec violations stables.
|
|
||||||
- [x] Conserver les contrôles de simulation, blockhash/nonce, cluster, signers autorisés et plafonds de coût.
|
|
||||||
- [x] Remplacer le squelette Memo par `ExSplMemoExecutor` et ses intents typés.
|
|
||||||
- [x] Maintenir Memo v1/v3 en decode-only et Memo v4 exécutable.
|
|
||||||
- [x] Construire l’instruction avec `spl-memo-interface` en conservant ordre et doublons des signers.
|
|
||||||
- [x] Étendre le test aval à un plan Memo réel et à son évaluation safety.
|
|
||||||
- [x] Réduire les frontières réservées à 102 et adapter l’audit.
|
|
||||||
- [ ] Valider les tests portés, Clippy et le workspace avec Cargo sur la machine de développement.
|
|
||||||
- [ ] Porter ensuite SPL Token classique et SPL Associated Token Account.
|
|
||||||
|
|
||||||
### 0.1.0-pre.017 — Exécuteur SPL Associated Token Account
|
|
||||||
|
|
||||||
- [x] Remplacer le squelette ATA par l’exécuteur typé validé de bot2.
|
|
||||||
- [x] Conserver `Create`, `CreateIdempotent`, `RecoverNested`, les builders officiels et les validations post-exécution.
|
|
||||||
- [x] Porter le target vers `kb-lib.executor.spl.associated_token_account`.
|
|
||||||
- [x] Réduire les frontières réservées à 101.
|
|
||||||
- [x] Valider les 548 tests unitaires, les tests d’intégration, Clippy et le workspace sur la machine de développement.
|
|
||||||
|
|
||||||
### 0.1.0-pre.018 — Exécuteur SPL Token-2022
|
|
||||||
|
|
||||||
- [x] Remplacer le squelette Token-2022 par les cinq modules métier complets de bot2.
|
|
||||||
- [x] Conserver les 33 tests, les extensions, Confidential Transfer et Confidential Mint/Burn.
|
|
||||||
- [x] Porter le target vers `kb-lib.executor.spl.token2022` et la nomenclature interne vers `TOKEN2022`.
|
|
||||||
- [x] Réduire les frontières réservées à 100.
|
|
||||||
- [x] Valider les 592 tests unitaires, les tests d’intégration, Clippy et le workspace sur la machine de développement.
|
|
||||||
|
|
||||||
### 0.1.0-pre.019 — Exécuteur SPL ElGamal Registry
|
|
||||||
|
|
||||||
- [x] Remplacer le squelette ElGamal Registry par les opérations `CreateRegistry` et `UpdateRegistry` validées de bot2.
|
|
||||||
- [x] Conserver les preuves inline/contexte, la simulation obligatoire, les plafonds de frais et les validations post-exécution.
|
|
||||||
- [x] Déplacer `spl-elgamal-registry-interface` dans les dépendances normales de `kb-lib`.
|
|
||||||
- [x] Porter le target vers `kb-lib.executor.spl.elgamal_registry`.
|
|
||||||
- [x] Réduire les frontières réservées à 99.
|
|
||||||
- [x] Valider les 598 tests unitaires, les tests d’intégration, Clippy et le workspace sur la machine de développement.
|
|
||||||
|
|
||||||
### 0.1.0-pre.020 — Configuration et logging
|
|
||||||
|
|
||||||
- [x] Remplacer le scaffold `kb-config` par les modèles, parseurs, sérialiseurs, validations JSON Schema et 20 tests de bot2.
|
|
||||||
- [x] Remplacer le scaffold `kb-logging` par la configuration des routes, le runtime tracing multi-writers et les 17 tests de bot2.
|
|
||||||
- [x] Préserver `kb_logging::tracing_target()` pour la compatibilité temporaire de `kb-app-demo`.
|
|
||||||
- [x] Corriger les targets et chemins de logs de Solana Core et SPL Memo dans les trois profils.
|
|
||||||
- [x] Vérifier ATA, Token-2022 et ElGamal Registry, déjà alignés sur leurs targets bot3.
|
|
||||||
- [x] Laisser SPL Token classique sous son identité réservée tant que son exécuteur n’est pas migré.
|
|
||||||
- [x] Valider `kb-config`, `kb-logging`, Clippy et le workspace avec Cargo sur la machine de développement.
|
|
||||||
- [x] Décider le nom `kb-onchain-transport`; appliquer le renommage structurel dans `0.1.0-pre.023`.
|
|
||||||
### 0.1.0-pre.021 — Exécuteur SPL Token classique
|
|
||||||
|
|
||||||
- [x] Migrer l’exécuteur SPL Token classique, ses builders officiels, ses intents et ses tests.
|
|
||||||
- [x] Adapter le portage à l’API consolidée de `kb-lib` et supprimer les références aux anciennes crates `kb_model` et `kb_execution_safety`.
|
|
||||||
- [x] Déplacer `spl-token-interface` dans les dépendances normales de `kb-lib`.
|
|
||||||
- [x] Valider 613 tests `kb-lib`, les tests `kb-config` et `kb-logging`, Clippy et le workspace.
|
|
||||||
|
|
||||||
### 0.1.0-pre.022 — Couche transactionnelle Solana
|
|
||||||
|
|
||||||
- [x] Migrer `kb_execution_solana` dans `kb-lib::executor::solana::transaction`.
|
|
||||||
- [x] Conserver les transactions legacy, durable nonce, preuves de simulation, résolution des signataires et limites de paquet.
|
|
||||||
- [x] Adapter les tests à `solana_keypair::Keypair` sans couplage à `kb-wallet`.
|
|
||||||
- [x] Valider 625 tests `kb-lib`, Clippy et le workspace.
|
|
||||||
|
|
||||||
### 0.1.0-pre.023 — Renommage du transport on-chain
|
|
||||||
|
|
||||||
- [x] Renommer la crate scaffold `kb-rpc` en `kb-onchain-transport`.
|
|
||||||
- [x] Renommer l’identifiant Rust en `kb_onchain_transport`.
|
|
||||||
- [x] Mettre à jour le workspace, les dépendances, le lockfile, les targets et chemins de logs.
|
|
||||||
- [x] Mettre à jour les documents actifs et conserver les documents historiques bot2 inchangés.
|
|
||||||
- [ ] Valider le renommage avec Cargo sur la machine de développement.
|
|
||||||
- [ ] Migrer ensuite les contrats communs et le transport HTTP standard de l’ancienne `kb_rpc`.
|
|
||||||
|
|
||||||
|
|
||||||
|
## 0.4.6 — alignement fonctionnel et clôture de la migration principale
|
||||||
|
|
||||||
### 0.1.0-pre.028 — configuration de tracing wallet
|
### Objectifs
|
||||||
|
|
||||||
- [x] Routes canoniques `kb-wallet`.
|
|
||||||
- [x] Configuration d’exemple sans clé fournisseur en clair.
|
|
||||||
- [ ] Migration fonctionnelle de `kb-pipeline` à poursuivre à partir de `pre.029`.
|
|
||||||
|
|
||||||
|
- 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`.
|
||||||
|
|
||||||
### 0.1.0-pre.029 — Pipeline, fondations
|
### Lots
|
||||||
|
|
||||||
- [x] Planification et scopes de replay.
|
- refonte de la documentation générale et des règles ;
|
||||||
- [x] Extraction canonique vers les tables core.
|
- reconstruction des changelogs et du roadmap ;
|
||||||
- [x] Backfill et replay de décodage.
|
- documentation complète des 11 crates ;
|
||||||
- [ ] Orchestrations Solana stateful et exécution.
|
- reconstruction des prompts bot3 ;
|
||||||
|
- audit ciblé `docs/V0_4_6_ALIGNMENT_AUDIT.md` ;
|
||||||
|
- traitement ou documentation explicite des exceptions restantes.
|
||||||
|
|
||||||
- [x] Migrer `decode_replay` dans `kb-pipeline`.
|
### 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.1.0-pre.031 — Backfill HTTP
|
## 0.4.7 — Metaplex Token Metadata complet et clôture de 0.4.x
|
||||||
|
|
||||||
- [x] Porter les campagnes par signatures explicites et historique d’adresse.
|
### Positionnement de version
|
||||||
- [x] Conserver les directions `before` et `after`, les ancres et la pagination RPC bornée.
|
|
||||||
- [x] Conserver la reprise au dernier candidat contigu, les retries, le pacing et l’annulation coopérative.
|
|
||||||
- [x] Adapter la persistance à `kb-store` et l’acquisition à `kb-onchain-transport`.
|
|
||||||
- [x] Conserver les 14 tests bot2.
|
|
||||||
- [ ] Valider avec Cargo sur la machine de développement.
|
|
||||||
- [ ] Porter ensuite les orchestrations Solana stateful et d’exécution.
|
|
||||||
|
|
||||||
### 0.1.0-pre.033 — Pipeline stateful Token-2022
|
- 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é.
|
||||||
|
|
||||||
- [x] Lecture et validation stateful Token-2022.
|
### Objectifs
|
||||||
- [x] Routage des projections matérialisées Token-2022.
|
|
||||||
- [x] Lecture et validation du registre ElGamal.
|
|
||||||
- [x] Préflight multi-comptes Token-2022 borné.
|
|
||||||
- [ ] Orchestration des preuves et de l'exécution Token-2022.
|
|
||||||
|
|
||||||
|
- 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`.
|
||||||
|
|
||||||
- [x] `0.1.0-pre.037` — contrôles stateful Solana natifs migrés dans `kb-pipeline`.
|
### 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/`.
|
||||||
|
|
||||||
|
### 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.
|
||||||
|
|
||||||
|
## 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
|
||||||
|
|
||||||
|
- rendre `kb-pipeline-demo-scenarios` pleinement autonome hors desktop ;
|
||||||
|
- améliorer le CLI, les fixtures et les rapports ;
|
||||||
|
- compléter les démonstrations des surfaces `0.4.x` ;
|
||||||
|
- maintenir les adapters 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.
|
||||||
|
|||||||
Reference in New Issue
Block a user