0.7.43-E5C

ROADMAP.md

@@ -1019,35 +1019,129 @@ Réalisé :
 
 Limite connue non-Raydium : un corpus local peut encore contenir des événements `orca_whirlpools.swap` partiels. Orca Whirlpools est explicitement reporté à `0.7.44`; cela ne remet pas en cause la clôture Raydium `0.7.42`.
 
-Décision : `0.7.42` est clos côté Raydium. La suite immédiate est `0.7.43` pour Meteora, puis `0.7.44` pour Orca/FluxBeam/DexLab/metaDAO/Printr.
+Décision : `0.7.42` est clos côté Raydium. Le lot `0.7.43` ouvert pour Meteora n’est pas considéré comme clos : il devient le point de reprise `0.7.43-E5C`, puis la suite est découpée en étapes plus petites pour éviter les lots multi-DEX trop larges.
 
-### 6.075. Version `0.7.43` — Meteora effectif : DLMM, DAMM v1/v2, DBC
-Objectif : compléter la famille Meteora en couvrant les événements réellement utiles au DEX effectif, avec corpus enrichi par Demo3 si nécessaire.
+### 6.075. Version `0.7.43` — Point de reprise, normalisation DEX-first et documentation
+Objectif : figer le point de reprise après saturation de session, clarifier l’état réel du corpus et empêcher la roadmap de regrouper plusieurs DEX/versions dans une seule tranche de validation.
+
+À faire / acté :
+
+- documenter que `0.7.43` n’est pas une clôture Meteora complète ;
+- conserver les résultats locaux observés : `2956` transactions, `7159` decoded events, `2738` trade events, `0` liquidity events sur le corpus courant, `1` lifecycle event, `0` fee/reward/admin events ;
+- acter que les nombreux `instruction_audit` Meteora sont une dette de décodage, pas une preuve d’événements non-trade matérialisés ;
+- imposer un ordre de travail : vrais DEX effectifs, puis launch surfaces, puis DEX historiques/legacy ;
+- imposer une validation séparée par DEX/version : `meteora_dlmm`, `meteora_damm_v1`, `meteora_damm_v2`, `meteora_dbc`, etc. ;
+- distinguer les statuts `known`, `observed`, `decoded`, `materialized`, `verified_by_corpus` ;
+- maintenir la règle : aucun `program_id` n’est vérifié sans signature/corpus/requête de validation.
+
+### 6.076. Version `0.7.44` — Ledger de décodage/replay et skip sûr
+Objectif : empêcher le replay local de rescanner inutilement les transactions/instructions dont le décodage est déjà certain, tout en gardant la possibilité de forcer ou de retraiter les cas ambigus.
 
 À faire :
 
-- conserver la validation `0.7.36` : les swaps DAMM v2 / DBC sans amounts fiables restent `non_actionable_trade` ;
-- vérifier `cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG` et les autres programmes Meteora dans le corpus local ;
-- consolider `meteora_dlmm` pour swaps, positions, add/remove liquidity, lifecycle et non-trade events ;
-- consolider `meteora_damm_v1` et `meteora_damm_v2` pour pools, swaps exploitables, configs dynamiques, fees/admin ;
-- clarifier la part `launch/bonding_curve` et la part `dex_effective` de `meteora_dbc` ;
-- éviter tout trade/candle artificiel lorsque les montants ou prix ne sont pas prouvés.
+- ajouter une table de suivi type `k_sol_decode_attempts` ou `k_sol_replay_decode_ledger` dans `kb_lib/src/db/schema.rs` ;
+- stocker `transaction_id`, `signature`, `instruction_id` lorsque disponible, `program_id`, `protocol_name`, `decoder_code`, `decoder_version`, `decode_status`, `certainty`, `event_count`, hash d’entrée, reason/error et timestamps ;
+- ajouter les entities/dtos/queries associées ;
+- mettre à jour les re-exports dans `kb_lib/src/db.rs`, puis `kb_lib/src/lib.rs` si nécessaire ;
+- intégrer le ledger dans `local_pipeline_replay.rs` sans changer la sémantique trade/candle ;
+- ajouter une option `force` pour ignorer le ledger ;
+- ne pas skipper automatiquement les transactions multi-token, multi-pool, multi-event ou marquées `partial` / `ambiguous` ;
+- retraiter les lignes concernées lorsqu’un decoder change de version logique ;
+- ajouter les diagnostics SQL permettant de mesurer skipped/replayed/ambiguous/forced.
 
