Release 0.10.0: user-set passcodes (OTC stays as fallback)

After a successful OTC sign-in, a contributor can set a passcode
(4-20 characters, bcrypt-hashed) and use email + passcode for
subsequent sign-ins. OTC remains the structural fallback: five
consecutive failed verifies lock the passcode path for 15 minutes
(HTTP 423), and a forgotten passcode is recovered by requesting a
fresh code. Migration 015_passcode.sql adds four nullable columns
to the users table; existing rows pass through as OTC-only and can
opt into a passcode from a new Sign-in tab in /settings/notifications.
The /login surface is extended to a five-step flow (email → either
passcode or OTC code → optional post-OTC passcode offer → optional
set-passcode). SPEC corrections per §19.3 rule 2: §6 names the
three auth paths, §14.1 documents the stepped login flow, §17 lists
the four new /auth/passcode/* endpoints, §19.2 surfaces four new
candidates and refreshes the cross-refs.

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

CHANGELOG.md

@@ -23,191 +23,145 @@ 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
+## 0.10.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.
+**Minor — schema migration required; new auth path is additive.**
+This release lands user-set passcodes after OTC (roadmap item #8,
+SPEC §6.2). After a successful one-time-code sign-in, the user can
+set a passcode (4–20 characters) and use email + passcode for
+subsequent sign-ins. OTC remains the structural fallback: a
+forgotten passcode is recovered by requesting a fresh code, and
+five consecutive failed passcode verifies lock the passcode path
+for 15 minutes (HTTP 423) while leaving the OTC path open. The
+`/login` surface now consults a new `GET /auth/passcode/check`
+endpoint after the email step to decide whether to render a
+passcode input or an OTC code input; an "Use a code instead" link
+on the passcode step lets the user fall back to OTC manually. The
+`/settings/notifications` page grew a new "Sign-in" tab where the
+user can set, change, or remove their passcode.
 
-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.
+### Upgrade steps (from 0.8.0)
 
-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.
+1. **MUST** restart the backend so migration `015_passcode.sql`
+   runs. The migration adds four nullable columns to the `users`
+   table: `passcode_hash`, `passcode_set_at`,
+   `passcode_failed_attempts` (default 0), `passcode_locked_until`.
+   Existing rows pass through with `passcode_hash = NULL`, which
+   the runtime treats as "no passcode set" — every existing user
+   continues to sign in via OTC unchanged, and can opt into a
+   passcode from the new settings tab at any time.
+2. **MUST** rebuild the frontend so the v0.10.0 `/login` flow and
+   the new settings tab ship. `frontend/package.json#version` and
+   `VERSION` both move to `0.10.0`.
+3. **SHOULD** announce the new sign-in option to users. Wording
+   suggestion: "You can now set a passcode for faster sign-in.
+   We'll keep emailing one-time codes as a fallback — if you
+   forget your passcode, just request a code as usual."
+4. **MAY** leave the §6.2 default lockout shape (5 attempts,
+   15-minute window) unchanged. v0.10.0 does not expose env
+   tunables for these; raising or lowering them lives in §19.2
+   as a candidate.
 
 ### 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.
+- **`POST /auth/passcode/set`** — authenticated. Body `{passcode}`.
+  Validates length (4–20) and refuses obvious patterns from a small
+  denylist (`0000`, `1234`, `aaaa`, `password`, etc.). bcrypt-hashes
+  the passcode and writes `users.passcode_hash` plus
+  `users.passcode_set_at`. Clears any active lockout and the
+  failure counter (a user setting a fresh passcode is implicitly
+  re-authenticating). Replaces any prior passcode.
+- **`DELETE /auth/passcode`** — authenticated. Clears the passcode
+  hash and the set-at stamp; the user is back to OTC-only.
+- **`POST /auth/passcode/verify`** — unauthenticated. Body
+  `{email, passcode}`. Returns HTTP 200 + minimal user payload on
+  success; HTTP 423 with `locked_until` when the account is in the
+  lockout window; HTTP 400 for every other failure (the
+  wrong-passcode and unknown-email modes both collapse to 400 so
+  the response does not enumerate account state).
+- **`GET /auth/passcode/check`** — unauthenticated. Query param
+  `email`. Returns `{has_passcode: boolean}`. The Login.jsx flow
+  consults this after the email step to decide whether to render a
+  passcode input or fall back to OTC. The response carries only
+  the boolean; lockout state, the hash, and the `passcode_set_at`
+  stamp are not leaked. An unknown email and a known-without-
+  passcode email both return `false`, so the endpoint is
+  account-enumeration-safe.
+- **Schema migration** `015_passcode.sql` — four ALTER TABLE ADD
+  COLUMN statements on the `users` table:
+  - `passcode_hash TEXT` (nullable) — the bcrypt hash. NULL means
+    "no passcode set".
+  - `passcode_set_at TEXT` (nullable) — ISO-8601 timestamp.
+  - `passcode_failed_attempts INTEGER NOT NULL DEFAULT 0` —
+    consecutive failure counter since last success.
+  - `passcode_locked_until TEXT` (nullable) — lockout window
+    expiry; verify refuses with HTTP 423 while populated and
+    in the future.
+- **`backend/app/passcode.py`** — the passcode state machine:
+  validation (length + denylist), bcrypt hashing, set/clear,
+  status check, and the verify path with lockout management.
+- **`frontend/src/components/Login.jsx`** — extended to a five-step
+  surface: email → passcode-or-code → optional post-OTC
+  passcode-offer → optional set-passcode. The "Use a code instead"
+  link on the passcode step re-dispatches an OTC and switches to
+  the code step. A 423 from passcode verify auto-falls back to OTC
+  with a visible status message.
+- **"Sign-in" tab** in `/settings/notifications` — shows
+  passcode-set status, the recorded `passcode_set_at` stamp when
+  set, and Set / Change / Remove buttons. Mirrors the §14.5
+  "Privacy & cookies" tab pattern.
+- **SPEC `§6` / `§14.1` / `§17` / `§19.2`** corrections per §19.3
+  rule 2:
+  - §6 names the three current auth paths (OTC, passcode-with-OTC-
+    fallback, OAuth-fallback-during-migration).
+  - §14.1 documents the stepped `/login` surface and the passcode
+    check endpoint.
+  - §17 lists the four new `/auth/passcode/*` endpoints.
+  - §19.2 surfaces four new candidates (passcode policy tunables
+    via env, per-IP rate-limit on `/auth/passcode/verify`,
+    passcode-change "old passcode" challenge, passkey/WebAuthn);
+    the "device-trust 30d" entry's passcode cross-ref is updated;
+    the "first-OTC profile capture" entry's roadmap cross-ref is
+    updated.
 
 ### 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.
+- **`backend/app/main.py`** — registers the four new
+  `/auth/passcode/*` routes on the existing oauth router, alongside
+  the v0.7.0 `/auth/otc/*` routes.
+- **`backend/app/api.py`** — `/api/auth/me` payload now includes
+  `has_passcode` (boolean) and `passcode_set_at` (string or null)
+  so the settings surface can render the Set / Change / Remove
+  affordances without a second round trip.
+- **`frontend/src/api.js`** — adds `checkPasscode`, `verifyPasscode`,
+  `setPasscode`, `clearPasscode` helpers, neighboring the v0.7.0
+  `requestOtc` / `verifyOtc` block.
+- **`frontend/src/components/NotificationSettings.jsx`** — adds the
+  `SignInSection` component between `MutesSection` and
+  `PrivacyCookiesSection`.
 
-### Deferred to later releases
+### Tests
 
-- **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.
+- **`backend/tests/test_passcode_vertical.py`** — 17 new tests
+  cover: set requires session; check returns false for unknown and
+  for set-less users; check returns true after set without leaking
+  other fields; happy-path OTC → set → verify roundtrip; wrong
+  passcode increments the counter without locking; five consecutive
+  failures lock with 423 and persist `passcode_locked_until`;
+  lockout expires and the next attempt clears the counter; the OTC
+  path is unaffected by passcode lockout; clear wipes the hash and
+  set-at; setting a new passcode replaces the prior one and resets
+  the lockout; `passcode_set_at` updates on every set; validation
+  refuses too-short passcodes and denylist patterns; `/api/auth/me`
+  carries `has_passcode` and `passcode_set_at` correctly.
+
+### Environment variables
+
+None new. The existing `SECRET_KEY` continues to sign session
+cookies; passcode hashing reuses the bcrypt dependency added in
+v0.7.0. The lockout shape (5 attempts, 15 minutes) and the length
+range (4–20) are hard-coded in `backend/app/passcode.py`. See
+§19.2 for the env-tunable candidate.
 
 ## 0.13.0 — 2026-05-28
 

SPEC.md

@@ -356,32 +356,37 @@ merge with no data movement.
 
 Authorization is owned by the app. Gitea sees only the bot account.
 
-Authentication, as of v0.7.0, is by email + one-time-code: a visitor
-enters their email address, receives a six-digit code via SMTP, and
-exchanges the code for a session. The Gitea OAuth callback that
-v0.1 used as the human sign-in path remains as a migration fallback
-during the v0.7.0 window — `users.gitea_id` is preserved on existing
-rows so a grandfathered user signing in via either path resolves to
-the same row — but the primary surface points at OTC. `users.email`
-is the identity key for everything provisioned after v0.7.0;
-`users.gitea_id` is the grandfathering linker (nullable, partial-
-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.
+Authentication has three paths, in the order a visitor encounters
+them:
 
-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.
+1. **Email + one-time code (OTC).** The v0.7.0 primary path: a
+   visitor enters their email address, receives a six-digit code via
+   SMTP, and exchanges the code for a session. Used by every visitor
+   on first sign-in, and as the fallback for the other two paths.
+2. **Email + passcode (with OTC fallback).** Added in v0.10.0
+   (roadmap item #8). After a successful OTC sign-in, the visitor
+   may set a user-chosen passcode (4–20 characters, bcrypt-hashed at
+   rest) and use email + passcode on subsequent sign-ins. Five
+   consecutive failed verifies lock the passcode path for 15 minutes
+   (HTTP 423); during the lockout the user falls back to OTC. The
+   OTC path is unaffected by the passcode lockout, so a forgotten
+   passcode is recovered by requesting a fresh OTC — there is no
+   separate "forgot passcode" flow. The user can remove the passcode
+   at any time from the §6.2 sign-in settings tab, returning to
+   OTC-only.
+3. **Gitea OAuth fallback (migration only).** The v0.1 OAuth
+   callback remains functional during the v0.7.0 window, with a
+   small "Sign in with Gitea (fallback)" link on `/login` so users
+   with active OAuth sessions or older invite paths still have a
+   way in. Scheduled for removal in a future release per §19.2.
+
+`users.gitea_id` is preserved on existing rows so a grandfathered
+user signing in via any of the three paths resolves to the same row.
+`users.email` is the identity key for everything provisioned after
+v0.7.0; `users.gitea_id` is the grandfathering linker (nullable,
+partial-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.
 
 ### 6.1 Four roles, each a strict superset of the one below
 
@@ -399,14 +404,10 @@ pending-queue triage surface.
    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.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
+   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
    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.
@@ -448,38 +449,6 @@ 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
@@ -2035,24 +2004,35 @@ with Gitea"; v0.7.0's email/OTC surface replaced that as the primary
 gesture, with a small "Sign in with Gitea (fallback)" link surviving
 on `/login` itself for the migration window.
 
+`/login` itself is a stepped surface, driven by which auth path the
+viewer is currently on (§6):
+
+1. **Email step.** The viewer enters their email. The frontend
+   consults `GET /auth/passcode/check?email=…` to learn whether
+   this email has a passcode set. The check endpoint is
+   account-enumeration-safe — it returns `has_passcode: false` for
+   both "unknown email" and "known email without passcode", so a
+   probing client cannot distinguish the two from the response.
+2. **Either the passcode step or the OTC code step.** If the email
+   has a passcode set, the viewer is asked for it (v0.10.0).
+   Otherwise an OTC is dispatched and the viewer is asked for the
+   six-digit code from their email (v0.7.0).
+3. **Optional post-OTC passcode-offer step.** After a successful
+   OTC verify on an account with no passcode set, the surface
+   asks "Set a passcode for faster sign-in next time?" — the user
+   can dismiss the offer or set one inline. The skip-for-now path
+   redirects straight to `/`.
+
+The passcode step carries a "Use a code instead" link that
+re-dispatches an OTC and switches to the code step — the same path
+the lockout response (HTTP 423) takes automatically after five
+consecutive failed passcode verifies.
+
 This is the front door. It sets expectation before the user encounters
 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`,
@@ -2689,45 +2669,57 @@ 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.
-  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.
+  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.
 - `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
-  `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.
+  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.
+- `GET  /auth/passcode/check` — unauthenticated. Query param `email`.
+  Returns `{has_passcode: boolean}`. The frontend's `/login` surface
+  calls this after the email step to decide whether to render a
+  passcode input or fall back to OTC. The response carries only the
+  boolean; lockout state, the bcrypt hash, and the `passcode_set_at`
+  stamp are not leaked. An unknown email and a known-without-passcode
+  email both return `false`, so the endpoint is enumeration-safe.
+- `POST /auth/passcode/set` — authenticated (any role). Body carries
+  `passcode` (4–20 characters). bcrypt-hashes the passcode, writes
+  `users.passcode_hash` + `users.passcode_set_at`, clears the failure
+  counter and any active lockout. Refuses obvious patterns (a small
+  denylist: `0000`, `1234`, `aaaa`, `password`, etc.) and length
+  violations with HTTP 422. Replaces any prior passcode. v0.10.0.
+- `DELETE /auth/passcode` — authenticated. Clears
+  `users.passcode_hash` and `users.passcode_set_at`, returning the
+  user to OTC-only on next sign-in. v0.10.0.
+- `POST /auth/passcode/verify` — unauthenticated. Body carries
+  `email` and `passcode`. Locates the user, checks the lockout
+  window, and compares via bcrypt. On success: clears the failure
+  counter, refreshes `last_seen_at`, stores the session cookie,
+  returns HTTP 200 with the minimal user payload. On failure:
+  increments `passcode_failed_attempts`. After five consecutive
+  failures, stamps `passcode_locked_until = now + 15 minutes` and
+  returns HTTP 423 with a `locked_until` field; subsequent attempts
+  inside the window are refused with the same shape. After the
+  window expires, the next attempt clears the counter and proceeds
+  normally. The OTC path (§17 above) is unaffected by the passcode
+  lockout — a locked-out user can still request and verify a fresh
+  OTC. The wrong-passcode and unknown-email failure modes both
+  return HTTP 400 with a generic message; the no-passcode-set
+  failure also collapses to 400 so the response does not enumerate
+  account state. v0.10.0.
 - `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.
@@ -3703,72 +3695,22 @@ 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 (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.
+- **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. The roadmap item-#6 candidate (v0.8.0) 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.
 - **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`
@@ -3785,16 +3727,17 @@ Candidates surfaced during v0.8.0 (open beta-access request flow,
   its session once the OTC adoption curve flattens.
 - **Device trust (30-day skip).** *Surfaced by v0.7.0 — the
   signed-in cookie already lasts 30 days via SessionMiddleware,
-  but every sign-in still requires a fresh OTC.* The roadmap
-  item-#9 candidate adds a "trust this device" affordance on the
-  verify step that issues a longer-lived rotating token, so
-  returning visitors on the same device skip the OTC step. The
-  shape question is whether the trust is a signed cookie distinct
-  from the session, a row in a `device_trust` table keyed by a
-  random device-id, or a property of the session itself; and
-  whether the trust survives password-equivalent events (none
-  exist yet — passcodes are item #8 / v0.10.0) or only survives
-  explicit logout. Earns its session as the v0.11.0 design pass.
+  but every sign-in still requires a fresh OTC or passcode.* The
+  roadmap item-#9 candidate adds a "trust this device" affordance
+  on the verify step that issues a longer-lived rotating token,
+  so returning visitors on the same device skip both the OTC and
+  the passcode step. The shape question is whether the trust is a
+  signed cookie distinct from the session, a row in a `device_trust`
+  table keyed by a random device-id, or a property of the session
+  itself; and whether the trust survives password-equivalent events
+  — v0.10.0's passcode-change and passcode-clear gestures are the
+  v1 instances — or only survives explicit logout. Earns its
+  session as the v0.11.0 design pass.
 - **Cloudflare Turnstile (or equivalent) on `/auth/otc/request`.**
   *Surfaced by v0.7.0 — the endpoint is now the new abuse hot
   path.* Per-email cooldown stops the trivial loop; what it
@@ -3814,6 +3757,47 @@ Candidates surfaced during v0.8.0 (open beta-access request flow,
   harness mocks the challenge. Earns its session as the v0.12.0
   design pass.
 
+Candidates surfaced during v0.10.0 (user-set passcodes, §6.2 /
+roadmap item #8):
+
+- **Passcode policy tunables via env.** v0.10.0 hard-codes the
+  lockout shape (5 consecutive failures → 15-minute lockout) and
+  the min/max passcode length (4 / 20) in
+  `backend/app/passcode.py`. The denylist of obvious patterns is
+  also hard-coded. A deployment that wants tighter or looser rules
+  has to fork the constants. Two env vars
+  (`PASSCODE_LOCKOUT_AFTER_ATTEMPTS`,
+  `PASSCODE_LOCKOUT_DURATION_MINUTES`) would let operators
+  reshape the lockout without forking; a third
+  (`PASSCODE_MIN_LENGTH`) would cover the length floor. Earns its
+  session if a deployment surfaces evidence that the v1 defaults
+  bite.
+- **Per-IP rate-limiting on `/auth/passcode/verify`.** v0.10.0's
+  lockout is per-account: 5 failures against the same email lock
+  that account for 15 minutes. A distributed attacker that knows
+  many emails can fan out across them without ever tripping any
+  one account's lockout. Adding a per-IP throttle (e.g., 30
+  passcode-verify attempts / minute / IP, returning HTTP 429) is
+  the natural pairing. Defer-able — the per-account lockout is
+  the v1 shape that closes the loud-loop case; the per-IP
+  distributed case waits on evidence. Touches §6.2 and §17.
+- **Passcode-change "still know your old passcode" challenge.**
+  v0.10.0 lets a signed-in user replace their passcode from
+  `/settings/notifications` without re-entering the old one — the
+  session is sufficient. A future hardening pass may require the
+  old passcode (or a fresh OTC verify) before accepting the
+  change, to mitigate session-hijack scenarios where the attacker
+  rotates the passcode to lock the legitimate owner out. The same
+  question applies to the clear gesture. Earns its session if
+  session-hijack becomes a real threat surface.
+- **Passkey / WebAuthn.** A much heavier next step than passcodes:
+  hardware-backed device credentials that resist phishing. The
+  v0.10.0 passcode shape is a stopgap for the "I'd rather not
+  type a code every time" ergonomic problem; passkeys are the
+  long-term answer. Out of scope for the current roadmap —
+  earns a dedicated session if/when the deployment grows enough
+  that the phishing surface justifies the integration cost.
+
 Candidates surfaced during v0.13.0 (cookie / privacy consent, §14.5
 and §14.6):
 

VERSION

@@ -1 +1 @@
-0.8.0
+0.10.0

backend/app/api.py

@@ -55,17 +55,6 @@ 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,
@@ -131,28 +120,17 @@ 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.
+        # v0.10.0: surface a single `has_passcode` flag so the §6.2
+        # settings tab can render "Set passcode" vs. "Change/Remove
+        # passcode" without a second round trip. The set-at timestamp
+        # rides along for the same reason. The hash itself is never
+        # exposed.
         row = db.conn().execute(
-            "SELECT first_name, last_name, beta_request_reason FROM users WHERE id = ?",
+            "SELECT passcode_hash, passcode_set_at 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
-        )
+        has_passcode = bool(row and row["passcode_hash"])
+        passcode_set_at = row["passcode_set_at"] if (row and has_passcode) else None
         return {
             "authenticated": True,
             "user": {
@@ -162,68 +140,11 @@ 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,
+                "has_passcode": has_passcode,
+                "passcode_set_at": passcode_set_at,
             },
         }
 
-    # ---------------------------------------------------------------
-    # 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,12 +30,6 @@ 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(
@@ -96,13 +90,6 @@ 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).
@@ -145,27 +132,17 @@ 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, permission_state)
-            VALUES (?, ?, ?, ?, ?, ?, 'granted')
+            INSERT INTO users (gitea_id, gitea_login, email, display_name, avatar_url, role)
+            VALUES (?, ?, ?, ?, ?, ?)
             """,
             (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
@@ -183,7 +160,6 @@ def provision_user(config: Config, profile: dict[str, Any]) -> SessionUser:
         email=email,
         avatar_url=avatar,
         role=role,
-        permission_state=permission_state,
     )
 
 
@@ -202,12 +178,6 @@ 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,
     }
 
 
@@ -218,7 +188,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, permission_state FROM users WHERE id = ?",
+        "SELECT id, gitea_id, gitea_login, email, display_name, avatar_url, role FROM users WHERE id = ?",
         (raw["user_id"],),
     ).fetchone()
     if row is None:
@@ -229,11 +199,6 @@ 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,
@@ -242,7 +207,6 @@ 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",
     )
 
 
@@ -254,31 +218,11 @@ def require_user(request: Request) -> SessionUser:
 
 
 def require_contributor(request: Request) -> SessionUser:
-    """§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.
-    """
+    """§6.1: authenticated, not write-muted."""
     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

@@ -24,6 +24,7 @@ from . import (
     email_otc,
     hygiene,
     otc,
+    passcode as passcode_mod,
     providers as providers_mod,
     webhooks,
 )
@@ -44,6 +45,15 @@ class OtcVerifyBody(BaseModel):
     code: str = Field(min_length=1, max_length=16)
 
 
+class PasscodeSetBody(BaseModel):
+    passcode: str = Field(min_length=1, max_length=64)
+
+
+class PasscodeVerifyBody(BaseModel):
+    email: str = Field(min_length=3, max_length=320)
+    passcode: str = Field(min_length=1, max_length=64)
+
+
 @asynccontextmanager
 async def lifespan(app: FastAPI):
     config = load_config()
@@ -172,26 +182,6 @@ 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": {
@@ -199,9 +189,75 @@ 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,
+        }
+
+    # ---------------------------------------------------------------
+    # v0.10.0: user-set passcodes after OTC (§6.2, roadmap item #8).
+    #
+    # After a successful OTC sign-in, a contributor may set a passcode
+    # and use email + passcode for subsequent sign-ins. OTC remains the
+    # forgot-passcode fallback — a verify failure beyond 5 consecutive
+    # attempts locks the passcode path for 15 minutes; the OTC path is
+    # unaffected by the lockout.
+    # ---------------------------------------------------------------
+
+    @router.get("/auth/passcode/check")
+    async def passcode_check(email: str = ""):
+        """Does this email have a passcode set? Anonymous endpoint —
+        the Login.jsx flow calls this after the user types their email
+        to decide whether to render a passcode input or fall back to
+        OTC. We surface only the boolean; lockout state, the hash, and
+        the set-at stamp are not leaked here."""
+        status = passcode_mod.passcode_status(email)
+        return {"has_passcode": status.has_passcode}
+
+    @router.post("/auth/passcode/set")
+    async def passcode_set(body: PasscodeSetBody, request: Request):
+        """Set or replace the signed-in user's passcode. Requires an
+        active session (OTC- or passcode-authenticated)."""
+        user = auth.require_user(request)
+        try:
+            passcode_mod.set_passcode(user.user_id, body.passcode)
+        except passcode_mod.PasscodeValidationError as e:
+            raise HTTPException(422, str(e))
+        return {"ok": True}
+
+    @router.delete("/auth/passcode")
+    async def passcode_delete(request: Request):
+        """Remove the signed-in user's passcode. The user is back to
+        OTC-only on next sign-in."""
+        user = auth.require_user(request)
+        passcode_mod.clear_passcode(user.user_id)
+        return {"ok": True}
+
+    @router.post("/auth/passcode/verify")
+    async def passcode_verify(body: PasscodeVerifyBody, request: Request):
+        """Sign in with email + passcode. Returns the standard session
+        payload on success; HTTP 423 with `locked_until` when the
+        account is in the lockout window; HTTP 400 for every other
+        failure (the wrong-vs-unknown distinction is intentionally
+        collapsed so a probing client cannot enumerate emails)."""
+        result = passcode_mod.verify_passcode(body.email, body.passcode)
+        if result.reason == "locked":
+            raise HTTPException(
+                423,
+                {
+                    "detail": "Too many failed attempts; sign in with a one-time code instead",
+                    "locked_until": result.locked_until,
+                },
+            )
+        if not result.ok or result.user is None:
+            raise HTTPException(400, "Invalid passcode")
+        auth.store_session(request, result.user)
+        return {
+            "ok": True,
+            "user": {
+                "id": result.user.user_id,
+                "display_name": result.user.display_name,
+                "email": result.user.email,
+                "role": result.user.role,
+            },
         }
 
     return router

backend/app/otc.py

@@ -1,4 +1,4 @@
-"""§6.2 / v0.7.0 / v0.8.0: email + one-time-code sign-in.
+"""§6.2 / v0.7.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,25 +25,14 @@ 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`,
-    and `permission_state = 'pending'` (v0.8.0 — see below).
+    row is provisioned with `gitea_id = NULL`, `gitea_login = NULL`.
 
-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.
+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.
 """
 from __future__ import annotations
 
@@ -55,7 +44,7 @@ from dataclasses import dataclass
 import bcrypt
 
 from . import db
-from .auth import SessionUser
+from .auth import SessionUser, allowlist_is_active
 
 log = logging.getLogger(__name__)
 
@@ -112,15 +101,25 @@ 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.
 # ---------------------------------------------------------------------------
 
 
@@ -128,16 +127,14 @@ def _check_code(code: str, code_hash: str) -> bool:
 class RequestOutcome:
     """The outcome of a `request_code` call.
 
-    `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.
+    `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.
     """
     sent: bool
     code: str | None
-    reason: str  # 'sent' | 'cooldown' | 'invalid'
+    reason: str  # 'sent' | 'allowlist' | 'cooldown' | 'invalid'
 
 
 def request_code(email: str) -> RequestOutcome:
@@ -163,6 +160,13 @@ 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(
@@ -271,16 +275,12 @@ 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. `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.
+         trip still resolves the same row.
       2. Otherwise: a fresh contributor row with `gitea_id = NULL`,
-         `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.
+         `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.
 
     The §6.1 owner-zero bootstrap still applies: if the email matches
     the configured `OWNER_GITEA_LOGIN`-derived owner identity, the row
@@ -307,19 +307,13 @@ 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, permission_state)
-        VALUES (NULL, NULL, ?, ?, '', 'contributor', 'pending')
+        INSERT INTO users (gitea_id, gitea_login, email, display_name, avatar_url, role)
+        VALUES (NULL, NULL, ?, ?, '', 'contributor')
         """,
         (email, display),
     )
@@ -332,5 +326,4 @@ def provision_or_link_user(email: str) -> SessionUser:
         email=email,
         avatar_url="",
         role="contributor",
-        permission_state="pending",
     )

backend/app/passcode.py

@@ -0,0 +1,367 @@
+"""§6.2 / v0.10.0: user-set passcodes after OTC (roadmap item #8).
+
+After a successful OTC sign-in, a contributor may set a passcode and
+use email + passcode for subsequent sign-ins. OTC remains the fallback
+— a forgotten passcode is recovered by requesting a fresh OTC.
+
+This module is the state machine behind the four `/auth/passcode/*`
+endpoints (`set`, `clear`, `verify`, `check`). The endpoints in
+`main.py` thin-wrap these helpers in the same shape the OTC module
+uses (see `otc.py`).
+
+Shape:
+
+  * `set_passcode(user_id, passcode)` — bcrypt-hash the passcode and
+    write it to `users.passcode_hash` + `users.passcode_set_at`.
+    Validation (length, denylist) happens here, not at the endpoint,
+    so the rule lives in one place. Replaces any prior passcode.
+  * `clear_passcode(user_id)` — null out `passcode_hash` and
+    `passcode_set_at`. The user is back to OTC-only.
+  * `verify_passcode(email, passcode)` — locate the user by email,
+    check lockout, compare via bcrypt, manage the failure counter,
+    and return a populated `SessionUser` on success.
+  * `passcode_status(email)` — does this email have a passcode set?
+    Used by the `/auth/passcode/check` endpoint that the Login.jsx
+    flow consults after the user types their email.
+
+Lockout is a v1 shape: 5 consecutive failures sets
+`passcode_locked_until` to `now + 15 minutes`, after which a verify
+attempt that lands inside the window returns HTTP 423. The OTC path
+is unaffected by the lockout — a user can request and verify a fresh
+OTC to sign in while their passcode is locked out, and `verify_code`
+in `otc.py` does not consult these columns.
+
+The lockout window and the failure threshold are hard-coded here.
+Tuning them via env vars (or moving to per-IP rate-limiting) is a
+§19.2 candidate; see SPEC §19.2.
+"""
+from __future__ import annotations
+
+import logging
+from dataclasses import dataclass
+
+import bcrypt
+
+from . import db
+from .auth import SessionUser
+
+log = logging.getLogger(__name__)
+
+
+# ---------------------------------------------------------------------------
+# Tunables — intentionally hard-coded in v0.10.0 (see module docstring).
+# ---------------------------------------------------------------------------
+
+LOCKOUT_AFTER_FAILED_ATTEMPTS = 5
+LOCKOUT_DURATION_MINUTES = 15
+
+PASSCODE_MIN_LENGTH = 4
+PASSCODE_MAX_LENGTH = 20
+
+# A small denylist of patterns we never want a passcode to be. The
+# rule is "no obvious patterns"; the list is deliberately small —
+# every entry here is a verbatim string match. A heavier check
+# (sequential digits, single-character runs of length >= N, etc.)
+# is a §19.2 candidate.
+PASSCODE_DENYLIST: frozenset[str] = frozenset(
+    {
+        "0000",
+        "1111",
+        "2222",
+        "3333",
+        "4444",
+        "5555",
+        "6666",
+        "7777",
+        "8888",
+        "9999",
+        "1234",
+        "12345",
+        "123456",
+        "1234567",
+        "12345678",
+        "123456789",
+        "1234567890",
+        "0123",
+        "01234",
+        "012345",
+        "0123456",
+        "01234567",
+        "012345678",
+        "0123456789",
+        "abcd",
+        "abcde",
+        "abcdef",
+        "qwer",
+        "qwerty",
+        "asdf",
+        "asdfg",
+        "asdfgh",
+        "aaaa",
+        "bbbb",
+        "cccc",
+        "password",
+        "letmein",
+    }
+)
+
+
+# ---------------------------------------------------------------------------
+# Validation
+# ---------------------------------------------------------------------------
+
+
+class PasscodeValidationError(Exception):
+    """The proposed passcode failed validation. The endpoint surface
+    maps this to HTTP 422 with the message intact."""
+
+
+def _validate(passcode: str) -> str:
+    """Return the normalized passcode (stripped) or raise.
+
+    Rules:
+      * 4-20 characters after stripping leading/trailing whitespace.
+      * Not on the small denylist of obvious patterns.
+
+    No character-class restriction beyond that — the spec says
+    "numeric PIN or short alphanumeric"; we don't refuse other
+    characters because the entropy isn't load-bearing (the per-account
+    lockout is what carries the security weight, mirroring the OTC
+    shape from v0.7.0).
+    """
+    pc = (passcode or "").strip()
+    if not pc:
+        raise PasscodeValidationError("Passcode is required")
+    if len(pc) < PASSCODE_MIN_LENGTH:
+        raise PasscodeValidationError(
+            f"Passcode must be at least {PASSCODE_MIN_LENGTH} characters"
+        )
+    if len(pc) > PASSCODE_MAX_LENGTH:
+        raise PasscodeValidationError(
+            f"Passcode must be at most {PASSCODE_MAX_LENGTH} characters"
+        )
+    if pc.lower() in PASSCODE_DENYLIST:
+        raise PasscodeValidationError("Passcode is too common; pick something less obvious")
+    return pc
+
+
+# ---------------------------------------------------------------------------
+# Hashing
+# ---------------------------------------------------------------------------
+
+
+def _hash(passcode: str) -> str:
+    return bcrypt.hashpw(passcode.encode("utf-8"), bcrypt.gensalt()).decode("ascii")
+
+
+def _check(passcode: str, passcode_hash: str) -> bool:
+    try:
+        return bcrypt.checkpw(passcode.encode("utf-8"), passcode_hash.encode("ascii"))
+    except (ValueError, TypeError):
+        return False
+
+
+# ---------------------------------------------------------------------------
+# Set / clear
+# ---------------------------------------------------------------------------
+
+
+def set_passcode(user_id: int, passcode: str) -> None:
+    """Hash and store the passcode. Replaces any prior passcode on the
+    same row; clears the failure counter and lockout (a user setting a
+    fresh passcode is implicitly re-authenticating their account)."""
+    pc = _validate(passcode)
+    h = _hash(pc)
+    db.conn().execute(
+        """
+        UPDATE users
+           SET passcode_hash = ?,
+               passcode_set_at = datetime('now'),
+               passcode_failed_attempts = 0,
+               passcode_locked_until = NULL
+         WHERE id = ?
+        """,
+        (h, user_id),
+    )
+
+
+def clear_passcode(user_id: int) -> None:
+    """Remove the passcode. The user is back to OTC-only on next sign-in."""
+    db.conn().execute(
+        """
+        UPDATE users
+           SET passcode_hash = NULL,
+               passcode_set_at = NULL,
+               passcode_failed_attempts = 0,
+               passcode_locked_until = NULL
+         WHERE id = ?
+        """,
+        (user_id,),
+    )
+
+
+# ---------------------------------------------------------------------------
+# Check (status surface for the Login.jsx flow)
+# ---------------------------------------------------------------------------
+
+
+@dataclass
+class PasscodeStatus:
+    """The shape `/auth/passcode/check` returns.
+
+    `has_passcode` is the only signal the frontend needs to decide
+    whether to show a passcode input or an OTC request step. We do
+    not leak the hash, the set-at timestamp, or the lockout state —
+    a probing client that wants to know "is this account locked
+    out" can attempt a verify and read the 423.
+    """
+    has_passcode: bool
+
+
+def passcode_status(email: str) -> PasscodeStatus:
+    email = (email or "").strip()
+    if not email or "@" not in email:
+        return PasscodeStatus(has_passcode=False)
+    row = db.conn().execute(
+        "SELECT passcode_hash FROM users WHERE email = ? COLLATE NOCASE",
+        (email,),
+    ).fetchone()
+    if row is None:
+        return PasscodeStatus(has_passcode=False)
+    return PasscodeStatus(has_passcode=bool(row["passcode_hash"]))
+
+
+# ---------------------------------------------------------------------------
+# Verify
+# ---------------------------------------------------------------------------
+
+
+@dataclass
+class VerifyOutcome:
+    """Result of a `verify_passcode` call.
+
+    `reason` distinguishes the failure modes the endpoint surfaces as
+    distinct HTTP shapes:
+      * 'ok'        — populated `user`, HTTP 200.
+      * 'unknown'   — no user with this email, HTTP 400 (generic).
+      * 'no_passcode' — user exists but never set a passcode, HTTP 400
+        (the frontend should fall back to OTC).
+      * 'locked'    — user is currently in the lockout window, HTTP
+        423. `locked_until` carries the ISO-8601 stamp for the client.
+      * 'wrong'     — passcode didn't match. HTTP 400. If the failure
+        crossed the lockout threshold the row is now locked; the
+        endpoint surfaces this as a fresh `locked` response on the
+        next attempt rather than collapsing the two states here.
+    """
+    ok: bool
+    user: SessionUser | None
+    reason: str
+    locked_until: str | None = None
+
+
+def verify_passcode(email: str, passcode: str) -> VerifyOutcome:
+    email = (email or "").strip()
+    passcode = (passcode or "").strip()
+    if not email or not passcode:
+        return VerifyOutcome(ok=False, user=None, reason="unknown")
+
+    row = db.conn().execute(
+        """
+        SELECT id, gitea_id, gitea_login, email, display_name, avatar_url, role,
+               passcode_hash, passcode_failed_attempts, passcode_locked_until
+          FROM users
+         WHERE email = ? COLLATE NOCASE
+        """,
+        (email,),
+    ).fetchone()
+    if row is None:
+        return VerifyOutcome(ok=False, user=None, reason="unknown")
+    if not row["passcode_hash"]:
+        return VerifyOutcome(ok=False, user=None, reason="no_passcode")
+
+    # Lockout check: if `passcode_locked_until` is populated and in the
+    # future, the verify is refused without touching the hash. Once the
+    # window has elapsed we let the verify proceed; the failed-attempts
+    # counter is also reset so the user gets a fresh 5-attempt budget.
+    locked_until = row["passcode_locked_until"]
+    if locked_until:
+        still_locked = db.conn().execute(
+            "SELECT datetime(?) > datetime('now') AS still_locked",
+            (locked_until,),
+        ).fetchone()["still_locked"]
+        if still_locked:
+            return VerifyOutcome(
+                ok=False,
+                user=None,
+                reason="locked",
+                locked_until=locked_until,
+            )
+        # Lockout expired — clear the counter so the next failure starts
+        # from zero, and continue with the verify.
+        db.conn().execute(
+            """
+            UPDATE users
+               SET passcode_failed_attempts = 0,
+                   passcode_locked_until = NULL
+             WHERE id = ?
+            """,
+            (row["id"],),
+        )
+
+    if _check(passcode, row["passcode_hash"]):
+        # Success: clear the counter (a single success wipes the
+        # accumulated failures — the threshold tracks *consecutive*
+        # failures).
+        db.conn().execute(
+            """
+            UPDATE users
+               SET passcode_failed_attempts = 0,
+                   passcode_locked_until = NULL,
+                   last_seen_at = datetime('now')
+             WHERE id = ?
+            """,
+            (row["id"],),
+        )
+        return VerifyOutcome(
+            ok=True,
+            user=SessionUser(
+                user_id=row["id"],
+                gitea_id=row["gitea_id"] or 0,
+                gitea_login=row["gitea_login"] or "",
+                display_name=row["display_name"],
+                email=row["email"] or email,
+                avatar_url=row["avatar_url"] or "",
+                role=row["role"],
+            ),
+            reason="ok",
+        )
+
+    # Failure: increment the counter. If this push crosses the
+    # threshold, stamp the lockout. The next verify attempt against
+    # the same row returns 423 with the `locked_until` stamp.
+    next_count = (row["passcode_failed_attempts"] or 0) + 1
+    if next_count >= LOCKOUT_AFTER_FAILED_ATTEMPTS:
+        db.conn().execute(
+            f"""
+            UPDATE users
+               SET passcode_failed_attempts = ?,
+                   passcode_locked_until = datetime('now', '+{LOCKOUT_DURATION_MINUTES} minutes')
+             WHERE id = ?
+            """,
+            (next_count, row["id"]),
+        )
+        new_locked_until = db.conn().execute(
+            "SELECT passcode_locked_until FROM users WHERE id = ?",
+            (row["id"],),
+        ).fetchone()["passcode_locked_until"]
+        return VerifyOutcome(
+            ok=False,
+            user=None,
+            reason="locked",
+            locked_until=new_locked_until,
+        )
+    db.conn().execute(
+        "UPDATE users SET passcode_failed_attempts = ? WHERE id = ?",
+        (next_count, row["id"]),
+    )
+    return VerifyOutcome(ok=False, user=None, reason="wrong")

backend/migrations/014_beta_access.sql

@@ -1,76 +0,0 @@
--- §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/migrations/015_passcode.sql

@@ -0,0 +1,52 @@
+-- §6.2 / v0.10.0: user-set passcodes after OTC (roadmap item #8).
+--
+-- After a successful OTC sign-in, a contributor may set a passcode
+-- (numeric PIN or short alphanumeric). Subsequent sign-ins on the same
+-- account can use email + passcode instead of email + OTC. OTC remains
+-- the structural fallback — a forgotten passcode is recovered by
+-- requesting a fresh OTC and signing in via that path. Per-account
+-- lockout after 5 consecutive verify failures redirects the user to
+-- the OTC path for 15 minutes; the OTC path itself is unaffected by
+-- the passcode lockout (a locked-out user can still receive a fresh
+-- code and sign in).
+--
+-- The columns are additive to the `users` table from `012_otc.sql`.
+-- v0.8.0's `permission_state` column (roadmap item #6) lands in the
+-- driver's integration order ahead of this migration; we do not touch
+-- that column here. v0.7.0's nullable-`gitea_id`/`gitea_login` shape
+-- is preserved verbatim.
+--
+-- Storage shape:
+--
+--   * `passcode_hash` (nullable) — bcrypt hash of the passcode.
+--     NULL means "no passcode set"; the user is OTC-only.
+--   * `passcode_set_at` (nullable) — timestamp of the most recent
+--     `passcode/set` call. Updated when a passcode is set or
+--     replaced; cleared when the passcode is removed.
+--   * `passcode_failed_attempts` — count of consecutive failed
+--     verify attempts since the last successful verify (or since
+--     the lockout cleared). Resets to 0 on success and on lockout
+--     expiry. Defaults to 0 so existing rows post-migration are
+--     not implicitly half-locked.
+--   * `passcode_locked_until` (nullable) — if populated and the
+--     timestamp is in the future, passcode verify is refused with
+--     HTTP 423. Cleared on successful verify after the window
+--     expires, or by the operator via direct DB intervention if
+--     ever needed (no admin endpoint surfaces this in v1).
+--
+-- v0.10.0 introduces no new env vars. The lockout window (5 attempts,
+-- 15 minutes) is hard-coded in `backend/app/passcode.py`; raising or
+-- lowering it is a future-§19.2 candidate. Passcode hashing reuses
+-- the bcrypt dependency added in v0.7.0 for OTC; no new secret is
+-- required (the existing `SECRET_KEY` continues to sign sessions).
+--
+-- Note on SQLite: ALTER TABLE ... ADD COLUMN is supported, so this
+-- migration does not need the rebuild dance that `012_otc.sql`
+-- required. The runner wraps each file in a single BEGIN/COMMIT
+-- block — see `backend/app/db.py` — so either every ADD COLUMN
+-- here lands or none do.
+
+ALTER TABLE users ADD COLUMN passcode_hash TEXT;
+ALTER TABLE users ADD COLUMN passcode_set_at TEXT;
+ALTER TABLE users ADD COLUMN passcode_failed_attempts INTEGER NOT NULL DEFAULT 0;
+ALTER TABLE users ADD COLUMN passcode_locked_until TEXT;

backend/tests/test_beta_access_vertical.py

@@ -1,390 +0,0 @@
-"""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,13 +13,9 @@ 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 (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.
+  * 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.
   * 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.
@@ -205,45 +201,33 @@ def test_otc_request_cooldown_is_per_email_not_global(app_with_fake_gitea):
 
 
 # ---------------------------------------------------------------------------
-# 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.
+# Allowlist gate
 # ---------------------------------------------------------------------------
 
 
-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.
-    """
+def test_otc_request_silently_drops_when_email_not_on_allowlist(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()
-        # Populate the allowlist with one specific email; the v0.7.0
-        # gate would have engaged here.
+        # Populate the allowlist so the gate turns on.
         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
-        assert len(_outbound_otc_codes("stranger@example.com")) == 1
+        # 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
 
 
 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
 

backend/tests/test_passcode_vertical.py

@@ -0,0 +1,532 @@
+"""End-to-end integration tests for the v0.10.0 user-set passcode
+vertical (§6.2, roadmap item #8).
+
+After a successful OTC sign-in the user can set a passcode and use
+email + passcode for subsequent sign-ins. OTC remains the structural
+fallback — these tests prove:
+
+  * `/auth/passcode/set` requires an active session.
+  * `/auth/passcode/check` returns `has_passcode` without leaking the
+    hash, the set-at stamp, or the lockout state.
+  * Happy path: OTC sign-in → set passcode → sign out → email +
+    passcode signs in (no OTC roundtrip).
+  * Wrong passcode increments the failure counter without locking.
+  * Five consecutive failures lock the passcode path (HTTP 423) and
+    persist `passcode_locked_until` on the user row.
+  * The lockout expires after `passcode_locked_until`; a verify
+    attempt past the window succeeds again and clears the counter.
+  * The OTC path is unaffected by the passcode lockout — a user
+    whose passcode is locked can still request and verify a fresh
+    OTC to sign in.
+  * Clearing the passcode wipes the hash; subsequent verify refuses
+    with the no-passcode failure shape.
+  * Setting a new passcode replaces the prior one (and resets the
+    failure counter / lockout state).
+  * `passcode_set_at` updates on every set call.
+  * The validation denylist refuses obvious patterns (e.g. `0000`,
+    `1234`).
+  * Passcode length is enforced (4-20).
+
+The fakes from `test_propose_vertical` give us a working app harness.
+The OTC envelope buffer from `test_otc_vertical` is reused for the
+OTC roundtrips this suite needs.
+"""
+from __future__ import annotations
+
+import pytest
+
+from test_propose_vertical import (  # noqa: F401
+    FakeGitea,
+    app_with_fake_gitea,
+    provision_user_row,
+    tmp_env,
+)
+
+
+# ---------------------------------------------------------------------------
+# Helpers — mirror the OTC suite's outbound-buffer helpers.
+# ---------------------------------------------------------------------------
+
+
+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]:
+    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
+
+
+def _sign_in_via_otc(client, email: str) -> None:
+    """Run an OTC request+verify so the client carries an authenticated
+    session. The cooldown is irrelevant on a fresh email; we don't
+    need to drop it."""
+    r = client.post("/auth/otc/request", json={"email": email})
+    assert r.status_code == 200, r.text
+    code = _outbound_otc_codes(email)[-1]
+    r = client.post("/auth/otc/verify", json={"email": email, "code": code})
+    assert r.status_code == 200, r.text
+
+
+# ---------------------------------------------------------------------------
+# Set passcode — auth-required, happy path
+# ---------------------------------------------------------------------------
+
+
+def test_set_passcode_requires_session(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app) as client:
+        r = client.post("/auth/passcode/set", json={"passcode": "secret123"})
+        assert r.status_code == 401
+
+
+def test_set_passcode_after_otc_landing_persists_hash(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_via_otc(client, "alice@example.com")
+
+        r = client.post("/auth/passcode/set", json={"passcode": "secret123"})
+        assert r.status_code == 200, r.text
+
+        row = db.conn().execute(
+            "SELECT passcode_hash, passcode_set_at FROM users WHERE email = ? COLLATE NOCASE",
+            ("alice@example.com",),
+        ).fetchone()
+        assert row is not None
+        assert row["passcode_hash"] is not None
+        # Not the plaintext.
+        assert row["passcode_hash"] != "secret123"
+        assert row["passcode_set_at"] is not None
+
+
+# ---------------------------------------------------------------------------
+# Check endpoint — leak-free shape
+# ---------------------------------------------------------------------------
+
+
+def test_check_endpoint_returns_false_for_unknown_email(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app) as client:
+        r = client.get("/auth/passcode/check", params={"email": "nobody@example.com"})
+        assert r.status_code == 200
+        assert r.json() == {"has_passcode": False}
+
+
+def test_check_endpoint_returns_false_for_user_without_passcode(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app) as client:
+        _reset_outbound()
+        _sign_in_via_otc(client, "bob@example.com")
+
+        r = client.get("/auth/passcode/check", params={"email": "bob@example.com"})
+        assert r.status_code == 200
+        assert r.json() == {"has_passcode": False}
+
+
+def test_check_endpoint_returns_true_after_set(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app) as client:
+        _reset_outbound()
+        _sign_in_via_otc(client, "carol@example.com")
+        client.post("/auth/passcode/set", json={"passcode": "letmein9"})
+
+        # Drop the session so the check is read in the anonymous shape.
+        client.cookies.clear()
+        r = client.get("/auth/passcode/check", params={"email": "carol@example.com"})
+        assert r.status_code == 200
+        assert r.json() == {"has_passcode": True}
+        # The response carries ONLY the boolean — no hash, no stamp.
+        assert set(r.json().keys()) == {"has_passcode"}
+
+
+# ---------------------------------------------------------------------------
+# Verify path — happy path
+# ---------------------------------------------------------------------------
+
+
+def test_verify_passcode_signs_in_user(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app) as client:
+        _reset_outbound()
+        _sign_in_via_otc(client, "dave@example.com")
+        client.post("/auth/passcode/set", json={"passcode": "secret123"})
+        client.cookies.clear()
+
+        r = client.post(
+            "/auth/passcode/verify",
+            json={"email": "dave@example.com", "passcode": "secret123"},
+        )
+        assert r.status_code == 200, r.text
+        me = client.get("/api/auth/me").json()
+        assert me["authenticated"] is True
+        assert me["user"]["email"] == "dave@example.com"
+        assert me["user"]["has_passcode"] is True
+
+
+# ---------------------------------------------------------------------------
+# Verify path — failure modes
+# ---------------------------------------------------------------------------
+
+
+def test_verify_passcode_wrong_increments_counter_without_locking(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_via_otc(client, "erin@example.com")
+        client.post("/auth/passcode/set", json={"passcode": "secret123"})
+        client.cookies.clear()
+
+        # Three bad attempts — under the lockout threshold.
+        for _ in range(3):
+            r = client.post(
+                "/auth/passcode/verify",
+                json={"email": "erin@example.com", "passcode": "wrongwrong"},
+            )
+            assert r.status_code == 400
+
+        row = db.conn().execute(
+            "SELECT passcode_failed_attempts, passcode_locked_until FROM users WHERE email = ?",
+            ("erin@example.com",),
+        ).fetchone()
+        assert row["passcode_failed_attempts"] == 3
+        assert row["passcode_locked_until"] is None
+
+
+def test_verify_passcode_locks_after_five_failures(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_via_otc(client, "frank@example.com")
+        client.post("/auth/passcode/set", json={"passcode": "secret123"})
+        client.cookies.clear()
+
+        # Five bad attempts — the last crosses the threshold and the
+        # response shape flips to 423.
+        statuses = []
+        for _ in range(5):
+            r = client.post(
+                "/auth/passcode/verify",
+                json={"email": "frank@example.com", "passcode": "wrongwrong"},
+            )
+            statuses.append(r.status_code)
+        # First four are 400, the fifth (threshold-crossing) is 423.
+        assert statuses == [400, 400, 400, 400, 423]
+
+        row = db.conn().execute(
+            "SELECT passcode_failed_attempts, passcode_locked_until FROM users WHERE email = ?",
+            ("frank@example.com",),
+        ).fetchone()
+        assert row["passcode_failed_attempts"] >= 5
+        assert row["passcode_locked_until"] is not None
+
+        # Sixth attempt — still locked, still 423, even with the correct
+        # passcode (lockout overrides the verify).
+        r = client.post(
+            "/auth/passcode/verify",
+            json={"email": "frank@example.com", "passcode": "secret123"},
+        )
+        assert r.status_code == 423
+
+
+def test_verify_passcode_lockout_expires(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_via_otc(client, "gina@example.com")
+        client.post("/auth/passcode/set", json={"passcode": "secret123"})
+        client.cookies.clear()
+
+        for _ in range(5):
+            client.post(
+                "/auth/passcode/verify",
+                json={"email": "gina@example.com", "passcode": "wrongwrong"},
+            )
+
+        # Backdate the lockout to the past so the next attempt clears it.
+        db.conn().execute(
+            """
+            UPDATE users
+               SET passcode_locked_until = datetime('now', '-1 minute')
+             WHERE email = ?
+            """,
+            ("gina@example.com",),
+        )
+
+        r = client.post(
+            "/auth/passcode/verify",
+            json={"email": "gina@example.com", "passcode": "secret123"},
+        )
+        assert r.status_code == 200, r.text
+
+        # Lockout cleared, counter reset.
+        row = db.conn().execute(
+            "SELECT passcode_failed_attempts, passcode_locked_until FROM users WHERE email = ?",
+            ("gina@example.com",),
+        ).fetchone()
+        assert row["passcode_failed_attempts"] == 0
+        assert row["passcode_locked_until"] is None
+
+
+def test_otc_path_unaffected_by_passcode_lockout(app_with_fake_gitea, monkeypatch):
+    from fastapi.testclient import TestClient
+
+    # Drop the OTC cooldown so the second request lands without a 429.
+    # The cooldown is re-read from env on every `request_code` call so
+    # this takes effect mid-process.
+    monkeypatch.setenv("OTC_REQUEST_COOLDOWN_SECONDS", "0")
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app) as client:
+        _reset_outbound()
+        _sign_in_via_otc(client, "harvey@example.com")
+        client.post("/auth/passcode/set", json={"passcode": "secret123"})
+        client.cookies.clear()
+
+        # Lock the passcode path.
+        for _ in range(5):
+            client.post(
+                "/auth/passcode/verify",
+                json={"email": "harvey@example.com", "passcode": "wrongwrong"},
+            )
+
+        # The OTC path is unaffected by the passcode lockout: the user
+        # can still request and verify a fresh code to sign in.
+        r = client.post("/auth/otc/request", json={"email": "harvey@example.com"})
+        assert r.status_code == 200
+        code = _outbound_otc_codes("harvey@example.com")[-1]
+        r = client.post("/auth/otc/verify", json={"email": "harvey@example.com", "code": code})
+        assert r.status_code == 200
+
+        # The user is now signed in via OTC even though the passcode
+        # path is locked. The /api/auth/me payload reflects this.
+        me = client.get("/api/auth/me").json()
+        assert me["authenticated"] is True
+        assert me["user"]["email"] == "harvey@example.com"
+
+
+# ---------------------------------------------------------------------------
+# Clear + replace
+# ---------------------------------------------------------------------------
+
+
+def test_clear_passcode_wipes_the_hash(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_via_otc(client, "ivy@example.com")
+        client.post("/auth/passcode/set", json={"passcode": "secret123"})
+
+        r = client.delete("/auth/passcode")
+        assert r.status_code == 200
+
+        row = db.conn().execute(
+            "SELECT passcode_hash, passcode_set_at FROM users WHERE email = ?",
+            ("ivy@example.com",),
+        ).fetchone()
+        assert row["passcode_hash"] is None
+        assert row["passcode_set_at"] is None
+
+        # Verify against the cleared passcode refuses (no-passcode shape
+        # collapses to a generic 400).
+        client.cookies.clear()
+        r = client.post(
+            "/auth/passcode/verify",
+            json={"email": "ivy@example.com", "passcode": "secret123"},
+        )
+        assert r.status_code == 400
+
+
+def test_setting_new_passcode_replaces_old(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app) as client:
+        _reset_outbound()
+        _sign_in_via_otc(client, "jane@example.com")
+        client.post("/auth/passcode/set", json={"passcode": "secret123"})
+        # Replace.
+        r = client.post("/auth/passcode/set", json={"passcode": "newsecret9"})
+        assert r.status_code == 200
+
+        client.cookies.clear()
+
+        # Old passcode refuses.
+        r = client.post(
+            "/auth/passcode/verify",
+            json={"email": "jane@example.com", "passcode": "secret123"},
+        )
+        assert r.status_code == 400
+
+        # New passcode signs in.
+        r = client.post(
+            "/auth/passcode/verify",
+            json={"email": "jane@example.com", "passcode": "newsecret9"},
+        )
+        assert r.status_code == 200
+
+
+def test_setting_new_passcode_resets_lockout(app_with_fake_gitea, monkeypatch):
+    from fastapi.testclient import TestClient
+    from app import db
+
+    monkeypatch.setenv("OTC_REQUEST_COOLDOWN_SECONDS", "0")
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app) as client:
+        _reset_outbound()
+        _sign_in_via_otc(client, "kate@example.com")
+        client.post("/auth/passcode/set", json={"passcode": "secret123"})
+
+        # Lock the passcode path with bad attempts (drop session first).
+        client.cookies.clear()
+        for _ in range(5):
+            client.post(
+                "/auth/passcode/verify",
+                json={"email": "kate@example.com", "passcode": "wrongwrong"},
+            )
+
+        row = db.conn().execute(
+            "SELECT passcode_locked_until FROM users WHERE email = ?",
+            ("kate@example.com",),
+        ).fetchone()
+        assert row["passcode_locked_until"] is not None
+
+        # Sign back in via OTC and reset the passcode.
+        r = client.post("/auth/otc/request", json={"email": "kate@example.com"})
+        assert r.status_code == 200
+        code = _outbound_otc_codes("kate@example.com")[-1]
+        r = client.post("/auth/otc/verify", json={"email": "kate@example.com", "code": code})
+        assert r.status_code == 200
+
+        r = client.post("/auth/passcode/set", json={"passcode": "freshcode9"})
+        assert r.status_code == 200
+
+        # Lockout cleared on set.
+        row = db.conn().execute(
+            "SELECT passcode_locked_until, passcode_failed_attempts FROM users WHERE email = ?",
+            ("kate@example.com",),
+        ).fetchone()
+        assert row["passcode_locked_until"] is None
+        assert row["passcode_failed_attempts"] == 0
+
+
+def test_passcode_set_at_updates_on_each_set(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+    from app import db
+    import time
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app) as client:
+        _reset_outbound()
+        _sign_in_via_otc(client, "luke@example.com")
+
+        client.post("/auth/passcode/set", json={"passcode": "secret123"})
+        first_stamp = db.conn().execute(
+            "SELECT passcode_set_at FROM users WHERE email = ?",
+            ("luke@example.com",),
+        ).fetchone()["passcode_set_at"]
+        assert first_stamp is not None
+
+        # SQLite's datetime('now') has second precision; sleep so the
+        # stamp visibly advances on the next set.
+        time.sleep(1.1)
+
+        client.post("/auth/passcode/set", json={"passcode": "newcode99"})
+        second_stamp = db.conn().execute(
+            "SELECT passcode_set_at FROM users WHERE email = ?",
+            ("luke@example.com",),
+        ).fetchone()["passcode_set_at"]
+        assert second_stamp is not None
+        assert second_stamp >= first_stamp
+        # Lexicographic compare on ISO-8601 datetime strings works for
+        # the SQLite shape.
+        assert second_stamp > first_stamp
+
+
+# ---------------------------------------------------------------------------
+# Validation
+# ---------------------------------------------------------------------------
+
+
+def test_set_passcode_refuses_too_short(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app) as client:
+        _reset_outbound()
+        _sign_in_via_otc(client, "mia@example.com")
+        r = client.post("/auth/passcode/set", json={"passcode": "abc"})
+        assert r.status_code == 422
+
+
+def test_set_passcode_refuses_denylist_pattern(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app) as client:
+        _reset_outbound()
+        _sign_in_via_otc(client, "nick@example.com")
+        for bad in ["0000", "1234", "aaaa", "qwerty", "password"]:
+            r = client.post("/auth/passcode/set", json={"passcode": bad})
+            assert r.status_code == 422, f"expected 422 for {bad!r}, got {r.status_code}"
+
+
+# ---------------------------------------------------------------------------
+# Auth me payload
+# ---------------------------------------------------------------------------
+
+
+def test_auth_me_carries_has_passcode_flag(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app) as client:
+        _reset_outbound()
+        _sign_in_via_otc(client, "olga@example.com")
+
+        me = client.get("/api/auth/me").json()
+        assert me["user"]["has_passcode"] is False
+        assert me["user"]["passcode_set_at"] is None
+
+        client.post("/auth/passcode/set", json={"passcode": "secret123"})
+        me = client.get("/api/auth/me").json()
+        assert me["user"]["has_passcode"] is True
+        assert me["user"]["passcode_set_at"] is not None

frontend/package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "rfc-app-frontend",
-  "version": "0.8.0",
+  "version": "0.10.0",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "rfc-app-frontend",
-      "version": "0.8.0",
+      "version": "0.10.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.8.0",
+  "version": "0.10.0",
   "type": "module",
   "scripts": {
     "dev": "vite",

frontend/src/App.css

@@ -410,26 +410,6 @@
   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;
 }
@@ -486,22 +466,6 @@
 .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,15 +87,11 @@ 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. 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.
+  // 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.
   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">
@@ -146,12 +142,11 @@ 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 viewer={viewer} />} />
+          <Route path="/beta-pending" element={<BetaPending />} />
           <Route path="/philosophy" element={<PhilosophyWithSidebar viewer={viewer} />} />
           {/* §14.5 / §14.6: cookie-consent companions to /philosophy.
               Available to anonymous and authenticated viewers alike. */}
