khadhroony-bot3/olddocs/archivekbot2/ROADMAP.md

Roadmap

Ce fichier contient les changements futurs et le phasage prévu. Il ne remplace pas le changelog : le changelog ne reçoit que les versions validées.

Version 0.0.x — stabilisation du squelette

• Réserver les crates core, décodeurs, matérialisateurs, exécuteurs et applications.
• Valider que le workspace compile après ajout de la couche d'exécution.
• Conserver CHANGELOG.md pour les versions validées uniquement.
• Réserver prompts/ pour les futures sessions ChatGPT par version.
• Documenter les objectifs court terme et long terme.
• Ajouter kb_config et config/example.config.json comme base de configuration.
• Ajouter les surfaces Bags Fee Share V1/V2 confirmées.
• Définir le format obligatoire des zips delta ChatGPT.
• Mettre à jour CHANGELOG.md pour 0.0.1 et 0.0.2.
• Exécuter cargo build.
• Exécuter cargo test --workspace.
• Exécuter cargo clippy --workspace --all-targets.
• Faire le commit v0.0.2 comme squelette stabilisé.

Version 0.1.x — logging et configuration

0.1.0 — kb_logging

• Finaliser l'API publique minimale de kb_logging.
• Définir les routes de logs console, fichier humain, fichier JSON et fichier erreurs.
• Router les logs vers console, fichier humain, fichier JSON et fichier erreurs.
• Gérer les niveaux par target et par sortie.
• Conserver le nettoyage ANSI des fichiers via writer dédié pour les messages issus de WebView Tauri.
• Ajouter la normalisation des globs crate::* en plus des globs crate.*.
• Ajouter les tests unitaires de configuration des targets et expressions de filtres.
• Ajouter les tests unitaires de sélection des routes console, fichier humain, fichier JSON et fichier erreurs.
• Ajouter les tests unitaires du writer sans ANSI.
• Valider localement cargo test -p kb_logging : 14 tests passés.
• Valider localement cargo clippy -p kb_logging --all-targets.
• Reporter 0.1.0 dans CHANGELOG.md après validation.

0.1.1 — kb_config

• Finaliser les structures typées de configuration.
• Normaliser les exports TS-rs avec export_to = "../frontend/ts/bindings/kb_config/settings/*.ts".
• Charger un fichier JSON avec plusieurs profils.
• Garantir un seul profil actif.
• Ajouter config/schema.config.json.
• Valider le JSON brut via jsonschema.
• Valider les profils absents, dupliqués ou incohérents.
• Exclure du schéma les transports avancés hors périmètre avant v1.x.
• Conserver les placeholders de clés directement dans les URLs.
• Supprimer ProfileConfig.enabled : active_profile est l’unique sélection de profil.
• Retirer data.idls_directory du contrat runtime : les IDLs restent des artefacts de développement.
• Conserver kb_core comme dépendance anticipée pour les erreurs communes workspace.
• Valider config/example.config.json.
• Ajouter les tests de parsing, validation et sérialisation.
• Valider localement cargo test --tests -p kb_config : 35 tests passés.
• Valider localement cargo clippy -p kb_config --all-targets.
• Reporter 0.1.1 dans CHANGELOG.md après validation.

0.1.2 — liaison kb_logging, kb_config et démo Tauri

• Initialiser kb_logging depuis le profil actif.
• Appliquer les niveaux, formats et chemins de fichiers depuis la configuration.
• Vérifier la création des fichiers de logs configurés et conserver la rotation comme amélioration future.
• Conserver main.html comme fenêtre d'accueil.
• Rendre le README workspace en HTML dans la fenêtre main sans afficher les commentaires de métadonnées file/version.
• Ajouter dans main.html un dropdown vers les fenêtres de démonstration.
• Créer kb_app_demo/src/demo_config.rs comme fenêtre de démo uniquement.
• Créer kb_app_demo/frontend/demo_config.html.
• Créer kb_app_demo/frontend/ts/demo_config.ts.
• Réutiliser le même format visuel que la fenêtre principale.
• Afficher le profil actif, la configuration complète et le schéma JSON.
• Ajouter un viewer JSON interactif pour le profil actif, la configuration complète et le schéma JSON.
• Désactiver le toolbar natif du viewer JSON pour éviter les boutons d’indentation non configurables.
• Exporter DemoConfigPayload via TS-rs et l'importer côté TypeScript.
• Déclarer demo_config dans capabilities/default.json et vite.config.ts, puis créer la fenêtre à la demande depuis Rust pour éviter une fenêtre cachée bloquante.
• Corriger la fermeture de l’application lorsque demo_config n’a jamais été ouverte.
• Ajouter un pont emit_frontend_log pour réémettre les logs WebView avec des targets tracing statiques.
• Router kb_app_demo.frontend::* dans la console et le fichier debug de kb_app_demo.
• Ajouter AppState comme état applicatif global dans kb_app_demo/src/app_state.rs.
• Retirer l’initialisation runtime globale de demo_config, qui reste une simple fenêtre de démo.
• Ajouter un verrou mono-instance uniquement dans kb_app_demo/src/main.rs, non appliqué à kb_app_demo_lib::run() pour préserver l’entrée mobile.
• Déplacer l’installation du provider Rustls par défaut dans kb_app_demo_lib::run() pour desktop et mobile.
• Ajouter un splashscreen avec fade-in/fade-out et durée minimale extensible pour les vérifications longues futures.
• Aligner le branchement du splashscreen dans tauri_builder.setup sur le modèle de khadhroony-bobobot/kb_demo_app.
• Corriger SplashOrder.duration_ms en u32 pour éviter un type BigInt côté TypeScript.
• Corriger l’animation du splash avec requestAnimationFrame, une opacité initiale explicite et une attente initiale de 1500 ms avant fade-in.
• Valider visuellement le fade-in/fade-out dans cargo tauri dev.
• Valider localement cargo test -p kb_core : 2 tests passés.
• Valider localement cargo test -p kb_config : 35 tests passés.
• Valider localement cargo test -p kb_logging : 14 tests passés.
• Valider localement cargo test -p kb_app_demo : 12 tests passés.
• Valider localement cargo clippy --all-targets.
• Valider localement cargo tauri dev -c kb_app_demo/tauri.conf.json depuis la racine du workspace.
• Reporter 0.1.2 dans CHANGELOG.md après validation.

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

• Explorer khadhroony-bobobot/kb_lib et les anciennes démos HTTP/WS comme source d'adaptation.
• Remonter depuis 0.3.x les points déjà nécessaires : réutilisation des pools HTTP/WS validés et finalisation initiale de kb_rpc.
• Ajouter les contrats JSON-RPC 2.0 partagés entre HTTP et WebSocket.
• Créer ou finaliser le client HTTP JSON-RPC Solana standard dans kb_rpc.
• Créer ou finaliser le client WebSocket Solana standard court dans kb_rpc.
• Ajouter la gestion de pool HTTP par rôle d'endpoint.
• Ajouter la gestion de pool WebSocket par rôle d'endpoint.
• Finaliser le premier modèle de rôles d'endpoints exploitable par les pools.
• Associer chaque rôle à un ou plusieurs types de requêtes via request_kinds.
• Router les requêtes HTTP et les requêtes WebSocket par rôle.
• Préparer les contrats nécessaires aux futurs pools HTTP et WebSocket persistants.
• Ajouter une fenêtre de démo HTTP JSON-RPC dédiée dans kb_app_demo.
• Ajouter une fenêtre de démo WebSocket dédiée dans kb_app_demo.
• Remplacer les champs libres role/method des démos HTTP/WS par des listes contrôlées issues de la config et des méthodes supportées.
• Ajouter une connexion/déconnexion explicite dans demo_ws.
• Réutiliser la même connexion WebSocket pour plusieurs souscriptions tant que l’endpoint sélectionné reste identique.
• Conserver la connexion WebSocket dans AppState quand la fenêtre demo_ws est fermée puis recréée.
• Ne plus déconnecter automatiquement demo_ws à la fermeture de la fenêtre ; réserver la fermeture au bouton déconnecter ou à l’arrêt global de l’application.
• Remplacer l’affichage JSON échappé des démos par des zones texte readonly avec bouton de copie.
• Ajouter le refresh explicite des pools HTTP/WS depuis les fenêtres de démo.
• Ajouter un profil mainnet Helius avec les paramètres issus de l’ancien config.json fourni.
• Élargir les listes de méthodes HTTP/WS de démonstration aux commandes Solana standard courantes.
• Ajouter un champ Params JSON complet à la démo HTTP pour tester les méthodes multi-paramètres.
• Ajouter l’unsubscribe explicite d’une subscription WebSocket sélectionnée sans fermer la socket persistante.
• Ajouter une limitation côté Rust des notifications WebSocket envoyées à la WebView pour éviter le gel sur les subscriptions très bavardes.
• Borner côté TypeScript l'historique affiché dans demo_ws.
• Ajouter les tests unitaires offline de kb_rpc pour JSON-RPC, rôles, endpoints désactivés, snapshots, round-robin HTTP/WS et génération d’IDs.
• Ajouter les liens correspondants dans le dropdown de la fenêtre principale.
• Conserver les démos dans des fichiers Rust, HTML et TypeScript séparés comme dans khadhroony-bobobot/kb_demo_app.
• Confirmer que gRPC, Helius enhanced WebSocket, Helius gRPC et LaserStream restent hors scope avant v1.x ou v2.x.
• Reporter vers les versions RPC ultérieures les wrappers métier spécialisés HTTP/WS à partir des commandes RPC déjà couvertes dans khadhroony-bobobot.
• Conserver les limites comme contrat de configuration et reporter vers 0.4.x leur enforcement runtime par token bucket et pause 429.
• Reporter vers 0.7.x la généralisation des clients WebSocket persistants de production avec registry, unsubscribe contrôlé et relay d'événements durables.
• Valider localement cargo test -p kb_rpc : 39 tests passés.
• Valider localement cargo test -p kb_app_demo : 28 tests passés.
• Valider localement cargo clippy --all-targets.
• Valider visuellement demo_http dans cargo tauri dev -c kb_app_demo/tauri.conf.json.
• Valider visuellement demo_ws dans cargo tauri dev -c kb_app_demo/tauri.conf.json.
• Valider que le pool HTTP alterne entre endpoints compatibles avec le profil mainnet_research.
• Valider que programSubscribe très bavard reste utilisable grâce au throttling UI et que l’unsubscribe fonctionne.
• Reporter 0.1.3 dans CHANGELOG.md après validation.

Version 0.2.x — SQL, stockage et conventions DB

0.2.0 — conventions storage, préfixes et contrats

• Auditer les crates existantes concernées par le stockage : kb_store_core, kb_store_pg, kb_config, kb_core, kb_app_demo et, si nécessaire seulement, kb_rpc.
• Définir le rôle exact de chaque crate touchée avant d'ajouter des migrations ou des requêtes.
• Valider que PostgreSQL utilise le schema courant/default, généralement public, sans schemas applicatifs explicites.
• Valider le préfixe de table kb_sol_<domain>_<name> pour les tables Solana du nouveau projet.
• Définir les domaines intégrés au nom de table : raw, core, obs, decode, mat, catalog, agg, ops, wallet.
• Documenter les tables candidates initiales sans les implémenter toutes immédiatement.
• Utiliser uniquement des noms de tables sans préfixe de schema explicite, par exemple kb_sol_raw_rpc_transactions, kb_sol_core_transactions, kb_sol_obs_program_observations, kb_sol_decode_decoded_events, kb_sol_mat_trade_events, kb_sol_catalog_tokens et kb_sol_ops_processing_ledger.
• Définir la séparation stricte entities/, dtos/, queries/, repositories/.
• Interdire les structures Rust dans queries/ : les structures appartiennent à entities/ ou dtos/.
• Définir la convention Entity comme représentation proche d'une ligne SQL.
• Définir la convention Dto comme contrat applicatif, Tauri ou repository.
• Définir la convention InsertDto / UpsertDto pour les écritures.
• Définir les règles de nommage SQL : id, created_at, updated_at, slot, signature, program_id, raw_json, payload_json.
• Définir les contraintes minimales : clés primaires, index uniques, index par signature, slot, program id et temps d'insertion.
• Définir les migrations comme artefacts PostgreSQL versionnés dans kb_store_pg.
• Préparer la page Tauri future de diagnostic DB sans l'implémenter si le store n'est pas encore prêt.
• Mettre à jour kb_store_core/README.md avec les conventions validées.
• Mettre à jour kb_store_pg/README.md avec les conventions PostgreSQL validées.
• Mettre à jour ou créer un document de prompt pour ouvrir la suite 0.2.x.
• Neutraliser les migrations héritées qui créaient des schemas applicatifs ou des tables qualifiées comme raw DOT sol_transactions.
• Ne pas modifier CHANGELOG.md avant validation locale du jalon.

0.2.1 — kb_store_core contrats et types communs

• Créer les modules publics minimaux de kb_store_core sans dépendre de PostgreSQL.
• Ajouter les erreurs storage en s'appuyant sur kb_core::Error et kb_core::Result.
• Ajouter les types communs : pagination, tri, limites, healthcheck, statut migration.
• Ajouter les premiers DTO génériques : raw RPC transaction, raw WS notification, core transaction, core instruction.
• Ajouter les contrats core pour account keys, logs et balance changes extraits.
• Ajouter CoreInstructionReplayInput pour fournir aux décodeurs une instruction avec contexte extrait.
• Ajouter les contrats de cycle de vie raw : état de rétention, état de traitement et mark lifecycle.
• Ajouter les contrats de replay par instruction : état instruction, filtre de replay et lifecycle mark.
• Ajouter les premiers traits repository sans implémentation SQL.
• Étendre les repositories pour préparer la sélection des instructions non traitées.
• Ajouter tests unitaires offline pour pagination, validation DTO et erreurs.
• Documenter le cycle de vie raw et la future compaction/purge sans l'activer.
• Documenter le split core des instructions, logs, account keys et balances avant les migrations.
• Valider localement cargo test -p kb_store_core : 28 tests passés.
• Valider localement cargo clippy --all-targets sans avertissement.
• Reporter 0.2.1 dans CHANGELOG.md après validation locale.

0.2.2 — kb_store_pg connexion PostgreSQL et migrations

• Ajouter la lecture effective de la configuration PostgreSQL depuis le profil actif.
• Créer les options de connexion PostgreSQL minimales dans kb_store_pg.
• Créer le pool PostgreSQL via sqlx::PgPool.
• Ajouter le masquage DSN pour les diagnostics.
• Ajouter un healthcheck PostgreSQL minimal basé sur SELECT 1.
• Lire le schema courant PostgreSQL via current_schema().
• Lire la version PostgreSQL pour les diagnostics.
• Ajouter une stratégie de migrations PostgreSQL explicite et non destructive.
• Ne pas créer de schemas PostgreSQL applicatifs ; utiliser le schema par défaut du profil, généralement public.
• Valider les noms de tables kb_sol_<domain>_<name> et refuser les schemas explicites.
• Ajouter des tests offline pour options, masquage DSN et validation des noms de tables.
• Ajouter un test PostgreSQL réel optionnel contrôlé par KB_POSTGRES_TEST_URL.
• Valider localement cargo test -p kb_store_pg : 11 tests passés.
• Valider localement le test PostgreSQL réel optionnel optional_postgres_healthcheck_from_env avec postgres://solana:solana@localhost:5432/solana.
• Valider localement cargo test -p kb_store_core : 28 tests passés.
• Valider localement cargo test -p kb_config : 35 tests passés.
• Valider localement cargo test -p kb_app_demo : 28 tests passés.
• Valider localement cargo clippy --all-targets sans avertissement après correction de l'exception async_trait / clippy::implicit_return.
• Reporter 0.2.2 dans CHANGELOG.md après validation.

0.2.3 — raw store Solana minimal

• Créer kb_sol_raw_rpc_transactions pour stocker le raw RPC immuable.
• Créer kb_sol_raw_ws_notifications pour stocker les notifications WebSocket brutes utiles.
• Prévoir notification_key, signature optionnelle et lien optionnel vers la transaction RPC canonique.
• Créer les queries et repositories PostgreSQL associés aux DTOs 0.2.1.
• Ajouter insert idempotent par signature pour les transactions raw.
• Ajouter insert append-only dédupliqué par notification_key pour les notifications WS raw.
• Ajouter index minimaux par signature, slot, subscription kind, lien RPC et date d'insertion.
• Ajouter une initialisation idempotente PostgresStore::initialize_raw_store_schema().
• Préparer auto_initialize_schema pour appliquer le schéma raw minimal après connexion quand le profil le demande.
• Documenter que 0.2.3 ne purge pas encore physiquement raw_json.
• Valider localement cargo test -p kb_store_pg : 21 tests passés.
• Valider localement le test PostgreSQL réel optionnel optional_postgres_raw_store_roundtrip_from_env avec KB_POSTGRES_TEST_URL=postgres://solana:solana@localhost:5432/solana.
• Valider localement cargo test -p kb_store_core : 28 tests passés.
• Valider localement cargo test -p kb_config : 35 tests passés.
• Valider localement cargo test -p kb_app_demo : 28 tests passés.
• Valider localement cargo clippy --all-targets sans avertissement.
• Reporter 0.2.3 dans CHANGELOG.md après validation.

0.2.4 — core Solana normalisé minimal

• 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.
• Construire CoreInstructionReplayInput depuis les tables core pour les décodeurs.
• Marquer les instructions insérées comme Pending pour permettre un replay instruction-level.
• Préparer le replay partiel par état, slot et program id via CoreInstructionReplayFilter.
• Ajouter une initialisation idempotente raw/core via PostgresStore::initialize_store_schema().
• Sérialiser l'initialisation raw/core par verrou PostgreSQL pg_advisory_xact_lock.
• Normaliser les noms de contraintes et d'index PostgreSQL avec les préfixes pk_, fk_, ck_, ux_ et ix_.
• Ajouter un script SQL de maintenance pour supprimer les tables raw/core dans l'ordre inverse des dépendances.
• Valider localement le script kb_store_pg/maintenance/drop_raw_core_store.sql sur la base PostgreSQL locale.
• Valider localement KB_POSTGRES_TEST_URL=postgres://solana:solana@localhost:5432/solana cargo test -p kb_store_pg -- --nocapture : 30 tests passés.
• Valider localement la création des 8 tables raw/core dans PostgreSQL.
• Valider localement cargo clippy --all-targets sans avertissement.
• Reporter le worker/extracteur raw RPC vers core vers les jalons d'ingestion/backfill, car 0.2.4 valide uniquement le stockage core et les inputs de replay.
• Reporter les observations minimales et le ledger ops vers un jalon dédié après stabilisation de l'extraction.
• Reporter l'extension du replay par module, version, signature, surface et discriminator après l'introduction des domaines decode et ops.
• Reporter 0.2.4 dans CHANGELOG.md après validation.

0.2.5 — diagnostics SQL dans kb_app_demo

