0.7.33

ROADMAP.md

@@ -861,7 +861,20 @@ Réalisé :
 
 Repoussé après cette clarification : consolider les transactions inconnues et protocol candidates sans polluer les trades/candles.
 
-### 6.065. Version `0.7.33` — Événements non-trade v1 : liquidité et cycle de vie pool
+### 6.065. Version `0.7.33` — Readiness trading des paires
+Réalisé :
+
+- ajouter une classification diagnostique `pairTradingReadiness` pour chaque paire inspectée localement ;
+- distinguer `direct_wsol_quote`, `direct_stable_quote`, `inverse_wsol_base`, `inverse_stable_base`, `cross_quote_requires_router`, `unknown_quote` et `non_trade_materialized` ;
+- exposer `quoteAssetClass` et `tradingRouteRequired` dans les diagnostics par paire ;
+- ajouter `pairTradingReadinessSummaries` dans le résumé local du pipeline ;
+- ajouter le profil `0.7.33_pair_trading_readiness` ;
+- valider que les résumés de readiness couvrent toutes les paires et restent cohérents avec les compteurs `tradeMaterializedPairCount`, `tradeEventCount` et `pairCandleCount` ;
+- ne pas modifier la logique de replay, `trade_events`, metrics ou candles.
+
+Objectif : préparer la future couche d’achat/vente en distinguant les paires immédiatement exploitables contre WSOL/stable des paires qui nécessitent inversion de lecture ou routeur/aggregator.
+
+### 6.066. Version `0.7.34` — Événements non-trade v1 : liquidité et cycle de vie pool
 Objectif : exploiter les événements utiles à l’analyse et au trading semi-automatique sans les mélanger avec les swaps/candles.
 
 À faire :
@@ -874,7 +887,7 @@ Objectif : exploiter les événements utiles à l’analyse et au trading semi-a
 - alimenter les diagnostics locaux avec les compteurs liquidité/lifecycle,
 - garantir qu’un événement de liquidité ou de cycle de vie ne produit jamais de candle directement.
 
-### 6.066. Version `0.7.34` — Événements non-trade v2 : fees, rewards et administration
+### 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 :
@@ -888,7 +901,7 @@ Objectif : conserver les événements utiles au risque, au scoring, à l’écon
 - 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.
 
-### 6.067. Version `0.7.35` — Meteora : DBC / DAMM v1 / DAMM v2 / DLMM
+### 6.068. Version `0.7.36` — Meteora : DBC / DAMM v1 / DAMM v2 / DLMM
 Objectif : consolider Meteora comme famille multi-programmes au lieu de traiter chaque variante comme un cas isolé incomplet.
 
 À faire :
@@ -902,7 +915,7 @@ Objectif : consolider Meteora comme famille multi-programmes au lieu de traiter
 - vérifier l’idempotence du replay local sur un corpus Meteora mixte,
 - documenter les limites connues des variantes insuffisamment couvertes.
 
-### 6.068. Version `0.7.36` — Launch surfaces : LaunchLab, LetsBonk, Bags, Moonshot/Moonit, Boop.fun, Believe
+### 6.069. Version `0.7.37` — 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 :
@@ -917,7 +930,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.069. Version `0.7.37` — Heaven : corpus, launch et AMM
+### 6.070. Version `0.7.38` — Heaven : corpus, launch et AMM
 Objectif : ajouter Heaven sans le classer trop tôt comme simple DEX ou simple launchpad.
 
 À faire :
@@ -929,7 +942,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.070. Version `0.7.38` — Orca / FluxBeam / DexLab : corpus et validation ciblée
+### 6.071. Version `0.7.39` — Orca / FluxBeam / DexLab : corpus et validation ciblée
 Objectif : consolider les connecteurs déjà présents à partir de corpus locaux vérifiables.
 
 À faire :
@@ -941,7 +954,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.071. Version `0.7.39` — Raydium AMM v4 legacy : corpus et validation ciblée
+### 6.072. Version `0.7.40` — 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 :
@@ -954,7 +967,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.072. Version `0.7.40` — Validation DEX v1 consolidée
+### 6.073. Version `0.7.41` — Validation DEX v1 consolidée
 Objectif : rejouer tous les DEX et launch surfaces supportés et valider les invariants du pipeline complet.
 
 À faire :
