0.7.24

ROADMAP.md

@@ -695,7 +695,49 @@ Réalisé :
 - prise en charge des candles matérialisées et des candles régénérées à la demande pour un timeframe custom,
 - intégration du rendu graphique directement dans `Demo Pipeline`.
 
-### 6.057. Version `0.7.25` — `kb_app` : overlays analytiques
+### 6.057. Version `0.7.25` — Enrichissement metadata des tokens
+Objectif : rendre le catalogue local lisible et exploitable en associant les mints à des métadonnées minimales fiables.
+
+À faire :
+
+- ajouter une couche `token_metadata` dans `kb_lib`, distincte du décodage DEX et de l’UI,
+- enrichir `kb_tokens` avec `symbol`, `name`, `decimals`, `metadata_uri`, `metadata_source`, `metadata_status` et `metadata_updated_at` lorsque le schéma le permet,
+- ajouter une résolution locale des mints connus (`SOL`, `USDC`, `USDT`, `RAY`, `JitoSOL` et autres références stables),
+- réutiliser les payloads déjà décodés des événements `pump_fun.create` / `pump_fun.create_v2_token` pour alimenter `name`, `symbol`, `uri` et `creator`,
+- ajouter une résolution Metaplex Token Metadata PDA pour les tokens SPL classiques,
+- ajouter une résolution Token-2022 via metadata pointer / extensions lorsque le mint utilise ce standard,
+- stocker explicitement les cas non résolus afin d’éviter les tentatives répétées inutiles,
+- exposer une commande UI ou un service de backfill permettant d’enrichir les tokens déjà présents en base,
+- maintenir une politique de priorité claire entre sources : `known_mint`, `pump_fun_create`, `metaplex`, `token_2022`, puis `unresolved`.
+
+### 6.058. Version `0.7.26` — Validation multi-DEX et non-régression du pipeline
+Objectif : vérifier que les connecteurs déjà branchés restent cohérents avant d’ouvrir la phase d’analyse `0.8.x`.
+
+À faire :
+
+- rejouer des bases neuves de test pour `pump_fun`, `pump_swap`, `raydium_cpmm` et `raydium_clmm`,
+- vérifier pour chaque DEX le triptyque `decoded_event_count / trade_event_count / pair_candle_count`,
+- garantir que les événements non pricés ou non candle ne produisent pas de trade event invalide,
+- conserver l’enrichissement `eventCategory`, `tradeCandidate`, `candleCandidate`, `liquidityCandidate`, `feeCandidate`, `rewardCandidate`, `adminCandidate` et `poolLifecycleCandidate` dans `payload_json`,
+- documenter les familles d’événements utilisées pour les candles et celles conservées seulement pour l’analyse ou la traçabilité,
+- ajouter ou compléter les tests unitaires sur `dex_decode`, `dex_detect`, `trade_aggregation`, `pair_candle_aggregation` et `pair_analytic_signal`,
+- ajouter des requêtes SQL de diagnostic de référence pour contrôler rapidement les tables clés après backfill,
+- conserver la tolérance aux événements DEX partiels tout en refusant les trades sans montant ou prix exploitable.
+
+### 6.059. Version `0.7.27` — Raydium AMM v4 legacy : corpus et validation ciblée
+Objectif : isoler correctement le vrai Raydium AMM v4 historique et le distinguer de `raydium_cpmm` et `raydium_clmm`.
+
+À faire :
+
+- rechercher des pools réellement rattachés au programme `675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8`,
+- constituer un petit corpus local de signatures/pools AMM v4 fiables pour les tests,
+- vérifier que les adresses issues de Dexscreener ou d’autres explorateurs ne sont pas seulement catégorisées globalement comme `Raydium`,
+- ajouter des requêtes de diagnostic par `program_id`, `accounts_json` et préfixe `data_json`,
+- valider la prise en charge `initialize2` et identifier les instructions de swap AMM v4 à supporter si elles apparaissent dans les transactions testées,
+- renommer et stabiliser les fonctions internes autour de `raydium_amm_v4` afin d’éviter l’ambiguïté avec `raydium_cpmm` et `raydium_clmm`,
+- documenter les limites connues si le corpus AMM v4 reste trop faible.
+
+### 6.060. Version `0.7.28` — `kb_app` : overlays analytiques
 Objectif : rendre visibles les signaux analytiques directement sur les graphes et vues de marché.
 
 À faire :