• Ajouter demo_sql_diag pour le diagnostic PostgreSQL global : profil actif, backend, DSN masqué, schema courant, tables détectées, version migrations et healthcheck.
• Ajouter demo_sql_pg_raw pour les tables kb_sol_raw_rpc_transactions et kb_sol_raw_ws_notifications.
• Ajouter demo_sql_pg_core pour les tables core normalisées kb_sol_core_*.
• Ajouter les boutons de refresh read-only dans chaque fenêtre.
• Ajouter les liens dans le dropdown de la fenêtre principale.
• Tenter l'initialisation raw/core au démarrage Tauri quand database.postgres.auto_initialize_schema est actif.
• Afficher dans le splashscreen les tables créées, déjà présentes, manquantes ou en erreur, avec logs tracing associés.
• Remplacer les payloads JSON textuels des démos SQL par le viewer JSON interactif déjà utilisé par demo_config.
• Garantir que les démos SQL ne lancent ni extracteur, ni décodage, ni matérialisation.
• Documenter à l’époque que l’extracteur raw RPC vers core était reporté à 0.4.x; ce phasage historique est remplacé par le recadrage 0.3.x ci-dessous.
• Valider localement cargo test -p kb_store_pg : 30 tests passés.
• Valider localement cargo test -p kb_config : 35 tests passés.
• Valider localement cargo test -p kb_app_demo : 32 tests passés.
• Valider localement cargo clippy --all-targets sans avertissement.
• Valider visuellement demo_sql_diag, demo_sql_pg_raw et demo_sql_pg_core via cargo tauri dev -c kb_app_demo/tauri.conf.json.
• Reporter 0.2.5 dans CHANGELOG.md après validation.

Version 0.3.x — fondation transactionnelle canonique et backfill gratuit

0.3.0 reste le jalon historique de cadrage Agave local validé. Les essais matériels ont ensuite montré qu’un nœud Agave mainnet complet n’était pas une source légère adaptée à cette phase. 0.3.1 réoriente donc la série vers une transaction canonique indépendante de la source, des observations d’acquisition légères, le backfill HTTP gratuit et l’extraction core.

sources HTTP / WebSocket / gRPC
  -> adaptateur de source dans kb_rpc
    -> transaction Solana canonique indépendante du provider
      -> kb_sol_raw_transactions
        -> kb_sol_obs_transaction_observations
          -> extraction core
            -> décodeurs et matérialiseurs

Après validation réelle de la transition 0.2.x -> 0.3.1, les fichiers SQL ont été consolidés en une baseline propre avec 0001_canonical_transaction_store.sql et 0002_core_store.sql. 0.3.4 ajoute uniquement 0003_processing_ledger.sql; l’historique des anciennes tables reste dans le changelog et la documentation, pas dans le DDL actif.

0.3.0 — cadrage Agave local et sources temps réel — clôturé

• Documenter l’hypothèse d’un nœud Agave local non votant comme source temps réel.
• Préparer le profil manuel agave_local_research, les probes RPC/WS et les mesures de ressources.
• Conserver mainnet_research comme profil actif stable et ne lancer aucune ingestion de production.
• Valider localement le delta 0.3.0-pre.001 avant mise à jour du changelog.
• Mesurer l’impact réel du snapshot, d’AccountsDB, du ledger, de la RAM, du swap et du réseau.
• Abandonner temporairement Agave local et blockSubscribe comme axe actif à cause du coût matériel et opérationnel.
• Reporter les conclusions historiques dans CHANGELOG.md.

0.3.1 — transaction canonique et observations d’acquisition — clôturé

• Remplacer la cible kb_sol_raw_rpc_transactions par kb_sol_raw_transactions.
• Remplacer la cible kb_sol_raw_ws_notifications par kb_sol_obs_transaction_observations.
• Renommer raw_json en canonical_json et raw_json_hash en canonical_json_hash.
• Ajouter canonical_format_version.
• Renommer kb_sol_core_transactions.raw_rpc_transaction_id en raw_transaction_id.
• Stocker dans les observations uniquement la provenance, le protocole, la méthode, le commitment, la session, le filtre, les timestamps, la taille, les hashes techniques, les statuts et les erreurs.
• Interdire la duplication durable du payload complet dans les observations.
• Aligner DTOs, entities, repositories, requêtes, diagnostics SQL et démos Tauri.
• Valider manuellement la migration réelle depuis le schéma 0.2.x sur PostgreSQL 17.10.
• Vérifier l’absence de kb_sol_raw_rpc_transactions et kb_sol_raw_ws_notifications.
• Vérifier la présence de kb_sol_raw_transactions, kb_sol_obs_transaction_observations, canonical_json, canonical_json_hash, canonical_format_version et raw_transaction_id.
• Consolider les migrations SQL en deux fichiers ne contenant que les tables actives.
• Conserver temporairement dans le DDL runtime le chemin de compatibilité idempotent pour les workspaces encore en pre.001, sans recréer les anciennes tables.
• Valider cargo test -p kb_app_demo : 32 tests passés.
• Valider cargo test -p kb_store_core : 30 tests passés.
• Valider KB_POSTGRES_TEST_URL=postgres://solana:solana@localhost:5432/solana cargo test -p kb_store_pg -- --nocapture : 32 tests passés.
• Valider cargo clippy --all-targets sans avertissement.
• Valider le démarrage Tauri et les diagnostics des huit tables raw/obs/core.
• Nettoyer manuellement les fixtures PostgreSQL de test.
• Vérifier et rationaliser les prompts 0.3.x.
• Reporter 0.3.1 dans CHANGELOG.md.

0.3.2 — contrat canonique et adaptateur HTTP — clôturé

• Définir le type canonique dans kb_model et ses conversions explicites.
• Conserver les signatures et public keys en base58, les payloads d’instruction en base64 et les valeurs numériques sans perte.
• Inclure transaction legacy/v0, message header, static account keys, Address Lookup Tables, loaded addresses, outer instructions, inner instructions, logs, statut, erreurs, fee, compute units, cost units, balances SOL/SPL, rewards, return data et block time quand disponibles.
• Garantir une sérialisation déterministe pour canonical_json_hash avec tri récursif des objets JSON et SHA-256.
• Ajouter dans kb_rpc un adaptateur getTransaction JSON-RPC vers le modèle canonique.
• Définir une interface interne commune pour les futurs adaptateurs Helius WebSocket et Yellowstone gRPC, sans créer de crate séparée.
• Ajouter des fixtures offline legacy et v0, succès et échec, ALT, CPI, Token et Token-2022.
• Tester l’idempotence : une même transaction provenant de plusieurs réponses HTTP doit produire le même hash canonique.
• Valider cargo test -p kb_model : 23 tests passés.
• Valider cargo test -p kb_rpc : 48 tests passés.
• Valider cargo test -p kb_store_core : 31 tests passés.
• Valider KB_POSTGRES_TEST_URL=postgres://solana:solana@localhost:5432/solana cargo test -p kb_store_pg -- --nocapture : 32 tests passés avec roundtrip PostgreSQL réel.
• Ajouter les retours explicites requis dans kb_model/src/canonical_transaction.rs, kb_rpc/src/get_transaction.rs et kb_store_core/src/dtos/raw_dtos.rs.
• Valider cargo clippy --all-targets sans avertissement.
• Nettoyer manuellement les fixtures PostgreSQL après validation.
• Reporter 0.3.2 dans CHANGELOG.md après validation.

0.3.3 — backfill HTTP sur comptes gratuits — clôturé

• Ajouter getSignaturesForAddress paginé avec before, until, limite, curseur de reprise et borne max_pages.
• Ajouter le backfill d’une liste explicite de signatures séparées par des retours à la ligne.
• Ajouter les campagnes avant/après une signature pour un programme, un token et un pool.
• Hydrater chaque signature avec getTransaction via les pools HTTP existants.
• Appliquer le débit, la concurrence et la pause 429 depuis le rôle configuré, avec retries bornés.
• Écrire une seule ligne canonique par signature dans kb_sol_raw_transactions.
• Écrire une observation légère par tentative getTransaction dans kb_sol_obs_transaction_observations.
• Conserver les statuts missing et failed sans créer de faux payload canonique.
• Ignorer avant hydratation les signatures déjà présentes dans le store canonique.
• Ajouter demo_backfill avec accordéons Bootstrap 5, journal, résumé et arrêt coopératif.
• Corriger le parcours after avec la borne RPC until, la pagination before, des pages de 1 000 et une sélection bornée des signatures les plus proches de l’ancre.
• Documenter le fonctionnement dans docs/BACKFILL_HTTP.md.
• Valider cargo test -p kb_rpc : 54 tests passés.
• Valider cargo test -p kb_pipeline : 10 tests passés après le correctif final d’arrêt/reprise.
• Valider cargo test -p kb_store_core : 31 tests passés.
• Valider cargo test -p kb_store_pg : 32 tests passés.
• Valider cargo test -p kb_app_demo et les exports TS-rs : 38 tests passés.
• Valider cargo clippy --all-targets sans avertissement.
• Valider visuellement les modes signatures explicites, programme avant/après, token avant/après et pool avant/après dans Tauri.
• Valider le parcours profond program_after : 5 516 signatures indexées parcourues pour sélectionner et hydrater les 5 signatures directement postérieures à l’ancre.
• Valider la persistance PostgreSQL réelle : 62 transactions canoniques et 62 observations, sans ligne core avant 0.3.4.
• Détecter l’arrêt opérateur pendant une campagne de 500 candidats et confirmer l’interruption des nouveaux appels getTransaction.
• Remplacer la création globale des futures par une file d’exécution bornée à la concurrence effective.
• Séparer candidates_started, candidates_completed, candidates_cancelled et candidates_not_started.
• Calculer le curseur de reprise before depuis le dernier préfixe contigu réellement terminé.
• Valider localement le correctif 0.3.3-pre.004 avec cargo test -p kb_pipeline, cargo test -p kb_app_demo et cargo clippy --all-targets.
• Rejouer l’arrêt d’une campagne de 500 candidats et vérifier qu’aucun candidat non démarré n’est journalisé comme traité : 7 démarrés, 3 terminés, 4 annulés et 493 non démarrés.
• Reporter la validation finale de 0.3.3 dans CHANGELOG.md.

0.3.4 — extraction transaction canonique vers core et clôture 0.3.x — clôturé

• Ajouter le worker kb_sol_raw_transactions -> kb_sol_core_* dans kb_pipeline.
• Résoudre les account keys statiques et les loaded addresses dans un ordre canonique unique.
• Extraire outer instructions, inner instructions, logs, balances, statut et contexte transactionnel.
• Conserver des hashes déterministes pour les payloads d’instruction et le texte des logs.
• Garantir l’idempotence par signature, indices stables et instruction path.
• Ajouter le ledger kb_sol_ops_processing_ledger pour l’extracteur et ses versions.
• Persister le graphe core, l’état raw et le succès ledger dans une transaction PostgreSQL unique.
• Permettre le replay par signature, lot pending, plage de slots et program id déjà indexé.
• Ajouter le mode normal, le force replay, la concurrence bornée et l’arrêt coopératif.
• Ajouter demo_core_extraction avec accordéons Bootstrap 5, journal et résumé JSON.
• Ajouter demo_sql_replay_candidates avec cinq tableaux read-only : transactions, programmes, mints, owners et account keys.
• Ajouter les filtres PostgreSQL bornés par raw, ledger, slots, programme outer/inner/logs, mint, owner et account key.
• Ajouter sélection par checkbox, reset des filtres, copie individuelle/multiligne et export CSV natif.
• Écrire les CSV dans data/exports_csv/ avec BOM UTF-8, séparateur ;, CRLF et nom non écrasant.
• Valider l’écriture CSV native dans Tauri/Linux : replay_transactions.csv écrit dans le workspace.
• Ajouter un registre énumérable de 182 program IDs dans kb_program_ids et l’exposer à l’interface.
• Ajouter les requêtes SQL d’intégrité raw/core/ledger.
• Valider une extraction pending réelle : 70 extraites, 0 skip, 0 échec.
• Valider l’intégrité après extraction : aucun doublon, orphelin, hash incohérent, ledger incohérent ou chemin inner invalide.
• Valider le skip réel sur 14 signatures : 0 extraction, 14 skips.
• Valider le force replay réel sur les mêmes 14 signatures : 14 extractions, 0 skip, cardinalité core inchangée.
• Valider un second skip après force replay : 0 extraction, 14 skips.
• Confirmer le ledger réel : 70 lignes succeeded, 84 tentatives après le force replay.
• Ajouter un test PostgreSQL optionnel qui provoque une erreur intermédiaire, vérifie le rollback complet puis rejoue le bundle corrigé.
• Rendre annulables les appels getSignaturesForAddress, getTransaction, l’attente du pacer et les pauses de retry/429.
• Ajouter les tests offline d’annulation d’une opération longue et d’une pause de retry déjà annulée.
• Conserver les transactions Solana échouées dans core et les rendre éligibles au futur décodage comme observations d’intention/échec.
• Interdire aux futurs matérialiseurs d’interpréter automatiquement les événements d’une transaction échouée comme mutations d’état réussies.
• Fusionner l’ancien périmètre 0.3.5 dans 0.3.4; les corpus exhaustifs sont reportés aux versions protocolaires concernées.
• Considérer le sélecteur read-only, les requêtes d’intégrité et le replay core comme outils de clôture de la fondation.
• Valider cargo test -p kb_pipeline après l’ajout des tests d’annulation : 24 tests passés.
• Valider KB_POSTGRES_TEST_URL=... cargo test -p kb_store_pg -- --nocapture avec le test de rollback : 39 tests passés.
• Valider cargo clippy --all-targets sans avertissement.
• Reporter 0.3.4 dans CHANGELOG.md et basculer le jalon actif vers 0.4.0.

Les contrôles autrefois prévus dans 0.3.5 sont reclassés ainsi : la stabilité canonique entre formes fournisseur est déjà couverte par 0.3.2; le coût et les limites du backfill sont documentés par 0.3.3; les corpus exhaustifs Pump, Meteora, Raydium et Orca appartiennent à leurs versions protocolaires; le rejeu réel d’un curseur before reste un contrôle opératoire utile mais ne bloque pas l’infrastructure de décodage, car la frontière contiguë et l’arrêt réel ont déjà été validés.

Version 0.4.x — décodeurs et matérialisations Solana Core/SPL

0.4.0 — infrastructure de décodage core — clôturé

• Utiliser prompts/019_v0_4_0_decoder_infrastructure.md comme contrat de session.
• Stabiliser les API kb_decoder_api et kb_materializer_api sur les inputs core contextualisés.
• Ajouter le dispatch déterministe par program_id, surface, instruction path, payload/discriminator et contexte inner/logs.
• Ajouter le replay borné par signatures, slots, program IDs, instruction paths, processor/version/hash et force replay.
• Ajouter la persistance atomique des observations décodées, sorties matérialisées, couvertures et ledger.
• Ajouter la politique explicite pour les transactions on-chain échouées et le refus des mutations métier supposées réussies.
• Ajouter la matrice machine-readable déclarée/observée/reconnue/décodée/matérialisée/erreur, séparée par succès ou échec on-chain.
• Ajouter demo_decode_replay sans SQL libre, avec sélection, processors, concurrence, journal, arrêt et diagnostics.
• Ajouter le classifieur initial de toutes les surfaces natives connues sans faux décodage.
• Borner automatiquement la sélection SQL aux program IDs déclarés par les décodeurs activés et refuser les filtres incompatibles.
• Permettre au force replay borné par signatures de resoumettre les inputs quel que soit leur lifecycle courant.
• Ajouter l’autorisation explicite « toutes les signatures » bornée par les filtres et la limite.
• Refuser tout force replay sans signatures ni autorisation « toutes les signatures ».
• Désactiver/refuser la matérialisation lorsqu’aucun matérialiseur n’est enregistré.
• Corréler les traces par campaign_id, signature, instruction path, program ID et processor/version.
• Valider localement les champs obligatoires du backfill avant invocation Tauri.
• Ne plus réappliquer les DDL à chaque commande Tauri et synchroniser précisément les snapshots de couverture.
• Valider cargo test -p kb_config : 36 tests passés.
• Valider cargo test -p kb_pipeline : 41 tests passés.
• Valider PostgreSQL réel cargo test -p kb_store_pg -- --nocapture : 44 tests passés.
• Valider cargo test -p kb_app_demo : 75 tests passés.
• Valider cargo clippy --all-targets sans avertissement.
• Valider le build frontend de production avec (cd kb_app_demo && npm run build).
• Valider dans Tauri le skip version/hash, le force replay ciblé, le second skip, le replay global limité, l’annulation et le redémarrage.
• Corriger le résumé d’annulation afin que completed = started et started + not_started = selected.
• Valider la campagne finale : 382 sélectionnés, 45 démarrés/terminés, 337 non démarrés, aucun unmatched ni échec.
• Valider les diagnostics 0.4.0 : 18 déclarations alors exposées, 382 observations Compute Budget et 94 observations System reconnues sans erreur ; Stake Config a ensuite été reclassé, ramenant le registre exécutable à 17 surfaces dans pre.008.
• Reporter 0.4.0 dans CHANGELOG.md et basculer le jalon actif vers 0.4.1.

0.4.1 — programmes Solana natifs, loaders et précompiles — clôturé