@@ -967,7 +980,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.073. Version `0.7.41` — `kb_demo_app` : overlays analytiques
+### 6.074. Version `0.7.42` — `kb_demo_app` : overlays analytiques
 Objectif : rendre visibles les signaux analytiques directement sur les graphes et vues de marché.
 
 À faire :
@@ -978,7 +991,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.074. Version `0.7.42` — `kb_demo_app` : vues consolidées token / pair / pool
+### 6.075. Version `0.7.43` — `kb_demo_app` : vues consolidées token / pair / pool
 Objectif : fournir une lecture métier plus confortable du modèle `0.7.x`.
 
 À faire :
@@ -990,7 +1003,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.075. Version `0.7.43` — Finition UI `0.7.x`
+### 6.076. Version `0.7.44` — Finition UI `0.7.x`
 Objectif : stabiliser la couche desktop de validation avant l’ouverture de `0.8.x`.
 
 À faire :
@@ -1001,7 +1014,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.076. Version `0.7.x` — Couverture DEX v1
+### 6.077. 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 :
@@ -1044,7 +1057,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.077. Version `0.8.x` — Analyse et filtrage
+### 6.078. Version `0.8.x` — Analyse et filtrage
 Objectif : transformer les événements bruts en signaux exploitables.
 
 À faire :
@@ -1059,7 +1072,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.078. Version `1.x.y` — Wallets et swap préparatoire
+### 6.079. Version `1.x.y` — Wallets et swap préparatoire
 Objectif : préparer la couche d’action.
 
 À faire :
@@ -1070,7 +1083,7 @@ Objectif : préparer la couche d’action.
 - préparation d’ordres et de swaps,
 - simulation et garde-fous.
 
-### 6.079. Version `2.x.y` — Trading semi-automatisé
+### 6.080. Version `2.x.y` — Trading semi-automatisé
 Objectif : brancher l’analyse à l’action tout en gardant des garde-fous explicites.
 
 À faire :
@@ -1081,7 +1094,7 @@ Objectif : brancher l’analyse à l’action tout en gardant des garde-fous exp
 - confirmations explicites ou semi-automatiques,
 - journaux d’exécution.
 
-### 6.080. Version `3.x.y` — Yellowstone gRPC
+### 6.081. Version `3.x.y` — Yellowstone gRPC
 Objectif : ajouter le connecteur gRPC dédié.
 
 À faire :
@@ -1215,9 +1228,10 @@ La priorité immédiate est désormais la suivante :
 
 1. conserver la validation acquise `0.7.31` : transactions failed traçables mais exclues des `trade_events`, metrics et candles, aucun trade/candle candidate sans payload montant/prix exploitable, aucun diagnostic bloquant masqué,
 2. conserver la clarification `0.7.32` entre gaps littéraux de catalogue et gaps bloquants/actionnables,
-3. utiliser la matrice `0.7.29` (`kb_lib/src/dex_support_matrix.rs`) comme source commune pour le catalogue DEX, les mappings program id -> protocole, la classification transactionnelle et les protocol candidates,
-4. garder les clients HTTP/WS et managers réseau hors du refactor DEX tant qu’ils ne bloquent pas le pipeline,
-5. consolider les événements non-trade sans les confondre avec les trades/candles : lifecycle de pool, liquidité, fees, rewards, admin/config, migration et launch/mint,
+3. conserver la classification `0.7.33` des paires par readiness trading : direct WSOL/stable, inverse WSOL/stable, cross-quote avec routeur requis, inconnue ou non matérialisée,
+4. utiliser la matrice `0.7.29` (`kb_lib/src/dex_support_matrix.rs`) comme source commune pour le catalogue DEX, les mappings program id -> protocole, la classification transactionnelle et les protocol candidates,
+5. garder les clients HTTP/WS et managers réseau hors du refactor DEX tant qu’ils ne bloquent pas le pipeline,
+6. consolider les événements non-trade sans les confondre avec les trades/candles : lifecycle de pool, liquidité, fees, rewards, admin/config, migration et launch/mint,
 6. rattacher les launch surfaces aux tokens et aux pools migrés : Raydium LaunchLab/Launchpad, LetsBonk/Bonk.fun, Boop.fun, Moonshot/Moonit, Believe, Bags et Heaven,
 7. consolider Meteora avec corpus fiable : `meteora_dlmm`, `meteora_damm_v1`, `meteora_damm_v2`, `meteora_dbc` et `meteora_dlc` si le programme est confirmé,
 8. consolider Orca, FluxBeam et DexLab sur corpus,