0.7.38-B

ROADMAP.md

@@ -942,195 +942,182 @@ Réalisé :
 - 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.
+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 une priorité DEX-first : consolider les DEX effectifs de swap avant de revenir aux 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.
+### 6.071. Version `0.7.39` — Réorientation DEX-first et inventaire des DEX effectifs
+Objectif : remplacer la priorité précédemment donnée aux launch surfaces par une consolidation des vrais DEX sur lesquels les swaps et événements de marché sont exécutés.
 
 À faire :
 
-- ajouter ou stabiliser `raydium_launchlab` / `raydium_launchpad`,
-- ajouter `letsbonk` / `bonk_fun` comme surface d’origine rattachée à LaunchLab/Raydium si le corpus le prouve,
-- ajouter `boop_fun` comme surface d’origine et suivre ses migrations,
-- consolider `moonshot` / `moonit` avec corpus au lieu de simples heuristiques faibles,
-- consolider `bags` comme surface d’origine, notamment lorsque le token passe par Meteora DBC/DAMM,
-- ajouter `believe` comme surface d’origine associée à Meteora DBC si les comptes/authorities le prouvent,
-- distinguer `launch_origin`, `pool_origin`, `dex_effective` et `migration_target`,
-- 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.
+- modifier la matrice DEX pour distinguer explicitement : `dex_effective`, `aggregator/router`, `launch_surface`, `to_verify` ;
+- vérifier les DEX de swap principaux déjà connus : `pump_swap`, `raydium_cpmm`, `raydium_clmm`, `raydium_amm_v4`, `raydium_stable_swap`, `meteora_dlmm`, `meteora_damm_v1`, `meteora_damm_v2`, `meteora_dbc`, `orca_whirlpools`, `fluxbeam`, `dexlab` ;
+- ajouter `metaDAO` et `Printr` comme entrées `to_verify` dans la matrice, sans `program_id` tant qu’ils ne sont pas prouvés ;
+- rechercher ou confirmer les `program_id` inconnus depuis les corpus locaux, les protocol candidates, DEX Screener, les explorateurs et les transactions résolues ;
+- ne promouvoir aucune entrée vers `partial` ou `supported` sans corpus transactionnel vérifiable ;
+- conserver les invariants `0.7.36` à `0.7.38` : aucun faux trade, aucune fausse candle, aucun événement non price-action transformé en trade/candle.
 
-### 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.
+Résultat attendu : une matrice DEX réorientée vers les surfaces de swap effectives, avec les launch surfaces explicitement reportées.
+
+### 6.072. Version `0.7.40` — Raydium effectif : AMM v4, Stable Swap, CPMM, CLMM
+Objectif : consolider la famille Raydium côté DEX effectifs avant les launch surfaces Raydium.
 
 À faire :
 
-- vérifier le ou les programmes Heaven réellement observés sur mainnet,
-- constituer un corpus local de mints, pools et swaps Heaven,
-- séparer les événements de lancement des événements de swap,
-- ajouter les decoded events, launch origins, pool/pair/listing et trade events seulement lorsque les instructions sont prouvées,
-- 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é.
+- vérifier `raydium_cpmm` et `raydium_clmm` comme références déjà supportées ;
+- rechercher des pools réellement rattachés au programme AMM v4 `675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8` ;
+- vérifier l’usage réel de `raydium_stable_swap` et du programme `5quBtoiQqxF9Jv6KYKctB59NT3gtJD2Y65kdnB1Uev3h` ;
+- distinguer clairement `raydium_amm_v4`, `raydium_cpmm`, `raydium_clmm`, `raydium_router`, `raydium_stable_swap`, `raydium_launchlab` et `raydium_launchpad` ;
+- identifier les instructions swap, initialize/create pool, liquidité, fees/admin réellement observées ;
+- ajouter des requêtes diagnostics par `program_id`, `accounts_json`, `data_json`, signature et pool address ;
+- documenter les limites si le corpus Raydium legacy reste faible.
 
