0.7.31

ROADMAP.md

@@ -826,9 +826,7 @@ Matrice cible initiale :
 | `zora` | à vérifier | à vérifier | hors phasage actif avant preuve Solana |
 
 ### 6.062. Version `0.7.30` — Classification fine des événements DEX décodés
-Objectif : préparer les événements non-trade utiles sans modifier la matérialisation trade/candle validée.
-
-Fait / à valider :
+Réalisé :
 
 - ajouter `DexEventLifecycleKind` pour distinguer `trade_swap`, `pool_creation`, `pair_creation`, `liquidity_add`, `liquidity_remove`, `position_open`, `position_close`, `migration`, `launch`, `mint`, `burn`, `fee_collection`, `reward`, `admin_config` et `unknown`,
 - ajouter `DexEventActionability` pour distinguer `trade_candidate`, `non_actionable_trade`, `non_trade_useful`, `failed_transaction`, `informational` et `unknown`,
@@ -838,7 +836,17 @@ Fait / à valider :
 - ajouter le profil `0.7.30_non_trade_event_classification`,
 - ne pas matérialiser encore les événements non-trade dans leurs tables dédiées.
 
-### 6.063. Version `0.7.31` — Transactions inconnues et protocol candidates
+### 6.063. Version `0.7.31` — Politique de matérialisation des failed transactions
+Réalisé :
+
+- empêcher `TradeAggregationService` de matérialiser une transaction dont `err_json` est renseigné ;
+- conserver les événements DEX décodés des failed transactions pour audit et diagnostic ;
+- réinitialiser les tables dérivées de marché pendant le replay local : `k_sol_trade_events`, `k_sol_pair_metrics`, `k_sol_pair_candles`, `k_sol_pair_analytic_signals` ;
+- reconstruire ensuite les trades/candles uniquement à partir des événements `tradeCandidate=true` et de transactions OK ;
+- 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` — Transactions inconnues et protocol candidates
 Objectif : ne plus perdre les transactions utiles qui ne correspondent pas encore à un DEX connu.
 
 À faire :
@@ -851,7 +859,7 @@ Objectif : ne plus perdre les transactions utiles qui ne correspondent pas encor
 - 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.
 
-### 6.064. Version `0.7.32` — Événements non-trade v1 : liquidité et cycle de vie pool
+### 6.065. Version `0.7.33` — É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 :
@@ -864,7 +872,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.065. Version `0.7.33` — Événements non-trade v2 : fees, rewards et administration
+### 6.066. Version `0.7.34` — É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 :
@@ -878,7 +886,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.066. Version `0.7.34` — Meteora : DBC / DAMM v1 / DAMM v2 / DLMM
+### 6.067. Version `0.7.35` — 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 :
@@ -892,7 +900,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.066. Version `0.7.34` — Launch surfaces : LaunchLab, LetsBonk, Bags, Moonshot/Moonit, Boop.fun, Believe
+### 6.068. Version `0.7.36` — 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 :
@@ -907,7 +915,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.067. Version `0.7.35` — Heaven : corpus, launch et AMM
+### 6.069. Version `0.7.37` — Heaven : corpus, launch et AMM
 Objectif : ajouter Heaven sans le classer trop tôt comme simple DEX ou simple launchpad.
 
 À faire :
@@ -919,7 +927,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.068. Version `0.7.36` — Orca / FluxBeam / DexLab : corpus et validation ciblée
+### 6.070. Version `0.7.38` — Orca / FluxBeam / DexLab : corpus et validation ciblée
 Objectif : consolider les connecteurs déjà présents à partir de corpus locaux vérifiables.
 
 À faire :
@@ -931,7 +939,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.069. Version `0.7.37` — Raydium AMM v4 legacy : corpus et validation ciblée
+### 6.071. Version `0.7.39` — 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 :
@@ -944,7 +952,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.070. Version `0.7.38` — Validation DEX v1 consolidée
+### 6.072. Version `0.7.40` — Validation DEX v1 consolidée
 Objectif : rejouer tous les DEX et launch surfaces supportés et valider les invariants du pipeline complet.
 
 À faire :
@@ -957,7 +965,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.071. Version `0.7.39` — `kb_demo_app` : overlays analytiques
+### 6.073. Version `0.7.41` — `kb_demo_app` : overlays analytiques
 Objectif : rendre visibles les signaux analytiques directement sur les graphes et vues de marché.
 
 À faire :
@@ -968,7 +976,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.072. Version `0.7.40` — `kb_demo_app` : vues consolidées token / pair / pool
+### 6.074. Version `0.7.42` — `kb_demo_app` : vues consolidées token / pair / pool
 Objectif : fournir une lecture métier plus confortable du modèle `0.7.x`.
 
 À faire :
@@ -980,7 +988,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.073. Version `0.7.41` — Finition UI `0.7.x`
+### 6.075. Version `0.7.43` — Finition UI `0.7.x`
 Objectif : stabiliser la couche desktop de validation avant l’ouverture de `0.8.x`.
 
 À faire :
@@ -991,7 +999,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.074. Version `0.7.x` — Couverture DEX v1
+### 6.076. 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 :
@@ -1034,7 +1042,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.075. Version `0.8.x` — Analyse et filtrage
+### 6.077. Version `0.8.x` — Analyse et filtrage
 Objectif : transformer les événements bruts en signaux exploitables.
 
 À faire :
@@ -1049,7 +1057,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.076. Version `1.x.y` — Wallets et swap préparatoire
+### 6.078. Version `1.x.y` — Wallets et swap préparatoire
 Objectif : préparer la couche d’action.
 
 À faire :
@@ -1060,7 +1068,7 @@ Objectif : préparer la couche d’action.
 - préparation d’ordres et de swaps,
 - simulation et garde-fous.
 
-### 6.077. Version `2.x.y` — Trading semi-automatisé
+### 6.079. Version `2.x.y` — Trading semi-automatisé
 Objectif : brancher l’analyse à l’action tout en gardant des garde-fous explicites.
 
 À faire :
@@ -1071,7 +1079,7 @@ Objectif : brancher l’analyse à l’action tout en gardant des garde-fous exp
 - confirmations explicites ou semi-automatiques,
 - journaux d’exécution.
 
-### 6.078. Version `3.x.y` — Yellowstone gRPC
+### 6.080. Version `3.x.y` — Yellowstone gRPC
 Objectif : ajouter le connecteur gRPC dédié.
 
 À faire :
@@ -1187,7 +1195,7 @@ Réalisé / à maintenir :
 
 Validé en `0.7.30` : classification fine des événements décodés via `eventLifecycleKind`, `eventActionability` et `nonTradeUseful`, avec diagnostics associés et sans changement volontaire sur les trades/candles.
 
-À poursuivre en `0.7.31` : transactions inconnues et protocol candidates ; puis en `0.7.32` : matérialisation contrôlée des événements non-trade utiles.
+À poursuivre après `0.7.31` : transactions inconnues/protocol candidates, puis matérialisation contrôlée des événements non-trade utiles, sans alimenter les trades/candles actionnables.
 
 ## 11. Documentation et livrables de référence
 Le projet doit maintenir au minimum :
@@ -1203,7 +1211,7 @@ Le projet doit maintenir au minimum :
 
 La priorité immédiate est désormais la suivante :
 
-1. conserver la validation acquise `0.7.28` : transactions failed traçables mais non actionnables, aucun trade/candle candidate sans payload montant/prix exploitable, aucun diagnostic bloquant masqué,
+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. 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,