From 3f6d2e9f7f47c12e6897d23a16fb3728b5ad8dae Mon Sep 17 00:00:00 2001 From: SinuS Von SifriduS Date: Thu, 14 May 2026 17:44:01 +0200 Subject: [PATCH] 0.7.38 --- CHANGELOG.md | 1 + Cargo.toml | 2 +- README.md | 24 +- ROADMAP.md | 134 +++++----- kb_demo_app/frontend/demo_pipeline2.html | 3 +- ...Pipeline2LocalPipelineDiagnosticSummary.ts | 41 +++ ...oPipeline2LocalPipelineValidationReport.ts | 44 ++++ ...e2LocalTokenMetadataGapDiagnosticSample.ts | 54 ++++ kb_demo_app/package.json | 2 +- kb_demo_app/src/demo_pipeline2.rs | 70 +++++- kb_demo_app/tauri.conf.json | 2 +- kb_lib/src/constants.rs | 15 ++ kb_lib/src/db.rs | 2 + kb_lib/src/db/dtos.rs | 2 + .../src/db/dtos/local_pipeline_diagnostics.rs | 48 ++++ kb_lib/src/db/queries.rs | 1 + .../db/queries/local_pipeline_diagnostics.rs | 98 ++++++++ kb_lib/src/lib.rs | 14 ++ kb_lib/src/local_pipeline_diagnostics.rs | 11 + kb_lib/src/local_pipeline_validation.rs | 57 ++++- kb_lib/src/token_metadata.rs | 238 +++++++++++++++++- 21 files changed, 775 insertions(+), 88 deletions(-) create mode 100644 kb_demo_app/frontend/ts/bindings/DemoPipeline2LocalTokenMetadataGapDiagnosticSample.ts diff --git a/CHANGELOG.md b/CHANGELOG.md index 245ca2b..05c2807 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -68,3 +68,4 @@ 0.7.35 - Ajout du profil `0.7.35_non_trade_fee_reward_admin`, matérialisation des événements non-trade fees/rewards/admin, raccordement aux diagnostics locaux et maintien strict de l’invariant : aucun fee/reward/admin ne peut produire de trade, metric ou candle. 0.7.36 - Consolidation de la famille Meteora : corpus mixte `meteora_damm_v1`, `meteora_damm_v2`, `meteora_dbc` et `meteora_dlmm`, correction des discriminants DAMM v2 / DBC, validation du profil `0.7.36_meteora_family_consolidation`, et reclassement explicite des swaps DAMM v2 / DBC sans payload montant/prix en `non_actionable_trade` afin d’éviter tout trade/candle artificiel. 0.7.37 - Première tranche metadata/catalog : ajout du profil `0.7.37_token_metadata_catalog_enrichment`, exposition des compteurs metadata dans diagnostics/validation et raccordement UI Demo Pipeline 2 sans rendre les metadata manquantes bloquantes. +0.7.38 - Priorisation des metadata manquantes : ajout du profil `0.7.38_token_metadata_gap_prioritization`, samples `tokenMetadataGapSamples`, priorités tradable/quote/catalog, raccordement UI Demo Pipeline 2 et maintien du caractère non bloquant des metadata incomplètes. diff --git a/Cargo.toml b/Cargo.toml index dc37b69..0b9061b 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -8,7 +8,7 @@ members = [ ] [workspace.package] -version = "0.7.37" +version = "0.7.38" edition = "2024" license = "MIT" repository = "https://git.sasedev.com/Sasedev/khadhroony-bobobot" diff --git a/README.md b/README.md index 9ae2a52..cc506d4 100644 --- a/README.md +++ b/README.md @@ -4,7 +4,7 @@ `khadhroony-bobobot` est un workspace Rust destiné à la détection, au décodage, à l’analyse et, à terme, au trading semi-automatisé de tokens Solana. -Le README précédent décrivait surtout l’état `0.3.1`. Ce fichier reflète l’état de reprise autour de `0.7.37-A` : le socle transport HTTP/WS, la résolution transactionnelle, le modèle SQLite, plusieurs connecteurs DEX, les candles, les signaux analytiques, la validation locale et une matrice DEX commune existent déjà. +Le README précédent décrivait surtout l’état `0.3.1`. Ce fichier reflète l’état de clôture `0.7.38` et la reprise prévue en `0.7.39` : le socle transport HTTP/WS, la résolution transactionnelle, le modèle SQLite, plusieurs connecteurs DEX, les candles, les signaux analytiques, la validation locale, la matrice DEX commune et les diagnostics de metadata prioritaires existent déjà. ## 1. Objectif @@ -31,7 +31,7 @@ Le workspace contient deux crates principales. La logique métier doit rester dans `kb_lib`. `kb_demo_app` doit rester une façade UI/Tauri et ne doit pas récupérer de logique Solana ou DEX profonde. -## 3. État actuel autour de `0.7.37-A` +## 3. État actuel après `0.7.38` ### 3.1. Socle stabilisé à ne pas refactorer maintenant @@ -232,20 +232,18 @@ Les tests peuvent rester plus souples lorsque cela clarifie le test. ## 8. Priorité immédiate -La phase actuelle est `0.7.37_token_metadata_catalog_enrichment`. +La phase `0.7.38_token_metadata_gap_prioritization` est considérée comme close. La clôture `0.7.38-B` ajoute un registre local minimal de tokens connus : `WSOL`, `USDC`, `USDT`, `JUP`, `RAY`, `BONK`. `USDC` et `USDT` restent les seuls ajouts stable-quote ; `JUP`, `RAY` et `BONK` enrichissent seulement l’affichage metadata sans changer la classification de quote. La prochaine étape est `0.7.39_launch_surfaces`. -Objectif : rendre le catalogue local exploitable visuellement et analytiquement sans toucher aux invariants de décodage/trade validés en `0.7.36`. +Préconditions validées avant de reprendre le codage : -À faire en priorité : +1. les invariants locaux restent sains : `blockingIssueCount = 0`, `actionableMissingTradeEventCount = 0`, `missingTradeEventCount = 0` ; +2. les profils `0.7.36_meteora_family_consolidation`, `0.7.37_token_metadata_catalog_enrichment` et `0.7.38_token_metadata_gap_prioritization` existent et passent sur le corpus local fourni ; +3. les metadata manquantes restent non bloquantes ; +4. les `tokenMetadataGapSamples` exposent maintenant une liste de travail priorisée ; +5. le registre local minimal contient `SOL`, `WSOL`, `USDC` et `USDT` ; +6. le backfill metadata peut traiter les tokens déjà présents en base et rafraîchir les `pair_symbol` sans recréer les objets de marché. -1. ajouter ou compléter un registre local des mints connus : `SOL`, `WSOL`, `USDC`, `USDT`, puis autres mints fréquents si vérifiés ; -2. améliorer le service de backfill metadata pour traiter les tokens déjà présents en base ; -3. exposer un résumé de metadata manquantes par asset class, protocole d’origine, DEX et quote asset ; -4. rafraîchir automatiquement ou explicitement les `pair_symbol` après mise à jour des tokens ; -5. ajouter une commande UI ou clarifier la commande existante pour relancer le metadata backfill ; -6. vérifier l’idempotence : relancer le backfill metadata ne doit pas recréer tokens/pools/pairs/trades ; -7. conserver les compteurs DEX propres : `blockingIssueCount = 0`, `actionableMissingTradeEventCount = 0`, `missingTradeEventCount = 0` ; -8. préparer ensuite les launch surfaces, qui deviennent l’étape suivante de la roadmap. +Objectif de `0.7.39` : détecter et rattacher les surfaces de lancement sans inventer de program ids, sans produire de faux trades/candles et sans confondre `launch_origin`, `pool_origin`, `dex_effective` et `migration_target`. ## 9. Fichiers utiles pour reprendre dans une nouvelle session diff --git a/ROADMAP.md b/ROADMAP.md index bc8bc9c..1ae4b4a 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -751,19 +751,17 @@ Réalisé : ### 6.059. Version `0.7.27` — Validation multi-DEX des connecteurs déjà branchés Objectif : verrouiller la non-régression du pipeline actuel avant d’ajouter de nouveaux DEX ou d’ouvrir la phase d’analyse `0.8.x`. -À faire : +Réalisé / validé : -- rejouer des bases neuves de test pour `pump_fun`, `pump_swap`, `raydium_cpmm` et `raydium_clmm`, -- ne pas ajouter de nouveau DEX dans cette version ; cette version sert uniquement à valider les connecteurs déjà branchés, -- vérifier pour chaque DEX le triptyque `decoded_event_count / trade_event_count / pair_candle_count`, -- vérifier que les compteurs `diagnosticsClean`, `blockingIssueCount`, `actionableMissingTradeEventCount`, `duplicateDecodedEventTradeCount` et `duplicateCandleBucketCount` restent cohérents après replay, -- garantir que les événements non pricés ou non candle ne produisent pas de trade event invalide, -- conserver l’enrichissement `eventCategory`, `tradeCandidate`, `candleCandidate`, `liquidityCandidate`, `feeCandidate`, `rewardCandidate`, `adminCandidate` et `poolLifecycleCandidate` dans `payload_json`, -- documenter les familles d’événements utilisées pour les candles et celles conservées seulement pour l’analyse, la liquidité, les frais, les rewards, l’administration ou la traçabilité, -- ajouter ou compléter les tests unitaires sur `dex_decode`, `dex_detect`, `trade_aggregation`, `pair_candle_aggregation`, `pair_analytic_signal`, `local_pipeline_replay` et `local_pipeline_diagnostics`, -- ajouter des requêtes SQL de diagnostic de référence pour contrôler rapidement les tables clés après backfill ou replay local, -- conserver la tolérance aux événements DEX partiels tout en refusant les trades sans montant ou prix exploitable, -- valider que les transactions échouées restent traçables dans les événements décodés sans produire de `k_sol_trade_events`. +- replay local et bases neuves de test utilisés pour stabiliser `pump_fun`, `pump_swap`, `raydium_cpmm` et `raydium_clmm` ; +- aucun nouveau DEX ajouté dans cette étape : la version a bien servi de verrou de non-régression ; +- vérification du triptyque `decoded_event_count / trade_event_count / pair_candle_count` par DEX ; +- garde-fous maintenus sur `diagnosticsClean`, `blockingIssueCount`, `actionableMissingTradeEventCount`, `duplicateDecodedEventTradeCount` et `duplicateCandleBucketCount` ; +- refus des trades sans montant ou prix exploitable ; +- conservation des transactions échouées comme decoded events traçables sans produire de `k_sol_trade_events` ; +- maintien des champs d’enrichissement dans `payload_json` : `eventCategory`, `tradeCandidate`, `candleCandidate`, `liquidityCandidate`, `feeCandidate`, `rewardCandidate`, `adminCandidate`, `poolLifecycleCandidate` ; +- couverture testée dans les zones critiques : `dex_decode`, `dex_detect`, `trade_aggregation`, `pair_candle_aggregation`, `pair_analytic_signal`, `local_pipeline_replay`, `local_pipeline_diagnostics` ; +- requêtes SQL de diagnostic conservées comme contrôle manuel après backfill ou replay local. ### 6.060. Version `0.7.28` — Refactor DEX commun et préparation extension Réalisé : @@ -888,16 +886,17 @@ Réalisé : ### 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 : +Réalisé : -- ajouter `k_sol_fee_events`, -- ajouter `k_sol_reward_events`, -- ajouter `k_sol_pool_admin_events`, -- matérialiser les événements `collect_protocol_fee`, `collect_fund_fee`, `collect_creator_fee`, `collect_fee` et assimilés, -- matérialiser les événements `set_reward_params`, `initialize_reward`, `collect_reward`, `update_reward_infos` et assimilés, -- matérialiser les événements `set_config`, `update_config`, `set_authority`, `set_fee_rate`, `pause`, `resume` et assimilés, -- 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. +- ajout des tables `k_sol_fee_events`, `k_sol_reward_events` et `k_sol_pool_admin_events` ; +- ajout des DTO, entities, requêtes, index et re-exports associés ; +- matérialisation contrôlée des événements fees/rewards/admin lorsque la classification et les comptes le permettent ; +- rattachement aux transactions, decoded events, pools et paires lorsque les données disponibles sont fiables ; +- raccordement aux diagnostics locaux via `feeEventCount`, `rewardEventCount` et `poolAdminEventCount` ; +- ajout du profil `0.7.35_non_trade_fee_reward_admin` ; +- invariant maintenu : aucun fee/reward/admin ne produit de trade, metric ou candle. + +Limite connue : le corpus local `0.7.38` ne contient pas encore d’événements fee/reward/admin matérialisés ; les compteurs peuvent donc rester à zéro sans bloquer la validation. ### 6.068. Version `0.7.36` — Meteora : DBC / DAMM v1 / DAMM v2 / DLMM Réalisé : @@ -915,26 +914,37 @@ Réalisé : ### 6.069. Version `0.7.37` — Token metadata et catalogue local Objectif : rendre le catalogue local exploitable et lisible avant d’ajouter davantage de launch surfaces. -Réalisé en `0.7.37-A` : +Réalisé : - ajout du profil `0.7.37_token_metadata_catalog_enrichment` ; -- exposition des compteurs metadata/catalog dans les diagnostics et le rapport de validation ; -- raccordement UI Demo Pipeline 2 au profil `0.7.37` ; -- maintien volontaire du caractère non bloquant des metadata manquantes. +- exposition des compteurs metadata/catalog dans les diagnostics et le rapport de validation : `tokenCount`, `tokenMetadataMissingCount`, `tradableTokenMetadataMissingCount`, `quoteTokenMetadataMissingCount`, `pairSymbolFallbackCount`, `pairSymbolResolvedCount`, `wsolQuotePairCount`, `stableQuotePairCount` ; +- raccordement UI Demo Pipeline 2 au profil `0.7.37` puis au profil `0.7.38` ; +- maintien volontaire du caractère non bloquant des metadata manquantes ; +- backfill metadata des tokens déjà présents dans `k_sol_tokens` sans nécessiter un nouveau backfill transactionnel ; +- enrichissement depuis les sources disponibles : registre local, payloads Pump.fun, comptes SPL/Token-2022, Metaplex lorsque le service dispose d’un `HttpEndpointPool` ; +- rafraîchissement des `pair_symbol` après enrichissement des tokens ; +- commande UI disponible via `Demo Pipeline 2 > Replay local > Refresh missing token metadata` avec limite dédiée ; +- idempotence attendue : le backfill metadata met à jour tokens et symboles de paires sans recréer pools, paires, trades, candles ou origins ; +- registre local minimal consolidé : `SOL`, `WSOL`, `USDC`, `USDT`. -À faire : +Limite non bloquante : les diagnostics détaillés par origine de découverte restent une amélioration de confort ; l’étape `0.7.38` fournit déjà une liste priorisée exploitable via `tokenMetadataGapSamples`. -- ajouter ou consolider un registre local des mints connus et stables : `SOL`, `WSOL`, `USDC`, `USDT`, puis autres mints seulement si vérifiés ; -- améliorer le backfill metadata pour traiter les tokens déjà présents dans `k_sol_tokens` sans nécessiter un nouveau backfill transactionnel ; -- enrichir les tokens depuis les sources disponibles : registre local, payloads DEX, comptes Token-2022, Metaplex, transactions déjà persistées ; -- rafraîchir les `pair_symbol` après mise à jour des metadata de tokens ; -- exposer des diagnostics précis : `tokenMetadataMissingCount` par `dexCode`, `quoteAssetClass`, mint connu/inconnu et origine de découverte ; -- ajouter ou clarifier une commande UI dans `kb_demo_app` pour lancer le backfill metadata et rafraîchir le catalogue ; -- garantir l’idempotence : relancer l’enrichissement metadata ne doit pas recréer tokens, pools, paires, trades, candles ou origins ; -- conserver l’invariant de validation : le manque de metadata n’est pas un diagnostic bloquant tant que les trades/candles actionnables sont sains ; -- ajouter le profil de validation `0.7.37_token_metadata_catalog_enrichment`. +### 6.070. Version `0.7.38` — Priorisation des metadata manquantes +Objectif : transformer les compteurs metadata/catalog de `0.7.37` en liste d’action priorisée sans rendre les metadata manquantes bloquantes. -### 6.070. Version `0.7.38` — Launch surfaces : LaunchLab, LetsBonk, Bags, Moonshot/Moonit, Boop.fun, Believe +Réalisé : + +- ajout du profil `0.7.38_token_metadata_gap_prioritization` ; +- exposition de `tokenMetadataGapSamples` dans les diagnostics locaux, la validation et les bindings Demo Pipeline 2 ; +- priorisation des tokens manquants par usage : `tradable_quote_missing_metadata`, `tradable_token_missing_metadata`, `quote_token_missing_metadata`, puis `catalog_token_missing_metadata` ; +- raccordement Demo Pipeline 2 au nouveau profil par défaut ; +- conservation de l’invariant : les metadata manquantes ne créent pas de blocking issue tant que les trades/candles actionnables restent sains ; +- 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. + +### 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. À faire : @@ -949,7 +959,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.071. Version `0.7.39` — Heaven : corpus, launch et AMM +### 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. À faire : @@ -961,7 +971,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.072. Version `0.7.40` — Orca / FluxBeam / DexLab : corpus et validation ciblée +### 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. À faire : @@ -973,7 +983,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.073. Version `0.7.41` — Raydium AMM v4 legacy : corpus et validation ciblée +### 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. À faire : @@ -986,7 +996,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.074. Version `0.7.42` — Validation DEX v1 consolidée +### 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. À faire : @@ -999,7 +1009,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.075. Version `0.7.43` — `kb_demo_app` : overlays analytiques +### 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 : @@ -1010,7 +1020,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.076. Version `0.7.44` — `kb_demo_app` : vues consolidées token / pair / pool +### 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 : @@ -1022,7 +1032,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.077. Version `0.7.45` — Finition UI `0.7.x` +### 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 : @@ -1033,7 +1043,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.078. Version `0.7.x` — Couverture DEX v1 +### 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 : @@ -1076,7 +1086,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.079. Version `0.8.x` — Analyse et filtrage +### 6.080. Version `0.8.x` — Analyse et filtrage Objectif : transformer les événements bruts en signaux exploitables. À faire : @@ -1091,7 +1101,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.080. Version `1.x.y` — Wallets et swap préparatoire +### 6.081. Version `1.x.y` — Wallets et swap préparatoire Objectif : préparer la couche d’action. À faire : @@ -1102,7 +1112,7 @@ Objectif : préparer la couche d’action. - préparation d’ordres et de swaps, - simulation et garde-fous. -### 6.081. Version `2.x.y` — Trading semi-automatisé +### 6.082. Version `2.x.y` — Trading semi-automatisé Objectif : brancher l’analyse à l’action tout en gardant des garde-fous explicites. À faire : @@ -1113,7 +1123,7 @@ Objectif : brancher l’analyse à l’action tout en gardant des garde-fous exp - confirmations explicites ou semi-automatiques, - journaux d’exécution. -### 6.082. Version `3.x.y` — Yellowstone gRPC +### 6.083. Version `3.x.y` — Yellowstone gRPC Objectif : ajouter le connecteur gRPC dédié. À faire : @@ -1243,17 +1253,21 @@ Le projet doit maintenir au minimum : ## 12. Priorité immédiate -La priorité immédiate reste de terminer `0.7.37_token_metadata_catalog_enrichment` par le backfill metadata effectif et le rafraîchissement des symboles de paires. +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`. -Ordre de travail recommandé : +Préconditions validées avant `0.7.39` : -1. conserver la validation acquise `0.7.36` : Meteora consolidé, transactions failed traçables mais non actionnables, swaps sans amounts classés `non_actionable_trade`, aucun diagnostic bloquant masqué ; -2. améliorer le catalogue local : metadata de tokens, symboles, noms, asset classes et `pair_symbol` lisibles ; -3. ajouter un registre local des mints connus et stables : `SOL`, `WSOL`, `USDC`, `USDT`, puis autres mints seulement après vérification ; -4. permettre un backfill metadata idempotent sur les tokens déjà présents sans relancer un backfill transactionnel complet ; -5. exposer les compteurs de metadata manquantes par DEX, asset class, quote asset et origine de découverte ; -6. ajouter ou clarifier la commande UI permettant de relancer le backfill metadata et le refresh du catalogue ; -7. vérifier que l’enrichissement metadata ne modifie pas les invariants DEX : pas de faux trades, pas de fausses candles, pas de recréation de pools/paires ; -8. déplacer ensuite les launch surfaces vers `0.7.38` : Raydium LaunchLab/Launchpad, LetsBonk/Bonk.fun, Boop.fun, Moonshot/Moonit, Believe et Bags ; -9. traiter Heaven en `0.7.39`, puis Orca/FluxBeam/DexLab, puis Raydium AMM v4 legacy ; -10. effectuer une validation DEX v1 consolidée avant d’ouvrir réellement `0.8.x` pour l’analyse, les filtres, les patterns et les projections graphiques. +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é ; +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`. + +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. diff --git a/kb_demo_app/frontend/demo_pipeline2.html b/kb_demo_app/frontend/demo_pipeline2.html index a245771..3b342c0 100644 --- a/kb_demo_app/frontend/demo_pipeline2.html +++ b/kb_demo_app/frontend/demo_pipeline2.html @@ -166,7 +166,8 @@