From 94abbb2767390d02e9e5111dc49cbee015ecf510 Mon Sep 17 00:00:00 2001 From: SinuS Von SifriduS Date: Sun, 19 Apr 2026 18:08:56 +0200 Subject: [PATCH] Roadmap --- TODO.md | 138 +++++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 102 insertions(+), 36 deletions(-) diff --git a/TODO.md b/TODO.md index e33538f..576c972 100644 --- a/TODO.md +++ b/TODO.md @@ -29,7 +29,7 @@ The project is split into several major applications sharing `khbb_lib`: ## Current architectural direction -Current implementation started with a simple inline listener loop in order to validate: +The implementation started from an inline listener loop in order to validate, one step at a time: - Solana HTTP RPC transport, - Solana WebSocket transport, @@ -38,9 +38,9 @@ Current implementation started with a simple inline listener loop in order to va - early domain classification, - heuristic signals, - HTTP enrichment, -- candidate tracking. +- candidate tracking and persistence. -This is considered a bootstrap architecture. +This bootstrap architecture has been useful for validation, but it is no longer the target shape of the project. ### Target architecture direction @@ -57,14 +57,16 @@ The target architecture should progressively move toward: - enrichment, - correlation, - persistence, - - strategy/trading. + - strategy/trading, + - UI/runtime control. This especially applies to: - multiple WebSocket clients, - Yellowstone gRPC client(s), - HTTP enrichment workers, -- future external data sources. +- future external data sources, +- a Tauri desktop shell for `khbb_listener_app`. --- @@ -201,6 +203,22 @@ This especially applies to: - confidence-based filtering - end-of-session summary logs +### v0.6.0 +- dedicated session candidate persistence in SQLite +- reusable candidate persistence base for later analyser/trader reuse +- listener end-of-session candidate persistence flow + +### v0.6.1 (in progress / bootstrap-valid) +- first refactor toward an autonomous WebSocket source client +- `listener.rs` no longer owns the low-level WebSocket transport directly +- `ws_source.rs` now encapsulates: + - connection lifecycle, + - subscribe operations, + - event reception, + - close/shutdown behavior +- listener runtime can now complete without hanging during WS shutdown +- current state is considered a **valid bootstrap of the autonomous WS client**, but not yet the final multi-instance source runtime + --- ## Current status summary @@ -219,6 +237,7 @@ At the current stage, the project can already: - confirm token-account-like activity, - correlate signals, - track session candidates in memory, +- persist session candidates, - summarize candidates at the end of a run. What is still missing is the transition from generic token activity detection to true: @@ -227,7 +246,8 @@ What is still missing is the transition from generic token activity detection to - token bootstrap detection, - pool/pair detection, - DEX-aware activity detection, -- persistent candidate storage, +- robust multi-source runtime orchestration, +- Tauri runtime/UI control, - pattern analysis, - trading integration. @@ -237,45 +257,80 @@ What is still missing is the transition from generic token activity detection to > Planned versions are provisional and may change. -### v0.6.0 -- persist session candidates to SQLite -- add dedicated candidate table(s) -- persist summary-worthy candidates at end of listener session -- create base persistence model reusable by analyser and trader +### v0.6.x — autonomous multi-instance WS client branch -### v0.6.1 -- refactor WebSocket client into an autonomous async source runtime -- introduce command/event channel model -- separate WS transport orchestration from listener business logic +This branch is now reserved for stabilizing the WebSocket source runtime as an autonomous reusable component. ### v0.6.2 +- stabilize `ws_source` contract and lifecycle +- improve unit/integration coverage around: + - spawn, + - connect, + - subscriptions, + - event reception, + - shutdown, + - close +- document the exact shutdown semantics +- reduce coupling between listener business logic and WS source internals + +### v0.6.3 - support multiple concurrent WS source clients - allow different endpoints/providers simultaneously - introduce source identity and source metadata - prepare failover / redundancy / specialization by source -### v0.6.3 -- introduce Yellowstone gRPC source runtime -- normalize WS + gRPC source events into a shared event model -- compare and reconcile overlapping data streams - ### v0.6.4 -- introduce source aggregation hub -- merge multi-source events into a unified ingestion pipeline -- prepare source-level prioritization and deduplication +- introduce source aggregation hub for multiple WS clients +- merge multi-source WS events into a unified ingestion pipeline +- prepare prioritization and deduplication across sources + +### v0.6.5 +- prepare transport-level abstraction so that WS sources and future gRPC sources can share a common high-level source contract +- identify what must remain WS-specific vs source-generic + +### v0.6.6 +- begin Yellowstone gRPC source runtime design and first bootstrap implementation +- align WS and gRPC runtime expectations before moving to a broader source orchestration branch + +### v0.7.x — `khbb_listener_app` migration to Tauri v2 + +This branch is now reserved for transforming `khbb_listener_app` into a Tauri v2 desktop application. ### v0.7.0 +- introduce Tauri v2 shell for `khbb_listener_app` +- add desktop window with: + - start button, + - stop button, + - readonly scrollable log area +- keep current listener runtime available through Tauri commands + +### v0.7.1 +- load `config.json` through the desktop app flow +- adapt tracing so logs can be surfaced both to file/stdout and to Tauri events +- define first Tauri runtime commands/events contract + +### v0.7.2 +- support start/stop lifecycle entirely through Tauri runtime control +- add runtime state reporting to UI +- prevent double-start / invalid stop / inconsistent state transitions + +### v0.7.3 +- improve desktop log streaming and session summaries +- expose listener candidate summaries in UI +- prepare future status panels beyond the initial log textarea + +### v0.8.0 - improve token-account vs mint distinction - decode more token-specific account information - improve quality of confirmed mint detection - reduce weak false candidate generation -### v0.7.1 +### v0.8.1 - introduce first persistent mint candidates - introduce first persistent token-account candidates -- session-to-database promotion logic +- session-to-database promotion logic refinement -### v0.7.2 +### v0.8.2 - begin real bootstrap flow persistence and tracking - correlate: - token accounts @@ -283,7 +338,7 @@ What is still missing is the transition from generic token activity detection to - bootstrap-like logs - source timing -### v0.8.0 +### v0.9.0 - begin DEX-aware detection layer - identify relevant program ids for first supported DEXes - start with a small prioritized list, likely including: @@ -292,19 +347,19 @@ What is still missing is the transition from generic token activity detection to - Pump-like ecosystems - detect pool/pair creation-related activity -### v0.8.1 +### v0.9.1 - add first pair / pool candidate models - begin liquidity/bootstrap/pair-side inference - distinguish token-only activity from pair/pool activity -### v0.8.2 +### v0.9.2 - add market-related enrichment: - liquidity hints - price hints - pool metadata - start preparing listener outputs for trading eligibility -### v0.9.0 +### v0.10.0 - begin `khbb_pattern_analyser_app` - consume persisted candidates/signals from listener - define first recurring pattern models: @@ -314,7 +369,7 @@ What is still missing is the transition from generic token activity detection to - repeated naming patterns - repeated creator behavior -### v0.9.1 +### v0.10.1 - pattern scoring - candidate clustering - repeated-behavior analysis across sessions @@ -322,7 +377,8 @@ What is still missing is the transition from generic token activity detection to ### v1.0.0 - first end-to-end listener milestone - persistent candidate ingestion -- multi-source ingestion foundations +- autonomous source-client foundations +- Tauri listener control foundations - DEX-aware first detection - pattern analyser initial interoperability @@ -349,14 +405,23 @@ What is still missing is the transition from generic token activity detection to ## Cross-cutting technical TODO ### Transport / source runtime -- [ ] move away from single inline WS runtime model -- [ ] introduce autonomous async WS source tasks +- [x] move away from single inline WS runtime model +- [x] introduce first autonomous async WS source task +- [ ] stabilize the autonomous WS source API and lifecycle contract - [ ] add multi-WS support - [ ] add gRPC source runtime - [ ] unify source event interface +- [ ] add source aggregation hub + +### Desktop / runtime control +- [ ] introduce Tauri v2 shell for `khbb_listener_app` +- [ ] add start/stop commands +- [ ] stream tracing logs to UI +- [ ] load runtime config via desktop flow +- [ ] expose runtime state to UI ### Storage -- [ ] persist session candidates +- [x] persist session candidates - [ ] define candidate history tables - [ ] define mint/pool/pair tables - [ ] define source tables / provider metadata tables @@ -391,6 +456,7 @@ What is still missing is the transition from generic token activity detection to ## Notes - Current versions intentionally favored iterative validation over final architecture purity. -- The current listener runtime is considered a stepping stone, not the final source-runtime model. +- The autonomous WS source refactor is now started and validated enough to continue as the main direction for `0.6.x`. +- The Tauri migration is intentionally separated into `0.7.x` so transport/runtime stabilization can happen first. - Candidate/correlation layers may continue to evolve before stabilizing. - Future versions may be renumbered, merged, split, or reprioritized depending on what real Solana traffic reveals.