0.7.27 +Refactor

ROADMAP.md

@@ -21,7 +21,7 @@ Le projet vise en priorité :
 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_app` : application Tauri V2 avec frontend TypeScript, chargée de l’interface et de la délégation vers `kb_lib`.
+- `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
 
@@ -40,8 +40,8 @@ Le socle du projet doit respecter les contraintes suivantes :
 
 ### 2.3. Règles de responsabilité
 
-- `kb_app` ne doit pas embarquer la logique métier réseau ou Solana.
-- `kb_app` doit seulement orchestrer l’UI, les commandes Tauri et les appels vers `kb_lib`.
+- `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
@@ -146,13 +146,13 @@ Objectif : corriger le squelette et poser la base de travail.
 Réalisé :
 
 - correction de `kb_lib/src/lib.rs`,
-- création de `KbError`,
-- création de `KbConfig`,
-- création de `init_tracing`,
+- 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_app/src/lib.rs` en conformité,
-- documentation de `kb_app/src/splash.rs`,
+- 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
@@ -174,7 +174,7 @@ Objectif : valider le transport via l’application desktop.
 
 Réalisé :
 
-- intégration minimale de `WsClient` dans `kb_app`,
+- intégration minimale de `WsClient` dans `kb_demo_app`,
 - boutons start/stop,
 - zone de logs,
 - validation du flux `frontend -> tauri -> kb_lib -> frontend`.
@@ -229,7 +229,7 @@ Réalisé :
 - 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_app`
+### 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é :
@@ -306,7 +306,7 @@ Réalisé :
 - 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_app`
+### 6.016. Version `0.4.4` — Démo HTTP dans `kb_demo_app`
 Réalisé :
 
 - ajout d’une fenêtre `Demo Http`,
@@ -325,9 +325,9 @@ Réalisé :
 
 - configuration DB dans `config.json`,
 - ouverture/validation SQLite,
-- façade `KbDatabase`,
+- façade `kb_lib::Database`,
 - premier schéma technique,
-- table `kb_db_metadata`,
+- 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
@@ -341,7 +341,7 @@ Réalisé :
 ### 6.020. Version `0.5.2` — Stockage des tokens observés
 Réalisé :
 
-- ajout de la table `kb_observed_tokens`,
+- 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,
@@ -350,9 +350,9 @@ Réalisé :
 ### 6.021. Version `0.5.3` — Événements et signaux locaux
 Réalisé :
 
-- conservation des événements runtime techniques via `kb_db_runtime_events`,
-- ajout des observations on-chain brutes via `kb_onchain_observations`,
-- ajout des signaux d’analyse via `kb_analysis_signals`,
+- 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.
 
@@ -436,10 +436,10 @@ Réalisé :
 - 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_app`
+### 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_app`,
+- 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`,
@@ -453,13 +453,13 @@ 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 `kb_onchain_observations` et `kb_analysis_signals`,
+- 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 `kb_chain_slots`, `kb_chain_transactions` et `kb_chain_instructions`,
+- 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,
@@ -481,7 +481,7 @@ Réalisé :
 Réalisé :
 
 - transformation des événements DEX décodés en objets métier pool / pair / listing,
-- alimentation de `kb_pools`, `kb_pairs`, `kb_pool_tokens` et `kb_pool_listings`,
+- 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`,
@@ -501,7 +501,7 @@ Réalisé :
 Réalisé :
 
 - enrichissement du décodeur `PumpSwap` avec extraction des mints et du `pool_v2`,
-- persistance des événements `PumpSwap` enrichis dans `kb_dex_decoded_events`,
+- 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,
@@ -512,7 +512,7 @@ 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 `kb_dex_decoded_events`,
+- 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`.
@@ -523,7 +523,7 @@ 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 `kb_dex_decoded_events`,
+- 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`.
 
