khadhroony-bot3/docs/legacy-khadhroony-bot2/CHANGELOG.md

Changelog

Ce fichier est réservé aux versions validées. Les changements non validés restent décrits dans ROADMAP.md ou RULES.md.

0.0.1 — projet vide

Initialisation du dépôt comme point de départ vide. Cette version sert uniquement de repère historique avant la création du squelette modulaire.

0.0.2 — squelette stabilisé

Validation du squelette initial de khadhroony-bot2 : workspace Rust modulaire, règles de développement, nomenclature des surfaces, registres de programmes, configuration multi-profils, couche d'exécution réservée, décodeurs/exécuteurs/matérialisateurs réservés, documentation de cadrage, prompts de session et application Tauri de démonstration en squelette. Cette version devient la base propre avant le développement 0.1.x consacré à kb_logging et kb_config.

0.1.0 — kb_logging réel

Validation du jalon kb_logging : API publique minimale, initialisation tracing_subscriber, routes console, fichier humain, fichier JSON et fichier erreurs, filtrage par target et niveau, nettoyage ANSI des fichiers pour les messages issus de WebView Tauri, support des globs crate.* et crate::*, et couverture unitaire renforcée. Validation locale effectuée : cargo test -p kb_logging avec 14 tests passés et cargo clippy -p kb_logging --all-targets sans erreur. cargo fmt n'est pas retenu comme validation obligatoire du jalon, car la configuration rustfmt.toml contient des options nightly non applicables sur stable et le formatage courant est géré depuis Eclipse.

0.1.1 — kb_config typé et validé

Validation du jalon kb_config : configuration JSON multi-profils avec un seul profil actif, schéma config/schema.config.json validé via jsonschema, désérialisation typée, validation métier des profils, endpoints HTTP JSON-RPC et WebSocket Solana standard, listeners standards, sorties de logging configurables, stores PostgreSQL/SQLite, wallet, exécution et sections de démonstration. Les placeholders de clés restent directement dans les URLs et les champs runtime hors périmètre avant v1.x sont refusés par le schéma. Les exports TS-rs suivent la convention ../frontend/ts/bindings/kb_config/settings/<Type>.ts. Validation locale effectuée : cargo test --tests -p kb_config avec 35 tests passés, dont les tests générateurs TS-rs export_bindings_*, et cargo clippy annoncé sans erreur pour le jalon.

0.1.2 — liaison kb_logging, kb_config et démo Tauri

Validation du jalon d’intégration Tauri : kb_app_demo charge le profil actif via kb_config, initialise kb_logging depuis cette configuration, conserve un AppState global, garde demo_config comme fenêtre de démonstration isolée et réémet les logs frontend vers tracing avec des targets statiques. La fenêtre principale rend le README workspace en HTML via markdown-it, expose un dropdown de démos, et la fenêtre configuration affiche le profil actif, la configuration complète et le schéma JSON avec un viewer JSON interactif. Le verrou mono-instance est appliqué uniquement dans kb_app_demo/src/main.rs afin de préserver l’entrée mobile par kb_app_demo_lib::run(). Le provider Rustls par défaut est initialisé dans la librairie pour desktop et mobile. Le splashscreen est aligné sur le modèle de khadhroony-bobobot/kb_demo_app, avec fade-in/fade-out, durée minimale extensible et attente initiale avant fade-in pour éviter l’apparition instantanée. kb_core expose maintenant l’erreur et le résultat communs sous kb_core::Error et kb_core::Result. Validation locale effectuée : cargo test -p kb_core avec 2 tests passés, cargo test -p kb_config avec 35 tests passés, cargo test -p kb_logging avec 14 tests passés, cargo test -p kb_app_demo avec 12 tests passés, cargo clippy --all-targets sans erreur et validation visuelle via cargo tauri dev -c kb_app_demo/tauri.conf.json.

0.1.3 — clients HTTP/WS Solana standard, rôles et pools

Validation du jalon RPC initial : kb_rpc expose les contrats JSON-RPC 2.0 partagés, le routage par rôle et request_kind, les clients HTTP JSON-RPC et WebSocket Solana standard, ainsi que les pools HTTP/WS par rôle. kb_app_demo ajoute les fenêtres dédiées demo_http et demo_ws, les listes contrôlées de rôles et méthodes, le refresh explicite des pools, le profil mainnet Helius, la connexion WebSocket persistante conservée dans AppState, les subscriptions multiples sur une même socket, l’unsubscribe individuel, la déconnexion globale à l’arrêt de l’application et le throttling des notifications WebSocket vers la WebView pour éviter les freezes sur les programmes très bavards. Les transports gRPC, Helius enhanced WebSocket, Helius gRPC et LaserStream restent hors périmètre avant les versions ultérieures. Validation locale effectuée : cargo test -p kb_rpc avec 39 tests passés, cargo test -p kb_app_demo avec 28 tests passés, cargo clippy --all-targets sans erreur, et validation visuelle des démos HTTP/WS via cargo tauri dev -c kb_app_demo/tauri.conf.json.

