khadhroony-bot3/CHANGELOG.md

<!-- file: CHANGELOG.md -->
<!-- version: 19 -->

# 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.2 — `ks-wallet` multi-wallet et stockage natif protégé

### Wallet natif et sécurité

- introduction du conteneur binaire versionné `<alias>.kswallet`, protégé par Argon2id v19 + XChaCha20-Poly1305 et publié atomiquement/no-clobber avec permissions privées ;
- séparation entre `WalletIdentity`, `WalletPassword`, `WalletFileHandle` et `UnlockedWallet`, sans getter public des bytes privés ;
- création, scan, lookup, inspection externe, unlock, signature et changement de mot de passe avec conservation exacte de la keypair/pubkey ;
- séparation des wallets persistants sous `wallets/` et des fixtures/keypairs temporaires sous `wallets/temporary/**` ;
- durcissement des erreurs, logs et `Debug` afin de ne pas exposer secret, password ou chemin local inutile.

### Migration et compatibilité

- migration non destructive du keypair JSON Solana legacy vers `.kswallet` ;
- inspection publique d'un fichier keypair externe sans import, avec retour limité à la pubkey et au format ;
- import/export testés de `SolanaCliJson` et du Base58 du keypair complet de 64 octets ;
- authentification obligatoire du mot de passe avant tout export secret ;
- refus des collisions d'alias/pubkey, symlinks, permissions ouvertes et écrasements silencieux ;
- exports opérateur du desktop confinés sous `data/wallets/` ;
- matrice documentée des formats Phantom, Solflare, Backpack, Trust Wallet et Base/Coinbase, avec Base58 comme seul adaptateur tiers de cette version.

### Configuration, scénarios et desktop

- `wallet_alias` optionnel/nullable par profil dans `ks-config`, sans mot de passe ni matériau secret ;
- résolution explicite d'un signer `.kswallet` dans les démos Devnet System/SPL/Metadata, sans fallback temporaire lorsqu'un alias persistant est choisi ;
- sélection session-only du wallet d'exécution depuis la fenêtre Wallets, indépendante de la configuration persistée et authentifiée côté backend ;
- inventaire/création/inspection/import/export des wallets et explorateur public SOL/tokens/historique par profil RPC dans `kb-app-demo-desktop`, via DTO applicatifs sûrs ;
- ajout de `ks-wallet-demo-scenarios`, consommateur externe réutilisable de `ks-wallet`, avec validation ordonnée A → B → rejet de A → ouverture/signature avec B → restauration vers A.

### Validation et suite

- `cargo fmt --all`, `cargo check --workspace`, `cargo clippy --all-targets`, audit workspace et `cargo test --workspace` validés sur la prerelease de clôture `0.5.2-pre.007` après réconciliation documentaire finale ;
- validation runtime du signer persistant dans les démos Devnet avec `persistence="persistent"` et exports JSON/Base58 sous `data/wallets/` ;
- l'inventaire/migration des fixtures historiques et la régression de chargement de fixture Token-2022 sont explicitement reportés à `0.5.4` ;
- `0.5.3` est consacré à l'audit et la normalisation de `ks-store`.

## 0.5.1 — namespaces Khadhroony Solana et configuration sûre

### Namespace et ownership

- migration des dix bibliothèques Solana généralistes vers `ks-*` / `ks_*`, avec maintien de `kb-app-demo-desktop` dans le domaine applicatif Bot ;
- migration des 255 identités techniques actives vers `ks-lib-decoder.*`, `ks-lib-executor.*` et `ks-lib-materializer.*` ;
- adoption du namespace `KS_*` pour les contrats Solana, de `KB_*` pour les contrats réellement possédés par le Bot et des classes `*_SECRET_*`, `*_PUBLIC_*` et internes ;
- conservation explicite du workspace, du dépôt et du répertoire racine sous le nom `khadhroony-bot3`.

### Configuration et composition

- remplacement du document applicatif monolithique par des documents spécialisés `logging`, `transport`, `listeners`, `store`, `wallet` et `execution`, chacun validé par son schéma et doté de defaults autonomes ;
- composition propre aux binaires via `<binary>.default.config.json`, avec sélection et validation des documents/profils partagés par `ks-config` ;
- sortie de `logs_directory` et `wallets_directory` des profils, avec overrides d’environnement dédiés ;
- déplacement de `auto_reconnect` vers les defaults WebSocket du transport et des autorisations d’envoi vers la politique d’exécution ;
- rangement des exemples conformes sous `config/exemples/` et des schémas actifs sous `config/schemas/`.

### Sécurité et frontières publiques

- distinction explicite entre configuration source, runtime backend-only et DTO publics/diagnostiques ;
- propagation de sensibilité selon `Secret > Internal > Public`, y compris dans les valeurs composées après substitution d’environnement ;
- retrait de `Serialize`/`Debug` des contrats de configuration sensibles et suppression des URLs résolues des snapshots transport exposables ;
- remplacement des retours Tauri directs par des DTO desktop sanitisés, sans URL RPC/WS, DSN PostgreSQL, chemins wallet/SQLite ni secrets ;
- durcissement des erreurs HTTP/WS et de validation afin de ne pas recopier de corps distant, message RPC ou valeur rejetée susceptible de contenir un secret ;
- retrait de TS-RS de `ks-config` et `ks-lib`, les bindings TypeScript devenant une responsabilité des applications Tauri via wrappers explicites.

### Validation et suite

- validations `cargo fmt`, `cargo check --workspace`, `cargo clippy --all-targets`, audit workspace et `cargo test --workspace` réussies sur la prerelease de clôture `0.5.1-pre.009`, puis build desktop de release `0.5.1` validé par `cargo tauri build` avec génération des bundles `.deb`, `.rpm` et `.AppImage` ;
- conservation des préfixes SQL `kb_sol_*` jusqu’au chantier cohérent `0.5.3` ;
- préparation de `0.5.2`, dédiée à la restructuration de `ks-wallet`, sans ouvrir de nouvelle surface protocolaire.

## 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.