@@ -533,7 +533,7 @@ 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 `kb_dex_decoded_events`,
+- 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`.
 
@@ -553,9 +553,9 @@ 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 `kb_dex_decoded_events`,
+- 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 `KbPoolKind::Clmm` pour refléter la nature concentrée de `Whirlpools`.
+- utilisation de `PoolKind::Clmm` pour refléter la nature concentrée de `Whirlpools`.
 
 ### 6.043. Version `0.7.11` — FluxBeam
 Réalisé :
@@ -563,7 +563,7 @@ 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 `kb_dex_decoded_events`,
+- 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.
 
@@ -573,7 +573,7 @@ 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 `kb_dex_decoded_events`,
+- 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.
 
@@ -662,33 +662,33 @@ Réalisé :
 - 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_app` : inspection et tests du pipeline `0.7.x`
+### 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_app`,
+- 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 `KbDatabase` dans `kb_app` afin d’éviter la réouverture de la base et la réinitialisation du schéma à chaque commande UI,
+- 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_app` : backfill token ciblé
+### 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_app`,
+- 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 `KbTokenBackfillService` depuis une commande Tauri dédiée,
+- 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_app` : visualisation candles / OHLCV
+### 6.056. Version `0.7.24` — `kb_demo_app` : visualisation candles / OHLCV
 Réalisé :
 
-- ajout d’un affichage graphique des candles / OHLCV dans `kb_app` via `echarts`,
+- 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,
@@ -736,7 +736,7 @@ Réalisé :
   - `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 `kb_trade_events`.
+- 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`.
@@ -763,15 +763,15 @@ Objectif : verrouiller la non-régression du pipeline actuel avant d’ajouter d
 - 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 `kb_trade_events`.
+- 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` — Matérialisation des événements liquidité et cycle de vie pool
 Objectif : exploiter les événements non buy/sell utiles à l’analyse et au trading semi-automatique sans les mélanger avec les trades/candles.
 
 À faire :
 
-- stabiliser ou ajouter la table `kb_liquidity_events`,
-- stabiliser ou ajouter la table `kb_pool_lifecycle_events`,
+- stabiliser ou ajouter la table `k_sol_liquidity_events`,
+- stabiliser ou ajouter la table `k_sol_pool_lifecycle_events`,
 - matérialiser les événements de type `increase_liquidity`, `decrease_liquidity`, `add_liquidity`, `remove_liquidity`, `open_position`, `close_position`, `initialize`, `create_pool`, `migrate` et assimilés,
 - rattacher chaque événement métier à `dex_id`, `pool_id`, `pair_id`, `transaction_id`, `decoded_event_id`, `signature` et `slot`,
 - conserver le `payload_json` source pour audit et extension future,
@@ -784,9 +784,9 @@ Objectif : conserver les événements non price-action utiles au risque, à l’
 
 À faire :
 