• Utiliser prompts/020_v0_4_1_native_solana_programs.md comme contrat de session.
• Auditer l’état réel de kb_decoder_solana_core, des types decode, du store, de la couverture et de la démo avant modification.
• Vérifier chaque format d’instruction depuis les sources officielles actuelles ; ne jamais inventer un discriminant, un ordre de champs ou une sémantique.
• Définir une taxonomie stable des événements natifs et les types partagés nécessaires sans créer de dépendance vers PostgreSQL, RPC ou Tauri.
• Décoder maximalement system, y compris nonce accounts, seeds, allocate/assign, transfers et CreateAccountAllowPrefund, depuis solana-system-interface 3.2.0.
• Décoder maximalement compute_budget, y compris RequestUnitsDeprecated, le tag réservé actuel et les limites modernes de solana-compute-budget-interface 3.0.0 ; pre.011 reproduit aussi l’acceptation runtime des octets suffixes via Borsh unchecked et les conserve pour audit.
• Décoder maximalement address_lookup_table : create, freeze, extend, deactivate et close depuis solana-address-lookup-table-interface 3.1.0.
• Ajouter une matérialisation générique et idempotente du lifecycle ALT, limitée aux observations exactes, réussies et commitées.
• Valider ALT sur corpus mainnet réel : 104 instructions core, 104 inputs décodés, 104 sorties lifecycle, zéro échec ou unsupported.
• Décoder maximalement vote depuis solana-vote-interface ^6.0 avec serde + wincode : 20 variantes, autorisations, identité, commissions, withdraw, votes/state updates, formes compactes/tower, V2/BLS et récompenses délégateurs ; les deux collecteurs V2 proviennent des comptes d’instruction et non de VoteInitV2.
• Décoder maximalement stake dans pre.013 : 18 tags officiels, initialize/authorize/delegate/split/merge/withdraw/deactivate/lockup, variantes checked/seed, minimum delegation, deactivate delinquent, move stake/lamports et redelegate historique désactivé.
• Reclasser StakeConfig11111111111111111111111111111111 comme compte natif historique non exécutable et le retirer du dispatch/domaine d’exécution.
• Valider pre.013 sur le corpus Stake mainnet : 2 601/2 601 inputs décodés, zéro failed, unsupported ou unmatched, dont 339 instructions Stake réparties sur neuf entry codes observés.
• Décoder config comme une écriture générique ConfigKeys + payload opaque borné et feature comme revoke_pending_activation selon leurs interfaces officielles.
• Valider pre.008 par tests ciblés, PostgreSQL réel, Clippy et démarrage/replay Tauri : 476/476 décodés, aucun échec, unsupported ou unmatched.
• Valider Config sur corpus réel : 95 instructions décodées, zéro échec ou unsupported. Conserver Feature en validation synthétique faute d’invocation core observable dans les campagnes adressées.
• Valider Vote par tests ciblés et replay mainnet : 51 tests décodeur réussis, 500 instructions Vote réelles décodées, toutes tower_sync, zéro échec Vote ; les 20 variantes restent couvertes par fixtures wincode officielles.
• Valider pre.011 après correction Compute Budget : 52 tests natifs, Clippy propre et force replay mainnet de 1 265/1 265 inputs décodés, avec zéro failed, unsupported ou unmatched.
• Stabiliser dans pre.012 le tracing transversal avant de reprendre les décodeurs : target canonique égal au package Cargo, matrice globale et par crate, error.jsonl dédié, erreurs decode/materialize structurées et responsabilité laissée à la crate opérationnelle.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• Décoder dans pre.014 les précompiles ed25519, secp256k1 et secp256r1, y compris compteurs, tables d’offsets, références outer courantes/externes, recovery ID secp256k1 et payloads structurés bornés sans recalcul cryptographique.
• Conserver Memo hors périmètre natif et réserver kb_decoder_spl_memo pour ses générations v1, v3 et v4.
• Distinguer recognized, decoded, ignored, unsupported et failed sans convertir une reconnaissance partielle en succès de décodage ; l’audit pre.017 confirme les statuts terminaux séparés du pipeline et des observations.
• Conserver la politique des transactions échouées : événements d’intention/échec autorisés, mutations réussies interdites par défaut ; SuccessfulCommittedOnly protège toutes les projections lifecycle natives.
• Matérialiser les projections natives génériques déjà stabilisées : ALT, lifecycle loaders, révocation Feature, durable nonce, contextes ZK ElGamal et rapports Slashing. Ne pas les présenter comme la totalité des matérialisations natives possibles.
• Implémenter dans pre.017 les projections natives manquantes réellement justifiées : lifecycle des durable nonce accounts System et lifecycle des comptes de contexte ZK ElGamal, sans matérialiser les preuves.
• Concevoir dans pre.017 le contrat de kb_materializer_staking pour les projections Stake/Vote nécessitant un état durable : état précédent/suivant, délégation, désactivation, retrait, autorités, lockup, identité/commission Vote et récompenses ; ne pas les ajouter au matérialiseur générique.
• Ajouter dans pre.022 un profil Compute Budget transactionnel agrégé ; conserver les précompiles de signature et les preuves ZK sans contexte en decode/audit tant qu’aucun consommateur n’exige une projection dédiée.
• Documenter dans pre.019 l’audit complet des projections actives, différées et volontairement absentes dans docs/NATIVE_SOLANA_MATERIALIZATION_AUDIT.md.
• Couvrir chaque variante déclarée par des fixtures officielles, dérivées des encodeurs SDK ou explicitement alignées sur le wire runtime ; l’audit pre.018 inclut aussi les deux instructions Slashing.
• Clore l’inventaire corpus : ALT et Config validés réellement ; Feature, loaders v3/v4, Slashing et ZK Token Proof validés synthétiquement faute d’invocation observable ; campagne Slashing retournée proprement à zéro signature.
• Couvrir les payloads tronqués, discriminants inconnus, comptes invalides, offsets précompile invalides et transactions on-chain échouées sur toutes les surfaces dont le runtime expose ces cas.
• Ajouter dans pre.014 les fixtures adversariales des trois précompiles : références courantes, externes et mixtes, signatures multiples, messages vides/volumineux, headers/tables tronqués, compteurs invalides, index ou offsets hors bornes, Base64 absent/invalide, débordement borné et transaction échouée non commitée.
• Ajouter dans pre.001/pre.002 les fixtures officielles System/Compute Budget, les limites numériques, payloads tronqués, tags inconnus, comptes manquants, déterminisme et transactions échouées.
• Ajouter dans pre.003 ALT exact, la projection lifecycle ALT, les IDs SPL vérifiés et les crates réservées manquantes.
• Analyser le replay mainnet pre.004 : 476 inputs, 475 décodés, un faux échec System dû à un compte additionnel et 11 faux refus de matérialisation hors surface ALT.
• Corriger dans pre.005 le décodage System afin de conserver les comptes additionnels validement résolus avec le rôle additional_account.
• Ajouter dans pre.005 une sélection de matérialiseur par observation exacte, avant ledger et politique de transaction.
• Réserver les exécuteurs manquants pour Memo, Single Pool, Account Compression, Noop et SPL Name Service.
• Formaliser puis rendre obligatoire le contrat de tracing par crate dans docs/TRACING_CONTRACT.md.
• Valider pre.005 : cinq exécuteurs SPL réservés, 42 tests pipeline, 22 tests natifs, 4 tests lifecycle, 76 tests démo et clippy propre.
• Valider le force replay ciblé puis global : 3/3 et 476/476 décodés, zéro échec, unsupported, unmatched et refus de matérialisation.
• Ajouter dans pre.006 les loaders immuables v1/v2, le loader upgradeable, Loader v4, le classement Native Loader opaque et la projection lifecycle des loaders.
• Valider pre.006 : 31 tests natifs, 6 tests lifecycle, 42 tests pipeline, 76 tests démo, Clippy propre et replay global Tauri de 476/476 inputs sans échec, unsupported, unmatched ni refus de matérialisation.
• Rejouer System, Compute Budget et ALT sur le corpus PostgreSQL réel : campagne globale pre.005 de 476 inputs, 476 décodés, aucun failed, unsupported, unmatched ou faux refus de matérialisation.
• Valider pre.017 : 12 tests lifecycle, 42 tests pipeline, 45 tests PostgreSQL réel, 76 tests démo, Clippy propre, 484 instructions System décodées avec 27 sorties nonce et 27 refus attendus de transactions échouées, puis 151 instructions ZK ElGamal avec 139 sorties de contexte.
• Auditer Agave v4.1.1 et ajouter dans pre.018 le stateless Slashing Program absent du registre : deux instructions exactes, dispatch sans fallback, projection de rapport et absence explicite de pénalité appliquée par le programme.
• Ajouter des invariants automatiques garantissant une surface par ID natif, au moins une couverture par surface, des identités de couverture uniques et zéro fallback unclassified_native_instruction.
• Ajouter dans pre.019 les modes program_latest, token_latest et pool_latest : une recherche « avant, plus anciennes » sans ancre commence sur la page de signatures la plus récente ; la direction after conserve une ancre obligatoire.
• Retirer dans pre.019 solana-zk-token-sdk et sa dépendance transitive à bincode; conserver uniquement un miroir wire local audité des tags et tailles historiques.
• pre.020 : matérialiser System create/allocate/assign, les écritures Config, les changements d’autorité Loader et les mutations de bytecode Loader sans dupliquer les balances core ni les payloads complets.
• Activer kb_materializer_admin pour assign/assign_with_seed, Config store, Loader v3 set_authority/set_authority_checked et Loader v4 transfer_authority, avec politique SuccessfulCommittedOnly.
• Activer kb_materializer_compliance_audit pour les write Loader v1/v2/v3/v4 et copy Loader v4, en conservant uniquement comptes, offsets, tailles, SHA-256 et préfixes bornés.
• Enregistrer les trois matérialiseurs natifs dans demo_decode_replay et ajouter les routes debug/info/error.jsonl dédiées aux deux crates nouvellement opérationnelles.
• pre.021 : activer kb_materializer_staking pour les intentions/transitions commitées Stake/Vote, avec limites explicites sur l'absence de snapshots de comptes, et sérialiser les tests PostgreSQL réels pour éviter les interblocages intermittents.
• pre.022 : produire le profil Compute Budget transactionnel agrégé via kb_materializer_compliance_audit et confirmer la politique d'absence de projection pour signatures/ZK sans contexte.
• Clôturer 0.4.1 avec 18 surfaces natives, matérialisations instructionnelles stables, logs propres et prompt de reprise 0.4.2.
• pre.023 : replay global ciblé, validations finales, documentation de clôture, prompt 0.4.2 et mise à jour du CHANGELOG.md.
• Confirmer que les précompiles de signature, les preuves ZK sans contexte et l’ancien ZK Token Proof restent volontairement sans projection dédiée, hors contexte matérialisable.
• Ne pas étendre demo_decode_replay au-delà des matérialiseurs natifs enregistrés : inspection suffisante via résumés, couverture et requêtes SQL de validation.
• Valider les replays ciblés avec corrélation par campaign_id pour System, Config, Stake, Vote, Compute Budget, ALT, ZK ElGamal et les surfaces synthétiques sans corpus.
• Exécuter les tests unitaires des crates touchées, PostgreSQL réel, Clippy et campagnes Tauri/réelles avant mise à jour du changelog.
• Mettre à jour CHANGELOG.md uniquement après validation complète de 0.4.1.

0.4.2 — infrastructure d’exécution et kb_executor_solana_core — clôturée

Principes de portée

• Les crates d’exécution sont des bibliothèques universelles réutilisables par kb_app_demo, les workers, les CLI et de futurs exécutables non liés au trading.
• La dangerosité d’une opération ne justifie pas son absence du builder : elle doit être encodée, testée et protégée par une politique dédiée, puis éventuellement rester non exposée dans kb_app_demo.
• L’objectif est de couvrir toutes les instructions natives officiellement appelables. Unsupported(reason) ne doit subsister que pour une surface non invocable par transaction, retirée du runtime, insuffisamment documentée officiellement ou encore temporairement non implémentée avec dette explicite au ROADMAP.
• Les exécuteurs restent indépendants du wallet, du RPC, des décodeurs et de Tauri ; ils produisent des plans déterministes et laissent simulation, signature, envoi et validation à l’orchestration.

Tranches validées

• pre.001 : ajouter les contrats typés de capacité, politique, plan préparé, simulation contextualisée, envoi, confirmation et diagnostic post-exécution sans casser les exécuteurs réservés historiques.
• pre.001 : implémenter les builders officiels System transfer/create account/allocate/assign et Compute Budget set unit limit/set unit price.
• pre.001 : remplacer Maybe dans kb_executor_solana_core par Yes/No pour le pont historique et Supported/Unsupported(reason) pour la voie typée.
• pre.001 : ajouter les contrôles de plan et pré-envoi pour simulation obligatoire, dry-run, cluster, mainnet, blockhash/nonce, signataires et plafonds.
• pre.002 : aligner le registre de l’exécuteur sur les dix-huit surfaces natives en incluant Slashing et corriger les retours explicites Clippy.
• Valider localement les fondations : kb_execution_api 21 tests, kb_execution_safety 13 tests, kb_executor_solana_core 10 tests, kb_pipeline 45 tests, kb_app_demo 78 tests, kb_config 36 tests et Clippy global propre.
• pre.003 : étendre la configuration wallet/exécution à localnet, devnet, testnet et mainnet, ajouter dry-run, plafonds de frais/priorité et âge maximal du blockhash.
• pre.003 : remplacer le placeholder kb_wallet par un wallet temporaire en mémoire ou persistant, stocké sous wallets/, créé sans écrasement, chargé de façon bornée et utilisable comme Signer sans exposer les octets privés.
• pre.003 : protéger les fichiers wallet par permissions Unix privées, effacement des buffers secrets sérialisés, .gitignore bloquant et interdiction de sélectionner le wallet temporaire dans un profil mainnet.
• Valider localement pre.003 : kb_wallet 6 tests, kb_config 40 tests, kb_store_pg 45 tests offline et PostgreSQL réel, kb_app_demo 78 tests et Clippy global propre.

Suite d’orchestration

• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• Valider localement pre.007 : kb_execution_api 22 tests et Clippy global propre.
• 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.
• pre.008 : étendre la configuration avec retries d’envoi, intervalle/nombre maximal de polls et plafond d’airdrop devnet ; construire directement les politiques RPC depuis ExecutionConfig.
• Valider localement pre.008 : kb_rpc 69 tests, kb_execution_api 22 tests, kb_config 40 tests, kb_execution_solana 7 tests, kb_execution_safety 15 tests, kb_wallet 6 tests, kb_executor_solana_core 10 tests, kb_store_pg 45 tests avec PostgreSQL réel et Clippy global propre.
• pre.009 : orchestrer le premier parcours backend Devnet complet avec wallet persistant, airdrop plafonné, plan System transfer, simulation exacte, signature, envoi, confirmation, getTransaction, insertion canonique, extraction core et decode replay ciblé.
• Valider pre.009 offline : kb_pipeline 49 tests, kb_rpc 69 tests, kb_execution_api 22 tests, kb_execution_safety 15 tests, kb_execution_solana 7 tests, kb_executor_solana_core 10 tests, kb_wallet 6 tests, kb_config 40 tests, kb_store_pg 45 tests avec PostgreSQL réel et Clippy global propre.
• Valider le parcours Devnet réel avec le wallet persistant préfinancé et un transfert de 1 000 000 lamports : simulation, signature, envoi, confirmation et replay post-exécution réussis.
• pre.010 : ajouter getAccountInfo et getMinimumBalanceForRentExemption, refuser avant simulation un transfert insuffisant vers une adresse inexistante et conserver l’erreur runtime ainsi que les logs lorsque la simulation échoue.
• pre.010 : ajouter demo_execution_solana_core, limité aux profils Devnet persistants, avec plan, simulation exacte, confirmation opérateur, envoi, progression et diagnostics post-exécution sans exposition de clé privée.
• Valider localement pre.010 : kb_rpc 70 tests, kb_pipeline 51 tests, kb_app_demo 87 tests, kb_execution_api 22 tests, kb_execution_safety 15 tests, kb_execution_solana 7 tests, kb_executor_solana_core 10 tests, kb_wallet 6 tests, kb_config 40 tests, kb_store_pg 45 tests avec PostgreSQL réel et Clippy global propre.
• Valider visuellement demo_execution_solana_core dans cargo tauri dev : simulation dry-run, refus sans confirmation opérateur, envoi Devnet confirmé, insertion canonique 1, extraction core 1 et decode replay 1 sans échec.
• pre.011 : ajouter les builders System create_account_with_seed, transfer_with_seed, allocate_with_seed, assign_with_seed et create_account_allow_prefund, avec validation des dérivations et signataires exacts.
• Valider localement pre.011 : kb_executor_solana_core 14 tests, kb_app_demo 87 tests et Clippy global propre. Le build frontend séparé n’est pas requis lorsque Vite est déjà validé par le serveur de développement Tauri.
• pre.012 : ajouter transfer_many, les créations de compte nonce normale/seedée et les builders de lifecycle nonce initialize/advance/authorize/withdraw/upgrade, avec plans multi-instructions et politique recent-blockhash explicite.
• Valider localement pre.012 : kb_executor_solana_core 19 tests, kb_execution_solana 7 tests, kb_execution_api 22 tests et Clippy global propre.
• pre.013 : ajouter la lecture RPC complète et bornée d’un compte nonce, sa validation System Program/Current/Initialized via solana-nonce et wincode, l’assemblage officiel Message::new_with_nonce avec AdvanceNonceAccount en première instruction, la valeur nonce comme blockhash et la preuve de simulation liée au message et à cette valeur.
• Valider localement pre.013 : kb_executor_solana_core 20 tests, kb_execution_solana 12 tests, kb_execution_api 22 tests, kb_rpc 70 tests et Clippy global propre.
• pre.014 : compléter Compute Budget avec RequestHeapFrame et SetLoadedAccountsDataSizeLimit, synchroniser les capacités et exports TS-rs, rendre normative la documentation des APIs publiques dans les README et détailler le phasage des exécuteurs futurs.
• Valider localement pre.014 : kb_executor_solana_core 21 tests, kb_execution_api 22 tests, kb_execution_safety 15 tests, kb_execution_solana 12 tests, kb_rpc 70 tests et Clippy global propre.
• pre.015 : ajouter les cinq builders officiels Address Lookup Table create/extend/freeze/deactivate/close, avec contrats d’intent, capacités exactes, exports TS-rs, contrôles statiques et documentation de la frontière stateful.
• Valider localement pre.015 : kb_executor_solana_core 25 tests, kb_execution_api 22 tests, kb_execution_safety 15 tests, kb_execution_solana 12 tests, kb_rpc 70 tests et Clippy global propre.
• pre.016 : ajouter les builders déterministes Ed25519, secp256k1 et secp256r1 dans deux formes par précompile — inline et table d’offsets — avec layouts officiels, références externes, bornes, exports TS-rs et documentation des contraintes de positionnement.
• Valider localement pre.016 : kb_executor_solana_core 31 tests, kb_execution_api 22 tests, kb_execution_safety 15 tests, kb_execution_solana 12 tests, kb_rpc 70 tests et Clippy global propre.
• pre.017 : ajouter les builders Config create/store, Feature activate/revoke, Slashing close/duplicate-block proof atomique et ZK ElGamal inline/account/close ; classer l’ancien ZK Token Proof comme historique decode-only, sans Unsupported générique.
• pre.018 : corriger les quatre avertissements Clippy de tests de pre.017, ajouter les vingt-quatre opérations Stake actuelles avec miroir wire wincode, plans composés officiels, capacités exactes, exports TS-rs et documentation stateful.
• Valider localement pre.017 : kb_executor_solana_core 46 tests, kb_execution_api 22, kb_execution_safety 15, kb_execution_solana 12 et kb_rpc 70. Clippy ne signale que quatre cloned_ref_to_slice_refs de tests, corrigés dans pre.018.

Exhaustivité des builders natifs

