Release 0.8.0: open beta-access request flow (first/last/why)

Replaces the v0.3.0 / v0.7.0 allowed_emails admission gate with an
admin-grant flow (roadmap item #6, SPEC §6.1 / §6.2 / §14.1 / §17).
Any valid email can sign in via OTC; a fresh user lands in
permission_state='pending' with a captured first/last/why profile,
and an admin grant flips them to 'granted' before write endpoints
accept them. Grandfathered users pass through the migration with
the column default 'granted' so existing contributors are unaffected.
The allowed_emails table stays in the schema as a fast-path bypass
pending v0.9.0's admin user-management page (item #7).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

CHANGELOG.md

@@ -23,6 +23,192 @@ skip versions are the composition of each intervening adjacent
 release's steps in order — no A-to-B path is pre-computed beyond
 that.
 
+## 0.8.0 — 2026-05-28
+
+**Minor — schema migration required; admission semantics shift.**
+This release replaces the v0.3.0 / v0.7.0 `allowed_emails` admission
+gate with an admin-grant flow (roadmap item #6, SPEC §6.1 / §6.2 /
+§14.1 / §17). Anyone with a valid email can sign in via the v0.7.0
+OTC flow; the OTC request endpoint no longer consults the
+allowlist. A fresh user lands in `permission_state='pending'` until
+an admin grants access. The first-OTC sign-in captures first name,
+last name, and a free-text "why I should be included in the beta"
+via a new `POST /api/auth/me/beta-request` endpoint; the captured
+fields populate the same `users` row alongside the OAuth-era
+columns.
+
+A pending user has the same read access an anonymous viewer has —
+the catalog, RFC bodies, the philosophy page, and every public
+conversation are reachable. Every write-shaped endpoint
+(`auth.require_contributor` floor) refuses pending users with 403.
+The frontend renders a thin "Your beta access request is in
+review" banner on every page and re-purposes the v0.3.0
+`/beta-pending` page as the post-capture landing surface.
+
+Grandfathered behavior: every `users` row at migration time
+carries `permission_state='granted'` via the column default, so
+existing contributors are unaffected. The OAuth fallback at
+`/auth/callback` still consults the v0.3.0 allowlist (legacy
+path); the OTC flow does not.
+
+The `allowed_emails` table stays in the schema as a fast-path
+bypass — the v0.3.0 admin UI continues to manage it, but the OTC
+request handler no longer reads it. v0.9.0 (roadmap item #7) is
+expected to ship the admin user-management page that replaces the
+allowlist surface entirely; until then, admin grants are done by
+direct DB `UPDATE`.
+
+### Upgrade steps (from 0.13.0)
+
+1. **MUST** restart the backend so migration `014_beta_access.sql`
+   runs. The migration adds `permission_state` (default `'granted'`,
+   so existing rows pass through unaffected), `first_name`,
+   `last_name`, `beta_request_reason`, `permission_decided_by`,
+   and `permission_decided_at` to the `users` table, plus an index
+   on `permission_state` for the pending queue. The migration is
+   ALTER-TABLE-based (no table rebuild) — every foreign key and
+   existing row passes through untouched.
+2. **MUST** rebuild the frontend. The `Login.jsx` surface now
+   runs a conditional third step (the capture form) on fresh OTC
+   sign-ins; `BetaPending.jsx` carries the new "your request is
+   in review" copy; `App.jsx` renders a thin pending-access
+   banner. The build embeds the new `/api/auth/me/beta-request`
+   client call.
+3. **SHOULD** announce the new admission flow to existing users.
+   Wording suggestion: "We've replaced our email-allowlist gate
+   with an admin-review flow. Existing users are unaffected;
+   new visitors sign in with their email, tell us a bit about
+   themselves, and an admin reviews their request before
+   discussion and contribution unlock." Existing sessions
+   remain valid.
+4. **SHOULD** plan the admin grant mechanism. v0.8.0 does not
+   ship a UI for the grant — v0.9.0 (roadmap item #7) will. For
+   the v0.8.0 window, an admin grants access via direct DB
+   gesture:
+   ```sql
+   UPDATE users
+      SET permission_state = 'granted',
+          permission_decided_by = <admin_user_id>,
+          permission_decided_at = datetime('now')
+    WHERE email = '<approved>';
+   ```
+   The pending queue lives in `SELECT * FROM users WHERE
+   permission_state = 'pending' ORDER BY created_at`.
+5. **MUST** decide whether to drain the `allowed_emails` table.
+   The OTC request handler no longer consults it; populated
+   rows are inert at the request surface. Three operator
+   choices, all valid:
+   * **Leave as-is** (the framework's default behavior — the
+     v0.3.0 admin UI continues to work, the rows stay as a
+     fast-path bypass record). Recommended if you anticipate
+     v0.9.0's user-management page folding the allowlist UI
+     into its surface.
+   * **Drain via the existing admin UI** (`/admin/allowlist`)
+     — one row at a time, no data loss elsewhere.
+   * **Bulk-drain via DB** — `DELETE FROM allowed_emails;`
+     drops every row; the table stays.
+6. **MAY** announce write access individually to grandfathered
+   users you want to keep at `'granted'`. The default-`'granted'`
+   migration means no action is required for them; this step
+   exists only if you want to send a "you're still in" message.
+
+### Added
+
+- **`backend/migrations/014_beta_access.sql`** — adds
+  `permission_state` (CHECK in `('pending', 'granted', 'revoked')`,
+  default `'granted'`), `first_name`, `last_name`,
+  `beta_request_reason`, `permission_decided_by` (FK to users,
+  ON DELETE SET NULL), `permission_decided_at` to the `users`
+  table. Plus `idx_users_permission_state` for the pending
+  queue.
+- **`POST /api/auth/me/beta-request`** — body
+  `{first_name, last_name, beta_request_reason}` (all required;
+  bounds 120 / 120 / 4000). Writes the fields to the signed-in
+  user's row and leaves `permission_state='pending'`. Refuses
+  HTTP 409 for already-granted / revoked users; refuses HTTP
+  401 for anonymous callers.
+- **`needs_profile` flag** on the `/auth/otc/verify` response.
+  `true` iff the user is `permission_state='pending'` AND
+  carries no profile fields yet (a fresh OTC sign-in). The
+  Login.jsx surface uses the flag to gate the capture step.
+- **`permission_state` field** on the `/api/auth/me` response,
+  plus `first_name`, `last_name`, `beta_request_reason`, and
+  the same `needs_profile` flag.
+- **First-OTC profile capture step** in `Login.jsx`. Third
+  step in the sign-in surface, gated by the verify response's
+  `needs_profile` flag.
+- **`/beta-pending` repurpose** in `BetaPending.jsx`. The
+  page now reads as "your request is in review" when the
+  viewer is pending; the v0.3.0 "private beta" framing
+  remains as the anonymous-viewer fallback.
+- **Thin pending-access banner** at the top of every page
+  for `permission_state='pending'` viewers (other than
+  `/beta-pending` itself).
+- **SPEC `§6` opening / `§6.1` / `§6.2` / `§14.1` / `§17` /
+  `§19.2`** corrections per §19.3 rule-2 — the admission
+  shift, the orthogonality of permission_state vs role / muted
+  / notification-mutes, the new endpoints, and the
+  newly-surfaced §19.2 candidates (admin user-management page,
+  allowlist deprecation, admin notification on new request).
+- **`backend/tests/test_beta_access_vertical.py`** — 9 new
+  tests covering: a fresh OTC user lands pending with empty
+  profile; the capture endpoint populates the fields and
+  keeps state pending; the capture endpoint refuses
+  anonymous / granted / revoked callers; a pending user is
+  refused write endpoints; an admin grant promotes pending →
+  granted; a grandfathered user is unaffected by the
+  migration; the OTC request endpoint accepts any email
+  regardless of allowlist state; the `allowed_emails` table
+  is still present in the schema.
+
+### Changed
+
+- **`backend/app/auth.py#require_contributor`** widens its
+  gate to refuse `permission_state != 'granted'` with HTTP
+  403. The §6.1 contributor capabilities (propose, branch,
+  PR, chat, claim) all funnel through this dependency, so
+  the widening covers them transitively. `SessionUser` now
+  carries `permission_state` (default `'granted'` for the
+  dataclass-default fallback path).
+- **`backend/app/otc.py#request_code`** drops the allowlist
+  check from the OTC request flow. The `RequestOutcome`
+  shape loses the `'allowlist'` reason (replaced by
+  `'sent'` / `'cooldown'` / `'invalid'`).
+- **`backend/app/otc.py#provision_or_link_user`** sets
+  `permission_state='pending'` explicitly on a fresh row.
+  Grandfathered (link-by-email) users pass through with
+  their existing column value.
+- **`backend/app/auth.py#provision_user`** (OAuth fallback)
+  now sets `permission_state='granted'` explicitly on a
+  fresh row. The OAuth callback still consults the
+  `is_allowed_sign_in` allowlist check (the legacy fallback
+  path retains its v0.3.0 admission shape during the OAuth
+  migration window).
+- **`backend/tests/test_otc_vertical.py`** — the
+  `test_otc_request_silently_drops_when_email_not_on_allowlist`
+  test (asserted the v0.7.0 allowlist gate) is replaced by
+  `test_otc_request_admits_emails_regardless_of_allowlist_population`
+  which asserts the v0.8.0 open-request contract. The
+  on-list test stays as a regression net for the
+  rate-limit / outbound-buffer plumbing.
+- **`SPEC.md`** §6 opening, §6.1, §6.2, §14.1, §17, §19.2
+  per §19.3 rule-2.
+- **`VERSION`** → `0.8.0`. `frontend/package.json#version` and
+  the lockfile mirror.
+
+### Deferred to later releases
+
+- **Admin user-management page** at `/admin/users` (item #7,
+  v0.9.0) — replaces the manual DB `UPDATE` gesture.
+- **Allowlist UI deprecation** (also v0.9.0) — once the
+  admin user-management page lands, the `/admin/allowlist`
+  surface and the `allowed_emails` table both retire.
+- **Admin email notification on new beta request** (item #7
+  again, v0.9.0).
+- **Revoke gesture in the UI** — the `permission_state='revoked'`
+  state is wired in the schema and the auth gate; v0.9.0 ships
+  the admin UI that flips the column.
+
 ## 0.13.0 — 2026-05-28
 
 **Minor — schema migration required; new optional env vars.** This

SPEC.md

@@ -369,6 +369,20 @@ unique). The Gitea bot user + token are still required for server-
 side git operations (repo reads, PR creation); only the operator-
 facing sign-in surface moved.
 
+Admission, as of v0.8.0, is by admin grant. v0.7.0 carried the
+v0.3.0 `allowed_emails` table forward as the admission gate at the
+OTC request surface — emails not on the list got a silent drop.
+v0.8.0 (roadmap item #6) reverses that: any valid email receives an
+OTC, the fresh `users` row lands in `permission_state='pending'`,
+and an admin grant flips the column to `'granted'` before write
+endpoints accept the user. The capture-fields step (first name,
+last name, free-text "why I should be included in the beta") feeds
+the admin's triage queue. The `allowed_emails` table stays in the
+schema as a fast-path bypass — the v0.3.0 admin UI still manages
+it — but the OTC request path no longer consults it. v0.9.0's
+admin user-management page replaces the allowlist UI and ships the
+pending-queue triage surface.
+
 ### 6.1 Four roles, each a strict superset of the one below
 
 1. **Anonymous.** Can read public RFCs (the meta repo's main branch,
@@ -385,10 +399,14 @@ facing sign-in surface moved.
    surface remain open per the v0.3.0 contract.
 2. **Contributor.** Default role for any authenticated account. A
    first OTC sign-in by a previously unknown email provisions a row
-   at this role; v0.7.0 keeps the v0.3.0 allowlist gate (`allowed_emails`)
-   as the admission control, deferring the open beta-access request
-   flow to a later release. Everything anonymous can do, plus:
-   propose new RFCs (open a PR against the meta repo), create
+   at this role; v0.8.0 replaced the v0.3.0 / v0.7.0 allowlist gate
+   with an admin-grant flow (roadmap item #6, see opening of §6).
+   The contributor capabilities below — propose, branch, PR, chat,
+   claim — are gated by `users.permission_state='granted'` as well
+   as by the role. A pending contributor (the post-OTC waiting
+   state) has the same read access as anonymous and zero write
+   capability until an admin grants. Everything anonymous can do,
+   plus: propose new RFCs (open a PR against the meta repo), create
    branches on any RFC repo, open PRs from branches they have
    contribute access to, chat on anything they can read, claim
    ownership of unclaimed super-drafts.
@@ -430,6 +448,38 @@ triage what they can't act on, and the restore lands cleanly); a
 self-DND'd contributor's own gestures continue to fire signals to
 others normally.
 
+v0.8.0 adds a fourth structurally-distinct field on the same row:
+`users.permission_state` (the admission gate the v0.8.0 release
+ships, see opening of §6 and §6.1). The four — role, muted,
+permission_state, the notification mutes — are orthogonal and the
+gate semantics compose:
+
+  * `role` answers "what scope of action is this user authorized to
+    perform if they're admitted at all?" (anonymous / contributor /
+    admin / owner).
+  * `muted` answers "is this contributor write-restricted by an
+    admin gesture against their existing grant?" (a sanctions
+    primitive — owner/admin imposed).
+  * `permission_state` answers "is this user admitted to the beta
+    at all?" (the v0.8.0 admin-grant gate — 'pending' / 'granted' /
+    'revoked'). The default for grandfathered rows at migration time
+    is `'granted'`; OTC freshly provisions `'pending'`.
+  * The notification mutes answer "does this user want to receive
+    signals about a particular RFC or from a particular other
+    user?" (self-imposed preference).
+
+The four never gate each other. A pending user with `role=owner`
+(impossible by construction in v0.8.0 — fresh OTC always provisions
+role=contributor — but the orthogonality holds at the column level)
+would still refuse write endpoints because the admission gate
+runs first; a granted contributor whose row is also muted refuses
+writes via the mute gate; a granted contributor with notification
+mutes set still passes the contributor gate and writes normally.
+v0.6.0's anon-write audit (item #4) is the structural floor for all
+four — every write-shaped endpoint funnels through
+`auth.require_contributor`, which checks all three of {authenticated,
+not muted, permission_state='granted'} in order.
+
 ### 6.3 Per-RFC delegated authority
 
 An RFC's `owners:` and `arbiters:` (from the meta-repo entry's
@@ -1990,6 +2040,19 @@ the mechanics, so the mechanics (super-drafts, graduation, public
 arguments, AI participation in chat) read as load-bearing rather than
 novel.
 
+v0.8.0 (roadmap item #6) added a third sign-in step the surface
+runs conditionally — on the first OTC sign-in by a previously
+unknown email, the verify response carries `needs_profile=true`
+and the surface prompts for first name, last name, and a free-text
+"why I should be included in the beta" before bouncing the user to
+`/beta-pending`. The page displays a "your request is in review"
+message keyed on `users.permission_state='pending'` (repurposed
+from the v0.3.0 post-OAuth-rejection surface). Anonymous viewers
+and pending viewers see the same read surfaces; only the write
+affordances differ. A persistent thin "Your beta access is in
+review" banner shows on every page (other than `/beta-pending`
+itself) until an admin grants access.
+
 ### 14.2 The `/philosophy` route
 
 Authenticated and anonymous visitors alike can reach `/philosophy`,
@@ -2626,25 +2689,45 @@ The follow-up session will refine this. A minimal starting set:
 - `POST /auth/otc/request` — unauthenticated. Body carries `email`.
   Generates a six-digit code, stores its bcrypt hash with an expiry
   (`OTC_TTL_MINUTES`, default 10), and dispatches a plain-text email
-  via the SMTP layer. Returns HTTP 200 (`{ok:true}`) uniformly so
-  allowlist state (§6.1 / §6.2) is not leaked to callers. Returns
-  HTTP 429 when the per-email cooldown (`OTC_REQUEST_COOLDOWN_SECONDS`,
-  default 60) blocks back-to-back requests — the loud-failure shape
-  for the abuse path. A re-request invalidates the prior unused
-  code for the same email so only one code is outstanding at a time.
-  Per §19.2's expected next session, this endpoint is the lead-up
-  to the Cloudflare-Turnstile abuse-mitigation overlay.
+  via the SMTP layer. Returns HTTP 200 (`{ok:true}`) uniformly.
+  Returns HTTP 429 when the per-email cooldown
+  (`OTC_REQUEST_COOLDOWN_SECONDS`, default 60) blocks back-to-back
+  requests — the loud-failure shape for the abuse path. A re-request
+  invalidates the prior unused code for the same email so only one
+  code is outstanding at a time. v0.7.0 also dropped requests
+  silently if the email wasn't on the `allowed_emails` list (the
+  v0.3.0 admission gate); v0.8.0 (item #6) removed that check —
+  admission moved to `permission_state` on the freshly-provisioned
+  `users` row, asserted at the contributor gate. Per §19.2's
+  expected next session, this endpoint is the lead-up to the
+  Cloudflare-Turnstile abuse-mitigation overlay.
 - `POST /auth/otc/verify` — unauthenticated. Body carries `email` and
   `code`. Validates the bcrypt hash against the most-recent unconsumed
   non-expired row for the email, marks the row consumed, provisions
   or links the `users` row by email (per §6.2's migration path —
   match by `users.email` case-insensitive, otherwise insert a fresh
-  contributor row with `gitea_id = NULL`), and stores the session
-  cookie. Returns HTTP 200 on success with a minimal user payload;
-  HTTP 400 on any failure (expired, consumed, wrong, unknown). The
-  failure modes collapse to a single generic message so a probing
-  client cannot distinguish "you got the wrong code" from "we don't
-  know this email" — the operator logs carry the distinction.
+  contributor row with `gitea_id = NULL` and
+  `permission_state='pending'`), and stores the session cookie.
+  Returns HTTP 200 on success; the response body carries
+  `{ok, user, needs_profile}` where `needs_profile=true` iff the
+  user is `permission_state='pending'` AND the row has no
+  first_name / last_name / beta_request_reason yet (a fresh OTC
+  sign-in). The `needs_profile` flag drives the Login.jsx surface's
+  step-3 capture form. HTTP 400 on any failure (expired, consumed,
+  wrong, unknown). The failure modes collapse to a single generic
+  message so a probing client cannot distinguish "you got the
+  wrong code" from "we don't know this email" — the operator logs
+  carry the distinction.
+- `POST /api/auth/me/beta-request` — authenticated. Body carries
+  `first_name`, `last_name`, `beta_request_reason` (all required;
+  bounded at 120 / 120 / 4000 chars). Writes the fields to the
+  signed-in user's row and leaves `permission_state='pending'`.
+  Idempotent for the same already-pending user (a re-submit
+  updates the row so the admin sees the latest text). Refuses
+  with HTTP 409 if the user is already `'granted'` or `'revoked'`.
+  v0.8.0 — the first-OTC profile-capture endpoint (roadmap item
+  #6). v0.9.0's admin user-management page consumes this column
+  set to render the request queue.
 - `GET /api/rfcs` — list entries with state, id, title, slug, repo,
   owners, last_active_at, has_open_prs, starred-by-me. Supports
   search, sort, filter chips, and the `unclaimed` predicate.
@@ -3620,23 +3703,72 @@ the new §15 (Notifications, in full), and §17 (the notification
 endpoints — list, mark-read, stream, watch mutation, preferences,
 quiet-hours, per-user mute, unsubscribe, bounce webhook).
 
-- **First-OTC profile capture.** *Surfaced by v0.7.0's email/OTC
-  migration.* When a fresh email lands at `/auth/otc/verify` with
-  no matching `users.email` row, v0.7.0 provisions the row with
-  `display_name = <local part of email>` and no other identity
-  fields. A subsequent release (the roadmap item-#6 candidate)
-  is expected to add a one-shot profile-capture step on the
-  first-OTC sign-in: first name, last name, and a free-text
-  "why I want access" field that flows into the open beta-access
-  request queue (also item #6) that replaces the v0.3.0
-  `allowed_emails` gate. The schema slot exists implicitly already
-  (`users.display_name` is updateable, the audit-log + permission-
-  events tables carry the freeform notes); the structural decision
-  is what gates the capture (modal on `/login` after verify? a
-  one-time redirect to `/welcome/profile`? a deferred banner on
-  the main view?) and how it interacts with the open-access
-  request flow that replaces the allowlist. Earns its session as
-  the v0.8.0 design pass.
+First-OTC profile capture (formerly a v0.7.0 candidate) is settled
+and folded into §6.1 (the contributor role now requires
+`permission_state='granted'`), §6.2 (the orthogonality of
+permission_state vs role / muted / notification-mutes), §14.1
+(the landing page's v0.8.0 first-OTC capture step), and §17
+(the `POST /api/auth/me/beta-request` endpoint and the verify
+endpoint's new `needs_profile` flag). The structural decision
+landed as: capture is a third step on the `/login` surface
+gated by `verify_response.needs_profile=true`; pending users
+land on `/beta-pending` after submitting and see a thin banner
+on every other page until an admin grants. v0.8.0 (roadmap item
+#6) shipped the work.
+
+Candidates surfaced during v0.8.0 (open beta-access request flow,
+§6.1 / §14.1, item #6):
+
+- **Admin user-management page** (`/admin/users`). *Surfaced by
+  v0.8.0 — the release ships the pending-state column but no
+  admin UI to triage it.* For v0.8.0, the admin gesture is an
+  out-of-band `UPDATE users SET permission_state='granted' WHERE
+  email=?`. v0.9.0 (roadmap item #7) is expected to ship the
+  triage queue: a list of `permission_state='pending'` rows
+  sorted by `created_at`, each showing the captured first /
+  last / why fields, with Grant and Revoke buttons that stamp
+  `permission_decided_by` and `permission_decided_at` (schema
+  slots already in place per `migrations/014_beta_access.sql`).
+  The page composes naturally with the existing `/admin/allowlist`
+  surface — both are admission-control gestures — so v0.9.0 may
+  fold the allowlist UI into this page (see next candidate).
+  Decision points: do grants / revokes also fire email
+  notifications to the user (probably yes — the notifications
+  layer from v0.6.0 has the personal-direct channel for it); is
+  there a "decline with reason" gesture that surfaces in the
+  user's view (probably yes — symmetric with §9.3's
+  proposal-decline shape); does the page support bulk grants
+  (probably no for v0.9.0 — the queue volume is operator-scale,
+  not user-scale). Earns its session as the v0.9.0 design pass.
+- **Allowlist deprecation.** *Surfaced by v0.8.0 — the
+  `allowed_emails` table stays in the schema but the OTC
+  request path no longer consults it.* v0.8.0 left the table
+  and the `/admin/allowlist` UI in place as a fast-path bypass
+  for deployments that want to pre-mark known-good emails (the
+  v0.8.0 contract is that those emails still go through the
+  pending-grant flow; the table itself is no longer a gate). A
+  future release retires both — probably v0.9.0 alongside the
+  admin user-management page, since the two surfaces are
+  functionally redundant once the pending queue lands.
+  Decision points: drop the table outright (a schema migration)
+  or leave it as a non-functional surface and remove only the
+  UI (a frontend-only change); how to handle existing
+  `allowed_emails` rows at the cutover (probably: walk them
+  into the pending queue with `permission_state='granted'` for
+  any matching `users` row, leave unmatched rows as a no-op
+  since v0.8.0 doesn't consult them anymore). Earns its
+  session as a sub-topic of the v0.9.0 admin user-management
+  pass.
+- **Admin notification on new beta request.** *Surfaced by
+  v0.8.0 — the capture endpoint writes to the row but does
+  not signal admins.* v0.9.0 candidate (item #7 again): when a
+  `POST /api/auth/me/beta-request` lands, fire an `admin-actionable`
+  notification (per §15.4's category set) to every owner / admin
+  so the queue doesn't go stale. The §15 infrastructure already
+  supports the category; the open question is whether the
+  notification is per-request (one email per submission) or
+  digested (a daily summary). Earns its session alongside the
+  admin user-management page.
 - **Removing the Gitea OAuth fallback.** *Surfaced by v0.7.0.*
   v0.7.0 keeps `/auth/callback` functional and links to it as a
   "Sign in with Gitea (fallback)" affordance on the new `/login`

VERSION

@@ -1 +1 @@
-0.13.0
+0.8.0

backend/app/api.py

@@ -55,6 +55,17 @@ class FunderCredentialBody(BaseModel):
     api_key: str = Field(min_length=1, max_length=2048)
 
 
+class BetaRequestBody(BaseModel):
+    # v0.8.0 — captured on the first OTC sign-in. All three fields are
+    # required so the admin queue has a coherent triage shape.
+    # The bounds match the v0.7.0 OTC body (320 chars for email-ish
+    # headers; 4000 for the free-text reason — the same upper bound
+    # DeclineBody uses elsewhere in this file).
+    first_name: str = Field(min_length=1, max_length=120)
+    last_name: str = Field(min_length=1, max_length=120)
+    beta_request_reason: str = Field(min_length=1, max_length=4000)
+
+
 def make_router(
     config: Config,
     gitea: Gitea,
@@ -120,6 +131,28 @@ def make_router(
         user = auth.current_user(request)
         if user is None:
             return {"authenticated": False, "user": None}
+        # v0.8.0: surface `permission_state` plus the capture-flow
+        # readiness signal (`needs_profile`). The frontend gates
+        # the /beta-pending page and the inline banner off these
+        # fields, and decides whether to prompt for the first/last/why
+        # capture on first OTC sign-in.
+        row = db.conn().execute(
+            "SELECT first_name, last_name, beta_request_reason FROM users WHERE id = ?",
+            (user.user_id,),
+        ).fetchone()
+        first_name = (row["first_name"] if row else None) or ""
+        last_name = (row["last_name"] if row else None) or ""
+        beta_request_reason = (row["beta_request_reason"] if row else None) or ""
+        # "Needs profile" iff the user is pending AND hasn't yet
+        # filed their beta-request capture. Granted users never see
+        # the capture prompt; pending users who already filed see
+        # the /beta-pending page without the capture form.
+        needs_profile = (
+            user.permission_state == "pending"
+            and not first_name
+            and not last_name
+            and not beta_request_reason
+        )
         return {
             "authenticated": True,
             "user": {
@@ -129,9 +162,68 @@ def make_router(
                 "email": user.email,
                 "avatar_url": user.avatar_url,
                 "role": user.role,
+                "permission_state": user.permission_state,
+                "first_name": first_name,
+                "last_name": last_name,
+                "beta_request_reason": beta_request_reason,
+                "needs_profile": needs_profile,
             },
         }
 
+    # ---------------------------------------------------------------
+    # v0.8.0: /api/auth/me/beta-request — first-OTC profile capture
+    # (roadmap item #6). Lands first name, last name, and the free-
+    # text "why I should be included in the beta" on the signed-in
+    # user's row. Idempotent for the same already-pending user;
+    # refuses to overwrite a row that's already granted (so a
+    # bored already-granted user can't accidentally re-submit the
+    # form and clobber the admin's audit trail). Uses
+    # `require_user` rather than `require_contributor` because
+    # `require_contributor` already enforces `permission_state =
+    # 'granted'` and would refuse a pending user; the whole point
+    # of this endpoint is to register the request _from_ a pending
+    # user.
+    # ---------------------------------------------------------------
+
+    @router.post("/api/auth/me/beta-request")
+    async def submit_beta_request(body: BetaRequestBody, request: Request) -> dict[str, Any]:
+        user = auth.require_user(request)
+        row = db.conn().execute(
+            "SELECT permission_state, first_name, last_name, beta_request_reason FROM users WHERE id = ?",
+            (user.user_id,),
+        ).fetchone()
+        if row is None:
+            # Defensive — the session pointed at a deleted row.
+            raise HTTPException(404, "User not found")
+        # Granted users have no business filing a beta request.
+        # 'revoked' likewise — the request flow is for fresh users
+        # only. Both shapes refuse with 409 (conflict) so the client
+        # can distinguish "you already have access" from
+        # "your access was revoked".
+        if row["permission_state"] == "granted":
+            raise HTTPException(409, "Your account is already granted access")
+        if row["permission_state"] == "revoked":
+            raise HTTPException(409, "Your account's access has been revoked")
+        # Re-submission from a pending user updates the row — the
+        # admin sees the latest text rather than a stale draft.
+        # The state stays 'pending'; only an admin can flip it.
+        db.conn().execute(
+            """
+            UPDATE users
+               SET first_name = ?,
+                   last_name = ?,
+                   beta_request_reason = ?
+             WHERE id = ?
+            """,
+            (
+                body.first_name.strip(),
+                body.last_name.strip(),
+                body.beta_request_reason.strip(),
+                user.user_id,
+            ),
+        )
+        return {"ok": True}
+
     # ---------------------------------------------------------------
     # §7: the catalog
     # ---------------------------------------------------------------

backend/app/auth.py

@@ -30,6 +30,12 @@ class SessionUser:
     email: str
     avatar_url: str
     role: str
+    # v0.8.0 / §6.1 — admission gate. Three states: 'pending' (waiting
+    # for an admin grant), 'granted' (active contributor), 'revoked'
+    # (was granted, later removed). Existing rows at migration time
+    # default to 'granted' so grandfathered users are unaffected; OTC
+    # provisions fresh users with 'pending' (see `app/otc.py`).
+    permission_state: str = "granted"
 
     def as_actor(self) -> Actor:
         return Actor(
@@ -90,6 +96,13 @@ def allowlist_is_active() -> bool:
 def is_allowed_sign_in(profile: dict[str, Any]) -> bool:
     """Decide whether a freshly-completed OAuth profile may sign in.
 
+    v0.8.0 (item #6) replaces the allowlist gate with an admin-grant
+    flow at the OTC `/request` surface, but the Gitea OAuth callback
+    in `main.py` still consults this helper so the fallback path
+    keeps the v0.3.0 admission shape during the OAuth migration
+    window. The eventual removal of the OAuth callback (§19.2)
+    retires this function alongside it.
+
     Three accept paths:
       1. The allowlist is empty (gate off).
       2. The Gitea profile's email is in `allowed_emails` (case-insensitive).
@@ -132,17 +145,27 @@ def provision_user(config: Config, profile: dict[str, Any]) -> SessionUser:
     existing = c.execute("SELECT * FROM users WHERE gitea_id = ?", (gitea_id,)).fetchone()
     if existing is None:
         role = "owner" if config.owner_gitea_login and login == config.owner_gitea_login else "contributor"
+        # v0.8.0: a fresh OAuth-provisioned user is also subject to
+        # the admin-grant flow. The OAuth fallback only fires for
+        # users who pass `is_allowed_sign_in` (so they're already on
+        # the legacy allowlist or are grandfathered by gitea_id);
+        # 'granted' is the right default here since the allowlist
+        # check is itself the admin gesture. A future release that
+        # retires the OAuth callback (§19.2) collapses both paths
+        # under the same gate.
         cur = c.execute(
             """
-            INSERT INTO users (gitea_id, gitea_login, email, display_name, avatar_url, role)
-            VALUES (?, ?, ?, ?, ?, ?)
+            INSERT INTO users (gitea_id, gitea_login, email, display_name, avatar_url, role, permission_state)
+            VALUES (?, ?, ?, ?, ?, ?, 'granted')
             """,
             (gitea_id, login, email, display, avatar, role),
         )
         user_id = cur.lastrowid
+        permission_state = "granted"
     else:
         user_id = existing["id"]
         role = existing["role"]
+        permission_state = existing["permission_state"] or "granted"
         c.execute(
             """
             UPDATE users
@@ -160,6 +183,7 @@ def provision_user(config: Config, profile: dict[str, Any]) -> SessionUser:
         email=email,
         avatar_url=avatar,
         role=role,
+        permission_state=permission_state,
     )
 
 
@@ -178,6 +202,12 @@ def store_session(request: Request, user: SessionUser) -> None:
         "email": user.email,
         "avatar_url": user.avatar_url,
         "role": user.role,
+        # v0.8.0: persist the admission state on the cookie payload so
+        # the post-cookie audit doesn't second-guess the row. The DB
+        # is re-read on every `current_user` call regardless (so an
+        # admin grant takes effect on the next request); this field
+        # is purely structural redundancy for the cookie shape.
+        "permission_state": user.permission_state,
     }
 
 
@@ -188,7 +218,7 @@ def current_user(request: Request) -> SessionUser | None:
     # Re-read the role from the database every request so role changes
     # take effect on the next API call without forcing a logout.
     row = db.conn().execute(
-        "SELECT id, gitea_id, gitea_login, email, display_name, avatar_url, role FROM users WHERE id = ?",
+        "SELECT id, gitea_id, gitea_login, email, display_name, avatar_url, role, permission_state FROM users WHERE id = ?",
         (raw["user_id"],),
     ).fetchone()
     if row is None:
@@ -199,6 +229,11 @@ def current_user(request: Request) -> SessionUser | None:
     # of which sign-in path the row came from. The DB remains the
     # source of truth for "is this an OAuth-linked user" (gitea_id IS
     # NOT NULL); the in-memory SessionUser is the per-request handle.
+    # v0.8.0: permission_state comes off the row directly. A NULL
+    # column value (shouldn't happen under the migration's
+    # NOT NULL DEFAULT, but be defensive) reads as 'granted' so the
+    # gate fails open for grandfathered surfaces rather than locking
+    # everyone out on a malformed row.
     return SessionUser(
         user_id=row["id"],
         gitea_id=row["gitea_id"] or 0,
@@ -207,6 +242,7 @@ def current_user(request: Request) -> SessionUser | None:
         email=row["email"] or "",
         avatar_url=row["avatar_url"] or "",
         role=row["role"],
+        permission_state=row["permission_state"] or "granted",
     )
 
 
@@ -218,11 +254,31 @@ def require_user(request: Request) -> SessionUser:
 
 
 def require_contributor(request: Request) -> SessionUser:
-    """§6.1: authenticated, not write-muted."""
+    """§6.1: authenticated, not write-muted, and granted by an admin.
+
+    v0.8.0 (item #6) widens this gate. A fresh OTC sign-in lands in
+    `permission_state='pending'`; the user can read everything an
+    anonymous viewer can read, but every write-shaped endpoint that
+    funnels through this dependency now refuses with 403 until an
+    admin grants them. The `pending` blast radius is the same as
+    anonymous (item #4 / v0.6.0 already audited the anon-write
+    refusal at every write site), so this widening is structurally
+    a relabel — the same surfaces that already refused 401 to
+    anonymous now also refuse 403 to pending.
+    """
     user = require_user(request)
     row = db.conn().execute("SELECT muted FROM users WHERE id = ?", (user.user_id,)).fetchone()
     if row and row["muted"]:
         raise HTTPException(status_code=403, detail="Your account is muted")
+    if user.permission_state != "granted":
+        # 'pending' is the post-OTC waiting state; 'revoked' is the
+        # admin-undid-the-grant state. Both refuse with the same 403
+        # shape; the client distinguishes via `/api/auth/me` which
+        # carries `permission_state` in the response.
+        raise HTTPException(
+            status_code=403,
+            detail="Your beta access request is in review",
+        )
     return user
 
 

backend/app/main.py

@@ -172,6 +172,26 @@ def _oauth_router(config) -> APIRouter:
         if not result.ok or result.user is None:
             raise HTTPException(400, "Invalid or expired code")
         auth.store_session(request, result.user)
+        # v0.8.0: surface `needs_profile` so the Login.jsx surface can
+        # decide whether to advance to the first/last/why capture step
+        # or jump straight to "/". `needs_profile=true` iff the user
+        # is `permission_state='pending'` AND the row has no profile
+        # fields yet — a fresh OTC user. Grandfathered users
+        # (`permission_state='granted'`) and pending users who already
+        # captured their fields both read as false.
+        row = db.conn().execute(
+            "SELECT first_name, last_name, beta_request_reason FROM users WHERE id = ?",
+            (result.user.user_id,),
+        ).fetchone()
+        first_name = (row["first_name"] if row else None) or ""
+        last_name = (row["last_name"] if row else None) or ""
+        beta_request_reason = (row["beta_request_reason"] if row else None) or ""
+        needs_profile = (
+            result.user.permission_state == "pending"
+            and not first_name
+            and not last_name
+            and not beta_request_reason
+        )
         return {
             "ok": True,
             "user": {
@@ -179,7 +199,9 @@ def _oauth_router(config) -> APIRouter:
                 "display_name": result.user.display_name,
                 "email": result.user.email,
                 "role": result.user.role,
+                "permission_state": result.user.permission_state,
             },
+            "needs_profile": needs_profile,
         }
 
     return router

backend/app/otc.py

@@ -1,4 +1,4 @@
-"""§6.2 / v0.7.0: email + one-time-code sign-in.
+"""§6.2 / v0.7.0 / v0.8.0: email + one-time-code sign-in.
 
 Replaces the Gitea OAuth gesture as the primary human-auth path. The
 Gitea bot user + token are still needed for server-side git
@@ -25,14 +25,25 @@ The shape:
     `users` row already carries `email` (case-insensitive), it is
     reused — `gitea_id` is left alone so a grandfathered OAuth-era
     user keeps the linker intact. Otherwise a fresh contributor
-    row is provisioned with `gitea_id = NULL`, `gitea_login = NULL`.
+    row is provisioned with `gitea_id = NULL`, `gitea_login = NULL`,
+    and `permission_state = 'pending'` (v0.8.0 — see below).
 
-The endpoints in `main.py` thin-wrap this module. The allowlist gate
-from v0.3.0 is consulted at request time — if `allowed_emails` is
-populated and the requested address isn't on it, the request returns
-202 as usual but no email is sent. This intentionally does not leak
-allowlist state to the caller; the §19.2 candidate for v0.8.0
-replaces this gate with an admin-grant flow.
+The endpoints in `main.py` thin-wrap this module.
+
+v0.8.0 (roadmap item #6) replaces the v0.3.0 `allowed_emails` gate at
+the request surface. The request handler used to silently drop OTC
+requests for emails not on the allowlist; now any valid email
+receives a code. The admission gate moves to `permission_state` on
+the freshly-provisioned `users` row: a fresh user lands in 'pending'
+and waits for an admin grant before write endpoints accept them.
+Read surfaces stay open (the same blast radius v0.6.0 / item #4
+already audited for anonymous viewers).
+
+The `allowed_emails` table itself stays in the schema as a
+fast-path bypass — the admin UI from v0.3.0 continues to manage it,
+and a future release (v0.9.0's admin user-management page) collapses
+the two admission surfaces into one. The OTC request path no
+longer consults the table.
 """
 from __future__ import annotations
 
@@ -44,7 +55,7 @@ from dataclasses import dataclass
 import bcrypt
 
 from . import db
-from .auth import SessionUser, allowlist_is_active
+from .auth import SessionUser
 
 log = logging.getLogger(__name__)
 
@@ -101,25 +112,15 @@ def _check_code(code: str, code_hash: str) -> bool:
         return False
 
 
-# ---------------------------------------------------------------------------
-# Allowlist gate — shared with the OAuth flow.
-# ---------------------------------------------------------------------------
-
-
-def _allowlist_admits(email: str) -> bool:
-    """The same allowlist v0.3.0 introduced for OAuth, applied to OTC
-    requests. If the allowlist is populated and the email is not on it,
-    we still respond 202 to the caller, but no code is sent."""
-    if not allowlist_is_active():
-        return True
-    row = db.conn().execute(
-        "SELECT 1 FROM allowed_emails WHERE email = ? LIMIT 1", (email,)
-    ).fetchone()
-    return row is not None
-
-
 # ---------------------------------------------------------------------------
 # Request path
+#
+# v0.8.0: the allowlist gate from v0.7.0 / v0.3.0 is removed here. Any
+# valid email receives a code; the admission gate moved to
+# `permission_state` on the freshly-provisioned `users` row (see
+# `provision_or_link_user`). The `allowed_emails` table stays in the
+# schema (admin UI from v0.3.0 still manages it); v0.9.0's admin
+# user-management page will collapse the two surfaces.
 # ---------------------------------------------------------------------------
 
 
@@ -127,14 +128,16 @@ def _allowlist_admits(email: str) -> bool:
 class RequestOutcome:
     """The outcome of a `request_code` call.
 
-    `code` is None whenever no code was generated — either because the
-    allowlist denied the email or because the cooldown window blocked
-    the request. The caller (the API endpoint) does not surface this
-    distinction to the user; it returns 202 either way.
+    `code` is None whenever no code was generated — the cooldown
+    window blocked the request or the email was syntactically
+    invalid. The caller (the API endpoint) does not surface the
+    invalid-email shape to the user; it returns 202 either way.
+    The cooldown shape surfaces as a loud 429 per the v0.7.0
+    contract.
     """
     sent: bool
     code: str | None
-    reason: str  # 'sent' | 'allowlist' | 'cooldown' | 'invalid'
+    reason: str  # 'sent' | 'cooldown' | 'invalid'
 
 
 def request_code(email: str) -> RequestOutcome:
@@ -160,13 +163,6 @@ def request_code(email: str) -> RequestOutcome:
         if row is not None:
             return RequestOutcome(sent=False, code=None, reason="cooldown")
 
-    # Allowlist: silently drop the send if the email isn't on the list.
-    # The row is not written either — there's nothing for verify to
-    # match against, so the user-facing experience is "I never got an
-    # email", which is the intended shape for the private-beta gate.
-    if not _allowlist_admits(email):
-        return RequestOutcome(sent=False, code=None, reason="allowlist")
-
     # Invalidate prior unused codes for this email. A re-request is
     # always for the most recent code; older codes are dead.
     db.conn().execute(
@@ -275,12 +271,16 @@ def provision_or_link_user(email: str) -> SessionUser:
       1. An existing row whose email equals (case-insensitive) the
          requested email — the OAuth-era user is grandfathered in via
          this path. `gitea_id` is preserved so a future OAuth round
-         trip still resolves the same row.
+         trip still resolves the same row. `permission_state` is
+         read off the row as-is — grandfathered users come through
+         migration with 'granted' (the column default), so their
+         contributor capabilities are unaffected.
       2. Otherwise: a fresh contributor row with `gitea_id = NULL`,
-         `gitea_login = NULL`. The display name defaults to the local
-         part of the email (everything before the `@`) — users can
-         rename later via the §19.2 first-OTC profile-capture flow
-         that v0.8.0 introduces.
+         `gitea_login = NULL`, and `permission_state = 'pending'`
+         (v0.8.0). The display name defaults to the local part of
+         the email (everything before the `@`); a separate
+         `POST /auth/me/beta-request` call lands first name / last
+         name / "why I want access" on the same row.
 
     The §6.1 owner-zero bootstrap still applies: if the email matches
     the configured `OWNER_GITEA_LOGIN`-derived owner identity, the row
@@ -307,13 +307,19 @@ def provision_or_link_user(email: str) -> SessionUser:
             email=existing["email"] or email,
             avatar_url=existing["avatar_url"] or "",
             role=existing["role"],
+            permission_state=existing["permission_state"] or "granted",
         )
 
     display = email.split("@", 1)[0] or email
+    # v0.8.0: 'pending' is the explicit insert value; the migration
+    # default of 'granted' is what passes grandfathered users
+    # through. A fresh OTC user lands in 'pending' regardless of
+    # what the migration default says, so the gate engages reliably
+    # even if a future migration changes the default.
     cur = db.conn().execute(
         """
-        INSERT INTO users (gitea_id, gitea_login, email, display_name, avatar_url, role)
-        VALUES (NULL, NULL, ?, ?, '', 'contributor')
+        INSERT INTO users (gitea_id, gitea_login, email, display_name, avatar_url, role, permission_state)
+        VALUES (NULL, NULL, ?, ?, '', 'contributor', 'pending')
         """,
         (email, display),
     )
@@ -326,4 +332,5 @@ def provision_or_link_user(email: str) -> SessionUser:
         email=email,
         avatar_url="",
         role="contributor",
+        permission_state="pending",
     )

backend/migrations/014_beta_access.sql

@@ -0,0 +1,76 @@
+-- §6.1 / §6.2 / §14.1 / v0.8.0: open beta-access request flow (roadmap item #6).
+--
+-- This release replaces v0.3.0's `allowed_emails` allowlist as the
+-- admission control. Anyone with a valid email can sign in via the
+-- v0.7.0 OTC flow; a fresh user lands in `permission_state='pending'`
+-- until an admin grants access. The first-OTC flow captures three
+-- profile fields (first name, last name, free-text "why I should be
+-- included in the beta") that the admin sees when triaging the
+-- request queue. The `allowed_emails` table stays in the schema as a
+-- fast-path bypass — populated rows are still readable by the
+-- existing admin UI; the OTC `/request` handler no longer consults
+-- it. v0.9.0's admin user-management page will replace the
+-- allowlist UI entirely.
+--
+-- Schema additions:
+--
+--   * `permission_state` — three-state CHECK: 'pending' | 'granted' |
+--     'revoked'. Default 'granted' so every row at migration time
+--     passes through unaffected; only newly provisioned OTC users
+--     land in 'pending' (the OTC verify path sets the column
+--     explicitly on a fresh row, per `app/otc.py`). 'revoked' is the
+--     admin gesture for an account that earned a grant then later
+--     lost it; v0.8.0 doesn't surface a revoke UI, but the schema
+--     slot is here so v0.9.0's admin user-management page can flip
+--     the column without another migration.
+--
+--   * `first_name`, `last_name` — nullable TEXT. Captured on the
+--     first OTC sign-in via `POST /auth/me/beta-request`. Existing
+--     rows (OAuth-era users, OTC users provisioned in v0.7.0) carry
+--     NULL through the migration; the admin queue treats an
+--     unpopulated capture as "auto-grandfathered" since the row's
+--     `permission_state` is already 'granted'.
+--
+--   * `beta_request_reason` — nullable TEXT. The free-text "why I
+--     should be included" from the capture form. Bounded to ~4000
+--     chars at the endpoint layer (no DB-level constraint —
+--     SQLite's TEXT is unbounded).
+--
+--   * `permission_decided_by` — nullable INTEGER. The `users.id` of
+--     the admin who flipped `permission_state` from 'pending' to
+--     'granted' (or 'granted' to 'revoked'). NULL for grandfathered
+--     rows (they were never decided — they passed through at
+--     migration). ON DELETE SET NULL because losing the admin row
+--     should not cascade-delete the user whose access they granted.
+--
+--   * `permission_decided_at` — nullable TEXT timestamp (ISO 8601,
+--     same shape as the existing `created_at` / `last_seen_at`).
+--     Co-populated with `permission_decided_by` on each decision.
+--
+-- Grandfathered-row invariant:
+--
+--   Every row that exists at migration time has
+--   `permission_state='granted'` and `permission_decided_by=NULL`
+--   (the column default + NULL preservation). v0.8.0's auth gate
+--   reads `permission_state='granted'` as the admission check, so
+--   no existing user is locked out by the upgrade. v0.7.0's OTC
+--   path is patched in the same release to set
+--   `permission_state='pending'` explicitly on a fresh row, so the
+--   gate engages only for users provisioned after the upgrade.
+
+ALTER TABLE users ADD COLUMN permission_state TEXT NOT NULL DEFAULT 'granted'
+    CHECK (permission_state IN ('pending', 'granted', 'revoked'));
+
+ALTER TABLE users ADD COLUMN first_name TEXT;
+ALTER TABLE users ADD COLUMN last_name TEXT;
+ALTER TABLE users ADD COLUMN beta_request_reason TEXT;
+
+ALTER TABLE users ADD COLUMN permission_decided_by INTEGER
+    REFERENCES users(id) ON DELETE SET NULL;
+ALTER TABLE users ADD COLUMN permission_decided_at TEXT;
+
+-- Index for the v0.9.0 admin queue: list pending requests ordered by
+-- when the user's row was created (the implicit "request received at"
+-- timestamp, since v0.8.0 sets pending at the same moment as the row
+-- itself is inserted via the OTC verify path).
+CREATE INDEX idx_users_permission_state ON users (permission_state);

backend/tests/test_beta_access_vertical.py

@@ -0,0 +1,390 @@
+"""End-to-end integration tests for v0.8.0's open beta-access request
+flow (§6.1 / §14.1, roadmap item #6).
+
+The release replaces v0.3.0's `allowed_emails` allowlist as the
+admission gate. Any valid email can sign in via the v0.7.0 OTC flow;
+a fresh user lands in `permission_state='pending'` until an admin
+grants access. The first-OTC flow captures first name, last name,
+and a free-text "why I should be included in the beta" via a new
+`POST /api/auth/me/beta-request` endpoint.
+
+The tests prove:
+
+  * A fresh OTC user lands `permission_state='pending'` with empty
+    profile fields, and the verify-response carries `needs_profile=true`.
+  * `POST /api/auth/me/beta-request` populates the three fields and
+    leaves the row in `pending`.
+  * A pending user is refused write endpoints (representative
+    samples: propose RFC, post discussion thread). The refusal is
+    403 (not 401 — they're authenticated, just not granted).
+  * An admin-grant flow promotes pending → granted. v0.8.0 doesn't
+    ship an admin UI for this (deferred to item #7 / v0.9.0), so
+    the test flips the column directly via DB and asserts that
+    `require_contributor` now admits the user.
+  * A grandfathered user (existing row pre-migration, default
+    `permission_state='granted'`) is unaffected — write endpoints
+    accept them.
+  * The `/auth/otc/request` endpoint accepts any email — the
+    v0.7.0 allowlist gate is gone from this path. The `allowed_emails`
+    table stays in the schema; the admin UI from v0.3.0 continues to
+    manage it for the fast-path bypass deployments may use.
+"""
+from __future__ import annotations
+
+import pytest
+
+from test_propose_vertical import (  # noqa: F401 — fixtures land via import
+    FakeGitea,
+    app_with_fake_gitea,
+    provision_user_row,
+    sign_in_as,
+    tmp_env,
+)
+
+
+def _reset_outbound():
+    from app import email as email_mod
+    email_mod.reset_sent_envelopes()
+
+
+def _outbound_otc_codes(to_address: str | None = None) -> list[str]:
+    """Pluck the code line from every OTC envelope in the test buffer."""
+    from app import email as email_mod
+    out = []
+    for env in email_mod.sent_envelopes():
+        if env.get("kind") != "otc":
+            continue
+        if to_address is not None and env["to"] != to_address:
+            continue
+        for line in env["body"].splitlines():
+            tok = line.strip()
+            if tok.isdigit() and len(tok) == 6:
+                out.append(tok)
+                break
+    return out
+
+
+# ---------------------------------------------------------------------------
+# Fresh OTC sign-in lands pending with empty fields
+# ---------------------------------------------------------------------------
+
+
+def test_fresh_otc_user_lands_pending_with_empty_profile(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+    from app import db
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app) as client:
+        _reset_outbound()
+
+        # Request + verify the OTC.
+        r = client.post("/auth/otc/request", json={"email": "newcomer@example.com"})
+        assert r.status_code == 200, r.text
+        code = _outbound_otc_codes("newcomer@example.com")[-1]
+
+        r = client.post("/auth/otc/verify", json={"email": "newcomer@example.com", "code": code})
+        assert r.status_code == 200, r.text
+        body = r.json()
+        # The verify response carries the new fields v0.8.0 added.
+        assert body["needs_profile"] is True
+        assert body["user"]["permission_state"] == "pending"
+
+        # The row reflects the same: pending state, no profile yet.
+        row = db.conn().execute(
+            "SELECT permission_state, first_name, last_name, beta_request_reason FROM users WHERE email = ? COLLATE NOCASE",
+            ("newcomer@example.com",),
+        ).fetchone()
+        assert row is not None
+        assert row["permission_state"] == "pending"
+        assert row["first_name"] is None
+        assert row["last_name"] is None
+        assert row["beta_request_reason"] is None
+
+        # /api/auth/me surfaces the same shape.
+        me = client.get("/api/auth/me").json()
+        assert me["authenticated"] is True
+        assert me["user"]["permission_state"] == "pending"
+        assert me["user"]["needs_profile"] is True
+        assert me["user"]["first_name"] == ""
+        assert me["user"]["last_name"] == ""
+        assert me["user"]["beta_request_reason"] == ""
+
+
+# ---------------------------------------------------------------------------
+# beta-request endpoint captures the fields and leaves state pending
+# ---------------------------------------------------------------------------
+
+
+def test_beta_request_populates_fields_keeps_state_pending(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+    from app import db
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app) as client:
+        _reset_outbound()
+        # Sign in the fresh user via the full OTC flow.
+        client.post("/auth/otc/request", json={"email": "alice@example.com"})
+        code = _outbound_otc_codes("alice@example.com")[-1]
+        client.post("/auth/otc/verify", json={"email": "alice@example.com", "code": code})
+
+        # Submit the capture form.
+        r = client.post(
+            "/api/auth/me/beta-request",
+            json={
+                "first_name": "Alice",
+                "last_name": "Liddell",
+                "beta_request_reason": "I want to help write the RFCs.",
+            },
+        )
+        assert r.status_code == 200, r.text
+
+        # The row reflects the captured fields; state stays pending.
+        row = db.conn().execute(
+            "SELECT permission_state, first_name, last_name, beta_request_reason FROM users WHERE email = ? COLLATE NOCASE",
+            ("alice@example.com",),
+        ).fetchone()
+        assert row["permission_state"] == "pending"
+        assert row["first_name"] == "Alice"
+        assert row["last_name"] == "Liddell"
+        assert row["beta_request_reason"] == "I want to help write the RFCs."
+
+        # /api/auth/me now reports needs_profile=false (fields are set).
+        me = client.get("/api/auth/me").json()
+        assert me["user"]["permission_state"] == "pending"
+        assert me["user"]["needs_profile"] is False
+        assert me["user"]["first_name"] == "Alice"
+
+
+def test_beta_request_refuses_anonymous(app_with_fake_gitea):
+    """The endpoint requires authentication — an anonymous caller can't
+    file a request without first signing in via OTC."""
+    from fastapi.testclient import TestClient
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app) as client:
+        client.cookies.clear()
+        r = client.post(
+            "/api/auth/me/beta-request",
+            json={"first_name": "A", "last_name": "B", "beta_request_reason": "Hi"},
+        )
+        assert r.status_code == 401
+
+
+def test_beta_request_refuses_granted_user(app_with_fake_gitea):
+    """A grandfathered (already granted) user has no business filing a
+    beta request. The endpoint refuses with 409 so the client can
+    distinguish the failure from "we don't know you" (401)."""
+    from fastapi.testclient import TestClient
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app) as client:
+        provision_user_row(user_id=1, login="grandfathered", role="contributor")
+        sign_in_as(
+            client,
+            user_id=1,
+            gitea_login="grandfathered",
+            display_name="Grandfathered",
+            role="contributor",
+        )
+        r = client.post(
+            "/api/auth/me/beta-request",
+            json={"first_name": "G", "last_name": "F", "beta_request_reason": "x"},
+        )
+        assert r.status_code == 409
+
+
+# ---------------------------------------------------------------------------
+# Pending user is refused write endpoints; admin grant promotes them
+# ---------------------------------------------------------------------------
+
+
+def test_pending_user_is_refused_write_endpoints(app_with_fake_gitea):
+    """A pending user can read everything anonymous can read, but every
+    write-shaped endpoint refuses with 403. The refusal shape mirrors
+    the v0.6.0 / item #4 audit's anon-401 — both are "no contributor
+    capability"; pending is the authenticated-but-ungranted variant.
+
+    Representative samples: propose RFC, post discussion thread.
+    """
+    from fastapi.testclient import TestClient
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app) as client:
+        _reset_outbound()
+        # Sign in via fresh OTC — lands pending.
+        client.post("/auth/otc/request", json={"email": "pending@example.com"})
+        code = _outbound_otc_codes("pending@example.com")[-1]
+        client.post("/auth/otc/verify", json={"email": "pending@example.com", "code": code})
+
+        # Reads work — every anonymous surface stays reachable.
+        assert client.get("/api/health").status_code == 200
+        assert client.get("/api/rfcs").status_code == 200
+        assert client.get("/api/philosophy").status_code == 200
+
+        # Propose — write-shaped, refused with 403.
+        r = client.post(
+            "/api/rfcs/propose",
+            json={"title": "T", "slug": "t", "pitch": "p", "tags": []},
+        )
+        assert r.status_code == 403
+        # The error body mentions the review state so a UI surface can
+        # render the right message — but the test asserts only on the
+        # status code (the body shape is the FastAPI default detail).
+
+
+def test_admin_grant_promotes_pending_to_granted(app_with_fake_gitea):
+    """v0.8.0 doesn't ship an admin UI for this — it's deferred to
+    item #7 / v0.9.0. For this release, an admin gesture is an
+    `UPDATE users SET permission_state='granted' WHERE email=?`. The
+    test flips the column directly via DB and asserts the
+    `require_contributor` gate now admits the user.
+    """
+    from fastapi.testclient import TestClient
+    from app import db
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app) as client:
+        _reset_outbound()
+        # Sign in a fresh OTC user — lands pending.
+        client.post("/auth/otc/request", json={"email": "promoted@example.com"})
+        code = _outbound_otc_codes("promoted@example.com")[-1]
+        client.post("/auth/otc/verify", json={"email": "promoted@example.com", "code": code})
+
+        # Before the grant: propose refused with 403.
+        r = client.post(
+            "/api/rfcs/propose",
+            json={"title": "T", "slug": "t-pre", "pitch": "p", "tags": []},
+        )
+        assert r.status_code == 403
+
+        # The admin gesture (v0.8.0 shape — direct UPDATE; v0.9.0 will
+        # ship a UI). The test stamps `permission_decided_by` and
+        # `permission_decided_at` as the v0.9.0 admin UI will, so the
+        # column population exercises the schema slot. user_id=99 is
+        # a placeholder admin row — provision it so the FK resolves.
+        provision_user_row(user_id=99, login="adminuser", role="admin")
+        db.conn().execute(
+            """
+            UPDATE users
+               SET permission_state = 'granted',
+                   permission_decided_by = 99,
+                   permission_decided_at = datetime('now')
+             WHERE email = ?
+            """,
+            ("promoted@example.com",),
+        )
+
+        # The next request reads the fresh column from the DB. The
+        # propose endpoint reaches the route body now (it then refuses
+        # for a different reason — the slug 't-prop' will fail
+        # the slug-format check or hit a mock-gitea path — but the
+        # status code is _not_ 403/401, which is the v0.8.0 assertion).
+        r = client.post(
+            "/api/rfcs/propose",
+            json={"title": "Title", "slug": "tprop", "pitch": "Pitch text.", "tags": []},
+        )
+        assert r.status_code != 403, r.text
+        assert r.status_code != 401, r.text
+
+
+def test_grandfathered_user_is_unaffected_by_migration(app_with_fake_gitea):
+    """An existing `users` row at migration time has
+    `permission_state='granted'` via the column default. The
+    grandfathered user passes write endpoints without filing a
+    beta request and without the admin UI. v0.6.0 (anon-write
+    audit) is the v0.6.0 contract; v0.8.0 widens the gate but
+    does not break this case.
+    """
+    from fastapi.testclient import TestClient
+    from app import db
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app) as client:
+        provision_user_row(user_id=5, login="oldhand", role="contributor")
+        # provision_user_row uses INSERT OR REPLACE INTO users with
+        # the column list it knows; permission_state is not in that
+        # list, so it picks up the column default ('granted') on
+        # insert. Confirm directly.
+        row = db.conn().execute(
+            "SELECT permission_state FROM users WHERE id = 5"
+        ).fetchone()
+        assert row["permission_state"] == "granted"
+
+        sign_in_as(
+            client,
+            user_id=5,
+            gitea_login="oldhand",
+            display_name="Old Hand",
+            role="contributor",
+        )
+
+        # Propose is write-shaped; the call should not refuse on
+        # the permission_state gate. (Subsequent failure modes —
+        # e.g. mock-gitea wiring — are not the v0.8.0 concern; this
+        # test asserts on the gate, not the propose body's success.)
+        r = client.post(
+            "/api/rfcs/propose",
+            json={"title": "Title", "slug": "gf-slug", "pitch": "Pitch.", "tags": []},
+        )
+        assert r.status_code != 403, r.text
+        assert r.status_code != 401, r.text
+
+
+# ---------------------------------------------------------------------------
+# /auth/otc/request accepts any email — the v0.7.0 allowlist gate is gone
+# ---------------------------------------------------------------------------
+
+
+def test_otc_request_accepts_any_email_regardless_of_allowlist(app_with_fake_gitea):
+    """v0.7.0 silently dropped OTC requests for emails not on the
+    `allowed_emails` table. v0.8.0 reverses this: the request
+    endpoint sends a code to any valid email; admission gates at
+    `permission_state` post-verify instead. The `allowed_emails`
+    table stays in the schema as a fast-path bypass for
+    deployments that want to pre-mark known-good emails (the v0.9.0
+    admin user-management page will collapse the two surfaces).
+    """
+    from fastapi.testclient import TestClient
+    from app import db
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app) as client:
+        _reset_outbound()
+        # Populate the allowlist with one specific email so the v0.7.0
+        # gate would have engaged. v0.8.0 ignores it for the request
+        # path.
+        db.conn().execute("INSERT INTO allowed_emails (email) VALUES (?)", ("known@example.com",))
+
+        # An email NOT on the allowlist still gets a code under v0.8.0.
+        r = client.post("/auth/otc/request", json={"email": "stranger@example.com"})
+        assert r.status_code == 200
+        codes = _outbound_otc_codes("stranger@example.com")
+        assert len(codes) == 1, "OTC code must be sent regardless of allowlist state"
+
+        # The row is there and the user can complete sign-in (and will
+        # land in 'pending' per the other tests).
+        row = db.conn().execute(
+            "SELECT 1 FROM otc_codes WHERE email = ?",
+            ("stranger@example.com",),
+        ).fetchone()
+        assert row is not None
+
+
+def test_allowlist_table_still_present_in_schema(app_with_fake_gitea):
+    """The schema migration leaves the `allowed_emails` table in
+    place — the admin UI from v0.3.0 still manages it for the
+    fast-path bypass deployments may use. This is a regression net
+    for "did the v0.8.0 cleanup accidentally drop the table"."""
+    from fastapi.testclient import TestClient
+    from app import db
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app):
+        # The table accepts inserts (i.e. it exists) — no schema check
+        # gymnastics needed.
+        db.conn().execute("INSERT INTO allowed_emails (email) VALUES (?)", ("kept@example.com",))
+        row = db.conn().execute(
+            "SELECT email FROM allowed_emails WHERE email = ?",
+            ("kept@example.com",),
+        ).fetchone()
+        assert row is not None

backend/tests/test_otc_vertical.py

@@ -13,9 +13,13 @@ sign-in path. The tests prove:
   * Expired codes refuse with 400.
   * Already-consumed codes refuse with 400 on re-use.
   * Wrong codes refuse with 400.
-  * Allowlist gate: when `allowed_emails` is populated and the email
-    isn't on it, the response is still 202 (no leak), but no email
-    lands in the outbound buffer and verify finds no matching code.
+  * Allowlist gate (v0.8.0 update): v0.7.0 silently dropped requests
+    for emails not on `allowed_emails`. v0.8.0 (item #6) removed
+    that gate from the request path; the admission gate is now
+    `permission_state` on the freshly-provisioned `users` row,
+    asserted in test_beta_access_vertical.py. The tests below
+    confirm v0.8.0's open-request shape for both on-list and
+    off-list emails.
   * Migration link: an existing OAuth-era user (with a `users.email`
     row) is linked by email on first OTC sign-in — `gitea_id` is
     preserved.
@@ -201,33 +205,45 @@ def test_otc_request_cooldown_is_per_email_not_global(app_with_fake_gitea):
 
 
 # ---------------------------------------------------------------------------
-# Allowlist gate
+# Allowlist gate — v0.8.0 update
+#
+# v0.7.0 gated the OTC request endpoint on the `allowed_emails` table:
+# emails not on the list got a silent drop (still 202, but no code).
+# v0.8.0 (roadmap item #6) reverses this: the request endpoint
+# accepts any valid email and sends a code. The admission gate moves
+# to `permission_state` on the freshly-provisioned `users` row,
+# which the next-tier tests in test_beta_access_vertical.py cover.
+# The `allowed_emails` table stays in the schema as a fast-path
+# bypass for admin convenience.
 # ---------------------------------------------------------------------------
 
 
-def test_otc_request_silently_drops_when_email_not_on_allowlist(app_with_fake_gitea):
+def test_otc_request_admits_emails_regardless_of_allowlist_population(app_with_fake_gitea):
+    """v0.8.0: the OTC request path no longer consults `allowed_emails`.
+    Whether the allowlist is empty or populated, every valid email
+    receives a code; admission gates at `permission_state` post-verify.
+    """
     from fastapi.testclient import TestClient
     from app import db
 
     app, _fake = app_with_fake_gitea
     with TestClient(app) as client:
         _reset_outbound()
-        # Populate the allowlist so the gate turns on.
+        # Populate the allowlist with one specific email; the v0.7.0
+        # gate would have engaged here.
         db.conn().execute("INSERT INTO allowed_emails (email) VALUES (?)", ("invited@example.com",))
 
+        # The not-on-list email still gets a code under v0.8.0.
         r = client.post("/auth/otc/request", json={"email": "stranger@example.com"})
-        # Still 202 — the allowlist's state is not leaked to callers.
         assert r.status_code == 200
-        # But no email was sent, and no row landed in otc_codes.
-        assert _outbound_otc_codes("stranger@example.com") == []
-        row = db.conn().execute(
-            "SELECT 1 FROM otc_codes WHERE email = ?",
-            ("stranger@example.com",),
-        ).fetchone()
-        assert row is None
+        assert len(_outbound_otc_codes("stranger@example.com")) == 1
 
 
 def test_otc_request_admits_allowlisted_email(app_with_fake_gitea):
+    """v0.8.0: still works for emails that happen to be on the legacy
+    allowlist — the table is no longer consulted at request time but
+    populated rows are admitted alongside everyone else (since the
+    gate is now open at the request surface)."""
     from fastapi.testclient import TestClient
     from app import db
 

frontend/package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "rfc-app-frontend",
-  "version": "0.13.0",
+  "version": "0.8.0",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "rfc-app-frontend",
-      "version": "0.13.0",
+      "version": "0.8.0",
       "dependencies": {
         "@codemirror/commands": "^6.10.3",
         "@codemirror/lang-markdown": "^6.5.0",

frontend/package.json

@@ -1,7 +1,7 @@
 {
   "name": "rfc-app-frontend",
   "private": true,
-  "version": "0.13.0",
+  "version": "0.8.0",
   "type": "module",
   "scripts": {
     "dev": "vite",

frontend/src/App.css

@@ -410,6 +410,26 @@
   cursor: pointer; padding: 0;
 }
 .otc-login .btn-link-quiet:hover { color: #1a1a1a; text-decoration: underline; }
+/* v0.8.0 — labels + textarea for the first-OTC profile capture step. */
+.otc-field-label {
+  font-size: 12px; color: #666;
+  margin: 8px 0 -4px;
+  font-weight: 600;
+}
+.otc-login textarea {
+  width: 100%;
+  padding: 10px 12px;
+  font-size: 15px;
+  border: 1px solid #ddd;
+  border-radius: 6px;
+  box-sizing: border-box;
+  font-family: inherit;
+  resize: vertical;
+}
+.otc-login textarea:focus {
+  outline: none;
+  border-color: #1a1a1a;
+}
 .otc-shortcut-hint {
   color: #888; font-size: 12px; margin: 4px 0 0;
 }
@@ -466,6 +486,22 @@
 .btn-link-quiet { color: #666; text-decoration: none; font-size: 13px; }
 .btn-link-quiet:hover { color: #1a1a1a; text-decoration: underline; }
 
+/* v0.8.0 — thin "your beta access is in review" banner. Shown on every
+   page (other than /beta-pending itself, which carries the larger
+   form of the message). Sits just under the app header so it doesn't
+   compete with the catalog rail. */
+.pending-access-banner {
+  background: #fff8e0;
+  border-bottom: 1px solid #e6dca0;
+  color: #4a3f00;
+  font-size: 13px;
+  padding: 8px 16px;
+  text-align: center;
+}
+.pending-access-banner a {
+  color: #4a3f00; text-decoration: underline;
+}
+
 /* ── §8 RFC view: three-column shape ─────────────────────────────────── */
 
 .main-pane {

frontend/src/App.jsx

@@ -87,11 +87,15 @@ export default function App() {
   // The deployment is in private beta: anonymous visitors get the full
   // app in read-only mode (viewer = null is passed through to every
   // component), and write affordances are hidden at the component
-  // level. /beta-pending is the post-OAuth-rejection page reachable by
-  // anyone. The original §14.1 Landing surface is retained for the
-  // `/welcome` URL only, in case a deployment wants to link to it.
+  // level. v0.8.0 (§6.1 / item #6): authenticated users with
+  // `permission_state='pending'` also pass through as `viewer` with
+  // their state attached — every write-gated affordance reads the
+  // state and treats pending the same as anonymous, while reads
+  // remain open. The /beta-pending page is the home root for a
+  // pending user.
   const viewer = me?.authenticated ? me.user : null
   const isAdmin = viewer && (viewer.role === 'owner' || viewer.role === 'admin')
+  const isPending = viewer && viewer.permission_state === 'pending'
 
   return (
     <div className="app">
@@ -142,11 +146,12 @@ export default function App() {
           )}
         </div>
       </header>
+      {isPending && <PendingAccessBanner />}
       <div className="app-body">
         <Routes>
           <Route path="/welcome" element={<Landing />} />
           <Route path="/login" element={<Login />} />
-          <Route path="/beta-pending" element={<BetaPending />} />
+          <Route path="/beta-pending" element={<BetaPending viewer={viewer} />} />
           <Route path="/philosophy" element={<PhilosophyWithSidebar viewer={viewer} />} />
           {/* §14.5 / §14.6: cookie-consent companions to /philosophy.
               Available to anonymous and authenticated viewers alike. */}
@@ -232,7 +237,26 @@ function AdminWithSidebar({ viewer }) {
   )
 }
 
+function PendingAccessBanner() {
+  // v0.8.0 — thin banner shown on every page (other than /beta-pending
+  // itself, which carries the same message in larger form) when the
+  // signed-in user's `permission_state='pending'`. Sign-out works
+  // normally via the header affordance.
+  return (
+    <div className="pending-access-banner">
+      Your beta access request is in review.{' '}
+      <Link to="/beta-pending">Learn more →</Link>
+    </div>
+  )
+}
+
 function Welcome({ viewer }) {
+  // v0.8.0 — a pending user landing on "/" gets the same page they'd
+  // see at /beta-pending, inline. This is the post-OTC home root for
+  // a user awaiting admin grant.
+  if (viewer && viewer.permission_state === 'pending') {
+    return <BetaPending viewer={viewer} />
+  }
   if (!viewer) {
     return (
       <div className="welcome">

frontend/src/api.js

@@ -49,6 +49,22 @@ export async function verifyOtc(email, code) {
   return jsonOrThrow(res)
 }
 
+// ── v0.8.0: open beta-access request flow (§6.1 / §14.1) ─────────────────
+//
+// On the first OTC sign-in, the user lands in `permission_state='pending'`
+// and `/api/auth/me` reports `needs_profile=true`. The Login.jsx surface
+// then prompts for first/last/why and POSTs them here. After this lands,
+// the user sees the /beta-pending page until an admin grants access.
+
+export async function submitBetaRequest({ first_name, last_name, beta_request_reason }) {
+  const res = await fetch('/api/auth/me/beta-request', {
+    method: 'POST',
+    headers: { 'Content-Type': 'application/json' },
+    body: JSON.stringify({ first_name, last_name, beta_request_reason }),
+  })
+  return jsonOrThrow(res)
+}
+
 export async function listRFCs() {
   return jsonOrThrow(await fetch('/api/rfcs'))
 }

frontend/src/components/BetaPending.jsx

@@ -1,38 +1,59 @@
-// BetaPending.jsx — the post-OAuth-rejection page.
+// BetaPending.jsx — the "your request is in review" page (§6.1 / §14.1).
 //
-// When a deployment is in private-beta mode (i.e. its `allowed_emails`
-// table has any rows), the OAuth callback redirects unrecognised users
-// here instead of provisioning them. The framework cannot know the
-// deployment operator's preferred contact channel — so the deployment
-// supplies one via VITE_BETA_CONTACT (an email, URL, or short
-// instruction). If unset, we render a generic ask-the-operator line.
+// v0.3.0 introduced this surface as the post-OAuth-rejection page (a
+// user whose email wasn't on the `allowed_emails` table bounced here).
+// v0.8.0 (roadmap item #6) repurposes it as the post-OTC pending-grant
+// page: any authenticated user whose `permission_state='pending'` lands
+// here on root visits, after a fresh-OTC profile capture, or via the
+// header "Your beta access is in review" affordance.
+//
+// The deployment supplies a contact channel via VITE_BETA_CONTACT (an
+// email, URL, or short instruction). If unset, we render a generic
+// ask-the-operator line.
 
 import { Link } from 'react-router-dom'
 
-export default function BetaPending() {
+export default function BetaPending({ viewer }) {
   const contact = import.meta.env.VITE_BETA_CONTACT || ''
+  const isPending = viewer?.permission_state === 'pending'
   return (
     <div className="beta-pending">
       <div className="beta-pending-inner">
-        <h1>{import.meta.env.VITE_APP_NAME} is in private Beta.</h1>
-        <p>
-          Discussion and contribution are gated to invited emails for now.
-          Reading is open — every super-draft, every active RFC, and every
-          public conversation is visible without signing in.
-        </p>
+        <h1>
+          {isPending
+            ? 'Your request is in review.'
+            : `${import.meta.env.VITE_APP_NAME} is in private Beta.`}
+        </h1>
+        {isPending ? (
+          <>
+            <p>
+              Thanks for telling us a bit about yourself. An admin will
+              review your request and get back to you as soon as we can.
+            </p>
+            <p>
+              While you wait, the catalog on the left lists every super-draft
+              and active RFC in the framework — reading is open. Discussion
+              and contribution unlock once your access is granted.
+            </p>
+          </>
+        ) : (
+          <p>
+            Discussion and contribution are gated to invited contributors for
+            now. Reading is open — every super-draft, every active RFC, and
+            every public conversation is visible without signing in.
+          </p>
+        )}
         {contact ? (
           <p className="beta-pending-contact">
-            To request access, contact <strong>{contact}</strong> with the
-            email address you'd like to sign in with.
+            Questions? Contact <strong>{contact}</strong>.
           </p>
         ) : (
           <p className="beta-pending-contact">
-            To request access, contact the deployment operator with the email
-            address you'd like to sign in with.
+            Questions? Contact the deployment operator.
           </p>
         )}
         <div className="beta-pending-actions">
-          <Link className="btn-primary" to="/">Browse as a guest</Link>
+          <Link className="btn-primary" to="/">Browse the catalog</Link>
           <Link className="btn-link-quiet" to="/philosophy">Read the philosophy →</Link>
         </div>
       </div>

frontend/src/components/Login.jsx

@@ -1,41 +1,57 @@
-// Login.jsx — v0.7.0's primary sign-in surface (§6.2).
+// Login.jsx — v0.7.0's primary sign-in surface (§6.2), extended by
+// v0.8.0 (§6.1 / §14.1, roadmap item #6) with the first-OTC profile
+// capture step.
 //
-// Two-step:
+// Three-step (the third is conditional):
 //   1. Enter email → POST /auth/otc/request → on 200, advance.
 //      On 429 (rate-limit), surface a "wait a moment" hint and keep
 //      the user on step 1.
 //   2. Enter the six-digit code from the email → POST /auth/otc/verify
-//      → on 200, redirect to the post-login landing. Cmd/Ctrl+Enter
-//      on the code field is the keyboard shortcut.
+//      → on 200, the response body carries `needs_profile`:
+//        * needs_profile=false (returning user, OAuth-era grandfather,
+//          or already-captured pending user): redirect to "/".
+//        * needs_profile=true (fresh OTC sign-in, no profile fields
+//          yet): advance to step 3.
+//      Cmd/Ctrl+Enter on the code field is the keyboard shortcut.
+//   3. First name, last name, and "why I should be included in the
+//      beta" → POST /api/auth/me/beta-request → redirect to
+//      /beta-pending. The user's row stays `permission_state='pending'`
+//      until an admin grants access.
 //
-// Server-side, /auth/otc/request always returns 202 for an unrecognized
-// email (so the allowlist gate doesn't leak), so this surface never
-// distinguishes "we couldn't reach you" from "we don't know you" —
-// it just advances to step 2. If a user is genuinely blocked, the
-// code never arrives.
+// Server-side, /auth/otc/request returns 202 uniformly so abuse paths
+// (e.g. distributed allowlist-probing) don't leak the recognized-email
+// set. This surface never distinguishes "we couldn't reach you" from
+// "we don't know you" — it just advances to step 2. If a request was
+// rate-limited, the user sees a 429 hint and stays on step 1.
 //
 // The legacy Gitea OAuth callback remains at /auth/login → /auth/callback
-// during the v0.7.0 migration; we surface a "Sign in with Gitea" link
-// as a fallback in the footer so users with active OAuth sessions or
-// older invite emails still have a path.
+// during the migration; we surface a "Sign in with Gitea" link as a
+// fallback in the footer so users with active OAuth sessions or older
+// invite emails still have a path.
 
 import { useEffect, useRef, useState } from 'react'
 import { useNavigate, Link } from 'react-router-dom'
-import { requestOtc, verifyOtc } from '../api'
+import { requestOtc, verifyOtc, submitBetaRequest } from '../api'
 
 export default function Login() {
   const [step, setStep] = useState('email')
   const [email, setEmail] = useState('')
   const [code, setCode] = useState('')
+  // v0.8.0 — step 3 capture fields.
+  const [firstName, setFirstName] = useState('')
+  const [lastName, setLastName] = useState('')
+  const [reason, setReason] = useState('')
   const [status, setStatus] = useState('')
   const [busy, setBusy] = useState(false)
   const emailRef = useRef(null)
   const codeRef = useRef(null)
+  const firstNameRef = useRef(null)
   const navigate = useNavigate()
 
   useEffect(() => {
     if (step === 'email') emailRef.current?.focus()
-    else codeRef.current?.focus()
+    else if (step === 'code') codeRef.current?.focus()
+    else if (step === 'profile') firstNameRef.current?.focus()
   }, [step])
 
   async function submitEmail(e) {
@@ -70,7 +86,19 @@ export default function Login() {
     setBusy(true)
     setStatus('')
     try {
-      await verifyOtc(email.trim(), code.trim())
+      const result = await verifyOtc(email.trim(), code.trim())
+      // v0.8.0 — a fresh OTC user lands in `permission_state='pending'`
+      // with no profile fields. The verify response now carries a
+      // `needs_profile` flag the server stamped from the row state;
+      // surface the capture form here instead of jumping straight to
+      // "/". The fallback path (no flag, e.g. an older backend
+      // before the migration ran) jumps to "/" as before.
+      if (result?.needs_profile) {
+        setStep('profile')
+        setStatus('')
+        setBusy(false)
+        return
+      }
       // Reload so App.jsx's getMe() picks up the fresh session. We
       // navigate to "/" via a hard load so any cached "anonymous"
       // view state in memory is dropped cleanly.
@@ -81,6 +109,34 @@ export default function Login() {
     }
   }
 
+  async function submitProfile(e) {
+    if (e) e.preventDefault()
+    const fn = firstName.trim()
+    const ln = lastName.trim()
+    const why = reason.trim()
+    if (!fn || !ln || !why) {
+      setStatus('All three fields are required.')
+      return
+    }
+    setBusy(true)
+    setStatus('')
+    try {
+      await submitBetaRequest({
+        first_name: fn,
+        last_name: ln,
+        beta_request_reason: why,
+      })
+      // The user is still `permission_state='pending'`; bounce them
+      // to /beta-pending so the next thing they see is the
+      // "your request is in review" page. Hard-load so App.jsx
+      // re-fetches /api/auth/me and picks up the captured fields.
+      window.location.assign('/beta-pending')
+    } catch (err) {
+      setStatus(err.message || 'Could not submit your request. Try again.')
+      setBusy(false)
+    }
+  }
+
   function onCodeKey(e) {
     // §6.2 ergonomic: Cmd/Ctrl+Enter submits from the code field.
     if ((e.metaKey || e.ctrlKey) && e.key === 'Enter') {
@@ -155,12 +211,64 @@ export default function Login() {
             </p>
           </form>
         )}
+        {step === 'profile' && (
+          <form onSubmit={submitProfile}>
+            <p className="otc-hint">
+              You're signed in. {import.meta.env.VITE_APP_NAME} is in private
+              beta — tell us a bit about yourself and an admin will review
+              your request.
+            </p>
+            <label className="otc-field-label">First name</label>
+            <input
+              ref={firstNameRef}
+              type="text"
+              autoComplete="given-name"
+              value={firstName}
+              onChange={e => setFirstName(e.target.value)}
+              required
+              disabled={busy}
+              maxLength={120}
+            />
+            <label className="otc-field-label">Last name</label>
+            <input
+              type="text"
+              autoComplete="family-name"
+              value={lastName}
+              onChange={e => setLastName(e.target.value)}
+              required
+              disabled={busy}
+              maxLength={120}
+            />
+            <label className="otc-field-label">
+              Why you'd like to be included in the beta
+            </label>
+            <textarea
+              value={reason}
+              onChange={e => setReason(e.target.value)}
+              required
+              disabled={busy}
+              rows={5}
+              maxLength={4000}
+              placeholder="A sentence or two is plenty."
+            />
+            <div className="otc-actions">
+              <button
+                type="submit"
+                disabled={busy || !firstName.trim() || !lastName.trim() || !reason.trim()}
+              >
+                {busy ? 'Submitting…' : 'Submit request'}
+              </button>
+            </div>
+          </form>
+        )}
         {status && <p className="otc-status">{status}</p>}
-        <p className="otc-fallback">
-          <Link to="/philosophy">Read the philosophy →</Link>
-          <span className="otc-fallback-sep">·</span>
-          <a href="/auth/login">Sign in with Gitea (fallback)</a>
-        </p>
+        {step !== 'profile' && (
+          <p className="otc-fallback">
+            <Link to="/philosophy">Read the philosophy →</Link>
+            <span className="otc-fallback-sep">·</span>
+            <a href="/auth/login">Sign in with Gitea (fallback)</a>
+          </p>
+        )}
       </div>
     </div>
   )