-- ajouter ou stabiliser `kb_fee_events`,
-- ajouter ou stabiliser `kb_reward_events`,
-- ajouter ou stabiliser `kb_pool_admin_events`,
+- ajouter ou stabiliser `k_sol_fee_events`,
+- ajouter ou stabiliser `k_sol_reward_events`,
+- ajouter ou stabiliser `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,
@@ -801,7 +801,7 @@ Objectif : ajouter ou stabiliser les connecteurs Meteora avec une séparation cl
 - vérifier les programmes et discriminants réellement utilisés pour `Meteora DBC`, `Meteora DAMM v1` et `Meteora DAMM v2`,
 - constituer un petit corpus local de pools et signatures fiables pour chaque variante,
 - décoder les créations de pool, swaps et événements de liquidité exploitables,
-- alimenter `kb_dex_decoded_events`, les tables métier pool/pair/listing et les nouvelles tables d’événements non-trade,
+- alimenter `k_sol_dex_decoded_events`, les tables métier pool/pair/listing et les nouvelles tables d’événements non-trade,
 - vérifier l’idempotence du replay local sur un corpus mixte Meteora,
 - documenter les limites connues des variantes insuffisamment couvertes par le corpus.
 
@@ -854,7 +854,7 @@ Objectif : traiter le vrai Raydium AMM v4 historique après les autres DEX, afin
 - renommer et stabiliser les fonctions internes autour de `raydium_amm_v4` afin d’éviter l’ambiguïté avec `raydium_cpmm` et `raydium_clmm`,
 - documenter les limites connues si le corpus AMM v4 reste trop faible.
 
-### 6.067. Version `0.7.35` — `kb_app` : overlays analytiques
+### 6.067. Version `0.7.35` — `kb_demo_app` : overlays analytiques
 Objectif : rendre visibles les signaux analytiques directement sur les graphes et vues de marché.
 
 À faire :
@@ -865,7 +865,7 @@ Objectif : rendre visibles les signaux analytiques directement sur les graphes e
 - afficher un panneau latéral listant les signaux liés à une paire et à un timeframe,
 - préparer l’extension future vers des indicateurs Ichimoku, Kumo, projections ABCD et égalités temps/prix sans les mélanger au pipeline de décodage DEX.
 
-### 6.068. Version `0.7.36` — `kb_app` : vues consolidées token / pair / pool
+### 6.068. Version `0.7.36` — `kb_demo_app` : vues consolidées token / pair / pool
 Objectif : fournir une lecture métier plus confortable du modèle `0.7.x`.
 
 À faire :
@@ -882,7 +882,7 @@ Objectif : stabiliser la couche desktop de validation avant l’ouverture de `0.
 
 À faire :
 
-- consolider les vues ajoutées dans `kb_app`,
+- 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`,
@@ -996,7 +996,7 @@ Modules cibles à court terme :
 - `db/dtos/*`
 - `db/queries/*`
 
-### 7.2. `kb_app`
+### 7.2. `kb_demo_app`
 Responsabilités cibles :
 
 - lancement Tauri,
@@ -1060,12 +1060,12 @@ La priorité immédiate est désormais la suivante :
 2. vérifier sur bases neuves et après replay local les invariants bloquants du pipeline : `diagnosticsClean = true`, `blockingIssueCount = 0`, aucun trade candidate exploitable perdu, aucun trade event invalide, aucun doublon réel par `decoded_event_id`, aucune candle dupliquée par bucket,
 3. documenter les requêtes SQL de diagnostic de référence et les résultats attendus pour les tables clés du pipeline,
 4. matérialiser ensuite les événements non buy/sell utiles au trading et à l’analyse : liquidité, cycle de vie des pools, fees, rewards et administration,
-5. garantir que ces événements non-trade restent séparés des `kb_trade_events` et des candles tout en restant rattachés aux transactions, decoded events, pools, pairs et wallets observés,
+5. garantir que ces événements non-trade restent séparés des `k_sol_trade_events` et des candles tout en restant rattachés aux transactions, decoded events, pools, pairs et wallets observés,
 6. ajouter ou stabiliser les autres DEX par lots vérifiables : Meteora, surfaces de lancement, Orca, FluxBeam et DexLab,
 7. traiter `raydium_amm_v4` legacy seulement après les autres DEX, avec un corpus dédié prouvant le programme `675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8`,
 8. 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,
 9. ajouter ensuite les overlays des signaux analytiques sur les candles,
-10. consolider les vues métier `token / pair / pool` dans `kb_app`, y compris les événements liquidité, lifecycle, fees, rewards et admin,
+10. consolider les vues métier `token / pair / pool` dans `kb_demo_app`, y compris les événements liquidité, lifecycle, fees, rewards et admin,
 11. stabiliser l’ergonomie, les filtres, la pagination et la navigation de l’UI d’inspection,
 12. préparer ensuite l’ouverture de `0.8.x` pour l’analyse, les filtres, les patterns et les projections graphiques,
 13. préparer enfin Yellowstone gRPC comme extension de capacité, et non comme remplacement du socle HTTP / WS existant.