• Compléter System avec les variantes seed, transferts seed, create_account_allow_prefund et le helper multi-instructions transfer_many.
• Implémenter les builders officiels de création et lifecycle durable nonce : create/create-with-seed, initialize, advance, authorize, withdraw et upgrade, exécutés avec un recent blockhash normal.
• Ajouter dans kb_execution_solana l’assemblage d’une transaction utilisant réellement un nonce durable : lecture complète bornée, validation exacte de l’état courant initialisé, AdvanceNonceAccount en première instruction, valeur nonce comme blockhash et preuve de simulation liée au message exact.
• pre.014 : compléter Compute Budget avec les quatre variantes client actuelles request_heap_frame, set_compute_unit_limit, set_compute_unit_price et set_loaded_accounts_data_size_limit, comparées aux builders officiels et protégées par des limites explicites. Conserver Unused et RequestUnitsDeprecated comme compatibilité de décodage seulement.
• pre.014 : rendre normative la documentation des APIs publiques dans les README des crates opérationnelles, documenter les contrats kb_execution_api, kb_execution_safety, kb_execution_solana, kb_executor_solana_core et auditer l’appariement des 102 surfaces décodeur/exécuteur réservées.
• Valider localement pre.014 : kb_executor_solana_core 21 tests, kb_execution_api 22 tests, kb_execution_safety 15 tests, kb_execution_solana 12 tests, kb_rpc 70 tests et Clippy global propre.
• Implémenter les builders stateless Address Lookup Table create/extend/freeze/deactivate/close contre l’interface officielle, avec signataires exacts, ordre conservé et bornes d’input.
• Ajouter l’orchestration ALT stateful : lecture/décodage du compte, autorité et état courants, capacité restante, slot récent, rent top-up mesuré, cooldown de fermeture et lifecycle localnet/devnet.
• Implémenter les précompiles Ed25519, secp256k1 et secp256r1 avec formes inline et offsets, layouts officiels déterministes, références inter-instructions, bornes de taille et aucune dépendance bincode directe.
• Valider localement pre.016 et confirmer les six builders par tests officiels, exports TS-rs et Clippy global.
• Implémenter Config create/store, Feature activate/revoke, les deux instructions Slashing et les douze vérifications plus fermeture ZK ElGamal officiellement appelables, même lorsqu’elles ne seront pas proposées dans la démo opérateur.
• Classer l’ancien ZK Token Proof comme programme historique decode-only : aucun builder moderne ne doit être inventé pour le stub retiré du runtime actif.
• Ajouter les orchestrations stateful de pre.022 : rent et état Config/Feature, compte de preuve et fenêtre temporelle Slashing, préallocation/owner/space des contextes ZK ElGamal.
• Implémenter Stake maximalement pour les vingt-quatre helpers clients actuels : create/initialize, checked/seed, split/merge, délégation, autorités, lockup, withdraw, deactivate, delinquent et move. Classer Redelegate/redelegate_with_seed comme historiques désactivés decode-only.
• Implémenter dans pre.019 Vote maximalement : vingt variantes wire actuelles, quatre créations composées legacy/V2 avec ou sans seed, autorités Ed25519/BLS, votes, TowerSync, commissions, collecteurs, retrait et dépôt de récompenses, avec tests unitaires avant tout essai devnet.
• Implémenter dans pre.020 les opérations Loader réellement constructibles : onze plans Loader v3 via solana-loader-v3-interface/wincode et neuf plans Loader v4 au wire officiel reproduit sans activer ses helpers bincode; conserver BPF Loader v1/v2 historiques en decode-only et Native Loader sans builder client.
• Traiter dans pre.020 la dette post-0.4.1 : migrer le parser Loader v3 upgradeable vers solana-loader-v3-interface ^8.0 avec wincode, préserver la compatibilité du booléen optionnel historique et ne pas activer les helpers bincode de Config, Loader v2 ou Loader v4.
• Consolider dans pre.021 les helpers internes répétés de kb_executor_solana_core : neuf parsers de clés, cinq parsers d’ID natif, validations communes de comptes distincts, montants positifs, longueurs exactes, dérivations seedées, wrappers d’erreur Loader et appender d’offsets u16; conserver séparées les sérialisations et validations dont le contrat reste propre à une surface.
• Ajouter une matrice machine-readable programme/opération/builder officiel/politique/tests unitaires/tests cluster/exposition UI, validée automatiquement contre les 109 constantes d’opération et les 18 surfaces natives.

Phasage restant de l’exhaustivité native

• pre.015 : builders stateless Address Lookup Table create/extend/freeze/deactivate/close, avec autorité, ordre de comptes, payer optionnel et contrats de lifecycle exacts ; conserver rent, capacité, slot et cooldown dans la tranche stateful pre.022.

• pre.016 : builders Ed25519, secp256k1 et secp256r1, avec formes inline/offsets, références d’instructions, comparaison aux constructeurs ou layouts officiels, low-S secp256r1 et position secp256k1 explicitement bornée.

• Validation locale de pre.016 avant passage à pre.017.

• pre.017 : Config, Feature, Slashing et surfaces ZK officiellement appelables ; classification explicite de l’ancien ZK Token Proof comme historique decode-only.

• Validation locale de pre.017 avant passage à pre.018, avec quatre avertissements Clippy de tests reportés et corrigés dans le lot suivant.

• pre.018 : Stake maximal — vingt-quatre helpers clients actuels, autorités, lockup, création/rent fourni, délégation, merge/split, retraits, move et variantes checked/seed ; Redelegate reste historique désactivé.

• Valider localement pre.018 : kb_executor_solana_core 57 tests, kb_execution_api 22, kb_execution_safety 15, kb_execution_solana 12, kb_rpc 70 et Clippy global propre.

• pre.019 : Vote maximal — vingt variantes wire, quatre créations composées, initialisation legacy/V2, vote/update, autorisations, commissions, collecteurs, identité, retrait, récompenses, compact update et TowerSync.

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

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

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

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

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

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

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

• pre.023 : remplacer le validateur Python de la matrice d’exécution par un test Rust fondé sur SOLANA_CORE_OPERATION_CODES; ajouter une matrice décodeur exacte de 18 surfaces/121 déclarations et l’inventaire canonique des 52 méthodes HTTP et neuf paires WebSocket standard.

• Valider localement pre.023 : kb_executor_solana_core 88 tests, kb_decoder_solana_core 116 tests, kb_rpc 78 tests et cargo clippy --all-targets propre.

• pre.024 : ajouter les adaptateurs configurables propres à kb_rpc des 38 méthodes HTTP standard auparavant limitées au contrat JSON brut ; conserver toutes les options officielles sélectionnables indépendamment, ne pas exposer les DTO Agave et imposer 52 typed / 0 raw dans la matrice RPC.

• Valider localement pre.024 : kb_rpc 98 tests après correction explicite du type de Vec<serde_json::Value> dans un test, puis cargo clippy --all-targets propre.

• pre.025 : déplacer le runtime WebSocket persistant de kb_app_demo vers kb_rpc, typer paramètres et notifications des neuf paires standard et garder les trois surfaces instables derrière une capacité explicite.

• Valider localement pre.025 après fix.001 : kb_rpc 113 tests, kb_app_demo 87 tests et cargo clippy --all-targets propre ; confirmer la désactivation dynamique des méthodes WebSocket instables rejetées par le nœud.

• pre.026 : auditer les logs Tauri de clôture et identifier l’unique erreur applicative réelle comme une incompatibilité TS-rs u64 -> bigint lors de demo_ws_unsubscribe; les avertissements de confirmation opérateur et de requête SQL lente restent attendus et non bloquants.

• pre.027 : premières projections Transfer Fee publiques dans kb_materializer_fees; validation 4/4, Token-2022 50/50, ElGamal Registry 5/5 et Clippy propre.

• pre.028 : sept feuilles Confidential Transfer Fee classées dans EventFamily::Fee et projetées sans déchiffrement ; validation Token-2022 50/50, ElGamal Registry 5/5, fees 6/6 et Clippy propre.

• pre.029 : projeter les snapshots bornés Mint/Account/Multisig Token-2022, leur inventaire TLV ordonné et les états confidentiels publics dans kb_materializer_token_accounts.

• pre.026 : aligner les payloads Tauri WebSocket, backfill, SQL et configuration sur des nombres JSON, supprimer la construction frontend de BigInt, borner l’identifiant d’unsubscribe à Number.isSafeInteger et ajouter des tests de non-régression sur les déclarations TS-rs.

• Valider la correction TS-rs de pre.026 : kb_config 41 tests, kb_app_demo 88 tests, cargo clippy --all-targets propre, démarrage Tauri/Vite réussi et souscriptions/désabonnements WebSocket réels sans erreur BigInt.

• pre.026/pre.027 : terminer les audits README/API, enregistrer les validations offline, PostgreSQL, Devnet et RPC réelles, conserver les opérations administratives stateful derrière leurs préflights et sans activation Mainnet, puis clôturer la documentation et le CHANGELOG.md.

Critères de clôture de l’exécuteur natif

• Chaque surface native du registre possède soit tous ses builders client officiellement appelables, soit une classification documentée non invocable, retirée ou historique decode-only dans la matrice canonique.
• La couverture bibliothèque est indépendante de l’exposition dans kb_app_demo ; masquer une opération dangereuse dans l’UI ne permet pas de la considérer comme hors périmètre.
• Toute API publique utile des crates d’exécution est inventoriée dans le README de sa crate avec rôle, paramètres, résultat, effets, limites et exemple minimal ; l’audit final couvre kb_execution_api, kb_execution_safety, kb_execution_solana, kb_executor_solana_core, kb_rpc, kb_pipeline et kb_app_demo.
• Chaque builder est comparé offline à un encodeur ou layout officiel. Les opérations stateful non exercées réellement restent bloquées par le préflight, hors UI dangereuse et sans activation Mainnet ; une validation Localnet/Devnet par opération reste obligatoire avant toute future activation mutable.
• La matrice machine-readable ne contient aucune opération callable sans statut, politique, tests offline, validation cluster et décision d’exposition UI ; le test Rust impose l’égalité exacte avec les 109 codes compilés.

Critères de clôture du décodeur natif et de kb_rpc

• Les 18 Program IDs natifs du registre partagé correspondent exactement aux 18 surfaces du décodeur.
• Les 121 déclarations de couverture sont comptées par surface et reliées à un test d’enum officielle ou de layout wire audité.
• Les 52 méthodes HTTP et neuf paires WebSocket standard sont inventoriées sans omission dans un registre compilé et une matrice JSON.
• Les 52 méthodes HTTP possèdent un contrat typé dédié ; la voie JSON brute ne constitue plus le contrat principal d’une méthode standard.
• Les neuf paires WebSocket possèdent paramètres, notifications et runtime persistant dans kb_rpc, sans logique de transport lourde dans kb_app_demo.

Démo et clôture

• Ajouter demo_execution_solana_core après le premier parcours backend Devnet validé ; exposer le transfert contrôlé et masquer les opérations administratives dangereuses.
• Afficher plan, comptes, signataires requis, plafonds, cluster réel, simulation, signature/envoi et validation post-exécution sans jamais transférer de clé privée à la WebView.
• Conserver 0.4.2 limité à la démo System transfer validée ; les créations/allocation/assignation et le nonce ne sont volontairement pas ajoutés à l’UI sans orchestrateur stateful cluster dédié.
• Valider les builders offline contre les encodeurs officiels, valider le parcours Devnet représentatif et conserver Mainnet désactivé par défaut ; les autres opérations stateful restent conditionnées à une preuve cluster ultérieure avant exposition.
• Clôturer 0.4.2 par tests ciblés, PostgreSQL réel, Clippy, parcours Devnet avec replay post-exécution, smoke tests RPC/Tauri, documentation finale et mise à jour du CHANGELOG.md.

Validation finale observée — 13 juillet 2026

• kb_program_ids 5 tests, kb_decoder_solana_core 116, kb_executor_solana_core 88, kb_execution_api 22, kb_execution_safety 15 et kb_execution_solana 12.
• kb_rpc 113 tests, kb_pipeline 56, kb_config 41 et kb_app_demo 88.
• kb_store_pg 45 tests avec PostgreSQL réel, migrations et roundtrips optionnels réussis.
• Parcours Devnet opt-in réussi avec wallet persistant préfinancé, transfert de 1 000 000 lamports, simulation, signature, envoi, confirmation, hydratation canonique, extraction core et decode replay.
• cargo clippy --all-targets sans avertissement.
• cargo tauri dev -c kb_app_demo/tauri.conf.json validé avec Vite, initialisation PostgreSQL et sessions WebSocket réelles.
• Les logs de clôture confirment les unsubscribe slot, root et program. Le refus de changer d’endpoint avec une session active est un garde-fou attendu. La limite SQL supérieure à 5 000 est désormais refusée dans le frontend avant l’appel backend.

La clôture de 0.4.2 n’active pas Mainnet et n’étend pas l’UI aux opérations administratives. La suite active reprend avec 0.4.3 — SPL Memo v1, v3 et v4. Le projet d’acquisition historique gratuite est volontairement retiré du ROADMAP actif et conservé séparément dans docs/HISTORICAL_DATA_ACQUISITION_PLAN.md, sans version attribuée.

Politique commune de tous les programmes Solana

Pour chaque programme Solana, natif, SPL, DEX, launchpad ou autre, l'ordre obligatoire est : décodeur maximal et corpus, décision/ajout des matérialisateurs concernés, puis exécuteur limité aux opérations explicitement supportées. Le décodeur conserve tout wire identifiable, historique, courant, récent ou expérimental. Les matérialisateurs projettent maximalement les faits stables sans dupliquer le core ni une autre projection. L'exécuteur exclut les opérations obsolètes ou purement historiques, mais peut construire les opérations courantes ou expérimentales officiellement encodées indépendamment de leur déploiement par cluster. Une absence de matérialisation ou d'exécution doit être une décision documentée, jamais un oubli. Chaque exécuteur est validé après le décodeur, avec builder officiel, simulation/dry-run, politiques d'autorisation et tests devnet avant mainnet.

Audit rétroactif des programmes déjà clôturés

• Solana natif : le décodeur conserve les wires historiques ; les absences de projection des précompiles et preuves ZK sont documentées ; BPF Loader v1/v2, ancien ZK Token Proof et Stake Redelegate restent decode-only, tandis que l'exécuteur couvre les opérations officiellement appelables.
• SPL Memo : le décodeur v1/v3/v4 et la matérialisation des annotations commitées respectent la politique maximale sans doublon.
• Corriger le contrat de kb_executor_spl_memo : v1 et v3 historiques deviennent Unsupported(reason)/decode-only; v4 reste la seule génération courante constructible et exécutée par la démo.
• Valider par Cargo la matrice, les capacités compilées et la régression Memo/exécution avant de commencer le code des matérialisateurs SPL Token.

0.4.3 — SPL Memo v1, v3 et v4

• Réserver kb_decoder_spl_memo et kb_executor_spl_memo pour les trois générations sans produire de faux événement ni activer d’envoi.
• Suivre prompts/022_v0_4_3_spl_memo.md et auditer les contrats officiels/historiques exacts des trois program IDs ; docs/SPL_MEMO_MATRIX.json prouve notamment que v1 ignore les comptes alors que v3/v4 exigent chaque compte comme signer.
• Implémenter le décodeur maximal synthétique : génération, payload UTF-8 ou tentative invalide, longueur/hash, comptes signataires ordonnés, outer/inner, transaction réussie ou échouée et couverture machine-readable ; compilation, 9 tests et Clippy validés après pre.001-delta-fix-001.
• Matérialiser les annotations Memo commitées dans un domaine dédié, sans détourner une projection métier incompatible ni produire de mutation réussie pour une transaction échouée ; pre.002 validé par les tests ciblés, le store PostgreSQL réel et Clippy.
• Remplacer l’exécuteur réservé par un contrat typé exact pour les générations réellement constructibles, avec builders/layouts officiels, signataires déclarés, simulation/dry-run et validation post-exécution Devnet.
• Clôturer le jalon avec corpus synthétique et réel, replay idempotent, tests ciblés, PostgreSQL réel si le store est touché, Clippy et documentation des trois crates concernées.

0.4.3-pre.001 — audit et décodeur Memo contextualisé

• Remplacer DecoderSupport::Maybe par une reconnaissance exacte des trois IDs et déplacer le target tracing vers src/constants.rs.
• Implémenter le wire brut borné, l’UTF‑8, le texte complet, longueur, SHA-256, préfixe diagnostic, comptes ordonnés, signataires et chemin outer/inner.
• Séparer add_memo, memo_intent et invalid_memo_attempt, sans jamais marquer committed une transaction échouée.
• Enregistrer spl_memo dans demo_decode_replay à côté du décodeur natif.
• Valider la compilation et les tests sur une machine disposant de Cargo : 9 tests Memo, 41 tests config, 89 tests démo et Clippy propre après delta-fix-001; le corpus réel reste requis pour la clôture globale du jalon.

0.4.3-pre.002 — annotations de transaction Memo

• Créer kb_materializer_transaction_annotations et la famille explicite TransactionAnnotation, sans détourner les projections existantes.
• Projeter uniquement add_memo réussi et commité avec identité, texte, longueur, hash, signataires vérifiés, provenance et clé d’idempotence.
• Refuser les transactions échouées et observations non commitées ; laisser les comptes complets, writable, diagnostics et preuves uniquement dans le decode.
• Réutiliser kb_sol_mat_events et le ledger commun sans migration SQL ni duplication core/decode.
• Enregistrer le matérialiseur dans demo_decode_replay et déclarer son target tracing dans les trois profils.
• Valider les tests ciblés, Clippy et PostgreSQL réel : modèle 23, Memo 9, matérialiseur 7, API matérialiseur 2, pipeline 56, config 41, démo 89, store PostgreSQL 45 et Clippy propre.
• Valider pre.002-delta-fix-001 côté compilation et persistance : store core 40, Memo 9, pipeline 57, démo 93 et store PostgreSQL réel 46 ; corriger dans delta-fix-002 l’assertion de matrice du matérialiseur, la garde de mutex signalée par Clippy et la limite de 64 filtres qui empêchait le démarrage Tauri avec 65 routes.
• Valider le parcours opérateur Mainnet de pre.002-delta-fix-002 : trois backfills de 100 transactions, core extraction 300/300, replay v1 102/102 avec 69 annotations et 33 refus, v3 439/439 avec 422 annotations et 17 refus, v4 100/100 avec 100 annotations, zéro unmatched ou failed input ; second replay v3 non forcé sélectionnant zéro entrée.
• Valider le démarrage Tauri avec 65 routes de logging sans dépassement de la limite de filtres ni erreur opérationnelle.
• Valider le test logging de pre.002-delta-fix-003 : 17 tests réussis, y compris la composition de plus de 64 routes ; Clippy a encore identifié la durée lexicale d’un MutexGuard dans le test pipeline malgré son drop explicite.
• Valider pre.002-delta-fix-004 : pipeline 57 tests et cargo clippy --all-targets propres après fermeture lexicale du MutexGuard.

0.4.3-pre.003 — contrat typé et wire de l’exécuteur Memo

• Remplacer le plan réservé par SplMemoGeneration, SplMemoOperation::AddMemo, SplMemoExecutionIntent et SplMemoSigner.
• À la clôture initiale de 0.4.3, construire v1/v3/v4 avec spl_memo_interface::instruction::build_memo; cette capacité historique est ensuite remplacée par l'audit transversal de 0.4.4, qui conserve uniquement v4 exécutable.
• Conserver les doublons dans les metas tout en dédupliquant les signataires transactionnels requis.
• Imposer simulation, plafond de frais, dépense nulle hors frais et validation post-exécution complète sans lier la bibliothèque à un cluster.
• Valider alors la séparation cluster/simulation/politique commune ; l'audit transversal ultérieur classe v1/v3 decode-only sans modifier le caractère universel du builder v4.
• Valider pre.003 : exécuteur Memo 14, API 22, safety 15, Solana 12 et cargo clippy --all-targets propres.
• Valider pre.003-delta-fix-001 après retrait des restrictions réseau placées à tort dans la bibliothèque universelle : exécuteur 15 tests et Clippy propre.
• Ajouter un parcours opérateur Devnet v4 réutilisant simulation, confirmation, hydratation, core extraction, decode replay, projection et idempotence.
• Réutiliser le journal générique des matérialisations et la fenêtre d’exécution Devnet pour Memo v4 avec DTO Tauri JSON sans bigint actif.

