1440 lines
163 KiB
Markdown
1440 lines
163 KiB
Markdown
<!-- file: ROADMAP.md -->
|
||
<!-- version: 172 -->
|
||
|
||
# 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
|
||
|
||
- [x] Réserver les crates core, décodeurs, matérialisateurs, exécuteurs et applications.
|
||
- [x] Valider que le workspace compile après ajout de la couche d'exécution.
|
||
- [x] Conserver `CHANGELOG.md` pour les versions validées uniquement.
|
||
- [x] Réserver `prompts/` pour les futures sessions ChatGPT par version.
|
||
- [x] Documenter les objectifs court terme et long terme.
|
||
- [x] Ajouter `kb_config` et `config/example.config.json` comme base de configuration.
|
||
- [x] Ajouter les surfaces Bags Fee Share V1/V2 confirmées.
|
||
- [x] Définir le format obligatoire des zips delta ChatGPT.
|
||
- [x] Mettre à jour `CHANGELOG.md` pour `0.0.1` et `0.0.2`.
|
||
- [x] Exécuter `cargo build`.
|
||
- [x] Exécuter `cargo test --workspace`.
|
||
- [x] Exécuter `cargo clippy --workspace --all-targets`.
|
||
- [x] Faire le commit `v0.0.2` comme squelette stabilisé.
|
||
|
||
## Version 0.1.x — logging et configuration
|
||
|
||
### 0.1.0 — `kb_logging`
|
||
|
||
- [x] Finaliser l'API publique minimale de `kb_logging`.
|
||
- [x] Définir les routes de logs console, fichier humain, fichier JSON et fichier erreurs.
|
||
- [x] Router les logs vers console, fichier humain, fichier JSON et fichier erreurs.
|
||
- [x] Gérer les niveaux par target et par sortie.
|
||
- [x] Conserver le nettoyage ANSI des fichiers via writer dédié pour les messages issus de WebView Tauri.
|
||
- [x] Ajouter la normalisation des globs `crate::*` en plus des globs `crate.*`.
|
||
- [x] Ajouter les tests unitaires de configuration des targets et expressions de filtres.
|
||
- [x] Ajouter les tests unitaires de sélection des routes console, fichier humain, fichier JSON et fichier erreurs.
|
||
- [x] Ajouter les tests unitaires du writer sans ANSI.
|
||
- [x] Valider localement `cargo test -p kb_logging` : 14 tests passés.
|
||
- [x] Valider localement `cargo clippy -p kb_logging --all-targets`.
|
||
- [x] Reporter `0.1.0` dans `CHANGELOG.md` après validation.
|
||
|
||
### 0.1.1 — `kb_config`
|
||
|
||
- [x] Finaliser les structures typées de configuration.
|
||
- [x] Normaliser les exports TS-rs avec `export_to = "../frontend/ts/bindings/kb_config/settings/*.ts"`.
|
||
- [x] Charger un fichier JSON avec plusieurs profils.
|
||
- [x] Garantir un seul profil actif.
|
||
- [x] Ajouter `config/schema.config.json`.
|
||
- [x] Valider le JSON brut via `jsonschema`.
|
||
- [x] Valider les profils absents, dupliqués ou incohérents.
|
||
- [x] Exclure du schéma les transports avancés hors périmètre avant `v1.x`.
|
||
- [x] Conserver les placeholders de clés directement dans les URLs.
|
||
- [x] Supprimer `ProfileConfig.enabled` : `active_profile` est l’unique sélection de profil.
|
||
- [x] Retirer `data.idls_directory` du contrat runtime : les IDLs restent des artefacts de développement.
|
||
- [x] Conserver `kb_core` comme dépendance anticipée pour les erreurs communes workspace.
|
||
- [x] Valider `config/example.config.json`.
|
||
- [x] Ajouter les tests de parsing, validation et sérialisation.
|
||
- [x] Valider localement `cargo test --tests -p kb_config` : 35 tests passés.
|
||
- [x] Valider localement `cargo clippy -p kb_config --all-targets`.
|
||
- [x] Reporter `0.1.1` dans `CHANGELOG.md` après validation.
|
||
|
||
### 0.1.2 — liaison `kb_logging`, `kb_config` et démo Tauri
|
||
|
||
- [x] Initialiser `kb_logging` depuis le profil actif.
|
||
- [x] Appliquer les niveaux, formats et chemins de fichiers depuis la configuration.
|
||
- [x] Vérifier la création des fichiers de logs configurés et conserver la rotation comme amélioration future.
|
||
- [x] Conserver `main.html` comme fenêtre d'accueil.
|
||
- [x] Rendre le README workspace en HTML dans la fenêtre `main` sans afficher les commentaires de métadonnées `file/version`.
|
||
- [x] Ajouter dans `main.html` un dropdown vers les fenêtres de démonstration.
|
||
- [x] Créer `kb_app_demo/src/demo_config.rs` comme fenêtre de démo uniquement.
|
||
- [x] Créer `kb_app_demo/frontend/demo_config.html`.
|
||
- [x] Créer `kb_app_demo/frontend/ts/demo_config.ts`.
|
||
- [x] Réutiliser le même format visuel que la fenêtre principale.
|
||
- [x] Afficher le profil actif, la configuration complète et le schéma JSON.
|
||
- [x] Ajouter un viewer JSON interactif pour le profil actif, la configuration complète et le schéma JSON.
|
||
- [x] Désactiver le toolbar natif du viewer JSON pour éviter les boutons d’indentation non configurables.
|
||
- [x] Exporter `DemoConfigPayload` via TS-rs et l'importer côté TypeScript.
|
||
- [x] 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.
|
||
- [x] Corriger la fermeture de l’application lorsque `demo_config` n’a jamais été ouverte.
|
||
- [x] Ajouter un pont `emit_frontend_log` pour réémettre les logs WebView avec des targets `tracing` statiques.
|
||
- [x] Router `kb_app_demo.frontend::*` dans la console et le fichier debug de `kb_app_demo`.
|
||
- [x] Ajouter `AppState` comme état applicatif global dans `kb_app_demo/src/app_state.rs`.
|
||
- [x] Retirer l’initialisation runtime globale de `demo_config`, qui reste une simple fenêtre de démo.
|
||
- [x] 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.
|
||
- [x] Déplacer l’installation du provider Rustls par défaut dans `kb_app_demo_lib::run()` pour desktop et mobile.
|
||
- [x] Ajouter un splashscreen avec fade-in/fade-out et durée minimale extensible pour les vérifications longues futures.
|
||
- [x] Aligner le branchement du splashscreen dans `tauri_builder.setup` sur le modèle de `khadhroony-bobobot/kb_demo_app`.
|
||
- [x] Corriger `SplashOrder.duration_ms` en `u32` pour éviter un type BigInt côté TypeScript.
|
||
- [x] Corriger l’animation du splash avec `requestAnimationFrame`, une opacité initiale explicite et une attente initiale de `1500 ms` avant fade-in.
|
||
- [x] Valider visuellement le fade-in/fade-out dans `cargo tauri dev`.
|
||
- [x] Valider localement `cargo test -p kb_core` : 2 tests passés.
|
||
- [x] Valider localement `cargo test -p kb_config` : 35 tests passés.
|
||
- [x] Valider localement `cargo test -p kb_logging` : 14 tests passés.
|
||
- [x] Valider localement `cargo test -p kb_app_demo` : 12 tests passés.
|
||
- [x] Valider localement `cargo clippy --all-targets`.
|
||
- [x] Valider localement `cargo tauri dev -c kb_app_demo/tauri.conf.json` depuis la racine du workspace.
|
||
- [x] Reporter `0.1.2` dans `CHANGELOG.md` après validation.
|
||
|
||
### 0.1.3 — clients HTTP/WS Solana standard, rôles et pools
|
||
|
||
- [x] Explorer `khadhroony-bobobot/kb_lib` et les anciennes démos HTTP/WS comme source d'adaptation.
|
||
- [x] 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`.
|
||
- [x] Ajouter les contrats JSON-RPC 2.0 partagés entre HTTP et WebSocket.
|
||
- [x] Créer ou finaliser le client HTTP JSON-RPC Solana standard dans `kb_rpc`.
|
||
- [x] Créer ou finaliser le client WebSocket Solana standard court dans `kb_rpc`.
|
||
- [x] Ajouter la gestion de pool HTTP par rôle d'endpoint.
|
||
- [x] Ajouter la gestion de pool WebSocket par rôle d'endpoint.
|
||
- [x] Finaliser le premier modèle de rôles d'endpoints exploitable par les pools.
|
||
- [x] Associer chaque rôle à un ou plusieurs types de requêtes via `request_kinds`.
|
||
- [x] Router les requêtes HTTP et les requêtes WebSocket par rôle.
|
||
- [x] Préparer les contrats nécessaires aux futurs pools HTTP et WebSocket persistants.
|
||
- [x] Ajouter une fenêtre de démo HTTP JSON-RPC dédiée dans `kb_app_demo`.
|
||
- [x] Ajouter une fenêtre de démo WebSocket dédiée dans `kb_app_demo`.
|
||
- [x] 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.
|
||
- [x] Ajouter une connexion/déconnexion explicite dans `demo_ws`.
|
||
- [x] Réutiliser la même connexion WebSocket pour plusieurs souscriptions tant que l’endpoint sélectionné reste identique.
|
||
- [x] Conserver la connexion WebSocket dans `AppState` quand la fenêtre `demo_ws` est fermée puis recréée.
|
||
- [x] 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.
|
||
- [x] Remplacer l’affichage JSON échappé des démos par des zones texte readonly avec bouton de copie.
|
||
- [x] Ajouter le refresh explicite des pools HTTP/WS depuis les fenêtres de démo.
|
||
- [x] Ajouter un profil `mainnet` Helius avec les paramètres issus de l’ancien `config.json` fourni.
|
||
- [x] Élargir les listes de méthodes HTTP/WS de démonstration aux commandes Solana standard courantes.
|
||
- [x] Ajouter un champ `Params JSON complet` à la démo HTTP pour tester les méthodes multi-paramètres.
|
||
- [x] Ajouter l’unsubscribe explicite d’une subscription WebSocket sélectionnée sans fermer la socket persistante.
|
||
- [x] Ajouter une limitation côté Rust des notifications WebSocket envoyées à la WebView pour éviter le gel sur les subscriptions très bavardes.
|
||
- [x] Borner côté TypeScript l'historique affiché dans `demo_ws`.
|
||
- [x] 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.
|
||
- [x] Ajouter les liens correspondants dans le dropdown de la fenêtre principale.
|
||
- [x] Conserver les démos dans des fichiers Rust, HTML et TypeScript séparés comme dans `khadhroony-bobobot/kb_demo_app`.
|
||
- [x] Confirmer que gRPC, Helius enhanced WebSocket, Helius gRPC et LaserStream restent hors scope avant `v1.x` ou `v2.x`.
|
||
- [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`.
|
||
- [x] Conserver les limites comme contrat de configuration et reporter vers `0.4.x` leur enforcement runtime par token bucket et pause 429.
|
||
- [x] 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.
|
||
- [x] Valider localement `cargo test -p kb_rpc` : 39 tests passés.
|
||
- [x] Valider localement `cargo test -p kb_app_demo` : 28 tests passés.
|
||
- [x] Valider localement `cargo clippy --all-targets`.
|
||
- [x] Valider visuellement `demo_http` dans `cargo tauri dev -c kb_app_demo/tauri.conf.json`.
|
||
- [x] Valider visuellement `demo_ws` dans `cargo tauri dev -c kb_app_demo/tauri.conf.json`.
|
||
- [x] Valider que le pool HTTP alterne entre endpoints compatibles avec le profil `mainnet_research`.
|
||
- [x] Valider que `programSubscribe` très bavard reste utilisable grâce au throttling UI et que l’unsubscribe fonctionne.
|
||
- [x] 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
|
||
|
||
- [x] 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`.
|
||
- [x] Définir le rôle exact de chaque crate touchée avant d'ajouter des migrations ou des requêtes.
|
||
- [x] Valider que PostgreSQL utilise le schema courant/default, généralement `public`, sans schemas applicatifs explicites.
|
||
- [x] Valider le préfixe de table `kb_sol_<domain>_<name>` pour les tables Solana du nouveau projet.
|
||
- [x] Définir les domaines intégrés au nom de table : `raw`, `core`, `obs`, `decode`, `mat`, `catalog`, `agg`, `ops`, `wallet`.
|
||
- [x] Documenter les tables candidates initiales sans les implémenter toutes immédiatement.
|
||
- [x] 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`.
|
||
- [x] Définir la séparation stricte `entities/`, `dtos/`, `queries/`, `repositories/`.
|
||
- [x] Interdire les structures Rust dans `queries/` : les structures appartiennent à `entities/` ou `dtos/`.
|
||
- [x] Définir la convention `Entity` comme représentation proche d'une ligne SQL.
|
||
- [x] Définir la convention `Dto` comme contrat applicatif, Tauri ou repository.
|
||
- [x] Définir la convention `InsertDto` / `UpsertDto` pour les écritures.
|
||
- [x] Définir les règles de nommage SQL : `id`, `created_at`, `updated_at`, `slot`, `signature`, `program_id`, `raw_json`, `payload_json`.
|
||
- [x] Définir les contraintes minimales : clés primaires, index uniques, index par signature, slot, program id et temps d'insertion.
|
||
- [x] Définir les migrations comme artefacts PostgreSQL versionnés dans `kb_store_pg`.
|
||
- [x] Préparer la page Tauri future de diagnostic DB sans l'implémenter si le store n'est pas encore prêt.
|
||
- [x] Mettre à jour `kb_store_core/README.md` avec les conventions validées.
|
||
- [x] Mettre à jour `kb_store_pg/README.md` avec les conventions PostgreSQL validées.
|
||
- [x] Mettre à jour ou créer un document de prompt pour ouvrir la suite `0.2.x`.
|
||
- [x] Neutraliser les migrations héritées qui créaient des schemas applicatifs ou des tables qualifiées comme `raw DOT sol_transactions`.
|
||
- [x] Ne pas modifier `CHANGELOG.md` avant validation locale du jalon.
|
||
|
||
### 0.2.1 — `kb_store_core` contrats et types communs
|
||
|
||
- [x] Créer les modules publics minimaux de `kb_store_core` sans dépendre de PostgreSQL.
|
||
- [x] Ajouter les erreurs storage en s'appuyant sur `kb_core::Error` et `kb_core::Result`.
|
||
- [x] Ajouter les types communs : pagination, tri, limites, healthcheck, statut migration.
|
||
- [x] Ajouter les premiers DTO génériques : raw RPC transaction, raw WS notification, core transaction, core instruction.
|
||
- [x] Ajouter les contrats core pour account keys, logs et balance changes extraits.
|
||
- [x] Ajouter `MdCoreInstructionReplayInput` pour fournir aux décodeurs une instruction avec contexte extrait.
|
||
- [x] Ajouter les contrats de cycle de vie raw : état de rétention, état de traitement et mark lifecycle.
|
||
- [x] Ajouter les contrats de replay par instruction : état instruction, filtre de replay et lifecycle mark.
|
||
- [x] Ajouter les premiers traits repository sans implémentation SQL.
|
||
- [x] Étendre les repositories pour préparer la sélection des instructions non traitées.
|
||
- [x] Ajouter tests unitaires offline pour pagination, validation DTO et erreurs.
|
||
- [x] Documenter le cycle de vie raw et la future compaction/purge sans l'activer.
|
||
- [x] Documenter le split core des instructions, logs, account keys et balances avant les migrations.
|
||
- [x] Valider localement `cargo test -p kb_store_core` : 28 tests passés.
|
||
- [x] Valider localement `cargo clippy --all-targets` sans avertissement.
|
||
- [x] Reporter `0.2.1` dans `CHANGELOG.md` après validation locale.
|
||
|
||
### 0.2.2 — `kb_store_pg` connexion PostgreSQL et migrations
|
||
|
||
- [x] Ajouter la lecture effective de la configuration PostgreSQL depuis le profil actif.
|
||
- [x] Créer les options de connexion PostgreSQL minimales dans `kb_store_pg`.
|
||
- [x] Créer le pool PostgreSQL via `sqlx::PgPool`.
|
||
- [x] Ajouter le masquage DSN pour les diagnostics.
|
||
- [x] Ajouter un healthcheck PostgreSQL minimal basé sur `SELECT 1`.
|
||
- [x] Lire le schema courant PostgreSQL via `current_schema()`.
|
||
- [x] Lire la version PostgreSQL pour les diagnostics.
|
||
- [x] Ajouter une stratégie de migrations PostgreSQL explicite et non destructive.
|
||
- [x] Ne pas créer de schemas PostgreSQL applicatifs ; utiliser le schema par défaut du profil, généralement `public`.
|
||
- [x] Valider les noms de tables `kb_sol_<domain>_<name>` et refuser les schemas explicites.
|
||
- [x] Ajouter des tests offline pour options, masquage DSN et validation des noms de tables.
|
||
- [x] Ajouter un test PostgreSQL réel optionnel contrôlé par `KB_POSTGRES_TEST_URL`.
|
||
- [x] Valider localement `cargo test -p kb_store_pg` : 11 tests passés.
|
||
- [x] Valider localement le test PostgreSQL réel optionnel `optional_postgres_healthcheck_from_env` avec `postgres://solana:solana@localhost:5432/solana`.
|
||
- [x] Valider localement `cargo test -p kb_store_core` : 28 tests passés.
|
||
- [x] Valider localement `cargo test -p kb_config` : 35 tests passés.
|
||
- [x] Valider localement `cargo test -p kb_app_demo` : 28 tests passés.
|
||
- [x] Valider localement `cargo clippy --all-targets` sans avertissement après correction de l'exception `async_trait` / `clippy::implicit_return`.
|
||
- [x] Reporter `0.2.2` dans `CHANGELOG.md` après validation.
|
||
|
||
### 0.2.3 — raw store Solana minimal
|
||
|
||
- [x] Créer `kb_sol_raw_rpc_transactions` pour stocker le raw RPC immuable.
|
||
- [x] Créer `kb_sol_raw_ws_notifications` pour stocker les notifications WebSocket brutes utiles.
|
||
- [x] Prévoir `notification_key`, signature optionnelle et lien optionnel vers la transaction RPC canonique.
|
||
- [x] Créer les queries et repositories PostgreSQL associés aux DTOs `0.2.1`.
|
||
- [x] Ajouter insert idempotent par signature pour les transactions raw.
|
||
- [x] Ajouter insert append-only dédupliqué par `notification_key` pour les notifications WS raw.
|
||
- [x] Ajouter index minimaux par signature, slot, subscription kind, lien RPC et date d'insertion.
|
||
- [x] Ajouter une initialisation idempotente `PostgresStore::initialize_raw_store_schema()`.
|
||
- [x] Préparer `auto_initialize_schema` pour appliquer le schéma raw minimal après connexion quand le profil le demande.
|
||
- [x] Documenter que `0.2.3` ne purge pas encore physiquement `raw_json`.
|
||
- [x] Valider localement `cargo test -p kb_store_pg` : 21 tests passés.
|
||
- [x] 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`.
|
||
- [x] Valider localement `cargo test -p kb_store_core` : 28 tests passés.
|
||
- [x] Valider localement `cargo test -p kb_config` : 35 tests passés.
|
||
- [x] Valider localement `cargo test -p kb_app_demo` : 28 tests passés.
|
||
- [x] Valider localement `cargo clippy --all-targets` sans avertissement.
|
||
- [x] Reporter `0.2.3` dans `CHANGELOG.md` après validation.
|
||
|
||
### 0.2.4 — core Solana normalisé minimal
|
||
|
||
- [x] Créer les tables core minimales : `kb_sol_core_transactions`, `kb_sol_core_account_keys`, `kb_sol_core_instructions`, `kb_sol_core_inner_instructions`, `kb_sol_core_logs`, `kb_sol_core_balance_changes`.
|
||
- [x] Construire `MdCoreInstructionReplayInput` depuis les tables `core` pour les décodeurs.
|
||
- [x] Marquer les instructions insérées comme `Pending` pour permettre un replay instruction-level.
|
||
- [x] Préparer le replay partiel par état, slot et program id via `CoreInstructionReplayFilter`.
|
||
- [x] Ajouter une initialisation idempotente raw/core via `PostgresStore::initialize_store_schema()`.
|
||
- [x] Sérialiser l'initialisation raw/core par verrou PostgreSQL `pg_advisory_xact_lock`.
|
||
- [x] Normaliser les noms de contraintes et d'index PostgreSQL avec les préfixes `pk_`, `fk_`, `ck_`, `ux_` et `ix_`.
|
||
- [x] Ajouter un script SQL de maintenance pour supprimer les tables raw/core dans l'ordre inverse des dépendances.
|
||
- [x] Valider localement le script `kb_store_pg/maintenance/drop_raw_core_store.sql` sur la base PostgreSQL locale.
|
||
- [x] Valider localement `KB_POSTGRES_TEST_URL=postgres://solana:solana@localhost:5432/solana cargo test -p kb_store_pg -- --nocapture` : 30 tests passés.
|
||
- [x] Valider localement la création des 8 tables raw/core dans PostgreSQL.
|
||
- [x] Valider localement `cargo clippy --all-targets` sans avertissement.
|
||
- [x] 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.
|
||
- [x] Reporter les observations minimales et le ledger ops vers un jalon dédié après stabilisation de l'extraction.
|
||
- [x] Reporter l'extension du replay par module, version, signature, surface et discriminator après l'introduction des domaines `decode` et `ops`.
|
||
- [x] Reporter `0.2.4` dans `CHANGELOG.md` après validation.
|
||
|
||
### 0.2.5 — diagnostics SQL dans `kb_app_demo`
|
||
|
||
- [x] Ajouter `demo_sql_diag` pour le diagnostic PostgreSQL global : profil actif, backend, DSN masqué, schema courant, tables détectées, version migrations et healthcheck.
|
||
- [x] Ajouter `demo_sql_pg_raw` pour les tables `kb_sol_raw_rpc_transactions` et `kb_sol_raw_ws_notifications`.
|
||
- [x] Ajouter `demo_sql_pg_core` pour les tables core normalisées `kb_sol_core_*`.
|
||
- [x] Ajouter les boutons de refresh read-only dans chaque fenêtre.
|
||
- [x] Ajouter les liens dans le dropdown de la fenêtre principale.
|
||
- [x] Tenter l'initialisation raw/core au démarrage Tauri quand `database.postgres.auto_initialize_schema` est actif.
|
||
- [x] Afficher dans le splashscreen les tables créées, déjà présentes, manquantes ou en erreur, avec logs `tracing` associés.
|
||
- [x] Remplacer les payloads JSON textuels des démos SQL par le viewer JSON interactif déjà utilisé par `demo_config`.
|
||
- [x] Garantir que les démos SQL ne lancent ni extracteur, ni décodage, ni matérialisation.
|
||
- [x] 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.
|
||
- [x] Valider localement `cargo test -p kb_store_pg` : 30 tests passés.
|
||
- [x] Valider localement `cargo test -p kb_config` : 35 tests passés.
|
||
- [x] Valider localement `cargo test -p kb_app_demo` : 32 tests passés.
|
||
- [x] Valider localement `cargo clippy --all-targets` sans avertissement.
|
||
- [x] 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`.
|
||
- [x] 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.
|
||
|
||
```text
|
||
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é
|
||
|
||
- [x] Documenter l’hypothèse d’un nœud Agave local non votant comme source temps réel.
|
||
- [x] Préparer le profil manuel `agave_local_research`, les probes RPC/WS et les mesures de ressources.
|
||
- [x] Conserver `mainnet_research` comme profil actif stable et ne lancer aucune ingestion de production.
|
||
- [x] Valider localement le delta `0.3.0-pre.001` avant mise à jour du changelog.
|
||
- [x] Mesurer l’impact réel du snapshot, d’AccountsDB, du ledger, de la RAM, du swap et du réseau.
|
||
- [x] Abandonner temporairement Agave local et `blockSubscribe` comme axe actif à cause du coût matériel et opérationnel.
|
||
- [x] Reporter les conclusions historiques dans `CHANGELOG.md`.
|
||
|
||
### 0.3.1 — transaction canonique et observations d’acquisition — clôturé
|
||
|
||
- [x] Remplacer la cible `kb_sol_raw_rpc_transactions` par `kb_sol_raw_transactions`.
|
||
- [x] Remplacer la cible `kb_sol_raw_ws_notifications` par `kb_sol_obs_transaction_observations`.
|
||
- [x] Renommer `raw_json` en `canonical_json` et `raw_json_hash` en `canonical_json_hash`.
|
||
- [x] Ajouter `canonical_format_version`.
|
||
- [x] Renommer `kb_sol_core_transactions.raw_rpc_transaction_id` en `raw_transaction_id`.
|
||
- [x] 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.
|
||
- [x] Interdire la duplication durable du payload complet dans les observations.
|
||
- [x] Aligner DTOs, entities, repositories, requêtes, diagnostics SQL et démos Tauri.
|
||
- [x] Valider manuellement la migration réelle depuis le schéma `0.2.x` sur PostgreSQL 17.10.
|
||
- [x] Vérifier l’absence de `kb_sol_raw_rpc_transactions` et `kb_sol_raw_ws_notifications`.
|
||
- [x] 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`.
|
||
- [x] Consolider les migrations SQL en deux fichiers ne contenant que les tables actives.
|
||
- [x] Conserver temporairement dans le DDL runtime le chemin de compatibilité idempotent pour les workspaces encore en `pre.001`, sans recréer les anciennes tables.
|
||
- [x] Valider `cargo test -p kb_app_demo` : 32 tests passés.
|
||
- [x] Valider `cargo test -p kb_store_core` : 30 tests passés.
|
||
- [x] Valider `KB_POSTGRES_TEST_URL=postgres://solana:solana@localhost:5432/solana cargo test -p kb_store_pg -- --nocapture` : 32 tests passés.
|
||
- [x] Valider `cargo clippy --all-targets` sans avertissement.
|
||
- [x] Valider le démarrage Tauri et les diagnostics des huit tables raw/obs/core.
|
||
- [x] Nettoyer manuellement les fixtures PostgreSQL de test.
|
||
- [x] Vérifier et rationaliser les prompts `0.3.x`.
|
||
- [x] Reporter `0.3.1` dans `CHANGELOG.md`.
|
||
|
||
### 0.3.2 — contrat canonique et adaptateur HTTP — clôturé
|
||
|
||
- [x] Définir le type canonique dans `kb_model` et ses conversions explicites.
|
||
- [x] Conserver les signatures et public keys en base58, les payloads d’instruction en base64 et les valeurs numériques sans perte.
|
||
- [x] 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.
|
||
- [x] Garantir une sérialisation déterministe pour `canonical_json_hash` avec tri récursif des objets JSON et SHA-256.
|
||
- [x] Ajouter dans `kb_rpc` un adaptateur `getTransaction` JSON-RPC vers le modèle canonique.
|
||
- [x] Définir une interface interne commune pour les futurs adaptateurs Helius WebSocket et Yellowstone gRPC, sans créer de crate séparée.
|
||
- [x] Ajouter des fixtures offline legacy et v0, succès et échec, ALT, CPI, Token et Token-2022.
|
||
- [x] Tester l’idempotence : une même transaction provenant de plusieurs réponses HTTP doit produire le même hash canonique.
|
||
- [x] Valider `cargo test -p kb_model` : 23 tests passés.
|
||
- [x] Valider `cargo test -p kb_rpc` : 48 tests passés.
|
||
- [x] Valider `cargo test -p kb_store_core` : 31 tests passés.
|
||
- [x] 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.
|
||
- [x] 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`.
|
||
- [x] Valider `cargo clippy --all-targets` sans avertissement.
|
||
- [x] Nettoyer manuellement les fixtures PostgreSQL après validation.
|
||
- [x] Reporter `0.3.2` dans `CHANGELOG.md` après validation.
|
||
|
||
### 0.3.3 — backfill HTTP sur comptes gratuits — clôturé
|
||
|
||
- [x] Ajouter `getSignaturesForAddress` paginé avec `before`, `until`, limite, curseur de reprise et borne `max_pages`.
|
||
- [x] Ajouter le backfill d’une liste explicite de signatures séparées par des retours à la ligne.
|
||
- [x] Ajouter les campagnes avant/après une signature pour un programme, un token et un pool.
|
||
- [x] Hydrater chaque signature avec `getTransaction` via les pools HTTP existants.
|
||
- [x] Appliquer le débit, la concurrence et la pause 429 depuis le rôle configuré, avec retries bornés.
|
||
- [x] Écrire une seule ligne canonique par signature dans `kb_sol_raw_transactions`.
|
||
- [x] Écrire une observation légère par tentative `getTransaction` dans `kb_sol_obs_transaction_observations`.
|
||
- [x] Conserver les statuts `missing` et `failed` sans créer de faux payload canonique.
|
||
- [x] Ignorer avant hydratation les signatures déjà présentes dans le store canonique.
|
||
- [x] Ajouter `demo_backfill` avec accordéons Bootstrap 5, journal, résumé et arrêt coopératif.
|
||
- [x] 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.
|
||
- [x] Documenter le fonctionnement dans `docs/BACKFILL_HTTP.md`.
|
||
- [x] Valider `cargo test -p kb_rpc` : 54 tests passés.
|
||
- [x] Valider `cargo test -p kb_pipeline` : 10 tests passés après le correctif final d’arrêt/reprise.
|
||
- [x] Valider `cargo test -p kb_store_core` : 31 tests passés.
|
||
- [x] Valider `cargo test -p kb_store_pg` : 32 tests passés.
|
||
- [x] Valider `cargo test -p kb_app_demo` et les exports TS-rs : 38 tests passés.
|
||
- [x] Valider `cargo clippy --all-targets` sans avertissement.
|
||
- [x] Valider visuellement les modes signatures explicites, programme avant/après, token avant/après et pool avant/après dans Tauri.
|
||
- [x] 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.
|
||
- [x] Valider la persistance PostgreSQL réelle : 62 transactions canoniques et 62 observations, sans ligne core avant `0.3.4`.
|
||
- [x] Détecter l’arrêt opérateur pendant une campagne de 500 candidats et confirmer l’interruption des nouveaux appels `getTransaction`.
|
||
- [x] Remplacer la création globale des futures par une file d’exécution bornée à la concurrence effective.
|
||
- [x] Séparer `candidates_started`, `candidates_completed`, `candidates_cancelled` et `candidates_not_started`.
|
||
- [x] Calculer le curseur de reprise `before` depuis le dernier préfixe contigu réellement terminé.
|
||
- [x] 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`.
|
||
- [x] 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.
|
||
- [x] 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é
|
||
|
||
- [x] Ajouter le worker `kb_sol_raw_transactions -> kb_sol_core_*` dans `kb_pipeline`.
|
||
- [x] Résoudre les account keys statiques et les loaded addresses dans un ordre canonique unique.
|
||
- [x] Extraire outer instructions, inner instructions, logs, balances, statut et contexte transactionnel.
|
||
- [x] Conserver des hashes déterministes pour les payloads d’instruction et le texte des logs.
|
||
- [x] Garantir l’idempotence par signature, indices stables et instruction path.
|
||
- [x] Ajouter le ledger `kb_sol_ops_processing_ledger` pour l’extracteur et ses versions.
|
||
- [x] Persister le graphe core, l’état raw et le succès ledger dans une transaction PostgreSQL unique.
|
||
- [x] Permettre le replay par signature, lot pending, plage de slots et program id déjà indexé.
|
||
- [x] Ajouter le mode normal, le force replay, la concurrence bornée et l’arrêt coopératif.
|
||
- [x] Ajouter `demo_core_extraction` avec accordéons Bootstrap 5, journal et résumé JSON.
|
||
- [x] Ajouter `demo_sql_replay_candidates` avec cinq tableaux read-only : transactions, programmes, mints, owners et account keys.
|
||
- [x] Ajouter les filtres PostgreSQL bornés par raw, ledger, slots, programme outer/inner/logs, mint, owner et account key.
|
||
- [x] Ajouter sélection par checkbox, reset des filtres, copie individuelle/multiligne et export CSV natif.
|
||
- [x] Écrire les CSV dans `data/exports_csv/` avec BOM UTF-8, séparateur `;`, CRLF et nom non écrasant.
|
||
- [x] Valider l’écriture CSV native dans Tauri/Linux : `replay_transactions.csv` écrit dans le workspace.
|
||
- [x] Ajouter un registre énumérable de 182 program IDs dans `kb_program_ids` et l’exposer à l’interface.
|
||
- [x] Ajouter les requêtes SQL d’intégrité raw/core/ledger.
|
||
- [x] Valider une extraction pending réelle : 70 extraites, 0 skip, 0 échec.
|
||
- [x] Valider l’intégrité après extraction : aucun doublon, orphelin, hash incohérent, ledger incohérent ou chemin inner invalide.
|
||
- [x] Valider le skip réel sur 14 signatures : 0 extraction, 14 skips.
|
||
- [x] Valider le force replay réel sur les mêmes 14 signatures : 14 extractions, 0 skip, cardinalité core inchangée.
|
||
- [x] Valider un second skip après force replay : 0 extraction, 14 skips.
|
||
- [x] Confirmer le ledger réel : 70 lignes `succeeded`, 84 tentatives après le force replay.
|
||
- [x] Ajouter un test PostgreSQL optionnel qui provoque une erreur intermédiaire, vérifie le rollback complet puis rejoue le bundle corrigé.
|
||
- [x] Rendre annulables les appels `getSignaturesForAddress`, `getTransaction`, l’attente du pacer et les pauses de retry/429.
|
||
- [x] Ajouter les tests offline d’annulation d’une opération longue et d’une pause de retry déjà annulée.
|
||
- [x] Conserver les transactions Solana échouées dans core et les rendre éligibles au futur décodage comme observations d’intention/échec.
|
||
- [x] Interdire aux futurs matérialiseurs d’interpréter automatiquement les événements d’une transaction échouée comme mutations d’état réussies.
|
||
- [x] Fusionner l’ancien périmètre `0.3.5` dans `0.3.4`; les corpus exhaustifs sont reportés aux versions protocolaires concernées.
|
||
- [x] 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.
|
||
- [x] Valider `cargo test -p kb_pipeline` après l’ajout des tests d’annulation : 24 tests passés.
|
||
- [x] Valider `KB_POSTGRES_TEST_URL=... cargo test -p kb_store_pg -- --nocapture` avec le test de rollback : 39 tests passés.
|
||
- [x] Valider `cargo clippy --all-targets` sans avertissement.
|
||
- [x] 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é
|
||
|
||
- [x] Utiliser `prompts/019_v0_4_0_decoder_infrastructure.md` comme contrat de session.
|
||
- [x] Stabiliser les API `kb_decoder_api` et `kb_materializer_api` sur les inputs core contextualisés.
|
||
- [x] Ajouter le dispatch déterministe par `program_id`, surface, instruction path, payload/discriminator et contexte inner/logs.
|
||
- [x] Ajouter le replay borné par signatures, slots, program IDs, instruction paths, processor/version/hash et force replay.
|
||
- [x] Ajouter la persistance atomique des observations décodées, sorties matérialisées, couvertures et ledger.
|
||
- [x] Ajouter la politique explicite pour les transactions on-chain échouées et le refus des mutations métier supposées réussies.
|
||
- [x] 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.
|
||
- [x] Ajouter `demo_decode_replay` sans SQL libre, avec sélection, processors, concurrence, journal, arrêt et diagnostics.
|
||
- [x] Ajouter le classifieur initial de toutes les surfaces natives connues sans faux décodage.
|
||
- [x] Borner automatiquement la sélection SQL aux program IDs déclarés par les décodeurs activés et refuser les filtres incompatibles.
|
||
- [x] Permettre au force replay borné par signatures de resoumettre les inputs quel que soit leur lifecycle courant.
|
||
- [x] Ajouter l’autorisation explicite « toutes les signatures » bornée par les filtres et la limite.
|
||
- [x] Refuser tout force replay sans signatures ni autorisation « toutes les signatures ».
|
||
- [x] Désactiver/refuser la matérialisation lorsqu’aucun matérialiseur n’est enregistré.
|
||
- [x] Corréler les traces par `campaign_id`, signature, instruction path, program ID et processor/version.
|
||
- [x] Valider localement les champs obligatoires du backfill avant invocation Tauri.
|
||
- [x] Ne plus réappliquer les DDL à chaque commande Tauri et synchroniser précisément les snapshots de couverture.
|
||
- [x] Valider `cargo test -p kb_config` : 36 tests passés.
|
||
- [x] Valider `cargo test -p kb_pipeline` : 41 tests passés.
|
||
- [x] Valider PostgreSQL réel `cargo test -p kb_store_pg -- --nocapture` : 44 tests passés.
|
||
- [x] Valider `cargo test -p kb_app_demo` : 75 tests passés.
|
||
- [x] Valider `cargo clippy --all-targets` sans avertissement.
|
||
- [x] Valider le build frontend de production avec `(cd kb_app_demo && npm run build)`.
|
||
- [x] Valider dans Tauri le skip version/hash, le force replay ciblé, le second skip, le replay global limité, l’annulation et le redémarrage.
|
||
- [x] Corriger le résumé d’annulation afin que `completed = started` et `started + not_started = selected`.
|
||
- [x] Valider la campagne finale : 382 sélectionnés, 45 démarrés/terminés, 337 non démarrés, aucun unmatched ni échec.
|
||
- [x] 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`.
|
||
- [x] 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é
|
||
|
||
- [x] Utiliser `prompts/020_v0_4_1_native_solana_programs.md` comme contrat de session.
|
||
- [x] 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.
|
||
- [x] Vérifier chaque format d’instruction depuis les sources officielles actuelles ; ne jamais inventer un discriminant, un ordre de champs ou une sémantique.
|
||
- [x] 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.
|
||
- [x] Décoder maximalement `system`, y compris nonce accounts, seeds, allocate/assign, transfers et `CreateAccountAllowPrefund`, depuis `solana-system-interface 3.2.0`.
|
||
- [x] 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.
|
||
- [x] Décoder maximalement `address_lookup_table` : create, freeze, extend, deactivate et close depuis `solana-address-lookup-table-interface 3.1.0`.
|
||
- [x] Ajouter une matérialisation générique et idempotente du lifecycle ALT, limitée aux observations exactes, réussies et commitées.
|
||
- [x] Valider ALT sur corpus mainnet réel : 104 instructions core, 104 inputs décodés, 104 sorties lifecycle, zéro échec ou unsupported.
|
||
- [x] 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`.
|
||
- [x] 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é.
|
||
- [x] Reclasser `StakeConfig11111111111111111111111111111111` comme compte natif historique non exécutable et le retirer du dispatch/domaine d’exécution.
|
||
- [x] 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.
|
||
- [x] Décoder `config` comme une écriture générique `ConfigKeys` + payload opaque borné et `feature` comme `revoke_pending_activation` selon leurs interfaces officielles.
|
||
- [x] 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`.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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`.
|
||
- [x] 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.
|
||
- [x] Auditer les crates utilisant `tracing.workspace = true` et couvrir les treize crates alors actives par un test de constante canonique et par les routes des trois profils.
|
||
- [x] Ajouter le tracing propriétaire manquant sur les clients/pools HTTP et WebSocket ainsi que sur le backfill ; promouvoir les inputs decode unmatched, statuts failed/unsupported et échecs de matérialisation/persistance au niveau `error`.
|
||
- [x] Formaliser dans `docs/SOLANA_INTERFACE_DEPENDENCIES.md` la politique d’interfaces officielles : dépendance seulement au point de consommation, priorité `wincode` puis Borsh, parser borné lorsque l’interface n’expose que `bincode`.
|
||
- [x] Passer `MdCoreInstructionReplayInput` au contrat `2` avec une liste stable et numériquement ordonnée des instructions outer, sans migration SQL, afin de résoudre les références inter-instructions des précompiles.
|
||
- [x] Décoder `zk_elgamal_proof` dans `pre.015` selon `solana-zk-elgamal-proof-interface ^0.1` et le runtime Agave : treize discriminants, preuves inline ou référencées par compte, contexte optionnel et fermeture du contexte, sans recalcul cryptographique.
|
||
- [x] Décoder dans `pre.016` l’ancien `zk_token_proof` comme compatibilité historique, puis retirer dans `pre.019` la dépendance dépréciée `solana-zk-token-sdk` au profit d’un miroir wire local borné des dix-sept discriminants et tailles auditées.
|
||
- [x] Décoder les loaders `native_loader`, `bpf_loader_deprecated`, `bpf_loader`, `bpf_loader_upgradeable` et `loader_v4` ; classer l’invocation Native Loader opaque comme `ignored` sans sémantique inventée.
|
||
- [x] 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.
|
||
- [x] Conserver Memo hors périmètre natif et réserver `kb_decoder_spl_memo` pour ses générations v1, v3 et v4.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] Documenter dans `pre.019` l’audit complet des projections actives, différées et volontairement absentes dans `docs/NATIVE_SOLANA_MATERIALIZATION_AUDIT.md`.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] Ajouter dans `pre.003` ALT exact, la projection lifecycle ALT, les IDs SPL vérifiés et les crates réservées manquantes.
|
||
- [x] 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.
|
||
- [x] Corriger dans `pre.005` le décodage System afin de conserver les comptes additionnels validement résolus avec le rôle `additional_account`.
|
||
- [x] Ajouter dans `pre.005` une sélection de matérialiseur par observation exacte, avant ledger et politique de transaction.
|
||
- [x] Réserver les exécuteurs manquants pour Memo, Single Pool, Account Compression, Noop et SPL Name Service.
|
||
- [x] Formaliser puis rendre obligatoire le contrat de tracing par crate dans `docs/TRACING_CONTRACT.md`.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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`.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] `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.
|
||
- [x] 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`.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] `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.
|
||
- [x] `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.
|
||
- [x] Clôturer `0.4.1` avec 18 surfaces natives, matérialisations instructionnelles stables, logs propres et prompt de reprise `0.4.2`.
|
||
- [x] `pre.023` : replay global ciblé, validations finales, documentation de clôture, prompt `0.4.2` et mise à jour du `CHANGELOG.md`.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] Exécuter les tests unitaires des crates touchées, PostgreSQL réel, Clippy et campagnes Tauri/réelles avant mise à jour du changelog.
|
||
- [x] 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
|
||
|
||
- [x] 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.
|
||
- [x] 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`.
|
||
- [x] 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.
|
||
- [x] 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
|
||
|
||
- [x] `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.
|
||
- [x] `pre.001` : implémenter les builders officiels System transfer/create account/allocate/assign et Compute Budget set unit limit/set unit price.
|
||
- [x] `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.
|
||
- [x] `pre.001` : ajouter les contrôles de plan et pré-envoi pour simulation obligatoire, dry-run, cluster, mainnet, blockhash/nonce, signataires et plafonds.
|
||
- [x] `pre.002` : aligner le registre de l’exécuteur sur les dix-huit surfaces natives en incluant Slashing et corriger les retours explicites Clippy.
|
||
- [x] 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.
|
||
- [x] `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.
|
||
- [x] `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.
|
||
- [x] `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.
|
||
- [x] 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
|
||
|
||
- [x] `pre.004` : ajouter dans `kb_rpc` les adaptateurs typés `getGenesisHash`, `getLatestBlockhash`, `getFeeForMessage` et `simulateTransaction`, avec routage par rôle, classification des clusters publics, diagnostics runtime et conversion vers `ExApiExecutionSimulationResult`, sans signature ni envoi.
|
||
- [x] `pre.004` : documenter dans `kb_executor_solana_core/README.md` chaque fonction publique, les six opérations constructibles, leurs paramètres, résultats, effets et frontières.
|
||
- [x] Valider localement `pre.004` : `kb_rpc` 63 tests, `kb_execution_api` 21 tests, `kb_execution_safety` 13 tests, `kb_executor_solana_core` 10 tests, `kb_config` 40 tests et Clippy global propre.
|
||
- [x] `pre.005` : ajouter `kb_execution_solana` pour assembler les instructions planifiées en transaction legacy, produire les payloads base64 de frais/simulation, lier la simulation au hash exact du message, résoudre exactement les signataires requis via l’interface Solana `Signer` et signer séparément hors Tauri.
|
||
- [x] `pre.005` : renommer la constante interne en `MAINNET_GENESIS_HASH` sans changer sa valeur ; conserver `mainnet-beta` seulement comme alias historique des endpoints/CLI et renommer le variant public en `Mainnet` sérialisé `mainnet`.
|
||
- [x] `pre.005` : distinguer la simulation exacte de la simulation avec remplacement de blockhash et interdire qu’un résultat `replaceRecentBlockhash=true` autorise la signature du message original.
|
||
- [x] Valider localement les tests ciblés de `pre.005`/`pre.006` : `kb_execution_solana` 7 tests, `kb_execution_api` 22 tests, `kb_execution_safety` 15 tests, `kb_rpc` 63 tests, `kb_executor_solana_core` 10 tests, `kb_wallet` 6 tests et `kb_config` 40 tests.
|
||
- [x] `pre.006` : corriger la compilation croisée de `pre.005`, supprimer l’avertissement TS-rs sur l’alias historique `mainnet_beta`, utiliser le trait public `ExApiTypedInstructionExecutor` dans les tests d’assemblage, resynchroniser le contrat de simulation RPC et rendre les erreurs de routage tracing explicites.
|
||
- [x] `pre.007` : supprimer le dernier opérateur `?` introduit dans un chemin de production de `kb_execution_api`, le remplacer par un `match` avec propagation explicite et auditer les fichiers d’exécution `0.4.2` contre `?`, `unwrap` et `expect` de production.
|
||
- [x] Valider localement `pre.007` : `kb_execution_api` 22 tests et Clippy global propre.
|
||
- [x] `pre.008` : ajouter les contrats RPC typés `getBalance`, `requestAirdrop`, `sendTransaction`, `getSignatureStatuses` et `getBlockHeight`, avec routage par rôle, préflight obligatoire, contrôle de la signature retournée et confirmation bornée jusqu’à succès, échec, expiration ou timeout.
|
||
- [x] `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`.
|
||
- [x] 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.
|
||
- [x] `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é.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] `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.
|
||
- [x] `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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] `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.
|
||
- [x] 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.
|
||
- [x] `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.
|
||
- [x] Valider localement `pre.012` : `kb_executor_solana_core` 19 tests, `kb_execution_solana` 7 tests, `kb_execution_api` 22 tests et Clippy global propre.
|
||
- [x] `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.
|
||
- [x] 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.
|
||
- [x] `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.
|
||
- [x] 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.
|
||
- [x] `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.
|
||
- [x] 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.
|
||
- [x] `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.
|
||
- [x] 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.
|
||
- [x] `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.
|
||
- [x] `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.
|
||
- [x] 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
|
||
|
||
- [x] Compléter System avec les variantes seed, transferts seed, `create_account_allow_prefund` et le helper multi-instructions `transfer_many`.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] `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.
|
||
- [x] `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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] Valider localement `pre.016` et confirmer les six builders par tests officiels, exports TS-rs et Clippy global.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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`.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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
|
||
|
||
- [x] `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`.
|
||
- [x] `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.
|
||
- [x] Validation locale de `pre.016` avant passage à `pre.017`.
|
||
- [x] `pre.017` : Config, Feature, Slashing et surfaces ZK officiellement appelables ; classification explicite de l’ancien ZK Token Proof comme historique `decode-only`.
|
||
- [x] Validation locale de `pre.017` avant passage à `pre.018`, avec quatre avertissements Clippy de tests reportés et corrigés dans le lot suivant.
|
||
- [x] `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é.
|
||
- [x] 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.
|
||
- [x] `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.
|
||
- [x] Valider localement `pre.019` : `kb_executor_solana_core` 70 tests, `kb_execution_api` 22, `kb_execution_safety` 15, `kb_execution_solana` 12, `kb_rpc` 70 et Clippy global propre.
|
||
- [x] `pre.020` : onze opérations Loader v3 et neuf opérations Loader v4 réellement constructibles, avec déploiement/upgrade/autorités/fermeture hors UI; BPF Loader v1/v2 restent historiques `decode-only` et Native Loader est classé sans instruction client.
|
||
- [x] Valider localement `pre.020` : `kb_executor_solana_core` 81 tests, `kb_decoder_solana_core` 115, `kb_execution_api` 22, `kb_execution_safety` 15, `kb_execution_solana` 12 et `kb_rpc` 70.
|
||
- [x] `pre.021` : centraliser dans un module privé les parsers `MdPubkey`/program ID et les validations communes de longueur, montant positif, comptes distincts, dérivation seedée et erreurs partagées ; supprimer les implémentations de production identiques sans modifier les 109 opérations ni leur wire.
|
||
- [x] Valider localement `pre.021` après `fix.001` : `kb_executor_solana_core` 86 tests et `cargo clippy --all-targets` propre ; ce Clippy couvre également les changements Loader de `pre.020`.
|
||
- [x] `pre.022` : implémenter le préflight stateful Localnet/Devnet pour ALT, Config, Feature, Slashing et contextes ZK ElGamal ; ajouter `getEpochInfo` typé et la matrice machine-readable complète des 18 surfaces natives avec classification de toute opération non invocable.
|
||
- [x] Valider localement `pre.022` : `kb_executor_solana_core` 87 tests, `kb_pipeline` 56 tests, `kb_rpc` 71 tests, `kb_execution_api` 22 tests, `kb_execution_safety` 15 tests, `kb_execution_solana` 12 tests, validateur de matrice réussi et `cargo clippy --all-targets` propre.
|
||
- [x] `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.
|
||
- [x] 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.
|
||
- [x] `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.
|
||
- [x] 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.
|
||
- [x] `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.
|
||
- [x] 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.
|
||
- [x] `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.
|
||
|
||
- [x] `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.
|
||
- [x] `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`.
|
||
- [x] `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.
|
||
- [x] 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`.
|
||
- [x] `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
|
||
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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`.
|
||
- [x] 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.
|
||
- [x] 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`
|
||
|
||
- [x] Les 18 Program IDs natifs du registre partagé correspondent exactement aux 18 surfaces du décodeur.
|
||
- [x] Les 121 déclarations de couverture sont comptées par surface et reliées à un test d’enum officielle ou de layout wire audité.
|
||
- [x] Les 52 méthodes HTTP et neuf paires WebSocket standard sont inventoriées sans omission dans un registre compilé et une matrice JSON.
|
||
- [x] 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.
|
||
- [x] 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
|
||
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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é.
|
||
- [x] 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.
|
||
- [x] 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
|
||
|
||
- [x] `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.
|
||
- [x] `kb_rpc` 113 tests, `kb_pipeline` 56, `kb_config` 41 et `kb_app_demo` 88.
|
||
- [x] `kb_store_pg` 45 tests avec PostgreSQL réel, migrations et roundtrips optionnels réussis.
|
||
- [x] 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.
|
||
- [x] `cargo clippy --all-targets` sans avertissement.
|
||
- [x] `cargo tauri dev -c kb_app_demo/tauri.conf.json` validé avec Vite, initialisation PostgreSQL et sessions WebSocket réelles.
|
||
- [x] 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
|
||
|
||
- [x] 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.
|
||
- [x] SPL Memo : le décodeur v1/v3/v4 et la matérialisation des annotations commitées respectent la politique maximale sans doublon.
|
||
- [x] 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
|
||
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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`.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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é
|
||
|
||
- [x] Remplacer `DecoderSupport::Maybe` par une reconnaissance exacte des trois IDs et déplacer le target tracing vers `src/constants.rs`.
|
||
- [x] 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.
|
||
- [x] Séparer `add_memo`, `memo_intent` et `invalid_memo_attempt`, sans jamais marquer committed une transaction échouée.
|
||
- [x] Enregistrer `spl_memo` dans `demo_decode_replay` à côté du décodeur natif.
|
||
- [x] 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
|
||
|
||
- [x] Créer `kb_materializer_transaction_annotations` et la famille explicite `TransactionAnnotation`, sans détourner les projections existantes.
|
||
- [x] Projeter uniquement `add_memo` réussi et commité avec identité, texte, longueur, hash, signataires vérifiés, provenance et clé d’idempotence.
|
||
- [x] Refuser les transactions échouées et observations non commitées ; laisser les comptes complets, writable, diagnostics et preuves uniquement dans le decode.
|
||
- [x] Réutiliser `kb_sol_mat_events` et le ledger commun sans migration SQL ni duplication core/decode.
|
||
- [x] Enregistrer le matérialiseur dans `demo_decode_replay` et déclarer son target tracing dans les trois profils.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] Valider le démarrage Tauri avec 65 routes de logging sans dépassement de la limite de filtres ni erreur opérationnelle.
|
||
- [x] 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.
|
||
- [x] 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
|
||
|
||
- [x] Remplacer le plan réservé par `SplMemoGeneration`, `SplMemoOperation::AddMemo`, `SplMemoExecutionIntent` et `SplMemoSigner`.
|
||
- [x] À 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.
|
||
- [x] Conserver les doublons dans les metas tout en dédupliquant les signataires transactionnels requis.
|
||
- [x] Imposer simulation, plafond de frais, dépense nulle hors frais et validation post-exécution complète sans lier la bibliothèque à un cluster.
|
||
- [x] 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.
|
||
- [x] Valider `pre.003` : exécuteur Memo 14, API 22, safety 15, Solana 12 et `cargo clippy --all-targets` propres.
|
||
- [x] 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.
|
||
- [x] Ajouter un parcours opérateur Devnet v4 réutilisant simulation, confirmation, hydratation, core extraction, decode replay, projection et idempotence.
|
||
- [x] 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
|
||
|
||
- [x] Ajouter un request simulation-first, un plan Memo v4 à dépense nulle hors frais et une autorisation d’envoi explicite.
|
||
- [x] 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.
|
||
- [x] Hydrater la signature exacte, extraire le core, rejouer `spl_memo`, vérifier la projection `transaction_annotation` puis exécuter un second replay non forcé.
|
||
- [x] 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
|
||
|
||
- [x] Étendre la fenêtre Solana Devnet existante sans créer une nouvelle WebView ni déplacer de logique métier dans l’application.
|
||
- [x] Exposer message UTF-8, signer wallet readonly, simulation, confirmation opérateur et diagnostic complet sans clé privée ni `bigint` Tauri.
|
||
- [x] Afficher confirmation, validation canonique/core/decode, nombre d’annotations et preuve d’idempotence.
|
||
- [x] Valider 96 tests démo, 61 tests pipeline, Clippy propre et démarrage Tauri/Vite.
|
||
- [x] 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
|
||
|
||
- [x] Reporter dans `docs/SPL_MEMO_MATRIX.json` les trois signatures v4 Devnet confirmées, leurs annotations de 34 octets et leurs seconds replays idempotents.
|
||
- [x] 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.
|
||
- [x] 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
|
||
|
||
- [x] Enregistrer les validations finales fournies par l’utilisateur, y compris PostgreSQL réel, le parcours Devnet opt-in avec envoi et Clippy propre.
|
||
- [x] Clôturer `0.4.3` dans le ROADMAP et le `CHANGELOG.md` sans modifier le code ni le schéma PostgreSQL.
|
||
- [x] Ajouter `prompts/023_v0_4_4_spl_token.md` et rendre `0.4.4 — SPL Token` actif.
|
||
|
||
#### Validation finale observée — 15 juillet 2026
|
||
|
||
- [x] `kb_program_ids` 5 tests, `kb_decoder_spl_memo` 9, `kb_materializer_transaction_annotations` 7 et `kb_executor_spl_memo` 15.
|
||
- [x] `kb_execution_api` 22 tests, `kb_execution_safety` 15 et `kb_execution_solana` 12.
|
||
- [x] `kb_pipeline` 61 tests, `kb_rpc` 113 et `kb_app_demo` 96.
|
||
- [x] `kb_store_pg` 46 tests avec PostgreSQL réel, migrations et requêtes de matérialisation typées réussies.
|
||
- [x] 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.
|
||
- [x] `cargo clippy --all-targets` sans avertissement.
|
||
- [x] 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
|
||
|
||
- [x] `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é.
|
||
- [x] 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
|
||
|
||
- [x] 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.
|
||
- [x] Détailler les responsabilités `token_accounts`, `admin`, `risk` et `fees`, ainsi que le futur journal métier et la démo opérateur.
|
||
- [x] 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
|
||
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] Étendre `kb_materializer_admin` sans régresser ses projections natives, pour `set_authority` et les configurations multisig Token clairement administratives.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] Enregistrer les matérialisateurs actifs dans le replay commun et valider leur idempotence, sans migration PostgreSQL si le contrat générique suffit.
|
||
- [x] 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`
|
||
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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
|
||
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] `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.
|
||
- [x] 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.
|
||
- [x] 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
|
||
|
||
- [x] 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.
|
||
- [x] Enchaîner onze transactions simulation-first : `InitializeMint2`, deux `InitializeAccount3`, `MintToChecked`, `TransferChecked`, `ApproveChecked`, `Revoke`, deux `BurnChecked` puis deux `CloseAccount`.
|
||
- [x] 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.
|
||
- [x] `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.
|
||
- [x] `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.
|
||
- [x] 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
|
||
|
||
- [x] É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é.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] Afficher séparément résultat de préflight, simulation, confirmation, extraction, décodage, matérialisations attendues et preuve d'idempotence.
|
||
- [x] 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
|
||
|
||
- [x] 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.
|
||
- [x] `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.
|
||
- [x] `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.
|
||
- [x] `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.
|
||
- [x] `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.
|
||
- [x] 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.
|
||
- [x] `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.
|
||
|
||
- [x] `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.
|
||
- [x] `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`.
|
||
- [x] `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.
|
||
- [x] `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.
|
||
- [x] `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`.
|
||
- [x] `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`.
|
||
- [x] `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.
|
||
- [x] Décoder maximalement `Create`, `CreateIdempotent`, `RecoverNested` et la forme historique vide officiellement identifiable.
|
||
- [x] Couvrir les ATA ciblant SPL Token et Token-2022 sans commencer le décodage général Token-2022.
|
||
- [x] 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.
|
||
|
||
- [x] 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`.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] Décoder et parser séparément le registre ElGamal, avec `create_registry`, `update_registry`, PDA officiel, owner, taille et état de 64 octets.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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`.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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
|
||
|
||
- [x] 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 ».
|
||
- [x] 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.
|
||
- [x] Les NFT classiques et programmables liés à un mint sont couverts par le futur `kb_decoder_metadata_metaplex_token_metadata` (`0.4.7`).
|
||
- [x] Les actifs Metaplex Core, qui ne sont pas des mints SPL Token classiques, sont couverts séparément en `0.4.8`.
|
||
- [x] Les NFT compressés exigent Bubblegum en plus d’Account Compression et Noop; leur couverture complète est planifiée en `0.4.9`.
|
||
- [x] 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
|
||
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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.
|
||
- [x] 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`
|
||
|
||
- [x] Auditer les quinze variantes `Key` publiées (`0..=14`) et relier chaque compte réel à un décodeur borné.
|
||
- [x] Rejeter explicitement `Key::Uninitialized` et toute variante future inconnue sans projection partielle.
|
||
- [x] Vérifier par test les discriminateurs Borsh du SDK épinglé, l’unicité de l’inventaire et sa correspondance avec la matrice.
|
||
- [x] Définir l’identité stable canonique `program_id:account`, le nom de layout, le discriminant et la version canonique.
|
||
- [x] Distinguer explicitement lifecycle, politique de matérialisation et politique d’exécution.
|
||
- [x] Autoriser la matérialisation des comptes historiques comme état historique de backfill/replay, sans jamais les exposer à l’exécuteur.
|
||
- [x] 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
|
||
|
||
- [x] 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`.
|
||
- [x] 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
|
||
|
||
- [x] 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.
|
||
- [x] Décoder `CreateMasterEditionV3` et `ConvertMasterEditionV1ToV2` avec wire et comptes exacts.
|
||
- [x] 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.
|
||
- [x] Couvrir vérification/dé-vérification de créateurs et collections, collection size/details et autorités de collection.
|
||
- [x] 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.
|
||
- [x] Couvrir uses, approve/revoke use authority et consommation d'usage avec comptes exacts.
|
||
- [x] Couvrir délégations et révocations metadata/collection/use/sale/transfer/utility/staking/programmable lorsqu'elles sont officiellement définies.
|
||
- [x] 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.
|
||
- [x] Couvrir les migrations et instructions historiques encore observables sans les confondre avec les variantes actuelles.
|
||
- [x] Décoder `FreezeDelegatedAccount` et `ThawDelegatedAccount` historiques avec leurs cinq comptes exacts et les conserver decode-only.
|
||
- [x] Décoder les burns NFT historiques et le mint déprécié via printing token (`BurnNft`, `BurnEditionNft`, `DeprecatedMintNewEditionFromMasterEditionViaPrintingToken`).
|
||
- [x] Décoder les instructions escrow/collect (`CreateEscrowAccount`, `CloseEscrowAccount`, `TransferOutOfEscrow`, `Collect`) avec wire et comptes exacts.
|
||
- [x] Décoder le wrapper moderne `Create` (`42`) avec `CreateArgs::V1`, neuf comptes positionnels et placeholders optionnels exacts.
|
||
- [x] Décoder le wrapper moderne `Mint` (`43`) avec `MintArgs::V1`, quinze comptes positionnels et placeholders optionnels exacts.
|
||
- [x] Décoder le wrapper moderne `Print` (`55`) avec `PrintArgs::V1`/`V2`, dix-huit comptes positionnels et Token Record optionnel exact.
|
||
- [x] Décoder le wrapper moderne `Update` (`50`) et ses variantes `V1`/`As…V2` avec wire et comptes exacts.
|
||
- [x] Décoder les wrappers modernes `Use`, `Verify` et `Unverify` avec leurs variantes et contrats positionnels exacts.
|
||
- [x] Décoder `Resize` et `Migrate`, couvrir les six discriminateurs historiques manquants `2`/`5`/`6`/`8`/`9`/`10` et prouver l’inventaire exhaustif `0..=57`.
|
||
- [x] 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é.
|
||
- [x] `pre.025` : parser `MetadataV1`, conserver les champs descriptifs et administratifs, et produire une projection JSON bornée.
|
||
- [x] `pre.026` : parser `DeprecatedMasterEditionV1`, `MasterEditionV2` et `EditionV1`, conserver supply/max supply, printing mints historiques, parent et numéro d’édition.
|
||
- [x] `pre.027` : parser `EditionMarker` et `EditionMarkerV2`, conserver ledger, groupe V1, index d’octet, masque et état de l’édition demandée.
|
||
- [x] `pre.028` : parser `TokenRecord`, conserver bump, état programmable, révision du rule set, delegate, rôle et locked transfer.
|
||
- [x] `pre.029` : parser les records Metadata/Holder Delegate, Collection Authority et Use Authority avec leurs champs exacts.
|
||
- [x] `pre.030` : parser `TokenOwnedEscrow`, conserver base token, autorité TokenOwner/Creator et bump.
|
||
- [x] `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.
|
||
- [x] `pre.025` : appliquer cette frontière au compte `Metadata` avant toute désérialisation.
|
||
- [x] `pre.026` : appliquer la même frontière aux comptes edition/master edition avant toute désérialisation.
|
||
- [x] `pre.027` : appliquer cette frontière aux Edition Markers avant toute lecture du discriminant ou du ledger.
|
||
- [x] `pre.028` : appliquer cette frontière au Token Record avant toute lecture de l’état programmable.
|
||
- [x] `pre.029` : appliquer cette frontière aux quatre familles de records avant désérialisation.
|
||
- [x] `pre.030` : appliquer cette frontière à Token Owned Escrow avant lecture de l’autorité.
|
||
- [x] `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.
|
||
- [x] `pre.025` : valider le PDA Metadata exact `[b"metadata", program_id, mint]` et conserver le bump.
|
||
- [x] `pre.026` : valider le PDA edition/master edition exact `[b"metadata", program_id, mint, b"edition"]` et conserver le bump.
|
||
- [x] `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]`.
|
||
- [x] `pre.028` : valider le PDA Token Record `[metadata, program_id, mint, token_record, token_account]` et le bump stocké.
|
||
- [x] `pre.029` : valider les PDA exacts des records Metadata/Holder Delegate, Collection Authority et Use Authority.
|
||
- [x] `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é.
|
||
- [x] `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.
|
||
- [x] `pre.025` : borner Metadata à 1 024 octets, name à 32, symbol à 10, URI à 200 et creators à 5.
|
||
- [x] `pre.026` : borner edition/master edition à 128 octets et exiger exactement 41 octets pour `EditionV1`.
|
||
- [x] `pre.027` : exiger 32 octets pour V1, une longueur Borsh sans suffixe pour V2 et un ledger V2 borné à 1 048 576 octets.
|
||
- [x] `pre.028` : exiger exactement 80 octets pour Token Record et refuser troncature, suffixe, clé ou bump incohérents.
|
||
- [x] `pre.029` : exiger 98 octets pour les delegate records, 10 pour Use Authority et les deux tailles Borsh Collection Authority.
|
||
- [x] `pre.030` : exiger 35 octets pour TokenOwner et 67 pour Creator, sans suffixe.
|
||
- [x] `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.
|
||
- [x] `pre.034` : matérialiser `MetadataV1` comme snapshot owned autoritatif, stable et commité, sans doublon avec les observations d’instructions.
|
||
- [x] `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.
|
||
- [x] `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.
|
||
- [x] `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.
|
||
- [x] `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.
|
||
|
||
- [x] 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
|
||
|
||
- [x] 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
|
||
|
||
- [x] 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.
|
||
|
||
- [x] 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.
|