0.2.0 — conventions PostgreSQL et contrats DB

Validation du jalon de cadrage stockage : conventions PostgreSQL définies autour du schéma courant/default du profil, généralement public, sans espaces applicatifs séparés, et convention de tables Solana kb_sol_<domain>_<name> avec les domaines raw, core, obs, decode, mat, catalog, agg, ops et wallet intégrés au nom de table. Les règles SQL de base sont documentées pour id, created_at, updated_at, slot, signature, program_id, raw_json et payload_json, avec index minimaux et contraintes strictes mais réversibles. Les responsabilités de kb_store_core et kb_store_pg sont clarifiées, avec séparation entities/, dtos/, queries/ et repositories/, et interdiction de placer des structures métier ou DB dans les requêtes. Les migrations historiques de brouillon sont neutralisées afin de ne pas créer d'espace PostgreSQL applicatif ni de table qualifiée par espace logique. Validation locale effectuée : cargo test -p kb_config avec 35 tests passés, cargo test -p kb_app_demo avec 28 tests passés et cargo clippy --all-targets sans erreur. kb_store_core et kb_store_pg ne disposent pas encore de tests à ce stade documentaire.

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

Validation du jalon d'infrastructure PostgreSQL : kb_store_pg expose maintenant une première implémentation réelle avec options de connexion, pool sqlx::PgPool, construction depuis la configuration active, masquage du DSN pour les diagnostics, healthcheck SELECT 1, lecture du schema courant, lecture de la version PostgreSQL et snapshot de migrations non destructif. La stratégie de migrations reste volontairement cadrée sans créer les tables Solana lourdes, qui sont reportées à 0.2.3 pour le raw store minimal. Les validateurs de noms de tables imposent la convention kb_sol_<domain>_<name> et refusent les schemas explicites. Validation locale effectuée : cargo test -p kb_store_pg avec 11 tests passés, test PostgreSQL réel optionnel optional_postgres_healthcheck_from_env validé avec KB_POSTGRES_TEST_URL=postgres://solana:solana@localhost:5432/solana, cargo test -p kb_store_core avec 28 tests passés, cargo test -p kb_config avec 35 tests passés, cargo test -p kb_app_demo avec 28 tests passés et cargo clippy --all-targets sans avertissement après remplacement local de l'exception allow par expect sur l'incompatibilité connue async_trait / clippy::implicit_return.

0.2.3 — raw store Solana minimal

Validation du jalon raw store minimal : kb_store_pg crée et initialise les deux premières tables Solana réelles, kb_sol_raw_rpc_transactions et kb_sol_raw_ws_notifications, sans créer de schema PostgreSQL applicatif explicite. Le raw RPC est inséré de façon idempotente par signature, les notifications WebSocket sont dédupliquées par notification_key, la signature des notifications reste optionnelle et le lien vers la transaction RPC canonique est préparé pour les étapes suivantes. Les tables conservent les champs de cycle de vie retention_state, processing_state, processed_at et processing_reason, avec raw_json nullable côté SQL afin de permettre les futures politiques compacted, archived et purged sans migration cassante. Les requêtes et l'implémentation PostgreSQL de RawTransactionStore couvrent les insertions, lookup de signature, lookup de notification et marquage lifecycle. Validation locale effectuée : cargo test -p kb_store_pg avec 21 tests passés, incluant le test PostgreSQL réel optionnel optional_postgres_raw_store_roundtrip_from_env avec KB_POSTGRES_TEST_URL=postgres://solana:solana@localhost:5432/solana, cargo test -p kb_store_core avec 28 tests passés, cargo test -p kb_config avec 35 tests passés, cargo test -p kb_app_demo avec 28 tests passés et cargo clippy --all-targets sans avertissement. Une correction locale du test raw PostgreSQL a été intégrée pour appeler directement test_signature() depuis le module de test.

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

Validation du jalon diagnostics SQL : kb_app_demo ajoute les fenêtres demo_sql_diag, demo_sql_pg_raw et demo_sql_pg_core pour inspecter en lecture seule l’état PostgreSQL courant. Le démarrage Tauri tente l’initialisation raw/core lorsque database.postgres.auto_initialize_schema est actif, journalise les tables créées ou déjà présentes via le splashscreen et tracing, puis les fenêtres exposent le profil actif, le backend, le DSN masqué, le schema courant, le healthcheck, l’état migrations et les statistiques de tables raw/core. Les payloads JSON des trois fenêtres utilisent le viewer interactif déjà utilisé par demo_config, sans ajouter de nouvelle dépendance npm. Le jalon ne lance ni extracteur raw RPC vers core, ni décodage, ni matérialisation ; ces traitements restent reportés à 0.3.x. Validation locale effectuée : cargo test -p kb_store_pg avec 30 tests passés, cargo test -p kb_config avec 35 tests passés, cargo test -p kb_app_demo avec 32 tests passés, cargo clippy --all-targets sans avertissement, et validation visuelle des trois fenêtres via cargo tauri dev -c kb_app_demo/tauri.conf.json.

