Launch docs restructure: four stages, one doc per stage

Status: PROPOSED 2026-08-14, awaiting operator sign-off. Nothing moved yet. Subject: docs/business/launches/README.md -> docs/business/launches/Supersedes the structure of: 2026-08-10 launch page restructure (EXECUTED). Its decisions are INHERITED, not reopened: release at the top with phases as subsections, the column set, three P-ratings scoped per release, and stable phase numbers. Related: #833 (broken doc links), #840 (guide consolidation).

The problem

Two problems, one structural and one definitional.

1. The milestone vocabulary and the doc vocabulary do not match. GitHub carries Prototype / Alpha / Beta / Testing. The doc carries Alpha / Beta. assign-milestone.yml auto-stamps Prototype on every issue and PR at open, with a backfill mode, so Prototype holds 153 open issues and Alpha holds 1. Nothing is mis-filed; nothing is being sorted either. The milestone is a default, not a judgment.

2. There is no agreed definition of what the stages MEAN, so the boundary gets re-argued each time. Operator supplied the industry-standard definitions (2026-08-14) and asked that they become the standard.

The definitions (operator-approved 2026-08-14)

Stage	Goal	Audience	Stability
Prototype	Test if an idea works, behaves, or feels right	Internal developers and designers only	Very low; parts are temporary
Alpha	Build and test the foundational, working core	Internal team plus closed testers	Low to medium; major change expected
Beta	Find edge-case bugs, balance performance, refine usability	External users, wider public, targeted opt-in groups	Medium to high; core is stable
1.0	Deliver the final, polished product	General public	High; patches and updates only

We are in Prototype now. Alpha is December 2026. Beta is Summer 2027.

Why December is Alpha and not Beta

Raised and settled 2026-08-14. The four rows are not equally weighted: Goal is the discriminator, audience and stability are consequences.

Alpha's goal is building and testing the foundational working core. Beta's is finding edge-case bugs and refining usability. December exists to answer whether two anonymous strangers actually approach each other, and whether people felt safe doing it. Nobody runs a Beta to discover whether their core mechanic exists. Scale agrees: roughly thirty invited people at one or two venues, run as scheduled events under heavy monitoring, is a closed cohort.

December ships at Beta-grade polish deliberately, because real strangers meet through it. That is a choice to over-build for a safety-sensitive audience, not evidence of a later stage. "Arrive complete" is a posture, not a phase.

"Alpha" also correctly sets participant expectations low, which matters more than how the word sounds to a venue or an investor.

The word "phase" keeps its existing meaning

Stages are Prototype / Alpha / Beta / 1.0. Phases remain the categorical groupings (Core mechanics, Safety, Analytics, Legal...) exactly as the 2026-08-10 plan established. The fourth stage is 1.0, not "Release", specifically to avoid colliding with the ordinary word.

The sorting test

If December were cancelled tomorrow, would we still do this?Yes -> Prototype. No -> Alpha.

Checked against the live backlog:

Work	Still do it?	Stage
Invisible lantern names, credential colocation	Yes	Prototype
Lantern CLI, context sync, intranet	Yes	Prototype
Admin mobile layout	Yes	Prototype
Trademark clearance	Not urgently	Alpha
Pilot venue agreements, launch events, the pitch	No	Alpha
ToS and Privacy Policy	Gates public signup	Alpha
Penetration testing, production cutover	No	Alpha

Consequence: the 153-vs-1 split is roughly accurate. We are genuinely in Prototype. Alpha is near-empty because the launch work was never written down, not because it was mis-filed. The fix is moving roughly fifteen issues to Alpha and turning off the auto-stamp, NOT re-triaging 153.

Phases become sequential (operator direction, 2026-08-14)

Superseding the "rename phases to tracks" idea. The operator's question was better: make phases actual phases, ordered by what unblocks what, so the doc answers "what do we do next".

The ordering was already latent and we flattened it out. The doc states one dependency out loud ("Recruitment sits last on purpose: pitching a venue before the thing works is how you burn a relationship you only get once") and leaves the rest implicit. You cannot harden what is not built, cannot write Terms until you know what shipped, cannot recruit venues until you can show them something safe, cannot run events until you have recruited anyone.

The June restructure traded ordering for accuracy about releases. This gets the ordering back without losing that accuracy, because each release now carries its OWN ordered phases.

This also dissolves the vocabulary collision flagged earlier: Safety and Analytics currently appear both as phase headings and as Category values. Under sequential phases, Phase = WHEN, Category = WHAT IT IS ABOUT. Each word means one thing, and no new vocabulary is invented.

Alpha, worked example

#	Phase	Entry condition / done when	State today
1	Build	The product works end to end	Nearly done
2	Prove	It has been deliberately attacked and verified	Not started. The real gap.
3	Clear	Legal clearance obtained	In progress, mostly operator
4	Ready	Distribution decided, production cut over	Not started
5	Recruit	Venues, merchants and invitees committed	Not started, gated on 2 and 3
6	Run	The launch events	December

Sorting the CURRENT Alpha content into it:

1. Build (product works): chat, frens, invite gate, light a lantern, phone+PIN, profiles, venue data, push, block, report, moderation pipeline, location gating, merchant provisioning/signup/offers/moderation/redemption, admin moderation surfaces, venue creation, event pipeline, ad telemetry, deletion and retention (all Built). Remaining: polish and refinement, embers, Google Places, performance, interest filtering, venues search and filters, splash refinement, ad network surface, attribution no-POS, merchant and venue dashboards.

