# khadhroony-bobobot — Roadmap ## 1. Objet du projet `khadhroony-bobobot` est un workspace Rust destiné à la détection, l’observation, l’analyse de patterns et, à terme, à l’exécution semi-automatisée d’achats/ventes de tokens sur la blockchain Solana. Le projet vise en priorité : - la détection de création de tokens et de paires sur différents DEX, - la réception et le tri des événements on-chain et RPC, - la collecte de métriques utiles au filtrage, - l’analyse statistique et comportementale des patterns, - la préparation d’une couche wallet puis swap/trading. ## 2. Principes d’architecture ### 2.1. Structure générale Le workspace est organisé autour de deux sous-crates principales : - `kb_lib` : bibliothèque métier, réseau, config, tracing, stockage, analyse et logique applicative. - `kb_demo_app` : application Demo Tauri V2 avec frontend TypeScript, chargée de l’interface et de la délégation vers `kb_lib`. ### 2.2. Contraintes de code Le socle du projet doit respecter les contraintes suivantes : - Rust 2024. - Aucun fichier `mod.rs`. - Exposition centralisée à la racine des crates via `lib.rs` ou `main.rs`. - Pas d’usage de `anyhow` ni `thiserror`. - Pas d’usage de `?`, `unwrap`, `expect` dans le code applicatif. - Utilisation de `match`, `if let Err`, `let Err = ... else`. - Documentation Rust obligatoire sur les éléments publics. - `#![deny(unreachable_pub)]` et `#![warn(missing_docs)]` activés et respectés. - Pas de `use` pour les types/fonctions externes, sauf pour les traits. - Tests unitaires importants et maintenus à chaque étape. ### 2.3. Règles de responsabilité - `kb_demo_app` ne doit pas embarquer la logique métier réseau ou Solana. - `kb_demo_app` doit seulement orchestrer l’UI, les commandes Tauri et les appels vers `kb_lib`. - `kb_lib` doit porter les clients réseau, la config, le tracing, les types partagés, les registres et la logique métier. ## 3. Vision fonctionnelle Le projet doit pouvoir évoluer progressivement vers les capacités suivantes : 1. Connexion à plusieurs endpoints HTTP / WS RPC Solana. 2. Répartition des rôles par endpoint. 3. Réception des notifications de slots, comptes, programmes, logs, signatures, blocs. 4. Détection de créations de tokens, pools et paires sur plusieurs DEX. 5. Collecte de métriques : liquidité, market cap, volume, prix, activité. 6. Persistance locale dans SQLite, puis évolution possible vers PostgreSQL. 7. Analyse de patterns et filtrage des tokens non tradables. 8. Gestion de wallets Solana. 9. Préparation puis exécution semi-automatisée de swaps/trading. 10. Intégration future de gRPC Yellowstone. ## 4. Configuration cible La configuration applicative est stockée dans un fichier `config.json`. ### 4.1. Points à couvrir dans la configuration Le fichier doit permettre de configurer : - les endpoints HTTP, - les endpoints WebSocket, - un nom logique par endpoint, - le rôle ou les tâches affectées à chaque endpoint, - les limites de débit par endpoint, - les options spécifiques aux providers publics ou privés, - les chemins de stockage local, - le répertoire des wallets Solana, - le tracing et ses formats, - la stratégie de reconnexion, - les paramètres de base de données, - les options d’UI persistées plus tard. ### 4.2. Exemple de catégories attendues - `app` - `logging` - `database` - `wallets` - `network` - `solana` - `http_endpoints` - `ws_endpoints` ### 4.3. Exigences particulières Chaque endpoint doit pouvoir porter sa propre configuration, par exemple : - nom logique, - URL, - provider, - présence ou non d’une clé API, - variable d’environnement pour clé API, - plafond de requêtes, - burst, - timeout, - usages autorisés, - rôle principal. Exemples de rôles futurs : - `slot_notifications` - `program_subscriptions` - `account_subscriptions` - `logs_subscriptions` - `http_queries` - `fallback` ## 5. Tracing cible Le tracing est centralisé dans `kb_lib`. ### 5.1. Exigences initiales - sortie console paramétrable, - sortie fichier paramétrable, - niveau de log configurable, - format du message configurable, - format du temps configurable, - ANSI console activable/désactivable, - fonctionnement compatible tests, - séparation claire entre initialisation et usage. ### 5.2. Objectifs complémentaires - pouvoir distinguer les logs du transport WS, - distinguer les logs HTTP, - distinguer les logs Tauri/UI, - distinguer les logs DB, - préparer une traçabilité par endpoint et par client. ## 6. Phasage par versions ### 6.001. Version `0.0.2` — Socle conforme Objectif : corriger le squelette et poser la base de travail. Réalisé : - correction de `kb_lib/src/lib.rs`, - création de `kb_lib::Error`, - création de `kb_lib::Config`, - création de `kb_lib::init_tracing`, - création des constantes Solana officielles, - préparation des modules `ws_client` et `http_client`, - remise de `kb_demo_app/src/lib.rs` en conformité, - documentation de `kb_demo_app/src/splash.rs`, - UI Tauri minimale. ### 6.002. Version `0.1.x` — Transport WebSocket générique Objectif : construire un vrai `WsClient` asynchrone clonable. Réalisé : - `connect`, `disconnect`, `connection_state`, - flux de lecture séparé du flux d’écriture, - identifiant incrémental interne par client, - canal sortant borné, - émission d’événements internes, - support de l’arrêt propre, - fermeture avec timeout, - tests offline avec serveur mock. ### 6.003. Version `0.1.1` — Intégration Tauri minimale du `WsClient` Objectif : valider le transport via l’application desktop. Réalisé : - intégration minimale de `WsClient` dans `kb_demo_app`, - boutons start/stop, - zone de logs, - validation du flux `frontend -> tauri -> kb_lib -> frontend`. ### 6.004. Version `0.2.0` — Couche JSON-RPC WS Solana Objectif : séparer clairement transport, réponses RPC et notifications. Réalisé : - enveloppes JSON-RPC 2.0, - gestion des `request_id`, - parsing des réponses et erreurs, - parsing des notifications, - premiers helpers JSON-RPC sur `WsClient`. ### 6.005. Version `0.3.0` — Registre subscriptions / notifications Objectif : fiabiliser la gestion des subscriptions. Réalisé : - stockage des subscriptions actives, - mapping entre requête de subscribe et `subscription_id` serveur, - unsubscribe propre avant fermeture, - timeout d’attente sur unsubscribe, - purge locale si nécessaire, - routage séparé des notifications. ### 6.006. Version `0.3.1` — Helpers subscribe/unsubscribe WebSocket Objectif : ajouter les helpers haut niveau correspondant aux principales méthodes PubSub Solana. Réalisé : - helpers pour `account`, `block`, `logs`, `program`, `root`, `signature`, `slot`, `slotsUpdates`, `vote`, - helpers d’unsubscribe correspondants, - premiers tests de validation des noms de méthodes. ### 6.007. Version `0.3.2` — Helpers typed et notifications typed Objectif : s’appuyer principalement sur `solana-rpc-client-api` pour typer les subscribe et les notifications. Réalisé : - helpers typed pour `account`, `block`, `logs`, `program`, `signature`, - parsing typed des notifications, - base de travail pour réduire l’usage direct de `serde_json::Value`. ### 6.008. Version `0.3.3` — Distinction API typed / raw Objectif : clarifier l’API publique de `WsClient`. Réalisé : - suffixe `_raw` sur les helpers raw, - conservation des helpers typed comme interface plus propre, - préparation d’une hiérarchie API plus explicite. ### 6.009. Version `0.3.4` — Fenêtre `Demo Ws` dans `kb_demo_app` Objectif : tester manuellement les souscriptions live dans une fenêtre dédiée. Réalisé : - fenêtre séparée `demo_ws`, - ouverture depuis la fenêtre principale, - connexion/déconnexion d’un client de démo, - test de souscriptions live, - affichage des événements raw et typed, - premiers tests réels sur `wss://api.mainnet.solana.com`. ### 6.010. Version `0.3.5` — Stabilisation de `Demo Ws` Objectif : rendre la fenêtre de démonstration robuste sous flux élevé et cohérente avec la configuration. Réalisé : - lire correctement les endpoints activés depuis la config et refléter les URLs résolues avec `api_key_env_var`, - améliorer la sélection réelle des endpoints affichés et utilisables, - ajouter du throttling / rate limiting de l’affichage UI sous fort débit, - limiter ou résumer les événements affichés côté fenêtre, - conserver l’intégralité des traces côté `tracing`, - éviter le gel de la fenêtre sur `logsSubscribe` et `programSubscribe`, - conserver des compteurs et états UI exploitables, - mieux gérer les fermetures/ralentissements d’endpoints publics. ### 6.011. Version `0.4.x` — Transport HTTP générique et helpers RPC Objectif : construire un `HttpClient` clonable, limité et extensible, puis ajouter les premiers helpers HTTP Solana. ### 6.012. Version `0.4.0` — Socle `HttpClient` Réalisé : - client `reqwest` asynchrone clonable, - résolution d’URL avec support de `api_key_env_var`, - limiteur local req/sec, - burst configurable, - délais configurables, - profils par endpoint, - abstraction JSON-RPC HTTP générique, - premiers appels de validation Solana. Livrables : - `HttpClient`, - enveloppes JSON-RPC HTTP, - premiers appels : - `getHealth` - `getVersion` - `getSlot` ### 6.013. Version `0.4.1` — Helpers HTTP Solana Réalisé : - ajouter des helpers HTTP haut niveau comme pour le client WS, - distinguer helpers raw et helpers typed quand cela est pertinent, - couvrir les premières méthodes utiles du RPC HTTP Solana, - conserver `HttpClient` comme couche générique réutilisable. ### 6.014. Version `0.4.2` — Politique HTTP avancée Réalisé : - préparer un état de pause avant envoi pour un endpoint HTTP, - préparer plusieurs quotas par famille de méthodes, - distinguer quota RPC général et quota `sendTransaction`, - préparer un futur pool d’endpoints HTTP et l’arbitrage entre eux. ### 6.015. Version `0.4.3` — Pool d’endpoints HTTP Réalisé : - ajouter un pool d’`HttpClient`, - sélectionner un endpoint selon le rôle demandé, - ignorer les endpoints `Paused` ou `Disabled`, - préparer une rotation simple entre endpoints actifs, - prendre en compte la classe de méthode HTTP, - préparer le routage multi-RPC et la limitation de concurrence par endpoint. ### 6.016. Version `0.4.4` — Démo HTTP dans `kb_demo_app` Réalisé : - ajout d’une fenêtre `Demo Http`, - ouverture depuis la fenêtre principale, - exécution manuelle de méthodes HTTP via le pool d’endpoints, - affichage des réponses JSON-RPC HTTP et des erreurs associées, - affichage de l’état du pool HTTP et des statuts des endpoints, - alignement visuel de la fenêtre sur le gabarit `Demo Ws`, - amélioration des presets UI, copie de réponse et bascule pretty/raw. ### 6.017. Version `0.5.x` — Base de données SQLite Objectif : poser la persistance locale avec une organisation préparée dès le départ à une future évolution vers PostgreSQL ou un autre backend. ### 6.018. Version `0.5.0` — Socle SQLite Réalisé : - configuration DB dans `config.json`, - ouverture/validation SQLite, - façade `kb_lib::Database`, - premier schéma technique, - table `k_sol_db_metadata`, - séparation `db/entities`, `db/dtos`, `db/queries`, `db/types`. ### 6.019. Version `0.5.1` — Premières tables métier de stockage local Réalisé : - ajout des tables de référence pour les endpoints connus HTTP/WS, - ajout des tables techniques pour les événements runtime locaux, - mise en place des `entities`, `dtos`, `queries` et `types` associés, - préparation du stockage local des endpoints HTTP/WS connus et de leur état utile. ### 6.020. Version `0.5.2` — Stockage des tokens observés Réalisé : - ajout de la table `k_sol_observed_tokens`, - stockage minimal des mints, symboles, noms, statuts et dates d’observation, - ajout du `token_program`, - préparation des relations futures avec pools, paires et événements on-chain, - conservation d’unicité locale par mint sans duplication par endpoint. ### 6.021. Version `0.5.3` — Événements et signaux locaux Réalisé : - conservation des événements runtime techniques via `k_sol_db_runtime_events`, - ajout des observations on-chain brutes via `k_sol_onchain_observations`, - ajout des signaux d’analyse via `k_sol_analysis_signals`, - distinction explicite entre événements runtime, observations on-chain et événements métier, - préparation de la traçabilité de provenance par type de source et endpoint, sans remettre en cause l’unicité locale d’un token par mint. ### 6.022. Version `0.5.4` — Modèle métier normalisé initial Réalisé : - ajouter les tables de référence métier pour les DEX, tokens, pools et paires, - distinguer clairement objets de référence et événements d’activité, - préparer les relations entre tokens, pools, paires et listings, - éviter que la détection technique `0.6.x` écrive directement dans des tables trop brutes ou ambiguës. ### 6.023. Version `0.5.5` — Activité métier normalisée Réalisé : - ajout des tables de swaps, - ajout des événements de liquidité, - ajout des événements de mint et burn utiles au suivi des tokens, - préparation de l’historique métier nécessaire avant l’arrivée des connecteurs DEX complets. ### 6.024. Version `0.5.6` — Consolidation de la couche stockage Objectif : stabiliser le schéma avant la détection technique réelle. À faire : - conserver l’abstraction du backend dès le départ, - limiter la dépendance directe au SQL concret aux modules `queries`, - garder les conversions explicites entre entités DB et DTOs applicatifs, - durcir les relations, contraintes et index utiles, - préparer une future compatibilité PostgreSQL sans casser l’organisation générale. ### 6.025. Version `0.6.0` — Pipeline de détection technique Objectif : relier les connecteurs RPC à la couche de stockage technique et métier. À faire : - ajouter une façade de persistance pour les observations et signaux issus des connecteurs, - préparer l’enregistrement des candidats tokens détectés depuis les sources RPC, - éviter que les futurs watchers RPC écrivent directement dans la DB sans couche intermédiaire, - préparer les prochaines étapes de détection technique on-chain / RPC. ### 6.026. Version `0.6.1` — Détection technique RPC Réalisé : - ajout d’un bridge `Solana WS notification -> pipeline de détection`, - persistance des notifications WS utiles comme observations on-chain normalisées, - génération d’un candidat token quand une `programNotification` expose un mint SPL / Token-2022 en JSON parsé, - préparation du branchement futur des watchers et règles RPC réelles sur une façade de détection unique. ### 6.027. Version `0.6.2` — Branchement `WsClient` vers la détection Réalisé : - ajouter un relais interne de notifications WS vers la couche de détection, - permettre à `WsClient` de forwarder les `JsonRpcWsNotification` vers un worker dédié, - conserver le découplage entre transport WS et logique de détection, - éviter de bloquer la boucle de lecture WS si la détection est lente. ### 6.028. Version `0.6.3` — Enrichissement des notifications WS utiles Réalisé : - enrichir `accountNotification`, `logsNotification` et `signatureNotification`, - mieux extraire slot, pubkey, signature, owner, parsed account type et clés pertinentes, - produire des observations plus précises et plus homogènes, - préparer les règles de détection techniques réelles. ### 6.029. Version `0.6.4` — Premières règles de détection technique Réalisé : - détection des premiers candidats pools/listings techniques depuis `programNotification`, - appui sur les DEX connus en base via `program_id` / `router_program_id`, - enregistrement des pools candidats et de leur listing initial sans parsing DEX complet, - alimentation conjointe des observations techniques, signaux d’analyse et tables métier normalisées, - maintien d’une logique encore indépendante des connecteurs DEX `0.7.x`. ### 6.030. Version `0.6.5` — Orchestration multi-clients WebSocket Réalisé : - introduction d’une abstraction `ws_manager.rs` pour piloter plusieurs `WsClient`, - construction des clients WS activés depuis la configuration d’endpoints, - démarrage et arrêt centralisés par endpoint ou globalement, - republication d’un flux unifié de `WsEvent` pour l’ensemble des clients gérés, - branchement optionnel du relais de détection WS sur tous les clients orchestrés, - préparation des futures politiques de répartition, supervision et reconnexion. ### 6.031. Version `0.6.6` — Démo légère `WsManager` dans `kb_demo_app` Réalisé : - ajout d’une fenêtre `Demo Ws Manager` dans `kb_demo_app`, - ouverture depuis la fenêtre principale, - affichage du snapshot consolidé du `WsManager`, - pilotage des endpoints WS gérés via `start/stop all` et `start/stop role`, - visualisation du flux unifié de `WsEvent`, - validation UI du branchement centralisé du relais de détection, - amélioration des messages de log UI pour les actions idempotentes déjà démarrées ou déjà arrêtées. ### 6.032. Version `0.7.0` — Résolution transactionnelle orientée DEX Réalisé : - introduction d’une file de résolution transactionnelle alimentée par les signatures issues des flux WS utiles, - corrélation initiale des `logsNotification` et `signatureNotification` avec des appels `getTransaction`, - utilisation du pool HTTP existant pour enrichir les signaux détectés côté WS, - persistance des résolutions transactionnelles dans `k_sol_onchain_observations` et `k_sol_analysis_signals`, - préparation du futur modèle transactionnel enrichi sans bloquer les flux temps réel. ### 6.033. Version `0.7.1` — Modèle transactionnel Solana enrichi Réalisé : - ajout des tables techniques `k_sol_chain_slots`, `k_sol_chain_transactions` et `k_sol_chain_instructions`, - distinction claire entre slot, transaction résolue et instructions normalisées, - support des instructions principales et inner instructions, - ajout des entités, DTOs et requêtes associées, - ajout d’un service de projection pour transformer une transaction JSON-RPC résolue en modèle transactionnel interne, - ajout des tests de roundtrip et de projection. ### 6.034. Version `0.7.2` — Décodeurs DEX spécifiques par programme et version Réalisé : - ajout d’un premier décodeur transactionnel spécifique Raydium AmmV4 / initialize2, - lecture combinée du `transaction_json` et des instructions projetées, - extraction des comptes utiles à l’initialisation du pool, - persistance des événements DEX décodés dans une table dédiée, - émission d’observations et de signaux dérivés du décodage DEX, - branchement automatique du décodage DEX depuis le pipeline de résolution transactionnelle, - préparation de la future détection métier pool / pair / listing. ### 6.035. Version `0.7.3` — Détection des nouveaux pools et paires via logs + transaction Réalisé : - transformation des événements DEX décodés en objets métier pool / pair / listing, - alimentation de `k_sol_pools`, `k_sol_pairs`, `k_sol_pool_tokens` et `k_sol_pool_listings`, - première détection métier pour Raydium AmmV4 / initialize2, - branchement automatique de la détection métier après résolution, projection et décodage DEX, - émission de signaux dédiés pour `new_pool`, `new_pair` et `first_listing_seen`, - garantie d’idempotence sur une même transaction déjà traitée. ### 6.036. Version `0.7.4` — Connecteurs DEX v1, vague 1 Réalisé : - ajout du décodeur `Pump.fun` pour les créations `create_v2`, - ajout du décodeur `PumpSwap` pour les trades `buy / sell`, - intégration des nouveaux décodeurs dans le pipeline générique `dex_decode`, - ajout de la détection métier `Pump.fun` vers `token / pool / pair / listing`, - maintien de `PumpSwap` au niveau décodage en attendant un mapping transactionnel plus riche, - préparation de l’extension vers `Meteora`, `Meteora DBC` et `LaunchLab`. ### 6.037. Version `0.7.5` — Connecteurs DEX v1, vague 2 Réalisé : - enrichissement du décodeur `PumpSwap` avec extraction des mints et du `pool_v2`, - persistance des événements `PumpSwap` enrichis dans `k_sol_dex_decoded_events`, - ajout de la détection métier `PumpSwap` vers `pool / pair / listing`, - émission des signaux dédiés `new_pool`, `new_pair` et `first_listing_seen`, - garantie d’idempotence sur une même transaction déjà traitée, - préparation du lot suivant pour `Meteora`, `Meteora DBC` et `LaunchLab`. ### 6.038. Version `0.7.6` — Connecteurs DEX v1, vague 3 Réalisé : - ajout du premier décodeur `Meteora DBC`, - prise en charge initiale des événements `create_pool` et `swap`, - persistance des événements `Meteora DBC` dans `k_sol_dex_decoded_events`, - ajout de la détection métier `Meteora DBC` vers `pool / pair / listing`, - émission des signaux dédiés `new_pool`, `new_pair` et `first_listing_seen`, - préparation du lot suivant pour `Meteora DAMM v2`, `Meteora DAMM v1` et `LaunchLab / Fun Launch`. ### 6.039. Version `0.7.7` — Meteora DAMM v2 Réalisé : - ajout du premier décodeur `Meteora DAMM v2`, - prise en charge initiale des événements de création de pool via `initialize_pool`, `initialize_pool_with_dynamic_config` et `initialize_customizable_pool`, - prise en charge initiale des swaps via `swap` et `swap2`, - persistance des événements `Meteora DAMM v2` dans `k_sol_dex_decoded_events`, - ajout de la détection métier `Meteora DAMM v2` vers `pool / pair / listing`, - préparation du rattachement futur entre `Meteora DBC` et `Meteora DAMM v2`. ### 6.040. Version `0.7.8` — Meteora DAMM v1 Réalisé : - ajout du premier décodeur `Meteora DAMM v1`, - prise en charge initiale des événements de création de pool via `initialize_pool` et `initialize_pool_with_config`, - prise en charge initiale des swaps via `swap`, - persistance des événements `Meteora DAMM v1` dans `k_sol_dex_decoded_events`, - ajout de la détection métier `Meteora DAMM v1` vers `pool / pair / listing`, - préparation du rattachement futur entre `Meteora DBC` et `Meteora DAMM v1`. ### 6.041. Version `0.7.9` — Launch origins / Fun Launch Réalisé : - ajout d’un registre des surfaces de lancement, - ajout d’un registre de clés observables par surface de lancement, - ajout d’une attribution entre événements/pools détectés et surfaces connues, - premier support de `Meteora Fun Launch` comme surface d’origine au-dessus de `Meteora DBC`, - branchement automatique de l’attribution depuis le pipeline de résolution transactionnelle, - conservation d’une séparation stricte entre protocole on-chain et origine de lancement. ### 6.042. Version `0.7.10` — Orca / Whirlpools Réalisé : - ajout du premier décodeur `Orca Whirlpools`, - prise en charge initiale des événements de création de pool via `initialize_pool` et `initialize_pool_v2`, - prise en charge initiale des swaps via `swap` et `swap_v2`, - persistance des événements `Orca Whirlpools` dans `k_sol_dex_decoded_events`, - ajout de la détection métier `Orca Whirlpools` vers `pool / pair / listing`, - utilisation de `PoolKind::Clmm` pour refléter la nature concentrée de `Whirlpools`. ### 6.043. Version `0.7.11` — FluxBeam Réalisé : - ajout du premier décodeur `FluxBeam`, - prise en charge initiale des événements de création de pool via un premier décodage `create_pool / initialize_pool`, - prise en charge initiale des swaps via `swap`, - persistance des événements `FluxBeam` dans `k_sol_dex_decoded_events`, - ajout de la détection métier `FluxBeam` vers `pool / pair / listing`, - conservation d’un premier décodage heuristique à raffiner ultérieurement avec des transactions FluxBeam réelles. ### 6.044. Version `0.7.12` — DexLab Réalisé : - ajout du premier décodeur `DexLab Swap/Pool`, - prise en charge initiale des événements de création de pool via un premier décodage `create_pool / initialize_pool`, - prise en charge initiale des swaps via `swap`, - persistance des événements `DexLab` dans `k_sol_dex_decoded_events`, - ajout de la détection métier `DexLab` vers `pool / pair / listing`, - conservation d’une séparation entre pool DexLab natif et éventuel `OpenBook Market ID` créé ensuite. ### 6.045. Version `0.7.13` — Bags / Moonit comme origines de lancement Réalisé : - extension de la couche `launch origins` à `Bags` et `Moonit`, - ajout d’un enregistrement programmatique des mappings `Bags` à partir des champs `tokenMint`, `dbcConfigKey`, `dbcPoolKey` et `dammV2PoolKey`, - prise en charge de l’attribution `Bags` par matching exact sur `config_account`, `pool_account` et `token_mint`, - prise en charge de l’attribution `Moonit` par détection automatique des token mints se terminant par `moon`, - conservation d’une séparation stricte entre origine de lancement et protocole on-chain. ### 6.046. Version `0.7.14` — Consolidation multi-DEX Réalisé : - ajout d’une couche commune `pool origins` pour enregistrer la première signature vue par le modèle pour chaque pool détecté, - rattachement d’un pool à son `decoded_event`, à son `pair`, à son `pool_listing` et à son éventuelle `launch_attribution`, - amélioration de la traçabilité inter-protocoles sans modifier les connecteurs DEX déjà validés, - conservation d’une logique idempotente avec mise à jour douce des liens `pair / listing / launch attribution`, - préparation de la future couche analytique sur une base multi-DEX plus cohérente. ### 6.047. Version `0.7.15` — Wallets, holdings et participants observés Réalisé : - ajout d’une première couche `wallets` pour les adresses observées dans le pipeline, - ajout d’une première couche `wallet participations` pour rattacher une adresse à une transaction, un decoded event, un pool et un pair, - extraction des rôles observés depuis les payloads décodés (`creator`, `payer`, `owner`, `user`), - branchement automatique depuis le pipeline de résolution transactionnelle, - report des holdings à l’étape suivante afin de conserver une séparation nette entre acteurs observés et balances observées. ### 6.048. Version `0.7.16` — Séries de prix, volumes et agrégats DEX Réalisé : - ajout d’une première table `trade events` pour normaliser les swaps observés, - ajout d’une première table `pair metrics` pour agréger les swaps par paire, - prise en charge des compteurs `trade_count`, `buy_count`, `sell_count`, - prise en charge optionnelle des volumes bruts `base` / `quote` et du dernier prix dérivé `quote_per_base`, - branchement automatique dans le pipeline de résolution transactionnelle, - conservation d’un modèle simple et idempotent en préparation de futures candles / séries temporelles. ### 6.049. Version `0.7.17` — Renforcement temps réel WS hybride Réalisé : - conservation de `logsSubscribe` comme source canonique de signatures candidates, - ajout d’une collecte de cibles `programSubscribe` à partir des DEX actifs connus, - ajout d’une collecte de cibles `accountSubscribe` à partir des pools actifs connus, - ajout d’une couche d’observations techniques WS hybrides pour `logs / program / account`, - ajout d’une première déduplication en mémoire des notifications techniques reçues en parallèle, - ajout d’une façade runtime pour exposer ce comportement au branchement `ws_manager`. ### 6.050. Version `0.7.18` — Backfill historique ciblé par token Réalisé : - ajout d’un premier service de backfill ciblé par `token_mint`, - récupération des signatures historiques via `getSignaturesForAddress`, - résolution des transactions pertinentes via `getTransaction`, - relecture du pipeline interne pour reconstruire transactions, décodage DEX, détection métier, origins, wallets et trade metrics, - ajout d’une seconde passe sur les pools découverts pour le token afin de récupérer des signatures supplémentaires liées à l’activité du pool, - conservation d’un périmètre ciblé sur des tokens encore actifs au lieu d’un scan exhaustif de la blockchain. ### 6.051. Version `0.7.19` — Holdings observés Réalisé : - ajout d’une première table `wallet holdings` pour agréger les couples `wallet/token` observés, - rattachement des holdings observés à la dernière transaction, au dernier decoded event, au dernier pool et au dernier pair connus, - conservation d’un champ `balance_raw` optionnel sans prétendre encore reconstruire un portefeuille complet, - alimentation automatique à partir des événements DEX déjà décodés et des wallets déjà observés, - branchement automatique dans le pipeline de résolution transactionnelle. ### 6.052. Version `0.7.20` — Candles / OHLCV Réalisé : - ajout d’une première table `pair candles` pour matérialiser les agrégats OHLCV par paire, - stockage en base des timeframes usuels (`1m`, `5m`, `15m`, `1h`), - conservation de `trade events` comme source brute de vérité, - ajout d’un service de régénération à la demande pour un timeframe arbitraire, - possibilité de choisir dynamiquement le timeframe lors d’une requête analytique, - branchement automatique dans le pipeline de résolution transactionnelle pour maintenir les candles matérialisées à jour. ### 6.053. Version `0.7.21` — Signaux analytiques plus riches Réalisé : - ajout d’une première table `pair analytic signals` dédiée aux signaux dérivés par paire, - prise en charge initiale des signaux `first_trade_seen`, `trade_burst_60s`, `buy_sell_imbalance_60s`, `price_jump_up_60s`, `price_jump_down_60s` et `volume_spike_60s`, - calcul des signaux à partir des `pair metrics`, `pair candles` et `trade events`, - persistance idempotente des signaux par paire et par bucket, - branchement automatique dans le pipeline de résolution transactionnelle. ### 6.054. Version `0.7.22` — `kb_demo_app` : inspection et tests du pipeline `0.7.x` Réalisé : - ajout d’une fenêtre dédiée `Demo Pipeline` dans `kb_demo_app`, - inspection du pipeline persistant par `signature`, - inspection du pipeline persistant par `token mint`, - inspection du pipeline persistant par `pair id`, - inspection du pipeline persistant par `pool address`, - affichage structuré des transactions résolues, événements DEX décodés, pools, paires, listings, launch origins, pool origins, wallets observés, holdings observés, trade events, pair metrics, candles et signaux analytiques, - possibilité d’utiliser un timeframe custom pour régénérer à la demande les candles non matérialisées, - conservation d’une instance partagée de `Database` dans `kb_demo_app` afin d’éviter la réouverture de la base et la réinitialisation du schéma à chaque commande UI, - validation pratique de l’inspection du pipeline `0.7.x` sans dépendre uniquement des logs bruts ou de la consultation manuelle de SQLite. ### 6.055. Version `0.7.23` — `kb_demo_app` : backfill token ciblé Réalisé : - ajout d’un pilotage UI du backfill historique ciblé par `token mint` dans `kb_demo_app`, - sélection du `token mint`, du rôle HTTP et des limites de signatures `mint / pool`, - exécution de `TokenBackfillService` depuis une commande Tauri dédiée, - affichage du résumé de backfill dans `Demo Pipeline`, - réinspection automatique du token après backfill lorsque des objets persistés exploitables sont effectivement reconstruits, - gestion explicite du cas où le backfill réussit sans matérialiser de token exploitable dans la base locale. ### 6.056. Version `0.7.24` — `kb_demo_app` : visualisation candles / OHLCV Réalisé : - ajout d’un affichage graphique des candles / OHLCV dans `kb_demo_app` via `echarts`, - sélection dynamique de la paire inspectée, - sélection dynamique du timeframe disponible, - affichage conjoint des chandeliers OHLC et du volume, - prise en charge des candles matérialisées et des candles régénérées à la demande pour un timeframe custom, - intégration du rendu graphique directement dans `Demo Pipeline`. ### 6.057. Version `0.7.25` — Enrichissement metadata des tokens Réalisé : - Ajout : - relecture locale du pipeline à partir des transactions brutes persistantes de la chaîne, - actualisation optionnelle des métadonnées de jetons manquantes lors de la relecture locale, - reconstruction des symboles de paires à partir des métadonnées des jetons, - commandes d’interface utilisateur dans le pipeline de démonstration 2 pour la relecture locale, - flux de travail d’actualisation du catalogue de jetons/paires piloté par les métadonnées. - Modifications : - les symboles de paires sont désormais dérivés comme `BASE/QUOTE` lorsque les deux symboles de jetons sont disponibles, - l’actualisation des métadonnées évite de nécessiter un remplissage complet de la blockchain lorsque les données de transaction brutes existent déjà localement. - Corrections : - suppression des cycles complets de suppression/remplissage répétés pour les métadonnées et les entités locales dérivées, - conservation de l’accès SQL dans les modules de requêtes de base de données au lieu du SQL brut au niveau du service. ### 6.058. Version `0.7.26` — Diagnostics locaux, replay et extraction instruction-scoped Réalisé : - Ajout du diagnostic local complet du pipeline persisté : - transactions OK / échouées, - événements décodés, - trade candidates, - trade events, - candles, - tokens, - pools, - pairs, - diagnostics par DEX, - diagnostics par paire, - samples d’événements manquants ou multi-trades. - Ajout des compteurs de santé du pipeline : - `diagnosticsClean`, - `blockingIssueCount`, - `actionableMissingTradeEventCount`, - `ignoredFailedTransactionTradeCandidateCount`, - `duplicateDecodedEventTradeCount`, - `multiTradeSignaturePairCount`, - `duplicateCandleBucketCount`. - Correction de l’agrégation des trades Raydium via extraction instruction-scoped des transferts SPL Token depuis `meta.innerInstructions`. - Correction des cas CPMM contenant plusieurs swaps dans une même transaction, sans mélange des montants entre instructions. - Conservation des transactions échouées comme événements décodés traçables, sans génération de `k_sol_trade_events`. - Clarification des compteurs de replay : - `pairCandleUpsertCount`, - `analyticSignalUpsertCount`. - Validation : - aucun trade candidate issu d’une transaction OK n’est perdu, - aucun trade event invalide n’est persisté, - aucun doublon réel par `decoded_event_id`, - aucune candle dupliquée par bucket, - aucune paire sans trade ni candle après replay, - seuls les trade candidates issus de transactions échouées restent ignorés. ### 6.059. Version `0.7.27` — Validation multi-DEX des connecteurs déjà branchés Objectif : verrouiller la non-régression du pipeline actuel avant d’ajouter de nouveaux DEX ou d’ouvrir la phase d’analyse `0.8.x`. À faire : - rejouer des bases neuves de test pour `pump_fun`, `pump_swap`, `raydium_cpmm` et `raydium_clmm`, - ne pas ajouter de nouveau DEX dans cette version ; cette version sert uniquement à valider les connecteurs déjà branchés, - vérifier pour chaque DEX le triptyque `decoded_event_count / trade_event_count / pair_candle_count`, - vérifier que les compteurs `diagnosticsClean`, `blockingIssueCount`, `actionableMissingTradeEventCount`, `duplicateDecodedEventTradeCount` et `duplicateCandleBucketCount` restent cohérents après replay, - garantir que les événements non pricés ou non candle ne produisent pas de trade event invalide, - conserver l’enrichissement `eventCategory`, `tradeCandidate`, `candleCandidate`, `liquidityCandidate`, `feeCandidate`, `rewardCandidate`, `adminCandidate` et `poolLifecycleCandidate` dans `payload_json`, - documenter les familles d’événements utilisées pour les candles et celles conservées seulement pour l’analyse, la liquidité, les frais, les rewards, l’administration ou la traçabilité, - ajouter ou compléter les tests unitaires sur `dex_decode`, `dex_detect`, `trade_aggregation`, `pair_candle_aggregation`, `pair_analytic_signal`, `local_pipeline_replay` et `local_pipeline_diagnostics`, - ajouter des requêtes SQL de diagnostic de référence pour contrôler rapidement les tables clés après backfill ou replay local, - conserver la tolérance aux événements DEX partiels tout en refusant les trades sans montant ou prix exploitable, - valider que les transactions échouées restent traçables dans les événements décodés sans produire de `k_sol_trade_events`. ### 6.060. Version `0.7.28` — Refactor DEX commun et préparation extension Réalisé : - ne pas toucher à `ws_client.rs`, `ws_manager.rs`, `http_client.rs`, `http_pool.rs` ni aux couches JSON-RPC déjà stabilisées, - extraire depuis `dex_decode.rs` les catégories communes d’événements : trade, candle candidate, liquidity candidate, fee candidate, reward candidate, admin candidate, pool lifecycle candidate, - créer une représentation interne documentée pour les familles d’événements DEX afin d’éviter les chaînes dispersées dans plusieurs fichiers, - clarifier la différence entre événement décodé, événement actionnable, trade candidate, candle candidate et événement conservé seulement pour analyse, - simplifier `dex_decode.rs` en gardant son rôle de service de persistance-orchestration, - simplifier `dex_detect.rs` en extrayant les helpers communs pool/pair/listing/origin/wallet quand cela réduit la duplication, - homogénéiser les contrats des modules `kb_lib/src/dex/*.rs` sans imposer trop tôt un trait générique lourd, - vérifier la rustdoc publique : utile, courte, orientée responsabilité ; supprimer la documentation redondante ou trop chargée, - conserver les tests verts et ajouter des tests de non-régression sur les catégories d’événements existantes. Contraintes : - refactor agressif autorisé si le résultat est plus propre, - chaque changement doit rester rejouable et testable, - aucun changement de comportement métier volontaire dans cette version, - aucun événement non price-action ne doit devenir un trade ou une candle. ### 6.061. Version `0.7.29` — Matrice DEX commune et validation baseline Réalisé : - ajouter `kb_lib/src/dex_support_matrix.rs` comme source commune de metadata DEX/surfaces ; - exposer pour chaque entrée : code interne, famille, version, type de surface, program id connu ou à vérifier, support actuel, statut, confiance, raisons de skip et activation catalogue ; - raccorder `dex_catalog`, `transaction_classification` et `protocol_candidate_recording` à cette matrice ; - ajouter le profil `0.7.29_multi_dex_matrix_baseline` ; - exposer la matrice dans le rapport de validation local ; - conserver explicitement le comportement `0.7.28` : transactions failed traçables mais non actionnables, et `meteora_damm_v1.swap` sans payload montant/prix non candidat trade/candle. Matrice cible initiale : | Code cible | Type | Statut `0.7.29` | Objectif immédiat | |---|---:|---|---| | `pump_fun` | launch + bonding curve | partiel | rattacher mint initial, bonding curve et migration | | `pump_swap` | AMM / swap | supporté | conserver trades/candles | | `raydium_cpmm` | AMM | supporté | conserver trades/candles | | `raydium_clmm` | CLMM | supporté | conserver trades/candles | | `raydium_launchlab` | launch surface | planifié, program id local connu | ajouter decoder/materialization dédiée | | `raydium_launchpad` | launch surface | à vérifier | ne pas inventer de program id | | `raydium_amm_v4` | AMM legacy | partiel | corpus dédié après autres Raydium | | `raydium_router` | router | partiel | ne pas matérialiser en trade direct avant preuve | | `raydium_stable_swap` | AMM legacy | planifié | traiter seulement si corpus pertinent | | `meteora_dlmm` | DLMM | supporté | verrouiller corpus et non-régression | | `meteora_damm_v1` | AMM legacy | partiel | garder skip explicite sans payload montant/prix | | `meteora_damm_v2` | AMM | partiel | corpus et séparation events | | `meteora_dbc` | launch / bonding curve | partiel | lifecycle, migration, swaps utiles | | `meteora_dlc` | à vérifier | à vérifier | confirmer surface/program id avant intégration | | `orca_whirlpools` | CLMM | partiel | validation par corpus | | `fluxbeam` | AMM | partiel | validation par corpus | | `dexlab` | AMM | partiel | validation par corpus | | `bags` | launch surface | planifié | attribution fiable, migration si prouvée | | `letsbonk` / `bonk` | launch surface | planifié | origine mint/lancement, sans supposer un AMM autonome | | `okx_dex` | aggregator/router | planifié | classifier sans trade direct avant preuve | | `boop_fun` | launch surface | planifié | origine mint/lancement/migration | | `moonshot` / `moonit` | launch surface | planifié | corpus, éviter heuristique faible | | `believe` | launch surface | planifié | confirmer comptes et migrations | | `heaven` | launch + AMM candidat | planifié | corpus et séparation launch/swap | | `zora` | à vérifier | à vérifier | hors phasage actif avant preuve Solana | ### 6.062. Version `0.7.30` — Classification fine des événements DEX décodés Réalisé : - ajouter `DexEventLifecycleKind` pour distinguer `trade_swap`, `pool_creation`, `pair_creation`, `liquidity_add`, `liquidity_remove`, `position_open`, `position_close`, `migration`, `launch`, `mint`, `burn`, `fee_collection`, `reward`, `admin_config` et `unknown`, - ajouter `DexEventActionability` pour distinguer `trade_candidate`, `non_actionable_trade`, `non_trade_useful`, `failed_transaction`, `informational` et `unknown`, - enrichir les payloads décodés avec `eventLifecycleKind`, `eventActionability` et `nonTradeUseful`, - exposer les compteurs diagnostics `decodedNonTradeUsefulEventCount`, `decodedNonActionableTradeEventCount` et `decodedUnknownEventCount`, - ajouter un résumé diagnostic par catégorie / lifecycle / actionability, - ajouter le profil `0.7.30_non_trade_event_classification`, - ne pas matérialiser encore les événements non-trade dans leurs tables dédiées. ### 6.063. Version `0.7.31` — Politique de matérialisation des failed transactions Réalisé : - empêcher `TradeAggregationService` de matérialiser une transaction dont `err_json` est renseigné ; - conserver les événements DEX décodés des failed transactions pour audit et diagnostic ; - réinitialiser les tables dérivées de marché pendant le replay local : `k_sol_trade_events`, `k_sol_pair_metrics`, `k_sol_pair_candles`, `k_sol_pair_analytic_signals` ; - reconstruire ensuite les trades/candles uniquement à partir des événements `tradeCandidate=true` et de transactions OK ; - exposer `resetMarketMaterializationDeletedCount` dans le résultat de replay UI ; - conserver la validation multi-DEX et la matrice DEX comme garde-fous avant d’ajouter les surfaces restantes. ### 6.064. Version `0.7.32` — Transactions inconnues et protocol candidates Réalisé : - consolider `k_sol_transaction_classifications`, déjà présente, avec les catégories utiles au suivi DEX, - consolider `k_sol_protocol_candidates`, déjà présente, pour prioriser les programmes inconnus ou partiellement reconnus, - classifier les transactions résolues en catégories : known supported, known partial, known non-trade, unknown program, unknown protocol candidate, unknown event kind, failed transaction, non-actionable trade, - conserver les `program_id`, comptes, signatures, préfixes de `data`, logs et indices d’instructions utiles à l’analyse, - créer des requêtes de diagnostic pour repérer les programmes inconnus fréquents, - permettre de promouvoir plus tard un protocol candidate vers un vrai DEX/surface sans perdre l’historique, - garantir que ces tables n’alimentent jamais directement les trades/candles. ### 6.065. Version `0.7.33` — Pair trading readiness et routes de cotation Réalisé : - classifier les paires `direct_wsol_quote`, `direct_stable_quote`, `inverse_wsol_base`, `inverse_stable_base`, `cross_quote_requires_router` et `non_trade_materialized` ; - exposer `quoteAssetClass` et `tradingRouteRequired` dans les diagnostics ; - éviter de bloquer la validation sur des paires seulement listées ou détectées sans trade matérialisé ; - préparer la future sélection des paires directement tradables versus paires nécessitant un router. ### 6.066. Version `0.7.34` — Événements non-trade v1 : liquidité et cycle de vie pool Réalisé : - stabiliser et étendre `k_sol_liquidity_events` au lieu de la recréer inutilement, - ajouter `k_sol_pool_lifecycle_events`, - matérialiser les événements `initialize`, `create_pool`, `migrate`, `open_position`, `close_position`, `increase_liquidity`, `decrease_liquidity`, `add_liquidity`, `remove_liquidity` et assimilés, - rattacher chaque événement à `dex_id`, `pool_id`, `pair_id`, `transaction_id`, `decoded_event_id`, `signature` et `slot` lorsque les informations existent, - conserver le `payload_json` source pour audit, - alimenter les diagnostics locaux avec les compteurs liquidité/lifecycle, - garantir qu’un événement de liquidité ou de cycle de vie ne produit jamais de candle directement. - première tranche DLMM : reconnaître et persister `meteora_dlmm.add_liquidity`, `meteora_dlmm.remove_liquidity`, `meteora_dlmm.initialize_position` et `meteora_dlmm.initialize_bin_array` comme événements non-trade utiles ; - intégrer la matérialisation non-trade dans les backfills ciblés token/pool, pas uniquement dans le replay local, afin que les diagnostics reflètent immédiatement les événements DLMM non-trade décodés ; - distinguer `PositionOpen` et `PositionClose` dans `LiquidityEventKind` au lieu de rabattre les positions CLMM/DLMM sur `Add`/`Remove` ; - conserver `meteora_damm_v1` manquant comme warning non bloquant lorsque le corpus de backfill local ne contient pas ce DEX. ### 6.067. Version `0.7.35` — Événements non-trade v2 : fees, rewards et administration Objectif : conserver les événements utiles au risque, au scoring, à l’économie du pool et à la traçabilité opérationnelle. À faire : - ajouter `k_sol_fee_events`, - ajouter `k_sol_reward_events`, - ajouter `k_sol_pool_admin_events`, - matérialiser les événements `collect_protocol_fee`, `collect_fund_fee`, `collect_creator_fee`, `collect_fee` et assimilés, - matérialiser les événements `set_reward_params`, `initialize_reward`, `collect_reward`, `update_reward_infos` et assimilés, - matérialiser les événements `set_config`, `update_config`, `set_authority`, `set_fee_rate`, `pause`, `resume` et assimilés, - rattacher ces événements aux transactions, decoded events, pools, paires et wallets observés lorsque les comptes le permettent, - documenter clairement que ces événements ne sont ni des trades ni des candles. ### 6.068. Version `0.7.36` — Meteora : DBC / DAMM v1 / DAMM v2 / DLMM Objectif : consolider Meteora comme famille multi-programmes au lieu de traiter chaque variante comme un cas isolé incomplet. À faire : - vérifier les programmes et discriminants réellement utilisés pour `Meteora DBC`, `Meteora DAMM v1`, `Meteora DAMM v2` et `Meteora DLMM`, - ajouter `meteora_dlmm` à la couverture cible seulement après corpus fiable, - constituer un corpus local par variante, - décoder les créations de pool, swaps, liquidités et événements lifecycle exploitables, - identifier les cas où `DBC` sert de launch origin avant migration vers un AMM, - alimenter `k_sol_dex_decoded_events`, les tables pool/pair/listing, les origins et les tables non-trade, - vérifier l’idempotence du replay local sur un corpus Meteora mixte, - documenter les limites connues des variantes insuffisamment couvertes. ### 6.069. Version `0.7.37` — Launch surfaces : LaunchLab, LetsBonk, Bags, Moonshot/Moonit, Boop.fun, Believe Objectif : détecter la première source de mint/lancement des tokens même lorsque le swap final se fait ailleurs. À faire : - ajouter ou stabiliser `raydium_launchlab` / `raydium_launchpad`, - ajouter `letsbonk` / `bonk_fun` comme surface d’origine rattachée à LaunchLab/Raydium si le corpus le prouve, - ajouter `boop_fun` comme surface d’origine et suivre ses migrations, - consolider `moonshot` / `moonit` avec corpus au lieu de simples heuristiques faibles, - consolider `bags` comme surface d’origine, notamment lorsque le token passe par Meteora DBC/DAMM, - ajouter `believe` comme surface d’origine associée à Meteora DBC si les comptes/authorities le prouvent, - distinguer `launch_origin`, `pool_origin`, `dex_effective` et `migration_target`, - rattacher les launch origins aux pools et paires lorsque les comptes permettent un matching fiable, - exposer les origins dans les diagnostics et l’UI d’inspection. ### 6.070. Version `0.7.38` — Heaven : corpus, launch et AMM Objectif : ajouter Heaven sans le classer trop tôt comme simple DEX ou simple launchpad. À faire : - vérifier le ou les programmes Heaven réellement observés sur mainnet, - constituer un corpus local de mints, pools et swaps Heaven, - séparer les événements de lancement des événements de swap, - ajouter les decoded events, launch origins, pool/pair/listing et trade events seulement lorsque les instructions sont prouvées, - documenter les limites si le corpus ne permet pas encore de matérialiser tous les événements, - vérifier que Heaven ne crée pas de candles invalides en cas d’événement de launch non pricé. ### 6.071. Version `0.7.39` — Orca / FluxBeam / DexLab : corpus et validation ciblée Objectif : consolider les connecteurs déjà présents à partir de corpus locaux vérifiables. À faire : - constituer des corpus locaux pour `Orca Whirlpools`, `FluxBeam` et `DexLab`, - vérifier les `program_id`, comptes, préfixes `data_json` et familles d’instructions utiles, - stabiliser les événements `create_pool`, `swap` et liquidité réellement observés, - alimenter les mêmes tables métier et diagnostics que les connecteurs déjà validés, - marquer explicitement les variantes partiellement supportées ou heuristiques, - rejouer les corpus plusieurs fois pour vérifier l’idempotence et l’absence de trades/candles invalides. ### 6.072. Version `0.7.40` — Raydium AMM v4 legacy : corpus et validation ciblée Objectif : traiter le vrai Raydium AMM v4 historique après les autres Raydium, afin de l’isoler de `raydium_cpmm`, `raydium_clmm` et des labels Raydium génériques. À faire : - rechercher des pools réellement rattachés au programme `675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8`, - constituer un petit corpus local de signatures/pools AMM v4 fiables, - vérifier que les adresses issues d’explorateurs ne sont pas seulement catégorisées globalement comme `Raydium`, - ajouter des requêtes de diagnostic par `program_id`, `accounts_json` et préfixe `data_json`, - valider `initialize2` et identifier les instructions de swap AMM v4 à supporter si elles apparaissent dans le corpus, - renommer/stabiliser les fonctions internes autour de `raydium_amm_v4` pour éviter l’ambiguïté avec `raydium_cpmm` et `raydium_clmm`, - documenter les limites connues si le corpus AMM v4 reste faible. ### 6.073. Version `0.7.41` — Validation DEX v1 consolidée Objectif : rejouer tous les DEX et launch surfaces supportés et valider les invariants du pipeline complet. À faire : - rejouer des bases neuves couvrant tous les connecteurs DEX supportés, - vérifier les compteurs globaux et par DEX : decoded events, trade events, liquidity events, lifecycle events, fee events, reward events, admin events, candles et analytic signals, - contrôler que chaque famille d’événements alimente uniquement les tables métier prévues, - vérifier les diagnostics bloquants et les samples d’anomalie, - documenter les corpus utilisés pour chaque DEX/surface, - conserver une matrice de support par DEX, variante, instruction et type d’événement, - verrouiller les invariants avant d’ouvrir l’analyse `0.8.x`. ### 6.074. Version `0.7.42` — `kb_demo_app` : overlays analytiques Objectif : rendre visibles les signaux analytiques directement sur les graphes et vues de marché. À faire : - afficher les signaux analytiques par bucket au-dessus ou autour des candles, - ajouter des marqueurs pour `first_trade_seen`, `trade_burst_60s`, `buy_sell_imbalance_60s`, `price_jump_up_60s`, `price_jump_down_60s` et `volume_spike_60s`, - permettre le filtrage par type de signal et par sévérité, - afficher un panneau latéral listant les signaux liés à une paire et à un timeframe, - préparer l’extension future vers Ichimoku, Kumo, projections ABCD et égalités temps/prix sans les mélanger au pipeline de décodage DEX. ### 6.075. Version `0.7.43` — `kb_demo_app` : vues consolidées token / pair / pool Objectif : fournir une lecture métier plus confortable du modèle `0.7.x`. À faire : - ajouter une fiche token avec mint, programme token, metadata, pools, paires et historique de découverte, - ajouter une fiche paire avec base/quote, DEX, pool, métriques, candles, signaux et derniers trades, - ajouter une fiche pool avec composition, vaults, origine, première signature vue, programme DEX et statut de décodage, - relier dans l’UI les launch origins, pool origins, wallets observés, holdings observés, événements de liquidité, lifecycle, fees, rewards, admin, candles et analytic signals, - préparer une navigation transversale entre objets techniques et objets métier, - rendre explicites les cas `tradeCount = null`, `lastPriceQuotePerBase = null`, tokens non enrichis et événements conservés uniquement pour analyse. ### 6.076. Version `0.7.44` — Finition UI `0.7.x` Objectif : stabiliser la couche desktop de validation avant l’ouverture de `0.8.x`. À faire : - consolider les vues ajoutées dans `kb_demo_app`, - améliorer la navigation, les filtres et la pagination, - ajouter les derniers raffinements de confort et de lisibilité, - préparer une base UI suffisamment stable pour la future phase d’analyse et filtrage `0.8.x`, - vérifier que les commandes Tauri restent de simples façades vers `kb_lib`. ### 6.077. Version `0.7.x` — Couverture DEX v1 Objectif : structurer les connecteurs DEX autour d’un pipeline complet de résolution, décodage, normalisation métier et classification des événements non-trade. Protocoles et surfaces cibles : - Pump.fun, - PumpSwap, - Raydium CPMM, - Raydium CLMM, - Raydium LaunchLab / Launchpad, - Raydium AMM v4 legacy, - Meteora DBC, - Meteora DAMM v1, - Meteora DAMM v2, - Meteora DLMM, - Orca Whirlpools, - FluxBeam, - DexLab, - Bags, - LetsBonk / Bonk.fun, - Boop.fun, - Moonshot / Moonit, - Believe, - Heaven. Hors périmètre immédiat : - `zora_solana`, tant qu’aucun programme Solana pertinent et exploitable n’est prouvé. Résultat attendu : - identification fiable des programmes et versions, - résolution des signatures pertinentes, - décodage des transactions utiles, - conservation des transactions inconnues ou candidates sans perte d’information, - création d’objets métier riches pour tokens, pools, paires, listings, participants, origins et holdings observés, - distinction claire entre première source de mint, launch origin, pool origin, DEX effectif et migration target, - enrichissement metadata des tokens découverts, - séparation stricte entre événements candle/trade et événements utiles seulement à l’analyse, - matérialisation progressive des événements non-trade dans des tables métier dédiées, - préparation d’une détection temps réel hybride et d’un backfill ciblé compatible avec les mêmes objets métier, - préparation d’agrégats DEX plus riches, de candles/OHLCV et d’une UI d’inspection du pipeline `0.7.x`. ### 6.078. Version `0.8.x` — Analyse et filtrage Objectif : transformer les événements bruts en signaux exploitables. À faire : - agrégation des métriques, - règles de filtrage, - exclusions des tokens non tradables, - statistiques de comportement, - premiers patterns, - enrichissement des signaux analytiques préparés en fin de `0.7.x`, - indicateurs graphiques optionnels comme Ichimoku / Kumo, - outils de sélection manuelle de points ABC et projection d’un point D selon des règles temps/prix explicites, - séparation stricte entre signaux analytiques observés, projections hypothétiques et décisions de trading. ### 6.079. Version `1.x.y` — Wallets et swap préparatoire Objectif : préparer la couche d’action. À faire : - gestion du répertoire wallets, - chargement sécurisé des keypairs, - abstraction wallet, - préparation d’ordres et de swaps, - simulation et garde-fous. ### 6.080. Version `2.x.y` — Trading semi-automatisé Objectif : brancher l’analyse à l’action tout en gardant des garde-fous explicites. À faire : - scénarios d’achat/vente, - règles d’entrée/sortie, - limites de risque, - confirmations explicites ou semi-automatiques, - journaux d’exécution. ### 6.081. Version `3.x.y` — Yellowstone gRPC Objectif : ajouter le connecteur gRPC dédié. À faire : - `GrpcClient` basé sur `yellowstone-grpc-client`, - adaptation du pipeline d’événements, - coexistence HTTP / WS / gRPC, - politique de répartition par source. ## 7. Organisation des modules ciblés ### 7.1. `kb_lib` Modules stables à ne pas remanier dans la phase immédiate : - `ws_client.rs` - `ws_manager.rs` - `http_client.rs` - `http_pool.rs` - `json_rpc_ws.rs` - `solana_pubsub_ws.rs` Modules ciblés par le refactor et la consolidation DEX : - `dex.rs` - `dex/*.rs` - `dex_decode.rs` - `dex_detect.rs` - `trade_aggregation.rs` - `pair_candle_aggregation.rs` - `pair_analytic_signal.rs` - `launch_origin.rs` - `pool_origin.rs` - `wallet_observation.rs` - `wallet_holding_observation.rs` - `token_metadata.rs` - `local_pipeline_replay.rs` - `local_pipeline_validation.rs` - `local_pipeline_diagnostics.rs` `local_pipeline_diagnostics.rs` est volontairement conservé comme outil temporaire de validation. Il pourra devenir obsolète ou être remplacé lorsque les tests DEX seront stabilisés. Il n’est pas prioritaire de le refactorer maintenant. ### 7.2. Base de données Organisation de la couche DB à conserver : - `db/schema.rs` : création des tables et index uniquement ; chaque table ou index reste dans une fonction dédiée, - `db/entities/*` : entités proches des lignes persistées, - `db/dtos/*` : DTOs applicatifs, - `db/queries/*` : requêtes SQL regroupées par table ou usage, - `db/queries/local_pipeline_diagnostics.rs` : requêtes de diagnostic local, utiles pendant la validation DEX. `schema.rs` peut rester long tant qu’il reste strictement un fichier de schéma. Le split prioritaire concerne plutôt les responsabilités métier dans `dex_decode.rs`, `dex_detect.rs` et `trade_aggregation.rs`. ### 7.3. `kb_demo_app` Responsabilités cibles : - lancement Tauri, - commandes UI, - affichage des états et messages, - réception des événements venant de `kb_lib`, - fenêtres de démonstration / diagnostic isolées, - inspection du pipeline persisté, - affichage candles et futurs overlays analytiques. `kb_demo_app` ne doit pas contenir de logique métier DEX profonde. ## 8. Ligne de conduite sur le `WsClient` Le `WsClient` doit être conçu en plusieurs couches : 1. transport brut WebSocket, 2. encodage/décodage JSON texte, 3. couche JSON-RPC 2.0, 4. couche Solana subscribe/unsubscribe/notification, 5. couche métier pour la répartition des messages. Cette séparation évite de mélanger : - les réponses à requêtes simples, - les réponses de subscribe, - les réponses de unsubscribe, - les notifications push. ## 9. Politique initiale de reconnexion Au départ : - pas de reconnexion automatique, - pas de resubscribe automatique, - comportement explicite contrôlé par l’appelant. Plus tard, ce comportement pourra devenir configurable dans `config.json` et pilotable depuis l’application. ## 10. Politique initiale de fermeture À la fermeture d’un `WsClient` : 1. marquer le client en arrêt, 2. tenter les `unsubscribe` actifs, 3. attendre les réponses dans une fenêtre bornée, 4. forcer la purge locale si nécessaire, 5. fermer proprement le flux d’écriture, 6. laisser se terminer le flux de lecture, 7. journaliser clairement les cas dégradés. ## 10.5. Jalons `0.7.29` Réalisé / à maintenir : - matrice DEX commune dans `kb_lib/src/dex_support_matrix.rs` ; - raccordement minimal du catalogue DEX à cette matrice ; - raccordement des mappings program id -> protocole utilisés par la classification transactionnelle et les protocol candidates ; - profil `0.7.29_multi_dex_matrix_baseline` ; - exposition de la matrice dans le rapport de validation local ; - aucune modification volontaire du comportement trade/candle validé en `0.7.28`. Validé en `0.7.30` : classification fine des événements décodés via `eventLifecycleKind`, `eventActionability` et `nonTradeUseful`, avec diagnostics associés et sans changement volontaire sur les trades/candles. À poursuivre après `0.7.31` : transactions inconnues/protocol candidates, puis matérialisation contrôlée des événements non-trade utiles, sans alimenter les trades/candles actionnables. ## 11. Documentation et livrables de référence Le projet doit maintenir au minimum : - un `README.md` global, - un `ROADMAP.md` global, - un `CHANGELOG.md` global, - des `README.md` et `TODO.md` par crate à mesure de l’évolution, - des tests unitaires robustes, - les bindings TS générés via `cargo test export_bindings` lorsque les types partagés évoluent. ## 12. Priorité immédiate La priorité immédiate est désormais la suivante : 1. conserver la validation acquise `0.7.31` : transactions failed traçables mais exclues des `trade_events`, metrics et candles, aucun trade/candle candidate sans payload montant/prix exploitable, aucun diagnostic bloquant masqué, 2. utiliser la matrice `0.7.29` (`kb_lib/src/dex_support_matrix.rs`) comme source commune pour le catalogue DEX, les mappings program id -> protocole, la classification transactionnelle et les protocol candidates, 3. garder les clients HTTP/WS et managers réseau hors du refactor DEX tant qu’ils ne bloquent pas le pipeline, 4. consolider les événements non-trade sans les confondre avec les trades/candles : lifecycle de pool, liquidité, fees, rewards, admin/config, migration et launch/mint, 5. rattacher les launch surfaces aux tokens et aux pools migrés : Raydium LaunchLab/Launchpad, LetsBonk/Bonk.fun, Boop.fun, Moonshot/Moonit, Believe, Bags et Heaven, 6. consolider Meteora avec corpus fiable : `meteora_dlmm`, `meteora_damm_v1`, `meteora_damm_v2`, `meteora_dbc` et `meteora_dlc` si le programme est confirmé, 7. consolider Orca, FluxBeam et DexLab sur corpus, 8. traiter `raydium_amm_v4` legacy seulement après les autres Raydium, avec corpus dédié prouvant le programme `675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8`, 9. ajouter une matérialisation dédiée des transactions inconnues ou partiellement décodées pour analyser les DEX manquants sans polluer les trades/candles, 10. effectuer une validation DEX v1 consolidée sur tous les connecteurs supportés avant de considérer la couche DEX `0.7.x` comme stable, 11. ajouter ensuite les overlays des signaux analytiques sur les candles, 12. consolider les vues métier `token / pair / pool` dans `kb_demo_app`, y compris les événements liquidité, lifecycle, fees, rewards et admin, 13. stabiliser l’ergonomie, les filtres, la pagination et la navigation de l’UI d’inspection, 14. préparer ensuite l’ouverture de `0.8.x` pour l’analyse, les filtres, les patterns et les projections graphiques, 15. préparer enfin Yellowstone gRPC comme extension de capacité, et non comme remplacement du socle HTTP / WS existant.