0.4.3-pre.004 — orchestration backend Memo v4 Devnet

• Ajouter un request simulation-first, un plan Memo v4 à dépense nulle hors frais et une autorisation d’envoi explicite.
• Réutiliser le wallet persistant, la vérification du genesis Devnet, le blockhash, les frais, la simulation liée au message, la signature et la confirmation communs.
• Hydrater la signature exacte, extraire le core, rejouer spl_memo, vérifier la projection transaction_annotation puis exécuter un second replay non forcé.
• Valider pre.004-delta-fix-001 : pipeline 61, exécuteur Memo 15, API 22, safety 15, Solana 12 et Clippy propres ; test opt-in Devnet réussi en simulation puis avec envoi.

0.4.3-pre.005 — démonstration Tauri Memo v4 Devnet

• Étendre la fenêtre Solana Devnet existante sans créer une nouvelle WebView ni déplacer de logique métier dans l’application.
• Exposer message UTF-8, signer wallet readonly, simulation, confirmation opérateur et diagnostic complet sans clé privée ni bigint Tauri.
• Afficher confirmation, validation canonique/core/decode, nombre d’annotations et preuve d’idempotence.
• Valider 96 tests démo, 61 tests pipeline, Clippy propre et démarrage Tauri/Vite.
• Exécuter trois Memo v4 Devnet réels : trois confirmations, trois insertions canoniques, trois extractions, trois annotations et trois seconds replays skipped, sans échec ni nouvelle matérialisation.

0.4.3-pre.006 — consolidation documentaire et corpus Devnet

• Reporter dans docs/SPL_MEMO_MATRIX.json les trois signatures v4 Devnet confirmées, leurs annotations de 34 octets et leurs seconds replays idempotents.
• Synchroniser les README du décodeur, du matérialiseur, de l’exécuteur, du pipeline et de la démo avec les limites réellement validées.
• Conserver comme non-revendications explicites l’envoi v1/v3 sur Devnet, le déploiement Localnet des binaires historiques et les coûts hors simulation/plafond de frais.

0.4.3-pre.007 — clôture et prompt SPL Token

• Enregistrer les validations finales fournies par l’utilisateur, y compris PostgreSQL réel, le parcours Devnet opt-in avec envoi et Clippy propre.
• Clôturer 0.4.3 dans le ROADMAP et le CHANGELOG.md sans modifier le code ni le schéma PostgreSQL.
• Ajouter prompts/023_v0_4_4_spl_token.md et rendre 0.4.4 — SPL Token actif.

Validation finale observée — 15 juillet 2026

• kb_program_ids 5 tests, kb_decoder_spl_memo 9, kb_materializer_transaction_annotations 7 et kb_executor_spl_memo 15.
• kb_execution_api 22 tests, kb_execution_safety 15 et kb_execution_solana 12.
• kb_pipeline 61 tests, kb_rpc 113 et kb_app_demo 96.
• kb_store_pg 46 tests avec PostgreSQL réel, migrations et requêtes de matérialisation typées réussies.
• Test opt-in Devnet exécuté avec KB_DEVNET_MEMO_EXECUTION_TEST=1 et KB_DEVNET_MEMO_SUBMIT=1 : simulation, envoi, confirmation, hydratation, extraction, replay, annotation et idempotence réussis.
• cargo clippy --all-targets sans avertissement.
• Démo Tauri/Vite validée avec simulation Memo et trois envois v4 Devnet réels ; chaque transaction a produit une annotation et un second replay skipped.

0.4.3 est clôturé. La suite active devient 0.4.4 — SPL Token selon prompts/023_v0_4_4_spl_token.md. Le worker d’acquisition historique reste différé et hors ROADMAP actif.

0.4.4 — SPL Token

• 0.4.4-pre.001 — auditer les 28 tags publiés par spl-token-interface 3.0.0 et implémenter le décodeur contextualisé classique : wire borné, comptes, autorités, multisig, inner instructions, transactions échouées, return data explicitement indisponible et Batch non imbriqué.
• Valider pre.001-delta-fix-001 le 15 juillet 2026 : 7 tests kb_decoder_spl_token réussis et cargo clippy --all-targets propre ; le correctif conserve le manifeste parent Batch, aligne la fixture multisig et autorise les listes explicites de tags via workspace.lints.clippy.manual_range_patterns.

0.4.4-pre.002 — contrat documentaire et politique d'exécution

• Rendre normative la couverture historique/courante/récente/expérimentale des décodeurs, la matérialisation maximale sans doublons et l'exclusion des opérations obsolètes dans les exécuteurs.
• Détailler les responsabilités token_accounts, admin, risk et fees, ainsi que le futur journal métier et la démo opérateur.
• Corriger la matrice et le test Memo : v1/v3 decode-only, v4 exécutable sur tout cluster sous gouvernance commune ; 16 tests Memo et Clippy global validés après fix-002.

0.4.4-pre.003 — matérialisations SPL Token classiques

• Activer kb_materializer_token_accounts pour les initialisations de mint, compte et multisig, transferts, approvals/revocations, mint, burn, freeze/thaw, close, sync native et unwrap, uniquement lorsqu'ils sont réussis et commités.
• Produire un journal de mutations instructionnelles avec signature, slot, chemin stable, opération, comptes, mint explicitement connu ou null, montant brut en chaîne, decimals wire éventuels, autorité, provenance et clé d'idempotence ; ne pas prétendre reconstruire le snapshot final du compte.
• Étendre kb_materializer_admin sans régresser ses projections natives, pour set_authority et les configurations multisig Token clairement administratives.
• Activer kb_materializer_risk pour des constats factuels : délégation/allowance, revoke, freeze/thaw, révocation d'autorité et configuration multisig structurellement faible ; ne produire aucun score arbitraire.
• Conserver kb_materializer_fees inactif pour SPL Token classique et tester/documenter explicitement no projection, car ni les transfer fees Token-2022 ni les frais réseau core n'appartiennent à cette surface.
• Dédupliquer les sorties parent/enfants de Batch par leur chemin dérivé et leur output_key, refuser toute observation non commitée et réutiliser kb_sol_mat_events avec le ledger commun.
• Enregistrer les matérialisateurs actifs dans le replay commun et valider leur idempotence, sans migration PostgreSQL si le contrat générique suffit.
• Valider pre.003 le 15 juillet 2026 : tests des quatre matérialiseurs, pipeline, config et démo réussis, Clippy global propre ; replay Mainnet de 370 instructions, 371 sorties, huit refus correspondant exactement à huit transactions échouées, puis second replay idempotent avec zéro sélection.

0.4.4-pre.004 — contrat typé et builders de kb_executor_spl_token

• Remplacer le scaffold par des intents typés pour les 24 opérations courantes et expérimentales officiellement constructibles ; classer les quatre initialisations historiques obsolètes en Unsupported(reason) au lieu de les construire.
• Appeler les builders officiels 3.0.0, préserver l'ordre des metas et séparer autorité simple, multisig, signataires transactionnels, montants bruts en chaînes, decimals, rent, SOL transféré et frais réseau.
• Construire UnwrapLamports et Batch après preuve exacte de leurs signatures et layouts officiels ; séparer explicitement constructibilité, déploiement par cluster et autorisation d'envoi.
• Imposer simulation, dry-run par défaut, plafond de frais et validation post-exécution, sans dépendance vers RPC, wallet, Tauri ou le décodeur.
• Valider pre.004-delta-fix-001 le 15 juillet 2026 : 15 tests kb_executor_spl_token, 22 tests API, 15 tests safety, 12 tests Solana, 61 tests pipeline et cargo clippy --all-targets propres.

0.4.4-pre.005 — préflight stateful et orchestration

• Ajouter dans le pipeline les lectures bornées des comptes Mint/Account/Multisig nécessaires aux préconditions : owner, mint, decimals, état, solde, native reserve, delegate/allowance, autorités, seuil M/N et rent des comptes à initialiser.
• Séparer le test réseau du test standard : layouts et bornes restent offline ; KB_DEVNET_SPL_TOKEN_PREFLIGHT_TEST=1 active un contrôle réel de TransferChecked sur des comptes Devnet explicitement fournis, sans signature ni dépense.
• Valider le socle pre.005 le 15 juillet 2026 : 67 tests kb_pipeline, 15 tests kb_executor_spl_token, Clippy global propre et préflight TransferChecked Devnet réel Ready sur deux comptes auxiliaires contrôlés du même mint.
• pre.005-delta-fix-001 : réutiliser l'orchestration commune pour préflight obligatoire, simulation liée au message exact, signature/envoi autorisé, confirmation, hydratation canonique, extraction core, replay Token, vérification des projections et second replay idempotent.
• Exposer séparément une API de simulation sans store ni signature et refuser l'envoi si les signataires requis ne sont pas tous résolus par le wallet persistant du profil.
• Valider le test opt-in d'orchestration le 15 juillet 2026 sur les comptes Devnet contrôlés : simulation seule puis envoi réel de TransferChecked, avec wallet isolé explicitement aligné sur l'autorité Token, confirmation, hydratation canonique, extraction core, replay et matérialisation réussis ; le contrat renforcé a produit la signature 5Q71KeomfhHBueDsD92C7L21vHUpFGZnZzCFPGaCDAMHx6yV4Jy2fMDzCpze8mNr2c1GLSRT93mmBaYy2RGZ95ZY, une matérialisation et un second replay sans échec, refus ni nouvelle sortie.

0.4.4-pre.006 — lifecycle contrôlé Devnet sans ATA

• Ajouter un orchestrateur séquentiel pour des comptes Mint/Account rent-exempt, non initialisés et possédés par le programme Token classique, sans création ATA implicite.
• Enchaîner onze transactions simulation-first : InitializeMint2, deux InitializeAccount3, MintToChecked, TransferChecked, ApproveChecked, Revoke, deux BurnChecked puis deux CloseAccount.
• Exiger la même autorité simple résolue par le wallet de profil, une confirmation destructive explicite, la conservation exacte des montants bruts et une validation canonique/idempotente complète avant de passer à l'étape suivante.
• pre.006-delta-fix-001 : remplacer la dépendance à l'ancienne commande CLI solana create-account par une préparation interne qui génère trois keypairs éphémères, mesure le rent, construit et simule trois SystemCreateAccount, exige les deux signatures, confirme puis vérifie owner Token, tailles 82/165/165 et données entièrement nulles.
• pre.006-delta-fix-002 : rendre une séquence partielle reprenable depuis un index explicite seulement après récupération canonique de la signature prédécesseur, correspondance de l'opération matérialisée, second replay idempotent, puis pacing borné et émission immédiate des signatures suivantes.
• Valider le lifecycle réel Devnet le 15 juillet 2026 : préparation interne des comptes 82/165/165, reprise contrôlée après throttling du RPC public, puis MintToChecked, TransferChecked, ApproveChecked, Revoke, deux BurnChecked et deux CloseAccount confirmés ; chaque étape récupérée ou envoyée produit exactement une matérialisation et un second replay idempotent. Le scénario multisig reste candidat pour l'audit final si son coût demeure raisonnable.

0.4.4-pre.007 — journal métier et démo opérateur

• Étendre la fenêtre d'exécution Devnet existante, sans nouvelle WebView par opération, avec un panneau Token représentatif TransferChecked, simulation par défaut et confirmation explicite avant envoi ; le lifecycle complet reste exercé par son scénario opt-in dédié.
• Conserver une seule fenêtre d'exécution : le panneau Token réutilise le profil, le wallet, le verrou d'exécution, la simulation et la confirmation déjà communs aux parcours System et Memo.
• Ajouter une vue bornée du journal kb_sol_mat_events, filtrable par signature, mint, compte, famille et opération, avec détail JSON typé et montants bruts sans perte.
• Visualiser les initialisations, transferts, délégations, mint/burn, freeze/thaw, changements d'autorité, close et opérations wrapped SOL comme événements chronologiques ; ne pas afficher d'OHLC ni de faux solde final.
• Afficher séparément résultat de préflight, simulation, confirmation, extraction, décodage, matérialisations attendues et preuve d'idempotence.
• Valider pre.007 le 15 juillet 2026 : 102 tests kb_app_demo, 80 tests pipeline, 15 tests exécuteur Token et Clippy global propres ; cargo tauri dev a démarré Vite et Tauri, chargé le journal borné et simulé TransferChecked. Le refus sans confirmation puis le refus d'un envoi exigeant une autorité externe au wallet de profil prouvent les deux garde-fous attendus, sans invalider le parcours backend Devnet déjà envoyé et matérialisé.

0.4.4-pre.008 — corpus, audit cluster et clôture

• Documenter dans la matrice les signatures Mainnet représentatives et le lifecycle Devnet, avec statut séparé pour interface, processor, builder, simulation, soumission et déploiement ; conserver Localnet non testé et UnwrapLamports/Batch sans revendication de déploiement cluster.
• pre.008-delta-fix-001 : ajouter le probe Devnet simulation-only de Batch et UnwrapLamports ; valider 81 tests pipeline et Clippy global propre le 16 juillet 2026.
• pre.008-delta-fix-002 : enregistrer les deux simulations Devnet réussies, sans signature ni envoi : Batch avec un enfant TransferChecked de montant nul en 270 compute units et UnwrapLamports d'un lamport depuis un compte wrapped SOL auxiliaire classique en 140 compute units, sans erreur runtime. Devnet expose donc les deux tags récents et aucun binaire Localnet p-token n'est requis pour pallier une absence de déploiement.
• pre.008-delta-fix-003 : aligner le test de non-invention cluster sur la preuve Devnet réelle tout en exigeant que Localnet/Mainnet restent non testés et que les signatures réelles restent vides pour les deux simulations sans envoi ; validation ciblée 8/8 et Clippy global propre le 16 juillet 2026.
• pre.008-delta-fix-004 : aligner les assertions Memo sur matrixVersion = 4 et compléter, dans les trois profils exemple, les routes console et fichier de kb_executor_spl_token ; validation 9/9 Memo, 7/7 annotations, 41/41 configuration, 102/102 démo et Clippy global propre le 16 juillet 2026.
• Exécuter la régression ciblée, PostgreSQL réel, Clippy global et Tauri/Vite : 77 routes chargées, simulation TransferChecked réussie, refus sans confirmation vérifié, matérialisation commitée exacte consultée et simulation Memo v4 réussie ; synchroniser README/CHANGELOG et clôturer 0.4.4 avant ATA.
• pre.008-delta-fix-005 : publier la clôture documentaire 0.4.4, activer 0.4.5 — SPL Associated Token Account et fournir prompts/024_v0_4_5_spl_associated_token_account.md sans commencer son implémentation.

0.4.5 — SPL Associated Token Account

Règle de couverture du jalon : décoder maximalement toute variante officiellement identifiable, qu'elle soit historique, courante ou expérimentale ; matérialiser maximalement chaque fait stable et prouvé sans chevauchement entre propriétaires ; exécuter toute variante actuelle officiellement constructible, en excluant seulement les opérations historiques, obsolètes ou qui ne sont plus d'actualité. Un remaniement reste autorisé lorsqu'il est nécessaire pour respecter ces contrats, à condition d'être borné, justifié, documenté et couvert par les régressions.

• pre.001 : auditer spl-associated-token-account-interface 2.0.0, les trois variantes Borsh publiées, les builders officiels, l'ordre et les flags des comptes, la dérivation PDA [wallet, Token Program ID, mint] et le processor de référence program@v8.0.0 ; publier docs/SPL_ASSOCIATED_TOKEN_ACCOUNT_MATRIX.json et quatre tests d'égalité interface/matrice/builders/PDA. Résolution Cargo 2.0.0, 4/4 tests et Clippy global validés le 16 juillet 2026 ; version workspace corrigée à 0.4.5 ; tests de matrice réintégrés dans decoder.rs pour conserver l'organisation homogène des décodeurs existants. Corpus canonique et égalité des binaires cluster encore non revendiqués.
• pre.002 : remplacer le scaffold par le décodeur ATA exact pour toutes les variantes officiellement identifiables de l'interface et du processor résolus, actuellement Create, CreateIdempotent et RecoverNested ; couvrir wire Borsh et Create historique vide, comptes ordonnés, flags, doublons, dérivations PDA, Token classique/Token-2022, outer/CPI, succès/échec, données inconnues/tronquées/suffixées et diagnostics bornés ; compléter le corpus offline et l'égalité matrice/couverture compilée sans commencer l'exécuteur. Validation opérateur du 16 juillet 2026 : ATA 10/10, configuration 41/41, pipeline 81/81, application 102/102 et Clippy global propre après pre.002-delta-fix-001.
• pre.003 : matérialiser maximalement les faits ATA commités avec propriétaires explicites : étendre kb_materializer_token_accounts pour ata_created, ata_created_or_reused_idempotently et nested_ata_recovered, puis étendre kb_materializer_risk pour le fait distinct nested_ata_anti_pattern_recovered sans score arbitraire. Documenter et tester l'absence de projection dans kb_materializer_lifecycle afin d'éviter le doublon de lifecycle, dans kb_materializer_admin car aucune autorité n'est modifiée et dans kb_materializer_fees car le wire ATA ne prouve aucun montant exact de rent ou de frais. Validation opérateur du 16 juillet 2026 : token_accounts 9/9, risk 6/6, lifecycle 17/17, admin 9/9, fees 3/3, décodeur ATA 10/10, application 103/103, pipeline 81/81 et Clippy global propre. Le replay PostgreSQL réel reste réservé à la validation cluster/finale.
• pre.004 : remplacer le scaffold exécuteur par les trois variantes actuelles officiellement constructibles Create, CreateIdempotent et RecoverNested ; comparer chaque plan au builder officiel et ajouter le préflight stateful pour dérivation, mint, compte existant, RecoverNested, rent, plafonds et signataires. pre.004-delta-fix-001 ajoute les types solana_pubkey::Pubkey explicites après l'échec d'inférence E0282. Validation opérateur du 16 juillet 2026 : exécuteur ATA 10/10, pipeline 84/84 et Clippy global propre.
• pre.005 : valider l'orchestration Devnet simulation-first, la post-validation stateful adaptée aux créations et à RecoverNested, la reprise bornée après 429, la confirmation, l'extraction, le replay ATA et CPI Token classique, la matérialisation et le second replay idempotent ; intégrer Create/CreateIdempotent et le journal lifecycle borné dans la fenêtre Solana existante. Validation opérateur du 16 juillet 2026 : décodeur ATA 10/10, exécuteur ATA 10/10, pipeline 90/90, configuration 41/41, application 111/111 et Clippy global propre ; cargo tauri dev -c kb_app_demo/tauri.conf.json démarre Vite, Tauri, les 83 routes de journalisation et le schéma PostgreSQL réel. Deux soumissions Devnet contrôlées CreateIdempotent classiques ont été simulées, confirmées, extraites, décodées et matérialisées exactement une fois, puis leur second replay n'a produit aucun doublon. Le mint Token-2022 contrôlé 3DxK…KTE a ensuite créé puis réutilisé l'ATA 6WfC…C9Y aux slots 476702448 et 476703343 ; les deux signatures ont réussi le parcours complet et leur second replay sans doublon. L'ATA indépendant mesure 170 octets, appartient à Token-2022, conserve le wallet/mint attendus et expose ImmutableOwner.
• pre.006 : valider le test opt-in Devnet RecoverNested hors UI avec fixture classique contrôlée, préflight des trois PDA, simulation, transfert de 1 000 000 000 unités brutes, fermeture du nested ATA, conservation de l'owner ATA, projections lifecycle/risk distinctes, deux matérialisations exactes et second replay idempotent sous la signature 37LG…HskM. Les suites pipeline 90/90, décodeur ATA 10/10, exécuteur ATA 10/10 et Clippy global restent propres après pre.006-delta-fix-001.
• pre.006-delta-fix-003 : clôturer 0.4.5 après la régression complète. Validation opérateur du 16 juillet 2026 : Program IDs 5/5, Token classique decode 8/8 et exécuteur 15/15, Memo 9/9, annotations 7/7, token accounts 9/9, risk 6/6, lifecycle 17/17, admin 9/9, fees 3/3, API d'exécution 22/22, safety 15/15, transaction Solana 12/12, pipeline 90/90, RPC 113/113, configuration 41/41, application 111/111 et PostgreSQL réel 46/46 ; Clippy global propre. Les manifests Cargo héritent tous de workspace.package.version = 0.4.5, l'interface ATA résolue reste 2.0.0, et les versions npm/Tauri de la démo sont synchronisées en 0.4.5. README, matrice, dépendances d'interface, CHANGELOG et prompt 0.4.6 sont publiés seulement après ces preuves.
• Décoder maximalement Create, CreateIdempotent, RecoverNested et la forme historique vide officiellement identifiable.
• Couvrir les ATA ciblant SPL Token et Token-2022 sans commencer le décodage général Token-2022.
• Matérialiser maximalement le lifecycle ATA et le fait de risque nested sans dupliquer les changements Token, puis développer l'exécuteur maximal des opérations actuelles après validation des projections.