-### 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.
+### 6.073. Version `0.7.41` — Meteora effectif : DLMM, DAMM v1/v2, DBC
+Objectif : compléter la famille Meteora en couvrant les événements réellement utiles au DEX effectif.
 
 À faire :
 
-- constituer des corpus locaux pour `Orca Whirlpools`, `FluxBeam` et `DexLab`,
-- vérifier les `program_id`, comptes, préfixes `data_json` et familles d’instructions utiles,
-- stabiliser les événements `create_pool`, `swap` et liquidité réellement observés,
-- alimenter les mêmes tables métier et diagnostics que les connecteurs déjà validés,
-- 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.
+- 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.
 
-### 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.
+### 6.074. Version `0.7.42` — Autres DEX effectifs : Orca, FluxBeam, DexLab, metaDAO, Printr
+Objectif : consolider les DEX non-Ray­dium/Meteora et intégrer les DEX récemment observés comme candidats vérifiables.
 
 À faire :
 
-- rechercher des pools réellement rattachés au programme `675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8`,
-- constituer un petit corpus local de signatures/pools AMM v4 fiables,
-- vérifier que les adresses issues d’explorateurs ne sont pas seulement catégorisées globalement comme `Raydium`,
-- ajouter des requêtes de diagnostic par `program_id`, `accounts_json` et préfixe `data_json`,
-- valider `initialize2` et identifier les instructions de swap AMM v4 à supporter si elles apparaissent dans le corpus,
-- 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.
+- constituer des corpus locaux pour `orca_whirlpools`, `fluxbeam` et `dexlab` ;
+- vérifier les `program_id`, comptes, préfixes `data_json` et familles d’instructions utiles ;
+- stabiliser les événements `create_pool`, `swap`, liquidité, positions et admin lorsque prouvés ;
+- ajouter `metaDAO` et `Printr` en `to_verify` avec recherche explicite de program ids, signatures, comptes et pools ;
+- ne pas confondre source externe de découverte et preuve on-chain ;
+- marquer explicitement les variantes partiellement supportées ou heuristiques.
 
-### 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.
+### 6.075. Version `0.7.43` — 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.
 
 À faire :
 
