0.7.38

ROADMAP.md

@@ -751,19 +751,17 @@ Réalisé :
 ### 6.059. Version `0.7.27` — Validation multi-DEX des connecteurs déjà branchés
 Objectif : verrouiller la non-régression du pipeline actuel avant d’ajouter de nouveaux DEX ou d’ouvrir la phase d’analyse `0.8.x`.
 
-À faire :
+Réalisé / validé :
 
-- rejouer des bases neuves de test pour `pump_fun`, `pump_swap`, `raydium_cpmm` et `raydium_clmm`,
-- ne pas ajouter de nouveau DEX dans cette version ; cette version sert uniquement à valider les connecteurs déjà branchés,
-- vérifier pour chaque DEX le triptyque `decoded_event_count / trade_event_count / pair_candle_count`,
-- vérifier que les compteurs `diagnosticsClean`, `blockingIssueCount`, `actionableMissingTradeEventCount`, `duplicateDecodedEventTradeCount` et `duplicateCandleBucketCount` restent cohérents après replay,
-- 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, la liquidité, les frais, les rewards, l’administration ou la traçabilité,
-- ajouter ou compléter les tests unitaires sur `dex_decode`, `dex_detect`, `trade_aggregation`, `pair_candle_aggregation`, `pair_analytic_signal`, `local_pipeline_replay` et `local_pipeline_diagnostics`,
-- ajouter des requêtes SQL de diagnostic de référence pour contrôler rapidement les tables clés après backfill ou replay local,
-- conserver la tolérance aux événements DEX partiels tout en refusant les trades sans montant ou prix exploitable,
-- valider que les transactions échouées restent traçables dans les événements décodés sans produire de `k_sol_trade_events`.
+- replay local et bases neuves de test utilisés pour stabiliser `pump_fun`, `pump_swap`, `raydium_cpmm` et `raydium_clmm` ;
+- aucun nouveau DEX ajouté dans cette étape : la version a bien servi de verrou de non-régression ;
+- vérification du triptyque `decoded_event_count / trade_event_count / pair_candle_count` par DEX ;
+- garde-fous maintenus sur `diagnosticsClean`, `blockingIssueCount`, `actionableMissingTradeEventCount`, `duplicateDecodedEventTradeCount` et `duplicateCandleBucketCount` ;
+- refus des trades sans montant ou prix exploitable ;
+- conservation des transactions échouées comme decoded events traçables sans produire de `k_sol_trade_events` ;
+- maintien des champs d’enrichissement dans `payload_json` : `eventCategory`, `tradeCandidate`, `candleCandidate`, `liquidityCandidate`, `feeCandidate`, `rewardCandidate`, `adminCandidate`, `poolLifecycleCandidate` ;
+- couverture testée dans les zones critiques : `dex_decode`, `dex_detect`, `trade_aggregation`, `pair_candle_aggregation`, `pair_analytic_signal`, `local_pipeline_replay`, `local_pipeline_diagnostics` ;
+- requêtes SQL de diagnostic conservées comme contrôle manuel après backfill ou replay local.
 
 ### 6.060. Version `0.7.28` — Refactor DEX commun et préparation extension
 Réalisé :
@@ -888,16 +886,17 @@ Réalisé :
 ### 6.067. Version `0.7.35` — Événements non-trade v2 : fees, rewards et administration
 Objectif : conserver les événements utiles au risque, au scoring, à l’économie du pool et à la traçabilité opérationnelle.
 
-À faire :
+Réalisé :
 