0.3.0 — cadrage Agave local et sources temps réel

Validation du jalon de cadrage 0.3.x : la phase ingestion/backfill/extraction raw vers core est reportée à 0.4.x, tandis que 0.3.x devient une phase d’expérimentation Agave local non votant et de stratégie live source. Le jalon documente le profil manuel agave_local_research, la commande de départ agave-validator, les probes RPC/WS attendus, les mesures ledger/accounts/CPU/RAM/réseau/lag, les règles de fallback vers les providers externes et les critères de décision avant 0.4.x. Le profil Agave reste désactivé par défaut afin de préserver mainnet_research comme base stable, et aucune ingestion de production, aucun backfill historique, aucun décodage DEX, aucune matérialisation et aucune opération de trading ne sont introduits dans ce jalon. Validation locale du delta 0.3.0-pre.001 confirmée par l’utilisateur avant mise à jour du changelog.

0.3.1 — transaction canonique et observations d’acquisition

Validation du jalon de stockage canonique : kb_sol_raw_transactions conserve désormais une transaction source-indépendante par signature avec canonical_json, canonical_json_hash et canonical_format_version, tandis que kb_sol_obs_transaction_observations conserve uniquement les informations de provenance, méthode, session, timestamps, taille, statut et erreur sans dupliquer le payload complet. La lignée core utilise raw_transaction_id; les DTOs, entities, repositories, requêtes et diagnostics Tauri ont été alignés. La migration réelle depuis le schéma 0.2.x a été contrôlée sur PostgreSQL 17.10 : les anciennes tables kb_sol_raw_rpc_transactions et kb_sol_raw_ws_notifications sont absentes, les tables canoniques sont présentes et les colonnes actives portent les nouveaux noms. Après cette validation, les fichiers SQL ont été consolidés en une baseline propre ne contenant que 0001_canonical_transaction_store.sql et 0002_core_store.sql; les fichiers SQL actifs n’embarquent plus les anciennes définitions de tables. Validation locale effectuée : cargo test -p kb_app_demo avec 32 tests passés, cargo test -p kb_store_core avec 30 tests passés, KB_POSTGRES_TEST_URL=postgres://solana:solana@localhost:5432/solana cargo test -p kb_store_pg -- --nocapture avec 32 tests passés, cargo clippy --all-targets sans avertissement, démarrage Tauri validé et diagnostics des huit tables raw/obs/core confirmés. Les fixtures PostgreSQL de test ont été nettoyées manuellement après validation.

0.3.2 — contrat canonique et adaptateur HTTP

Validation du jalon transactionnel canonique : kb_model expose désormais un modèle source-indépendant couvrant les transactions legacy et version 0, le message, les comptes statiques et chargés par Address Lookup Tables, les instructions externes et internes, les logs, le statut et les erreurs, les frais, compute units et cost units, les balances SOL et SPL/Token-2022, les rewards, les return data et le block time lorsqu’ils sont disponibles. Les signatures et clés publiques restent en base58, les données d’instruction sont normalisées en base64, les montants SPL bruts sont canonicalisés sans perte et la sérialisation déterministe trie récursivement les objets JSON avant calcul du hash SHA-256. kb_rpc fournit l’adaptateur getTransaction JSON-RPC et l’interface commune préparant les futurs adaptateurs Helius WebSocket et Yellowstone gRPC dans la crate existante, tandis que kb_store_core::RawTransactionInsert::from_canonical relie le modèle au store canonique. Les fixtures offline couvrent legacy/v0, succès/échec, ALT, CPI, SPL Token et Token-2022, et les formes fournisseur équivalentes produisent le même hash. Validation locale effectuée : cargo test -p kb_model avec 23 tests passés, cargo test -p kb_rpc avec 48 tests passés, cargo test -p kb_store_core avec 31 tests passés, KB_POSTGRES_TEST_URL=postgres://solana:solana@localhost:5432/solana cargo test -p kb_store_pg -- --nocapture avec 32 tests passés, puis cargo clippy --all-targets sans avertissement après ajout des retours explicites imposés par clippy::implicit_return. Les fixtures PostgreSQL du roundtrip ont été nettoyées manuellement après validation.

0.3.3 — backfill HTTP gratuit et demo_backfill

Validation du jalon de backfill HTTP : kb_rpc expose désormais getSignaturesForAddress avec pagination before / until, tandis que getTransaction alimente le modèle canonique sans conserver durablement le payload fournisseur. kb_pipeline orchestre les campagnes de signatures explicites et les recherches avant ou après une signature pour un programme, un token ou un pool, avec déduplication, limites de pages, reprise exportable, concurrence, temporisation, retries bornés, arrêt coopératif et journalisation détaillée. Le parcours after utilise la borne RPC until, des pages pouvant atteindre 1 000 signatures et une sélection bornée en mémoire afin de ne conserver que les X signatures directement postérieures à l’ancre dans l’historique de l’adresse. kb_app_demo ajoute la fenêtre demo_backfill, organisée en accordéons Bootstrap 5, avec paramètres communs, textarea de signatures, formulaires programme/token/pool, journal, résumé et commande d’arrêt. Chaque transaction complète est insérée une seule fois dans kb_sol_raw_transactions; chaque tentative d’acquisition produit une observation légère dans kb_sol_obs_transaction_observations, tandis que les résultats missing et failed ne créent aucun faux payload canonique.

