v0.1.0-pre.011

docs/legacy-khadhroony-bot2/CHANGELOG.md

@@ -35,7 +35,7 @@ Validation du jalon de cadrage stockage : conventions PostgreSQL définies autou
 
 ## 0.2.1 — contrats `kb_store_core` et replay instruction-level
 
-Validation du jalon de contrats storage : `kb_store_core` expose les types communs backend-agnostiques pour pagination, healthcheck, migrations, erreurs de stockage, DTOs applicatifs, entities proches SQL et traits repositories sans implémentation PostgreSQL. Les contrats couvrent le raw RPC et WebSocket, le cycle de vie raw `Full` / `Compacted` / `Archived` / `Purged`, les états de traitement raw, la signature optionnelle des notifications WebSocket, la déduplication par `notification_key`, le lien futur optionnel notification vers transaction canonique, ainsi que le replay par instruction. Le replay est défini comme un scheduling au niveau instruction, mais le décodage reçoit un contexte extrait complet via `CoreInstructionReplayInput` : instruction ciblée, account keys, logs, balance changes et contexte transactionnel minimal. Les repositories restent abstraits et ne créent encore ni pool PostgreSQL, ni migration SQL réelle. Validation locale effectuée : `cargo test -p kb_store_core` avec 28 tests passés et `cargo clippy --all-targets` sans avertissement. Les validations précédentes du jalon ont également confirmé `kb_store_pg` sans test actif, `kb_config` avec 35 tests passés et `kb_app_demo` avec 28 tests passés.
+Validation du jalon de contrats storage : `kb_store_core` expose les types communs backend-agnostiques pour pagination, healthcheck, migrations, erreurs de stockage, DTOs applicatifs, entities proches SQL et traits repositories sans implémentation PostgreSQL. Les contrats couvrent le raw RPC et WebSocket, le cycle de vie raw `Full` / `Compacted` / `Archived` / `Purged`, les états de traitement raw, la signature optionnelle des notifications WebSocket, la déduplication par `notification_key`, le lien futur optionnel notification vers transaction canonique, ainsi que le replay par instruction. Le replay est défini comme un scheduling au niveau instruction, mais le décodage reçoit un contexte extrait complet via `MdCoreInstructionReplayInput` : instruction ciblée, account keys, logs, balance changes et contexte transactionnel minimal. Les repositories restent abstraits et ne créent encore ni pool PostgreSQL, ni migration SQL réelle. Validation locale effectuée : `cargo test -p kb_store_core` avec 28 tests passés et `cargo clippy --all-targets` sans avertissement. Les validations précédentes du jalon ont également confirmé `kb_store_pg` sans test actif, `kb_config` avec 35 tests passés et `kb_app_demo` avec 28 tests passés.
 
 ## 0.2.2 — infrastructure PostgreSQL minimale
 
@@ -47,7 +47,7 @@ Validation du jalon raw store minimal : `kb_store_pg` crée et initialise les de
 
 ## 0.2.4 — core Solana normalisé minimal
 