2. Prove: live two-account E2E, break-it walkthrough (#193), full manual code review, penetration testing (#865), real-device testing, iOS PWA push verification (#722), safety-comfort measurement (#867). Almost nothing here is started, and this phase is what stands between a working build and a defensible launch.

3. Clear: ToS and privacy policy (#141, #837), trademark (#140), business legalities, privacy architecture completion (#523).

4. Ready: app-store-wrapper decision (#163), production cutover (#76), devops hardening (#164: required checks, rollback path, deploy monitoring), pre-launch token and secret rotation.

5. Recruit: pilot venue agreements (#868), repeatable pitch (#869), sales and onboarding process (#870), partnership model, partner network activation, marketing and GTM (#326, #199), "scheduled lanterns" positioning.

6. Run: target launch events (#871), running them, monitoring while live.

Runs throughout

Genuinely parallel work that gates nothing and is gated by nothing, kept out of the sequence rather than fudged into it: hiring a second engineer (#873), Google Workspace and Slack (#872), keeping every P0 tracked as an issue, and the business plan close-out.

The phase order means "you cannot FINISH this phase before the previous one", not "you cannot start it." Trademark can start today; it just cannot be the reason December slips while Prove has not happened.

Why this beats the categorical version

It answers "what do we do next", which nothing in the current doc does. "153 issues in Prototype" says nothing. "We are finishing Build and have not started Prove" names the risk, and is true.

Prototype, same treatment

Prototype is Build for the TEAM rather than the product, so it gets a shorter sequence: build the environment, prove it works, then it runs continuously. That is the flat-buckets answer arrived at properly rather than asserted.

Structure

docs/business/launches/
  README.md       parent: release table, the definitions, the sorting test,
                  shared P-rating and Status legends, links out, history
  PROTOTYPE.md    what we are building and proving now
  ALPHA.md        December 2026
  BETA.md         Summer 2027

README.md rather than LAUNCH.md so browsing to the directory lands on it automatically; its H1 says "Launch Plan".

Unscheduled work stays in the parent, because it is short and belongs next to the release table rather than in a stage doc it has no stage for. 1.0 gets a doc when it has content; an empty file is worse than an absent one.

Option	Trade
Parent + one doc per stage (chosen)	Each stage's detail is separately readable and separately editable; the parent stays short enough to actually read. Cost: four files to keep consistent.
Keep one file	No drift risk. Rejected: already ~200 lines with Prototype still to add, and the stages have genuinely different content shapes.
One file per phase (Safety, Analytics...)	Rejected outright: reintroduces exactly the categorical-bucket error the 2026-08-10 plan fixed.

Rollout

1. git mv docs/business/timelines docs/business/launches, then INITIAL_LAUNCH.md -> README.md. Use git mv so history follows.
2. Split ALPHA.md and BETA.md out of the current content unchanged; content edits are a separate commit from the move, so the diff is reviewable.
3. Write PROTOTYPE.md from the current backlog using the sorting test.
4. Parent gains the definitions, the sorting test, and the legends.
5. Fix the ten inbound links (docs/ABOUT.md, docs/index.md, docs/business/README.md, EVENT_FIRST_GTM.md, both MERCHANT_INTEGRATION docs, DIRECTORY_DEFINITIONS.md, SEALED_IDENTITY.md, DOCS_DEPLOYMENT.md, the 2026-08-10 plan). Non-negotiable: #833 already tracks ~500 broken links and this must not add to them.
6. Update DIRECTORY_DEFINITIONS.md for the new directory.
7. Change assign-milestone.yml: stop auto-stamping Prototype. Either drop the auto-assign entirely, or keep it as an explicit fallback that also comments asking for a stage. Operator decision, not taken here.
8. Move the roughly fifteen launch-gated issues to the Alpha milestone.

Steps 1 to 6 are documentation and can land as one PM PR. Steps 7 and 8 touch a workflow and 15 issues; they can ride the same PR or split, but 7 needs her word since it changes repo automation.

Open questions for the operator

1. Does Prototype carry P-ratings? ANSWERED, yes (operator 2026-08-14), read as "blocks our ability to build Alpha".
2. Phases inside Prototype, or a flat list? ANSWERED by the sequential-phase direction: Prototype gets its own short sequence, not a flat list.
3. assign-milestone.yml: drop or downgrade? ANSWERED (operator 2026-08-14): modify it to auto-assign the correct stage via the Anthropic API. Reuse the existing pattern in lint-pr-labels.yml, which already calls Claude Haiku, validates the suggestion against an allowlist, applies it in the same run, and degrades gracefully when the key is missing. Two additions: give it the SORTING TEST as the prompt rather than a list of stage names, since the decision rule classifies far better than the vocabulary; and never overwrite a stage a human already set.

Code names

Internal until ship (operator, 2026-08-14). Light-themed and alphabetical so the sequence documents itself: Beacon, Ember, Kindle, Wick, Halo, Aurora. Reasons against publishing early, all real: a named release is a public promise, an alphabetical public sequence leaks cadence into a market with no live competitor yet, and each public name is another trademark clearance alongside the live one.