La correction finale de l’arrêt coopératif remplace la création globale des futures par une file bornée à la concurrence effective, distingue les candidats sélectionnés, démarrés, terminés, annulés et non démarrés, et calcule resume_before_signature depuis le dernier préfixe contigu réellement terminé. Une campagne réelle de 500 candidats a validé l’arrêt avec 7 candidats démarrés, 3 terminés, 4 annulés et 493 non démarrés, sans journalisation artificielle des candidats restants. Validation locale effectuée : cargo test -p kb_rpc avec 54 tests passés, cargo test -p kb_pipeline avec 10 tests passés, cargo test -p kb_store_core avec 31 tests passés, cargo test -p kb_store_pg avec 32 tests passés, cargo test -p kb_app_demo avec 38 tests passés et cargo clippy --all-targets sans avertissement. Les campagnes Tauri réelles ont validé les signatures explicites, programme avant/après, token avant/après et pool avant/après ; le cas program_after a parcouru 5 516 signatures indexées avant de sélectionner les 5 signatures les plus proches de l’ancre. Les diagnostics PostgreSQL ont confirmé 62 transactions canoniques et 62 observations, sans alimentation prématurée des tables core, dont l’extraction reste prévue pour 0.3.4.

0.3.4 — extraction canonique vers core et clôture de la fondation 0.3.x

Validation du jalon d’extraction structurelle : kb_pipeline transforme les transactions canoniques en graphes core atomiques comprenant transactions, account keys statiques et ALT, instructions outer et inner à chemins stables, logs reliés prudemment et deltas SOL/SPL Token/Token-2022. kb_store_core et kb_store_pg exposent et implémentent les contrats de persistance, le ledger versionné kb_sol_ops_processing_ledger, le skip par version/hash, le force replay et le rollback complet. kb_app_demo ajoute demo_core_extraction et le navigateur read-only demo_sql_replay_candidates avec filtres, sélection, copie et exports CSV sous data/exports_csv/; kb_program_ids fournit un registre énumérable de 182 programmes. Les transactions Solana échouées restent extractibles et seront décodables comme observations d’intention ou d’échec, sans être matérialisées automatiquement comme mutations réussies. Validation réelle effectuée sur PostgreSQL 17.10 : 70 transactions extraites sans erreur, sept contrôles d’intégrité sans anomalie, replay normal de 14 signatures entièrement ignoré, force replay des mêmes 14 signatures sans duplication, second replay entièrement ignoré, cardinalité finale de 70 transactions core et ledger final de 70 succès pour 84 tentatives. Validation locale finale : cargo test -p kb_pipeline avec 24 tests passés, KB_POSTGRES_TEST_URL=... cargo test -p kb_store_pg -- --nocapture avec 39 tests passés dont le rollback/replay corrigé, cargo test -p kb_app_demo avec 60 tests passés, cargo test -p kb_program_ids avec 2 tests passés et cargo clippy --all-targets sans avertissement. L’ancien jalon 0.3.5 est absorbé dans cette version ; la suite active devient 0.4.0 pour l’infrastructure commune de décodage et de matérialisation.

0.4.0 — infrastructure commune de décodage et de matérialisation

Validation du socle commun de replay contextualisé : kb_decoder_api et kb_materializer_api travaillent sur les inputs core complets, kb_pipeline sélectionne uniquement les programmes compatibles avec les processors activés, effectue un dispatch déterministe par programme et chemin d’instruction, persiste atomiquement couverture, ledger, événements décodés et sorties matérialisées, et applique le skip par processor/version/hash. Le force replay est autorisé uniquement avec des signatures explicites ou avec l’autorisation opérateur « toutes les signatures » bornée par les filtres et la limite. La matérialisation est refusée lorsqu’aucun matérialiseur n’est enregistré. Le classifieur solana_native_classifier déclare les 18 surfaces natives/runtime/loaders/précompiles connues sans produire de faux décodage.

kb_app_demo ajoute demo_decode_replay, ses diagnostics decode/ledger/couverture et les contrôles de replay normal, force replay ciblé, replay global explicitement autorisé, concurrence bornée et arrêt coopératif. Chaque campagne possède un campaign_id propagé par spans jusqu’au pipeline, au store PostgreSQL et au décodeur. Les migrations raw/core/decode sont appliquées une seule fois au démarrage Tauri ; les commandes de démo réutilisent ensuite le schéma initialisé. Les validations frontend du backfill bloquent localement les requêtes incomplètes sans produire de faux événements backend ERROR.