0.4.6 — Token-2022, extensions et registre ElGamal — clôturé

0.4.6 clôt la couverture Token-2022 et le registre ElGamal comme deux frontières techniques distinctes. Token-2022 conserve son Program ID, sa matrice, ses événements, ses états TLV, ses matérialisateurs et ses capacités d’exécution propres. Le registre ElGamal conserve séparément son Program ID, son état de 64 octets, son PDA, ses opérations administratives et ses preuves. Le programme natif ZK ElGamal Proof reste une troisième surface indépendante.

• Résoudre et documenter les interfaces réellement utilisées : spl-token-2022-interface 3.1.1, spl-elgamal-registry-interface 0.2.1, solana-zk-elgamal-proof-interface 0.1.3, Group 0.7.2, Metadata 1.0.1 et TLV 0.9.1.
• Publier docs/SPL_TOKEN_2022_MATRIX.json et docs/SPL_ELGAMAL_REGISTRY_MATRIX.json avec frontières, wire, comptes, états, capacités et preuves séparés.
• Décoder les instructions Token-2022 de base, les familles d’extensions identifiables, Token Metadata/Group incorporés, les parcours confidentiels et les instructions outer/CPI, sans fusionner les implémentations tierces.
• Parser les préfixes Mint, Account et Multisig, le discriminant de type de compte et la région TLV bornée, y compris metadata variable, groupes et extensions publiques/confidentielles sans inventer de valeur déchiffrée.
• Décoder et parser séparément le registre ElGamal, avec create_registry, update_registry, PDA officiel, owner, taille et état de 64 octets.
• Attribuer chaque fait stable à un matérialiseur propriétaire unique : token accounts, metadata, admin, fees, risk/compliance ou annotations ; préserver la provenance et refuser les transactions échouées.
• Exposer les exécuteurs typés Token-2022 et ElGamal Registry avec simulation obligatoire, dry-run par défaut, signataires exacts, préflights stateful, preuves inline/context-state, plafonds et postconditions explicites.
• Valider sur Devnet huit opérations publiques Token-2022 : MintToChecked, TransferChecked, ApproveChecked, Revoke, BurnChecked, FreezeAccount, ThawAccount et CloseAccount, avec hydratation, extraction, replay, matérialisation et second replay idempotent.
• Valider ElGamal Registry synthétiquement/offline : builders, exact-wire, PDA, état, lectures RPC bornées, preuves et orchestration. La validation réseau publique reste explicitement indisponible sur Devnet/Mainnet au 20 juillet 2026 ; aucune preuve cluster n’est inventée.
• Valider le corpus Mainnet/PostgreSQL : 55 instructions Token-2022 décodées sans échec, aucune duplication decode/mat, et correction du wire Write du loader immuable sur 68 instructions Mainnet.
• Qualifier les rejets natifs restants : 31 immutable_loader_tag_truncated, 44 loader_v4_tag_truncated et 1 loader_accounts_invalid, tous dans des transactions Solana échouées ; quatre variantes Loader v4 inconnues restent explicitement Unsupported.
• Ajouter le mode incomplete_signatures dans le replay de kb_app_demo : sélection des signatures contenant au moins une instruction pending, failed, replay_requested ou unsupported, limite appliquée aux signatures, expansion aux instructions compatibles et réévaluation sans force replay global.
• Valider deux campagnes PostgreSQL réelles incomplete_signatures identiques : 81 entrées sélectionnées, 1 décodée, 4 unsupported, 76 failed, aucun unmatched, aucun not-started et aucune duplication de matérialisation.
• Valider la régression 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.
• Publier le bilan final dans docs/V0_4_6_VALIDATION.md et préparer prompts/026_v0_4_7_metaplex_token_metadata.md.

Modèle de couverture des tokens et actifs numériques

• Les tokens fongibles et les NFT basés sur un mint restent décodés au niveau des mouvements par kb_decoder_spl_token ou kb_decoder_spl_token_2022; il n’existe pas d’instruction Token distincte nommée « NFT ».
• La classification fongible/NFT/SFT est une projection dérivée de la supply, des decimals, des authorities et des standards metadata observés; elle ne doit jamais remplacer l’adresse canonique du mint ou de l’actif.
• Les NFT classiques et programmables liés à un mint sont couverts par le futur kb_decoder_metadata_metaplex_token_metadata (0.4.7).
• Les actifs Metaplex Core, qui ne sont pas des mints SPL Token classiques, sont couverts séparément en 0.4.8.
• Les NFT compressés exigent Bubblegum en plus d’Account Compression et Noop; leur couverture complète est planifiée en 0.4.9.
• Les metadata Token-2022 incorporées, Metaplex externes et implémentations tierces de Token Metadata Interface conservent leur provenance et ne sont jamais fusionnées silencieusement.

0.4.7 — Metaplex Token Metadata

Ce jalon est prioritaire immédiatement après Token-2022. Metaplex Token Metadata n'est pas un programme SPL officiel : il s'agit d'un programme indépendant de la Metaplex Foundation, utilisé comme standard de metadata externe pour SPL Token classique et Token-2022. Son Program ID canonique est metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s et doit être revérifié depuis les sources officielles au début du jalon.

Audit et dépendances

• Lire RULES.md, les contrats decode/materialization/execution/replay, les matrices SPL Token/Token-2022, docs/SOLANA_INTERFACE_DEPENDENCIES.md et le prompt 026 avant tout code.
• Ouvrir l’audit des crates et sources officielles Metaplex réellement disponibles : SDK Rust mpl-token-metadata ^5.1, Program ID, IDL 1.14.0, inventaire généré des instructions et séparation maintenu/historique. Les comptes, builders et PDA détaillés restent à prouver par variante.
• Créer docs/METAPLEX_TOKEN_METADATA_MATRIX.json comme matrice d’audit machine-readable avant le décodage maximal : sources officielles figées, inventaire SDK courant, frontière historique IDL, familles de PDA/comptes et statuts de preuve. L’enrichissement exhaustif par instruction et compte reste requis avant l’activation runtime.
• Ne pas introduire Anchor dans ce jalon : Token Metadata utilise ses propres layouts Borsh et interfaces ; l'infrastructure Anchor reste en 0.4.18, juste avant les protocoles qui en dépendent réellement.
• Conserver wincode ^0.5 tant que les crates Solana utilisées exposent leurs implémentations SchemaRead/SchemaWrite contre wincode 0.5.x; ne pas migrer isolément le workspace vers 0.6.

Journal de préversions

• 0.4.7-pre.001 : ouverture de l’audit officiel, ajout de mpl-token-metadata ^5.1, création de la matrice initiale et des squelettes kb_decoder_metadata_metaplex_token_metadata et kb_executor_metadata_metaplex_token_metadata; aucun décodeur runtime ni builder/exécuteur actif.

• 0.4.7-pre.002 : activer le dispatcher contextualisé et le décodage Borsh exact du premier groupe création/mise à jour (CreateMetadataAccountV3, UpdateMetadataAccountV2), avec comptes ordonnés, outer/CPI, transactions échouées non committées, bornes et diagnostics fail-closed; garder l’enregistrement runtime, la matérialisation et l’exécution pour les groupes suivants.

• 0.4.7-pre.003 : ajouter le groupe de vérification de collection (VerifyCollection, UnverifyCollection, SetAndVerifyCollection) avec discriminateurs officiels, comptes ordonnés, autorité de collection, payer/update authority, collection_authority_record optionnel, outer/CPI, échecs non committés et diagnostics fail-closed; conserver matérialisation, exécution et registre runtime pour des préversions dédiées.

• 0.4.7-pre.004 : décodage du groupe sized collection item (VerifySizedCollectionItem, UnverifySizedCollectionItem, SetAndVerifySizedCollectionItem).

• 0.4.7-pre.005 : décoder l’administration des autorités de collection (ApproveCollectionAuthority, RevokeCollectionAuthority) avec records PDA, autorités distinctes, comptes système/rent et contrats signer/writable exacts.

• 0.4.7-pre.006 : décoder les usages et autorités d’usage (ApproveUseAuthority, RevokeUseAuthority, Utilize) avec compteurs u64, use_authority_record, burner, comptes Token/ATA, comptes système/rent, outer/CPI et échecs non committés.

• 0.4.7-pre.007 : décoder la signature de creator et la déclaration de première vente (SignMetadata, UpdatePrimarySaleHappenedViaToken) avec comptes ordonnés, signer/writable exacts, outer/CPI, échecs non committés et diagnostics fail-closed.

• 0.4.7-pre.008 : décoder la normalisation et la classification metadata (PuffMetadata, RemoveCreatorVerification, SetTokenStandard) avec edition optionnelle, comptes ordonnés et diagnostics fail-closed.

• 0.4.7-pre.009 : décoder CreateMetadataAccountV2 historique (discriminant 16) avec DataV2, mutabilité, comptes exacts et politique non exécutable.

• 0.4.7-pre.010 : décoder CreateMetadataAccount et UpdateMetadataAccount historiques (discriminants 0 et 1) avec layouts Data V1 bornés, comptes exacts et politique non exécutable.

• 0.4.7-pre.011 : décoder CreateMasterEditionV3 et la conversion historique ConvertMasterEditionV1ToV2, avec max_supply, comptes exacts et politique d’exécution distincte.

• 0.4.7-pre.012 : décoder le mint d’éditions imprimées via token et la variante historique vault proxy (MintNewEditionFromMasterEditionViaToken, MintNewEditionFromMasterEditionViaVaultProxy), avec numéro d’édition u64, edition marker et comptes exacts.

• 0.4.7-pre.013 : décoder SetCollectionSize et le bridge BubblegumSetCollectionSize, avec taille u64, autorités/records exacts et frontière Bubblegum explicite.

• 0.4.7-pre.014 : décoder Delegate et Revoke programmables, leurs enums Borsh, 14 comptes positionnels et placeholders optionnels.

• 0.4.7-pre.015 : décoder Transfer, Lock, Unlock, Burn et CloseAccounts, avec enums Borsh, montants u64, comptes programmables exacts et transactions échouées non committées.

• 0.4.7-pre.016 : réauditer exhaustivement l’index officiel des instructions Rust avant le décodage des comptes, puis décoder FreezeDelegatedAccount et ThawDelegatedAccount historiques avec discriminants 26/27, cinq comptes exacts, outer/CPI, échecs non committés et politique decode-only.

• 0.4.7-pre.017 : décoder BurnNft, BurnEditionNft et DeprecatedMintNewEditionFromMasterEditionViaPrintingToken historiques avec discriminateurs 29/37/3, comptes exacts, comptes optionnels de fin, outer/CPI, échecs non committés et politique decode-only.

• 0.4.7-pre.018 : décoder CreateEscrowAccount, CloseEscrowAccount, TransferOutOfEscrow et Collect, avec montant u64, authorities optionnelles, comptes exacts et diagnostics fail-closed.

• 0.4.7-pre.019 : décoder le wrapper moderne Create (42) avec CreateArgs::V1, neuf comptes positionnels et placeholders optionnels exacts.

• 0.4.7-pre.020 : décoder le wrapper moderne Mint (43) avec MintArgs::V1, montant u64, AuthorizationData, quinze positions et placeholders optionnels exacts.

• 0.4.7-pre.021 : décoder le wrapper moderne Print (55) avec PrintArgs::V1/V2, édition u64, dix-huit positions et Token Record optionnel exact.

• 0.4.7-pre.022 : décoder le wrapper moderne Update (50) et toutes les variantes UpdateArgs V1/V2, avec onze positions et placeholders optionnels exacts.

• 0.4.7-pre.023 : décoder les wrappers modernes Use (51), Verify (52) et Unverify (53) avec leurs enums Borsh, comptes positionnels, placeholders optionnels, outer/CPI et échecs non committés.

• 0.4.7-pre.024 : décoder Resize (56), Migrate (48) et les six discriminateurs historiques manquants 2/5/6/8/9/10, puis prouver une couverture exhaustive des 58 discriminateurs 0..=57.

• 0.4.7-pre.025 : décoder le compte Metadata, vérifier owner, discriminant MetadataV1, bornes officielles et PDA canonique [metadata, program_id, mint], sans encore enregistrer le décodeur stateful dans le pipeline.

• 0.4.7-pre.026 : décoder DeprecatedMasterEditionV1, MasterEditionV2 et EditionV1, vérifier owner, layouts bornés et PDA commun [metadata, program_id, mint, edition], tout en conservant V1 comme état historique decode-only.

• 0.4.7-pre.027 : décoder EditionMarker et EditionMarkerV2, vérifier owner, bitmaps, groupes de 248 éditions, seeds PDA V1/V2 et longueurs Borsh exactes.

• 0.4.7-pre.028 : décoder TokenRecord, vérifier owner, layout fixe de 80 octets, PDA mint/token account, bump stocké, états programmables, delegate, rôle et locked transfer.

• 0.4.7-pre.029 : décoder MetadataDelegateRecord, HolderDelegateRecord, CollectionAuthorityRecord et UseAuthorityRecord, avec longueurs, rôles-seeds, PDA et bumps exacts.

• 0.4.7-pre.030 : décoder TokenOwnedEscrow, distinguer TokenOwner/Creator, vérifier les deux familles de seeds PDA, longueurs Borsh et bump stocké, puis documenter les transitions stateful escrow/migrate/resize sans les matérialiser prématurément.

• 0.4.7-pre.031 : décoder ReservationListV1/V2 historiques, préserver compteurs, supply snapshot, caches et PDA dépendant de resource, avec limites officielles et politique decode-only.

• 0.4.7-pre.032 : inventaire exhaustif des quinze variantes Key, liaison de chaque layout à son décodeur, sentinelle Uninitialized explicitement rejetée et audit fail-closed des futures variantes upstream.

• 0.4.7-pre.033 : ajouter l’enveloppe canonique des snapshots, l’identité stable program_id:account, la version de layout, les classes actif/historique/expérimental et la provenance live/replay/backfill/repair ; rendre explicite que les comptes historiques sont matérialisables mais jamais exécutables.

• 0.4.7-pre.034 : règles décodeur/matérialiseur/exécuteur renforcées ; projection canonique commitée de MetadataV1, snapshot owned autoritatif et absence de doublon d’état avec les observations d’instructions.

• 0.4.7-pre.035 : matérialiser les autres comptes Metaplex actifs, expérimentaux et historiques avec identité stable, lifecycle, provenance et propriétaire unique des faits.

Audit canonique des comptes 0.4.7

• Auditer les quinze variantes Key publiées (0..=14) et relier chaque compte réel à un décodeur borné.
• Rejeter explicitement Key::Uninitialized et toute variante future inconnue sans projection partielle.
• Vérifier par test les discriminateurs Borsh du SDK épinglé, l’unicité de l’inventaire et sa correspondance avec la matrice.
• Définir l’identité stable canonique program_id:account, le nom de layout, le discriminant et la version canonique.
• Distinguer explicitement lifecycle, politique de matérialisation et politique d’exécution.
• Autoriser la matérialisation des comptes historiques comme état historique de backfill/replay, sans jamais les exposer à l’exécuteur.
• Conserver source, slot, write version, signature, index outer/inner et statut committed dans la provenance canonique.

Découpage prévisionnel restant de 0.4.7

• pre.036 : intégration du décodeur de comptes dans kb_pipeline, routage owner/discriminant, replay, fermeture de comptes, ordering et déduplication.
• pre.037 : corrélation instructions/comptes avant-après et vérification stateful des observations décodées.
• pre.038 : exécuteur moderne de base (Create, Update, Mint, Print, Verify, Unverify, Use, Resize, Migrate) avec builders officiels et simulation-first.
• pre.039 : exécuteur programmable (Delegate, Revoke, Transfer, Lock, Unlock, Burn) avec Token Records et Authorization Rules.
• pre.040 : exécuteur collection/use/admin, en excluant formellement les opérations historiques.
• pre.041 : preflight stateful complet, postconditions et replay de confirmation idempotent.
• pre.042 : intégration kb_app_demo, bindings et scénarios PostgreSQL/replay/dry-run.
• pre.043 : corpus Mainnet de signatures et comptes historiques/actifs.
• pre.044 : validations Devnet et Localnet des opérations encore appelables.
• pre.045 : audit de non-duplication et conflits de provenance Metaplex externe / Token-2022 incorporée / Metaplex Core.
• pre.046 : audit final, documentation, changelog, prompt de session suivant et clôture de 0.4.7.

Frontière du décodeur

• Créer le squelette canonique kb_decoder_metadata_metaplex_token_metadata, borné au Program ID Metaplex vérifié, sans enregistrement runtime ni prétention de décodage dans 0.4.7-pre.001.
• Créer le squelette canonique kb_executor_metadata_metaplex_token_metadata, audit-only et sans builder runtime avant validation exacte des comptes, autorités, coûts, confirmations et postconditions stateful.
• Réutiliser le Program ID déjà enregistré dans kb_program_ids, puis ajouter les capacités au registre runtime et aux options Tauri seulement après validation du premier corpus, sans heuristique fondée seulement sur un PDA ou un discriminant.
• Préserver signature, slot, outer/CPI, chemin d'instruction, statut de transaction, payload hash, comptes ordonnés, signers/writable et provenance de layout.
• Produire des diagnostics stables et bornés pour discriminant inconnu, payload tronqué/suffixé, comptes manquants/supplémentaires, PDA incohérent, owner incorrect, enum future et chaîne/vecteur hors limites.
• Classer les variantes futures ou non prouvées en Unsupported, et les payloads structurellement invalides en Failed, sans projection partielle trompeuse.