-- rejouer des bases neuves couvrant tous les connecteurs DEX supportés,
-- vérifier les compteurs globaux et par DEX : decoded events, trade events, liquidity events, lifecycle events, fee events, reward events, admin events, candles et analytic signals,
-- contrôler que chaque famille d’événements alimente uniquement les tables métier prévues,
-- vérifier les diagnostics bloquants et les samples d’anomalie,
-- documenter les corpus utilisés pour chaque DEX/surface,
-- conserver une matrice de support par DEX, variante, instruction et type d’événement,
+- vérifier par DEX la couverture `swap` / `tradeCandidate` / `candleCandidate` ;
+- vérifier par DEX la couverture liquidité : add/remove/increase/decrease/open/close position ;
+- vérifier par DEX les événements lifecycle : create/init/migrate/pause/resume/close ;
+- vérifier par DEX les fees, rewards, creator fees, protocol fees et admin/config ;
+- vérifier les burns/mints utiles au suivi token/pool sans les transformer en price-action ;
+- matérialiser uniquement les événements prouvés dans les tables dédiées ;
+- 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.076. Version `0.7.44` — `kb_demo_app` Demo3 : recherche de paires/pools par DEX ou program id
+Objectif : ajouter une fenêtre ou vue de démonstration dédiée à la constitution de corpus par DEX.
+
+À faire :
+
+- ajouter une `Demo3` dans `kb_demo_app` ;
+- permettre la saisie d’un `program_id`, d’un `dex_code`, d’un `pool_address`, d’un `pair_id` ou d’un token mint ;
+- rechercher dans la base locale les transactions, instructions, decoded events, pools, paires, listings et candidates associés ;
+- fournir des presets pour les programmes à vérifier, par exemple `675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8`, `5quBtoiQqxF9Jv6KYKctB59NT3gtJD2Y65kdnB1Uev3h`, `cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG` ;
+- afficher les signatures candidates à backfill/replay ;
+- garder `kb_demo_app` comme façade UI : toute requête métier doit rester dans `kb_lib`.
+
+### 6.077. Version `0.7.45` — `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 :
+
+- ajouter une `Demo4` pour interroger DEX Screener ou une source équivalente ;
+- rechercher des paires par token mint, chain, DEX name, pool address ou program id lorsque disponible ;
+- comparer les résultats externes avec les objets locaux : tokens, pools, pairs, listings, decoded events ;
+- afficher les écarts : paire externe absente localement, pool local sans source externe, DEX label ambigu, program id manquant ;
+- 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.078. Version `0.7.46` — 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 :
+
+- ajouter des démos dédiées à `pump_fun`, `raydium_launchpad` / `raydium_launchlab`, `believe`, `bags`, `moonshot` / `moonit`, `boop_fun`, `letsbonk` / `bonk_fun`, `heaven` ;
+- distinguer `launch_origin`, `pool_origin`, `dex_effective` et `migration_target` ;
+- rattacher les launch origins aux pools et paires uniquement lorsque les comptes permettent un matching fiable ;
+- exposer les origins dans les diagnostics et l’UI d’inspection ;
+- maintenir l’interdiction de faux program ids, faux trades et fausses candles.
+
+### 6.079. Version `0.7.47` — `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 :
+
+- ajouter une démo temps réel type `Demo10` avec bouton `start` / `stop` ;
+- permettre de sélectionner les endpoints WS/HTTP et les DEX/program ids à souscrire ;
+- lancer le client WebSocket existant sans refactorer inutilement `ws_client.rs` / `ws_manager.rs` ;
+- effectuer les `logsSubscribe`, `programSubscribe` ou `accountSubscribe` nécessaires selon le DEX ;
+- détecter en temps réel mints, swaps, liquidités et autres événements utiles ;
+- écrire en base via le pipeline existant : observations, transactions résolues, decoded events, pools/pairs/listings, trade events, candles et non-trade events ;
+- afficher les compteurs live, erreurs, subscriptions actives et derniers objets persistés ;
+- prévoir un arrêt propre avec unsubscribe avant close.
+
+### 6.080. Version `0.7.48` — 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 :
+
+- rejouer des bases neuves couvrant tous les connecteurs DEX supportés ;
+- vérifier les compteurs globaux et par DEX : decoded events, trade events, liquidity events, lifecycle events, fee events, reward events, admin events, burns/mints utiles, candles et analytic signals ;
+- contrôler que chaque famille d’événements alimente uniquement les tables métier prévues ;
+- vérifier les diagnostics bloquants et les samples d’anomalie ;
+- documenter les corpus utilisés pour chaque DEX/surface ;
+- 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.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 :
-
-- afficher les signaux analytiques par bucket au-dessus ou autour des candles,
-- ajouter des marqueurs pour `first_trade_seen`, `trade_burst_60s`, `buy_sell_imbalance_60s`, `price_jump_up_60s`, `price_jump_down_60s` et `volume_spike_60s`,
-- permettre le filtrage par type de signal et par sévérité,
-- 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.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 :
-
-- ajouter une fiche token avec mint, programme token, metadata, pools, paires et historique de découverte,
-- ajouter une fiche paire avec base/quote, DEX, pool, métriques, candles, signaux et derniers trades,
-- ajouter une fiche pool avec composition, vaults, origine, première signature vue, programme DEX et statut de décodage,
-- relier dans l’UI les launch origins, pool origins, wallets observés, holdings observés, événements de liquidité, lifecycle, fees, rewards, admin, candles et analytic signals,
-- 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.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 :
-
-- consolider les vues ajoutées dans `kb_demo_app`,
-- améliorer la navigation, les filtres et la pagination,
-- ajouter les derniers raffinements de confort et de lisibilité,
-- 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.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 :
-
-- Pump.fun,
-- PumpSwap,
-- Raydium CPMM,
-- Raydium CLMM,
-- Raydium LaunchLab / Launchpad,
-- Raydium AMM v4 legacy,
-- Meteora DBC,
-- Meteora DAMM v1,
-- Meteora DAMM v2,
-- Meteora DLMM,
-- Orca Whirlpools,
-- FluxBeam,
-- DexLab,
-- Bags,
-- LetsBonk / Bonk.fun,
-- Boop.fun,
-- Moonshot / Moonit,
-- Believe,
-- Heaven.
-
-Hors périmètre immédiat :
-
-- `zora_solana`, tant qu’aucun programme Solana pertinent et exploitable n’est prouvé.
-
-Résultat attendu :
-
-- identification fiable des programmes et versions,
-- résolution des signatures pertinentes,
-- décodage des transactions utiles,
-- conservation des transactions inconnues ou candidates sans perte d’information,
-- création d’objets métier riches pour tokens, pools, paires, listings, participants, origins et holdings observés,
-- distinction claire entre première source de mint, launch origin, pool origin, DEX effectif et migration target,
-- enrichissement metadata des tokens découverts,
-- séparation stricte entre événements candle/trade et événements utiles seulement à l’analyse,
-- matérialisation progressive des événements non-trade dans des tables métier dédiées,
-- 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.080. Version `0.8.x` — Analyse et filtrage
+### 6.081. Version `0.8.x` — Analyse et filtrage
 Objectif : transformer les événements bruts en signaux exploitables.
 
 À faire :
 
