Milestone sort: 163 open issues into Prototype, Alpha, Beta

Status: proposal, awaiting operator approval. Nothing has been changed. Why now: the launch plan restructure gave the stages meaning; the milestone field has not caught up.

What is true today

162 of 163 open issues carry the Prototype milestone. One carries Alpha.

That is not drift. It is the intended result of two closed issues: "Auto-Assign Prototype Milestone to New Issues" (#81) and "Need to attach all current tasks to the prototype milestone" (#299). When Prototype was the only stage, stamping everything Prototype was correct.

It stopped being correct when the launch docs defined four stages. A field whose value is the same for every row carries no information, so today the milestone tells you nothing about when anything is due.

The two halves

A one-time sort of the existing 163, and a change to the stamping workflow so new issues stop landing in Prototype by default. Doing only the first means the sort decays from the next issue onward.

.github/workflows/assign-milestone.yml ("Assign Prototype Milestone") applies the stamp on issue open and has a backfill mode. The operator has asked for an AI classifier to replace the unconditional stamp; that is the second half.

What the sort already knows

64 of the 163 are already decided. The launch stage docs name them directly, which means the operator has already made those calls and applying them is transcription rather than judgment.

Source	Issues named	Still open
PROTOTYPE.md	34	26
ALPHA.md	67	33
BETA.md	5	5

99 are named nowhere. That is the actual work.

Proposed decision rule for the 99

Recommendation: do not classify them one at a time by reading each. Group first, decide the group, then handle exceptions. The label clusters are already close to the stage boundaries.

Cluster	Count	Proposed default	Reasoning
security	19	Alpha	Real users make a security gap a live risk rather than a theoretical one
privacy	3	Alpha	Same
bug	13	Prototype	A bug in shipped behaviour blocks the thing it is in
devops	19	Prototype	Pipeline and tooling work pays back immediately and gates everything else
documentation	10	Split	Contributor docs are Prototype; public and legal docs are Alpha
enhancement	24	Split	The largest and least uniform group, needs real reading
analytics	4	Alpha	Measurement matters once there is something to measure
refactor, ops, design, marketing	7	Case by case	Too few to need a rule

The defaults are a starting position, not an answer. Every one is overridable, and enhancement at 24 items is where the genuine judgment lives.

Phases

Phase 1: apply the 64 already decided. Mechanical, reversible, no judgment. Delivers a milestone field that is no longer a constant.

Phase 2: sort the 99 by cluster. Propose a bucket per cluster, operator approves or overrides the defaults, then apply. Exceptions handled individually.

Phase 3: resolve conflicts. Any issue named in more than one stage doc.

Phase 4: fix the stamping workflow, so new issues are classified rather than defaulted. Until this lands, every new issue re-enters as Prototype and the sort starts decaying immediately.

Phase 5: record the cutover. The 549 closed issues are left alone: they are history, re-milestoning them changes nothing and risks rewriting what actually happened. Note the date so nobody later reads pre-cutover milestones as meaningful.

Open questions

1. Are the cluster defaults right, particularly security to Alpha and devops to Prototype.
2. How much does enhancement (24) get read individually versus split by a coarser rule.
3. Does Phase 4 build the AI classifier, or just remove the unconditional stamp and leave new issues unmilestoned until someone decides.

The full lists

Every open issue below, so the sort can be reviewed rather than trusted.

Already decided: Alpha (33)

• Before launch, replace ALL tokens to ensure security compliance. (#76)
• URGENT: Trademark Search for Lantern (#140)
• Legal: Create Terms of Service (ToS) (#141)
• Code Quality: Bundle Size Optimization (Code-Splitting) (#153)
• Social: Friend System (#159)
• Retention: Gamification System (#160)
• Notifications: Push Notification System (#161)
• Mobile: Native iOS/Android Apps (#163)
• Infra: Application Monitoring & Observability (#164)
• Chats: In-App Messaging (#166)
• Core: Lanterns, Waves & Connections (#177)
• Stress Test Considerations (#193)
• Business: Revenue Model & Marketing Plan (#199)
• Need to refine the design (#293)
• Phase 2: Interest-based filtering and matching at venues (#319)
• Phase 3: Venue analytics : aggregate interest and vibe insights for merchants (#320)
• Strategic Considerations: Rollout, Product, and Messaging (#326)
• Offers wiring : UX polish & follow-up refinements (post #139) (#357)
• [META] Privacy & Security Hardening : Master Tracker (#523)
• feat: badge system with anonymous cohort targeting for venue offers + opt-in leaderboard (#579)
• Site: "Finding each other" needs a see-it-in-the-app screenshot strip (+ in-app flow to capture) (#593)
• Funding: pursue non-dilutive grants (woman/veteran/LGBTQ+ founder) (#629)
• Pre-alpha: iOS real-device coverage for PWA push (no iPhone on the team) (#722)
• feat(site): show a phone with a lit lantern beacon on the splash cover, flame becomes background (#848)
• test(security): penetration testing by an outside party before Alpha (#865)
• feat(venues): add Google Places as a second venue source, with the cost established (#866)
• feat(safety): how we measure whether Alpha participants felt safe, without averaging groups together (#867)
• business(alpha): pilot venue agreements, with named contacts and a shared understanding of participating (#868)
• business(alpha): a repeatable merchant pitch, partnership terms, and objection handling (#869)
• business(alpha): sales and onboarding process, from outreach to a live merchant (#870)
• business(alpha): define the target launch events, because the events are the experiment design (#871)
• business(ops): Google Workspace and Slack, with the per-seat run rate modelled before committing (#872)
• business(ops): hire a second engineer (also unblocks the senior-approval rule) (#873)

Already decided: Prototype (26)

• Implement unique Lantern Name generation with collision handling and expand word lists (#251)
• Personalization: user-chosen lantern names (pool-composed) + flame color choice (#578)
• Migrate lucide-react 0.x → 1.x (brand icons removed) (#770)
• Migrate vitest 3 → 4 (unblocks @vitest/ui 4) (#771)
• Admin System Health uptime tab: false DOWN for Admin Portal + Storybook (browser CORS probes) (#797)
• feat(internal): intranet search across docs, worklogs, plans, and issues (#800)
• feat(dx): one-click prebuilt Codespace with Claude Code preinstalled for internal tool building (#801)
• chore(admin): align admin vitest with vite 8 (build-vs-test transform split) (#804)
• feat(internal): intranet shortlinks (go-links) service, speakable short URLs for team resources (#811)
• Dev env: local auth-api can't mint custom tokens (ADC lacks iam.serviceAccounts.signBlob), so local admin/merchant login is impossible (#819)
• refactor(web): extract shared CloseButton / PasswordReveal / ViewModeToggle primitives (#822)
• Admin portal has no mobile layout: sidebar never collapses, content renders off-screen on a phone (#826)
• feat(platform): team-built apps initiative, define the platform teammates build their own tools on (#827)
• docs: burn down the remaining ~500 broken doc links (split from #829) (#833)
• feat(context): sync the per-user context home across machines (desktop, VM, future laptops) (#834)
• chore(functions): bump Cloud Functions runtime off the Node 22 pin (#838)
• Consolidate docs/engineering/guides: overlapping and duplicated guide docs (#840)
• feat(platform): app creation portal so non-engineers can build on Lantern infrastructure (needs spec) (#849)
• feat(dx): lantern up <preset>, one-command local service stacks with port-collision guards (#855)
• feat(dx): lantern board, print the PM board + today's live PR ledger in the terminal (#856)
• feat(dx): lantern next, ranked next-task list from board + registered live plans + scored issues (#859)
• feat(context): sync model, dated files for volatile state, a generated index, and how memories converge (#862)
• design(privacy): one data-classification and egress policy, before search, the assistant, and the apps platform each invent their own (#874)
• security: sensitive fields colocated with readable data, so admin clients pull credentials and sealed-identity material into the browser (#875)
• bug(admin): dashboard profile-completion counts are structurally always zero (plaintext fields were encrypted away) (#881)
• docs(sites): four subdomains, three audiences, and one of them is internal-only (#883)

Already decided: Beta (5)

• Safety Mechanics - SOS Emergency System (#128)
• Safe Spaces Partnership Program (#129)
• In-App Safety Education & Resources (#130)
• Safety-Verified Venue tier + badge (reassurance-first) (#630)
• Ring 1: nearby always-open safe havens from OSM (planning-time reassurance) (#631)

Not named anywhere: 99, grouped by primary label

enhancement (24)

• [Discord] Add better search functionality and preset categories (#125)
• Core Lantern Features - Auto-Shutoff & Wave Rules (#134)
• Bonfire: Event Feature (#162)
• Merchant: Community Portal & Tools (#167)
• Merchant: Claim Venue UI Flow (#171)
• Move OSM Import to server side configs for better fraud handling (#224)
• Admin Portal: Merchant-User Association (Phase 4) (#231)
• Feature: Admin Portal Configuration Management (OSM Tags, Categories, Tiers) (#237)
• Add Resend integration to Admin Portal (System Health & Billing) (#238)
• Add AI Assistant integration to Admin Portal and Discord Bot (#239)
• Feature: Allow non-GitHub users to submit issues with email notifications (#241)
• Audit and standardize Cloud Run API proxy coverage across all environments (#275)
• Image Processing Service : Cloud Run Service (#280)
• Explore Firebase Data Connect (#287)
• Hero card icon: add venue photo and lantern count options (#323)
• Refactor: Decompose Dashboard + Introduce Zustand for State Management (#324)
• Extract OfferCards/AdSlot to @lantern/shared with style theming (#350)
• feat(auth): Phase 2 : escalating backup nudge (banner + modal) (#362)
• feat(merchants): add an LLM moderation stage in front of the keyword pre-check (#799)
• Event Tracking: should the row icon differ by client / server / both? (#823)
• Merchant portal: venues need a detail page for editing, not inline controls in the list (#824)
• feat(admin): reissue an admin's Main App Invite Link from the Users tab (#850)
• feat(admin): show what access each admin user actually has, in one place (#851)
• feat(agents): skill for keeping the timeline docs current as work is planned, prioritized, and finished (#853)

devops (19)

• [Discord] Discord Github Syncs (#49)
• Create additional workflows and intakes in Discord (#59)
• Add AI to our Lantern Bot (#63)
• Documentation - GitHub Projects Usage Guide (#83)
• Discord - Refine Issue Intake Submission Flow (#86)
• Code Quality: Increase Test Coverage to 70%+ (#152)
• Code Quality: Docker Configuration (#154)
• DevEx: Developer Onboarding & Tools (#194)
• Sync venue_types.csv with external venue sources (#212)
• Add ability to update OSM places based on user tags ( giving back to the API essentially ) (#216)
• Allow for user input flag if place is "permanently closed" (#217)
• Add CI checks and npm validations for undocumented client SDK exports (#265)
• Add tests for docs-api service (#267)
• Validate VitePress build on docs-only PRs (revisit when admin/public docs split) (#460)
• WSL: revert .bashrc GitHub-auth workaround suspected of dropping connections (#590)
• Docs publishing: auto-deploy the docs site on merge, and add Save-vs-Publish in the admin editor (#623)
• Feature rollout analysis (commit-based) + admin-portal rollout monitor design (#626)
• Context layer: flip Claude memory subtree to context-canonical (#654)
• feat(dx): create worktrees at a visible repo-root location instead of .claude/worktrees (#854)

security (19)

• Location: Anti-Fraud Detection (Phase 2) (#156)
• Location: Enhanced Verification (Phase 3) (#157)
• Location: Incident Response Plan (#158)
• Admin Portal: Rate Limiting for Admin Actions (#230)
• feat: Anonymous analytics endpoint for pre-auth funnel tracking (#309)
• feat(auth): Tiered recovery model with biometric, deferred backup, and escalating prominence (#352)
• feat(auth): Phase 3 : TOTP authenticator setup UI + client crypto (#363)
• feat(auth-api): Phase 4 : endpoints for PIN-encrypted seed + TOTP (#364)
• feat(auth): Phase 5 : PIN re-entry gating for sensitive recovery actions (#365)
• deps(admin): drop the GHSA-qwww-vcr4-c8h2 allowlist entry when a patched react-router ships (#735)
• privacy(moderation): appeal payloads send raw phoneHash to the moderator UI; strip if the portal does not need it (#846)
• privacy(assistant): read_collection allowlist exposes users/lanterns/waves rows into LLM context; trim or field-mask (#847)
• security(auth): admin authorization has two sources of truth, and a partial demotion fails open (#886)
• security(auth): the invite gate is advisory, not enforced: account creation never checks an invite (#887)
• Banning an admin does not revoke admin access (ban is never checked on admin routes or admin login) (#888)
• Portal five-strike lockout allowed one unbounded burst of password guesses (#891)
• infra: duplicated guards need a mechanism, the written rule has now failed four times including once by its own author (#893)
• Follow-ups from PR #876 second review: sealed PIN gate, offer-route ban gate, mint chokepoint, pagination, stats scan (#894)
• infra: ban neutral-* while the codebase is clean, so the ratchet starts at zero instead of at 725 (#895)

bug (13)

• Refactor API client base-URL resolution to use the API_SERVICES registry (#343)
• feat(location): Preflight gate, diagnostic UX, and read-only fallback for missing location (#355)
• PhoneNumberInput: non-US accounts can't reach login/unlock/recovery (US-only by design) + input hardening (#782)
• Admin login: successful sign-in logs loud console errors (auth cascade tries admin, then merchant, then Firebase) (#798)
• Fresh-clone dev console shows an error telling newcomers to set VITE_ANALYTICS_API_URL in .env.local (#839)
• chore(web): page title is 'Lantern (Prototype)' in production too (#864)
• bug(admin): GitHub username lookup only scans the first 100 users, so it silently reports real users as nonexistent (#879)
• bug(admin): false 'Set Up Separate Admin Password' banner for every admin once the #875 credential migration runs (#882)
• Some DETACHED full validate runs are killed mid-run (cause unknown); foreground and scoped runs complete (#884)
• Two simultaneous requests could light two lanterns for one account, breaking an invariant other services rely on (#889)
• refactor(shared): the 2-hour lantern lifetime is defined three times and can drift silently (#890)
• PR #876 review follow-ups: lantern extinguish/relight transaction cluster + lower-severity items (#898)
• infra(context): every fleet boot warns that context may be STALE, and the cause is the check racing itself (#899)

documentation (10)

• Legal: Trade Secret Documentation (#143)
• Transparency: AI Usage & Cost Documentation (#188)
• Docs CMS: frontmatter schema, section configs, audience-scoped builds & editor UI (#325)
• Persist admin assistant transcripts (Firestore + TTL) for admin review and analytics (#335)
• docs(auth): Phase 6 : recovery model documentation (#366)
• docs(sealed-identity): reconcile ban docs post-Option-B + optionally consolidate the cluster (#653)
• refactor(agents): split the communication rule into a neutral team contract + per-user voice overlay (#835)
• feat(agents): skill for integrating a new platform, so the docs that name it get updated (#852)
• feat(onboarding): finish-line hook, doctor-green prints the day-one path (#858)
• business(alpha): entity, Employee Rights Charter, and governance docs signed off (#896)

analytics (4)

• Implement analytics event registration lifecycle pipeline (#273)
• Forge: promote category, session_id, and origin to top-level BigQuery columns (#332)
• Assistant: BigQuery analytics integration (canned queries) (#333)
• feat(admin/bq): scheduled-query CRUD from the BigQuery console (#373)

privacy (3)

• Build and integrate privacy-first server-side analytics and ad attribution with GCP + BigQuery (comprehensive plan and code examples) (#65)
• Research: add frens from saved phone contacts (Contact Picker / privacy-preserving matching) (#588)
• Stage B: GC sweep for orphaned sealed users docs after start-over (Fork A) (#683)

refactor (3)

• Wire systemConfig/venues refreshThresholds + importDefaults geo overrides into their consumers (#580)
• refactor(merchants): dedup offer serialization + apply the OfferReviewQueue robustness fixes to MerchantApplications (#809)
• Venue-activity poll: skip a background tick while a fetch is already in flight (#828)

ops (2)

• Define Venue "Categories" and Implement Ad Safeguards (#77)
• Merchant: Phase 1 Pilot Integration (#178)

design (1)

• Logo Redesign (#91)

marketing (1)

• light.ourlantern.app content + layout updates (June 2026 round) (#589)