Validation locale finale : cargo test -p kb_config avec 36 tests passés, cargo test -p kb_pipeline avec 41 tests passés, KB_POSTGRES_TEST_URL=postgres://solana:solana@localhost:5432/solana_test cargo test -p kb_store_pg -- --nocapture avec 44 tests passés, cargo test -p kb_app_demo avec 75 tests passés et cargo clippy --all-targets sans avertissement. Les campagnes Tauri réelles ont validé neuf skips version/hash, neuf force replays ciblés, un second skip cohérent, un replay global strictement limité à cinq inputs, l’annulation puis le redémarrage d’une campagne, et la corrélation complète des traces. Le correctif final d’annulation garantit started + not_started = selected et completed = started; une campagne réelle a terminé avec 382 inputs sélectionnés, 45 démarrés/terminés, 337 non démarrés, 45 dispatchs unsupported, aucun unmatched, aucun échec et aucun événement dans errors.jsonl. La couverture PostgreSQL confirme 18 déclarations natives, 382 observations Compute Budget reconnues sans erreur et 94 observations System reconnues sans erreur. 0.4.1 devient le jalon actif pour le décodage maximal des programmes Solana natifs, loaders et précompiles.

0.4.1 — programmes Solana natifs, loaders, précompiles et matérialisations natives

Validation du jalon 0.4.1 : kb_decoder_solana_core couvre désormais les programmes Solana natifs/runtime, historiques, loaders, précompiles et surfaces ZK explicitement incluses dans le périmètre. Le registre exécutable natif contient 18 surfaces après reclassification de StakeConfig11111111111111111111111111111111 comme compte historique non exécutable et ajout du stateless Slashing Program S1ashing11111111111111111111111111111111111 observé dans Agave v4.1.1 derrière feature gate. Les surfaces décodées incluent System, Vote, Stake, Config, Compute Budget, Address Lookup Table, Feature, ZK ElGamal Proof, l’ancien ZK Token Proof historique/no-op, les loaders Native/BPF v1/v2/Upgradeable/v4, Ed25519, secp256k1, secp256r1 et Slashing. SPL Memo, SPL Token, Token-2022, Stake Pool, Single Pool, Account Compression, Noop et SPL Name Service restent réservés aux jalons suivants.

Le jalon a étendu le contrat de replay instructionnel avec les instructions outer ordonnées afin de résoudre les références inter-instructions des précompiles et du profil Compute Budget. Les décodeurs bornent les offsets, tailles, compteurs, références d’instructions, comptes requis et payloads suffixes sans recalcul cryptographique pour les signatures ou preuves ZK. L’ancien solana-zk-token-sdk déprécié a été retiré ; le miroir ZK Token historique repose maintenant sur une table wire locale auditée, sans dépendance directe à bincode.

Les matérialisations natives sont clôturées au niveau instructionnel stable. kb_materializer_lifecycle projette Address Lookup Table, lifecycle des loaders, révocation Feature, durable nonce, comptes System create/allocate, contextes ZK ElGamal et rapports Slashing. kb_materializer_admin projette assignations System, écritures Config opaques et changements d’autorité Loader. kb_materializer_compliance_audit projette écritures/copies de bytecode Loader et profils Compute Budget transactionnels agrégés. kb_materializer_staking projette les intentions commitées Stake/Vote : comptes, autorités, lockup, délégation, désactivation, split, merge, retraits, move stake/lamports, identité Vote, commission, vote state et dépôt de rewards. Les sorties ne prétendent pas reconstruire les snapshots finaux de comptes, les sysvars historiques, les crédits Vote cumulés, l’activation Stake par epoch, les unités compute consommées ou les frais finaux runtime.

kb_app_demo enregistre les matérialiseurs natifs solana_native_lifecycle, solana_native_admin, solana_native_compliance_audit et solana_native_staking. Les profils de logging montent à 53 routes avec fichiers dédiés pour les crates opérationnelles ajoutées. demo_backfill accepte maintenant les modes program_latest, token_latest et pool_latest : une recherche « avant, plus anciennes » sans ancre commence sur les signatures les plus récentes, tandis que la direction « après, plus récentes » conserve une ancre obligatoire.

Les validations utilisateur finales confirment : kb_program_ids 5 tests, kb_decoder_solana_core 114 tests, kb_materializer_lifecycle 16 tests, kb_materializer_admin 7 tests, kb_materializer_compliance_audit 7 tests, kb_materializer_staking 8 tests, kb_config 36 tests, kb_pipeline 45 tests, kb_store_pg 45 tests avec PostgreSQL réel, kb_app_demo 78 tests et cargo clippy --all-targets sans avertissement. Le correctif de sérialisation test-only des tests PostgreSQL réels élimine l’interblocage intermittent observé lors des tests optionnels concurrents.

