0.5.3

ROADMAP.md

@@ -348,22 +348,46 @@ Réalisé :
 - conservation d’unicité locale par mint sans duplication par endpoint.
 
 ### 6.21. Version `0.5.3` — Événements et signaux locaux
+Réalisé :
+
+- conservation des événements runtime techniques via `kb_db_runtime_events`,
+- ajout des observations on-chain brutes via `kb_onchain_observations`,
+- ajout des signaux d’analyse via `kb_analysis_signals`,
+- distinction explicite entre événements runtime, observations on-chain et événements métier,
+- préparation de la traçabilité de provenance par type de source et endpoint, sans remettre en cause l’unicité locale d’un token par mint.
+
+### 6.22. Version `0.5.4` — Modèle métier normalisé initial
+Objectif : poser la couche relationnelle métier entre les observations brutes et la future détection technique.
+
 À 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,
-- 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.
+- ajouter les tables de référence métier pour les DEX, tokens, pools et paires,
+- distinguer clairement objets de référence et événements d’activité,
+- préparer les relations entre tokens, pools, paires et listings,
+- éviter que la détection technique `0.6.x` écrive directement dans des tables trop brutes ou ambiguës.
+
+### 6.23. Version `0.5.5` — Activité métier normalisée
+Objectif : poser les premiers événements métier exploitables.
+
+À faire :
+
+- ajouter les tables de swaps,
+- ajouter les événements de liquidité,
+- ajouter les événements de mint et burn utiles au suivi des tokens,
+- préparer l’historique métier nécessaire avant l’arrivée des connecteurs DEX complets.
+
+### 6.24. Version `0.5.6` — Consolidation de la couche stockage
+Objectif : stabiliser le schéma avant la détection technique réelle.
 
-### 6.22. Version `0.5.x` — Consolidation de la couche stockage
 À faire :
 
 - conserver l’abstraction du backend dès le départ,
 - limiter la dépendance directe au SQL concret aux modules `queries`,
 - garder les conversions explicites entre entités DB et DTOs applicatifs,
+- durcir les relations, contraintes et index utiles,
 - préparer une future compatibilité PostgreSQL sans casser l’organisation générale.
 
-### 6.23. Version `0.6.x` — Détection technique on-chain / RPC
+### 6.25. Version `0.6.x` — Détection technique on-chain / RPC
 Objectif : commencer la détection utile pour l’application.
 
 À faire :
@@ -373,7 +397,7 @@ Objectif : commencer la détection utile pour l’application.
 - débuts de normalisation d’événements,
 - premiers connecteurs DEX.
 
-### 6.24. Version `0.7.x` — DEX connectors v1
+### 6.26. Version `0.7.x` — DEX connectors v1
 Objectif : structurer les connecteurs par protocole.
 
 Cibles initiales possibles :
@@ -392,7 +416,7 @@ Cibles initiales possibles :
 - création de types métiers propres,
 - enrichissement des métadonnées token/pool/pair.
 
-### 6.25. Version `0.8.x` — Analyse et filtrage
+### 6.27. Version `0.8.x` — Analyse et filtrage
 Objectif : transformer les événements bruts en signaux exploitables.
 
 À faire :
@@ -403,7 +427,7 @@ Objectif : transformer les événements bruts en signaux exploitables.
 - statistiques de comportement,
 - premiers patterns.
 
-### 6.26. Version `1.x.y` — Wallets et swap préparatoire
+### 6.28. Version `1.x.y` — Wallets et swap préparatoire
 Objectif : préparer la couche d’action.
 
 À faire :
@@ -414,7 +438,7 @@ Objectif : préparer la couche d’action.
 - préparation d’ordres et de swaps,
 - simulation et garde-fous.
 
-### 6.27. Version `2.x.y` — Trading semi-automatisé
+### 6.29. Version `2.x.y` — Trading semi-automatisé
 Objectif : brancher l’analyse à l’action tout en gardant des garde-fous explicites.
 
 À faire :
@@ -425,7 +449,7 @@ Objectif : brancher l’analyse à l’action tout en gardant des garde-fous exp
 - confirmations explicites ou semi-automatiques,
 - journaux d’exécution.
 
-### 6.28. Version `3.x.y` — Yellowstone gRPC
+### 6.30. Version `3.x.y` — Yellowstone gRPC
 Objectif : ajouter le connecteur gRPC dédié.
 
 À faire :
@@ -510,9 +534,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.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,
+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. préparer ensuite l’exploitation de ces signaux pour la future détection technique on-chain / RPC.
+6. reporter la couche analytique agrégée après la fin de `0.6.x`.