khadhroony-bot3/CHANGELOG.md

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