From 24d21818cfd094224c25621f83ab8fe27c3be18c Mon Sep 17 00:00:00 2001 From: SinuS Von SifriduS Date: Wed, 13 May 2026 11:17:53 +0200 Subject: [PATCH] 0.7.32 --- CHANGELOG.md | 1 + Cargo.toml | 2 +- README.md | 13 +- ROADMAP.md | 51 ++--- kb_demo_app/frontend/demo_pipeline2.html | 3 +- ...LocalPairActionabilityDiagnosticSummary.ts | 38 ++++ ...Pipeline2LocalPipelineDiagnosticSummary.ts | 49 ++++- kb_demo_app/package.json | 2 +- kb_demo_app/src/demo_pipeline2.rs | 107 +++++++++- kb_demo_app/src/demo_ws.rs | 9 +- kb_demo_app/src/demo_ws_manager.rs | 3 +- kb_demo_app/src/main.rs | 6 +- kb_demo_app/tauri.conf.json | 2 +- kb_lib/src/db.rs | 2 + kb_lib/src/db/dtos.rs | 10 +- .../src/db/dtos/local_pipeline_diagnostics.rs | 90 ++++++++ .../program_instruction_discriminator_row.rs | 1 - kb_lib/src/db/queries.rs | 1 + .../db/queries/local_pipeline_diagnostics.rs | 195 ++++++++++++++++++ kb_lib/src/dex_support_matrix.rs | 21 +- kb_lib/src/lib.rs | 4 + kb_lib/src/local_pipeline_diagnostics.rs | 18 ++ kb_lib/src/local_pipeline_validation.rs | 173 ++++++++++++++++ 23 files changed, 736 insertions(+), 65 deletions(-) create mode 100644 kb_demo_app/frontend/ts/bindings/DemoPipeline2LocalPairActionabilityDiagnosticSummary.ts diff --git a/CHANGELOG.md b/CHANGELOG.md index be3ffad..0f697fb 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -62,3 +62,4 @@ 0.7.29 - Ajout d’une matrice DEX commune (`dex_support_matrix`) utilisée par le catalogue DEX, la classification transactionnelle et l’enregistrement des protocol candidates ; ajout du profil de validation `0.7.29_multi_dex_matrix_baseline` exposant la matrice dans le rapport de validation ; préparation explicite des surfaces planifiées sans inventer de program ids non vérifiés. 0.7.30 - Ajout d’une taxonomie DEX plus fine pour les événements décodés : `eventLifecycleKind`, `eventActionability`, `nonTradeUseful`, compteurs diagnostics des événements non-trade utiles, trades non actionnables et classifications inconnues ; ajout du profil `0.7.30_non_trade_event_classification` sans modification volontaire de la matérialisation trade/candle. 0.7.31 - Application de la politique Option B : les transactions failed restent traçables dans les événements décodés mais ne peuvent plus alimenter `trade_events`, metrics ou candles ; le replay local réinitialise les tables de matérialisation marché avant reconstruction pour supprimer les anciennes lignes dérivées non actionnables. +0.7.32 - Clarification de la sémantique des diagnostics locaux : séparation des gaps littéraux de paires et des gaps bloquants/actionnables, ajout des compteurs de matérialisation par paire, résumé `pairActionabilitySummaries`, profil `0.7.32_validation_report_semantics` et garde-fous sur la matrice DEX sans modification de la matérialisation trade/candle. diff --git a/Cargo.toml b/Cargo.toml index f094054..4137221 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -8,7 +8,7 @@ members = [ ] [workspace.package] -version = "0.7.31" +version = "0.7.32" edition = "2024" license = "MIT" repository = "https://git.sasedev.com/Sasedev/khadhroony-bobobot" diff --git a/README.md b/README.md index 12a55fe..6caea34 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.30` : 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 reprise autour de `0.7.32` : 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à. ## 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.30` +## 3. État actuel autour de `0.7.32` ### 3.1. Socle stabilisé à ne pas refactorer maintenant @@ -99,6 +99,8 @@ Depuis `0.7.29`, la matrice de support DEX est portée par `kb_lib/src/dex_suppo Depuis `0.7.30`, les événements décodés reçoivent aussi une classification plus fine : `eventLifecycleKind`, `eventActionability` et `nonTradeUseful`. Cette classification sert aux diagnostics et prépare la matérialisation future des événements non-trade sans alimenter directement les trades/candles. +Depuis `0.7.32`, les diagnostics distinguent explicitement les gaps littéraux de catalogue (`literalPairWithoutTradeCount`, `literalPairWithoutCandleCount`) des gaps bloquants/actionnables (`blockingPairWithoutTradeCount`, `blockingPairWithoutCandleCount`). Les anciens champs `pairWithoutTradeCount` et `pairWithoutCandleCount` restent exposés comme alias de compatibilité pour les gaps bloquants/actionnables. + | Code cible | Type | Statut `0.7.29` | Prochaine action | |---|---:|---|---| | `pump_fun` | Launch + bonding curve | partiel | verrouiller le rattachement mint initial -> pools migrés | @@ -215,9 +217,10 @@ Les tests peuvent rester plus souples lorsque cela clarifie le test. La reprise doit suivre cet ordre : -1. conserver la non-régression `0.7.31` : transactions failed traçables mais exclues des `trade_events`, metrics et candles ; -2. utiliser la matrice `0.7.29` comme source commune pour le catalogue, la classification et les protocol candidates ; -3. relier progressivement les événements non-trade aux tables existantes : lifecycle, liquidité, fees, rewards, admin ; +1. conserver la sémantique `0.7.32` : les gaps littéraux de catalogue ne doivent pas être confondus avec les gaps bloquants/actionnables utilisés par la validation ; +2. conserver la non-régression `0.7.31` : transactions failed traçables mais exclues des `trade_events`, metrics et candles ; +3. utiliser la matrice `0.7.29` comme source commune pour le catalogue, la classification et les protocol candidates ; +4. relier progressivement les événements non-trade aux tables existantes : lifecycle, liquidité, fees, rewards, admin ; 4. consolider Meteora, surtout `meteora_dlmm` et le cas partiel `meteora_damm_v1` ; 5. ajouter les launch surfaces manquantes comme origines de mint : LaunchLab/Launchpad, LetsBonk/Bonk.fun, Boop.fun, Moonshot/Moonit, Believe, Bags ; 6. traiter Heaven ; diff --git a/ROADMAP.md b/ROADMAP.md index 4fbcbcf..3063133 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -846,18 +846,20 @@ 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` — Transactions inconnues et protocol candidates -Objectif : ne plus perdre les transactions utiles qui ne correspondent pas encore à un DEX connu. +### 6.064. Version `0.7.32` — Sémantique des diagnostics et compteurs de validation +Réalisé : -À faire : +- 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` — É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. @@ -1212,17 +1214,18 @@ 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. 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. +2. conserver la clarification `0.7.32` entre gaps littéraux de catalogue et gaps bloquants/actionnables, +3. 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, +4. garder les clients HTTP/WS et managers réseau hors du refactor DEX tant qu’ils ne bloquent pas le pipeline, +5. 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. diff --git a/kb_demo_app/frontend/demo_pipeline2.html b/kb_demo_app/frontend/demo_pipeline2.html index 7bf1936..e5f1227 100644 --- a/kb_demo_app/frontend/demo_pipeline2.html +++ b/kb_demo_app/frontend/demo_pipeline2.html @@ -166,7 +166,8 @@