Sasedev/khadhroony-bobobot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.5.2

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-04-23 17:18:15 +02:00
parent 3b8e029cde
commit 6d00c0ddf4
14 changed files with 545 additions and 65 deletions
Download Patch File Download Diff File Expand all files Collapse all files

96
ROADMAP.md
View File

@@ -141,7 +141,6 @@ Le tracing est centralisé dans `kb_lib`.
## 6. Phasage par versions
### 6.1. Version `0.0.2` — Socle conforme
Objectif : corriger le squelette et poser la base de travail.
Réalisé :
@@ -157,7 +156,6 @@ Réalisé :
- UI Tauri minimale.
### 6.2. Version `0.1.x` — Transport WebSocket générique
Objectif : construire un vrai `WsClient` asynchrone clonable.
Réalisé :
@@ -172,7 +170,6 @@ Réalisé :
- tests offline avec serveur mock.
### 6.3. Version `0.1.1` — Intégration Tauri minimale du `WsClient`
Objectif : valider le transport via l’application desktop.
Réalisé :
@@ -183,7 +180,6 @@ Réalisé :
- 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.
Réalisé :
@@ -195,7 +191,6 @@ Réalisé :
- premiers helpers JSON-RPC sur `WsClient`.
### 6.5. Version `0.3.0` — Registre subscriptions / notifications
Objectif : fiabiliser la gestion des subscriptions.
Réalisé :
@@ -208,7 +203,6 @@ Réalisé :
- routage séparé des notifications.
### 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é :
@@ -218,7 +212,6 @@ Réalisé :
- 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é :
@@ -228,7 +221,6 @@ Réalisé :
- 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é :
@@ -238,7 +230,6 @@ Réalisé :
- 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é :
@@ -251,7 +242,6 @@ Réalisé :
- 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.
Réalisé :
@@ -269,8 +259,7 @@ Réalisé :
Objectif : construire un `HttpClient` clonable, limité et extensible, puis ajouter les premiers helpers HTTP Solana.
### 0.4.0 — Socle `HttpClient`
### 6.12. Version `0.4.0` — Socle `HttpClient`
Réalisé :
- client `reqwest` asynchrone clonable,
@@ -291,8 +280,7 @@ Livrables :
- `getVersion`
- `getSlot`
### 0.4.1 — Helpers HTTP Solana
### 6.13. Version `0.4.1` — Helpers HTTP Solana
Réalisé :
- ajouter des helpers HTTP haut niveau comme pour le client WS,
@@ -300,8 +288,7 @@ Réalisé :
- couvrir les premières méthodes utiles du RPC HTTP Solana,
- conserver `HttpClient` comme couche générique réutilisable.
### 0.4.2 — Politique HTTP avancée
### 6.14. Version `0.4.2` — Politique HTTP avancée
Réalisé :
- préparer un état de pause avant envoi pour un endpoint HTTP,
@@ -309,8 +296,7 @@ Réalisé :
- distinguer quota RPC général et quota `sendTransaction`,
- préparer un futur pool d’endpoints HTTP et l’arbitrage entre eux.
### 0.4.3 — Pool d’endpoints HTTP
### 6.15. Version `0.4.3` — Pool d’endpoints HTTP
Réalisé :
- ajouter un pool d’`HttpClient`,
@@ -320,8 +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.
### 0.4.4 — Démo HTTP dans `kb_app`
### 6.16. Version `0.4.4` — Démo HTTP dans `kb_app`
Réalisé :
- ajout d’une fenêtre `Demo Http`,
@@ -332,11 +317,10 @@ Réalisé :
- 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.12. Version `0.5.x` — Base de données SQLite
### 6.17. 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.
#### 0.5.0 — Socle SQLite
### 6.18. Version `0.5.0` — Socle SQLite
Réalisé :
- configuration DB dans `config.json`,
@@ -346,29 +330,32 @@ Réalisé :
- table `kb_db_metadata`,
- séparation `db/entities`, `db/dtos`, `db/queries`, `db/types`.
#### 0.5.1 — Premières tables métier de stockage local
À faire :
### 6.19. Version `0.5.1` — Premières tables métier de stockage local
Réalisé :
- ajouter les tables de référence pour les endpoints connus,
- ajouter les tables techniques pour les événements runtime locaux,
- poser les `entities`, `dtos`, `queries` et `types` associés,
- préparer le stockage local des endpoints HTTP/WS connus et de leur état utile.
- 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.
#### 0.5.2 — Stockage des tokens observés
À faire :
### 6.20. Version `0.5.2` — Stockage des tokens observés
Réalisé :
- ajouter les premières tables liées aux tokens observés,
- préparer le stockage minimal des mints, symboles, statuts et dates de découverte,
- préparer les relations futures avec pools, paires et événements on-chain.
- ajout de la table `kb_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.
#### 0.5.3 — Événements et signaux locaux
### 6.21. Version `0.5.3` — Événements et signaux locaux
À faire :
- stocker les événements techniques importants remontés par les connecteurs,
- préparer la conservation locale des signaux utiles à l’analyse,
- distinguer événements runtime, observations on-chain et événements métier.
- distinguer événements runtime, observations on-chain et événements métier,
- préparer la traçabilité de provenance si plusieurs sources détectent un même objet, sans remettre en cause l’unicité locale d’un token par mint.
#### 0.5.x — Consolidation de la couche stockage
### 6.22. Version `0.5.x` — Consolidation de la couche stockage
À faire :
- conserver l’abstraction du backend dès le départ,
@@ -376,8 +363,7 @@ Réalisé :
- garder les conversions explicites entre entités DB et DTOs applicatifs,
- préparer une future compatibilité PostgreSQL sans casser l’organisation générale.
### 6.13. Version `0.6.x` — Détection technique on-chain / RPC
### 6.23. Version `0.6.x` — Détection technique on-chain / RPC
Objectif : commencer la détection utile pour l’application.
À faire :
@@ -387,8 +373,7 @@ Objectif : commencer la détection utile pour l’application.
- débuts de normalisation d’événements,
- premiers connecteurs DEX.
### 6.14. Version `0.7.x` — DEX connectors v1
### 6.24. Version `0.7.x` — DEX connectors v1
Objectif : structurer les connecteurs par protocole.
Cibles initiales possibles :
@@ -407,8 +392,7 @@ Cibles initiales possibles :
- création de types métiers propres,
- enrichissement des métadonnées token/pool/pair.
### 6.15. Version `0.8.x` — Analyse et filtrage
### 6.25. Version `0.8.x` — Analyse et filtrage
Objectif : transformer les événements bruts en signaux exploitables.
À faire :
@@ -419,8 +403,7 @@ Objectif : transformer les événements bruts en signaux exploitables.
- statistiques de comportement,
- premiers patterns.
### 6.16. Version `1.x.y` — Wallets et swap préparatoire
### 6.26. Version `1.x.y` — Wallets et swap préparatoire
Objectif : préparer la couche d’action.
À faire :
@@ -431,8 +414,7 @@ Objectif : préparer la couche d’action.
- préparation d’ordres et de swaps,
- simulation et garde-fous.
### 6.17. Version `2.x.y` — Trading semi-automatisé
### 6.27. Version `2.x.y` — Trading semi-automatisé
Objectif : brancher l’analyse à l’action tout en gardant des garde-fous explicites.
À faire :
@@ -443,8 +425,7 @@ Objectif : brancher l’analyse à l’action tout en gardant des garde-fous exp
- confirmations explicites ou semi-automatiques,
- journaux d’exécution.
### 6.18. Version `3.x.y` — Yellowstone gRPC
### 6.28. Version `3.x.y` — Yellowstone gRPC
Objectif : ajouter le connecteur gRPC dédié.
À faire :
@@ -457,7 +438,6 @@ Objectif : ajouter le connecteur gRPC dédié.
## 7. Organisation des modules ciblés
### 7.1. `kb_lib`
Modules cibles à court terme :
- `error.rs`
@@ -472,7 +452,6 @@ Modules cibles à court terme :
- `rpc_ws_solana.rs`
### 7.2. `kb_app`
Responsabilités cibles :
- lancement Tauri,
@@ -483,7 +462,6 @@ Responsabilités cibles :
- fenêtres de démonstration / diagnostic isolées.
## 8. Ligne de conduite sur le `WsClient`
Le `WsClient` doit être conçu en plusieurs couches :
1. transport brut WebSocket,
@@ -500,7 +478,6 @@ Cette séparation évite de mélanger :
- les notifications push.
## 9. Politique initiale de reconnexion
Au départ :
- pas de reconnexion automatique,
@@ -510,7 +487,6 @@ Au départ :
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,
@@ -522,7 +498,6 @@ Plus tard, ce comportement pourra devenir configurable dans `config.json` et pil
7. journaliser clairement les cas dégradés.
## 11. Documentation et livrables de référence
Le projet doit maintenir au minimum :
- un `README.md` global,
@@ -533,12 +508,11 @@ Le projet doit maintenir au minimum :
- 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. démarrer la version `0.5.1` avec les premières tables métier SQLite,
2. ajouter les tables locales pour les endpoints connus HTTP/WS,
3. ajouter les tables locales pour les événements runtime techniques,
4. structurer ces tables via `db/entities`, `db/dtos`, `db/queries` et `db/types`,
1. démarrer la version `0.5.3` avec les événements et signaux locaux,
2. stocker les événements techniques importants remontés par les connecteurs,
3. distinguer clairement événements runtime, observations on-chain et événements métier,
4. préparer la conservation locale des signaux utiles à l’analyse,
5. conserver l’abstraction du backend dès cette phase SQLite,
6. préparer ensuite le stockage des tokens observés et des premiers signaux persistés.
6. préparer ensuite l’exploitation de ces signaux pour la future détection technique on-chain / RPC.