@@ -237,26 +232,7 @@ 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,22 +49,49 @@ export async function verifyOtc(email, code) {
   return jsonOrThrow(res)
 }
 
-// ── v0.8.0: open beta-access request flow (§6.1 / §14.1) ─────────────────
+// ── v0.10.0: user-set passcodes after OTC (§6.2, roadmap item #8) ─────────
 //
-// 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.
+// After a successful OTC sign-in, a contributor may set a passcode and
+// use email + passcode for subsequent sign-ins. OTC remains the
+// forgot-passcode fallback — 5 consecutive verify failures locks the
+// passcode path for 15 minutes (HTTP 423); the OTC path is unaffected.
 
-export async function submitBetaRequest({ first_name, last_name, beta_request_reason }) {
-  const res = await fetch('/api/auth/me/beta-request', {
+export async function checkPasscode(email) {
+  // Anonymous endpoint. Returns `{has_passcode: boolean}` so the
+  // Login.jsx flow can decide whether to render a passcode input or
+  // fall back to OTC. We URL-encode the email so addresses with '+'
+  // round-trip cleanly.
+  const params = new URLSearchParams({ email })
+  const res = await fetch(`/auth/passcode/check?${params}`)
+  return jsonOrThrow(res)
+}
+
+export async function verifyPasscode(email, passcode) {
+  const res = await fetch('/auth/passcode/verify', {
     method: 'POST',
     headers: { 'Content-Type': 'application/json' },
-    body: JSON.stringify({ first_name, last_name, beta_request_reason }),
+    body: JSON.stringify({ email, passcode }),
   })
   return jsonOrThrow(res)
 }
 
+export async function setPasscode(passcode) {
+  // Requires an active session — the server returns 401 if not signed
+  // in. The signed-in user is the implicit subject; the body carries
+  // only the new passcode.
+  const res = await fetch('/auth/passcode/set', {
+    method: 'POST',
+    headers: { 'Content-Type': 'application/json' },
+    body: JSON.stringify({ passcode }),
+  })
+  return jsonOrThrow(res)
+}
+
+export async function clearPasscode() {
+  const res = await fetch('/auth/passcode', { method: 'DELETE' })
+  return jsonOrThrow(res)
+}
+
 export async function listRFCs() {
   return jsonOrThrow(await fetch('/api/rfcs'))
 }

frontend/src/components/BetaPending.jsx

@@ -1,59 +1,38 @@
-// BetaPending.jsx — the "your request is in review" page (§6.1 / §14.1).
+// BetaPending.jsx — the post-OAuth-rejection page.
 //
-// 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.
+// 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.
 
 import { Link } from 'react-router-dom'
 
-export default function BetaPending({ viewer }) {
+export default function BetaPending() {
   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>
-          {isPending
-            ? 'Your request is in review.'
-            : `${import.meta.env.VITE_APP_NAME} is in private Beta.`}
-        </h1>
-        {isPending ? (
-          <>
+        <h1>{import.meta.env.VITE_APP_NAME} is in private Beta.</h1>
         <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.
+          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>
-            <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">
-            Questions? Contact <strong>{contact}</strong>.
+            To request access, contact <strong>{contact}</strong> with the
+            email address you'd like to sign in with.
           </p>
         ) : (
           <p className="beta-pending-contact">
-            Questions? Contact the deployment operator.
+            To request access, contact the deployment operator with the email
+            address you'd like to sign in with.
           </p>
         )}
         <div className="beta-pending-actions">
-          <Link className="btn-primary" to="/">Browse the catalog</Link>
+          <Link className="btn-primary" to="/">Browse as a guest</Link>
           <Link className="btn-link-quiet" to="/philosophy">Read the philosophy →</Link>
         </div>
       </div>

frontend/src/components/Login.jsx

@@ -1,57 +1,69 @@
-// 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.
+// Login.jsx — v0.7.0's email + OTC sign-in surface (§6.2), extended
+// in v0.10.0 with passcode sign-in (roadmap item #8).
 //
-// 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, 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.
+// Three-to-five-step flow:
+//   1. Enter email → GET /auth/passcode/check.
+//      * If `has_passcode`: advance to step 'passcode'.
+//      * Otherwise: POST /auth/otc/request, advance to step 'code'.
+//   2a. Step 'passcode': enter passcode → POST /auth/passcode/verify.
+//       * On 200: redirect to /.
+//       * On 423: passcode is locked (5 consecutive failures); the
+//         UI auto-falls back to OTC by requesting a fresh code.
+//       * On 400: wrong passcode; the user can retry or click
+//         "Use a code instead" to fall back to OTC manually.
+//   2b. Step 'code' (the v0.7.0 path): enter the six-digit code →
+//       POST /auth/otc/verify → on 200, the server has signed in the
+//       user. If the user has no passcode set, we show step
+//       'offer-passcode' inviting them to set one for faster sign-in
+//       next time. Dismiss skips to /; "Set passcode" advances to
+//       step 'set-passcode'.
+//   3. Step 'set-passcode': enter a passcode → POST /auth/passcode/set
+//      → redirect to /. The user can also "Skip for now".
 //
-// 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.
+// 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". The
+// check endpoint also returns `has_passcode: false` for an unknown
+// email — so an unknown email always lands in the OTC path, no
+// account-enumeration signal.
 //
 // The legacy Gitea OAuth callback remains at /auth/login → /auth/callback
-// 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.
+// 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.
 
 import { useEffect, useRef, useState } from 'react'
 import { useNavigate, Link } from 'react-router-dom'
-import { requestOtc, verifyOtc, submitBetaRequest } from '../api'
+import {
+  requestOtc,
+  verifyOtc,
+  checkPasscode,
+  verifyPasscode,
+  setPasscode as apiSetPasscode,
+} from '../api'
 
 export default function Login() {
+  // Steps: 'email' → 'passcode' or 'code' → (after OTC verify) optional
+  // 'offer-passcode' → optional 'set-passcode'. The latter two only
+  // appear on the OTC path for accounts that don't yet have a passcode.
   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 [passcode, setPasscode] = useState('')
+  const [newPasscode, setNewPasscode] = useState('')
   const [status, setStatus] = useState('')
   const [busy, setBusy] = useState(false)
   const emailRef = useRef(null)
   const codeRef = useRef(null)
-  const firstNameRef = useRef(null)
+  const passcodeRef = useRef(null)
+  const newPasscodeRef = useRef(null)
   const navigate = useNavigate()
 
   useEffect(() => {
     if (step === 'email') emailRef.current?.focus()
     else if (step === 'code') codeRef.current?.focus()
-    else if (step === 'profile') firstNameRef.current?.focus()
+    else if (step === 'passcode') passcodeRef.current?.focus()
+    else if (step === 'set-passcode') newPasscodeRef.current?.focus()
   }, [step])
 
   async function submitEmail(e) {
@@ -63,20 +75,68 @@ export default function Login() {
     setBusy(true)
     setStatus('')
     try {
+      const { has_passcode } = await checkPasscode(email.trim())
+      if (has_passcode) {
+        setStep('passcode')
+        setStatus('')
+      } else {
         await requestOtc(email.trim())
         setStep('code')
         setStatus('Check your inbox — a six-digit code is on the way.')
+      }
     } catch (err) {
       if (err.status === 429) {
         setStatus('Slow down — wait a minute before requesting another code.')
       } else {
-        setStatus(err.message || 'Could not request a code. Try again.')
+        setStatus(err.message || 'Could not start sign-in. Try again.')
       }
     } finally {
       setBusy(false)
     }
   }
 
+  async function submitPasscode(e) {
+    if (e) e.preventDefault()
+    if (!passcode.trim()) {
+      setStatus('Enter your passcode.')
+      return
+    }
+    setBusy(true)
+    setStatus('')
+    try {
+      await verifyPasscode(email.trim(), passcode.trim())
+      window.location.assign('/')
+    } catch (err) {
+      if (err.status === 423) {
+        // Lockout — auto-fall back to OTC. The OTC request endpoint
+        // is independent of the passcode lockout, so this lands a
+        // fresh code in the user's inbox immediately.
+        setPasscode('')
+        try {
+          await requestOtc(email.trim())
+          setStep('code')
+          setStatus(
+            'Too many failed attempts. We sent a one-time code to your email — use it to sign in.',
+          )
+        } catch (e2) {
+          if (e2.status === 429) {
+            setStep('code')
+            setStatus(
+              'Too many failed attempts. Wait a minute, then request a one-time code to sign in.',
+            )
+          } else {
+            setStatus(
+              'Too many failed attempts. Use the "Use a code instead" link to sign in via email.',
+            )
+          }
+        }
+      } else {
+        setStatus('Wrong passcode. Try again, or use a one-time code instead.')
+      }
+      setBusy(false)
+    }
+  }
+
   async function submitCode(e) {
     if (e) e.preventDefault()
     if (!code.trim() || code.trim().length !== 6) {
@@ -86,53 +146,40 @@ export default function Login() {
     setBusy(true)
     setStatus('')
     try {
-      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.
+      await verifyOtc(email.trim(), code.trim())
+      // OTC verified. If the user has no passcode, offer to set one
+      // before redirecting. We re-read `has_passcode` from the server
+      // rather than caching the step-1 result because the user could
+      // have set a passcode in another tab between then and now.
+      const { has_passcode } = await checkPasscode(email.trim())
+      if (has_passcode) {
         window.location.assign('/')
+      } else {
+        setStep('offer-passcode')
+        setBusy(false)
+      }
     } catch (err) {
       setStatus('That code is invalid or expired. Try again, or request a new code.')
       setBusy(false)
     }
   }
 
-  async function submitProfile(e) {
+  async function submitNewPasscode(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.')
+    const pc = newPasscode.trim()
+    if (pc.length < 4) {
+      setStatus('Passcode must be at least 4 characters.')
       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')
+      await apiSetPasscode(pc)
+      window.location.assign('/')
     } catch (err) {
-      setStatus(err.message || 'Could not submit your request. Try again.')
+      // 422 carries the validation message verbatim (denylist /
+      // length); surface it as-is so the user knows what to change.
+      setStatus(err.message || 'Could not set passcode. Try a different one.')
       setBusy(false)
     }
   }
@@ -144,12 +191,44 @@ export default function Login() {
     }
   }
 
+  function onPasscodeKey(e) {
+    if ((e.metaKey || e.ctrlKey) && e.key === 'Enter') {
+      submitPasscode(e)
+    }
+  }
+
   function backToEmail() {
     setStep('email')
     setCode('')
+    setPasscode('')
     setStatus('')
   }
 
+  async function fallbackToOtc() {
+    // Manual "Use a code instead" from the passcode step. Same shape
+    // as the email-step OTC dispatch.
+    setBusy(true)
+    setStatus('')
+    try {
+      await requestOtc(email.trim())
+      setPasscode('')
+      setStep('code')
+      setStatus('Check your inbox — a six-digit code is on the way.')
+    } catch (err) {
+      if (err.status === 429) {
+        setStatus('Slow down — wait a minute before requesting another code.')
+      } else {
+        setStatus(err.message || 'Could not request a code. Try again.')
+      }
+    } finally {
+      setBusy(false)
+    }
+  }
+
+  function skipPasscodeOffer() {
+    window.location.assign('/')
+  }
+
   return (
     <div className="otc-login">
       <div className="otc-login-inner">
@@ -157,7 +236,8 @@ export default function Login() {
         {step === 'email' && (
           <form onSubmit={submitEmail}>
             <p className="otc-hint">
-              Enter your email. We'll send you a one-time code.
+              Enter your email. If you've set a passcode, you'll enter that
+              next; otherwise we'll send a one-time code.
             </p>
             <input
               ref={emailRef}
@@ -170,10 +250,49 @@ export default function Login() {
               disabled={busy}
             />
             <button type="submit" disabled={busy || !email.trim()}>
-              {busy ? 'Sending…' : 'Send code'}
+              {busy ? 'Checking…' : 'Continue'}
             </button>
           </form>
         )}
+        {step === 'passcode' && (
+          <form onSubmit={submitPasscode}>
+            <p className="otc-hint">
+              Enter the passcode for <strong>{email}</strong>.
+            </p>
+            <input
+              ref={passcodeRef}
+              type="password"
+              autoComplete="current-password"
+              value={passcode}
+              onChange={e => setPasscode(e.target.value)}
+              onKeyDown={onPasscodeKey}
+              placeholder="Your passcode"
+              required
+              disabled={busy}
+            />
+            <div className="otc-actions">
+              <button type="submit" disabled={busy || !passcode.trim()}>
+                {busy ? 'Signing in…' : 'Sign in'}
+              </button>
+              <button
+                type="button"
+                className="btn-link-quiet"
+                onClick={fallbackToOtc}
+                disabled={busy}
+              >
+                Use a code instead
+              </button>
+              <button
+                type="button"
+                className="btn-link-quiet"
+                onClick={backToEmail}
+                disabled={busy}
+              >
+                Use a different email
+              </button>
+            </div>
+          </form>
+        )}
         {step === 'code' && (
           <form onSubmit={submitCode}>
             <p className="otc-hint">
@@ -211,64 +330,69 @@ export default function Login() {
             </p>
           </form>
         )}
-        {step === 'profile' && (
-          <form onSubmit={submitProfile}>
+        {step === 'offer-passcode' && (
+          <div className="otc-offer-passcode">
             <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.
+              You're signed in. Want to set a passcode for faster sign-in
+              next time? You can always use a one-time code instead — and
+              you can change or remove the passcode from your settings.
             </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()}
+                type="button"
+                onClick={() => { setStep('set-passcode'); setStatus('') }}
               >
-                {busy ? 'Submitting…' : 'Submit request'}
+                Set a passcode
+              </button>
+              <button
+                type="button"
+                className="btn-link-quiet"
+                onClick={skipPasscodeOffer}
+              >
+                Skip for now
+              </button>
+            </div>
+          </div>
+        )}
+        {step === 'set-passcode' && (
+          <form onSubmit={submitNewPasscode}>
+            <p className="otc-hint">
+              Pick a passcode (4–20 characters). You'll use it with your
+              email to sign in next time.
+            </p>
+            <input
+              ref={newPasscodeRef}
+              type="password"
+              autoComplete="new-password"
+              value={newPasscode}
+              onChange={e => setNewPasscode(e.target.value)}
+              placeholder="New passcode"
+              required
+              disabled={busy}
+              minLength={4}
+              maxLength={20}
+            />
+            <div className="otc-actions">
+              <button type="submit" disabled={busy || newPasscode.trim().length < 4}>
+                {busy ? 'Saving…' : 'Save passcode'}
+              </button>
+              <button
+                type="button"
+                className="btn-link-quiet"
+                onClick={skipPasscodeOffer}
+                disabled={busy}
+              >
+                Skip for now
               </button>
             </div>
           </form>
         )}
         {status && <p className="otc-status">{status}</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>
   )

frontend/src/components/NotificationSettings.jsx

@@ -29,6 +29,9 @@ import {
   muteUser,
   searchUsers,
   getCookieConsent,
+  getMe,
+  setPasscode,
+  clearPasscode,
 } from '../api.js'
 import { getConsent, onConsentChange, hydrateFromServer } from '../lib/consent.js'
 
@@ -50,11 +53,167 @@ export default function NotificationSettings({ viewer }) {
       <QuietHoursSection />
       <WatchesSection />
       <MutesSection viewer={viewer} />
+      <SignInSection />
       <PrivacyCookiesSection />
     </div>
   )
 }
 
+// ── §6.2 sign-in (v0.10.0 / roadmap item #8): passcode management ──────────
+
+function SignInSection() {
+  // Source of truth for `has_passcode` and `passcode_set_at` is the
+  // /api/auth/me payload (v0.10.0 added both fields). We re-read after
+  // every mutation so the surface reflects what just landed.
+  const [me, setMe] = useState(null)
+  const [error, setError] = useState(null)
+  const [mode, setMode] = useState('idle') // 'idle' | 'set' | 'change'
+  const [draft, setDraft] = useState('')
+  const [busy, setBusy] = useState(false)
+  const [savedNote, setSavedNote] = useState('')
+
+  useEffect(() => {
+    getMe()
+      .then(payload => setMe(payload.user || null))
+      .catch(e => setError(e.message))
+  }, [])
+
+  async function refresh() {
+    const payload = await getMe()
+    setMe(payload.user || null)
+  }
+
+  async function save(e) {
+    if (e) e.preventDefault()
+    const pc = draft.trim()
+    if (pc.length < 4) {
+      setError('Passcode must be at least 4 characters.')
+      return
+    }
+    setBusy(true)
+    setError(null)
+    setSavedNote('')
+    try {
+      await setPasscode(pc)
+      setDraft('')
+      setMode('idle')
+      setSavedNote('Passcode saved.')
+      await refresh()
+    } catch (err) {
+      // 422 carries the validation message verbatim (denylist /
+      // length); surface it as-is so the user knows what to change.
+      setError(err.message || 'Could not save passcode. Try a different one.')
+    } finally {
+      setBusy(false)
+      setTimeout(() => setSavedNote(''), 2000)
+    }
+  }
+
+  async function remove() {
+    if (!confirm('Remove your passcode? You will sign in with a one-time code next time.')) {
+      return
+    }
+    setBusy(true)
+    setError(null)
+    setSavedNote('')
+    try {
+      await clearPasscode()
+      setSavedNote('Passcode removed.')
+      await refresh()
+    } catch (err) {
+      setError(err.message || 'Could not remove passcode.')
+    } finally {
+      setBusy(false)
+      setTimeout(() => setSavedNote(''), 2000)
+    }
+  }
+
+  if (!me) return <SectionShell title="Sign-in" subtitle={error || 'Loading…'} />
+
+  const hasPasscode = !!me.has_passcode
+
+  return (
+    <SectionShell
+      title="Sign-in"
+      subtitle="How you sign in. A passcode lets you skip the one-time-code email; the one-time-code path is always available as a fallback (and as the recovery path if you forget your passcode)."
+    >
+      <div className="settings-row">
+        <span className="settings-note">
+          <strong>Passcode:</strong>{' '}
+          {hasPasscode ? 'Set.' : 'Not set — you sign in with a one-time code each time.'}
+        </span>
+      </div>
+      {hasPasscode && me.passcode_set_at && (
+        <p className="settings-note muted">Set on {me.passcode_set_at}.</p>
+      )}
+
+      {mode === 'idle' && (
+        <div className="settings-row">
+          {hasPasscode ? (
+            <>
+              <button
+                className="btn-primary"
+                onClick={() => { setMode('change'); setDraft(''); setError(null) }}
+                disabled={busy}
+              >
+                Change passcode
+              </button>
+              <button
+                className="btn-link-muted"
+                onClick={remove}
+                disabled={busy}
+              >
+                Remove passcode
+              </button>
+            </>
+          ) : (
+            <button
+              className="btn-primary"
+              onClick={() => { setMode('set'); setDraft(''); setError(null) }}
+              disabled={busy}
+            >
+              Set passcode
+            </button>
+          )}
+        </div>
+      )}
+
+      {(mode === 'set' || mode === 'change') && (
+        <form className="settings-row" onSubmit={save}>
+          <label>
+            {mode === 'change' ? 'New passcode' : 'Passcode'}
+            <input
+              type="password"
+              autoComplete="new-password"
+              value={draft}
+              onChange={e => setDraft(e.target.value)}
+              placeholder="4–20 characters"
+              minLength={4}
+              maxLength={20}
+              required
+              disabled={busy}
+            />
+          </label>
+          <button className="btn-primary" type="submit" disabled={busy || draft.trim().length < 4}>
+            {busy ? 'Saving…' : 'Save'}
+          </button>
+          <button
+            type="button"
+            className="btn-link-muted"
+            onClick={() => { setMode('idle'); setDraft(''); setError(null) }}
+            disabled={busy}
+          >
+            Cancel
+          </button>
+        </form>
+      )}
+
+      {savedNote && <p className="settings-note">{savedNote}</p>}
+      {error && <p className="settings-note warning">{error}</p>}
+    </SectionShell>
+  )
+}
+
 // ── §14.5 cookie / privacy consent (v0.13.0 / roadmap item #11) ────────────
 
 function PrivacyCookiesSection() {