0.6.0

ROADMAP.md

@@ -383,17 +383,27 @@ Objectif : stabiliser le schéma avant la détection technique réelle.
 - durcir les relations, contraintes et index utiles,
 - préparer une future compatibilité PostgreSQL sans casser l’organisation générale.
 
-### 6.25. Version `0.6.x` — Détection technique on-chain / RPC
-Objectif : commencer la détection utile pour l’application.
+### 6.25. Version `0.6.0` — Pipeline de détection technique
+Objectif : relier les connecteurs RPC à la couche de stockage technique et métier.
 
 À faire :
 
-- réception de notifications ciblées,
-- détection de créations de comptes/programmes d’intérêt,
-- débuts de normalisation d’événements,
-- premiers connecteurs DEX.
+- ajouter une façade de persistance pour les observations et signaux issus des connecteurs,
+- préparer l’enregistrement des candidats tokens détectés depuis les sources RPC,
+- éviter que les futurs watchers RPC écrivent directement dans la DB sans couche intermédiaire,
+- préparer les prochaines étapes de détection technique on-chain / RPC.
 
-### 6.26. Version `0.7.x` — DEX connectors v1
+### 6.26. Version `0.6.1` — Détection technique RPC
+Objectif : brancher les premiers watchers et règles techniques sur la façade de détection.
+
+À faire :
+
+- relier les notifications WS / RPC au pipeline de détection,
+- produire des observations on-chain normalisées,
+- générer les premiers signaux techniques exploitables,
+- préparer la découverte effective des tokens et pools avant les connecteurs DEX dédiés.
+
+### 6.27. Version `0.7.x` — DEX connectors v1
 Objectif : structurer les connecteurs par protocole.
 
 Cibles initiales possibles :
@@ -412,7 +422,7 @@ Cibles initiales possibles :
 - création de types métiers propres,
 - enrichissement des métadonnées token/pool/pair.
 
-### 6.27. Version `0.8.x` — Analyse et filtrage
+### 6.28. Version `0.8.x` — Analyse et filtrage
 Objectif : transformer les événements bruts en signaux exploitables.
 
 À faire :
@@ -423,7 +433,7 @@ Objectif : transformer les événements bruts en signaux exploitables.
 - statistiques de comportement,
 - premiers patterns.
 
-### 6.28. Version `1.x.y` — Wallets et swap préparatoire
+### 6.29. Version `1.x.y` — Wallets et swap préparatoire
 Objectif : préparer la couche d’action.
 
 À faire :
@@ -434,7 +444,7 @@ Objectif : préparer la couche d’action.
 - préparation d’ordres et de swaps,
 - simulation et garde-fous.
 
-### 6.29. Version `2.x.y` — Trading semi-automatisé
+### 6.30. Version `2.x.y` — Trading semi-automatisé
 Objectif : brancher l’analyse à l’action tout en gardant des garde-fous explicites.
 
 À faire :
@@ -445,7 +455,7 @@ Objectif : brancher l’analyse à l’action tout en gardant des garde-fous exp
 - confirmations explicites ou semi-automatiques,
 - journaux d’exécution.
 
-### 6.30. Version `3.x.y` — Yellowstone gRPC
+### 6.31. Version `3.x.y` — Yellowstone gRPC
 Objectif : ajouter le connecteur gRPC dédié.
 
 À faire :
@@ -530,9 +540,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.5.4` avec le modèle métier normalisé initial,
-2. poser les tables de référence pour les DEX, tokens, pools, paires et listings,
-3. séparer clairement les objets métier des observations techniques brutes,
-4. préparer les relations nécessaires avant la détection technique `0.6.x`,
-5. conserver l’abstraction du backend dès cette phase SQLite,
-6. reporter la couche analytique agrégée après la fin de `0.6.x`.
+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.