Les campagnes mainnet ciblées validées couvrent notamment : System 817 inputs décodés avec 258 sorties et 52 refus attendus sur transactions échouées ; Config 96/96 avec 96 sorties admin ; Stake 448/448 avec 447 sorties et un refus attendu ; Vote 600/600 avec 600 sorties ; Compute Budget 2 746/2 746 avec 1 603 profils transactionnels matérialisés ; ZK ElGamal 151/151 avec 139 sorties de contexte ; ALT 104/104 avec 104 sorties lifecycle ; Slashing sans corpus observable, validé par sources officielles et fixtures synthétiques. Tous ces replays se terminent avec unmatched = 0, failedInputs = 0, unsupported = 0 et journaux error.jsonl vides dans les archives fournies.

La suite active devient 0.4.2 : infrastructure d’exécution et kb_executor_solana_core, avec séparation stricte entre plan, simulation, signature, envoi et validation post-exécution. Les exécuteurs SPL suivront ensuite la politique décodeur maximal → matérialisateurs → exécuteur limité par opération.

0.4.2 — infrastructure d’exécution native et RPC Solana standard

Validation du jalon d’exécution native. kb_execution_api, kb_execution_safety, kb_execution_solana, kb_wallet, kb_executor_solana_core, kb_rpc et kb_pipeline séparent explicitement intent, plan, politique, lecture stateful, simulation, signature, envoi, confirmation et validation post-exécution. Le wallet temporaire de laboratoire reste confiné à Localnet/Devnet ; dry-run et simulation sont obligatoires par défaut, les plafonds de dépense/frais sont vérifiés et Mainnet reste désactivé sans politique et confirmation explicites.

kb_executor_solana_core couvre 18 surfaces natives avec 109 opérations appelables : System, Compute Budget, Address Lookup Table, précompiles Ed25519/secp256k1/secp256r1, Config, Feature, Slashing, ZK ElGamal, Stake, Vote, Loader v3 et Loader v4. BPF Loader v1/v2, Native Loader et l’ancien ZK Token Proof sont classés sans builder client ; Stake Redelegate reste historique decode-only. Chaque builder est comparé à un encodeur officiel ou à un layout wire audité. La matrice docs/NATIVE_SOLANA_EXECUTION_MATRIX.json est vérifiée par un test Rust contre les 109 codes compilés. kb_decoder_solana_core conserve l’égalité exacte avec les 18 Program IDs natifs et 121 déclarations de couverture.

Le préflight stateful de kb_pipeline inspecte ALT, Config, Feature, Slashing et les contextes ZK ElGamal sur Localnet/Devnet et retourne NotRequired, Ready ou Blocked. Les opérations administratives non validées réellement par un scénario cluster restent derrière ce garde-fou, hors de l’UI et sans activation Mainnet. Le parcours Devnet représentatif System transfer a été validé avec un wallet persistant préfinancé et 1 000 000 lamports : simulation exacte, signature, envoi, confirmation, getTransaction, insertion canonique, extraction core et decode replay ciblé ont réussi.

kb_rpc expose des contrats propres et configurables pour les 52 méthodes HTTP standard et les neuf paires WebSocket standard. Les options sont composables sans exposer les DTO Agave. WsSession gère multiplexage, unsubscribe, timeout, reconnexion bornée et réabonnement. blockSubscribe, slotsUpdatesSubscribe et voteSubscribe sont activables par endpoint ; un rejet serveur indiquant une méthode absente ou non activée désactive automatiquement la capacité pour la session. kb_app_demo ne contient plus la boucle de transport WebSocket.

La frontière Tauri/TS-rs a été corrigée pour ne plus transmettre de bigint dans les payloads JSON actifs. Les identifiants WebSocket sont contrôlés contre Number.isSafeInteger et les limites du navigateur SQL sont validées avant l’invocation backend. Les logs réels confirment les souscriptions/désabonnements WebSocket et le garde-fou de changement d’endpoint avec session active.

Validation finale fournie par l’utilisateur : kb_program_ids 5 tests, kb_decoder_solana_core 116, kb_executor_solana_core 88, kb_execution_api 22, kb_execution_safety 15, kb_execution_solana 12, kb_rpc 113, kb_pipeline 56, kb_config 41, kb_app_demo 88 et kb_store_pg 45 avec PostgreSQL réel. Le test Devnet opt-in et le replay post-exécution sont réussis, cargo clippy --all-targets est propre et cargo tauri dev démarre avec Vite et initialise correctement PostgreSQL. Aucun jalon suivant n’est ouvert par cette clôture.

0.4.3 — SPL Memo v1, v3 et v4

Validation complète de la surface SPL Memo. kb_decoder_spl_memo reconnaît exactement les Program IDs v1, v3 et v4, décode le payload UTF-8 brut, sa longueur et son SHA-256, conserve les comptes ordonnés et leurs flags, distingue les règles historiques de signataires, les chemins outer/inner, les transactions réussies ou échouées et les tentatives invalides sans produire de faux état commité. La matrice machine-readable docs/SPL_MEMO_MATRIX.json relie les contrats officiels, les fixtures synthétiques et le corpus Mainnet réel des trois générations.

