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.