2026-03-31 · 09:00 HKT
Structure-Aware Microstructure Framing
Refined the trading research stack from pure entry-edge thinking into a structure-aware framework that separates observed microstructure signals, reconstructed market regime, and strategy action.
Progress
- Separated imbalance analysis into three layers: signal layer, structural layer, and strategy layer.
- Clarified that primitive signals describe current market behavior, but do not directly predict outcome by themselves.
- Focused the structural layer on whether the original trading thesis is still supported by the market, rather than on simple price direction.
- Reframed single-leg risk as a regime-support problem: the main danger is not just that the second leg failed to arrive, but that the market changed while we kept waiting.
- Shifted the design goal from reactive execution toward structure-aware trading systems that track how support forms, decays, and eventually invalidates an open position.
Next
- Keep refining the distinction between temporary dislocation, directional repricing, and mixed unstable states.
- Feed the structural interpretation into first, second, rotate, and tail decisions with strict time-boundary discipline.
- Resume empirical analysis only after the updated runtime path has produced another 10 to 20 fresh slugs.
2026-03-31 · 18:00 HKT
Pulling The Strategy Back Toward Arbitrage
Today's adjustment was to pull the trading path back from trailing and drift-following behavior toward a cleaner arbitrage contract: pairability before direction, execution feasibility before expansion, and tighter ownership across first, second, and rotate.
Progress
- Recognized that the previous path had become too trailing and was starting to drift away from the core arbitrage principle.
- Kept EntryScore in the audit and research lane, rather than allowing it to become a runtime authority too early.
- Re-centered first-leg selection on pairability, support, and execution feasibility instead of directional drift-following.
- Kept first, second, and rotate as separate owners so post-entry behavior is not confused with opening logic.
- Used the new Postgres validity views to measure outcome quality continuously instead of checking candidate quality by hand slug by slug.
Next
- Keep reducing bad candidate rate before considering stronger runtime use of EntryScore-like signals.
- Use hourly and slug-level PG views to isolate which windows and slugs still drag the system away from clean arbitrage behavior.
- Resume deeper empirical attribution only after the updated runtime path has produced another 10 to 20 fresh slugs.
2026-03-31 · 22:00 HKT
External Direction Versus Microstructure Direction
Opened a focused analysis plan to separate external directional structure from very-short-horizon microstructure pressure, so EntryScore is no longer judged as if both layers should always point to the same side.
Progress
- Made the problem explicit: when external direction and microstructure direction align, EntryScore candidates are easier to explain, but when they conflict, the system often picks the wrong side or gets rejected later by anti-trend and directional-branch guards.
- Clarified the main hypothesis: microstructure factors may not be wrong, but they may be describing local bounce, residual liquidity, or short-horizon imbalance rather than the higher-level repricing direction.
- Reframed the question for first-leg quality: the issue is not only whether a candidate exists, but whether microstructure is being misused as a primary directional judge when external structure is already dominant.
- Defined the first analysis split as aligned, conflict, and neutral classes, then tied those classes back to near-window pair success, adjacent-window pair success, no recovery, and stop-loss outcomes.
- Set up the next measurement path around microstructure lag, bounce-versus-trend continuation, and local liquidity residue so the result can feed both first selection and pair completion logic.
Next
- Run the aligned-versus-conflict outcome slice in Postgres instead of relying on anecdotal slug review.
- Measure how many snapshots or seconds microstructure lags after external direction flips.
- Use the result to decide when microstructure can support first selection and when it must yield to higher-level external structure.
2026-03-30 · All Day
Dashboard And Console Stabilization
Improved the Polybot read surface so daily execution progress, live monitoring, and diagnostics can be tracked remotely without digging through raw logs by hand.
Progress
- Separated lightweight live dashboard reads from heavier history and diagnostics views.
- Stabilized latest slug countdown, automatic slug switching, and SSE-driven live updates.
- Reworked dashboard layout, recent trade/slugs paging, and interaction details.
- Turned console into a structured operations page with paging, filters, collapsible logs, and log paging.
- Unified dashboard, console, slugs, trades, and diagnostics into the same Matrix-style visual system.
Next
- Keep daily progress notes here so the landing page becomes the working weblog.
- Continue reducing heavy historical scans from any remaining live-adjacent helpers.
- Consider indexing selected history into Postgres once the read-only UI shape is stable.
2026-03-29 · All Day
Remote Weblog Control Plane Brought Online
Brought the Polybot remote control plane online behind systemd and nginx, and established the live-vs-history design boundary for the first usable web surface.
Progress
- Shipped the first remote dashboard, console, trades, slugs, and slug detail pages.
- Added dashboard live endpoints and SSE for current slug monitoring.
- Moved the service under polybot-weblog systemd management and fronted it with nginx.
- Added explicit documentation for architecture, goals, deployment, and handoff context.
Next
- Keep live payloads lightweight and suitable for fast push updates.
- Push heavier queries toward pull-based history pages and diagnostics.