-- ajouter `k_sol_fee_events`,
-- ajouter `k_sol_reward_events`,
-- ajouter `k_sol_pool_admin_events`,
-- matérialiser les événements `collect_protocol_fee`, `collect_fund_fee`, `collect_creator_fee`, `collect_fee` et assimilés,
-- matérialiser les événements `set_reward_params`, `initialize_reward`, `collect_reward`, `update_reward_infos` et assimilés,
-- matérialiser les événements `set_config`, `update_config`, `set_authority`, `set_fee_rate`, `pause`, `resume` et assimilés,
-- rattacher ces événements aux transactions, decoded events, pools, paires et wallets observés lorsque les comptes le permettent,
-- documenter clairement que ces événements ne sont ni des trades ni des candles.
+- ajout des tables `k_sol_fee_events`, `k_sol_reward_events` et `k_sol_pool_admin_events` ;
+- ajout des DTO, entities, requêtes, index et re-exports associés ;
+- matérialisation contrôlée des événements fees/rewards/admin lorsque la classification et les comptes le permettent ;
+- rattachement aux transactions, decoded events, pools et paires lorsque les données disponibles sont fiables ;
+- raccordement aux diagnostics locaux via `feeEventCount`, `rewardEventCount` et `poolAdminEventCount` ;
+- ajout du profil `0.7.35_non_trade_fee_reward_admin` ;
+- invariant maintenu : aucun fee/reward/admin ne produit de trade, metric ou candle.
+
+Limite connue : le corpus local `0.7.38` ne contient pas encore d’événements fee/reward/admin matérialisés ; les compteurs peuvent donc rester à zéro sans bloquer la validation.
 
 ### 6.068. Version `0.7.36` — Meteora : DBC / DAMM v1 / DAMM v2 / DLMM
 Réalisé :
@@ -915,26 +914,37 @@ Réalisé :
 ### 6.069. Version `0.7.37` — Token metadata et catalogue local
 Objectif : rendre le catalogue local exploitable et lisible avant d’ajouter davantage de launch surfaces.
 
-Réalisé en `0.7.37-A` :
+Réalisé :
 
 - ajout du profil `0.7.37_token_metadata_catalog_enrichment` ;
-- exposition des compteurs metadata/catalog dans les diagnostics et le rapport de validation ;
-- raccordement UI Demo Pipeline 2 au profil `0.7.37` ;
-- maintien volontaire du caractère non bloquant des metadata manquantes.
+- exposition des compteurs metadata/catalog dans les diagnostics et le rapport de validation : `tokenCount`, `tokenMetadataMissingCount`, `tradableTokenMetadataMissingCount`, `quoteTokenMetadataMissingCount`, `pairSymbolFallbackCount`, `pairSymbolResolvedCount`, `wsolQuotePairCount`, `stableQuotePairCount` ;
+- raccordement UI Demo Pipeline 2 au profil `0.7.37` puis au profil `0.7.38` ;
+- maintien volontaire du caractère non bloquant des metadata manquantes ;
+- backfill metadata des tokens déjà présents dans `k_sol_tokens` sans nécessiter un nouveau backfill transactionnel ;
+- enrichissement depuis les sources disponibles : registre local, payloads Pump.fun, comptes SPL/Token-2022, Metaplex lorsque le service dispose d’un `HttpEndpointPool` ;
+- rafraîchissement des `pair_symbol` après enrichissement des tokens ;
+- commande UI disponible via `Demo Pipeline 2 > Replay local > Refresh missing token metadata` avec limite dédiée ;
+- idempotence attendue : le backfill metadata met à jour tokens et symboles de paires sans recréer pools, paires, trades, candles ou origins ;
+- registre local minimal consolidé : `SOL`, `WSOL`, `USDC`, `USDT`.
 
-À faire :
+Limite non bloquante : les diagnostics détaillés par origine de découverte restent une amélioration de confort ; l’étape `0.7.38` fournit déjà une liste priorisée exploitable via `tokenMetadataGapSamples`.
 
-- ajouter ou consolider un registre local des mints connus et stables : `SOL`, `WSOL`, `USDC`, `USDT`, puis autres mints seulement si vérifiés ;
-- améliorer le backfill metadata pour traiter les tokens déjà présents dans `k_sol_tokens` sans nécessiter un nouveau backfill transactionnel ;
-- enrichir les tokens depuis les sources disponibles : registre local, payloads DEX, comptes Token-2022, Metaplex, transactions déjà persistées ;
-- rafraîchir les `pair_symbol` après mise à jour des metadata de tokens ;
-- exposer des diagnostics précis : `tokenMetadataMissingCount` par `dexCode`, `quoteAssetClass`, mint connu/inconnu et origine de découverte ;
-- ajouter ou clarifier une commande UI dans `kb_demo_app` pour lancer le backfill metadata et rafraîchir le catalogue ;
-- garantir l’idempotence : relancer l’enrichissement metadata ne doit pas recréer tokens, pools, paires, trades, candles ou origins ;
-- conserver l’invariant de validation : le manque de metadata n’est pas un diagnostic bloquant tant que les trades/candles actionnables sont sains ;
-- ajouter le profil de validation `0.7.37_token_metadata_catalog_enrichment`.
+### 6.070. Version `0.7.38` — Priorisation des metadata manquantes
+Objectif : transformer les compteurs metadata/catalog de `0.7.37` en liste d’action priorisée sans rendre les metadata manquantes bloquantes.
 
