0.3.4

ROADMAP.md

@@ -61,11 +61,11 @@ Le projet doit pouvoir évoluer progressivement vers les capacités suivantes :
 
 ## 4. Configuration cible
 
-La configuration applicative sera stockée dans un fichier `config.json`.
+La configuration applicative est stockée dans un fichier `config.json`.
 
 ### 4.1. Points à couvrir dans la configuration
 
-Le fichier devra à terme permettre de configurer :
+Le fichier doit permettre de configurer :
 
 - les endpoints HTTP,
 - les endpoints WebSocket,
@@ -93,12 +93,13 @@ Le fichier devra à terme permettre de configurer :
 
 ### 4.3. Exigences particulières
 
-Chaque endpoint devra pouvoir porter sa propre configuration, par exemple :
+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,
@@ -116,7 +117,7 @@ Exemples de rôles futurs :
 
 ## 5. Tracing cible
 
-Le tracing devra être centralisé dans `kb_lib`.
+Le tracing est centralisé dans `kb_lib`.
 
 ### 5.1. Exigences initiales
 
@@ -139,83 +140,132 @@ Le tracing devra être centralisé dans `kb_lib`.
 
 ## 6. Phasage par versions
 
-## 6.1. Version `0.0.2` — Socle conforme
+### 6.1. Version `0.0.2` — Socle conforme
 
 Objectif : corriger le squelette et poser la base de travail.
 
-À faire :
+Réalisé :
 
-- corriger `kb_lib/src/lib.rs`,
-- créer `KbError`,
-- créer `KbConfig`,
-- créer `init_tracing`,
-- créer les constantes Solana officielles,
-- préparer les modules `ws_client` et `http_client`,
-- remettre `kb_app/src/lib.rs` en conformité,
-- documenter `kb_app/src/splash.rs`,
-- garder une UI minimale avec bouton connect / disconnect et zone de sortie.
+- correction de `kb_lib/src/lib.rs`,
+- création de `KbError`,
+- création de `KbConfig`,
+- création de `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`,
+- UI Tauri minimale.
 
-Livrables :
-
-- squelette propre,
-- config JSON minimale,
-- tracing centralisé,
-- UI Tauri minimale opérationnelle,
-- premiers types partagés.
-
-## 6.2. Version `0.1.x` — Transport WebSocket générique
+### 6.2. Version `0.1.x` — Transport WebSocket générique
 
 Objectif : construire un vrai `WsClient` asynchrone clonable.
 
-À faire :
+Réalisé :
 
-- `connect`, `disconnect`, `is_connected`,
+- `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.
-
-Contraintes :
-
-- aucune reconnexion implicite au départ,
-- pas d’usage de `solana-pubsub-client`,
+- fermeture avec timeout,
 - tests offline avec serveur mock.
 
-## 6.3. Version `0.2.x` — Couche JSON-RPC WS Solana
+### 6.3. 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_app`,
+- boutons start/stop,
+- zone de logs,
+- validation du flux `frontend -> tauri -> kb_lib -> frontend`.
+
+### 6.4. Version `0.2.0` — Couche JSON-RPC WS Solana
 
 Objectif : séparer clairement transport, réponses RPC et notifications.
 
-À faire :
+Réalisé :
 
 - enveloppes JSON-RPC 2.0,
 - gestion des `request_id`,
-- registre des requêtes en attente,
-- distinction entre requêtes standard et subscribe/unsubscribe,
-- parsing des réponses,
-- séparation stricte des notifications.
+- parsing des réponses et erreurs,
+- parsing des notifications,
+- premiers helpers JSON-RPC sur `WsClient`.
 
-Livrables :
-
-- registre `request_id -> pending kind`,
-- registre `subscription_id -> metadata`,
-- tests de corrélation et de séparation des flux.
-
-## 6.4. Version `0.3.x` — Registre subscriptions / notifications
+### 6.5. Version `0.3.0` — Registre subscriptions / notifications
 
 Objectif : fiabiliser la gestion des subscriptions.
 
-À faire :
+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 même si le serveur ne répond pas,
+- purge locale si nécessaire,
 - routage séparé des notifications.
 
-## 6.5. Version `0.4.x` — Transport HTTP générique
+### 6.6. 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.7. 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.8. 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.9. Version `0.3.4` — Fenêtre `Demo Ws` dans `kb_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.10. 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.
+
+À faire :
+
+- 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.11. Version `0.4.x` — Transport HTTP générique
 
 Objectif : construire un `HttpClient` clonable et limité.
 
@@ -226,15 +276,11 @@ Objectif : construire un `HttpClient` clonable et limité.
 - burst configurable,
 - délais configurables,
 - profils par endpoint,