Décodage des instructions

• Inventorier et couvrir les générations historiques et actuelles publiées de création et mise à jour de metadata (CreateMetadataAccount, V2, V3, UpdateMetadataAccount, V2).
• Couvrir création de master edition, edition, edition marker et mint d'éditions, avec limites numériques et PDA exacts.
  • Décoder CreateMasterEditionV3 et ConvertMasterEditionV1ToV2 avec wire et comptes exacts.
  • Décoder le mint d'éditions via token et vault proxy, avec numéro d'édition u64, edition marker et comptes exacts.
  • Décoder et valider les comptes edition/edition marker ainsi que leurs PDA dans la tranche de décodage d’état.
• Couvrir vérification/dé-vérification de créateurs et collections, collection size/details et autorités de collection.
  • Décoder SetCollectionSize et BubblegumSetCollectionSize avec taille u64, flags exacts et record optionnel.
  • Valider les PDA/owners des collection authority records lors du décodage des comptes on-chain.
• Couvrir uses, approve/revoke use authority et consommation d'usage avec comptes exacts.
• Couvrir délégations et révocations metadata/collection/use/sale/transfer/utility/staking/programmable lorsqu'elles sont officiellement définies.
• Couvrir les opérations programmables actuelles : transfer, lock, unlock, burn, delegate, revoke et authorization data/rule set lorsque le wire exact est prouvé. La validation stateful des rule sets et PDA reste planifiée séparément.
• Couvrir les migrations et instructions historiques encore observables sans les confondre avec les variantes actuelles.
  • Décoder FreezeDelegatedAccount et ThawDelegatedAccount historiques avec leurs cinq comptes exacts et les conserver decode-only.
  • Décoder les burns NFT historiques et le mint déprécié via printing token (BurnNft, BurnEditionNft, DeprecatedMintNewEditionFromMasterEditionViaPrintingToken).
  • Décoder les instructions escrow/collect (CreateEscrowAccount, CloseEscrowAccount, TransferOutOfEscrow, Collect) avec wire et comptes exacts.
  • Décoder le wrapper moderne Create (42) avec CreateArgs::V1, neuf comptes positionnels et placeholders optionnels exacts.
  • Décoder le wrapper moderne Mint (43) avec MintArgs::V1, quinze comptes positionnels et placeholders optionnels exacts.
  • Décoder le wrapper moderne Print (55) avec PrintArgs::V1/V2, dix-huit comptes positionnels et Token Record optionnel exact.
  • Décoder le wrapper moderne Update (50) et ses variantes V1/As…V2 avec wire et comptes exacts.
  • Décoder les wrappers modernes Use, Verify et Unverify avec leurs variantes et contrats positionnels exacts.
  • Décoder Resize et Migrate, couvrir les six discriminateurs historiques manquants 2/5/6/8/9/10 et prouver l’inventaire exhaustif 0..=57.
• Préserver tous les champs wire significatifs : autorités, creators, seller fee basis points, collection, uses, token standard, collection details, programmable config et authorization data pour les instructions actuellement couvertes.

Intégration kb_pipeline et kb_app_demo

• Enregistrer le décodeur dans le registre runtime de kb_pipeline après stabilisation de la matrice d’instructions et des comptes.
• Ajouter les tests kb_pipeline pour outer/CPI, transactions échouées, replay, déduplication et routage vers les matérialiseurs.
• Ajouter les tests kb_pipeline de matérialisation idempotente et d’orchestration d’exécution simulation-first.
• Enregistrer décodeur, matérialiseurs et exécuteur dans kb_app_demo, puis couvrir les campagnes replay et les scénarios PostgreSQL.
• Valider dans kb_app_demo les refus explicites des instructions historiques/non supportées et les commandes Tauri éventuelles.

Décodage des comptes et PDA

• Parser et versionner Metadata, MasterEditionV1/V2, Edition, EditionMarker, EditionMarkerV2, TokenRecord, MetadataDelegateRecord, CollectionAuthorityRecord, UseAuthorityRecord et tout autre compte officiel confirmé.
  • pre.025 : parser MetadataV1, conserver les champs descriptifs et administratifs, et produire une projection JSON bornée.
  • pre.026 : parser DeprecatedMasterEditionV1, MasterEditionV2 et EditionV1, conserver supply/max supply, printing mints historiques, parent et numéro d’édition.
  • pre.027 : parser EditionMarker et EditionMarkerV2, conserver ledger, groupe V1, index d’octet, masque et état de l’édition demandée.
  • pre.028 : parser TokenRecord, conserver bump, état programmable, révision du rule set, delegate, rôle et locked transfer.
  • pre.029 : parser les records Metadata/Holder Delegate, Collection Authority et Use Authority avec leurs champs exacts.
  • pre.030 : parser TokenOwnedEscrow, conserver base token, autorité TokenOwner/Creator et bump.
  • pre.031 : parser ReservationListV1/V2, conserver Master Edition, supply snapshot, réservations et caches historiques en decode-only.
• Vérifier l'owner du compte avant tout parsing et refuser les comptes étrangers même si leur payload ressemble au layout attendu.
  • pre.025 : appliquer cette frontière au compte Metadata avant toute désérialisation.
  • pre.026 : appliquer la même frontière aux comptes edition/master edition avant toute désérialisation.
  • pre.027 : appliquer cette frontière aux Edition Markers avant toute lecture du discriminant ou du ledger.
  • pre.028 : appliquer cette frontière au Token Record avant toute lecture de l’état programmable.
  • pre.029 : appliquer cette frontière aux quatre familles de records avant désérialisation.
  • pre.030 : appliquer cette frontière à Token Owned Escrow avant lecture de l’autorité.
  • pre.031 : appliquer cette frontière aux Reservation Lists avant lecture de leur génération historique.
• Vérifier les PDA canoniques et l'ordre exact des seeds pour metadata, edition/master edition, edition markers, token records, delegates, collection authorities et use authorities.
  • pre.025 : valider le PDA Metadata exact [b"metadata", program_id, mint] et conserver le bump.
  • pre.026 : valider le PDA edition/master edition exact [b"metadata", program_id, mint, b"edition"] et conserver le bump.
  • pre.027 : valider le PDA V1 [metadata, program_id, mint, edition, edition/248 décimal] et le PDA V2 [metadata, program_id, mint, edition, marker].
  • pre.028 : valider le PDA Token Record [metadata, program_id, mint, token_record, token_account] et le bump stocké.
  • pre.029 : valider les PDA exacts des records Metadata/Holder Delegate, Collection Authority et Use Authority.
  • pre.030 : valider les PDA escrow TokenOwner [metadata, program_id, base_token, 0, escrow] et Creator [metadata, program_id, base_token, 1, creator, escrow], ainsi que le bump stocké.
  • pre.031 : valider le PDA Reservation List [metadata, program_id, master_edition, reservation, resource] avec contexte resource explicite.
• Borner strictement noms, symboles, URI, creators, options, enums et données d'autorisation ; distinguer taille minimale, taille exacte et compte extensible.
  • pre.025 : borner Metadata à 1 024 octets, name à 32, symbol à 10, URI à 200 et creators à 5.
  • pre.026 : borner edition/master edition à 128 octets et exiger exactement 41 octets pour EditionV1.
  • pre.027 : exiger 32 octets pour V1, une longueur Borsh sans suffixe pour V2 et un ledger V2 borné à 1 048 576 octets.
  • pre.028 : exiger exactement 80 octets pour Token Record et refuser troncature, suffixe, clé ou bump incohérents.
  • pre.029 : exiger 98 octets pour les delegate records, 10 pour Use Authority et les deux tailles Borsh Collection Authority.
  • pre.030 : exiger 35 octets pour TokenOwner et 67 pour Creator, sans suffixe.
  • pre.031 : limiter les listes à 200 entrées, 6 949 octets pour V1 et 9 749 pour V2, avec padding nul uniquement.
• Corréler mint, token account, edition, collection et rule set uniquement lorsque toutes les identités sont prouvées.
• Conserver explicitement la provenance metaplex_token_metadata, distincte de token_2022_embedded_metadata et de metaplex_core.

Matérialisation

• Étendre kb_materializer_metadata comme propriétaire unique des faits descriptifs : nom, symbole, URI, seller fee, creators, collection, uses, token standard, mutabilité, collection details, programmable config et provenance.
  • pre.034 : matérialiser MetadataV1 comme snapshot owned autoritatif, stable et commité, sans doublon avec les observations d’instructions.
  • pre.035 : matérialiser Edition/Master Edition, Edition Marker et Reservation Lists historiques avec lifecycle et provenance explicites.
• Étendre kb_materializer_admin pour update authority, collection authority, delegates, rule set authority et changements d'autorité prouvés.
  • pre.035 : projeter les Delegate Records et Authority Records avec kb_materializer_admin déclaré comme propriétaire unique du fait administratif.
• Étendre kb_materializer_lifecycle pour création, mise à jour, édition, verify/unverify, mint d'édition, burn, lock/unlock et transitions programmables prouvées.
  • pre.035 : projeter Token Record et Token Owned Escrow avec kb_materializer_lifecycle déclaré comme propriétaire unique du fait de lifecycle.
• Étendre kb_materializer_risk/compliance_audit pour creators non vérifiés, metadata mutable, royalties, délégations sensibles, rule sets et conflits de provenance, sans dupliquer les faits metadata.
• Définir une identité canonique stable par mint/asset + source + compte metadata, avec event_key/output_key idempotents.
  • pre.033–035 : utiliser program_id:account et un output_key stable par compte pour les snapshots actifs, expérimentaux et historiques.
• Conserver simultanément metadata Metaplex externe et metadata Token-2022 incorporée ; exposer source, autorité, slot, priorité de lecture et conflits sans fusion silencieuse.
• Refuser toute matérialisation engagée issue d'une transaction Solana en échec.

Exécuteur et préflight

• Créer ou finaliser kb_executor_metadata_metaplex_token_metadata uniquement après audit des builders officiels et de leurs comptes exacts.
• Définir des intents typés pour les opérations officiellement constructibles ; retourner Unsupported(reason) pour les surfaces sans builder/wire suffisamment prouvé.
• Préserver l'ordre exact des metas, signers, writable, PDA, authorities, payer, token program et system/sysvar programs.
• Imposer simulation-first, dry-run par défaut, plafond de frais/dépense et confirmation opérateur dédiée pour burn, authority changes, verify/unverify, delegate/revoke, lock/unlock et opérations programmables.
• Ajouter les prélectures stateful : owner, layout/version, PDA, mint/token account, update authority, collection authority, delegate, token standard, rule set, état locked/burned et cohérence avec SPL Token/Token-2022.
• Définir des postconditions exactes et un replay de confirmation idempotent avant d'autoriser une opération comme réussie.
• Ne jamais télécharger le JSON externe référencé par URI dans le chemin critique de construction, simulation ou confirmation on-chain.

JSON externe et sécurité

• Concevoir le fetch HTTP/IPFS/Arweave comme composant optionnel séparé du décodeur canonique on-chain.
• Borner timeout, taille, content type, redirections, nombre de tentatives, cache et concurrence ; conserver URL finale, hash, provenance et date d'observation.
• Bloquer SSRF, localhost, réseaux privés/link-local et schémas non autorisés ; ne jamais faire confiance aux champs du JSON distant.
• Ne jamais faire dépendre le statut Decoded on-chain de la disponibilité ou de la validité du contenu externe.
• Autoriser une première livraison sans fetch actif si l'isolation et les politiques réseau ne sont pas encore entièrement prouvées.

Corpus, replay et validation

• Ajouter un corpus synthétique couvrant chaque instruction, compte, PDA et branche de diagnostic, avec valeurs limites et variantes historiques/currentes.
• Ajouter des signatures Mainnet réelles pour token fongible, NFT, SFT, collection sized/unsized, master edition, edition et programmable NFT.
• Couvrir outer et CPI, transactions réussies et échouées, comptes dupliqués/manquants, mauvais Program ID/owner/PDA, payload tronqué/suffixé et discriminant inconnu.
• Ajouter des cas de conflit entre metadata Metaplex externe et metadata Token-2022 incorporée, sans perte de provenance.
• Enregistrer le décodeur et les materializers dans kb_pipeline et kb_app_demo, avec démonstration de lecture des observations/projections.
• Vérifier le replay PostgreSQL idempotent, l'absence de doublons decode/materialization et le mode incomplete_signatures sans forceReplay global.
• Valider avec PostgreSQL réel, tests ciblés, tests pipeline/app demo, bindings Tauri si modifiés et cargo clippy --all-targets propre.

Documentation et clôture

• Mettre à jour les README des crates touchées, README.md, docs/SOLANA_INTERFACE_DEPENDENCIES.md, la matrice dédiée et les contrats de provenance metadata.
• Documenter précisément les surfaces observées sur Mainnet, celles seulement synthétiques, les variantes Unsupported et les limites du fetch externe.
• Mettre à jour CHANGELOG.md et cocher ce jalon seulement après validations réelles.
• Préparer le prompt suivant 0.4.8 — Metaplex Core sans mélanger les actifs Core avec les mints SPL/Token-2022.

0.4.8 — Metaplex Core

Metaplex Core est un standard d’actifs indépendant qui ne repose pas sur un mint SPL Token pour représenter chaque NFT. Il doit donc disposer de sa propre frontière de programme et ne pas être traité comme une simple variante de metadata SPL.

• Créer kb_decoder_metaplex_core avec Program IDs, comptes Asset/Collection et plugins audités depuis les sources Metaplex officielles.
• Décoder les opérations et états des actifs Core, collections, authorities, royalties, attributes et plugins sans les fusionner avec Metaplex Token Metadata.
• Matérialiser une identité d’actif canonique avec provenance metaplex_core, distincte des mints SPL Token/Token-2022.
• Ajouter exécuteur, corpus, démo et replay seulement après validation exacte des comptes et autorités.

0.4.9 — SPL Account Compression, Noop et Metaplex Bubblegum

Ce jalon remonte avant les pools de stake : Bubblegum dépend directement d’Account Compression et de Noop, et complète la couverture NFT ouverte par Metaplex Token Metadata et Metaplex Core.

• Réserver kb_executor_spl_account_compression, kb_executor_spl_noop et kb_executor_nft_metaplex_bubblegum sans activer d’envoi.
• Implémenter kb_decoder_spl_account_compression et kb_decoder_spl_noop.
• Finaliser kb_decoder_nft_metaplex_bubblegum pour les instructions, arbres, feuilles et metadata des NFT compressés ; ne pas considérer Compression/Noop seuls comme un décodeur NFT complet.
• Corréler Bubblegum, Account Compression et Noop sans fusionner leurs frontières de programme ni dupliquer les événements.
• Matérialiser l’identité des actifs compressés avec arbre, leaf index, asset id, owner/delegate, collection et metadata prouvées.
• N’activer les exécuteurs qu’après validation des preuves Merkle, coûts et builders officiels.

0.4.10 — SPL Stake Pool

• Décoder maximalement SPoo1... dans kb_decoder_spl_stake_pool.
• Distinguer le pool SPL du Stake Program natif, adapter staking, reward, fee, admin et lifecycle, puis développer kb_executor_spl_stake_pool après validation du décodeur.

0.4.11 — SPL Single Pool

• Réserver kb_executor_spl_single_pool sans activer d’envoi.
• Implémenter kb_decoder_spl_single_pool pour SVSPx....
• Couvrir et matérialiser lifecycle, dépôts/retraits, mint LST et récompenses, puis activer kb_executor_spl_single_pool seulement après validation des projections.

0.4.12 — SPL Token Wrap

Token Wrap est un programme SPL actuel et audité, destiné au wrapping bidirectionnel entre SPL Token classique et Token-2022. Il ne doit pas être classé avec les programmes historiques.

• Ajouter le Program ID canonique TwRapQCDhWkZRrDaHfZGuHxkZ91gHDRkyuzNqeU5MgR à kb_program_ids après vérification finale des sources officielles.
• Créer kb_decoder_spl_token_wrap et auditer instructions, comptes d’état, PDA, mints source/wrapped et contrats de conversion.
• Matérialiser le lien canonique entre mint source et mint wrapped sans fusionner leurs balances, supplies, authorities ou metadata.
• Créer kb_executor_spl_token_wrap uniquement après preuve des builders, coûts, decimals, ratios et conditions de fermeture/unwrapping.
• Ajouter corpus réel, démo, préflight et replay PostgreSQL idempotent.

0.4.13 — SPL Token Swap

SPL Token Swap reste dans la série 0.4.x : il s’agit d’un programme SPL autonome avec Program ID propre, même si son domaine fonctionnel est un AMM. Les phases AMM ultérieures couvriront les protocoles tiers et réutiliseront les abstractions établies ici.

• Vérifier et enregistrer le Program ID officiel SwapsVeCiPHMUAtzQWZw7RjsKjgCjhwU55QGu4U1Szw dans kb_program_ids.
• Créer kb_decoder_spl_token_swap et auditer instructions, courbes, fees, états de pool, autorités et compatibilité Token classique/Token-2022.
• Matérialiser pools, liquidité, swaps, fees et lifecycle sans dupliquer les mouvements Token sous-jacents.
• Créer kb_executor_spl_token_swap seulement après preuve des courbes, slippage, comptes ordonnés, builders et simulations.
• Ajouter corpus réel, démo, préflight et replay PostgreSQL idempotent.

0.4.14 — SPL Token Lending

SPL Token Lending reste également dans 0.4.x : c’est un programme SPL autonome avec Program ID propre. Les phases Lending ultérieures couvriront Solend, Kamino et les autres protocoles dérivés ou indépendants.

• Vérifier et enregistrer le Program ID officiel 6TvznH3B2e3p2mbhufNBpgSrLx6UkgvxtVQvopEZ2kuH dans kb_program_ids.
• Créer kb_decoder_spl_token_lending et auditer markets, reserves, obligations, collateral, liquidations, flash loans, oracles et autorités.
• Matérialiser lending, borrowing, collateral, interest, liquidation, fees et risk sans dupliquer les transferts Token.
• Créer kb_executor_spl_token_lending uniquement après validation des calculs, oracles, slippage, health factor et simulation.
• Ajouter corpus réel, démo, préflight et replay PostgreSQL idempotent.

0.4.15 — SPL Name Service

• Réserver kb_executor_metadata_spl_name_service sans activer d’envoi.
• Implémenter kb_decoder_metadata_spl_name_service pour namesLPne....
• Décoder puis matérialiser metadata/admin/lifecycle des noms, puis activer kb_executor_metadata_spl_name_service après validation des autorités et coûts.

0.4.16 — SPL Governance et programmes utilitaires déployés

• Auditer les déploiements et versions encore pertinents de SPL Governance, Feature Proposal, Record, Shared Memory et Instruction Padding depuis leurs dépôts maintenus ou forks officiels identifiés.
• Créer des jalons internes séparés par Program ID ; ne pas regrouper leurs wire formats dans un décodeur générique « SPL utilities ».
• Prioriser Governance si des stratégies ou materializations de vote/DAO en dépendent ; conserver Feature Proposal, Record, Shared Memory et Instruction Padding comme surfaces d’infrastructure à priorité moindre.
• Distinguer strictement les programmes déployés, les interfaces sans Program ID universel et les implémentations tierces.