@@ -703,20 +745,22 @@ Objectif : rendre visibles les signaux analytiques directement sur les graphes e
 - afficher les signaux analytiques par bucket au-dessus ou autour des candles,
 - ajouter des marqueurs pour `first_trade_seen`, `trade_burst_60s`, `buy_sell_imbalance_60s`, `price_jump_up_60s`, `price_jump_down_60s` et `volume_spike_60s`,
 - permettre le filtrage par type de signal et par sévérité,
-- afficher un panneau latéral listant les signaux liés à une paire et à un timeframe.
+- afficher un panneau latéral listant les signaux liés à une paire et à un timeframe,
+- préparer l’extension future vers des indicateurs Ichimoku, Kumo, projections ABCD et égalités temps/prix sans les mélanger au pipeline de décodage DEX.
 
-### 6.058. Version `0.7.26` — `kb_app` : vues consolidées token / pair / pool
+### 6.061. Version `0.7.29` — `kb_app` : vues consolidées token / pair / pool
 Objectif : fournir une lecture métier plus confortable du modèle `0.7.x`.
 
 À faire :
 
-- ajouter une fiche token,
-- ajouter une fiche paire,
-- ajouter une fiche pool,
+- ajouter une fiche token avec mint, programme token, metadata, pools, paires et historique de découverte,
+- ajouter une fiche paire avec base/quote, DEX, pool, métriques, candles, signaux et derniers trades,
+- ajouter une fiche pool avec composition, vaults, origine, première signature vue, programme DEX et statut de décodage,
 - relier dans l’UI les launch origins, pool origins, wallets observés, holdings observés, candles et analytic signals,
-- préparer une navigation transversale entre objets techniques et objets métier.
+- préparer une navigation transversale entre objets techniques et objets métier,
+- rendre explicites les cas `tradeCount = null`, `lastPriceQuotePerBase = null` et tokens non enrichis.
 
-### 6.059. Version `0.7.27` — Finition UI `0.7.x`
+### 6.062. Version `0.7.30` — Finition UI `0.7.x`
 Objectif : stabiliser la couche desktop de validation avant l’ouverture de `0.8.x`.
 
 À faire :