-Validation du jalon core store minimal : `kb_store_pg` crée et initialise maintenant les tables core `kb_sol_core_transactions`, `kb_sol_core_account_keys`, `kb_sol_core_instructions`, `kb_sol_core_inner_instructions`, `kb_sol_core_logs` et `kb_sol_core_balance_changes`, en complément du raw store `0.2.3`, sans schema PostgreSQL applicatif explicite. Les migrations et l'initializer utilisent des noms SQL préfixés et explicites pour les contraintes et index : `pk_`, `fk_`, `ck_`, `ux_` et `ix_`. L'initialisation raw/core est sérialisée par un verrou PostgreSQL `pg_advisory_xact_lock` afin d'éviter les courses concurrentes pendant les tests ou les démarrages parallèles. `CoreTransactionStore` dispose de l'implémentation PostgreSQL minimale pour insérer les transactions core, account keys, instructions, inner instructions, logs et deltas de balances, puis reconstruire `CoreInstructionReplayInput` pour les futurs décodeurs. Le script de maintenance `kb_store_pg/maintenance/drop_raw_core_store.sql` permet de réinitialiser explicitement les tables raw/core locales dans l'ordre inverse des dépendances. Validation locale effectuée : `KB_POSTGRES_TEST_URL=postgres://solana:solana@localhost:5432/solana cargo test -p kb_store_pg -- --nocapture` avec 30 tests passés, création vérifiée des 8 tables dans PostgreSQL, réinitialisation validée via le script de maintenance, puis `cargo clippy --all-targets` sans avertissement. Le worker d'extraction raw RPC vers core, les observations et le ledger ops sont conservés pour les jalons suivants.
+Validation du jalon core store minimal : `kb_store_pg` crée et initialise maintenant les tables core `kb_sol_core_transactions`, `kb_sol_core_account_keys`, `kb_sol_core_instructions`, `kb_sol_core_inner_instructions`, `kb_sol_core_logs` et `kb_sol_core_balance_changes`, en complément du raw store `0.2.3`, sans schema PostgreSQL applicatif explicite. Les migrations et l'initializer utilisent des noms SQL préfixés et explicites pour les contraintes et index : `pk_`, `fk_`, `ck_`, `ux_` et `ix_`. L'initialisation raw/core est sérialisée par un verrou PostgreSQL `pg_advisory_xact_lock` afin d'éviter les courses concurrentes pendant les tests ou les démarrages parallèles. `CoreTransactionStore` dispose de l'implémentation PostgreSQL minimale pour insérer les transactions core, account keys, instructions, inner instructions, logs et deltas de balances, puis reconstruire `MdCoreInstructionReplayInput` pour les futurs décodeurs. Le script de maintenance `kb_store_pg/maintenance/drop_raw_core_store.sql` permet de réinitialiser explicitement les tables raw/core locales dans l'ordre inverse des dépendances. Validation locale effectuée : `KB_POSTGRES_TEST_URL=postgres://solana:solana@localhost:5432/solana cargo test -p kb_store_pg -- --nocapture` avec 30 tests passés, création vérifiée des 8 tables dans PostgreSQL, réinitialisation validée via le script de maintenance, puis `cargo clippy --all-targets` sans avertissement. Le worker d'extraction raw RPC vers core, les observations et le ledger ops sont conservés pour les jalons suivants.
 
 ## 0.2.5 — diagnostics SQL PostgreSQL dans `kb_app_demo`
 

docs/legacy-khadhroony-bot2/ROADMAP.md

@@ -172,7 +172,7 @@ Ce fichier contient les changements futurs et le phasage prévu. Il ne remplace
 - [x] Ajouter les types communs : pagination, tri, limites, healthcheck, statut migration.
 - [x] Ajouter les premiers DTO génériques : raw RPC transaction, raw WS notification, core transaction, core instruction.
 - [x] Ajouter les contrats core pour account keys, logs et balance changes extraits.
-- [x] Ajouter `CoreInstructionReplayInput` pour fournir aux décodeurs une instruction avec contexte extrait.
+- [x] Ajouter `MdCoreInstructionReplayInput` pour fournir aux décodeurs une instruction avec contexte extrait.
 - [x] Ajouter les contrats de cycle de vie raw : état de rétention, état de traitement et mark lifecycle.
 - [x] Ajouter les contrats de replay par instruction : état instruction, filtre de replay et lifecycle mark.
 - [x] Ajouter les premiers traits repository sans implémentation SQL.
@@ -229,7 +229,7 @@ Ce fichier contient les changements futurs et le phasage prévu. Il ne remplace
 ### 0.2.4 — core Solana normalisé minimal
 
 - [x] Créer les tables core minimales : `kb_sol_core_transactions`, `kb_sol_core_account_keys`, `kb_sol_core_instructions`, `kb_sol_core_inner_instructions`, `kb_sol_core_logs`, `kb_sol_core_balance_changes`.
-- [x] Construire `CoreInstructionReplayInput` depuis les tables `core` pour les décodeurs.
+- [x] Construire `MdCoreInstructionReplayInput` depuis les tables `core` pour les décodeurs.
 - [x] Marquer les instructions insérées comme `Pending` pour permettre un replay instruction-level.
 - [x] Préparer le replay partiel par état, slot et program id via `CoreInstructionReplayFilter`.
 - [x] Ajouter une initialisation idempotente raw/core via `PostgresStore::initialize_store_schema()`.
@@ -460,7 +460,7 @@ Les contrôles autrefois prévus dans `0.3.5` sont reclassés ainsi : la stabili
 - [x] Auditer les crates utilisant `tracing.workspace = true` et couvrir les treize crates alors actives par un test de constante canonique et par les routes des trois profils.
 - [x] Ajouter le tracing propriétaire manquant sur les clients/pools HTTP et WebSocket ainsi que sur le backfill ; promouvoir les inputs decode unmatched, statuts failed/unsupported et échecs de matérialisation/persistance au niveau `error`.
 - [x] Formaliser dans `docs/SOLANA_INTERFACE_DEPENDENCIES.md` la politique d’interfaces officielles : dépendance seulement au point de consommation, priorité `wincode` puis Borsh, parser borné lorsque l’interface n’expose que `bincode`.