-- agrégation des métriques,
-- règles de filtrage,
-- exclusions des tokens non tradables,
-- statistiques de comportement,
-- premiers patterns,
-- enrichissement des signaux analytiques préparés en fin de `0.7.x`,
-- indicateurs graphiques optionnels comme Ichimoku / Kumo,
-- outils de sélection manuelle de points ABC et projection d’un point D selon des règles temps/prix explicites,
+- agrégation des métriques ;
+- règles de filtrage ;
+- exclusions des tokens non tradables ;
+- statistiques de comportement ;
+- premiers patterns ;
+- enrichissement des signaux analytiques préparés en fin de `0.7.x` ;
+- indicateurs graphiques optionnels comme Ichimoku / Kumo ;
+- 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.081. Version `1.x.y` — Wallets et swap préparatoire
-Objectif : préparer la couche d’action.
+### 6.082. Version `1.x.y` — Wallets, comptes et transferts
+Objectif : préparer la couche d’action sans encore brancher l’achat/vente automatique.
 
 À faire :
 
-- gestion du répertoire wallets,
-- chargement sécurisé des keypairs,
-- abstraction wallet,
-- préparation d’ordres et de swaps,
-- simulation et garde-fous.
+- gestion du répertoire wallets ;
+- création de wallet/keypair ;
+- chargement sécurisé des keypairs ;
+- inspection des informations wallet ;
+- transfert de fonds depuis cette wallet vers un autre account ;
+- garde-fous d’affichage, confirmation et simulation ;
+- préparation d’ordres et de swaps seulement après stabilisation des transferts de base.
 
-### 6.082. Version `2.x.y` — Trading semi-automatisé
+### 6.083. Version `2.x.y` — Trading semi-automatisé
 Objectif : brancher l’analyse à l’action tout en gardant des garde-fous explicites.
 
 À faire :
 
-- scénarios d’achat/vente,
-- règles d’entrée/sortie,
-- limites de risque,
-- confirmations explicites ou semi-automatiques,
+- scénarios d’achat/vente ;
+- règles d’entrée/sortie ;
+- limites de risque ;
+- confirmations explicites ou semi-automatiques ;
 - journaux d’exécution.
 
