Roadmap

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.