-- endpoints publics ou API-key.
-
-Livrables :
-
-- `HttpClient`,
+- endpoints publics ou API-key,
 - abstraction de requêtes JSON-RPC HTTP,
 - premiers appels sur endpoints Solana.
 
-## 6.6. Version `0.5.x` — Base de données SQLite
+### 6.12. Version `0.5.x` — Base de données SQLite
 
 Objectif : poser la persistance locale.
 
@@ -245,7 +291,7 @@ Objectif : poser la persistance locale.
 - premières tables techniques,
 - stockage des endpoints, événements, tokens observés, subscriptions actives si utile.
 
-## 6.7. Version `0.6.x` — Détection technique on-chain / RPC
+### 6.13. Version `0.6.x` — Détection technique on-chain / RPC
 
 Objectif : commencer la détection utile pour l’application.
 
@@ -256,7 +302,7 @@ Objectif : commencer la détection utile pour l’application.
 - débuts de normalisation d’événements,
 - premiers connecteurs DEX.
 
-## 6.8. Version `0.7.x` — DEX connectors v1
+### 6.14. Version `0.7.x` — DEX connectors v1
 
 Objectif : structurer les connecteurs par protocole.
 
@@ -276,7 +322,7 @@ Cibles initiales possibles :
 - création de types métiers propres,
 - enrichissement des métadonnées token/pool/pair.
 
-## 6.9. Version `0.8.x` — Analyse et filtrage
+### 6.15. Version `0.8.x` — Analyse et filtrage
 
 Objectif : transformer les événements bruts en signaux exploitables.
 
@@ -288,7 +334,7 @@ Objectif : transformer les événements bruts en signaux exploitables.
 - statistiques de comportement,
 - premiers patterns.
 
-## 6.10. Version `1.x.y` — Wallets et swap préparatoire
+### 6.16. Version `1.x.y` — Wallets et swap préparatoire
 
 Objectif : préparer la couche d’action.
 
@@ -300,7 +346,7 @@ Objectif : préparer la couche d’action.
 - préparation d’ordres et de swaps,
 - simulation et garde-fous.
 
-## 6.11. Version `2.x.y` — Trading semi-automatisé
+### 6.17. Version `2.x.y` — Trading semi-automatisé
 
 Objectif : brancher l’analyse à l’action tout en gardant des garde-fous explicites.
 
@@ -312,7 +358,7 @@ Objectif : brancher l’analyse à l’action tout en gardant des garde-fous exp
 - confirmations explicites ou semi-automatiques,
 - journaux d’exécution.
 
-## 6.12. Version `3.x.y` — Yellowstone gRPC
+### 6.18. Version `3.x.y` — Yellowstone gRPC
 
 Objectif : ajouter le connecteur gRPC dédié.
 
@@ -325,7 +371,7 @@ Objectif : ajouter le connecteur gRPC dédié.
 
 ## 7. Organisation des modules ciblés
 
-## 7.1. `kb_lib`
+### 7.1. `kb_lib`
 
 Modules cibles à court terme :
 
@@ -338,8 +384,9 @@ Modules cibles à court terme :
 - `http_client.rs`
 - `rpc_json.rs`
 - `rpc_ws.rs`
+- `rpc_ws_solana.rs`
 
-## 7.2. `kb_app`
+### 7.2. `kb_app`
 
 Responsabilités cibles :
 
@@ -347,7 +394,8 @@ Responsabilités cibles :
 - commandes UI,
 - affichage des états et messages,
 - réception des événements venant de `kb_lib`,
-- persistance future des préférences UI.
+- persistance future des préférences UI,
+- fenêtres de démonstration / diagnostic isolées.
 
 ## 8. Ligne de conduite sur le `WsClient`
 
@@ -393,7 +441,8 @@ Plus tard, ce comportement pourra devenir configurable dans `config.json` et pil
 Le projet doit maintenir au minimum :
 
 - un `README.md` global,
-- un `Roadmap.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.
@@ -402,11 +451,8 @@ Le projet doit maintenir au minimum :
 
 La priorité immédiate est la suivante :
 
-1. corriger le squelette,
-2. poser `KbError`,
-3. poser `KbConfig`,
-4. poser `init_tracing`,
-5. poser les constantes Solana,
-6. préparer `ws_client` et `http_client`,
-7. remettre `kb_app` en conformité,
-8. conserver une UI minimale, puis brancher progressivement les clients réseau.
+1. stabiliser `Demo Ws`,
+2. corriger la lecture/exposition des endpoints activés depuis la config,
+3. améliorer la robustesse de l’UI sous fort débit,
+4. préparer ensuite le transport HTTP générique,
+5. poursuivre la structuration des connecteurs DEX.