0.7.34

ROADMAP.md

@@ -846,38 +846,27 @@ Réalisé :
 - exposer `resetMarketMaterializationDeletedCount` dans le résultat de replay UI ;
 - conserver la validation multi-DEX et la matrice DEX comme garde-fous avant d’ajouter les surfaces restantes.
 
-### 6.064. Version `0.7.32` — Sémantique des diagnostics et compteurs de validation
+### 6.064. Version `0.7.32` — Transactions inconnues et protocol candidates
 Réalisé :
 
-- conserver la politique `0.7.31` : transactions failed traçables mais exclues des `trade_events`, metrics et candles ;
-- clarifier que `pairWithoutTradeCount` et `pairWithoutCandleCount` sont des compteurs de gaps bloquants/actionnables, pas des compteurs littéraux sur tout le catalogue ;
-- ajouter `literalPairWithoutTradeCount` et `literalPairWithoutCandleCount` pour les paires de catalogue sans trade/candle matérialisé ;
-- ajouter `blockingPairWithoutTradeCount` et `blockingPairWithoutCandleCount` comme noms explicites des anciens compteurs bloquants ;
-- ajouter les compteurs de matérialisation par paire : `tradeMaterializedPairCount`, `candleMaterializedPairCount`, `actionablePairCount`, `candleBucketTimeframeCount` et `candlesAreBucketed` ;
-- ajouter `pairActionabilitySummaries` pour distinguer les paires matérialisées, actionnables sans matérialisation, candidates failed, non-actionables, décodées sans trade candidate et catalog-only ;
-- ajouter le profil `0.7.32_validation_report_semantics` ;
-- ajouter des garde-fous de validation sur la matrice DEX : entrées `supported` entièrement matérialisées, entrées `partial` avec `skipReason`, entrées `planned/to_verify` non activées au catalogue ;
-- ne pas modifier la logique de replay, trade aggregation ou candle aggregation validée en `0.7.31`.
+- consolider `k_sol_transaction_classifications`, déjà présente, avec les catégories utiles au suivi DEX,
+- consolider `k_sol_protocol_candidates`, déjà présente, pour prioriser les programmes inconnus ou partiellement reconnus,
+- classifier les transactions résolues en catégories : known supported, known partial, known non-trade, unknown program, unknown protocol candidate, unknown event kind, failed transaction, non-actionable trade,
+- conserver les `program_id`, comptes, signatures, préfixes de `data`, logs et indices d’instructions utiles à l’analyse,
+- créer des requêtes de diagnostic pour repérer les programmes inconnus fréquents,
+- permettre de promouvoir plus tard un protocol candidate vers un vrai DEX/surface sans perdre l’historique,
+- garantir que ces tables n’alimentent jamais directement les trades/candles.
 
-Repoussé après cette clarification : consolider les transactions inconnues et protocol candidates sans polluer les trades/candles.
-
-### 6.065. Version `0.7.33` — Readiness trading des paires
+### 6.065. Version `0.7.33` — Pair trading readiness et routes de cotation
 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.
+- classifier les paires `direct_wsol_quote`, `direct_stable_quote`, `inverse_wsol_base`, `inverse_stable_base`, `cross_quote_requires_router` et `non_trade_materialized` ;
+- exposer `quoteAssetClass` et `tradingRouteRequired` dans les diagnostics ;
+- éviter de bloquer la validation sur des paires seulement listées ou détectées sans trade matérialisé ;
+- préparer la future sélection des paires directement tradables versus paires nécessitant un router.
 
 ### 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 :
+Réalisé :
 
 - stabiliser et étendre `k_sol_liquidity_events` au lieu de la recréer inutilement,
 - ajouter `k_sol_pool_lifecycle_events`,
@@ -886,6 +875,10 @@ Objectif : exploiter les événements utiles à l’analyse et au trading semi-a
 - conserver le `payload_json` source pour audit,
 - 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.
+- première tranche DLMM : reconnaître et persister `meteora_dlmm.add_liquidity`, `meteora_dlmm.remove_liquidity`, `meteora_dlmm.initialize_position` et `meteora_dlmm.initialize_bin_array` comme événements non-trade utiles ;
+- intégrer la matérialisation non-trade dans les backfills ciblés token/pool, pas uniquement dans le replay local, afin que les diagnostics reflètent immédiatement les événements DLMM non-trade décodés ;
+- distinguer `PositionOpen` et `PositionClose` dans `LiquidityEventKind` au lieu de rabattre les positions CLMM/DLMM sur `Add`/`Remove` ;
+- conserver `meteora_damm_v1` manquant comme warning non bloquant lorsque le corpus de backfill local ne contient pas ce DEX.
 
 ### 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.
@@ -1227,19 +1220,17 @@ Le projet doit maintenir au minimum :
 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. 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,
-9. traiter `raydium_amm_v4` legacy seulement après les autres Raydium, avec corpus dédié prouvant le programme `675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8`,
-10. ajouter une matérialisation dédiée des transactions inconnues ou partiellement décodées pour analyser les DEX manquants sans polluer les trades/candles,
-11. effectuer une validation DEX v1 consolidée sur tous les connecteurs supportés avant de considérer la couche DEX `0.7.x` comme stable,
-12. ajouter ensuite les overlays des signaux analytiques sur les candles,
-13. consolider les vues métier `token / pair / pool` dans `kb_demo_app`, y compris les événements liquidité, lifecycle, fees, rewards et admin,
-14. stabiliser l’ergonomie, les filtres, la pagination et la navigation de l’UI d’inspection,
-15. préparer ensuite l’ouverture de `0.8.x` pour l’analyse, les filtres, les patterns et les projections graphiques,
-16. préparer enfin Yellowstone gRPC comme extension de capacité, et non comme remplacement du socle HTTP / WS existant.
+2. 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,
+3. garder les clients HTTP/WS et managers réseau hors du refactor DEX tant qu’ils ne bloquent pas le pipeline,
+4. 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,
+5. 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,
+6. consolider Meteora avec corpus fiable : `meteora_dlmm`, `meteora_damm_v1`, `meteora_damm_v2`, `meteora_dbc` et `meteora_dlc` si le programme est confirmé,
+7. consolider Orca, FluxBeam et DexLab sur corpus,
+8. traiter `raydium_amm_v4` legacy seulement après les autres Raydium, avec corpus dédié prouvant le programme `675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8`,
+9. ajouter une matérialisation dédiée des transactions inconnues ou partiellement décodées pour analyser les DEX manquants sans polluer les trades/candles,
+10. effectuer une validation DEX v1 consolidée sur tous les connecteurs supportés avant de considérer la couche DEX `0.7.x` comme stable,
+11. ajouter ensuite les overlays des signaux analytiques sur les candles,
+12. consolider les vues métier `token / pair / pool` dans `kb_demo_app`, y compris les événements liquidité, lifecycle, fees, rewards et admin,
+13. stabiliser l’ergonomie, les filtres, la pagination et la navigation de l’UI d’inspection,
+14. préparer ensuite l’ouverture de `0.8.x` pour l’analyse, les filtres, les patterns et les projections graphiques,
+15. préparer enfin Yellowstone gRPC comme extension de capacité, et non comme remplacement du socle HTTP / WS existant.