@@ -724,9 +768,10 @@ Objectif : stabiliser la couche desktop de validation avant l’ouverture de `0.
 - consolider les vues ajoutées dans `kb_app`,
 - améliorer la navigation, les filtres et la pagination,
 - ajouter les derniers raffinements de confort et de lisibilité,
-- préparer une base UI suffisamment stable pour la future phase d’analyse et filtrage `0.8.x`.
+- préparer une base UI suffisamment stable pour la future phase d’analyse et filtrage `0.8.x`,
+- vérifier que les commandes Tauri restent de simples façades vers `kb_lib` et ne récupèrent pas de logique métier.
 
-### 6.060. Version `0.7.x` — Couverture DEX v1
+### 6.063. Version `0.7.x` — Couverture DEX v1
 Objectif : structurer les connecteurs DEX autour d’un pipeline complet de résolution, décodage et normalisation métier.
 
 Protocoles cibles :
@@ -737,7 +782,9 @@ Protocoles cibles :
 - LaunchLab / Fun Launch
 - Pump.fun
 - PumpSwap
-- Raydium
+- Raydium AMM v4 legacy
+- Raydium CPMM
+- Raydium CLMM
 - Orca
 - Bags
 - FluxBeam
@@ -750,10 +797,12 @@ Résultat attendu :
 - résolution des signatures pertinentes,
 - décodage des transactions utiles,
 - création d’objets métier riches pour tokens, pools, paires, listings, participants et holdings observés,
+- enrichissement metadata des tokens découverts,
+- séparation claire entre événements candle/trade et événements utiles seulement à l’analyse, aux frais, à la liquidité, aux rewards ou à l’administration,
 - préparation d’une détection temps réel hybride et d’un backfill ciblé compatible avec les mêmes objets métier,
 - préparation d’agrégats DEX plus riches, de candles / OHLCV et d’une UI d’inspection du pipeline `0.7.x`.
 
-### 6.061. Version `0.8.x` — Analyse et filtrage
+### 6.064. Version `0.8.x` — Analyse et filtrage
 Objectif : transformer les événements bruts en signaux exploitables.
 
 À faire :
@@ -763,9 +812,12 @@ Objectif : transformer les événements bruts en signaux exploitables.
 - exclusions des tokens non tradables,
 - statistiques de comportement,
 - premiers patterns,
-- enrichissement des signaux analytiques préparés en fin de `0.7.x`.
+- enrichissement des signaux analytiques préparés en fin de `0.7.x`,
+- indicateurs graphiques optionnels comme Ichimoku / Kumo,
+- outils de sélection manuelle de points ABC et projection d’un point D selon des règles temps/prix explicites,
+- séparation stricte entre signaux analytiques observés, projections hypothétiques et décisions de trading.
 
-### 6.062. Version `1.x.y` — Wallets et swap préparatoire
+### 6.065. Version `1.x.y` — Wallets et swap préparatoire
 Objectif : préparer la couche d’action.
 
 À faire :
@@ -776,7 +828,7 @@ Objectif : préparer la couche d’action.
 - préparation d’ordres et de swaps,
 - simulation et garde-fous.
 
-### 6.063. Version `2.x.y` — Trading semi-automatisé
+### 6.066. Version `2.x.y` — Trading semi-automatisé
 Objectif : brancher l’analyse à l’action tout en gardant des garde-fous explicites.
 
 À faire :
@@ -787,7 +839,7 @@ Objectif : brancher l’analyse à l’action tout en gardant des garde-fous exp
 - confirmations explicites ou semi-automatiques,
 - journaux d’exécution.
 
-### 6.064. Version `3.x.y` — Yellowstone gRPC
+### 6.067. Version `3.x.y` — Yellowstone gRPC
 Objectif : ajouter le connecteur gRPC dédié.
 
 À faire :
@@ -814,6 +866,12 @@ Modules cibles à court terme :
 - `json_rpc_ws.rs`
 - `solana_pubsub_ws.rs`
 - `detect.rs`
+- `dex_decode.rs`
+- `dex_detect.rs`
+- `trade_aggregation.rs`
+- `pair_candle_aggregation.rs`
+- `pair_analytic_signal.rs`
+- `token_metadata.rs`
 
 ### 7.2. `kb_app`
 Responsabilités cibles :
@@ -875,10 +933,13 @@ Le projet doit maintenir au minimum :
 
 La priorité immédiate est désormais la suivante :
 
-1. poursuivre la fin de série `0.7.x` côté `kb_app` avant l’ouverture de `0.8.x`,
-2. ajouter un pilotage UI du backfill historique ciblé par `token_mint`,
-3. ajouter une vue graphique des candles / OHLCV avec `echarts`,
-4. ajouter les overlays des signaux analytiques sur les candles,
-5. consolider les vues métier `token / pair / pool` dans `kb_app`,
-6. stabiliser l’ergonomie, les filtres et la navigation de l’UI d’inspection,
-7. préparer enfin l’arrivée de Yellowstone gRPC comme extension de capacité, et non comme remplacement du socle existant.
+1. ajouter l’enrichissement metadata des tokens afin que le catalogue affiche au minimum les symboles/noms connus et les métadonnées résolues,
+2. rejouer une campagne de validation multi-DEX sur bases neuves pour `pump_fun`, `pump_swap`, `raydium_cpmm` et `raydium_clmm`,
+3. constituer un corpus ciblé pour `raydium_amm_v4` legacy au lieu de s’appuyer sur des labels Raydium trop génériques,
+4. conserver les événements non-candle enrichis en payload pour l’analyse future, sans créer de trades invalides,
+5. ajouter les overlays des signaux analytiques sur les candles,
+6. consolider les vues métier `token / pair / pool` dans `kb_app`,
+7. stabiliser l’ergonomie, les filtres et la navigation de l’UI d’inspection,
+8. préparer ensuite l’ouverture de `0.8.x` pour l’analyse, les filtres, les patterns et les projections graphiques,
+9. préparer enfin Yellowstone gRPC comme extension de capacité, et non comme remplacement du socle HTTP / WS existant.
+