0.4.17 — SPL historique ou archivé

• Auditer Managed Token, Stateless Asks, Token Upgrade, Binary Option et Binary Oracle Pair avant toute réservation de crate ou Program ID.
• Auditer Token Collection et les anciennes implémentations Token Metadata/Token Group uniquement comme sources historiques ou compatibilité, sans les confondre avec les interfaces actuelles.
• Ne pas attribuer un Program ID universel aux interfaces Token Group, Token Metadata ou Transfer Hook ; dispatcher vers les implémentations observées.

0.4.18 — infrastructure de décodage Anchor

Anchor est un framework et un ensemble de conventions, pas un programme Solana unique. Les programmes SPL planifiés dans 0.4.x utilisent leurs propres interfaces et n’exigent pas cette couche. Le jalon Anchor est donc placé immédiatement avant Meteora afin de fournir l’infrastructure commune requise par Meteora, Pump, Raydium et les autres programmes Anchor, sans remplacer leurs décodeurs protocolaires ni accepter un discriminant isolé comme preuve d’identité.

• Auditer les versions Anchor réellement rencontrées, les discriminateurs d’instruction et de compte, les événements Program data:, les erreurs, les IDL historiques/courantes et les différences entre générations.
• Définir un registre versionné Program ID + provenance IDL + hash/version + cluster + plage de slots ; refuser tout décodage lorsqu’aucun descripteur vérifié ne correspond au programme et à sa version observée.
• Créer une couche commune pour les enveloppes, comptes, événements et erreurs Anchor, tout en laissant aux crates Meteora/Pump/Raydium leurs Program IDs, leur sémantique métier, leurs invariants, leurs matérialisations et leurs exécuteurs.
• Décoder outer et CPI avec chemins exacts, comptes ordonnés, discriminateurs vérifiés, arguments Borsh bornés et politique explicite pour suffixes, troncatures et versions inconnues.
• Extraire les événements Anchor depuis les logs sans les confondre avec des logs texte arbitraires, conserver l’ordre d’émission et rattacher chaque événement à l’instruction/CPI source lorsque la pile d’invocation le permet.
• Décoder les comptes Anchor uniquement avec owner/program ID, discriminant et layout IDL vérifiés ; conserver les comptes inconnus ou versions futures comme Unsupported, jamais comme état partiellement inventé.
• Définir les contrats de fallback pour les programmes sans IDL publique, les IDL obsolètes, les upgrades et les collisions de discriminateurs entre Program IDs.
• Ajouter une matrice machine-readable, des corpus synthétiques/Mainnet et des tests anti-collision prouvant qu’un même discriminant sous deux Program IDs ne partage jamais silencieusement le même sens.
• Raccorder incomplete_signatures afin qu’une nouvelle IDL ou version de descripteur puisse reprendre uniquement les signatures Anchor non complètement décodées.
• Préparer 0.5.x — Meteora : les décodeurs Meteora doivent consommer cette infrastructure pour le wire commun, tout en conservant leurs frontières protocolaires propres.

0.4.19 — clôture Solana Core/SPL et metadata adjacente

• Exécuter le replay complet des corpus 0.3.x et des corpus SPL dédiés.
• Vérifier couverture, matérialisations, idempotence, versions de processor et absence de régression.
• Produire la documentation des événements core/SPL disponibles pour les stratégies.

Version 0.5.x — Meteora

Les surfaces AMM et de liquidité précèdent le launchpad DBC dans l’ordre de développement.

0.5.0 — corpus et surfaces Meteora

• Constituer les corpus dédiés DLMM, DAMM v1, DAMM v2, DBC et Vault.
• Vérifier tous les Program IDs dans kb_program_ids.
• Auditer IDL/interfaces, comptes, événements, autorités et frais.
• Établir la matrice complète instructions/events/materializations/executors.

0.5.1 — Meteora DLMM

• Décoder maximalement instructions, événements, bins, positions et lifecycle.
• Matérialiser pools, bins, positions, liquidité, swaps, fees et changements administratifs.
• Implémenter kb_executor_dlmm_meteora après validation du décodeur, avec slippage, limites de liquidité, autorités et coûts bornés.

0.5.2 — Meteora DAMM v1

• Décoder maximalement instructions, événements et états de pool.
• Matérialiser pools, liquidité, swaps, fees et lifecycle sans dupliquer les mouvements Token.
• Implémenter kb_executor_amm_meteora_damm_v1 pour les opérations client officiellement appelables.

0.5.3 — Meteora DAMM v2

• Décoder maximalement instructions, événements et états de pool.
• Matérialiser pools, liquidité, swaps, fees et lifecycle.
• Implémenter kb_executor_amm_meteora_damm_v2 avec quotes, slippage, plafonds et simulation.

0.5.4 — Meteora DBC

• Décoder maximalement le launchpad DBC après stabilisation des AMM et Vault.
• Matérialiser créations, courbes, migrations, liquidité, paramètres et risques observables.
• Implémenter kb_executor_launchpad_meteora_dbc pour les opérations client officiellement appelables.

0.5.5 — Meteora Vault

• Auditer et décoder les surfaces Vault et complémentaires réellement confirmées.
• Matérialiser dépôts, retraits, parts, stratégies, fees et lifecycle.
• Implémenter kb_executor_vault_meteora uniquement pour les opérations appelables validées.

0.5.6 — régression Meteora

• Fusionner les corpus Meteora et rejouer toutes les surfaces.
• Vérifier interactions, idempotence et régressions croisées.
• Valider les cinq exécuteurs offline et sur localnet/devnet, puis enregistrer coûts, autorités et exposition dans la matrice.

Version 0.6.x — Pump

Les surfaces AMM Pump Swap sont traitées avant le launchpad Pump Fun.

0.6.0 — corpus et surfaces Pump

• Constituer des corpus dédiés Pump Swap, Pump Fun et Pump Fees.
• Vérifier tous les Program IDs dans kb_program_ids.
• Établir la matrice complète instructions/events/materializations.

0.6.1 — Pump Swap

• Décoder toutes les instructions et événements connus.
• Matérialiser trades, liquidité, lifecycle et changements administratifs.
• Implémenter kb_executor_amm_pump_swap maximalement pour les opérations client appelables, avec quotes/plafonds/slippage et comparaison au contrat officiel.

0.6.2 — Pump Fun

• Décoder toutes les instructions et événements connus, y compris les entrées non directement liées au trading.
• Matérialiser créations, migrations, trades, liquidité, paramètres et risques observables.
• Implémenter kb_executor_launchpad_pump_fun après stabilisation du décodeur : builders officiels/IDL validés, autorités, coûts, slippage, simulation et tests devnet ; l’exposition trading reste une décision séparée.

0.6.3 — Pump Fees

• Décoder toutes les instructions et événements connus.
• Matérialiser les signaux de frais, buyback, partage, donation et changements d’autorité utiles à la gestion du risque.
• Implémenter kb_executor_admin_pump_fees pour les opérations administratives officiellement appelables, avec politiques d’autorité renforcées et aucune exposition UI par défaut.

0.6.4 — régression Pump

• Fusionner les corpus Pump et rejouer toutes les surfaces.
• Vérifier les interactions et régressions croisées.
• Valider les trois exécuteurs Pump offline et sur devnet/localnet, puis enregistrer leur statut exact dans la matrice décodeur/matérialiseur/exécuteur.

Version 0.7.x — Raydium

Les surfaces AMM précèdent le launchpad LaunchLab.

0.7.0 — corpus et surfaces Raydium

• Constituer les corpus AMM v4, CPMM, CLMM, Stable Swap et LaunchLab.
• Vérifier tous les Program IDs et versions de programme dans kb_program_ids.
• Auditer instructions, événements, états, autorités, fees et courbes.
• Établir la matrice complète instructions/events/materializations/executors.

0.7.1 — Raydium AMM v4

• Décoder maximalement instructions, événements et comptes historiques/courants.
• Matérialiser pools, liquidité, swaps, fees et lifecycle.
• Implémenter kb_executor_amm_raydium_lp_v4 après preuve des builders et limites.

0.7.2 — Raydium CPMM

• Décoder maximalement instructions, événements et états CPMM.
• Matérialiser pools, liquidité, swaps, fees et lifecycle.
• Implémenter kb_executor_cpmm_raydium avec quotes, slippage et plafonds.

0.7.3 — Raydium CLMM

• Décoder maximalement instructions, événements, ticks, positions et rewards.
• Matérialiser pools, ticks, positions, liquidité, swaps, fees et rewards.
• Implémenter kb_executor_clmm_raydium avec bornes de ticks, slippage et coûts.

0.7.4 — Raydium Stable Swap

• Auditer les surfaces actuelles et historiques confirmées sans inventer de programme générique.
• Décoder et matérialiser uniquement les contrats dont le Program ID et le wire sont prouvés.
• N’activer un exécuteur qu’après identification d’une interface ou crate canonique.

0.7.5 — Raydium LaunchLab

• Décoder maximalement LaunchLab après stabilisation des AMM.
• Matérialiser créations, migrations, liquidité, paramètres et risques observables.
• Implémenter kb_executor_launchpad_raydium_launchlab pour les opérations client appelables.

0.7.6 — régression Raydium

• Fusionner les corpus Raydium et rejouer toutes les surfaces.
• Vérifier interactions, idempotence et régressions croisées.
• Valider les exécuteurs confirmés offline/localnet/devnet et enregistrer coûts, slippage et autorités.

Version 0.8.x — Orca

La surface AMM Whirlpool précède le launchpad Wavebreak.

0.8.0 — corpus et surfaces Orca

• Constituer les corpus Whirlpool, Wavebreak et surfaces complémentaires confirmées.
• Vérifier tous les Program IDs et versions dans kb_program_ids.
• Auditer instructions, événements, comptes, authorities, fees et matrice commune.

0.8.1 — Orca Whirlpool

• Décoder maximalement instructions, événements, ticks, positions et rewards.
• Matérialiser pools, ticks, positions, liquidité, swaps, fees et rewards.
• Implémenter kb_executor_clmm_orca_whirlpool avec slippage, bornes de ticks, positions, liquidité et autorités.

0.8.2 — Orca Wavebreak

• Décoder maximalement le launchpad après stabilisation de Whirlpool.
• Matérialiser créations, migrations, liquidité, paramètres et risques observables.
• Implémenter kb_executor_launchpad_orca_wavebreak pour les opérations client officiellement appelables.

0.8.3 — régression Orca

• Fusionner les corpus Orca et rejouer toutes les surfaces.
• Vérifier interactions, idempotence et régressions croisées.
• Valider les exécuteurs offline/localnet/devnet et enregistrer leur statut dans la matrice.

Version 0.9.x — Jupiter, routeurs et surfaces complémentaires

• Décoder Jupiter Aggregator v4/v6 et les routes multi-hop, puis implémenter kb_executor_router_jupiter_aggregator_v4 et kb_executor_router_jupiter_aggregator_v6 après validation des contrats encore appelables.
• Décoder Jupiter DCA puis implémenter kb_executor_router_jupiter_dca pour les opérations officiellement appelables.
• Décoder Jupiter Limit Order v1/v2 puis implémenter kb_executor_orderbook_jupiter_limit_order et kb_executor_orderbook_jupiter_limit_order_v2.
• Décoder Jupiter Perpetuals puis implémenter kb_executor_perpetuals_jupiter avec politiques de marge, collateral, levier, prix et liquidation renforcées.
• Traiter les surfaces Jupiter lending/admin/wallet selon les crates réservées correspondantes ; chaque décodeur validé reçoit un statut d’exécuteur explicite, pas une promesse générique Jupiter.
• Décoder Jupiter même lorsque la source temps réel n’est pas directement abonnée au program id Jupiter.
• Ajouter OKX/Onchain Labs et DFlow après validation des program ids, puis leurs exécuteurs réservés kb_executor_router_okx_labs_v1, kb_executor_router_okx_labs_v2 et kb_executor_router_dflow_aggregator_v4.
• Ajouter Bags Fee Share v1/v2 puis kb_executor_fees_bags_fee_share_v1 et kb_executor_fees_bags_fee_share_v2, avec garde-fous administratifs et aucune exposition trading implicite.
• Mesurer quelles routes Jupiter sont déjà reçues via les DEX sous-jacents.
• Valider les exécuteurs routeur/orderbook/perpetuals offline puis localnet/devnet ; l’activation live dépend de quotes exactes, slippage, limites de dépense et validation post-exécution.

Version 0.10.x — démonstrations Devnet Solana Core

Le scan de kb_decoder_solana_core et kb_executor_solana_core confirme que System, Compute Budget, Address Lookup Table, Stake et Vote appartiennent tous au domaine Solana Core. Les exécuteurs sont disponibles, mais kb_pipeline et DemoExecutionSolanaCore n’orchestrent actuellement qu’un transfert System de bout en bout.

• Confirmer les capacités exactes déjà compilées : quatre opérations Compute Budget, cinq opérations Address Lookup Table, vingt-quatre helpers Stake actuels et vingt-quatre opérations Vote actuelles.
• Ajouter un accordéon par famille seulement lorsque la famille dispose d’une démonstration utile ; conserver System affiché directement tant qu’il reste la seule orchestration réseau complète.
• Ajouter en premier une transaction System enrichie de SetComputeUnitLimit et SetComputeUnitPrice, avec plan, simulation, soumission, hydratation et replay.
• Ajouter ensuite le lifecycle Address Lookup Table contrôlé : create, extend, deactivate, attente du cooldown puis close ; freeze doit utiliser une table jetable distincte car il est irréversible.
• Ajouter un lifecycle Stake contrôlé sur compte temporaire : create/initialize, delegate vers un vote account Devnet existant, deactivate, attente d’epoch puis withdraw/close.
• Ajouter Vote en dernier : création d’un vote account temporaire et opérations administratives sûres ; ne pas tenter de produire artificiellement des votes de consensus sans validator contrôlé.
• Mutualiser l’orchestration réseau générique afin d’éviter une fonction pipeline spécifique par opération et conserver simulation-first, autorisation explicite, plafonds, postconditions et second replay.

Version 0.11.x — sources temps réel interchangeables

Cette série commence seulement lorsque les transactions reçues peuvent être décodées et matérialisées immédiatement.

0.11.0 — contrat de stream commun dans kb_rpc

• Ajouter une interface interne de flux transactionnel source-indépendante dans kb_rpc.
• Normaliser toutes les sources vers le même modèle canonique kb_model.
• Garantir que les décodeurs et stores ne dépendent d’aucun provider.

0.11.1 — extension Helius WebSocket

• Ajouter transactionSubscribe et transactionUnsubscribe dans des modules internes Helius de kb_rpc.
• Ajouter accountInclude, accountExclude, accountRequired, vote, failed et options de transaction complète.
• Tester offline avant tout abonnement payant.
• Acheter Helius Developer seulement pour la campagne mainnet réelle.

0.11.2 — Yellowstone gRPC

• Ajouter le client Yellowstone gRPC dans kb_rpc avec tonic et Protobuf.
• Supporter Triton, Chainstack, Shyft et autres endpoints compatibles par configuration.
• Ajouter filtres transaction account_include, account_exclude, account_required, vote et failed.
• Normaliser SubscribeUpdateTransaction vers la transaction canonique.

0.11.3 — fallback Solana standard

• Ajouter logsSubscribe par mention et logsSubscribe("all") comme probes/fallbacks mesurés.
• Ajouter l’hydratation getTransaction bornée.
• Ne jamais stocker le payload complet des notifications quand la transaction canonique est disponible.

0.11.4 — comparaison fournisseur et coût

• Comparer Helius transactionSubscribe, Yellowstone gRPC et logs + hydration.
• Mesurer couverture, latence, octets, crédits/coût, doublons, pertes et reconnexions.
• Utiliser kb_sol_obs_transaction_observations pour les comparaisons de timing par signature.
• Commencer avec Meteora, Pump et Raydium ; ajouter Orca ensuite ; garder Jupiter hors filtre initial.
• Choisir la source principale, le fallback et le fournisseur selon les mesures.

0.11.5 — ingestion live durable

• Ajouter sessions persistantes, backpressure, reconnexion et réparation des trous.
• Désactiver le trading pendant toute perte de source ou phase de rattrapage.
• Marquer les origines live, replayed, backfilled et repaired.
• Interdire par défaut toute décision de trading depuis un événement non live.

Version 0.12.x — wallet, sécurité et démos devnet

• Promouvoir kb_wallet du backend temporaire 0.4.2 vers des backends de production chiffrés, coffre système ou hardware wallet.
• Lire l’adresse wallet locale et les soldes SOL/SPL.
• Généraliser les parcours wallet et soldes SOL/SPL au-delà du laboratoire d’exécution native validé en 0.4.2.
• Finaliser kb_execution_safety minimal.
• Ajouter simulation obligatoire, limites de dépense, slippage, dry-run et validation post-transaction.
• Ajouter les pages Tauri wallet, balances et transferts.

Version 0.13.x — listeners et trading assisté

• Relier les transactions décodées live aux listeners métier.
• Notifier créations de tokens/pools, migrations, liquidité, swaps, frais et opérations administratives dangereuses.
• Ajouter des conditions manuelles d’achat/revente sans automatisation complète.
• Ajouter heartbeat opérateur et état global TRADING_DISABLED / LIVE_READY.
• Interdire tout envoi mainnet tant que les garde-fous ne sont pas validés.
• N’autoriser les listeners ou stratégies à demander que des capacités d’exécuteur explicitement activées ; une crate réservée ou un builder hors UI ne constitue pas une autorisation de trading.

Développement parallèle par surface

Pour chaque surface prioritaire :

• Décodeur maximal, y compris instructions obsolètes ou non directement liées au trading.
• Corpus de signatures dédié.
• Événements décodés stables.
• Matérialisation complète de tout ce qui est exploitable.
• Tests synthétiques.
• Replay et SQL anti-régression.
• Statut d’exécuteur obligatoire dans le même jalon : réservé, en implémentation, complet, ou non applicable avec justification officielle.
• Pour toute surface appelable, implémenter l’exécuteur après stabilisation du décodeur et des garde-fous ; couvrir maximalement les opérations client même si elles restent hors kb_app_demo.
• Synchroniser le README de l’exécuteur avec ses types, constantes, opérations, paramètres, effets, erreurs, exemple d’usage et limites d’exposition.

Objectif long terme — bibliothèque d’analyse Solana

• Étendre les registres à toutes les surfaces observées.
• Ajouter classification automatique des programmes inconnus.
• Ajouter matérialisations NFT, metadata, oracle, lending, staking, governance, bridge, perpetuals, vault, routing, risk et compliance audit.
• Ajouter agrégations comparables à un explorateur : tokens, pools, pairs, volumes, états, risques, anomalies et historiques.
• Ajouter replay partiel par module, version, slot, signature, program id, surface et discriminator.

Transports futurs

• Étudier shred delivery/RabbitStream uniquement après stabilisation des flux transactionnels complets.
• Ne pas confondre les transactions pré-exécution sans metadata avec la source canonique de décodage.