Roadmap

The product ships contract-first: future capabilities exist today as fixed endpoint shapes and visibly locked UI slots. This page maps each slot to the work that lights it up. Everything here is Roadmap unless marked shipped.

Serving tiers: root → tree → live

One NodeDocument v1 contract, three data sources; only coverage grows.

Tier-A: the full-tree extraction campaign

The plan (spec'd in solver-lab/data_plane/specs/extraction_spec_v1.md) is a re-solve + extract pass over the sealed backbone: the offline teacher re-runs each solve and emits packed full-tree nodes — all flop and turn decision nodes, river roots, deeper river re-solved at runtime — as binary boardpacks served via HTTP range reads.

What it unlocks in the product — every locked slot that names the "extraction campaign":

• Tree navigation in the strategy browser (the disabled node breadcrumb slots; the 501 endpoint starts returning documents).
• Facing-bet nodes — pot odds / MDF readouts on real decisions, not just root geometry.
• Real IP reach weights — the "IP weights: uniform (v0)" badge retires.
• True chips-per-bb constants (bb_chips_derived retires). Done — adapter rev 2 converts with the declared flat 100 chips/bb.
• The library's "Full tree" tier filter stops being disabled.

Live tier

Real-time solves for arbitrary nodes and configurations — same document shape, served from the same endpoints. Sequenced after tree; unblocks the locked solution axes (Cash, ICM, other table sizes, asymmetric stacks) as solver capacity allows.

Preflop data

• EV exports — the preflop packs carry no EVs yet; the Breakdown tab on /study is locked until they ship ("nothing is fabricated here in the meantime").
• Coverage growth — as more postflop families ship, covered_boundaries climbs per depth and more bridges turn green, with no app changes.

API

• /v1/families/:fam/aggregate — an open question with the API team. Today the family flop report is a client-side fan-out over per-board documents (bounded concurrency 12, cached 1h); a server aggregate would make it one cheap, content-addressed response.

The coaching-SaaS slots

The /practice and /analyze routes are deliberate stubs (M2/M3) for the coaching product on top of the exact-solve data plane:

• Hand-history uploader — bring your own hands in; parse and store them (the Supabase scaffolding in the app is the placeholder for accounts and storage — env-driven, disabled until a project exists).
• Analyzer — replay a hand against the solved tree: locate each decision in coverage, diff the action taken against the solve, quantify the EV gap.
• Drills / practice — spaced repetition on the spots where your play diverges most.
• LLM coach — conversational review grounded exclusively on exact solves: it cites the solved node it is reading, and it refuses to answer for out-of-coverage spots rather than improvising strategy. The coverage labels that already gate the UI are the same guardrail the coach will use.

Salvageable prior art for these (Supabase auth/RLS, replayer, drills, coach chat) is audited in the repo's SALVAGE.md.

Deliberately not yet wired

ESLint config, CI, and Playwright for this app — planned to land with the first real feature PR. The API repo already runs its full gate (AGPL deny-check + tests) on every pnpm test.