RFC-026 — Multi-destination porkchop expansion (v0.8)

Status · Draft Date · 2026-06-09 Target · v0.8 Tracked by · GH issue #312

Why this is an RFC. The v0.7 /plan trimmed itself to Mars-only per ADR-076 because the Lambert-grid solver only had Mars data in static/data/porkchop/. v0.8 needs to re-expand /plan to all twelve advertised destinations (Mercury, Venus, Mars, Vesta, Ceres, Psyche, Jupiter, Saturn, Uranus, Neptune, Pluto, Bennu) — with honest landing porkchops for the inner-system + belt targets and honest flyby porkchops for the gas/ice giants and Bennu. This RFC locks the data shape, generation pipeline, and UI-restore plan so the implementation slices can start cleanly.

Gating sentence: Implements the multi-destination expansion of /plan deferred by ADR-076 — landing porkchops for Mercury, Venus, Vesta, Ceres, Psyche, and flyby porkchops for Jupiter, Saturn, Uranus, Neptune, Pluto, Bennu; tracked by issue #312.

Goal

Re-expand the /plan destination dropdown from Mars-only (v0.7, per ADR-076) to the full twelve-destination set, with honest porkchop coverage at each.

Scope (v0.8)

Landing porkchops — Lambert-grid shape identical to Mars (per ADR-026):

• Mercury (1-year synodic period; tight launch windows; high V∞)
• Venus (1.6-year synodic; favourable ∆v; multi-month transit)
• Vesta (3.6 AU semi-major; ~24-month transits; sample-return scope)
• Ceres (2.77 AU; Dawn flight heritage)
• Psyche (3 AU; M-class asteroid mission flight heritage)

Flyby porkchops — different shape (per ADR-028):

• Jupiter, Saturn, Uranus, Neptune, Pluto — gas/ice giant flybys; V∞-vs-Tof contour with NO LOI ∆v term (the destination's gravity well doesn't matter for a flyby)
• Bennu — single-asteroid rendezvous porkchop (close approach geometry)

Non-goals (v0.8)

• Gravity-assist trajectory planning (the GRAVITY_ASSIST_CAVEAT_DESTINATIONS constant in /plan/+page.svelte just adds a UI banner — the optimizer still treats every transfer as direct)
• Multi-body trajectory optimization (JUICE-style gravity-assist sequencing)
• Real-time porkchop solving (everything is pre-computed grids, same as Mars)

Data layer

Each destination ships a Lambert grid as static/data/porkchop/<dest>.json:

{
  "destination": "venus",
  "type": "landing",
  "departure_window": ["2026-01-01", "2030-12-31"],
  "arrival_window": ["2026-06-01", "2032-06-01"],
  "grid": { "c3": [[…]], "v_infinity": [[…]] },
  "source": "Patched-conics + JPL DE441 ephemeris"
}

Generation: a Python or TypeScript Lambert solver computes c3 and V∞ across the 2-D grid of departure × arrival dates, using JPL DE441 planetary ephemerides for the body positions.

For flyby destinations the JSON shape drops the LOI ∆v field and emphasises V∞ at arrival.

UI changes

Mostly a one-line revert in /plan/+page.svelte:

// v0.8: re-expand per RFC-026.
const DESTINATION_IDS: DestinationId[] = [
  'mercury', 'venus', 'mars', 'vesta', 'ceres', 'psyche',
  'jupiter', 'saturn', 'uranus', 'neptune', 'pluto', 'bennu',
];

FLYBY_ONLY and GRAVITY_ASSIST_CAVEAT_DESTINATIONS are already in place as dead code (kept by ADR-076 for exactly this purpose). The destinationLabel() switch already covers every destination.

Open UX question: should the dropdown group destinations (inner / outer / belt) for scannability now that there are twelve? Deferred to a UX iteration once the data layer is in.

Risks

• Lambert convergence at extreme grid corners — some destinations have launch windows that don't converge cleanly (e.g. Pluto). Acceptance criterion: every destination produces a grid where ≥95 % of cells solve; the remaining holes are filled with explicit "no transfer" markers.
• Outer-system computation time — Pluto + Neptune flyby grids over a 10-year window take longer to generate than Mars. One-off generation cost, not user-facing.
• /plan UI scaling — twelve dropdown options is more than Mars-only, but still a flat list — no design change needed.

Acceptance

• All 12 destinations plot a real porkchop with no empty regions for in-bounds dates
• /plan?dest=<any> deep-links work for all 12
• preflight green; new spec covers "every destination renders without console errors"
• ADR-076 + RFC-026 + issue #312 closed
• v0.8 milestone shipped