-### 6.070. Version `0.7.38` — Launch surfaces : LaunchLab, LetsBonk, Bags, Moonshot/Moonit, Boop.fun, Believe
+Réalisé :
+
+- ajout du profil `0.7.38_token_metadata_gap_prioritization` ;
+- exposition de `tokenMetadataGapSamples` dans les diagnostics locaux, la validation et les bindings Demo Pipeline 2 ;
+- priorisation des tokens manquants par usage : `tradable_quote_missing_metadata`, `tradable_token_missing_metadata`, `quote_token_missing_metadata`, puis `catalog_token_missing_metadata` ;
+- raccordement Demo Pipeline 2 au nouveau profil par défaut ;
+- conservation de l’invariant : les metadata manquantes ne créent pas de blocking issue tant que les trades/candles actionnables restent sains ;
+- validation locale confirmée avec `validationPassed = true`, `blockingIssueCount = 0`, `missingTradeEventCount = 0`, `decodedTradeCandidateWithoutTradeEventCount = 0` ;
+- les samples permettent de sélectionner les prochains mints à enrichir via registre local, payloads DEX, Token-2022, Metaplex ou backfill HTTP.
+
+Décision : `0.7.38` est clos. La clôture `0.7.38-B` conserve la logique de stable quotes limitée à `USDC`/`USDT` et ajoute un registre metadata local pour `JUP`, `RAY` et `BONK` sans les classer automatiquement comme quotes. La suite de développement commence à `0.7.39` avec les launch surfaces.
+
+### 6.071. Version `0.7.39` — Launch surfaces : LaunchLab, LetsBonk, Bags, Moonshot/Moonit, Boop.fun, Believe
 Objectif : détecter la première source de mint/lancement des tokens même lorsque le swap final se fait ailleurs.
 
 À faire :
@@ -949,7 +959,7 @@ Objectif : détecter la première source de mint/lancement des tokens même lors
 - rattacher les launch origins aux pools et paires lorsque les comptes permettent un matching fiable,
 - exposer les origins dans les diagnostics et l’UI d’inspection.
 
-### 6.071. Version `0.7.39` — Heaven : corpus, launch et AMM
+### 6.072. Version `0.7.39` — Heaven : corpus, launch et AMM
 Objectif : ajouter Heaven sans le classer trop tôt comme simple DEX ou simple launchpad.
 
 À faire :
@@ -961,7 +971,7 @@ Objectif : ajouter Heaven sans le classer trop tôt comme simple DEX ou simple l
 - documenter les limites si le corpus ne permet pas encore de matérialiser tous les événements,
 - vérifier que Heaven ne crée pas de candles invalides en cas d’événement de launch non pricé.
 
-### 6.072. Version `0.7.40` — Orca / FluxBeam / DexLab : corpus et validation ciblée
+### 6.073. Version `0.7.40` — Orca / FluxBeam / DexLab : corpus et validation ciblée
 Objectif : consolider les connecteurs déjà présents à partir de corpus locaux vérifiables.
 
 À faire :
@@ -973,7 +983,7 @@ Objectif : consolider les connecteurs déjà présents à partir de corpus locau
 - marquer explicitement les variantes partiellement supportées ou heuristiques,
 - rejouer les corpus plusieurs fois pour vérifier l’idempotence et l’absence de trades/candles invalides.
 
-### 6.073. Version `0.7.41` — Raydium AMM v4 legacy : corpus et validation ciblée
+### 6.074. Version `0.7.41` — Raydium AMM v4 legacy : corpus et validation ciblée
 Objectif : traiter le vrai Raydium AMM v4 historique après les autres Raydium, afin de l’isoler de `raydium_cpmm`, `raydium_clmm` et des labels Raydium génériques.
 
 À faire :
