Roadmap: time, missions, satellites, interplanetary travel

[apresmoi]

One place to track what we want to build next. Each item is a wish, not a plan — scope and approach get decided when someone picks it up.

Ordered after alowpoly's review: the sections run in dependency order, because nothing that moves through time works properly until something owns time. Catalogue work runs in parallel; operational work is its own lane.

Foundation

What has to be true before missions, observatories or travel can be built honestly.

• One owner for simulation time — everything that moves reads the same clock
• One implementation of navigation and orbits, not two
• One contract for a prepared trajectory, whatever produced it
• Reconstructed history, predicted position and designed transfer are told apart, never blurred
• Every trajectory states where it is valid, how accurate it is, and what it came from
• The shell can carry time controls without becoming a single large file
• Fix the absolute kernel paths in Phoebe and Tethys
• Settle whether an object may carry both inventory kinds, and correct the contract either way

Time

• Replay: watch the system move over a chosen span
• Fast forward and rewind, with speed control
• Go to a date, and to a named event
• Share a view that carries its moment in time
• Show which moment is on screen, and how fast it is running
• Moving through time is repeatable — the same request gives the same result
• Respects reduced motion

One mission, proven end to end

Before broad coverage: a single bounded mission that exercises time, trajectory and events together. Cassini is the candidate — the repository already has its kernel bank.

• One tour segment, with one encounter
• Time controls working against it
• Seek to a named event
• A shareable link that lands on a moment

Missions

• Voyager 1 and 2, with their real trajectories
• Moon missions, Apollo first
• Mars missions: orbiters, landers, rovers
• Outer-system missions: Galileo, New Horizons, Juno
• A mission's path in time, not only its end state
• Where a spacecraft is right now, for the ones still flying

Satellites and telescopes

• Hubble
• JWST
• The other space telescopes, as a set
• Earth-orbit satellites worth showing
• 3D models for them
• What each one is looking at, and what it has seen

Travel between planets

Not the camera. Today "fly to" moves the viewer to a body — it is a way of looking around, and it is not what this is about. This is the real journey: the orbit a spacecraft would actually fly, when it is allowed to leave, and how long it is in transit. A path you could launch, not a path the camera takes.

Its own program rather than a feature of mission replay: it reuses the clock and the trajectory contract, but designing a transfer is a different problem from replaying a flown one.

• Pick an origin and a destination, get the realistic trajectory
• Departure windows: when you can leave, and when you cannot
• Travel time for each window
• The transfer orbit drawn in the scene
• Any planet pair, not just Earth to Mars
• Compare windows across the next several years
• Show why the windows exist — the geometry that opens and closes them
• Say plainly what the model assumes, and check it against an independent source

Catalogue objects

Runs in parallel with everything above. Today: M1, M2-9, M8, M31, M33, M42, M45, the Helix, the LMC and the SMC.

• The rest of the Messier catalogue
• NGC objects
• IC objects
• Decide which ones are worth a full 3D bake and which stay catalogue facts
• Every one of them reachable by its catalogue name, and by its common name
• Sources and credits recorded for each

Operational

Its own lane, not blocking the work above.

