Roadmap update
This commit is contained in:
52
ROADMAP.md
52
ROADMAP.md
@@ -401,7 +401,37 @@ Réalisé :
|
||||
- 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.27. Version `0.7.x` — DEX connectors v1
|
||||
### 6.27. Version `0.6.2` — Branchement `WsClient` vers la détection
|
||||
Objectif : relier directement les notifications WS issues de `WsClient` au pipeline de détection.
|
||||
|
||||
À faire :
|
||||
|
||||
- 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.28. Version `0.6.3` — Enrichissement des notifications WS utiles
|
||||
Objectif : améliorer la couverture technique des notifications WS.
|
||||
|
||||
À faire :
|
||||
|
||||
- enrichir `accountNotification`, `logsNotification`, `signatureNotification`,
|
||||
- mieux extraire slot, pubkey, signature, owner, parsed account type,
|
||||
- produire des observations plus précises et plus homogènes,
|
||||
- préparer les règles de détection techniques réelles.
|
||||
|
||||
### 6.29. Version `0.6.4` — Premières règles de détection technique
|
||||
Objectif : commencer la détection technique on-chain utile avant les connecteurs DEX dédiés.
|
||||
|
||||
À faire :
|
||||
|
||||
- détecter les premiers candidats pools / listings techniques,
|
||||
- commencer à distinguer signaux de mint, apparition de pool et activité anormale,
|
||||
- préparer l’alimentation des tables métier normalisées,
|
||||
- garder la logique encore indépendante des connecteurs DEX `0.7.x`.
|
||||
|
||||
### 6.30. Version `0.7.x` — DEX connectors v1
|
||||
Objectif : structurer les connecteurs par protocole.
|
||||
|
||||
Cibles initiales possibles :
|
||||
@@ -420,7 +450,7 @@ Cibles initiales possibles :
|
||||
- création de types métiers propres,
|
||||
- enrichissement des métadonnées token/pool/pair.
|
||||
|
||||
### 6.28. Version `0.8.x` — Analyse et filtrage
|
||||
### 6.31. Version `0.8.x` — Analyse et filtrage
|
||||
Objectif : transformer les événements bruts en signaux exploitables.
|
||||
|
||||
À faire :
|
||||
@@ -431,7 +461,7 @@ Objectif : transformer les événements bruts en signaux exploitables.
|
||||
- statistiques de comportement,
|
||||
- premiers patterns.
|
||||
|
||||
### 6.29. Version `1.x.y` — Wallets et swap préparatoire
|
||||
### 6.32. Version `1.x.y` — Wallets et swap préparatoire
|
||||
Objectif : préparer la couche d’action.
|
||||
|
||||
À faire :
|
||||
@@ -442,7 +472,7 @@ Objectif : préparer la couche d’action.
|
||||
- préparation d’ordres et de swaps,
|
||||
- simulation et garde-fous.
|
||||
|
||||
### 6.30. Version `2.x.y` — Trading semi-automatisé
|
||||
### 6.33. Version `2.x.y` — Trading semi-automatisé
|
||||
Objectif : brancher l’analyse à l’action tout en gardant des garde-fous explicites.
|
||||
|
||||
À faire :
|
||||
@@ -453,7 +483,7 @@ Objectif : brancher l’analyse à l’action tout en gardant des garde-fous exp
|
||||
- confirmations explicites ou semi-automatiques,
|
||||
- journaux d’exécution.
|
||||
|
||||
### 6.31. Version `3.x.y` — Yellowstone gRPC
|
||||
### 6.34. Version `3.x.y` — Yellowstone gRPC
|
||||
Objectif : ajouter le connecteur gRPC dédié.
|
||||
|
||||
À faire :
|
||||
@@ -538,9 +568,9 @@ 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.0` avec le pipeline de détection technique,
|
||||
2. ajouter une façade unique entre les connecteurs RPC et la base de données,
|
||||
3. préparer l’enregistrement des observations on-chain, des signaux et des candidats tokens,
|
||||
4. éviter que les watchers futurs accèdent directement à la DB sans couche intermédiaire,
|
||||
5. conserver l’abstraction du backend et la séparation entre stockage brut et modèle métier,
|
||||
6. préparer ensuite la version `0.6.1` pour brancher les premières règles de détection technique RPC.
|
||||
1. démarrer la version `0.6.2` avec le branchement `WsClient` vers la détection,
|
||||
2. ajouter un relais asynchrone entre notifications WS et worker de détection,
|
||||
3. éviter de bloquer la boucle de lecture du client WS,
|
||||
4. préparer ensuite la version `0.6.3` pour enrichir les notifications WS utiles,
|
||||
5. conserver le découplage entre transport, détection et stockage,
|
||||
6. préparer enfin `0.6.4` pour les premières règles de détection technique.
|
||||
|
||||
Reference in New Issue
Block a user