@@ -986,7 +996,7 @@ Objectif : traiter le vrai Raydium AMM v4 historique après les autres Raydium,
 - renommer/stabiliser les fonctions internes autour de `raydium_amm_v4` pour éviter l’ambiguïté avec `raydium_cpmm` et `raydium_clmm`,
 - documenter les limites connues si le corpus AMM v4 reste faible.
 
-### 6.074. Version `0.7.42` — Validation DEX v1 consolidée
+### 6.075. Version `0.7.42` — Validation DEX v1 consolidée
 Objectif : rejouer tous les DEX et launch surfaces supportés et valider les invariants du pipeline complet.
 
 À faire :
@@ -999,7 +1009,7 @@ Objectif : rejouer tous les DEX et launch surfaces supportés et valider les inv
 - conserver une matrice de support par DEX, variante, instruction et type d’événement,
 - verrouiller les invariants avant d’ouvrir l’analyse `0.8.x`.
 
-### 6.075. Version `0.7.43` — `kb_demo_app` : overlays analytiques
+### 6.076. Version `0.7.43` — `kb_demo_app` : overlays analytiques
 Objectif : rendre visibles les signaux analytiques directement sur les graphes et vues de marché.
 
 À faire :
@@ -1010,7 +1020,7 @@ Objectif : rendre visibles les signaux analytiques directement sur les graphes e
 - afficher un panneau latéral listant les signaux liés à une paire et à un timeframe,
 - préparer l’extension future vers Ichimoku, Kumo, projections ABCD et égalités temps/prix sans les mélanger au pipeline de décodage DEX.
 
-### 6.076. Version `0.7.44` — `kb_demo_app` : vues consolidées token / pair / pool
+### 6.077. Version `0.7.44` — `kb_demo_app` : vues consolidées token / pair / pool
 Objectif : fournir une lecture métier plus confortable du modèle `0.7.x`.
 
 À faire :
@@ -1022,7 +1032,7 @@ Objectif : fournir une lecture métier plus confortable du modèle `0.7.x`.
 - préparer une navigation transversale entre objets techniques et objets métier,
 - rendre explicites les cas `tradeCount = null`, `lastPriceQuotePerBase = null`, tokens non enrichis et événements conservés uniquement pour analyse.
 
-### 6.077. Version `0.7.45` — Finition UI `0.7.x`
+### 6.078. Version `0.7.45` — Finition UI `0.7.x`
 Objectif : stabiliser la couche desktop de validation avant l’ouverture de `0.8.x`.
 
 À faire :
@@ -1033,7 +1043,7 @@ Objectif : stabiliser la couche desktop de validation avant l’ouverture de `0.
 - 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`.
 
-### 6.078. Version `0.7.x` — Couverture DEX v1
+### 6.079. Version `0.7.x` — Couverture DEX v1
 Objectif : structurer les connecteurs DEX autour d’un pipeline complet de résolution, décodage, normalisation métier et classification des événements non-trade.
 
 Protocoles et surfaces cibles :
@@ -1076,7 +1086,7 @@ Résultat attendu :
 - 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.079. Version `0.8.x` — Analyse et filtrage
+### 6.080. Version `0.8.x` — Analyse et filtrage
 Objectif : transformer les événements bruts en signaux exploitables.
 
 À faire :
@@ -1091,7 +1101,7 @@ Objectif : transformer les événements bruts en signaux exploitables.
 - 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.080. Version `1.x.y` — Wallets et swap préparatoire
+### 6.081. Version `1.x.y` — Wallets et swap préparatoire
 Objectif : préparer la couche d’action.
 
 À faire :
@@ -1102,7 +1112,7 @@ Objectif : préparer la couche d’action.
 - préparation d’ordres et de swaps,
 - simulation et garde-fous.
 
-### 6.081. Version `2.x.y` — Trading semi-automatisé
+### 6.082. Version `2.x.y` — Trading semi-automatisé
 Objectif : brancher l’analyse à l’action tout en gardant des garde-fous explicites.
 
 À faire :
@@ -1113,7 +1123,7 @@ Objectif : brancher l’analyse à l’action tout en gardant des garde-fous exp
 - confirmations explicites ou semi-automatiques,
 - journaux d’exécution.
 