• Add the R2 publishing credentials so the on-demand publish workflow can run (ci: publish an object's prepared assets to R2 on demand #380)
• Cut what loads before anything renders — decided by what the production bundle actually contains, not by file names
• Shrink world-context.json, most of which is orbit detail that is never drawn
• Split the volume lens banks so only the lens actually shown loads
• Derive prepared coordinate precision from a positional-error budget per scale, rather than a chosen number of decimals
• Make prepare:facilities refresh the inventory that pins what it rewrites
• Prune the orphaned R2 keys (~34 GB)
• Run real browser checks on pull requests
• Cache header for the catalogue fragment
• Make a cancelled CI job say why it was cancelled
• Correct the payload figure quoted in perf(site): defer volume lens bank fetch until selected or in view #373 (1.27 MB, not 3.12 MB)

[alowpoly]

The direction is strong, but I think the roadmap needs an explicit dependency order before these become implementation issues. The current runtime has animation playback permission, but it does not yet have a simulation-time owner. The astronomy package can evaluate bodies at epochJdTt, and the preparation side already has SPICE support; the missing seam is the contract between those systems.

I would order the work as follows:

1. Runtime consolidation and correctness

   • Make renderer navigation/orbit the single implementation and retire the substantial duplicate under src/platform.
   • Separate prepared-world-context parsing from its mounted DOM runtime.
   • Split shell controllers out of planet-shell-client.mts before adding time controls to it.
   • Settle the dual-inventory contract and fix the absolute kernel paths first; those are correctness issues rather than roadmap features.

2. One simulation-clock contract

   • Own epochJdTt, rate/direction, paused/playing state and valid bounds in one place.
   • Make replay, speed control, go-to-date, named-event seeking, visible time and URL sharing acceptance criteria of that subsystem rather than independent features.
   • Define deterministic stepping, history restoration and reduced-motion behavior.

3. One prepared trajectory contract

   • Record frame, time scale, validity interval, source/kernel identity, interpolation method, maximum error, LOD/sample strategy and named events.
   • Explicitly distinguish reconstructed mission history, predicted/current ephemerides and designed transfer trajectories.
   • Keep SPICE interpretation at preparation time; the browser should interpolate prepared states.

4. One bounded mission proof before broad coverage

   • Cassini looks like the best first slice because the repository already has a Cassini kernel bank and substantial Cassini source handling.
   • A bounded Saturn-tour segment with one encounter, time controls, event seeking and a shareable time URL would prove the full contract before attempting Voyager/Apollo coverage.

5. Generalize missions and observatories

   • Extend the proven moving-entity contract to Voyager, Galileo, New Horizons, Juno, Hubble and JWST.
   • Add models and telescope pointing after trajectory/time semantics are established.

6. Treat interplanetary planning as a separate program

   • “Any planet pair” needs a bounded transfer model, a Lambert/equivalent solver, independent oracle comparisons and clear disclosure of assumptions. It can reuse the clock and trajectory transport, but it is not mission replay.

Catalogue expansion can remain an independent lane, provided catalogue facts stay distinct from objects selected for full 3D preparation.

A few operational-item notes:

• “Code-split the scene router” should start with a production bundle-composition measurement. The source router is about 47 KB, while planet-shell-client.mts and prepared-world-context are each about 76 KB; a chunk named after the router may mostly contain its imports. Split by ownership and lazy-load boundary rather than filename.
• Do not round prepared coordinates to an arbitrary decimal count. Establish positional-error budgets for each spatial scale, then derive serialization precision from them.
• World-context shrinking, lens-bank splitting and browser PR checks belong in the codebase lane. Credentials, publishing and R2 pruning can remain in the operations lane.

Suggested high-level structure for this issue: Foundation → Cassini proof → missions → observatories → travel, with catalogue expansion parallel and operational work tracked separately.

[apresmoi]

Restructured the body along this ordering — thanks, the dependency argument is right: nothing that moves through time works honestly until something owns time.

Adopted as written:

• Foundation section added, leading with one owner for simulation time, one navigation/orbit implementation, and one trajectory contract that distinguishes reconstructed history from predicted position from designed transfer.
• Cassini as the single bounded proof, before Voyager or Apollo — its own section between Time and Missions.
• Travel is its own program, noted in the section itself: it reuses the clock and the trajectory transport, but designing a transfer is a different problem from replaying a flown one. Added an item for stating the model's assumptions and checking them against an independent source.
• Lanes separated — catalogue runs parallel, operational is explicitly non-blocking.
• The kernel paths and the dual-inventory contract moved out of Operational into Foundation, as correctness rather than roadmap.

Both operational corrections taken:

• The router item no longer names a file. I had measured the built chunk at 1.05 MB brotli and written the item as "code-split the scene router", which mistakes a chunk for its contents — the item now says the decision comes from what the production bundle actually contains.
• Coordinate rounding is now "derive precision from a positional-error budget per scale" rather than a decimal count.

One thing I would not sequence as strictly: the kernel paths and the inventory contract are small and independent, so they need not gate the clock work even though they sit in Foundation. Everything else in that section genuinely does come first.

Kept the items at the level of what we want rather than how — they should turn into their own issues as they get picked up, with the checkboxes here linking to them.