-### 6.076. Version `0.7.44` — Autres DEX effectifs : Orca, FluxBeam, DexLab, metaDAO, Printr
-Objectif : consolider les DEX non-Raydium/Meteora et intégrer les DEX récemment observés comme candidats vérifiables.
+### 6.077. Version `0.7.45` — `meteora_dlmm` séparé
+Objectif : consolider `meteora_dlmm` comme DEX effectif séparé, avec corpus dédié et events utiles au trading.
 
 À faire :
 
-- revalider `orca_whirlpools` sur corpus dédié : create_pool, swap, liquidité, positions, mints et montants fiables ;
-- traiter explicitement les swaps Orca partiels comme non-actionnables tant que les montants ne sont pas reconstruits ;
-- constituer des corpus locaux pour `fluxbeam` et `dexlab` ;
-- vérifier les `program_id`, comptes, préfixes `data_json` et familles d’instructions utiles ;
-- vérifier `metaDAO` et `Printr` par corpus on-chain local avant toute promotion ;
-- ne pas confondre source externe de découverte et preuve on-chain ;
-- marquer explicitement les variantes partiellement supportées ou heuristiques.
+- vérifier le ou les `program_id` par corpus local, pas seulement par constante ;
+- consolider swaps exploitables, add/remove liquidity, positions, lifecycle et audits restants ;
+- matérialiser uniquement les events prouvés dans les tables dédiées ;
+- conserver tout event incomplet en `instruction_audit` ou non-actionnable ;
+- ajouter les compteurs diagnostics par event kind.
 
-### 6.077. Version `0.7.45` — Couverture événementielle DEX : swap, liquidité, fees, rewards, admin, burns
-Objectif : s’assurer que chaque DEX effectif expose les événements utiles au scoring et au risque sans polluer les trades/candles.
+### 6.078. Version `0.7.46` — `meteora_damm_v1` séparé
+Objectif : reprendre `meteora_damm_v1` sans le mélanger à DAMM v2, DBC ou DLMM.
+
+À faire :
+
+- valider les swaps exploitables et les cas sans amounts ;
+- rechercher create/init pool, liquidity, fee/admin/config et autres events utiles ;
+- maintenir la règle : pas de trade/candle si base/quote amount ou prix ne sont pas fiables ;
+- produire un corpus SQL minimal pour chaque event promu.
+
+### 6.079. Version `0.7.47` — `meteora_damm_v2` séparé
+Objectif : reprendre `meteora_damm_v2` comme DEX effectif séparé, avec traitement spécifique des nombreux `instruction_audit`.
+
+À faire :
+
+- vérifier `cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG` dans le corpus local avant de le marquer `verified_by_corpus` ;
+- consolider `create_pool`, swaps exploitables, configs dynamiques, fees/admin et events lifecycle ;
+- conserver les swaps sans payload montant/prix fiables comme `non_actionable_trade` ;
+- ne promouvoir aucun event depuis `instruction_audit` sans signature de validation.
+
+### 6.080. Version `0.7.48` — `meteora_dbc` séparé
+Objectif : séparer proprement bonding/launch, swap effectif, migration et attribution d’origine dans `meteora_dbc`.
+
+À faire :
+
+- distinguer les events de bonding curve / launch des events de DEX effectif ;
+- vérifier swaps exploitables, migration, lifecycle, mint/burn éventuels et launch attribution ;
+- éviter toute candle artificielle sur events de bonding/launch non pricés ;
+- documenter les signatures/corpus avant toute promotion.
+
+### 6.081. Version `0.7.49` — `orca_whirlpools` séparé
+Objectif : revalider Orca Whirlpools par corpus dédié avant toute promotion au même niveau que Raydium/Meteora.
+
+À faire :
+
+- revalider create_pool, swap, liquidité, positions, mints et montants fiables ;
+- traiter les swaps Orca partiels comme non-actionnables tant que les montants ne sont pas reconstruits ;
+- matérialiser uniquement les events prouvés ;
+- ajouter des diagnostics par event kind.
+
+### 6.082. Version `0.7.50` — `fluxbeam` séparé
+Objectif : vérifier FluxBeam comme DEX effectif distinct.
+
+À faire :
+
+- constituer un corpus local ;
+- vérifier `program_id`, comptes, préfixes `data_json` et familles d’instructions utiles ;
+- valider swaps, pools, liquidity et events non-trade prouvés ;
+- marquer explicitement les parties heuristiques ou non-actionnables.
+
+### 6.083. Version `0.7.51` — `dexlab` séparé
+Objectif : vérifier DexLab comme DEX effectif distinct, sans le confondre avec OpenBook ou une autre couche de marché.
+
+À faire :
+
+- constituer un corpus local ;
+- vérifier `program_id`, comptes, préfixes `data_json` et familles d’instructions utiles ;
+- valider swaps, pools et éventuels liens de market/pool ;
+- conserver les cas partiels en audit.
+
+### 6.084. Version `0.7.52` — `metaDAO` candidat DEX
+Objectif : rechercher et vérifier metaDAO sans inventer de `program_id`.
+
+À faire :
+
+- rechercher les signatures/corpus via Demo3, DEX Screener ou sources externes de découverte ;
+- ne considérer une source externe que comme indice ;
+- promouvoir uniquement après preuve on-chain locale ;
+- documenter chaque programme, event et limite.
+
+### 6.085. Version `0.7.53` — `printr` candidat DEX
+Objectif : rechercher et vérifier Printr sans inventer de `program_id`.
+
+À faire :
+
+- rechercher les signatures/corpus via Demo3, DEX Screener ou sources externes de découverte ;
+- ne considérer une source externe que comme indice ;
+- promouvoir uniquement après preuve on-chain locale ;
+- documenter chaque programme, event et limite.
+
+### 6.086. Version `0.7.54` — Couverture événementielle DEX consolidée
+Objectif : s’assurer que chaque DEX effectif supporté expose les événements utiles au scoring et au risque sans polluer les trades/candles.
 
 À faire :
 
