Stage timeline shift: December is the Prototype release, Alpha is Summer 2027

Status: EXECUTED 2026-08-31 (operator decision, relayed directly in session). Subject: docs/business/launches/, tooling/scripts/classify-milestone.mjs, assign-milestone.yml. Supersedes the dates in: 2026-08-14 launch docs restructure. Its structure (four stages, one page each, sequential phases, stage definitions) is kept; its "December is Alpha" conclusion is reversed.

What changed?

	Before	After
Prototype	Now, continuous, no release of its own	Now, releasing December 2026: feature-complete, attacked and verified, legally cleared
Alpha	December 2026, invite-only launch events	Summer 2027: production cutover, recruitment, invite-only launch events
Beta	Summer 2027	Unscheduled, follows Alpha
1.0	Unscheduled	Unscheduled (unchanged)

Why?

• The operator's stated concern: "We aren't likely going to be 100% production ready by Dec." A December launch with real strangers requires production, and production by December is not realistic.
• The relabel fits the operator-approved stage definitions better than the old one did. Prototype's audience is internal only; Alpha's is internal plus closed testers. A December with no outsiders is Prototype by that table. Invited strangers at venues are closed testers, so the launch events are Alpha wherever they land.
• This is honest about where we are. Her words: still in prototype phase, working toward alpha.

What moved where?

• Into Prototype (from the old Alpha page): the Build, Prove, and Clear phases, the Bugs section, and the funding and grants outreach row. Funding is grants only: no shareholders, no venture capital (operator, 2026-08-31).
• Stayed in Alpha: the Ready phase (production cutover, app-store-wrapper decision, devops hardening), Recruit, Run, and the Runs-throughout rows that serve the launch (second engineer, Google Workspace and Slack, business plan close-out).
• The sorting test changed to match: "Does the December Prototype release need it? Yes, Prototype. Does it only matter once invited outsiders touch the product? Alpha."
• The milestone classifier changed with the docs. STAGE_GUIDANCE in classify-milestone.mjs is a second copy of these rules, and leaving it on the old sort would mis-file every new issue. Its security-and-privacy tie-break flipped from Alpha to Prototype, because that work now gates the December release.

What was adjusted the same day (round 2, operator answers)?

• Legal is not a December blocker. Her words: "They aren't blockers, but perhaps agree this should be folded into alpha." The Clear phase (ToS and Privacy Policy, trademark, business legalities and governance) moved to Alpha as its Phase 1, with a note that long-lead items still start during Prototype. The "Privacy architecture in place" row stayed in Prototype (folded into Build): it is engineering, and plaintext phone numbers are hard to walk back regardless of launch dates.
• Safety-comfort measurement moved to Alpha's Run phase. The instrument is used at the events; blocking December on its design was stricter than the shift required.
• Penetration testing runs twice. The first pass stays a Prototype gate; a "Pre-launch penetration re-test" row joined Alpha's Ready phase, because the December pen test proves the December build, not the production build outsiders touch six months later.
• Code names settled (final, later the same day): strictly alphabetical, stages included. Prototype is Pilot Light (outside the alphabet, as Prototype sits outside the versioned sequence), Alpha is Aurora, Beta is Beacon, and versioned releases from 1.0 continue the alphabet: 1.0 is Candela (the scientific unit of brightness, Latin for "candle"; approved same day), later releases named when planned, with Dawn, Ember, Flare, Glow, Halo penciled as the runway. This replaces the old arbitrary-letter list (Beacon, Ember, Kindle, Wick, Halo, Aurora); its members can re-enter at their letters (Ember at E, Halo at H, Kindle at K, Wick at W).
• The classifier guidance in classify-milestone.mjs moved legal back to the Alpha side to match.
• The admin dashboard shows the code names; everything else keeps the stage words (operator scope decision, 2026-08-31). The wick's stops read Pilot Light, Aurora, Beacon, Candela. The launch doc pages, GitHub milestones, and the issue classifier keep Prototype/Alpha/Beta as the working vocabulary, and the code names stay internal until each release ships. Refined 2026-09-01: the dashboard speaks the code names as its ONE vocabulary. Both attempts at carrying the mapping visibly on the dashboard (a "· release code names" heading suffix, then blurb glossing like "We are in Prototype (code name Pilot Light)... Aurora, our invite-only Alpha") were rejected as fluff and as confusing; the mapping now lives only in the launch docs and in each stop's screen-reader stage suffix.
• Wherever a code name appears, it must READ as a code name, not as the stage's new name (operator, 2026-08-31, settling the consistency question: these are code names, Prototype is still Prototype). The docs say "code name" beside every appearance. On the dashboard this was first implemented as a "· release code names" heading suffix; that suffix was rejected as fluff on 2026-09-01 (see the refinement in the bullet above), so the dashboard's only remaining mapping is each stop pairing its name with its stage for screen readers.