-- [x] Passer `CoreInstructionReplayInput` au contrat `2` avec une liste stable et numériquement ordonnée des instructions outer, sans migration SQL, afin de résoudre les références inter-instructions des précompiles.
+- [x] Passer `MdCoreInstructionReplayInput` au contrat `2` avec une liste stable et numériquement ordonnée des instructions outer, sans migration SQL, afin de résoudre les références inter-instructions des précompiles.
 - [x] Décoder `zk_elgamal_proof` dans `pre.015` selon `solana-zk-elgamal-proof-interface ^0.1` et le runtime Agave : treize discriminants, preuves inline ou référencées par compte, contexte optionnel et fermeture du contexte, sans recalcul cryptographique.
 - [x] Décoder dans `pre.016` l’ancien `zk_token_proof` comme compatibilité historique, puis retirer dans `pre.019` la dépendance dépréciée `solana-zk-token-sdk` au profit d’un miroir wire local borné des dix-sept discriminants et tailles auditées.
 - [x] Décoder les loaders `native_loader`, `bpf_loader_deprecated`, `bpf_loader`, `bpf_loader_upgradeable` et `loader_v4` ; classer l’invocation Native Loader opaque comme `ignored` sans sémantique inventée.
@@ -532,14 +532,14 @@ Les contrôles autrefois prévus dans `0.3.5` sont reclassés ainsi : la stabili
 
 #### Suite d’orchestration
 
-- [x] `pre.004` : ajouter dans `kb_rpc` les adaptateurs typés `getGenesisHash`, `getLatestBlockhash`, `getFeeForMessage` et `simulateTransaction`, avec routage par rôle, classification des clusters publics, diagnostics runtime et conversion vers `ExecutionSimulationResult`, sans signature ni envoi.
+- [x] `pre.004` : ajouter dans `kb_rpc` les adaptateurs typés `getGenesisHash`, `getLatestBlockhash`, `getFeeForMessage` et `simulateTransaction`, avec routage par rôle, classification des clusters publics, diagnostics runtime et conversion vers `ExApiExecutionSimulationResult`, sans signature ni envoi.
 - [x] `pre.004` : documenter dans `kb_executor_solana_core/README.md` chaque fonction publique, les six opérations constructibles, leurs paramètres, résultats, effets et frontières.
 - [x] Valider localement `pre.004` : `kb_rpc` 63 tests, `kb_execution_api` 21 tests, `kb_execution_safety` 13 tests, `kb_executor_solana_core` 10 tests, `kb_config` 40 tests et Clippy global propre.
 - [x] `pre.005` : ajouter `kb_execution_solana` pour assembler les instructions planifiées en transaction legacy, produire les payloads base64 de frais/simulation, lier la simulation au hash exact du message, résoudre exactement les signataires requis via l’interface Solana `Signer` et signer séparément hors Tauri.
 - [x] `pre.005` : renommer la constante interne en `MAINNET_GENESIS_HASH` sans changer sa valeur ; conserver `mainnet-beta` seulement comme alias historique des endpoints/CLI et renommer le variant public en `Mainnet` sérialisé `mainnet`.
 - [x] `pre.005` : distinguer la simulation exacte de la simulation avec remplacement de blockhash et interdire qu’un résultat `replaceRecentBlockhash=true` autorise la signature du message original.
 - [x] Valider localement les tests ciblés de `pre.005`/`pre.006` : `kb_execution_solana` 7 tests, `kb_execution_api` 22 tests, `kb_execution_safety` 15 tests, `kb_rpc` 63 tests, `kb_executor_solana_core` 10 tests, `kb_wallet` 6 tests et `kb_config` 40 tests.