kb_materializer_transaction_annotations projette uniquement les Memo réussis et commités dans la famille transaction_annotation, avec texte borné, génération, Program ID, signataires vérifiés, provenance et clé d’idempotence. Les comptes complets et diagnostics d’audit restent dans le decode. La persistance réutilise kb_sol_mat_events et le ledger commun sans nouvelle table ; demo_decode_replay expose un journal typé et borné filtrable par signature.

kb_executor_spl_memo fournit les intents typés v1/v3/v4 et construit les trois générations avec spl-memo-interface 2.1.0, payload exact et signataires readonly ordonnés. La bibliothèque reste universelle sur les clusters ; simulation obligatoire, dry-run par défaut, plafond de frais, autorisation opérateur et politiques Mainnet appartiennent à l’infrastructure commune. Le parcours Memo v4 Devnet réutilise wallet, RPC, safety, transaction Solana, confirmation, hydratation canonique, extraction core et decode replay. Trois transactions réelles ont chacune produit une annotation et un second replay idempotent skipped.

La clôture utilisateur confirme : kb_program_ids 5 tests, kb_decoder_spl_memo 9, kb_materializer_transaction_annotations 7, kb_executor_spl_memo 15, kb_execution_api 22, kb_execution_safety 15, kb_execution_solana 12, kb_pipeline 61, kb_rpc 113, kb_app_demo 96 et kb_store_pg 46 avec PostgreSQL réel. Le test opt-in Devnet avec envoi est réussi et cargo clippy --all-targets est propre. La suite active devient 0.4.4 — SPL Token selon prompts/023_v0_4_4_spl_token.md; l’acquisition historique différée reste hors ROADMAP actif.

0.4.4 — SPL Token classique

Validation complète du programme SPL Token classique Tokenkeg.... kb_decoder_spl_token reconnaît exactement les 28 tags publiés par spl-token-interface 3.0.0, conserve le wire borné, les comptes ordonnés, outer/inner paths, autorités simples ou multisig, montants bruts, decimals, transactions échouées non commitées et diagnostics sans inventer mint ni état final. Batch conserve son parent et ses enfants déterministes sans accepter les batchs imbriqués. La matrice docs/SPL_TOKEN_MATRIX.json relie interface, processor, builders, corpus et preuves cluster.

Les projections stables produisent des événements instructionnels token_account, admin et risk, sans fee classique fictive, sans OHLC et sans snapshot final reconstruit. Le replay Mainnet de 370 instructions a produit 371 sorties, huit refus correspondant exactement à huit transactions échouées, puis un second replay idempotent sans nouvelle sortie. Le journal Tauri expose des filtres bornés par signature, mint, compte, famille et opération, avec montants JSON sans perte.

kb_executor_spl_token expose 24 opérations typées courantes ou récentes et laisse les quatre initialisations Rent obsolètes en decode-only. Le préflight stateful Localnet/Devnet valide layouts, relations mint/comptes, soldes, native reserve, délégations, autorités, multisig et rent hors du décodeur et de l'exécuteur. Le parcours Devnet TransferChecked a réussi simulation, envoi, confirmation, hydratation, extraction, replay, matérialisation et second replay idempotent. Un lifecycle contrôlé sans ATA a ensuite initialisé mint et comptes, minté, transféré, approuvé, révoqué, brûlé puis fermé les comptes avec récupération sûre après interruption RPC.

Les tags récents Batch et UnwrapLamports ont été simulés avec succès sur le programme classique Devnet, sans signature ni envoi, respectivement en 270 et 140 compute units. La clôture Tauri charge 77 routes de logs, réussit le préflight et la simulation TransferChecked, bloque l'envoi sans confirmation, affiche la matérialisation commitée exacte et simule Memo v4 sans erreur runtime.

La régression finale communiquée confirme notamment : kb_program_ids 5 tests, kb_decoder_spl_token 8, kb_executor_spl_token 15, kb_decoder_spl_memo 9, kb_materializer_transaction_annotations 7, kb_execution_api 22, kb_execution_safety 15, kb_execution_solana 12, kb_pipeline 81, kb_rpc 113, kb_config 41, kb_app_demo 102 et kb_store_pg 46 avec PostgreSQL réel. cargo clippy --all-targets est propre. La suite active devient 0.4.5 — SPL Associated Token Account selon prompts/024_v0_4_5_spl_associated_token_account.md.

0.4.5 — SPL Associated Token Account

Validation complète du programme SPL Associated Token Account ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL. Le décodeur consomme spl-associated-token-account-interface 2.0.0, reconnaît exactement Create, CreateIdempotent, RecoverNested et la forme historique vide de Create, puis conserve comptes ordonnés, flags, doublons, chemins outer/inner, transactions échouées et diagnostics bornés. Les adresses observées sont comparées aux PDA canoniques dérivés depuis wallet, Token Program ID et mint ; une incohérence reste décodable et n'est jamais corrigée silencieusement.