How was the phase-label design settled (2026-09-01)?

The operator brainstormed with Claude design and brought back a mockup; it is built.

• The problem, from her first live pass on deployed dev (phone): the original all-amber "underway" chips read as complete, and the row centred under the flame sprawled into the next stop. An interim one-hue-per-state fix (dim / secondary blue / amber) still "made the labels look bad", so she took the treatment to a design brainstorm rather than picking from the three rendered variants in mockups/wick-variants-420.png.
• The chosen design, from her mockup (mockups/wick-operator-mockup.png; its stage names predate the timeline shift, only the chip treatment is the decision): a phase DONE is a filled green pill with a leading check, one UNDERWAY is a filled amber pill with a leading dot, one NOT BEGUN is an empty dotted-outline pill. Fill, marker, and hue all change together, so no single channel carries the state.
• This supersedes "amber strictly means done" from earlier the same day. Amber now means underway (the flame and the current stop are already amber, so amber reads as "where the fire is") and green means done. The misread her rule existed to stop is prevented by the marker + fill split instead: done is the only state with a check, not begun the only one without a fill.
• Token mapping, measured on the black hero ground: done text is --success-text on a 16% --success tint (7.30:1; the --success fill token itself is only 3.20:1 as text), underway text is --accent-500 on a 14% tint (8.25:1), the dotted outline is --muted at 60% (~3.3:1, over the 3:1 non-text bar), and the failed chip moved to a --danger tint fill so a read failure cannot look like a not-begun phase. All chips carry the same 1px border (transparent on filled states) so state changes never change chip size.
• The chips stack three per row, packed, centred under the current stop, and the target is DESKTOP (all operator, 2026-09-01). Three follow-ups landed in sequence: "stack the labels by defaulting to 3 per row"; then her deployed pass rejected the first implementation (a grid of three max-content columns, whose per-column sizing punched a hole between two narrow chips); then "those labels need to be centered" plus "keep this to desktop view", so the block centres under the Pilot Light stop like her mockup and the phone layout is deferred to its own dedicated pass.
• Where it lives: apps/admin/src/admin/dashboard/LaunchTimeline.jsx (PhaseProgress; the check is lucide's Check, the dot a currentColor span, both aria-hidden since the sr-only state word already speaks) and AdminDashboard.css under .launch-wick__steps. A new EveryChipState story shows all three states in one row; the built result at phone width is mockups/wick-chosen-420.png.
• Green is strict, confirmed at her ask: a phase chip goes green only when EVERY row in that phase is checked off. stagePhaseState in releaseFeed.js returns done only when done === total, a unit test holds it, and the strictness is deliberate: the hardcoded row this replaced once called Build done with eight rows open.

What still has to happen?

• Resort the GitHub milestones: DONE 2026-09-01. All 92 issues then under the Alpha milestone were re-classified against the shifted sorting test; 74 moved to the Prototype milestone and 18 stayed in Alpha (the launch events and recruitment rows, safety-comfort measurement, the pre-launch penetration re-test, and production-facing follow-ups). One remaining manual touch for the operator: the Alpha milestone's description and due date should say Summer 2027 (the GitHub API surface available in the agent container cannot edit milestone objects, only assign them).
• Re-measure the classifier. The 78% agreement was scored against the pre-shift hand sort. Now that the resort is done the re-measurement is unblocked, but it has to run on the dev VM: tooling/scripts/classify-milestone-dryrun.mjs needs the gh CLI and an ANTHROPIC_API_KEY in .env.local, and the remote agent container has neither.
• The canonical business plan Google Doc needs almost nothing. Verified by reading it in full (2026-08-31): its roadmap is deliberately milestone-anchored ("The dates are not fixed; the milestones are"), so the shift contradicts nothing. The one stale spot is section 9's "Working timing assumption" paragraph (Phase 1 done 2 to 4 months from the April sign-off, Phase 2 immediately after), which self-describes as a placeholder to revisit monthly. Worth a one-paragraph touch whenever the operator next edits the doc, nothing more.
• An unstated mapping worth writing down somewhere, someday: the repo's Alpha (San Diego only, invited group, non-paying pilot venues) corresponds to the plan's Phase 1 pilot, not its Phase 2 dual-market paying launch. Both documents are consistent under that reading, but neither states it.