chart/docs/NEXT_STEPS.md

Current recommendations

Last reviewed: 2026-08-15 00:00 CDT.

This file is the short list of work worth considering next. Verified history, measurements and completed work remain in docs/implementation.md, and the decisions behind them in docs/plan.md.

Fix next

Revisit the trendline live-edge bend with painted-pixel evidence

Mid-session 1m tape holes are now counted in source index as well as on the time scale. Production still appears to show a bend where 30m manual lines cross from the last real candle into future whitespace. The deployed code is verified to use one canvas LineSeries, retained transparent time-scale points, and canonical source-space prices. Diagnostic values can report unequal historical/future screen slopes when the final candles are sparse, but synthetic browser coverage passes after gap slots are inserted. The transparent-point production fix did not visibly settle the report, so do not add another geometry patch from the current theory.

Painted-pixel diagnostics are now implemented: diagnostic mode samples the internal canvases around each join by the line's RGB colour and reports painted historical/future slopes beside canonical and API-coordinate slopes. A browser regression confirms actual canvas pixels stay continuous in the deterministic sparse-tail case. The remaining step is a production capture with those painted values; do not change geometry again until it says whether production pixels or production coordinates diverge.

Load bars from the visible window

The 1m chart stopping at ~1am was a leftover get(tf, 1000) on the WebSocket snapshot. The store already held 5,000. The socket now sends everything in the store (MAX_BARS_PER_TF). That is the immediate fix, not the destination.

Next: send the visible window and fetch older bars when the time scale hits the left edge. Do not put another silent numeric cap on a payload. How much the client gets is either “what is on screen” or the named store limit — never a bare 1000 in a socket handler.

Deepen freshness telemetry

The status bar now reports when the browser received its latest snapshot or bar. A later server-side implementation can distinguish market closure, source delay and transport failure by carrying exact trade time, the last settled minute, source receipt time and an application heartbeat over the existing WebSocket. Any stale threshold must account for Yahoo's declared delay.

Light / dark themes

Do not invert the cream palette. Chrome tokens flip cheaply; stored drawing hexes and the dark palette stops do not. The constraints are in docs/plan_light_dark_themes.md.

Frontend build

The CDN-to-Vite plan is in docs/vite_build.md. First tranche is a production Dockerfile that reproduces today's nixpacks image, so a later package.json cannot make Coolify treat this as a Node app. Do not start the file move until that deploy has been seen live.

Mobile authoring

The detailed plan is in docs/mobile_enhance.md. Recommended first tranche:

1. Add touch-sized invisible hit regions without enlarging the visual marks.
2. Keep the first tap's trendline anchor visible with price/time, Cancel and Undo anchor.
3. Add a compact sticky mobile tool rail next to the chart.
4. Add a selected-drawing action bar so End here and Delete do not require right-click or a hardware keyboard.

Prefer tap-tap trendlines on touch devices. Reserve one-finger vertical movement for page scrolling, retain horizontal chart panning and pinch zoom, and offer a chart-focused landscape/fullscreen mode.

Market-data alternatives

No durable unauthenticated source of free real-time CME /ES data has been identified. CME real-time access is normally broker-subsidized and tied to an authenticated exchange entitlement, not a public free API.

Practical ranking:

1. Keep Schwab for verified entitled real-time streaming and Yahoo for delayed development/history seeding.
2. Pilot Tastytrade/dxLink on a live futures-approved account. Confirm actual delay, candle retention, continuous/root symbol behavior and server-side-use terms before integrating it.
3. Consider IBKR as the strongest low-cost fallback if literal zero cost is not required; resolve and roll the active contract explicitly for live data.
4. Consider TradeStation only if its account-funding/API-access requirements are already acceptable.
5. Evaluate Nasdaq Data Link CHRIS only for continuous daily seeding after confirming current freshness and free-key availability.

Do not build a backend around scraped TradingView, CME, Barchart, Investing.com, MarketWatch or Stooq pages. Public display access is not a supported market-data API or a CME redistribution license.

References:

• Tastytrade streaming: https://developer.tastytrade.com/streaming-market-data/
• IBKR market data: https://www.interactivebrokers.com/en/pricing/research-news-marketdata.php
• TradeStation API: https://www.tradestation.com/platforms-and-tools/trading-api/
• Nasdaq Data Link API: https://docs.data.nasdaq.com/

Deferred test tied to production work

When startup seeding is changed to bulk-load bars, add an integration test that asserts expensive level rebuilding happens once and that final stores/levels match incremental ingestion. Do not assert a wall-clock duration and do not add a test that merely codifies today's slow startup.

Test and deployment commands

README is authoritative for local pytest, local Playwright E2E, pre-deploy and production smoke-test commands. Browser E2E creates and deletes drawings, so it must remain pointed at the local stack rather than production.