Admin dashboard launch timeline, post-timeline-shift - Manual Test Plan

Field	Value
Branch / PR	claude/timeline-release-roadmap-7og3ft
Environment	Deployed dev admin portal (local admin login is blocked by the ADC custom-token limitation, so this plan runs post-merge on dev)
Build flags / config	n/a
Build (commit)	fill in at test time
Tester

What changed: the hero blurb and the wick's stops now say Prototype releases December 2026 with Alpha at Summer 2027 and Beta undated; the flame moved from Alpha to Prototype; the progress chips under the flame now derive from PROTOTYPE.md (five phases) instead of ALPHA.md.

Automated evidence already in hand (2026-08-31): all 51 releaseFeed unit tests pass, the full admin suite passes (714 tests), and running the real parser against the real PROTOTYPE.md produces exactly the five chips below (Environment, Build, Gates, Prove current; Internal tools not started).

---

Scenario 1: The hero blurb tells the new timeline

Steps

1. Open the admin portal Dashboard.
2. Read the paragraph under the Dashboard heading.

Expected: it says we are in Pilot Light, releasing December 2026 (December 2026 in the accent color), with Aurora, our invite-only launch, to follow in Summer 2027. One vocabulary, the code names: no "(code name ...)" glossing and no "our invite-only Alpha" phrasing (both shipped and were rejected as confusing, operator 2026-09-01). No text says anything starts in December other than Pilot Light.

Result: [ ] pass [ ] fail [ ] blocked Actual: Evidence: Follow-up:

Scenario 2: The wick's flame sits on Prototype and the dates are right

Steps

1. On the Dashboard, look at the launch timeline band.

Expected: the band's heading reads plain "Launch timeline" (a "· release code names" suffix shipped briefly and was rejected as fluff, operator 2026-09-01; the code names are the dashboard's one vocabulary and need no gloss). The stops read the internal code names, in order: Pilot Light (the current stop, carrying the big flame, glow, and ring) with "Dec 2026" as the only line under it, Aurora ahead with "Summer 2027" under it, Beacon with no date line at all, and Candela last with no date. Everything right of the flame is the perforated line. Nothing clips at the left edge: the Pilot Light name, its date, and the chip row all render fully inside the band. Bonus check in devtools: each stop's name carries hidden screen-reader text pairing it with its stage, e.g. "Pilot Light (the Prototype release)".

Result: [ ] pass [ ] fail [ ] blocked Actual: Evidence: Follow-up:

Scenario 3: The progress chips derive from the Prototype page

Steps

1. Under the flame, count the chips and read their labels.
2. Press Refresh and watch the row re-render.

Expected (desktop view; the phone layout is deferred to its own pass, operator 2026-09-01): five chips reading Environment, Build, Gates, Prove, Internal tools, stacked three per row, each row packed tight and the block centred under the Pilot Light stop, matching the operator's mockup. Three states, per the operator's 2026-09-01 mockup: done = a filled green pill with a leading check, underway = a filled amber pill with a leading dot, not started = an empty dotted-outline pill, so nothing underway can read as complete. As of 2026-09-01 the first four are amber-dot underway and Internal tools dotted; if the plan has moved since, the chips should match whatever docs/business/launches/PROTOTYPE.md says at test time, which is the point of the derivation. Refresh must not error and must not show six Alpha-named chips (Build, Prove, Clear, Ready, Recruit, Run), which would mean a stale cached read of the old page.

First live pass (operator, phone, 2026-09-01): FAIL on the original design, twice. All-amber underway chips read as complete, and the row centred at the 22% stop sprawled toward Aurora. The spacing was fixed same day (row moved under the band); the chip treatment went through a design brainstorm and landed on the operator's check/dot/dotted mockup, built and verified in Storybook at 420px and 1180px. Re-test this scenario after the fix deploys.

Result: [ ] pass [ ] fail [ ] blocked Actual: Evidence: Follow-up:

Scenario 4: The failure state still says so (control)

This is the falsifying arm: our change repointed the read, so a wrong path would surface here, not in the happy path.

Steps

1. In the browser devtools network tab, confirm the Dashboard fetches docs/business/launches/PROTOTYPE.md through the docs API (not ALPHA.md).

Expected: exactly one stage-page fetch, for PROTOTYPE.md. If instead the page still fetches ALPHA.md, the repoint did not deploy and the chips are lying about their source even if they happen to look plausible.

Result: [ ] pass [ ] fail [ ] blocked Actual: Evidence: Follow-up: