RFC-008 — Outer planets + dwarf planets in /plan

Status · Decided · closed by ADR-028 (2026-05-02) Date · 2026-05-02 TA anchor · §components/lambert-worker · §components/plan-screen Related PRDs · PRD-002 (Mission Configurator) Related UXSs · UXS-002 (Mission Configurator) Related ADRs · ADR-008 (Lambert worker), ADR-022 (Lambert protocol), ADR-023 (mobile magnifier), ADR-026 (multi-destination v0.1.6 / 5 destinations), ADR-028 (this RFC's closure) Why this is an RFC · v0.1.6 (ADR-026) shipped 5 destinations: Mercury, Venus, Mars, Jupiter, Saturn. Three planets and several dwarfs were explicitly deferred to v0.3.0. Adding them isn't trivial: Uranus's Hohmann transfer takes ~16 years, Neptune ~30. Pluto's eccentricity (e=0.249) breaks the circular-orbit approximation we use elsewhere. And every outer-planet mission realistically uses a gravity-assist trajectory, which we don't model. This RFC asks: what scope, what scaling, what teaching frame.

The question

The user feedback after v0.1.6: "we should also support outer planets and Pluto." Implementation has three open questions, each with multiple defensible options:

1. Y-axis scaling for transit times that span 5–35 years.
2. Whether to model gravity-assist trajectories, which dominated every real outer-planet mission.
3. Which dwarf planets, if any, to include — and how to handle Pluto's eccentric orbit.

Use cases

• STEM student opens /plan, picks Neptune, sees a porkchop with Y-axis spanning ~30 years and discovers viscerally that "Voyager 2 took 12 years" only because of the Jupiter gravity assist — direct Hohmann is much longer.
• Curious learner picks Pluto, sees no convergent Hohmann transfer in our 0–4 year departure window: the launch windows are decades apart. The plot teaches "this is why New Horizons existed at all."
• Teacher uses Uranus + Neptune as the educational outliers — students who internalise Mercury's ∆v cliff (v0.1.6) and Saturn's 12-year cycle now confront the fact that there are still planets we've barely visited.
• Contributor asks: "where are the dwarfs?" — RFC-008 settles whether Ceres / Eris / Makemake / Haumea ship.

Goals

• Each new destination gets its own pre-computed porkchop grid (per ADR-026's pattern).
• Outer-planet transfer times legible at 112 × 100 grid resolution (preserve ADR-023 magnifier contract).
• Honest about gravity-assist: the porkchop shows direct trajectories only; gravity-assist as a separate teaching layer if at all.
• No regression for v0.1.6's 5 destinations.

Constraints

• ADR-008 + ADR-026 lock the Lambert solver + pre-computed grid pattern. New destinations follow.
• ADR-023 locks the 112 × 100 grid resolution for the mobile magnifier. Transfer-time ranges must scale rather than the grid.
• Lambert convergence at extreme distances (Pluto perihelion ~30 AU; aphelion ~49 AU) is numerically tricky — Lambert's iterative solution can diverge for very-high-energy or grazing transfers.
• Build-time data budget — v0.1.6's 5 grids were ~110 KB each (~550 KB total). Adding 3 planets + 4 dwarfs = 7 more grids ~770 KB. Acceptable per ADR-016 budget but worth noting.
• Eccentricity — every other destination uses a circular-orbit approximation (a only). Pluto's e=0.249 makes that insufficient; either accept the simplification (label "Pluto's perihelion-only fly-by"), or add e + L0 to the destination model.

Options

Y-axis scaling (transfer times span 5–35 years)

Option YA-A — Per-destination range with year ticks. Same as v0.1.6's two-tier (days for inner, years for outer). Tof for Uranus: [3000, 6500] days = ~8–18 years. Tof for Neptune: [10000, 20000] days = ~27–55 years. The plot reads as "wide" but legible.

Option YA-B — Logarithmic Y-axis. A log-scale TOF axis would compress the multi-decade range and let Mars + Neptune display side-by-side in comparison views. Educational moment compromised: porkchops are about cheapness vs date, not cheapness vs log(date). Users would have to learn the log axis before reading the plot.

Option YA-C — Drop multi-year missions; show only "fast" trajectories. Uranus in 8–10 years, Neptune in 12–15 years — these are gravity-assist trajectories. Can't show direct-Hohmann at all because they're too long for the user to plan around. Educational frame: "this is why we use Jupiter gravity assists."

Gravity-assist modelling

Option GA-A — No gravity-assist. Pre-computed porkchops show direct-Hohmann only. Honest about the limitation: a small footnote on outer-planet panels says "real missions use planetary gravity assists; this view shows direct trajectories only." Cleanest scope.

Option GA-B — Two grids per outer destination: direct + Jupiter-assisted. Toggle on /plan switches between them. Doubles data + Lambert work. The Jupiter-assist grid would require multi-leg Lambert (still solvable but materially more complex math).

Option GA-C — A "VEEGA / Voyager-style" preset for each destination. Hardcoded gravity-assist trajectories from real missions (Voyager 2, Galileo, Cassini, New Horizons) shown as reference points overlaid on the direct-Hohmann porkchop. Educational power; engineering scope manageable; doesn't require a generalised gravity-assist solver.

Dwarf planets

Option DW-A — Skip dwarfs entirely. Stay at 3 outer planets (Uranus, Neptune, Pluto). Pluto already a dwarf-planet edge case but is the only one with a flown mission (New Horizons) so users expect it.

Option DW-B — Add Ceres + Pluto only. Ceres because Dawn flew there (2015 orbit insertion); the asteroid-belt context matters. Pluto because of New Horizons. Skip Eris/Makemake/Haumea — no flown missions, very long transfers.

Option DW-C — All four dwarf planets plus Pluto. Educational completeness; data scope grows but is tractable. Eris's e=0.43 and 558-year orbit make even direct trajectories impractical to plot legibly.

Open questions resolved

1. OQ #1 — Pluto's eccentricity. RESOLVED: extend DestinationConstants with optional e field. Pluto uses it; everyone else inherits the v0.1.6 circular approximation. Backward-compat preserved.
2. OQ #2 — Lambert convergence at multi-decade transfers. RESOLVED: add a per-destination convergence-tolerance fallback. Cells that fail to converge render as DV_FAILED (already the convention). Document expected failure rate per destination in the JSON's credit field.
3. OQ #3 — UI affordance for "this trip is decades long". RESOLVED: outer-planet panels surface a one-line caveat banner "Direct trajectory shown — real missions use gravity assists" matching the v0.1.7 sparse-data caveat pattern.
4. OQ #4 — Should /fly support outer-planet trajectories? RESOLVED: yes, but with a simplified arc (single half-ellipse, no gravity-assist visualisation). The arc reads "long curve" rather than the real trajectory.
5. OQ #5 — Dwarf inclusion timing. RESOLVED: Pluto + Ceres in v0.3.0. Eris / Makemake / Haumea deferred to a possible v0.4 if user demand emerges; their orbits don't read well on the porkchop format.

Goals for the closure ADR (ADR-028)

The ADR locks:

• Final destination list for v0.3.0 (Uranus, Neptune, Pluto, Ceres = 4 new entries; total now 9 destinations)
• Y-axis scaling rule (Option YA-A — per-destination range with year ticks)
• Gravity-assist scope (Option GA-A — direct-trajectory only with caveat banner; Option GA-C reference trajectories deferred to v0.4)
• Schema additions to DestinationConstants (optional e field for Pluto)
• Pre-computed grid contract reuse from ADR-026 (no new schema; per-destination JSON files)
• /fly arc geometry handling for multi-year trajectories (single ellipse + caveat)
• Mission-data implications: do existing missions (Voyager 2 to Uranus + Neptune; Dawn to Ceres; New Horizons to Pluto) get added to the catalog? — yes, in scope for v0.3.0.