-- [x] `pre.006` : corriger la compilation croisée de `pre.005`, supprimer l’avertissement TS-rs sur l’alias historique `mainnet_beta`, utiliser le trait public `TypedInstructionExecutor` dans les tests d’assemblage, resynchroniser le contrat de simulation RPC et rendre les erreurs de routage tracing explicites.
+- [x] `pre.006` : corriger la compilation croisée de `pre.005`, supprimer l’avertissement TS-rs sur l’alias historique `mainnet_beta`, utiliser le trait public `ExApiTypedInstructionExecutor` dans les tests d’assemblage, resynchroniser le contrat de simulation RPC et rendre les erreurs de routage tracing explicites.
 - [x] `pre.007` : supprimer le dernier opérateur `?` introduit dans un chemin de production de `kb_execution_api`, le remplacer par un `match` avec propagation explicite et auditer les fichiers d’exécution `0.4.2` contre `?`, `unwrap` et `expect` de production.
 - [x] Valider localement `pre.007` : `kb_execution_api` 22 tests et Clippy global propre.
 - [x] `pre.008` : ajouter les contrats RPC typés `getBalance`, `requestAirdrop`, `sendTransaction`, `getSignatureStatuses` et `getBlockHeight`, avec routage par rôle, préflight obligatoire, contrôle de la signature retournée et confirmation bornée jusqu’à succès, échec, expiration ou timeout.
@@ -603,7 +603,7 @@ Les contrôles autrefois prévus dans `0.3.5` sont reclassés ainsi : la stabili
 - [x] Valider localement `pre.019` : `kb_executor_solana_core` 70 tests, `kb_execution_api` 22, `kb_execution_safety` 15, `kb_execution_solana` 12, `kb_rpc` 70 et Clippy global propre.
 - [x] `pre.020` : onze opérations Loader v3 et neuf opérations Loader v4 réellement constructibles, avec déploiement/upgrade/autorités/fermeture hors UI; BPF Loader v1/v2 restent historiques `decode-only` et Native Loader est classé sans instruction client.
 - [x] Valider localement `pre.020` : `kb_executor_solana_core` 81 tests, `kb_decoder_solana_core` 115, `kb_execution_api` 22, `kb_execution_safety` 15, `kb_execution_solana` 12 et `kb_rpc` 70.
-- [x] `pre.021` : centraliser dans un module privé les parsers `Pubkey`/program ID et les validations communes de longueur, montant positif, comptes distincts, dérivation seedée et erreurs partagées ; supprimer les implémentations de production identiques sans modifier les 109 opérations ni leur wire.
+- [x] `pre.021` : centraliser dans un module privé les parsers `MdPubkey`/program ID et les validations communes de longueur, montant positif, comptes distincts, dérivation seedée et erreurs partagées ; supprimer les implémentations de production identiques sans modifier les 109 opérations ni leur wire.
 - [x] Valider localement `pre.021` après `fix.001` : `kb_executor_solana_core` 86 tests et `cargo clippy --all-targets` propre ; ce Clippy couvre également les changements Loader de `pre.020`.
 - [x] `pre.022` : implémenter le préflight stateful Localnet/Devnet pour ALT, Config, Feature, Slashing et contextes ZK ElGamal ; ajouter `getEpochInfo` typé et la matrice machine-readable complète des 18 surfaces natives avec classification de toute opération non invocable.
 - [x] Valider localement `pre.022` : `kb_executor_solana_core` 87 tests, `kb_pipeline` 56 tests, `kb_rpc` 71 tests, `kb_execution_api` 22 tests, `kb_execution_safety` 15 tests, `kb_execution_solana` 12 tests, validateur de matrice réussi et `cargo clippy --all-targets` propre.

docs/legacy-khadhroony-bot2/RULES.md

@@ -138,7 +138,7 @@ Aucun renommage massif de crates n'est autorisé sans étape de contrôle dédi
 
 - Une crate est opérationnelle lorsqu’elle effectue des I/O, orchestre un pipeline, décode, matérialise, exécute, applique une politique runtime ou prend une décision mutable observable.
 - Toute crate opérationnelle ajoutée ou modifiée doit dépendre de `tracing` depuis le workspace et déclarer exactement un `pub(crate) const TRACING_TARGET` dans `src/constants.rs`.
-- La valeur canonique de `TRACING_TARGET` est le nom exact du package Cargo. Les targets historiques `khbot.*`, les suffixes de module et les targets de fenêtre sont interdits dans les nouvelles modifications.
+- La valeur canonique de `DC_METADATA_MTM_TRACING_TARGET` est le nom exact du package Cargo. Les targets historiques `khbot.*`, les suffixes de module et les targets de fenêtre sont interdits dans les nouvelles modifications.
 - Les macros `tracing` doivent utiliser `target: crate::TRACING_TARGET` et des champs structurés stables. La granularité interne passe par `action`, `stage`, `window`, `campaign_id`, `signature`, `instruction_path`, `program_id`, `processor_name`, `processor_version`, `status` et `error_code`.
 - Les crates passives de types, contrats, DTO, API sans exécution, registres ou constantes restent sans dépendance `tracing`. `kb_config` reste une exception de bootstrap tant que sa validation précède l’installation du subscriber.
 - Il est interdit d’ajouter `tracing` sans événement réel ou de conserver un faux target uniquement consommé par `let _target`.
@@ -150,14 +150,14 @@ Aucun renommage massif de crates n'est autorisé sans étape de contrôle dédi
 - Chaque profil doit router les événements vers les sorties globales `debug.log`, `info.log`, `error.jsonl` et `app.log`, puis vers `debug.log`, `info.log` et `error.jsonl` dans un répertoire propre à chaque crate utilisant `tracing`.
 - L’ajout ou la suppression de `tracing.workspace = true` dans une crate impose la mise à jour simultanée de la matrice de routes, de ses tests et de `docs/TRACING_CONTRACT.md`.
 - Le contrat détaillé est défini dans `docs/TRACING_CONTRACT.md`.
-- L’audit mécanique spécifique au projet est exécuté par `python3 scripts/audit_khadhroony_workspace_rules.py`. Il couvre notamment `TRACING_TARGET` et l’usage obligatoire de `solana_pubkey::Pubkey` à la place de `solana_address::Address`.
+- L’audit mécanique spécifique au projet est exécuté par `python3 scripts/audit_khadhroony_workspace_rules.py`. Il couvre notamment `DC_METADATA_MTM_TRACING_TARGET` et l’usage obligatoire de `solana_pubkey::Pubkey` à la place de `solana_address::Address`.
 
 ## Règles de réutilisation des interfaces Solana et SPL
 
 - Les dépendances déclarées dans `[workspace.dependencies]` forment un catalogue de versions et de features autorisées ; elles ne doivent être ajoutées à une crate consommatrice que lorsqu’un type, un encodeur, un décodeur ou un identifiant officiel est réellement utilisé.
 
 - Dans un `Cargo.toml`, placer dans `[dependencies]` toute crate référencée par le code de bibliothèque compilé en production. Réserver `[dev-dependencies]` aux références contenues exclusivement dans `#[cfg(test)]`, les tests d’intégration, benches ou exemples. Une dépendance de test vers un décodeur ou matérialiseur concret est légitime lorsqu’elle sert uniquement à éprouver une orchestration générique fondée sur les traits API ; elle ne prouve pas qu’une capacité de production manque. Toute promotion de `dev-dependencies` vers `dependencies` doit être motivée par un appel runtime réel, et toute dépendance runtime inutilisée doit être supprimée.
-- Les registres de composition runtime des applications doivent énumérer explicitement chaque décodeur et matérialiseur concret activé. Toute nouvelle surface instructionnelle dotée d’un `EventMaterializer` doit être ajoutée au registre applicatif et couverte par un test d’inventaire ordonné ; une crate présente dans le workspace ou dans `kb_pipeline` n’est pas activée automatiquement. Les matérialiseurs exclusivement stateful qui n’implémentent pas `EventMaterializer` restent routés par leurs APIs de snapshots dédiées.
+- Les registres de composition runtime des applications doivent énumérer explicitement chaque décodeur et matérialiseur concret activé. Toute nouvelle surface instructionnelle dotée d’un `MtApiEventMaterializer` doit être ajoutée au registre applicatif et couverte par un test d’inventaire ordonné ; une crate présente dans le workspace ou dans `kb_pipeline` n’est pas activée automatiquement. Les matérialiseurs exclusivement stateful qui n’implémentent pas `MtApiEventMaterializer` restent routés par leurs APIs de snapshots dédiées.
 - Les corrélations instruction/état doivent produire une issue explicite (`confirmed`, `contradicted` ou `not_applicable`) et ne doivent jamais transformer automatiquement une configuration observée en violation, score ou conclusion métier.
 - Une interface officielle Solana ou SPL étroite doit être préférée à `solana-sdk` lorsque son contrat suffit.
 - L’ordre de préférence des formats est : schéma officiel `wincode`, schéma officiel Borsh, puis parseur local borné reproduisant exactement le runtime lorsque l’interface officielle n’expose que `bincode`.