# Roadmap

## Now

1. Keep the first trusted square concise and fully MoonBit-owned.
2. Keep the selected `northeast-stepout` clearance gates visible in the
   dossier and operator view while the underlying terrain, illumination, energy,
   and operator-review blockers are cleared.
3. Keep source fixtures reproducible through MoonBit tests and manifests.
4. Use `ui/rabbita-moon` as the canonical interactive operator product while
   `src/ui` owns its renderer-neutral state and the generated HTML remains a
   static report.
5. Keep `src/ui/motion_contract.mbt` as the current locomotion handoff: it
   exposes route-motion readiness without placing robot gait primitives in
   Moonphys.
6. Follow `docs/LOCOMOTION_PHASE_GUIDANCE.md` for the route-motion to robot
   gait adapter phases.
7. Follow `docs/STEP_BY_STEP_PLAN.md` as the active build order: selected-route
   clearance first, evidence-backed Moon view next, then general data-layer
   hardening and robot migration through domain-local packages.
8. Follow the immediate step-by-step data plan in `docs/DATA_LAYER.md`: keep
   the generic root readable, migrate one robot dataset family at a time, and
   keep product labels tied to validated catalog evidence.
9. Keep the checked DE440 globe-lighting boundary in
   `docs/LUNAR_LIGHTING_PHASE.md` separate from route-clearance authority.
10. Keep the third-person Earthrise view synchronized with that same observer
    timeline; texture rotation remains presentation, not lighting authority.
11. Keep route illumination tied to all 336 hourly Sun samples and the matching
    measured horizon sector; do not return to extrema-only shadow claims.
12. Keep the ranked 2026-11-08 to 2026-11-22 selected-route illumination
    window visible as candidate evidence while current mission authority stays
    blocked.

## Next

- Deliver the canonical lunar operator experience in
  `docs/UI_UX_NEXT_PHASE.md`: open on the Moon, make global-to-local controls
  real, show route gates in the first viewport, and keep robot motion in a
  separate adapter preview.
- Use the ranked future window to review the selected route's illumination
  constraint, then tighten terrain, mission-energy, and operator-review
  evidence before any overall clearance can move from block to review or allow.
- Keep the historical `src/dataset` facade removed. Terrain source manifests
  stay in `src/terrain`, lunar facts stay in `src/lunar_data`, and generic
  refs/manifests stay in `src/data_core`.
- Let the route-motion contract become `suite-adapter-ready` only after the
  route gates allow traversal.
- Add a second lunar site only after the first site has a clean route-gate
  story.
- Keep live browser behavior in `ui/rabbita-moon`; do not create another live
  UI package while this canonical surface is being consolidated.
- Add explicit suite adapters later. MoonRobo can provide Noetix/URDF gait and
  Rabbita visualization there, but adapters stay out of the standalone domain
  packages. The current first step is split between MoonMoon's typed suite
  preview payload in `src/suite_adapter_preview` and MoonRobo's typed source
  contract in `../moonrobo/src/moonmoon_adapter`. The current bridge exports the
  typed MoonRobo contract and Noetix walk-clip authority through
  `../moonrobo/cmd/moonmoon_contract` and regenerates MoonMoon suite-preview
  source metadata plus a Rabbita JS clip bridge without importing MoonRobo into
  standalone core packages. Runtime sampling now consumes that generated clip
  bridge for timing, stride, phase roles, support windows, curve metadata, and
  typed authored joint, motion, contact-frame, and motor-frame samples generated
  by MoonRobo. The compiled Moonphys suite-preview path consumes MoonRobo
  contact and motor frames directly; Rabbita's generated artifact remains a
  visual/browser freshness gate. MoonRobo now exposes
  `cmd/moonmoon_suite_evidence` as a live typed adapter evidence command, and
  MoonMoon's gait check runs it through
  `ui/rabbita-moon/check-live-moonrobo-suite.mjs`. Rabbita runtime now imports
  `ui/rabbita-moon/.generated/live-moonrobo-noetix-clip.js`, generated by
  `ui/rabbita-moon/prepare-live-moonrobo-clip.mjs` from MoonRobo live typed
  adapter commands before dev, build, export, and gait checks. The MoonBit
  suite-preview payload now ingests that live evidence summary as typed payload
  data and uses it as a readiness blocker. MoonMoon now also has a native
  suite-preview live-contract ingestion path that decodes full MoonRobo contract
  JSON, carries authored contact frames in the default suite payload, and
  reviews the parsed motion/contact/motor tables through Moonphys. The
  `cmd/suite_preview` command and Rabbita `check:live-suite-payload` gate now
  exercise that path from live MoonRobo JSON. The committed generated MoonBit
  table snapshot has been removed; plain MoonBit tests use compact fixture
  coverage, and the live command gate owns full MoonRobo integration coverage.
  Rabbita now generates an ignored local E1 assembly asset bridge from the
  downloaded package and renders a second Three.js 3D character from all 25 URDF
  STL link visuals, with bounded `viewport-voxel-area-silhouette-v1` reduced
  geometry for realtime walking. Full-STL source readiness is validated by the
  generated bridge and contract checks, not by browser-side parsing during the
  animation loop. `npm run check:gait` is now the fast viewport/runtime gate;
  `npm run check:gait:heavy` runs the full MoonRobo/Moonphys integration chain.
  Rabbita now also has a primary third-person Three.js viewport combining the
  reduced E1 robot and the lunar heightfield terrain in one walking scene.
  The next
  implementation targets are visual gait polish, terrain IK completion, and
  durable evidence consumers.

## Non-Goals

- No committed `output/` tree.
- No Python verification layer for core product behavior.
- No hidden browser bundle under `src/ui`.
- No robot- or job-runner-specific compatibility code in the standalone model.
- No robot-specific gait asset, walk primitive, or URDF animation system inside
  `src/moonphys`.