@@ -1060,8 +1154,8 @@ Objectif : s’assurer que chaque DEX effectif expose les événements utiles au
 - ajouter des compteurs et samples diagnostics par DEX et par type d’événement ;
 - conserver l’invariant : aucun fee/reward/admin/liquidity/lifecycle/burn non price-action ne produit de trade, metric ou candle.
 
-### 6.078. Version `0.7.46` — `kb_demo_app` Demo4 : DEX Screener et sources externes de découverte
-Objectif : utiliser des sources externes comme aides à la découverte de corpus sans les traiter comme vérité métier, après la première consolidation Raydium.
+### 6.087. Version `0.7.55` — `kb_demo_app` Demo4 : DEX Screener et sources externes de découverte
+Objectif : utiliser des sources externes comme aides à la découverte de corpus sans les traiter comme vérité métier.
 
 À faire :
 
@@ -1072,7 +1166,7 @@ Objectif : utiliser des sources externes comme aides à la découverte de corpus
 - permettre de copier les signatures/adresses candidates pour backfill ;
 - ne jamais promouvoir automatiquement un DEX, un `program_id` ou une paire sur la seule base d’une réponse externe.
 
-### 6.079. Version `0.7.47` — Démos spécialisées launch surfaces après DEX effectifs
+### 6.088. Version `0.7.56` — Démos spécialisées launch surfaces après DEX effectifs
 Objectif : préparer des vues spécialisées pour les launch surfaces, mais seulement après stabilisation des DEX effectifs.
 
 À faire plus tard :
@@ -1083,7 +1177,7 @@ Objectif : préparer des vues spécialisées pour les launch surfaces, mais seul
 - exposer les origins dans les diagnostics et l’UI d’inspection ;
 - maintenir l’interdiction de faux program ids, faux trades et fausses candles.
 
-### 6.080. Version `0.7.48` — `kb_demo_app` Demo10 : watcher WebSocket live DEX
+### 6.089. Version `0.7.57` — `kb_demo_app` Demo10 : watcher WebSocket live DEX
 Objectif : valider le passage du replay/backfill vers l’observation temps réel contrôlée.
 
 À faire :
@@ -1097,7 +1191,7 @@ Objectif : valider le passage du replay/backfill vers l’observation temps rée
 - afficher les compteurs live, erreurs, subscriptions actives et derniers objets persistés ;
 - prévoir un arrêt propre avec unsubscribe avant close.
 
-### 6.081. Version `0.7.49` — Validation DEX v1 consolidée
+### 6.090. Version `0.7.58` — Validation DEX v1 consolidée
 Objectif : rejouer tous les DEX effectifs supportés et valider les invariants du pipeline complet avant de revenir aux launch surfaces ou à l’analyse `0.8.x`.
 
 À faire :
@@ -1110,7 +1204,7 @@ Objectif : rejouer tous les DEX effectifs supportés et valider les invariants d
 - 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.082. Version `0.8.x` — Analyse et filtrage
+### 6.091. Version `0.8.x` — Analyse et filtrage
 Objectif : transformer les événements bruts en signaux exploitables.
 
 À faire :
@@ -1282,29 +1376,33 @@ Le projet doit maintenir au minimum :
 
 ## 12. Priorité immédiate
 
