# CHANGELOG — khadhroony-bot3 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. ## 0.5.0 — cadrage de la fondation `0.5.x` ### Architecture et namespaces - audit des frontières réelles de configuration, logging, wallet, store, scénarios et desktop avant toute restructuration ; - adoption de la séparation entre `khadhroony-solana`, domaine des bibliothèques Solana généralistes, et `khadhroony-bot`, domaine applicatif du futur robot de trading ; - décision de migrer en `0.5.1` les dix crates généralistes vers `ks-*` / `ks_*`, tout en conservant `kb-app-demo-desktop` côté Bot ; - adoption du namespace d'environnement `KS_*` et des classes `KS_SECRET_*`, `KS_PUBLIC_*` et `KS_*` interne ; - décision de migrer les identités techniques généralistes vers `ks-lib-decoder.*`, `ks-lib-materializer.*` et `ks-lib-executor.*`. ### Configuration, wallet et stockage - confirmation du split futur entre configuration généraliste et configuration logging, avec documents, schémas et profils indépendants ; - cadrage d'une séparation entre configuration source, runtime résolue et surfaces publiques/diagnostiques afin qu'aucun secret résolu ne puisse être exposé involontairement ; - caractérisation du format wallet `0.4.8` comme contrat de migration à préserver ou importer explicitement en `0.5.2` ; - audit de `ks-store` confirmant les frontières existantes tout en identifiant `block_time`, provenance et index trading/routing comme axes de `0.5.3` ; - décision de migrer en `0.5.3` les tables Solana `kb_sol_*` vers `k_sol_*`, `kb_*` restant réservé aux éventuelles données réellement spécifiques au Bot. ### Scénarios et exécution - confirmation que les campagnes réutilisables appartiennent à la future crate `ks-pipeline-demo-scenarios`, le desktop restant adaptateur UI/Tauri ; - inventaire des exécuteurs actifs et réservés sans convertir les surfaces réservées en dette implicite ; - maintien du registre ElGamal dans son statut synthétique connu en l'absence de nouvelle possibilité de validation réseau. ### Préparation des versions suivantes - transfert des décisions durables vers le ROADMAP, la politique de namespace Khadhroony Solana et les documents d'architecture ; - archivage du plan et du prompt `0.5.0` ; - préparation de `0.5.1`, qui ouvrira la migration `ks-*` / `KS_*` et la restructuration sûre de la configuration. ## 0.4.8 — Solana Program Metadata et complétude Metadata on-chain ### Solana Program Metadata - implémentation complète de la surface indépendante `ProgM6JCCvbYkfKqJYHePx4xxSUSqJp7rh8Lyv7nk7S` : IDL, modèles, comptes, neuf instructions stables, PDA, décodeur, matérialiseur, exécuteur et pipeline ; - replay mainnet de recherche et campagne Devnet réutilisable couvrant les neuf opérations ; - intégration desktop dédiée avec préflight, simulation, confirmation, postconditions et preuves structurées. ### Token-2022 Token Metadata - fermeture des cinq opérations de `spl-token-metadata-interface` dans la surface Token-2022 existante : `Initialize`, `UpdateField`, `Emit`, `RemoveKey` et `UpdateAuthority` ; - campagne Devnet complète avec fixture fraîche, return data `Emit`, lectures stateful, replay et matérialisation ; - conservation de la frontière stricte entre Token-2022 Token Metadata, Solana Program Metadata et Metaplex Token Metadata. ### Metaplex Token Metadata - réaudit de la surface courante et qualification des campagnes Create/Mint, collection, Print/Burn, lifecycle pNFT, escrow, maintenance et Use ; - fermeture de la matrice Devnet courante à 15 opérations `confirmed`, 5 `unavailable` et 0 `not_run` ; - maintien des opérations indisponibles comme probes bornées sans fausse promotion réseau. ### Desktop et cohérence transversale - finalisation de `demo_execution_metadata` avec trois domaines séparés, campagnes réutilisables, JsonViewer, accordéons de preuves et journal pleine largeur ; - centralisation des scénarios réseau réutilisables dans `ks-pipeline-demo-scenarios` plutôt que dans l’adaptateur Tauri ; - réconciliation des matrices, registres runtime, exports publics, IDL, TODO et stockage ; - confirmation qu’aucune migration PostgreSQL spécialisée Metadata n’est nécessaire. ### Validation et release - `cargo fmt --all`, `cargo check --workspace`, `cargo clippy --all-targets`, audit Rust du workspace et `cargo test --workspace` validés ; - build desktop de release validé par `cargo tauri build`, qui pilote lui-même TypeScript/Vite ; - génération validée des bundles `.deb`, `.rpm` et `.AppImage` en version desktop `0.4.8` ; - `kb-offchain-transport` et les traitements metadata off-chain restent hors de la chaîne canonique et sont reportés à `0.16.x+`. ## 0.4.7 — Metaplex Token Metadata ### Capacités - achèvement de la surface Metaplex Token Metadata migrée depuis bot2 ; - décodeurs d’instructions et de comptes, PDA, owners, modèles et variantes historiques ; - matérialisation metadata, administration, lifecycle et risques applicables ; - intents typés, builders, exécuteur, préflight stateful, simulation-first et postconditions ; - intégration dans `ks-pipeline`, scénarios synthétiques et runner Devnet réutilisable ; - intégration desktop sans fetch HTTP/IPFS/Arweave. ### Validation - parcours réseau représentatifs Create/Update exécutés sur Devnet ; - matrices et tests de couverture fermés pour le milestone `0.4.7` ; - campagnes spécialisées complémentaires explicitement reportées puis fermées pendant `0.4.8`. ## 0.4.6 — alignement fonctionnel de khadhroony-bot3 ### Architecture - clôture de la migration principale de bot2 vers l’architecture consolidée bot3 ; - onze crates documentées et versionnées `0.4.6` ; - décodeurs, exécuteurs et matérialisateurs regroupés dans `ks-lib` ; - stockage consolidé dans `ks-store` et transports RPC dans `ks-onchain-transport`. ### Capacités - Solana Core, SPL Memo, SPL Token classique, Associated Token Account et Token-2022 alignés sur le périmètre historique `0.4.6` ; - backfill, acquisition canonique, extraction Core, replay, matérialisation et idempotence validés ; - System Transfer, Memo v4 et surfaces SPL prévues validés dans les campagnes applicatives ; - session WebSocket persistante indépendamment du cycle de vie de la fenêtre `demo_ws`. ### Validation - `cargo fmt --all`, `cargo check --workspace`, `cargo clippy --all-targets` et `cargo test --workspace` validés ; - audits Rust, exports, règles Khadhroony et contrats statiques pré-`0.4.6` validés ; - matrices, registres runtime et bindings TS-RS validés ; - campagne desktop finale déclarée conforme. ### Exceptions et reports - registre ElGamal non déclaré validé réellement sur Devnet ou Mainnet faute de déploiement et de preuves disponibles ; - achèvement de Metaplex Token Metadata reporté à `0.4.7` ; - SPL Token Metadata et décision sur `kb-offchain-transport` reportés à `0.4.8` ; - améliorations structurelles de `ks-config`, `ks-logging` et `ks-store` reportées à `0.5.x`. ## 0.1.0-mig-from-kbot2 — transition architecturale vers khadhroony-bot3 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`. ### Architecture - consolidation de plus de 250 crates historiques en 11 crates de workspace ; - regroupement des modèles, décodeurs, exécuteurs et matérialisateurs dans `ks-lib` ; - consolidation du stockage dans `ks-store` ; - renommage de `kb-rpc` en `ks-onchain-transport` ; - migration du pipeline dans `ks-pipeline` ; - extraction des scénarios de démonstration dans `ks-pipeline-demo-scenarios` ; - maintien de `kb-app-demo-desktop` comme crate mixte bibliothèque et binaire ; - migration et renommage du portefeuille en `ks-wallet`. ### Normes - adoption de Rust 2024 et des règles strictes du workspace bot3 ; - interdiction des paniques implicites et des erreurs opaques dans le code de production ; - normalisation des exports publics, des en-têtes de fichiers, du tracing et des conventions de modules ; - 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 - 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. ### Validation - 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. # Historique fonctionnel de khadhroony-bot2 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`. `khadhroony-bot3` résulte de la migration et de la consolidation de cette base historique dans une nouvelle architecture. Son alignement fonctionnel est clôturé par la version bot3 `0.4.6`. Les versions `0.4.7` et `0.4.8` de `khadhroony-bot3` ont ensuite achevé respectivement Metaplex Token Metadata puis les surfaces Metadata on-chain complémentaires, avec exécution, pipeline, scénarios et validations réseau. 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. ## 0.4.7-kbot2 — Metaplex Token Metadata interrompu par la migration bot3 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`. - implémentation du décodeur Metaplex Token Metadata dans bot2 ; - implémentation de la matérialisation associée dans bot2 ; - 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.4.6-kbot2 — Token-2022, extensions et registre ElGamal - couverture bornée de Token-2022, de ses extensions et des interfaces externes associées ; - préflight, orchestration de preuves, corrélation stateful, validation et matérialisation ; - 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.4.5-kbot2 — SPL Associated Token Account - décodage et exécution des créations ATA classiques et Token-2022 ; - vérification des PDA, de l’ordre des seeds et des contrats officiels ; - intégration aux matérialisateurs et au pipeline de validation. ## 0.4.4-kbot2 — SPL Token classique - couverture des instructions SPL Token classiques, y compris opérations checked, multisig, native token et batch borné ; - matérialisation des comptes, autorités, délégations, risques et changements administratifs ; - exécution typée, préflight, simulation-first et validation des signers. ## 0.4.3-kbot2 — SPL Memo v1, v3 et v4 - décodage borné des trois générations ; - matérialisation des annotations transactionnelles ; - exécution limitée à Memo v4 ; - validation Devnet de Memo v4. ## 0.4.2-kbot2 — exécution native et RPC Solana standard - infrastructure d’exécution Solana Core ; - couverture des programmes natifs, loaders, précompiles et opérations supportées ; - simulation, soumission, confirmation et politiques de sécurité ; - matrice d’exécution native et contrats de transaction legacy ou durable nonce. ## 0.4.1-kbot2 — programmes Solana natifs - décodage des programmes natifs, loaders, Compute Budget, Address Lookup Table, Stake, Vote et précompiles ; - matérialisations lifecycle, administration, compliance et staking ; - extraction et replay contextualisés. ## 0.4.0-kbot2 — infrastructure de décodage et matérialisation - contrats communs de décodeurs, support, compatibilité et replay ; - ledger de traitement et matérialisation optionnelle ; - matrices contractuelles exécutables et tests de couverture. ## 0.3.4-kbot2 — extraction Core et clôture de la fondation transactionnelle - extraction des transactions canoniques vers les tables Core ; - replay déterministe et traitement idempotent ; - ledger de progression et reprise bornée. ## 0.3.3-kbot2 — backfill HTTP - acquisition historique gratuite par adresse et signatures ; - pagination, retries, annulation coopérative et reprise déterministe ; - démonstration applicative du backfill. ## 0.3.2-kbot2 — contrat canonique et adaptateur HTTP - définition d’une transaction Solana canonique indépendante du fournisseur ; - conversions explicites depuis les réponses RPC ; - conservation sans perte des données nécessaires au replay. ## 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.