kb_materializer_token_accounts possède exclusivement le lifecycle de l'adresse associée : créée, créée ou réutilisée idempotemment, ou récupérée depuis une imbrication. kb_materializer_risk possède le constat distinct d'anti-pattern nested récupéré, sans score arbitraire. Les CPI SPL Token restent propriétaires des initialisations, transferts et fermetures, et les matérialiseurs lifecycle général, admin et fees ne produisent aucun doublon. Les transactions non commitées ou invalides sont refusées comme mutations.

kb_executor_spl_associated_token_account expose les trois variantes actuelles pour SPL Token classique et Token-2022 avec les builders officiels, metas dans l'ordre exact, signataires uniques, simulation obligatoire, dry-run par défaut et coûts rent/frais plafonnés. Le pipeline stateful contrôle mints, owners, Program IDs, dérivations, comptes existants, rent, signataires et postconditions avant et après l'exécution. La fenêtre Tauri Solana existante ajoute création ATA, dérivation readonly et journal lifecycle borné ; RecoverNested reste volontairement hors UI.

Les scénarios Devnet contrôlés du 16 juillet 2026 ont validé la création et la réutilisation idempotente d'ATA classiques et Token-2022, puis un RecoverNested classique transférant 1 000 000 000 unités brutes vers l'ATA wallet et fermant le nested ATA. Chaque envoi a suivi simulation, confirmation, hydratation canonique, extraction, decode, matérialisation et second replay idempotent. L'ATA Token-2022 observé mesure 170 octets et expose ImmutableOwner, sans que le jalon ne commence le décodage général de ses extensions.

La clôture confirme 5 tests Program IDs, 8 tests décodeur Token classique, 15 tests exécuteur Token, 9 tests Memo, 7 tests annotations, 9 tests matérialiseur token accounts, 6 tests risk, 17 tests lifecycle, 9 tests admin, 3 tests fees, 10 tests décodeur ATA, 10 tests exécuteur ATA, 22 tests API d'exécution, 15 tests safety, 12 tests transaction Solana, 90 tests pipeline, 113 tests RPC, 41 tests configuration, 111 tests démo et 46 tests PostgreSQL réels. cargo clippy --all-targets est propre et cargo tauri dev -c kb_app_demo/tauri.conf.json a démarré Vite, Tauri et PostgreSQL. La suite active devient 0.4.6 — Token-2022, extensions et registre ElGamal selon prompts/025_v0_4_6_spl_token_2022.md.

0.4.6 — Token-2022, extensions et registre ElGamal

Validation du jalon Token-2022 et ElGamal Registry avec frontières techniques séparées. Token-2022 couvre les instructions de base, les familles d’extensions identifiables, les états Mint/Account/Multisig et TLV, les metadata/group incorporés, les parcours confidentiels, les matérialisations propriétaires et les exécuteurs simulation-first avec préflights stateful et preuves inline/context-state. Huit opérations publiques Token-2022 ont été confirmées sur Devnet, hydratées, extraites, décodées, matérialisées et rejouées idempotemment. Le corpus Mainnet contient 55 instructions Token-2022 décodées sans échec. Le registre ElGamal dispose de son décodeur, de sa matrice, de son parser d’état de 64 octets, de sa matérialisation administrative, de ses builders CreateRegistry/UpdateRegistry, de son PDA, de ses préflights et de son orchestration de preuves. La validation réseau publique reste indisponible sur Devnet/Mainnet au 20 juillet 2026 ; la validation synthétique/offline est conservée sans inventer de preuve cluster. La validation Mainnet a corrigé le wire Write du loader immuable : longueur u32 et données à l’offset 12, supprimant 68 diagnostics loader_vector_length_mismatch. Les 76 rejets restants sont tous issus de transactions Solana échouées et restent explicitement fail-closed ; quatre tags Loader v4 inconnus sont classés Unsupported. Un timeout ponctuel du pool PostgreSQL a été réparé par replay ciblé. Le replay de kb_app_demo ajoute incomplete_signatures, qui sélectionne seulement les signatures contenant une instruction pending, failed, replay_requested ou unsupported, limite d’abord les signatures puis étend leurs instructions compatibles sans force replay global. Deux campagnes PostgreSQL réelles ont produit le même résultat : 81 entrées, 1 décodée, 4 unsupported, 76 failed, aucun unmatched et aucun doublon decode/mat. Validation finale : kb_store_core 41/41, kb_store_pg 46/46 avec PostgreSQL réel, kb_pipeline 124/124, kb_app_demo 118/118 et cargo clippy --all-targets propre. La suite active devient 0.4.7 — Metaplex Token Metadata selon prompts/026_v0_4_7_metaplex_token_metadata.md. Anchor n’étant pas requis par les programmes SPL de 0.4.x, son infrastructure commune est planifiée en 0.4.18, immédiatement avant Meteora.