docs(roadmap): add docs/roadmap.md — current state to MVP path

[jensholdgaard]

Summary

Living document parallel to hazards.md and benchmarks.md,
asked for after PR #15 merged: hazards say what we mustn't
break, benchmarks say what success looks like, roadmap says
how we get from here to there.

What the doc does

• Reframes "MVP" specifically as thesis-proving (the five
  [THESIS]-marked benchmarks A1/B1/B2/C1/C2 in
  benchmarks.md) rather than production-ready. This
  collapses the surface area: WAL, OTLP, snapshots, full §6.8
  telemetry, query DSL, Helm — all real shipping concerns,
  none of which change the answer to "does the thesis hold."
  Each is named in §5 (Deliberately out of MVP) with a
  why-deferred reason and a when-it-lands marker, so the
  deferrals are explicit.
• Records current state as of 2026-05-11 (post PR feat(miner): add sim_seq + confidence_ratio (RFC 0001 §3.2, §6.3) #15):
  what each crate has, the §5 6/29 count, and a per-thesis-gate
  blocker table mapping each gate to specific missing
  capabilities.
• Lays out a three-phase path at scope-level only (per the
  team verdict on the planning question — phase scope, not
  per-PR prescription, so the doc stays stable as mid-stream
  design decisions land):
  1. Phase 1 — Finish the miner (Drain tree, descend,
     widen, audit, three-zone branching,
     separators+reconstruct(), overflow). Unblocks C1,
     C2.
  2. Phase 2 — ourios-parquet (schema, writer, reader,
     audit stream). Unblocks A1.
  3. Phase 3 — ourios-querier + ourios-bench + corpus.
     Unblocks B1, B2.

Design choices flagged in the team chat

• Doc location: docs/roadmap.md (flat top-level), not
  docs/architecture/roadmap.md. The architecture/
  directory CLAUDE.md §7 names doesn't exist yet, and
  seeding it for one file would be premature; flat at this
  scale is easier to grep + find.
• Per-PR plan depth: phase-level scope only. Pre-naming
  the ~10–14 PRs to MVP would rot the doc whenever a
  mid-stream design correction happens (which has happened
  every multi-PR series this session). Per-PR scope is settled
  at planning time, not committed to the doc.

Update cadence (§6 in the doc itself)

Refreshed:

• After every merged PR that materially changes §3 (current
  state).
• At phase boundaries (§4).
• When a thesis-gate result lands in benchmarks.md §9.

Explicitly not refreshed on every spec edit — RFC patches
and hazards.md edits don't change the road map unless they
change what MVP requires. If §3 needs a refresh every PR, the
doc has become an activity log; the fix is to be more
selective, not to stop updating.

Test plan

• mdbook build clean — new doc renders, SUMMARY.md
  navigation picks it up under the Benchmarks section
• No Rust changes; no fmt/clippy/test impact
• No §5 scenarios added or removed; status stays at red

🤖 Generated with Claude Code