-La priorité immédiate après `0.7.42` est `0.7.43_meteora_effective_surfaces`. La consolidation Raydium est considérée comme close côté Raydium : `raydium_cpmm`, `raydium_clmm` et `raydium_amm_v4` sont traités comme surfaces Raydium effectives, avec les limites explicitement documentées ci-dessous.
+La priorité immédiate après le point de reprise `0.7.43-E5C` n’est plus de terminer Meteora en un seul bloc. Le lot Meteora groupé a montré ses limites : les events, les audits, les surfaces bonding/launch et les variantes de DEX doivent être traités séparément.
 
-Préconditions validées avant `0.7.43` :
+Préconditions considérées acquises avant cette reprise :
 
-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é ;
+1. validation `0.7.36` acquise : Meteora consolidé au niveau baseline, 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é, registre local `WSOL`/`USDC`/`USDT`/`JUP`/`RAY`/`BONK` disponible ;
 4. `0.7.39` acquis : matrice DEX-first, suppression de l’alias `raydium`, `metaDAO` et `Printr` en `to_verify`, aucun `program_id` fictif ;
 5. `0.7.40` acquis : `Demo3` découvre on-chain des signatures, mints, deltas et comptes candidats ; Demo Pipeline 2 peut backfiller une signature précise ;
 6. `0.7.41` acquis : `raydium_amm_v4.swap` décode les inner instructions `675kPX...`, produit des trades/candles lorsque les montants sont exploitables, et conserve les transactions failed sans matérialisation marché ;
-7. `0.7.42` acquis côté Raydium : CLMM/CPMM couvrent swaps et premiers non-swaps prouvés ; AMM v4 couvre les swaps et conserve les non-swaps legacy en audit ; les non-trade events utiles prouvés alimentent leurs tables dédiées ;
-8. la dette Orca Whirlpools observée dans le corpus local est reportée à `0.7.44` et ne doit pas être mélangée à la clôture Raydium.
+7. `0.7.42` acquis côté Raydium : CLMM/CPMM couvrent swaps et premiers non-swaps prouvés ; AMM v4 couvre les swaps et conserve les non-swaps legacy en audit ;
+8. `0.7.43-E5C` est le point de reprise documentaire et technique, avec Clippy `kb_lib` validé localement après correction.
 
 Ordre de travail recommandé pour la suite :
 
-1. `0.7.43` : consolider Meteora effectif (`meteora_dlmm`, `meteora_damm_v1`, `meteora_damm_v2`, `meteora_dbc`) avec la même approche corpus-first ;
-2. `0.7.44` : revalider Orca Whirlpools, puis FluxBeam, DexLab, metaDAO et Printr ;
-3. `0.7.45` : établir une couverture transversale des événements DEX utiles au scoring : swaps, liquidités, lifecycle, fees, rewards, admin/config, burns/mints ;
-4. `0.7.46` : ajouter Demo4 pour les sources externes de découverte sans promotion automatique ;
-5. `0.7.47` : ajouter des démos spécialisées launch surfaces après DEX effectifs ;
-6. `0.7.48` : ajouter Demo10 pour le watcher WebSocket live DEX ;
-7. `0.7.49` : validation DEX v1 consolidée ;
-8. passer ensuite à l’analyse `0.8.x`, puis à la couche wallet.
+1. `0.7.44` : ledger de décodage/replay et skip sûr ;
+2. `0.7.45` : `meteora_dlmm` ;
+3. `0.7.46` : `meteora_damm_v1` ;
+4. `0.7.47` : `meteora_damm_v2` ;
+5. `0.7.48` : `meteora_dbc` ;
+6. `0.7.49` : `orca_whirlpools` ;
+7. `0.7.50` : `fluxbeam` ;
+8. `0.7.51` : `dexlab` ;
+9. `0.7.52` : `metaDAO` candidat DEX ;
+10. `0.7.53` : `printr` candidat DEX ;
+11. `0.7.54` : couverture événementielle DEX consolidée ;
+12. `0.7.55+` : sources externes de découverte, launch surfaces, watcher live et validation consolidée.
 
 Garde-fous constants :
 
@@ -1314,4 +1412,5 @@ Garde-fous constants :
 - pas de promotion d’un DEX sans corpus transactionnel ;
 - pas de logique métier DEX profonde dans `kb_demo_app` ;
 - pas de metadata manquante bloquante ;
-- pas de refactor réseau inutile tant que les clients HTTP/WS existants suffisent.
+- pas de refactor réseau inutile tant que les clients HTTP/WS existants suffisent ;
+- pas de skip replay sur transaction/instruction ambiguë, multi-token ou multi-event sans preuve ledger.