-### 6.083. Version `3.x.y` — Yellowstone gRPC
+### 6.084. Version `3.x.y` — Yellowstone gRPC
 Objectif : ajouter le connecteur gRPC dédié.
 
 À faire :
 
-- `GrpcClient` basé sur `yellowstone-grpc-client`,
-- adaptation du pipeline d’événements,
-- coexistence HTTP / WS / gRPC,
+- `GrpcClient` basé sur `yellowstone-grpc-client` ;
+- adaptation du pipeline d’événements ;
+- coexistence HTTP / WS / gRPC ;
 - politique de répartition par source.
 
 ## 7. Organisation des modules ciblés
@@ -1186,6 +1173,9 @@ Responsabilités cibles :
 - réception des événements venant de `kb_lib`,
 - fenêtres de démonstration / diagnostic isolées,
 - inspection du pipeline persisté,
+- `Demo3` pour la recherche de paires/pools par DEX ou `program_id`,
+- `Demo4` pour les requêtes DEX Screener et la comparaison avec la base locale,
+- `Demo10` pour le watcher WebSocket live DEX avec start/stop,
 - affichage candles et futurs overlays analytiques.
 
 `kb_demo_app` ne doit pas contenir de logique métier DEX profonde.
@@ -1253,7 +1243,7 @@ Le projet doit maintenir au minimum :
 
 ## 12. Priorité immédiate
 
-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`.
+La priorité immédiate après `0.7.38-B` est `0.7.39_dex_first_effective_swap_surfaces`. La phase launch surfaces est volontairement reportée : elle sera reprise après consolidation des DEX effectifs et des outils de constitution de corpus.
 
 Préconditions validées avant `0.7.39` :
 
@@ -1261,13 +1251,28 @@ Préconditions validées avant `0.7.39` :
 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`.
+5. les diagnostics locaux restent l’outil de vérité pour décider si un DEX peut passer de `planned` ou `to_verify` à `partial` ou `supported`.
 
-Ordre de travail recommandé pour `0.7.39` :
+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.
+1. scanner `dex_support_matrix.rs`, `dex.rs`, `dex/*.rs`, `dex_decode.rs`, `dex_detect.rs`, `trade_aggregation.rs`, `local_pipeline_validation.rs`, `local_pipeline_diagnostics.rs`, `transaction_classification.rs` et `protocol_candidate_recording.rs` ;
+2. produire un état des DEX effectifs déjà couverts, partiels, à vérifier ou absents ;
+3. ajouter `metaDAO` et `Printr` comme DEX `to_verify` sans `program_id` inventé ;
+4. vérifier les DEX principaux de swap : PumpSwap, Raydium CPMM/CLMM/AMM v4/Stable Swap, Meteora DLMM/DAMM/DBC, Orca Whirlpools, FluxBeam, DexLab ;
+5. rechercher des corpus par `program_id`, pair/pool address, signature et token mint ;
+6. ajouter `Demo3` pour rechercher localement les paires/pools/signatures par DEX ou `program_id` ;
+7. ajouter `Demo4` pour interroger DEX Screener ou sources externes et comparer avec la base locale sans promotion automatique ;
+8. compléter la couverture par DEX des swaps, liquidités, lifecycle, fees, rewards, admin/config, burns/mints utiles ;
+9. ajouter ensuite `Demo10` pour le watcher WebSocket live DEX avec start/stop, subscribe/unsubscribe et écriture en base via le pipeline existant ;
+10. reprendre seulement après cela les launch surfaces : Raydium LaunchLab/Launchpad, LetsBonk/Bonk.fun, Bags, Moonshot/Moonit, Boop.fun, Believe, Heaven ;
+11. passer ensuite à la couche wallet : création de wallet/keypair, inspection et transfert de fonds vers un autre account.
+
+Garde-fous constants :
+
+- pas de faux trade ;
+- pas de fausse candle ;
+- pas de `program_id` fictif ;
+- 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.