-### 6.082. Version `3.x.y` — Yellowstone gRPC
+### 6.083. Version `3.x.y` — Yellowstone gRPC
 Objectif : ajouter le connecteur gRPC dédié.
 
 À faire :
@@ -1243,17 +1253,21 @@ Le projet doit maintenir au minimum :
 
 ## 12. Priorité immédiate
 
-La priorité immédiate reste de terminer `0.7.37_token_metadata_catalog_enrichment` par le backfill metadata effectif et le rafraîchissement des symboles de paires.
+La priorité immédiate est `0.7.39_launch_surfaces` : détecter et rattacher les origines de lancement sans casser les invariants `0.7.36` à `0.7.38`.
 
-Ordre de travail recommandé :
+Préconditions validées avant `0.7.39` :
 
-1. conserver la validation acquise `0.7.36` : Meteora consolidé, transactions failed traçables mais non actionnables, swaps sans amounts classés `non_actionable_trade`, aucun diagnostic bloquant masqué ;
-2. améliorer le catalogue local : metadata de tokens, symboles, noms, asset classes et `pair_symbol` lisibles ;
-3. ajouter un registre local des mints connus et stables : `SOL`, `WSOL`, `USDC`, `USDT`, puis autres mints seulement après vérification ;
-4. permettre un backfill metadata idempotent sur les tokens déjà présents sans relancer un backfill transactionnel complet ;
-5. exposer les compteurs de metadata manquantes par DEX, asset class, quote asset et origine de découverte ;
-6. ajouter ou clarifier la commande UI permettant de relancer le backfill metadata et le refresh du catalogue ;
-7. vérifier que l’enrichissement metadata ne modifie pas les invariants DEX : pas de faux trades, pas de fausses candles, pas de recréation de pools/paires ;
-8. déplacer ensuite les launch surfaces vers `0.7.38` : Raydium LaunchLab/Launchpad, LetsBonk/Bonk.fun, Boop.fun, Moonshot/Moonit, Believe et Bags ;
-9. traiter Heaven en `0.7.39`, puis Orca/FluxBeam/DexLab, puis Raydium AMM v4 legacy ;
-10. effectuer une validation DEX v1 consolidée avant d’ouvrir réellement `0.8.x` pour l’analyse, les filtres, les patterns et les projections graphiques.
+1. validation `0.7.36` acquise : Meteora consolidé, transactions failed traçables mais non actionnables, swaps sans amounts classés `non_actionable_trade`, aucun diagnostic bloquant masqué ;
+2. validation `0.7.37` acquise : compteurs metadata/catalog exposés, backfill metadata idempotent, `pair_symbol` rafraîchissables, metadata manquantes non bloquantes ;
+3. validation `0.7.38` acquise : `tokenMetadataGapSamples` priorisés, Demo Pipeline 2 raccordé, `validationPassed = true`, `blockingIssueCount = 0`, registre local `WSOL`/`USDC`/`USDT`/`JUP`/`RAY`/`BONK` disponible ;
+4. registre local minimal disponible : `SOL`, `WSOL`, `USDC`, `USDT` ;
+5. les diagnostics locaux restent l’outil de vérité pour décider si une surface peut passer de `planned` à `partial` ou `supported`.
+
+Ordre de travail recommandé pour `0.7.39` :
+
+1. scanner `launch_origin.rs`, `pool_origin.rs`, `protocol_candidate_recording.rs`, `dex_support_matrix.rs`, `transaction_classification.rs`, `dex_decode.rs` et `dex_detect.rs` ;
+2. identifier les surfaces candidates déjà présentes dans la matrice : Raydium LaunchLab/Launchpad, LetsBonk/Bonk.fun, Bags, Moonshot/Moonit, Boop.fun et Believe ;
+3. ne promouvoir une surface que si le corpus prouve le program id, les comptes/authorities et la migration vers le DEX effectif ;
+4. distinguer explicitement `launch_origin`, `pool_origin`, `dex_effective` et `migration_target` ;
+5. exposer les origins dans les diagnostics et l’UI d’inspection ;
+6. conserver les garde-fous : pas de faux trade, pas de fausse candle, pas de program id inventé, pas de metadata manquante bloquante.