0.6.6

ROADMAP.md

@@ -436,7 +436,18 @@ 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.7.0` — Résolution transactionnelle orientée DEX
+### 6.031. Version `0.6.6` — Démo légère `WsManager` dans `kb_app`
+Réalisé :
+
+- ajout d’une fenêtre `Demo Ws Manager` dans `kb_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
 Objectif : relier la détection temps réel aux transactions Solana complètes.
 
 À faire :
@@ -446,7 +457,7 @@ Objectif : relier la détection temps réel aux transactions Solana complètes.
 - utiliser le pool HTTP existant pour enrichir les signaux détectés côté WS,
 - éviter qu’une notification intéressante reste au niveau d’un simple signal technique sans résolution métier.
 
-### 6.032. Version `0.7.1` — Modèle transactionnel Solana enrichi
+### 6.033. Version `0.7.1` — Modèle transactionnel Solana enrichi
 Objectif : préparer un modèle interne plus riche, inspiré d’une vision `slot -> signature -> instruction`.
 
 À faire :
@@ -456,7 +467,7 @@ Objectif : préparer un modèle interne plus riche, inspiré d’une vision `slo
 - conserver la possibilité de relier plus tard un pool, un token ou un wallet à une signature fondatrice,
 - préparer l’historique transactionnel nécessaire aux futurs décodeurs DEX.
 
-### 6.033. Version `0.7.2` — Décodeurs DEX spécifiques par programme et version
+### 6.034. Version `0.7.2` — Décodeurs DEX spécifiques par programme et version
 Objectif : remplacer les heuristiques ponctuelles par de vrais décodeurs Rust dédiés.
 
 À faire :
@@ -466,7 +477,7 @@ Objectif : remplacer les heuristiques ponctuelles par de vrais décodeurs Rust d
 - encapsuler les index de comptes et les motifs de logs propres à chaque protocole,
 - prévoir des décodeurs séparés au minimum pour Raydium, Pump.fun / PumpSwap, Meteora, puis les autres cibles.
 
-### 6.034. Version `0.7.3` — Détection des nouveaux pools et paires via logs + transaction
+### 6.035. Version `0.7.3` — Détection des nouveaux pools et paires via logs + transaction
 Objectif : détecter rapidement les nouvelles paires/pools à partir des flux RPC et des transactions enrichies.
 
 À faire :
@@ -476,7 +487,7 @@ Objectif : détecter rapidement les nouvelles paires/pools à partir des flux RP
 - extraire token A, token B, LP mint, vaults et comptes utiles quand cela est possible,
 - alimenter `kb_pools`, `kb_pairs`, `kb_pool_tokens` et `kb_pool_listings` avec des données plus fiables que la seule détection de comptes.
 
-### 6.035. Version `0.7.4` — Modèle métier DEX enrichi
+### 6.036. Version `0.7.4` — Modèle métier DEX enrichi
 Objectif : faire converger la détection technique et le modèle métier vers une vision proche de l’activité réelle du marché.
 
 À faire :
@@ -486,7 +497,7 @@ Objectif : faire converger la détection technique et le modèle métier vers un
 - préparer une vision cohérente `token <-> pool <-> pair <-> protocole`,
 - distinguer les objets de référence des événements d’activité.
 
-### 6.036. Version `0.7.5` — Wallets, holdings et participants observés
+### 6.037. Version `0.7.5` — Wallets, holdings et participants observés
 Objectif : préparer le suivi des acteurs on-chain autour des pools et tokens détectés.
 
 À faire :
@@ -496,7 +507,7 @@ Objectif : préparer le suivi des acteurs on-chain autour des pools et tokens d
 - préparer l’identification des créateurs, mint authorities, wallets d’activité et contreparties,
 - éviter de limiter l’analyse future au seul niveau token/pool sans vision des participants.
 
-### 6.037. Version `0.7.6` — Séries de prix, volumes et agrégats DEX
+### 6.038. Version `0.7.6` — Séries de prix, volumes et agrégats DEX
 Objectif : préparer la couche analytique fine à partir des événements métier normalisés.
 
 À faire :
@@ -506,7 +517,7 @@ Objectif : préparer la couche analytique fine à partir des événements métie
 - permettre plus tard le calcul d’OHLCV, volume, nombre de trades et liquidité par fenêtre,
 - préparer le terrain pour la couche analytique `0.8.x`.
 
-### 6.038. Version `0.7.x` — DEX connectors v1
+### 6.039. Version `0.7.x` — DEX connectors v1
 Objectif : structurer les connecteurs DEX autour d’un pipeline complet de résolution, décodage et normalisation métier.
 
 Cibles initiales possibles :
@@ -526,7 +537,7 @@ Résultat attendu :
 - création d’objets métier riches pour tokens, pools, paires, wallets, holdings et séries de prix,
 - remplacement progressif des scripts heuristiques externes par des composants Rust intégrés.
 
-### 6.039. Version `0.8.x` — Analyse et filtrage
+### 6.040. Version `0.8.x` — Analyse et filtrage
 Objectif : transformer les événements bruts en signaux exploitables.
 
 À faire :
@@ -537,7 +548,7 @@ Objectif : transformer les événements bruts en signaux exploitables.
 - statistiques de comportement,
 - premiers patterns.
 
-### 6.040. Version `1.x.y` — Wallets et swap préparatoire
+### 6.041. Version `1.x.y` — Wallets et swap préparatoire
 Objectif : préparer la couche d’action.
 
 À faire :
@@ -548,7 +559,7 @@ Objectif : préparer la couche d’action.
 - préparation d’ordres et de swaps,
 - simulation et garde-fous.
 
-### 6.041. Version `2.x.y` — Trading semi-automatisé
+### 6.042. Version `2.x.y` — Trading semi-automatisé
 Objectif : brancher l’analyse à l’action tout en gardant des garde-fous explicites.
 
 À faire :
@@ -559,7 +570,7 @@ Objectif : brancher l’analyse à l’action tout en gardant des garde-fous exp
 - confirmations explicites ou semi-automatiques,
 - journaux d’exécution.
 
-### 6.042. Version `3.x.y` — Yellowstone gRPC
+### 6.043. Version `3.x.y` — Yellowstone gRPC
 Objectif : ajouter le connecteur gRPC dédié.
 
 À faire :
@@ -580,10 +591,12 @@ Modules cibles à court terme :
 - `constants.rs`
 - `types.rs`
 - `ws_client.rs`
+- `ws_manager.rs`
 - `http_client.rs`
-- `rpc_json.rs`
-- `rpc_ws.rs`
-- `rpc_ws_solana.rs`
+- `http_pool.rs`
+- `json_rpc_ws.rs`
+- `solana_pubsub_ws.rs`
+- `detect.rs`
 
 ### 7.2. `kb_app`
 Responsabilités cibles :
@@ -644,9 +657,10 @@ Le projet doit maintenir au minimum :
 ## 12. Priorité immédiate
 La priorité immédiate est désormais la suivante :
 
-1. démarrer la version `0.6.3` avec l’enrichissement des notifications WS utiles,
-2. améliorer l’extraction des métadonnées utiles depuis `accountNotification`, `logsNotification` et `signatureNotification`,
-3. produire des observations on-chain plus précises et homogènes,
-4. préparer ensuite la version `0.6.4` pour les premières règles de détection technique,
-5. conserver le découplage entre transport, détection et stockage,
-6. planifier enfin `0.6.5` pour l’orchestration multi-clients WebSocket via `ws_pool.rs` ou `ws_manager.rs`.
+1. démarrer la version `0.7.0` avec la résolution transactionnelle orientée DEX,
+2. introduire une file de signatures ou de résolutions alimentée par les flux WS utiles,
+3. corréler `logsNotification`, `programNotification` et `signatureNotification` avec des appels `getTransaction`,
+4. utiliser le pool HTTP existant pour enrichir les signaux détectés côté WS,
+5. préparer ensuite la version `0.7.1` pour le modèle transactionnel Solana enrichi,
+6. conserver le découplage entre transport, résolution transactionnelle, détection métier et stockage.
+