Release 0.11.0: trust device for 30 days

CHANGELOG.md

@@ -197,6 +197,119 @@ consent infrastructure is wired so item #13 (v0.15.0) can read from
   (because their `cookie_consent` row does not yet exist); their
   current sessions remain valid.
 
+## 0.11.0 — 2026-05-28
+
+**Minor — schema migration required; no new env vars.** This release
+ships the "trust this device for 30 days" gesture (roadmap item #9,
+SPEC §6.2). After a successful OTC or passcode sign-in, the user
+can check a single checkbox to mint a server-issued opaque
+device-trust token; the token rides as a long-lived HttpOnly +
+Secure + SameSite=Lax cookie, and the matching row's hash lives in a
+new `device_trust` table. On a subsequent visit, the cookie is
+presented at `POST /auth/device-trust/start` — if a non-expired,
+non-revoked row matches, the session is re-established without
+another OTC / passcode roundtrip. A new `/settings/notifications`
+"Trusted devices" section lists active rows (created-at, last-seen,
+expiry, rough UA label) with per-row "Revoke" and a "Revoke all
+devices" button. The cookie is "essential" per the v0.13.0 cookie-
+consent contract — it is part of authentication, not analytics — and
+is set regardless of the user's analytics / other-cookies choice.
+
+The session model gains a cookie, not a session-store change: the
+existing `rfc_session` cookie still carries the in-flight session
+state; the new `rfc_device_trust` cookie is consulted only by
+`/auth/device-trust/start` to bootstrap a fresh session on a return
+visit. The raw token only ever lives in the outbound `Set-Cookie`
+header and the inbound `Cookie` header; server-side storage is the
+bcrypt hash; constant-time comparison via `bcrypt.checkpw` on the
+candidate walk. The raw token is never logged.
+
+### Added
+
+- **`device_trust` table** (`backend/migrations/017_device_trust.sql`).
+  Per-row id, `user_id` (FK with cascade), `device_token_hash`
+  (bcrypt at rest, unique index documents the no-collision
+  invariant), `created_at`, `expires_at` (`created_at + 30 days`),
+  `user_agent` (verbatim, app-layer-truncated to 1024 chars),
+  `last_seen_at` (refreshed on every successful lookup), `revoked_at`
+  (NULL means active). Secondary index on `(user_id, revoked_at)` so
+  the /settings list query is a covering walk.
+- **`backend/app/device_trust.py`** — sibling of `otc.py` and
+  `passcode.py`. Carries `issue(user_id, user_agent)`,
+  `lookup(raw_token)`, `list_for_user(user_id)`, `revoke(user_id,
+  row_id)`, and `revoke_all(user_id)`. The 30-day window and the
+  cookie name (`rfc_device_trust`) live as module-level constants;
+  env-ifying them is a §19.2 candidate.
+- **`§17` endpoints**
+  - `POST /auth/device-trust/start` — anonymous-reachable. Reads the
+    `rfc_device_trust` cookie; on a hit, signs the user in. On a
+    miss (expired, revoked, or unknown), clears the stale cookie and
+    returns 401.
+  - `GET  /api/auth/me/devices` — list active trusted devices for
+    the signed-in user.
+  - `DELETE /api/auth/me/devices/{id}` — revoke a single row.
+    User-id scope enforced in SQL so a hostile client cannot
+    revoke another user's row by guessing ids.
+  - `DELETE /api/auth/me/devices` — revoke every active row.
+- **OTC and passcode verify bodies** gain an optional
+  `trust_device: bool` field (default false). When true and verify
+  succeeds, the endpoint mints a fresh device-trust row and sets
+  the cookie on the response. Pre-v0.11.0 clients that omit the
+  field continue to behave as before.
+- **Login.jsx** gains a "Trust this device for 30 days" checkbox
+  on both the OTC and passcode verify steps, plus a silent on-mount
+  call to `POST /auth/device-trust/start` so a returning user with
+  a valid cookie skips the email step entirely. A failure is
+  intentionally invisible — the user proceeds to the normal email
+  step.
+- **`/settings/notifications` "Trusted devices" section** — lists
+  active rows with per-row "Revoke" + a "Revoke all devices" button
+  (with a `confirm()` prompt because the gesture is broad). The
+  surface intentionally does not single out the row whose cookie
+  the current request carries so a user can revoke "this device"
+  alongside any other from one place.
+
+### Changed
+
+- **`backend/app/main.py`** — the OTC and passcode verify endpoints
+  now also accept the `trust_device` flag and accept an injected
+  `Response` so they can attach the cookie. Two helpers
+  (`_set_device_trust_cookie`, `_clear_device_trust_cookie`) carry
+  the cookie attribute set in one place so the contract is
+  consistent across endpoints. The `Response` import is added
+  alongside the existing FastAPI re-exports.
+- **`backend/app/api.py`** — imports `device_trust as device_trust_mod`
+  alongside `auth`/`db`; mounts the three `/api/auth/me/devices*`
+  endpoints immediately after `/api/auth/me/beta-request` so the
+  auth-shaped neighborhood stays clustered.
+- **`frontend/src/api.js`** — exports `startDeviceTrust()`,
+  `listMyDevices()`, `revokeMyDevice(id)`, `revokeAllMyDevices()`.
+  `verifyOtc` and `verifyPasscode` accept an optional
+  `{ trustDevice }` argument that rides on the POST body.
+
+### Upgrade steps (from 0.10.0)
+
+- You **MUST** apply schema migration `017_device_trust.sql`. The
+  migration creates a single new table with one secondary index;
+  the framework runs migrations automatically at process start, so
+  no manual step is required beyond restarting the backend so the
+  migration runner picks the file up.
+- You **MUST** rebuild the frontend and restart the backend after
+  upgrading. `frontend/package.json#version` and `VERSION` both
+  move to `0.11.0` and the new `Set-Cookie` shape requires the
+  backend to be on the matching version.
+- You **MUST** serve the deployment over HTTPS. The
+  `rfc_device_trust` cookie is set with `Secure=True` — a
+  cleartext deployment will never receive the cookie back from
+  the browser, so the trust gesture will appear to silently fail.
+  Production OHM deployments already serve over HTTPS; local
+  development against `http://localhost` is unaffected (no cookie
+  is set, the OTC/passcode paths continue to work).
+- You **MAY** announce the new feature to your users. Existing
+  signed-in sessions are unaffected — the device-trust cookie is
+  opt-in on the next sign-in, and a user who never checks the box
+  keeps the v0.10.0 behavior verbatim.
+
 ## 0.10.0 — 2026-05-28
 
 **Minor — schema migration required; new auth path is additive.**
@@ -337,208 +450,6 @@ 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.9.0 — 2026-05-28
-
-**Minor — no schema migration; reuses v0.8.0 columns and existing
-SMTP.** This release ships the admin user-management surface at
-`/admin/users` and the new-beta-request notifications that feed
-it (roadmap item #7, SPEC §6.1 / §15 / §17). The two halves
-compose: admins receive an inbox + email signal the moment a
-pending user submits the v0.8.0 capture form; clicking through
-lands on the page where they Grant or Revoke access.
-
-The page consumes the v0.8.0 schema columns
-(`permission_state`, `first_name`, `last_name`,
-`beta_request_reason`, `permission_decided_by`,
-`permission_decided_at`) without adding new ones — migration
-slot 016 stays reserved for a future release. The single new
-write endpoint, `POST /api/admin/users/<id>/permission`,
-replaces v0.8.0's documented manual `UPDATE users SET
-permission_state='granted'` gesture with an audited UI flip.
-
-Admin notifications ride the existing §15 chokepoint — the
-`new_beta_request` event_kind is added to the enum with
-category `admin-actionable`, fan-out is to every owner / admin
-minus the requester themselves, and the §15.4 email dispatch
-only reaches recipients whose `email_admin_actionable` toggle
-is on (the default for owners + admins). The event is the
-framework's first non-RFC-scoped notification — `rfc_slug` is
-NULL and the email deep-link points `/admin/users` instead of
-`/rfc/<slug>`.
-
-Decision on `/admin/allowlist`: the surface stays as a
-sibling sub-tab, not folded into `/admin/users`. The two have
-different keys (allowlist by email pre-sign-up, user list by
-user_id post-sign-up) and a union row would be confusing
-rather than clarifying. The allowlist's fast-path-bypass role
-from v0.8.0 is unchanged; retiring the table outright is
-deferred to a later session (see §19.2).
-
-### Upgrade steps (from 0.10.0)
-
-1. **MAY** rebuild the frontend. The build is the same shape
-   as v0.10.0; the lockfile pins to `0.9.0` so `npm install`
-   in `frontend/` updates it cleanly. No new env vars on the
-   frontend; the existing `VITE_APP_NAME` requirement carries
-   over.
-2. **MAY** restart the backend. No schema migration runs in
-   this release — every v0.9.0 column is from
-   `014_beta_access.sql` (v0.8.0). Restart only if you want
-   the new endpoints registered in this version's binary.
-3. **SHOULD** verify SMTP can reach the deployment's admin
-   inbox before the first pending user submits the capture
-   form. v0.9.0 reuses the v0.7.0 SMTP configuration
-   (`SMTP_HOST`, `SMTP_PORT`, `SMTP_USER`, `SMTP_PASSWORD`,
-   `SMTP_STARTTLS`, `EMAIL_FROM`, `EMAIL_FROM_NAME`); a
-   misconfigured deployment will still write the inbox row,
-   but the admin won't hear about it through email. No new
-   env var is required — the framework reuses the existing
-   admin-user list (role IN ('owner', 'admin')) as the
-   notification recipients.
-4. **SHOULD** announce the surface to existing admins. Wording
-   suggestion: "There's now a Users tab in /admin where you can
-   Grant or Revoke beta access — and you'll get an email +
-   inbox row when a fresh request lands. The manual SQL gesture
-   from v0.8.0 still works but is no longer the documented
-   path."
-5. **MAY** drain the existing pending queue through the new UI.
-   If your deployment carried pending users through the v0.8.0
-   manual-UPDATE window, the Pending bucket on `/admin/users`
-   surfaces all of them with their captured profile. Granting
-   from the UI stamps `permission_decided_by` /
-   `permission_decided_at`, which any prior manual UPDATE
-   gestures may have left NULL (no harm done — the v0.8.0
-   contract didn't require those stamps).
-
-### Added
-
-- **`POST /api/admin/users/<id>/permission`** — body
-  `{state: 'pending'|'granted'|'revoked'}`. Flips the column,
-  stamps `permission_decided_by` + `permission_decided_at`,
-  and writes a `permission_events` row with event_kind in
-  `{permission_granted, permission_revoked,
-  permission_repended}`. Refuses 422 on self-flip (symmetric
-  to `set_mute` / `set_role` self-action refusals) and 422
-  on invalid state. Returns `{ok, permission_state, changed}`
-  where `changed=false` indicates a no-op (the requested
-  state already matched).
-- **Widened `GET /api/admin/users` response** carrying
-  `permission_state`, `first_name`, `last_name`,
-  `beta_request_reason`, `created_at`,
-  `permission_decided_at`, plus joined
-  `permission_decided_by_login` /
-  `permission_decided_by_display`. Sort order surfaces
-  `pending` rows first (the admin queue), then `granted`,
-  then `revoked`; within a bucket, owners precede admins
-  precede contributors, with recency as the tiebreaker.
-- **`new_beta_request` event_kind** in the §15.1 enum. Fired
-  by `notify.fan_out_new_beta_request` from the first
-  successful `POST /api/auth/me/beta-request` (re-submits
-  from the same pending user don't re-fire — the row's
-  first-time-complete check guards against carpet-bombing).
-  Recipients: every owner + admin minus the requester
-  themselves. Category: `admin-actionable`. Deep-link:
-  `/admin/users`. Actor: the requester per §15.9.
-- **`/admin/users` page enhancements** in `Admin.jsx`. The
-  Users tab gains a state filter chip row (All / Pending /
-  Granted / Revoked with counts), a Grant / Revoke control
-  column, a Permission state badge, and an expandable
-  "why they want access" row beneath each pending user.
-  Sign-up timestamp surfaces in a new column.
-- **`frontend/src/api.js#setUserPermission`** — client for
-  the new endpoint, neighboring `setUserMute` and
-  `setUserRole`.
-- **`/beta-pending` copy update** in `BetaPending.jsx`. The
-  "your request is in review" page now honestly references
-  the admin-email signal v0.9.0 ships and admits the
-  framework does not commit to an SLA — turnaround depends
-  on operator availability, and the deployment operator is
-  the right person to ask if a wait runs long. No
-  deployment-specific text is baked in; per-deployment copy
-  lives in §13 of the deployment's repo, not in the
-  framework.
-- **`backend/tests/test_admin_users_vertical.py`** — 10 new
-  tests covering: a beta-request submission fans
-  notifications to every admin + owner (and not to the
-  requester or to contributors); the requester's profile
-  fields land in the notification payload; re-submitting
-  the capture form does not re-fan; the `admin-actionable`
-  category mapping is wired; the `/api/admin/users`
-  listing carries the v0.8.0 columns with `pending` rows
-  sorted first; the permission-flip endpoint promotes
-  pending → granted with the right audit shape; the
-  endpoint promotes granted → revoked; the endpoint
-  refuses self-flip with 422; the endpoint refuses
-  non-admin callers with 403 and anonymous callers with
-  401; the endpoint refuses invalid states with 422; a
-  state-already-matches flip returns `changed=false`
-  without writing an audit row.
-
-### Changed
-
-- **`backend/app/api.py`** — the `POST /api/auth/me/beta-request`
-  handler now calls `notify.fan_out_new_beta_request` after the
-  capture UPDATE lands, gated on the row not previously having
-  all three profile fields populated (so re-submits don't
-  re-fan).
-- **`backend/app/api_admin.py`** — the `list_users` query joins
-  against `users d ON d.id = u.permission_decided_by` for the
-  deciding-admin handle. The new `set_permission` endpoint
-  lives alongside `set_role` / `set_mute`.
-- **`backend/app/notify.py`** — adds
-  `CATEGORY_ADMIN_ACTIONABLE`, the `fan_out_new_beta_request`
-  helper, and the `new_beta_request` arm in `render_summary`.
-- **`backend/app/email.py`** — the `_EVENT_TO_CATEGORY` map
-  carries `new_beta_request → admin-actionable`, and
-  `_deep_link` routes framework-scoped admin signals to
-  `/admin/users` instead of `/rfc/<slug>`.
-- **`frontend/src/components/Admin.jsx`** — the `UsersTab`
-  component is rewritten with state filter chips, a per-row
-  `UserRow` + `PermissionCell` decomposition, and a
-  `useMemo`-cached counts table. The pending-row reason
-  blockquote renders as a secondary `<tr>` beneath the user
-  row when present.
-- **`frontend/src/components/BetaPending.jsx`** — pending-state
-  copy revised to reference the admin email signal honestly.
-- **`frontend/src/App.css`** — new admin-chip / permission-badge
-  / user-row-reason rules.
-- **`SPEC.md`** §6 opening, §15.1 event-kinds enum, §17 admin
-  endpoints, §19.2 candidates list — per §19.3 rule-2.
-- **`VERSION`** → `0.9.0`. `frontend/package.json#version` and
-  the lockfile mirror.
-
-### Environment variables
-
-None new. The release reuses the v0.7.0 SMTP configuration
-(`SMTP_HOST`, `SMTP_PORT`, `SMTP_USER`, `SMTP_PASSWORD`,
-`SMTP_STARTTLS`, `EMAIL_FROM`, `EMAIL_FROM_NAME`,
-`EMAIL_ENABLED`, `EMAIL_BUNDLE_THRESHOLD`) and the existing
-admin-user list (role IN ('owner', 'admin')) as the
-notification recipients. A deployment whose SMTP is misconfigured
-will still see the inbox rows; only the email channel is muted.
-
-### Deferred to later releases
-
-- **Grant / revoke notification to the user** — symmetric
-  signal: when an admin grants or revokes access, fire a
-  `personal-direct` notification (event_kind
-  `permission_change_affecting_me`, already in the §15.1
-  enum) so the affected user sees the state change in
-  their inbox and email. v0.9.0 audits the gesture in
-  `permission_events` but does not yet escape the
-  app-internal log to the user. See §19.2.
-- **Decline-with-reason on revoke** — the current Revoke
-  gesture takes only a confirmation; a follow-up release
-  may capture a free-text reason in
-  `permission_events.details`. See §19.2.
-- **Allowlist deprecation** — the `/admin/allowlist` sub-tab
-  stays in place in v0.9.0 (the two surfaces have different
-  keys and a union row would be confusing). Retiring the
-  table outright is deferred to a session that can re-read
-  the post-v0.9.0 operator experience and decide whether
-  the fast-path-bypass role is still pulling weight. See
-  §19.2.
-
 ## 0.8.0 — 2026-05-28
 
 **Minor — schema migration required; admission semantics shift.**

SPEC.md

@@ -339,6 +339,16 @@ and exact columns are illustrative; the implementing session can adjust.
   on first write and updated on every change. Absence of a row means
   "no choice yet" — the banner shows. Anonymous viewers persist their
   choice in `localStorage` only, with no corresponding row here.
+- `device_trust` — per-row record of the §6.2 device-trust gesture
+  (v0.11.0, roadmap item #9). One row per `(user, trusted device)`
+  pair; a user with three trusted devices has three rows. Columns:
+  `id`, `user_id` (FK users, ON DELETE CASCADE), `device_token_hash`
+  (bcrypt at rest, with a unique index documenting the no-collision
+  invariant of the 256-bit CSPRNG token space), `created_at`,
+  `expires_at` (`created_at + 30 days`), `user_agent` (verbatim,
+  application-layer-truncated to 1024 chars), `last_seen_at`
+  (refreshed on every successful lookup), `revoked_at` (NULL means
+  active). The raw token never lives in this table — only the hash.
 
 **Super-draft scoping.** For rows in `threads` and `changes` where the
 entry referenced by `rfc_slug` is in state `super-draft`, `branch_name`
@@ -374,7 +384,24 @@ them:
    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
+3. **Device trust (cookie-only, 30 days).** Added in v0.11.0
+   (roadmap item #9). After a successful OTC or passcode sign-in,
+   the visitor may check "trust this device for 30 days." The
+   framework then mints a server-issued opaque token, hashes it
+   (bcrypt) into the `device_trust` table, and sets a long-lived
+   HttpOnly + Secure + SameSite=Lax cookie carrying the raw token.
+   On a subsequent visit, `POST /auth/device-trust/start` resolves
+   the cookie and re-establishes the session without an OTC /
+   passcode roundtrip. The user can list and revoke their trusted
+   devices from the `/settings/notifications` "Trusted devices"
+   section; a revoked or expired cookie is cleared on the next
+   request. The cookie is "essential" per §14.5 — it is part of
+   authentication, not analytics, and is set regardless of the
+   user's analytics / other-cookies choice. The raw token only
+   ever lives in the outbound `Set-Cookie` header and the inbound
+   `Cookie` header; server-side storage is the hash, with
+   constant-time comparison on lookup.
+4. **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
@@ -398,23 +425,9 @@ 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
-(roadmap item #7) shipped the user-management surface that
-consumes the `permission_state` column: `/admin/users` carries
-every user with their state, profile, and sign-up reason, plus
-Grant / Revoke controls that flip the column and write a
-`permission_events` audit row. The capture-form submission also
-fans a `new_beta_request` notification out to every admin/owner
-through the §15 substrate, so the queue surfaces in the inbox +
-email channels admins already have.
-
-The `/admin/allowlist` sub-tab stays in place alongside
-`/admin/users` rather than merging: the two surfaces have
-different keys (allowlist by email pre-sign-up, user list by
-user_id post-sign-up) and a union row would be confusing rather
-than clarifying. The allowlist's role narrowed to "fast-path
-bypass for known-good emails" with the v0.8.0 admission shift;
-v0.9.0 retains that role unchanged.
+it — but the OTC request path no longer consults it. v0.9.0's
+admin user-management page replaces the allowlist UI and ships the
+pending-queue triage surface.
 
 ### 6.1 Four roles, each a strict superset of the one below
 
@@ -2300,14 +2313,8 @@ signal taxonomy this section commits to. The starting set:
 `graduation_complete`, `graduation_rolled_back`, `rfc_withdrawn`,
 `rfc_reopened`, `claim_opened`, `claim_merged`,
 `permission_change_affecting_me`, `app_wide_mute_set`,
-`app_wide_mute_lifted`, `new_beta_request`, `digest_emitted`.
-The enum is extensible; the build session adjusts as new gestures
-are wired in. The `new_beta_request` event (v0.9.0, roadmap item
-#7) is framework-scoped rather than RFC-scoped — the row's
-`rfc_slug` is NULL and the deep-link points `/admin/users`
-instead of `/rfc/<slug>` — but otherwise rides the standard
-fan-out chokepoint with category `admin-actionable` so the §15.4
-email gate only reaches owners/admins.
+`app_wide_mute_lifted`, `digest_emitted`. The enum is extensible; the
+build session adjusts as new gestures are wired in.
 
 ### 15.2 The inbox
 
@@ -2823,6 +2830,28 @@ The follow-up session will refine this. A minimal starting set:
   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.
+- `POST /auth/device-trust/start` — unauthenticated. Reads the
+  `rfc_device_trust` cookie (set previously by an OTC or passcode
+  verify with `trust_device: true`). On a non-expired, non-revoked
+  match, re-establishes the session and returns HTTP 200 with the
+  minimal user payload. On a miss (no cookie, expired, revoked, or
+  unknown), returns HTTP 401 and clears the stale cookie via the
+  response's `Set-Cookie` header. The failure modes collapse to
+  one shape so a probing client cannot enumerate "your row was
+  revoked" vs. "this token never existed". v0.11.0.
+- `GET /api/auth/me/devices` — authenticated. Returns the active
+  (`revoked_at IS NULL` AND `expires_at > now`) device-trust rows
+  for the signed-in user: `id`, `created_at`, `expires_at`,
+  `last_seen_at`, `user_agent`. The bcrypt hash is structurally
+  private and is never surfaced. v0.11.0.
+- `DELETE /api/auth/me/devices/{id}` — authenticated. Stamps
+  `revoked_at` on the row with id `{id}` belonging to the
+  signed-in user. The user-id scope is enforced in SQL so a
+  hostile client cannot revoke another user's row by guessing
+  ids; a row that does not match returns HTTP 404. v0.11.0.
+- `DELETE /api/auth/me/devices` — authenticated. Revokes every
+  active row for the signed-in user; returns the count revoked.
+  v0.11.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.
@@ -2965,15 +2994,8 @@ The follow-up session will refine this. A minimal starting set:
 - `POST /api/rfcs/<slug>/prs/<pr_number>/withdraw` — withdraw per §10.8.
 - `POST /api/rfcs/<slug>/prs/<pr_number>/resolution-branch` — cut a
   fresh resolution branch and replay per §10.9.
-- `GET  /api/admin/users` — list users for the §6 / Slice 7 admin
-  surface. v0.9.0 (roadmap item #7) widened the payload to carry
-  `permission_state`, `first_name`, `last_name`, `beta_request_reason`,
-  `created_at`, `permission_decided_at`, and the joined
-  `permission_decided_by_login` / `permission_decided_by_display`
-  for the user-management page. Sort order surfaces `pending` rows
-  first (the daily admin queue), then `granted`, then `revoked`;
-  within a bucket, owners precede admins precede contributors,
-  with recency as the tiebreaker.
+- `GET  /api/admin/users` — list users with role and write-mute state,
+  for the §6 / Slice 7 admin surface.
 - `POST /api/admin/users/<id>/role` — set role. Only owners may grant
   or revoke `owner`; admins may flip contributor ↔ admin freely. An
   owner-self-demotion is refused on this endpoint; owner succession
@@ -2982,16 +3004,6 @@ The follow-up session will refine this. A minimal starting set:
   write-mute (not the §15.8 notification mutes). Refused on owners
   and admins — for them, the role-change channel is the right
   refusal. Writes a `permission_events` row.
-- `POST /api/admin/users/<id>/permission` — v0.9.0 (roadmap item #7).
-  Flip `permission_state` between `pending`, `granted`, and `revoked`.
-  Stamps `permission_decided_by` + `permission_decided_at` on the
-  row and writes a `permission_events` row with event_kind in
-  `{permission_granted, permission_revoked, permission_repended}`.
-  Refuses with 422 if the admin tries to flip their own row
-  (symmetric to the `set_mute` / `set_role` self-action refusals).
-  v0.8.0 shipped the column shape with no admin UI — operators ran
-  a manual `UPDATE users` to grant access; v0.9.0 retires the
-  manual gesture.
 - `GET  /api/admin/audit` — paged read of the `actions` log with
   filters `action_kind`, `actor_user_id`, `rfc_slug`, plus `before_id`
   for the page boundary. Returns the joined actor login/display so
@@ -3831,64 +3843,56 @@ on every other page until an admin grants. v0.8.0 (roadmap item
 Candidates surfaced during v0.8.0 (open beta-access request flow,
 §6.1 / §14.1, item #6):
 
-- **Admin user-management page** (`/admin/users`). *Shipped in
-  v0.9.0 (roadmap item #7).* The listing surfaces every user with
-  permission_state, profile fields, sign-up reason, and a Grant /
-  Revoke control set; the `POST /api/admin/users/<id>/permission`
-  endpoint flips the column and writes a `permission_events` row.
-  v0.9.0 left the `/admin/allowlist` sub-tab in place rather than
-  merging (see allowlist deprecation below). The grant/revoke
-  notify-the-user surface is deferred (see the new candidate
-  below).
-- **Allowlist deprecation.** *Decision deferred past v0.9.0.*
-  v0.9.0 considered merging `/admin/allowlist` into the new
-  `/admin/users` page but kept the surface as a sibling sub-tab:
-  the two have different keys (allowlist by email pre-sign-up,
-  user list by user_id post-sign-up) and a union row would be
-  confusing rather than clarifying. The fast-path-bypass role
-  the allowlist has carried since v0.8.0 stays intact; the
-  cutover to retire the table outright is a later session.
-  Decision points unchanged from v0.8.0: 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
-  once the v0.9.0 admin queue has run long enough to confirm the
-  allowlist's bypass role is no longer pulling weight.
-- **Admin notification on new beta request.** *Shipped in v0.9.0
-  (roadmap item #7).* The `POST /api/auth/me/beta-request`
-  handler now calls `notify.fan_out_new_beta_request`, which
-  fans a `new_beta_request` event (category `admin-actionable`,
-  rfc_slug NULL) out to every owner / admin. The §15 chokepoint
-  handles the SSE broadcast and the §15.4 email dispatch; the
-  email reaches only recipients whose `email_admin_actionable`
-  toggle is on (the default for owners + admins).
-- **Grant / revoke notification to the user.** *Surfaced by
-  v0.9.0.* The new flip endpoint stamps `permission_decided_by` +
-  writes a `permission_events` row but does not yet signal the
-  affected user that their state changed. A future release could
-  fire a `personal-direct` notification (event_kind
-  `permission_change_affecting_me`, already in the §15.1 enum) so
-  a granted user sees "Your beta-access request was approved" in
-  their inbox and email, and a revoked user sees a parallel
-  refusal notice. Decision points: does revocation include a
-  reason field (probably yes — symmetric with §9.3's decline
-  comment); does grant carry a welcome message (probably no —
-  the existing welcome surfaces are sufficient); does the
-  notification escape the §15.8 mute path (probably yes — it's
-  a personal-direct admission state change). Earns its session
-  as a follow-up to the v0.9.0 page.
-- **Decline-with-reason on permission revoke.** *Surfaced by
-  v0.9.0.* The current Revoke gesture takes only a confirmation;
-  there is no audit-visible reason captured. A future release
-  could add a free-text reason input that lands in the
-  `permission_events.details` JSON column (no schema change
-  needed — the column is already JSON-shaped). This is the
-  symmetric companion to the §9.3 proposal-decline contract.
-  Earns its session alongside the grant/revoke notification
-  candidate above.
+- **Admin user-management page** (`/admin/users`). *Surfaced by
+  v0.8.0 — the release ships the pending-state column but no
+  admin UI to triage it.* For v0.8.0, the admin gesture is an
+  out-of-band `UPDATE users SET permission_state='granted' WHERE
+  email=?`. v0.9.0 (roadmap item #7) is expected to ship the
+  triage queue: a list of `permission_state='pending'` rows
+  sorted by `created_at`, each showing the captured first /
+  last / why fields, with Grant and Revoke buttons that stamp
+  `permission_decided_by` and `permission_decided_at` (schema
+  slots already in place per `migrations/014_beta_access.sql`).
+  The page composes naturally with the existing `/admin/allowlist`
+  surface — both are admission-control gestures — so v0.9.0 may
+  fold the allowlist UI into this page (see next candidate).
+  Decision points: do grants / revokes also fire email
+  notifications to the user (probably yes — the notifications
+  layer from v0.6.0 has the personal-direct channel for it); is
+  there a "decline with reason" gesture that surfaces in the
+  user's view (probably yes — symmetric with §9.3's
+  proposal-decline shape); does the page support bulk grants
+  (probably no for v0.9.0 — the queue volume is operator-scale,
+  not user-scale). Earns its session as the v0.9.0 design pass.
+- **Allowlist deprecation.** *Surfaced by v0.8.0 — the
+  `allowed_emails` table stays in the schema but the OTC
+  request path no longer consults it.* v0.8.0 left the table
+  and the `/admin/allowlist` UI in place as a fast-path bypass
+  for deployments that want to pre-mark known-good emails (the
+  v0.8.0 contract is that those emails still go through the
+  pending-grant flow; the table itself is no longer a gate). A
+  future release retires both — probably v0.9.0 alongside the
+  admin user-management page, since the two surfaces are
+  functionally redundant once the pending queue lands.
+  Decision points: drop the table outright (a schema migration)
+  or leave it as a non-functional surface and remove only the
+  UI (a frontend-only change); how to handle existing
+  `allowed_emails` rows at the cutover (probably: walk them
+  into the pending queue with `permission_state='granted'` for
+  any matching `users` row, leave unmatched rows as a no-op
+  since v0.8.0 doesn't consult them anymore). Earns its
+  session as a sub-topic of the v0.9.0 admin user-management
+  pass.
+- **Admin notification on new beta request.** *Surfaced by
+  v0.8.0 — the capture endpoint writes to the row but does
+  not signal admins.* v0.9.0 candidate (item #7 again): when a
+  `POST /api/auth/me/beta-request` lands, fire an `admin-actionable`
+  notification (per §15.4's category set) to every owner / admin
+  so the queue doesn't go stale. The §15 infrastructure already
+  supports the category; the open question is whether the
+  notification is per-request (one email per submission) or
+  digested (a daily summary). Earns its session alongside the
+  admin user-management page.
 - **Removing the Gitea OAuth fallback.** *Surfaced by v0.7.0.*
   v0.7.0 keeps `/auth/callback` functional and links to it as a
   "Sign in with Gitea (fallback)" affordance on the new `/login`
@@ -3903,19 +3907,51 @@ Candidates surfaced during v0.8.0 (open beta-access request flow,
   message), and whether the `/auth/login` and `/auth/callback`
   routes get a tombstone redirect to `/login` or just 404. Earns
   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 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.
+- **Device trust (30-day skip).** *Settled in v0.11.0 (roadmap
+  item #9). The shape: a distinct `rfc_device_trust` cookie
+  (HttpOnly + Secure + SameSite=Lax + 30-day Max-Age) carrying a
+  server-issued opaque token, keyed against a `device_trust` table
+  whose rows store the bcrypt hash. `POST /auth/device-trust/start`
+  resolves a presented cookie at next visit. A
+  `/settings/notifications` "Trusted devices" section lists active
+  rows with per-row + bulk revoke. The trust outlives a sign-out
+  (sign-out clears the session cookie, not the device-trust
+  cookie) and is not affected by passcode set/change/clear — the
+  next two items below carry the remaining open questions.*
+- **Cross-device session revocation surface.** v0.11.0's
+  `/settings/notifications → Trusted devices` revokes the
+  long-lived device-trust grants. What it does NOT revoke is an
+  active session cookie sitting in another browser, or the
+  v0.10.0 passcode-failure-counter shape, or a stale
+  password-equivalent that some future release ships. The natural
+  next step is a single "active sessions and devices" surface
+  that lists everything currently authenticating as this user —
+  device-trust rows + active session cookies (if/when the
+  framework moves to server-side sessions) + future credential
+  shapes — and lets the user kill any of them with one gesture.
+  Earns its session when a second cross-cutting concern lands
+  (the most likely first trigger: future Yubikey / WebAuthn
+  support, which surfaces another credential to revoke).
+- **Password-equivalent change invalidates device trust.** v0.11.0
+  intentionally leaves device-trust rows live across a passcode
+  set / change / clear. The argument is structural: the user has
+  the v0.10.0 lockout, the v0.11.0 per-device revoke list, and a
+  fresh sign-in path via OTC, so the cookie is not a high-value
+  bypass relative to the keys-to-the-account a passcode change
+  signals. The argument against is the conventional "changing a
+  password should kill every active session" expectation users
+  bring from other systems. This earns its own session once the
+  evidence is in: either a security-review finding that says
+  "this is the wrong default," or user feedback that says "I
+  expected my old laptop to sign out when I changed my passcode."
+- **Device-trust window tunables via env.** v0.11.0 hard-codes
+  the 30-day window in `backend/app/device_trust.py`
+  (`TRUST_DURATION_DAYS = 30`). Surfacing it as an env var
+  (`DEVICE_TRUST_DURATION_DAYS`?) is small and obvious; deferring
+  follows the same pattern as the v0.10.0 passcode-lockout
+  hard-coding — name the tunable when a deployment wants it
+  different rather than shipping a knob that has no operator
+  asking for it.
 - **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

VERSION

@@ -1 +1 @@
-0.9.0
+0.11.0

backend/app/api.py

@@ -26,12 +26,12 @@ from . import (
     api_prs,
     auth,
     db,
+    device_trust as device_trust_mod,
     docs as docs_mod,
     entry as entry_mod,
     cache,
     funder,
     health,
-    notify,
     philosophy,
     providers as providers_mod,
 )
@@ -238,20 +238,70 @@ def make_router(
                 user.user_id,
             ),
         )
-        # v0.9.0 (roadmap item #7): notify every admin/owner of the
-        # fresh request. Only the first submission is the
-        # "newly-pending" gesture — re-submits from the same user
-        # would otherwise carpet the admin inbox. We fire only when
-        # this is the row's first time getting all three fields
-        # populated (the prior row carried at least one NULL).
-        prior = row  # captured before the UPDATE above
-        was_already_complete = bool(
-            prior["first_name"] and prior["last_name"] and prior["beta_request_reason"]
-        )
-        if not was_already_complete:
-            notify.fan_out_new_beta_request(requester_user_id=user.user_id)
         return {"ok": True}
 
+    # ---------------------------------------------------------------
+    # v0.11.0: trust device for 30 days (§6.2, roadmap item #9).
+    #
+    # The mint path lives on the OAuth router (issuing the cookie is
+    # coupled to OTC/passcode verify). This module owns the read/revoke
+    # surface the /settings/devices page calls.
+    # ---------------------------------------------------------------
+
+    @router.get("/api/auth/me/devices")
+    async def list_my_devices(request: Request) -> dict[str, Any]:
+        """Active device-trust rows for the signed-in user.
+
+        Active = not revoked, not expired. The current request's
+        device (if any) is *not* singled out here — the surface
+        shows the same row shape for every device so the user can
+        revoke any of them without the page leaking which row
+        carries the cookie they're using right now.
+        """
+        user = auth.require_user(request)
+        rows = device_trust_mod.list_for_user(user.user_id)
+        return {
+            "items": [
+                {
+                    "id": r.id,
+                    "created_at": r.created_at,
+                    "expires_at": r.expires_at,
+                    "last_seen_at": r.last_seen_at,
+                    "user_agent": r.user_agent,
+                }
+                for r in rows
+            ]
+        }
+
+    @router.delete("/api/auth/me/devices/{device_id}")
+    async def revoke_my_device(device_id: int, request: Request) -> dict[str, Any]:
+        """Revoke a single device-trust row for the signed-in user.
+
+        The user-id scope is enforced in SQL so a hostile client
+        cannot revoke another user's row by guessing ids. A row that
+        doesn't exist, doesn't belong to this user, or is already
+        revoked reads as 404 — the wrong-vs-already-revoked
+        distinction would only help a probing client enumerate ids.
+        """
+        user = auth.require_user(request)
+        ok = device_trust_mod.revoke(user.user_id, device_id)
+        if not ok:
+            raise HTTPException(404, "Device not found")
+        return {"ok": True}
+
+    @router.delete("/api/auth/me/devices")
+    async def revoke_all_my_devices(request: Request) -> dict[str, Any]:
+        """Revoke every active device-trust row for the signed-in user.
+
+        The user's current request stays authenticated via its
+        session cookie; the device-trust cookie carried on the
+        current device is also revoked, but `rfc_session` keeps the
+        request flow alive until sign-out / expiry.
+        """
+        user = auth.require_user(request)
+        count = device_trust_mod.revoke_all(user.user_id)
+        return {"ok": True, "revoked": count}
+
     # ---------------------------------------------------------------
     # §7: the catalog
     # ---------------------------------------------------------------

backend/app/api_admin.py

@@ -50,16 +50,6 @@ class MuteBody(BaseModel):
     muted: bool
 
 
-class PermissionStateBody(BaseModel):
-    # v0.9.0: the admin flip from the user-management page (roadmap
-    # item #7). `pending` is not surfaceable from the admin UI —
-    # only the OTC verify path lands a row in `pending` — but we
-    # accept it in the pattern in case a future restore-to-queue
-    # gesture wants to re-pend a granted user; today the UI only
-    # exposes `granted` and `revoked`.
-    state: str = Field(pattern="^(pending|granted|revoked)$")
-
-
 class AllowlistAddBody(BaseModel):
     email: str = Field(min_length=3, max_length=320)
     note: str | None = Field(default=None, max_length=200)
@@ -78,41 +68,13 @@ def make_router(config: Config) -> APIRouter:
 
     @router.get("/api/admin/users")
     async def list_users(request: Request) -> dict[str, Any]:
-        """v0.9.0: the user-management surface (roadmap item #7).
-
-        The listing carries every column the admin queue needs to triage
-        pending beta-access requests alongside the existing role/mute
-        affordances. Sort order surfaces pending requests first (so the
-        admin lands on the inbox shape), then granted, then revoked;
-        within a state, ownership/role and recency are the tiebreakers
-        so the legacy ordering (owner first, then admin, then by name)
-        is preserved inside the granted bucket.
-
-        `permission_decided_by_login` joins the deciding admin row so
-        the UI can render "granted by @ben" without a second round-trip.
-        """
         auth.require_admin(request)
         rows = db.conn().execute(
             """
-            SELECT u.id, u.gitea_login, u.display_name, u.email, u.role, u.muted,
-                   u.created_at, u.last_seen_at,
-                   u.permission_state, u.first_name, u.last_name,
-                   u.beta_request_reason,
-                   u.permission_decided_by, u.permission_decided_at,
-                   d.gitea_login AS decided_by_login,
-                   d.display_name AS decided_by_display
-              FROM users u
-         LEFT JOIN users d ON d.id = u.permission_decided_by
-             ORDER BY
-                CASE u.permission_state
-                  WHEN 'pending' THEN 0
-                  WHEN 'granted' THEN 1
-                  WHEN 'revoked' THEN 2
-                  ELSE 3
-                END,
-                u.role = 'owner' DESC, u.role = 'admin' DESC,
-                COALESCE(u.last_seen_at, u.created_at) DESC,
-                u.display_name COLLATE NOCASE
+            SELECT id, gitea_login, display_name, email, role, muted,
+                   created_at, last_seen_at
+              FROM users
+             ORDER BY role = 'owner' DESC, role = 'admin' DESC, display_name COLLATE NOCASE
             """
         ).fetchall()
         return {
@@ -126,13 +88,6 @@ def make_router(config: Config) -> APIRouter:
                     "muted": bool(r["muted"]),
                     "created_at": r["created_at"],
                     "last_seen_at": r["last_seen_at"],
-                    "permission_state": r["permission_state"] or "granted",
-                    "first_name": r["first_name"] or "",
-                    "last_name": r["last_name"] or "",
-                    "beta_request_reason": r["beta_request_reason"] or "",
-                    "permission_decided_at": r["permission_decided_at"],
-                    "permission_decided_by_login": r["decided_by_login"],
-                    "permission_decided_by_display": r["decided_by_display"],
                 }
                 for r in rows
             ]
@@ -181,74 +136,6 @@ def make_router(config: Config) -> APIRouter:
         )
         return {"ok": True, "role": body.role, "changed": True}
 
-    # ----- Permission state (§6.1, v0.9.0 roadmap item #7) -----
-
-    @router.post("/api/admin/users/{user_id}/permission")
-    async def set_permission(user_id: int, body: PermissionStateBody, request: Request) -> dict[str, Any]:
-        """Flip a user's `permission_state` between pending/granted/revoked.
-
-        v0.8.0 wired the column shape but shipped no admin UI for it —
-        the grant gesture was a manual `UPDATE users` against the DB.
-        v0.9.0 (roadmap item #7) lands the admin user-management page;
-        this endpoint is its single write surface.
-
-        Audit shape: every flip writes a `permission_events` row with
-        event_kind in {'permission_granted', 'permission_revoked',
-        'permission_repended'} so §6.5's log carries the change. The
-        `permission_decided_by` / `permission_decided_at` columns on
-        the user row are co-stamped so the user listing can render
-        "granted by @ben at <date>" without a second join through
-        the audit table.
-
-        Refuses with 422 if the admin tries to flip their own row
-        (no self-grant / self-revoke; symmetric to set_mute's
-        self-mute refusal and set_role's self-downgrade refusal).
-        """
-        viewer = auth.require_admin(request)
-        target = db.conn().execute(
-            "SELECT id, role, permission_state FROM users WHERE id = ?",
-            (user_id,),
-        ).fetchone()
-        if target is None:
-            raise HTTPException(404, "User not found")
-        if target["id"] == viewer.user_id:
-            raise HTTPException(422, "You cannot change your own permission state")
-
-        before = target["permission_state"] or "granted"
-        after = body.state
-        if before == after:
-            return {"ok": True, "permission_state": after, "changed": False}
-
-        db.conn().execute(
-            """
-            UPDATE users
-               SET permission_state = ?,
-                   permission_decided_by = ?,
-                   permission_decided_at = datetime('now')
-             WHERE id = ?
-            """,
-            (after, viewer.user_id, user_id),
-        )
-        event_kind = {
-            "granted": "permission_granted",
-            "revoked": "permission_revoked",
-            "pending": "permission_repended",
-        }[after]
-        db.conn().execute(
-            """
-            INSERT INTO permission_events
-                (actor_user_id, subject_user_id, event_kind, details)
-            VALUES (?, ?, ?, ?)
-            """,
-            (
-                viewer.user_id,
-                user_id,
-                event_kind,
-                json.dumps({"before": before, "after": after}),
-            ),
-        )
-        return {"ok": True, "permission_state": after, "changed": True}
-
     # ----- Write-mute (§6.2) -----
 
     @router.post("/api/admin/users/{user_id}/mute")

backend/app/device_trust.py

@@ -0,0 +1,351 @@
+"""§6.2 / v0.11.0: trust device for 30 days (roadmap item #9).
+
+After a successful OTC or passcode sign-in, a contributor may check
+"trust this device for 30 days." The framework then issues a
+server-issued opaque token, hashes it (bcrypt) for storage in the
+`device_trust` table, and sets a long-lived cookie carrying the raw
+token. On a subsequent visit, the cookie is presented at
+`/auth/device-trust/start`; if a non-expired, non-revoked row matches,
+the session is re-established without another OTC / passcode round
+trip.
+
+The shape:
+
+  * `issue(user_id, user_agent)` — mint a fresh CSPRNG token, hash it,
+    insert a row, and return the raw token + row id so the endpoint
+    can set the cookie. The 30-day expiry is the only knob; the
+    `revoked_at` column stays NULL.
+  * `lookup(raw_token)` — walk the user's active rows (the unique
+    index keys on the hash, so we read a small candidate set), check
+    the bcrypt hash in constant time, drop any row whose `expires_at`
+    has passed or whose `revoked_at` is non-NULL, and return the
+    matched row or None. On a hit, refresh `last_seen_at`.
+  * `list_for_user(user_id)` — return the active rows for the
+    /settings/devices surface. Revoked + expired rows are filtered out
+    so the surface only shows live trust grants.
+  * `revoke(user_id, row_id)` — stamp `revoked_at` on the row. The
+    next lookup refuses the cookie token (the row is dead).
+  * `revoke_all(user_id)` — bulk-revoke every active row for the user.
+    The /settings/devices surface's "revoke all" button calls this.
+
+Cookie shape: `rfc_device_trust`. HttpOnly, Secure, SameSite=Lax,
+Max-Age=2592000 (30 days), Path=/. The cookie value is the raw token;
+server-side storage is the hash. The cookie is "essential" per the
+v0.13.0 cookie-consent banner (it is part of authentication, not
+analytics), so the framework sets it regardless of analytics /
+other-cookies choices.
+
+Constant-time comparison: bcrypt's `checkpw` is already constant-time
+over the hash bytes. We walk the candidate set linearly with `_check`
+which delegates to `bcrypt.checkpw`; no early-exit shortcut leaks
+which row was the match.
+
+The raw token never appears in a log line or an exception message;
+the helpers carry the token only as a parameter and forget it after
+hashing.
+
+The cookie sits orthogonal to the §6.1 `permission_state` gate: a
+revoked or pending user with a valid device-trust cookie still
+re-establishes their session (the cookie identifies the user, not
+their admission state), and the existing `require_contributor` /
+`require_admin` dependencies in `auth.py` continue to refuse the
+unrelated write surfaces.
+"""
+from __future__ import annotations
+
+import logging
+import secrets
+from dataclasses import dataclass
+
+import bcrypt
+
+from . import db
+from .auth import SessionUser
+
+log = logging.getLogger(__name__)
+
+
+# ---------------------------------------------------------------------------
+# Tunables — hard-coded in v0.11.0 (§19.2 candidate to env-ify later).
+# ---------------------------------------------------------------------------
+
+TRUST_DURATION_DAYS = 30
+COOKIE_NAME = "rfc_device_trust"
+COOKIE_MAX_AGE_SECONDS = TRUST_DURATION_DAYS * 24 * 60 * 60
+# 256 bits of CSPRNG entropy. `secrets.token_urlsafe(32)` yields ~43
+# URL-safe characters; the bcrypt hash is what's stored, so the raw
+# token only ever lives in the cookie.
+TOKEN_BYTES = 32
+# User-Agent header values seen in the wild can be unbounded; clamp
+# to a reasonable ceiling so a hostile UA doesn't bloat the row.
+USER_AGENT_MAX_LENGTH = 1024
+
+
+# ---------------------------------------------------------------------------
+# Issue
+# ---------------------------------------------------------------------------
+
+
+@dataclass
+class IssueOutcome:
+    """The shape returned from `issue`.
+
+    `raw_token` is the cookie value to send to the client; it never
+    appears in storage. `row_id` is the surrogate key for the
+    /settings/devices UI to address the row by id.
+    """
+    raw_token: str
+    row_id: int
+
+
+def _new_token() -> str:
+    return secrets.token_urlsafe(TOKEN_BYTES)
+
+
+def _hash(token: str) -> str:
+    return bcrypt.hashpw(token.encode("utf-8"), bcrypt.gensalt()).decode("ascii")
+
+
+def _check(token: str, token_hash: str) -> bool:
+    try:
+        return bcrypt.checkpw(token.encode("utf-8"), token_hash.encode("ascii"))
+    except (ValueError, TypeError):
+        return False
+
+
+def _trim_user_agent(ua: str) -> str:
+    ua = (ua or "").strip()
+    if len(ua) > USER_AGENT_MAX_LENGTH:
+        return ua[:USER_AGENT_MAX_LENGTH]
+    return ua
+
+
+def issue(user_id: int, user_agent: str) -> IssueOutcome:
+    """Mint a fresh device-trust token + row for `user_id`.
+
+    The row's expiry is set 30 days in the future. The hash, not the
+    raw token, lands in the database. The caller (the endpoint) sets
+    the cookie with the raw token returned here.
+    """
+    raw = _new_token()
+    h = _hash(raw)
+    ua = _trim_user_agent(user_agent)
+    cur = db.conn().execute(
+        f"""
+        INSERT INTO device_trust (user_id, device_token_hash, expires_at, user_agent)
+        VALUES (?, ?, datetime('now', '+{TRUST_DURATION_DAYS} days'), ?)
+        """,
+        (user_id, h, ua),
+    )
+    row_id = cur.lastrowid
+    return IssueOutcome(raw_token=raw, row_id=row_id)
+
+
+# ---------------------------------------------------------------------------
+# Lookup
+# ---------------------------------------------------------------------------
+
+
+@dataclass
+class LookupOutcome:
+    """The result of `lookup`.
+
+    `user` is populated only on a hit. `reason` distinguishes the
+    failure modes so the endpoint can decide whether to clear the
+    cookie ('expired', 'revoked', 'unknown') or just refuse ('invalid').
+    """
+    ok: bool
+    user: SessionUser | None
+    reason: str  # 'ok' | 'invalid' | 'unknown' | 'expired' | 'revoked'
+    row_id: int | None = None
+
+
+def lookup(raw_token: str) -> LookupOutcome:
+    """Resolve a presented cookie token to a user.
+
+    A hit refreshes `last_seen_at` on the matched row. A miss returns
+    a reason so the endpoint can clear the stale cookie if the row
+    was revoked or expired (vs. simply unknown, which probably means
+    the cookie was forged or the row was wiped by a /settings/devices
+    revoke from another browser).
+    """
+    raw = (raw_token or "").strip()
+    if not raw:
+        return LookupOutcome(ok=False, user=None, reason="invalid")
+
+    # The unique index on `device_token_hash` would let us SELECT by
+    # hash if bcrypt were a stable hash, but bcrypt incorporates a
+    # per-row salt — equal tokens produce different hashes. We walk
+    # the candidate set instead. In practice the set is small (a
+    # human has a handful of trusted devices) and bcrypt is cheap on
+    # the order of milliseconds; the walk is bounded by the user's
+    # active device count.
+    #
+    # We don't pre-filter by `revoked_at IS NULL` here so that a
+    # token presented for a recently-revoked row produces a
+    # 'revoked' outcome (the endpoint surfaces a different shape).
+    # Same for expired: we let the walk hit and classify after.
+    rows = db.conn().execute(
+        """
+        SELECT id, user_id, device_token_hash, expires_at, revoked_at
+          FROM device_trust
+         ORDER BY id DESC
+        """,
+    ).fetchall()
+
+    matched = None
+    for row in rows:
+        if _check(raw, row["device_token_hash"]):
+            matched = row
+            break
+
+    if matched is None:
+        return LookupOutcome(ok=False, user=None, reason="unknown")
+
+    if matched["revoked_at"] is not None:
+        return LookupOutcome(ok=False, user=None, reason="revoked", row_id=matched["id"])
+
+    expired = db.conn().execute(
+        "SELECT datetime(?) < datetime('now') AS expired",
+        (matched["expires_at"],),
+    ).fetchone()["expired"]
+    if expired:
+        return LookupOutcome(ok=False, user=None, reason="expired", row_id=matched["id"])
+
+    # Refresh last-seen so the /settings/devices surface can show the
+    # user when each device was last active. This is the only write
+    # the lookup path does on the hot read.
+    db.conn().execute(
+        "UPDATE device_trust SET last_seen_at = datetime('now') WHERE id = ?",
+        (matched["id"],),
+    )
+    user_row = db.conn().execute(
+        """
+        SELECT id, gitea_id, gitea_login, email, display_name, avatar_url, role, permission_state
+          FROM users
+         WHERE id = ?
+        """,
+        (matched["user_id"],),
+    ).fetchone()
+    if user_row is None:
+        # The user row was deleted but the device_trust row hadn't
+        # cascaded yet (shouldn't happen under the FK ON DELETE
+        # CASCADE — be defensive anyway). Treat as 'unknown' so the
+        # endpoint clears the cookie.
+        return LookupOutcome(ok=False, user=None, reason="unknown", row_id=matched["id"])
+
+    # Also stamp last_seen_at on the user row so the user's overall
+    # activity stamp keeps pace with cookie-only sign-ins.
+    db.conn().execute(
+        "UPDATE users SET last_seen_at = datetime('now') WHERE id = ?",
+        (matched["user_id"],),
+    )
+
+    return LookupOutcome(
+        ok=True,
+        user=SessionUser(
+            user_id=user_row["id"],
+            gitea_id=user_row["gitea_id"] or 0,
+            gitea_login=user_row["gitea_login"] or "",
+            display_name=user_row["display_name"],
+            email=user_row["email"] or "",
+            avatar_url=user_row["avatar_url"] or "",
+            role=user_row["role"],
+            permission_state=user_row["permission_state"] or "granted",
+        ),
+        reason="ok",
+        row_id=matched["id"],
+    )
+
+
+# ---------------------------------------------------------------------------
+# List / revoke (for the /settings/devices surface)
+# ---------------------------------------------------------------------------
+
+
+@dataclass
+class DeviceRow:
+    """The shape the /settings/devices endpoint returns.
+
+    Note the absence of `device_token_hash` — the hash is structurally
+    private, and the surface has no use for it.
+    """
+    id: int
+    created_at: str
+    expires_at: str
+    last_seen_at: str
+    user_agent: str
+
+
+def list_for_user(user_id: int) -> list[DeviceRow]:
+    """Active device-trust rows for the user, freshest first.
+
+    Filters out revoked rows and rows whose expiry has passed; the
+    surface only shows live trust grants. A user wondering "which
+    devices are signed in" gets the answer that matches what the
+    framework would actually accept on a presented cookie.
+    """
+    rows = db.conn().execute(
+        """
+        SELECT id, created_at, expires_at, last_seen_at, user_agent
+          FROM device_trust
+         WHERE user_id = ?
+           AND revoked_at IS NULL
+           AND datetime(expires_at) > datetime('now')
+         ORDER BY last_seen_at DESC, id DESC
+        """,
+        (user_id,),
+    ).fetchall()
+    return [
+        DeviceRow(
+            id=row["id"],
+            created_at=row["created_at"],
+            expires_at=row["expires_at"],
+            last_seen_at=row["last_seen_at"],
+            user_agent=row["user_agent"] or "",
+        )
+        for row in rows
+    ]
+
+
+def revoke(user_id: int, row_id: int) -> bool:
+    """Revoke a single device-trust row for the given user.
+
+    Returns True iff a row was matched (still active, belongs to the
+    user). The user-id scope is enforced in SQL so a hostile client
+    cannot revoke another user's row by guessing ids.
+    """
+    cur = db.conn().execute(
+        """
+        UPDATE device_trust
+           SET revoked_at = datetime('now')
+         WHERE id = ?
+           AND user_id = ?
+           AND revoked_at IS NULL
+        """,
+        (row_id, user_id),
+    )
+    return cur.rowcount > 0
+
+
+def revoke_all(user_id: int) -> int:
+    """Revoke every active device-trust row for the user. Returns the
+    count of rows touched.
+
+    The /settings/devices "revoke all" button calls this. The user's
+    current request stays authenticated via its session cookie; the
+    device-trust cookie on the current device is also revoked, but
+    the session middleware's `rfc_session` cookie keeps the request
+    flow alive until the user signs out or the session cookie
+    expires.
+    """
+    cur = db.conn().execute(
+        """
+        UPDATE device_trust
+           SET revoked_at = datetime('now')
+         WHERE user_id = ?
+           AND revoked_at IS NULL
+        """,
+        (user_id,),
+    )
+    return cur.rowcount

backend/app/email.py

@@ -139,10 +139,6 @@ _EVENT_TO_CATEGORY: dict[str, str] = {
     "graduation_complete": "personal-direct",
     "super_draft_graduation_ready": "admin-actionable",
     "claim_opened": "structural",
-    # v0.9.0: roadmap item #7. A fresh beta-access request lands as
-    # an admin-actionable signal so it consults `email_admin_actionable`
-    # and reaches owners/admins only.
-    "new_beta_request": "admin-actionable",
 }
 
 
@@ -289,13 +285,6 @@ def _deep_link(payload: dict, cfg: EmailConfig) -> str:
     slug = payload.get("rfc_slug")
     pr = payload.get("pr_number")
     branch = payload.get("branch_name")
-    event_kind = payload.get("event_kind")
-    # v0.9.0: framework-scoped admin signals link to the admin
-    # surface, not /rfc/... The `new_beta_request` event is the
-    # canonical example; future framework-scoped admin events
-    # may reuse the same branch.
-    if event_kind == "new_beta_request":
-        return f"{cfg.app_url}/admin/users"
     if slug and pr:
         return f"{cfg.app_url}/rfc/{slug}/pr/{pr}"
     if slug and branch:

backend/app/main.py

@@ -10,8 +10,8 @@ import logging
 import secrets
 from contextlib import asynccontextmanager
 
-from fastapi import APIRouter, FastAPI, HTTPException, Request
-from fastapi.responses import RedirectResponse
+from fastapi import APIRouter, FastAPI, HTTPException, Request, Response
+from fastapi.responses import JSONResponse, RedirectResponse
 from pydantic import BaseModel, Field
 from starlette.middleware.sessions import SessionMiddleware
 
@@ -20,6 +20,7 @@ from . import (
     auth,
     cache,
     db,
+    device_trust as device_trust_mod,
     digest,
     email_otc,
     hygiene,
@@ -43,6 +44,12 @@ class OtcRequestBody(BaseModel):
 class OtcVerifyBody(BaseModel):
     email: str = Field(min_length=3, max_length=320)
     code: str = Field(min_length=1, max_length=16)
+    # v0.11.0 — "trust this device for 30 days" checkbox on the Login.jsx
+    # OTC step. When true and verify succeeds, the server issues a fresh
+    # device-trust row and sets the `rfc_device_trust` cookie on the
+    # response. Defaults to false so existing clients that don't send
+    # the flag continue to behave the way they did pre-v0.11.0.
+    trust_device: bool = False
 
 
 class PasscodeSetBody(BaseModel):
@@ -52,6 +59,8 @@ class PasscodeSetBody(BaseModel):
 class PasscodeVerifyBody(BaseModel):
     email: str = Field(min_length=3, max_length=320)
     passcode: str = Field(min_length=1, max_length=64)
+    # v0.11.0 — same trust-device opt-in as the OTC verify body.
+    trust_device: bool = False
 
 
 @asynccontextmanager
@@ -117,6 +126,48 @@ def create_app() -> FastAPI:
 app = create_app()
 
 
+def _set_device_trust_cookie(response: Response, raw_token: str) -> None:
+    """Attach the v0.11.0 device-trust cookie to the response.
+
+    HttpOnly + Secure + SameSite=Lax + 30-day Max-Age + Path=/. The
+    cookie value is the raw token; server-side storage is the hash.
+    The cookie is "essential" per the v0.13.0 cookie-consent contract
+    (it is part of authentication), so we set it regardless of the
+    user's analytics / other-cookies choice.
+
+    Secure=True means the cookie is only ever sent over HTTPS. The
+    SessionMiddleware in `create_app` keeps `https_only=False` for
+    dev parity, but the device-trust cookie holds a 30-day credential
+    and must not travel cleartext — production deployments serve over
+    HTTPS, so Secure on the device-trust cookie is non-negotiable.
+    """
+    response.set_cookie(
+        key=device_trust_mod.COOKIE_NAME,
+        value=raw_token,
+        max_age=device_trust_mod.COOKIE_MAX_AGE_SECONDS,
+        path="/",
+        secure=True,
+        httponly=True,
+        samesite="lax",
+    )
+
+
+def _clear_device_trust_cookie(response: Response) -> None:
+    """Delete the device-trust cookie on the response.
+
+    Used when the framework detects a presented cookie that is
+    expired, revoked, or otherwise stale — the next request from
+    this device will not carry a dead token.
+    """
+    response.delete_cookie(
+        key=device_trust_mod.COOKIE_NAME,
+        path="/",
+        secure=True,
+        httponly=True,
+        samesite="lax",
+    )
+
+
 def _oauth_router(config) -> APIRouter:
     router = APIRouter()
 
@@ -177,7 +228,7 @@ def _oauth_router(config) -> APIRouter:
         return {"ok": True}
 
     @router.post("/auth/otc/verify")
-    async def otc_verify(body: OtcVerifyBody, request: Request):
+    async def otc_verify(body: OtcVerifyBody, request: Request, response: Response):
         result = otc.verify_code(body.email, body.code)
         if not result.ok or result.user is None:
             raise HTTPException(400, "Invalid or expired code")
@@ -202,6 +253,18 @@ def _oauth_router(config) -> APIRouter:
             and not last_name
             and not beta_request_reason
         )
+        # v0.11.0 — opt-in device trust. The checkbox lives on the
+        # Login.jsx OTC step; when true, the server mints a fresh
+        # device-trust row and sets the long-lived cookie. The cookie
+        # is "essential" per the v0.13.0 consent contract (it is part
+        # of authentication, not analytics) so it lands regardless of
+        # the user's analytics / other-cookies choice. We capture the
+        # User-Agent at issuance so the /settings/devices surface can
+        # render a rough device label.
+        if body.trust_device:
+            ua = request.headers.get("user-agent", "")
+            outcome = device_trust_mod.issue(result.user.user_id, ua)
+            _set_device_trust_cookie(response, outcome.raw_token)
         return {
             "ok": True,
             "user": {
@@ -254,12 +317,16 @@ def _oauth_router(config) -> APIRouter:
         return {"ok": True}
 
     @router.post("/auth/passcode/verify")
-    async def passcode_verify(body: PasscodeVerifyBody, request: Request):
+    async def passcode_verify(body: PasscodeVerifyBody, request: Request, response: Response):
         """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)."""
+        collapsed so a probing client cannot enumerate emails).
+
+        v0.11.0: the body's `trust_device` flag, if true, mints a
+        fresh device-trust row and sets the long-lived cookie. Same
+        opt-in contract as `/auth/otc/verify`."""
         result = passcode_mod.verify_passcode(body.email, body.passcode)
         if result.reason == "locked":
             raise HTTPException(
@@ -272,6 +339,10 @@ def _oauth_router(config) -> APIRouter:
         if not result.ok or result.user is None:
             raise HTTPException(400, "Invalid passcode")
         auth.store_session(request, result.user)
+        if body.trust_device:
+            ua = request.headers.get("user-agent", "")
+            outcome = device_trust_mod.issue(result.user.user_id, ua)
+            _set_device_trust_cookie(response, outcome.raw_token)
         return {
             "ok": True,
             "user": {
@@ -282,4 +353,62 @@ def _oauth_router(config) -> APIRouter:
             },
         }
 
+    # ---------------------------------------------------------------
+    # v0.11.0: trust device for 30 days (§6.2, roadmap item #9).
+    #
+    # The /auth/device-trust/start endpoint resolves a presented
+    # `rfc_device_trust` cookie. If it matches a non-expired,
+    # non-revoked row, the session is re-established and the client
+    # is told to skip OTC/passcode entry. A stale cookie (expired or
+    # revoked) is cleared on the response. A miss is structurally
+    # silent — the client falls back to the email step.
+    #
+    # The endpoint is anonymous-reachable: a returning visitor with
+    # the cookie hits this before the email step. We do not gate it
+    # on a session because the entire point is to establish one.
+    # ---------------------------------------------------------------
+
+    @router.post("/auth/device-trust/start")
+    async def device_trust_start(request: Request):
+        """Sign in via a presented device-trust cookie.
+
+        On a hit, re-establishes the session in the cookie store and
+        returns a user payload shaped like /auth/otc/verify (minus
+        `needs_profile`, which a returning device-trust user is
+        structurally past — they signed in at least once before).
+        On a miss, returns 401 + clears the stale cookie. An
+        'unknown' miss (cookie present but no row matches) also
+        clears, since the token is dead to the server either way.
+
+        Note on response construction: we return a `JSONResponse`
+        directly rather than raising `HTTPException` on the miss
+        path because FastAPI's exception handler builds a new
+        response from scratch and would drop any `set_cookie` /
+        `delete_cookie` calls. The hand-built `JSONResponse` lets
+        us attach the cookie-clear header alongside the 401.
+        """
+        raw = request.cookies.get(device_trust_mod.COOKIE_NAME, "")
+        if not raw:
+            return JSONResponse({"detail": "No device trust"}, status_code=401)
+        outcome = device_trust_mod.lookup(raw)
+        if not outcome.ok or outcome.user is None:
+            # Clear the stale cookie so subsequent requests don't
+            # keep replaying a dead token. We surface 401 in all
+            # cases so a probing client can't tell "your row was
+            # revoked" from "this token never existed".
+            response = JSONResponse({"detail": "Device trust invalid"}, status_code=401)
+            _clear_device_trust_cookie(response)
+            return response
+        auth.store_session(request, outcome.user)
+        return {
+            "ok": True,
+            "user": {
+                "id": outcome.user.user_id,
+                "display_name": outcome.user.display_name,
+                "email": outcome.user.email,
+                "role": outcome.user.role,
+                "permission_state": outcome.user.permission_state,
+            },
+        }
+
     return router

backend/app/notify.py

@@ -64,7 +64,6 @@ log = logging.getLogger(__name__)
 CATEGORY_PERSONAL = "personal-direct"
 CATEGORY_STRUCTURAL = "structural"
 CATEGORY_CHURN = "churn"
-CATEGORY_ADMIN_ACTIONABLE = "admin-actionable"
 
 # Action kinds whose actor's first interaction with a slug triggers
 # auto-watch per §15.6. The substantive-gesture list in the spec is
@@ -209,67 +208,6 @@ def fan_out_from_action(
             )
 
 
-def fan_out_new_beta_request(
-    *,
-    requester_user_id: int,
-) -> None:
-    """v0.9.0 (roadmap item #7): announce a fresh beta-access request to
-    every admin/owner.
-
-    Called from `POST /api/auth/me/beta-request` after the row's
-    first/last/why fields are populated. Fan-out shape mirrors the §15
-    chokepoint contract: one row per recipient, written via `_emit_one`
-    so the SSE broadcast + email dispatch run through the same surface
-    every other notification uses. The event has no rfc_slug (it is
-    framework-scoped, not RFC-scoped); the deep-link payload points
-    `/admin/users` instead of `/rfc/<slug>`.
-
-    Actor is the requester per §15.9 (the underlying user, never the
-    bot). Category is `admin-actionable` so the §15.4 email gate
-    consults `email_admin_actionable` (owners/admins-only by
-    construction) and the digest exclusion rules treat it identically
-    to other admin-actionable signals (graduation_ready et al).
-
-    Recipients are owners + admins minus the requester themselves
-    (a self-promotion shouldn't reach the requester's own inbox). The
-    requester is never in the role set in practice — the endpoint
-    refuses 'granted'/'revoked' callers and a fresh OTC user lands
-    `contributor`+`pending` — but we filter regardless so the call
-    is robust to future changes in the auth gate.
-    """
-    requester = db.conn().execute(
-        "SELECT first_name, last_name, email, display_name FROM users WHERE id = ?",
-        (requester_user_id,),
-    ).fetchone()
-    if requester is None:
-        return
-    first = (requester["first_name"] or "").strip()
-    last = (requester["last_name"] or "").strip()
-    email = requester["email"] or ""
-    display = requester["display_name"] or email or "a new user"
-    full_name = (f"{first} {last}").strip() or display
-    details = {
-        "requester_user_id": requester_user_id,
-        "requester_first_name": first,
-        "requester_last_name": last,
-        "requester_email": email,
-        "requester_display": full_name,
-    }
-    for recipient_id in _admin_user_ids():
-        if recipient_id == requester_user_id:
-            continue
-        _emit_one(
-            recipient_user_id=recipient_id,
-            event_kind="new_beta_request",
-            category=CATEGORY_ADMIN_ACTIONABLE,
-            actor_user_id=requester_user_id,
-            rfc_slug=None,
-            branch_name=None,
-            pr_number=None,
-            details=details,
-        )
-
-
 def fan_out_chat_message(
     *,
     actor_user_id: int,
@@ -769,16 +707,6 @@ def render_summary(event_kind: str, actor_display: str | None, rfc_title: str |
         return f"{actor} began graduating {title}."
     if event_kind == "pr_conflict_with_main":
         return f"{actor} started a resolution branch on {title}."
-    if event_kind == "new_beta_request":
-        # v0.9.0: framework-scoped, not RFC-scoped. The actor (the
-        # requester) and the captured full name + email read as
-        # one self-contained sentence; the inbox row and the email
-        # body share this text per §15.4.
-        full_name = extras.get("requester_display") or actor
-        email_addr = extras.get("requester_email") or ""
-        if email_addr:
-            return f"New beta-access request from {full_name} ({email_addr})."
-        return f"New beta-access request from {full_name}."
     return f"{event_kind} on {title}"
 
 

backend/migrations/017_device_trust.sql

@@ -0,0 +1,75 @@
+-- §6.2 / v0.11.0: trust device for 30 days (roadmap item #9).
+--
+-- After a successful OTC or passcode sign-in, the user can check
+-- "trust this device for 30 days." The framework then issues a
+-- server-issued opaque device-trust token, stores its hash on this
+-- table, and sets a long-lived HttpOnly + Secure + SameSite=Lax
+-- cookie carrying the raw token. On a subsequent visit, the cookie is
+-- presented at `/auth/device-trust/start`; if the server can match the
+-- hash to a non-expired non-revoked row, the user is signed in without
+-- another OTC / passcode round-trip.
+--
+-- v0.11.0 introduces no new env vars. The 30-day window is hard-coded
+-- in `backend/app/device_trust.py`; raising or lowering it (or making
+-- it user-selectable) is a §19.2 candidate, alongside the cross-device
+-- session-revocation surface this table will eventually share with the
+-- v0.10.0 passcode-lockout shape (see SPEC §19.2 / SESSIONS-AND-DEVICES).
+--
+-- Storage shape:
+--
+--   * `id` — surrogate key. Lets the revoke-device UI address a single
+--     row by id without leaking the token shape.
+--   * `user_id` — FK into users(id) with cascade on delete. A deleted
+--     user automatically loses every trusted device.
+--   * `device_token_hash` — bcrypt hash of the random opaque token
+--     issued at trust-time. The raw token only ever lives in the
+--     outbound `Set-Cookie` header and the inbound `Cookie` header;
+--     server-side storage is the hash, so a DB compromise does not
+--     hand attackers a stash of valid device tokens.
+--   * `created_at` — when the row was issued.
+--   * `expires_at` — `created_at + 30 days`. A row past this timestamp
+--     is dead; the lookup path refuses it without further checks.
+--   * `user_agent` — the User-Agent header captured at issuance.
+--     Stored verbatim (truncated to 1024 chars at the application
+--     layer) so the revoke-device UI can show a rough device label.
+--     Not used for any auth decision — purely a hint to the user
+--     reviewing their device list.
+--   * `last_seen_at` — refreshed every time the row authenticates a
+--     request. Lets the revoke-device UI surface "last used 3 days
+--     ago" so the user can tell which row corresponds to which
+--     device.
+--   * `revoked_at` — NULL means active; non-NULL stamps when the user
+--     (or admin) revoked the row. Lookups treat any non-NULL value
+--     as "this row is dead" without consulting the expiry; the
+--     revoke gesture is intentionally one-way (a revoked device must
+--     re-trust to come back online).
+--
+-- Indexing: a unique index on `device_token_hash` so collisions are
+-- detectable at insert time (the token space is 256 bits of CSPRNG
+-- entropy, so a collision is structurally impossible, but the
+-- declaration documents the invariant). A separate index on
+-- `(user_id, revoked_at)` so the revoke-device UI's list query is
+-- a covering walk.
+--
+-- The bcrypt dependency reused here was added in v0.7.0 for OTC and
+-- extended in v0.10.0 for passcodes; v0.11.0 needs no new dep.
+--
+-- The cookie shape: `rfc_device_trust` carries the raw token,
+-- HttpOnly, Secure, SameSite=Lax, Max-Age=2592000 (30 days). It is
+-- "essential" per the v0.13.0 cookie-consent banner (it is part of
+-- authentication, not analytics), so it is set regardless of the
+-- user's analytics / other-cookies choices.
+
+CREATE TABLE device_trust (
+    id                  INTEGER PRIMARY KEY AUTOINCREMENT,
+    user_id             INTEGER NOT NULL REFERENCES users(id) ON DELETE CASCADE,
+    device_token_hash   TEXT NOT NULL,
+    created_at          TEXT NOT NULL DEFAULT (datetime('now')),
+    expires_at          TEXT NOT NULL,
+    user_agent          TEXT NOT NULL DEFAULT '',
+    last_seen_at        TEXT NOT NULL DEFAULT (datetime('now')),
+    revoked_at          TEXT
+);
+
+CREATE UNIQUE INDEX idx_device_trust_token_hash ON device_trust (device_token_hash);
+CREATE INDEX idx_device_trust_user ON device_trust (user_id, revoked_at);

backend/tests/test_admin_users_vertical.py

@@ -1,425 +0,0 @@
-"""End-to-end integration tests for v0.9.0's admin user-management page
-and new-beta-request notifications (roadmap item #7, §6.1 / §15).
-
-The release lands two halves of the same surface:
-
-  * **Admin notification on new beta request.** When a pending user
-    submits `POST /api/auth/me/beta-request`, every owner/admin
-    receives a `new_beta_request` notification (the §15 substrate
-    insert lands the row; the §15.4 email path dispatches subject to
-    the recipient's `email_admin_actionable` toggle).
-
-  * **Admin user-management surface** at `/admin/users`. The
-    `GET /api/admin/users` listing carries every user with their
-    permission_state, profile fields, sign-up reason, and decision
-    audit. The new `POST /api/admin/users/<id>/permission` endpoint
-    flips the column and writes a `permission_events` row.
-
-The tests prove:
-
-  * The first beta-request submission fans a `new_beta_request`
-    row out to every admin/owner (and not to the requester
-    themselves). The row carries the captured profile in
-    `payload.extras`.
-  * Re-submitting the form from the same pending user doesn't
-    re-fan (we only notify on the row's first complete state).
-  * `GET /api/admin/users` carries the v0.9.0 columns
-    (permission_state, first/last/reason, decided_by).
-  * `POST /api/admin/users/<id>/permission` flips the state,
-    stamps decided_by/at, and writes a `permission_events` row.
-  * The endpoint refuses self-flip (422) and refuses non-admin
-    callers (403).
-  * The endpoint accepts only the three valid states (422 on
-    anything else).
-"""
-from __future__ import annotations
-
-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]:
-    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 _provision_pending_user(client, email: str) -> int:
-    """Sign in a fresh OTC user (lands `pending`) and return their user_id."""
-    from app import db
-    _reset_outbound()
-    client.post("/auth/otc/request", json={"email": email})
-    code = _outbound_otc_codes(email)[-1]
-    client.post("/auth/otc/verify", json={"email": email, "code": code})
-    row = db.conn().execute(
-        "SELECT id FROM users WHERE email = ? COLLATE NOCASE", (email,)
-    ).fetchone()
-    return row["id"]
-
-
-# ---------------------------------------------------------------------------
-# Admin notification on beta-request submission
-# ---------------------------------------------------------------------------
-
-
-def test_beta_request_submission_notifies_every_admin(app_with_fake_gitea):
-    """First-time submission of a beta-request fans a notification out
-    to every owner and admin. The requester themselves never receives
-    a row (filtered out by user_id even if they happened to be in the
-    admin set, which they aren't in practice — fresh OTC users are
-    `contributor`+`pending`)."""
-    from fastapi.testclient import TestClient
-    from app import db
-
-    app, _fake = app_with_fake_gitea
-    with TestClient(app) as client:
-        # Provision two admins and one owner so the fan-out has multiple
-        # targets. The OWNER_GITEA_LOGIN-derived ownership doesn't fire
-        # here (no OAuth round-trip in this path); we seed the role
-        # directly.
-        provision_user_row(user_id=10, login="ownerzero", role="owner")
-        provision_user_row(user_id=11, login="admin_one", role="admin")
-        provision_user_row(user_id=12, login="admin_two", role="admin")
-        provision_user_row(user_id=13, login="contrib_one", role="contributor")
-
-        # Sign in a fresh OTC user → permission_state='pending'.
-        requester_id = _provision_pending_user(client, "newbie@example.com")
-
-        # Capture-form submit.
-        r = client.post(
-            "/api/auth/me/beta-request",
-            json={
-                "first_name": "Newt",
-                "last_name": "Newcomer",
-                "beta_request_reason": "I want to write the Human RFC.",
-            },
-        )
-        assert r.status_code == 200, r.text
-
-        # Every owner + admin gets a `new_beta_request` notification.
-        # The contributor (id=13) does not. The requester (whoever id
-        # they got) does not.
-        rows = db.conn().execute(
-            """
-            SELECT recipient_user_id, event_kind, actor_user_id, payload
-              FROM notifications
-             WHERE event_kind = 'new_beta_request'
-            """
-        ).fetchall()
-        recipients = sorted(r["recipient_user_id"] for r in rows)
-        assert recipients == [10, 11, 12], f"unexpected recipients: {recipients}"
-        # Actor is the requester (§15.9: never the bot).
-        for r in rows:
-            assert r["actor_user_id"] == requester_id
-            import json as _json
-            extras = _json.loads(r["payload"])
-            assert extras["requester_first_name"] == "Newt"
-            assert extras["requester_last_name"] == "Newcomer"
-            assert extras["requester_email"] == "newbie@example.com"
-
-
-def test_beta_request_resubmit_does_not_re_notify(app_with_fake_gitea):
-    """Once a user has completed the capture form, re-submitting it
-    (the endpoint is idempotent for pending users) must not re-fan a
-    fresh notification to every admin — that would carpet-bomb the
-    inbox on every typo correction."""
-    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=20, login="adminzero", role="admin")
-        _provision_pending_user(client, "carpet@example.com")
-
-        body = {
-            "first_name": "Carpet",
-            "last_name": "Bomb",
-            "beta_request_reason": "first draft",
-        }
-        r1 = client.post("/api/auth/me/beta-request", json=body)
-        assert r1.status_code == 200
-
-        # Re-submit with edited reason — endpoint accepts (idempotent
-        # update), but the admin inbox stays at one row.
-        body2 = dict(body, beta_request_reason="cleaner final draft")
-        r2 = client.post("/api/auth/me/beta-request", json=body2)
-        assert r2.status_code == 200
-
-        rows = db.conn().execute(
-            "SELECT COUNT(*) AS n FROM notifications WHERE event_kind = 'new_beta_request'"
-        ).fetchone()
-        assert rows["n"] == 1
-
-
-def test_beta_request_notification_is_admin_actionable_category(app_with_fake_gitea):
-    """The §15.4 category mapping must route `new_beta_request` to the
-    admin-actionable bucket so the email gate consults
-    `email_admin_actionable` (and skips for non-admin recipients).
-    """
-    from app import email as email_mod
-
-    assert email_mod.category_for("new_beta_request", "structural") == "admin-actionable"
-
-
-# ---------------------------------------------------------------------------
-# /api/admin/users — listing carries the v0.9.0 columns
-# ---------------------------------------------------------------------------
-
-
-def test_admin_users_listing_carries_permission_columns(app_with_fake_gitea):
-    """The Users tab consumes this shape — confirm every required
-    column is on the response."""
-    from fastapi.testclient import TestClient
-    from app import db
-
-    app, _fake = app_with_fake_gitea
-    with TestClient(app) as client:
-        # Seed an admin and a pending user with all the v0.8.0 columns
-        # populated. Direct-DB insert avoids the OTC dance (which would
-        # overwrite the cookie); the test above proves the capture
-        # pathway end-to-end and this one just exercises the listing
-        # surface's shape.
-        provision_user_row(user_id=30, login="ben", role="owner")
-        db.conn().execute(
-            """
-            INSERT INTO users (id, gitea_id, gitea_login, email,
-                               display_name, avatar_url, role,
-                               permission_state, first_name, last_name,
-                               beta_request_reason)
-            VALUES (31, NULL, NULL, 'pendinguser@example.com',
-                    'pendinguser', '', 'contributor',
-                    'pending', 'Penn', 'Ding', 'I want in.')
-            """
-        )
-
-        sign_in_as(
-            client, user_id=30, gitea_login="ben",
-            display_name="Ben", role="owner",
-        )
-
-        r = client.get("/api/admin/users")
-        assert r.status_code == 200
-        items = r.json()["items"]
-        assert isinstance(items, list)
-        pending = next(
-            (i for i in items if i["email"] == "pendinguser@example.com"), None,
-        )
-        assert pending is not None
-        assert pending["permission_state"] == "pending"
-        assert pending["first_name"] == "Penn"
-        assert pending["last_name"] == "Ding"
-        assert pending["beta_request_reason"] == "I want in."
-        assert pending["permission_decided_at"] is None
-        assert pending["permission_decided_by_login"] is None
-        # Pending bucket is listed first (sort order).
-        assert items[0]["permission_state"] == "pending"
-
-
-# ---------------------------------------------------------------------------
-# /api/admin/users/<id>/permission — the flip endpoint
-# ---------------------------------------------------------------------------
-
-
-def test_permission_flip_grant_promotes_pending_to_granted(app_with_fake_gitea):
-    """The end-to-end gesture: a fresh OTC user lands pending, an admin
-    flips them to granted via the endpoint, the row reflects the new
-    state + decided_by/at, and a `permission_events` audit row lands."""
-    from fastapi.testclient import TestClient
-    from app import db
-
-    app, _fake = app_with_fake_gitea
-    with TestClient(app) as client:
-        # Pending user.
-        pending_id = _provision_pending_user(client, "flip@example.com")
-
-        # Admin acting on them.
-        provision_user_row(user_id=40, login="adminflipper", role="admin")
-        sign_in_as(
-            client, user_id=40, gitea_login="adminflipper",
-            display_name="Admin Flipper", role="admin",
-        )
-
-        r = client.post(
-            f"/api/admin/users/{pending_id}/permission",
-            json={"state": "granted"},
-        )
-        assert r.status_code == 200, r.text
-        body = r.json()
-        assert body["permission_state"] == "granted"
-        assert body["changed"] is True
-
-        # Row reflects the new state + decision stamp.
-        row = db.conn().execute(
-            "SELECT permission_state, permission_decided_by, permission_decided_at "
-            "FROM users WHERE id = ?",
-            (pending_id,),
-        ).fetchone()
-        assert row["permission_state"] == "granted"
-        assert row["permission_decided_by"] == 40
-        assert row["permission_decided_at"] is not None
-
-        # Audit row landed in permission_events.
-        events = db.conn().execute(
-            """
-            SELECT actor_user_id, subject_user_id, event_kind
-              FROM permission_events
-             WHERE event_kind = 'permission_granted'
-            """
-        ).fetchall()
-        assert len(events) == 1
-        assert events[0]["actor_user_id"] == 40
-        assert events[0]["subject_user_id"] == pending_id
-
-
-def test_permission_flip_revoke_promotes_granted_to_revoked(app_with_fake_gitea):
-    """Revoke is the symmetric gesture. Used when an account earned a
-    grant then later lost it (§6.1 / `revoked` state)."""
-    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=50, login="goner", role="contributor")
-        # Default permission_state is 'granted' via the column default.
-        provision_user_row(user_id=51, login="adminrevoker", role="admin")
-        sign_in_as(
-            client, user_id=51, gitea_login="adminrevoker",
-            display_name="Admin Revoker", role="admin",
-        )
-
-        r = client.post(
-            "/api/admin/users/50/permission",
-            json={"state": "revoked"},
-        )
-        assert r.status_code == 200, r.text
-
-        row = db.conn().execute(
-            "SELECT permission_state FROM users WHERE id = 50"
-        ).fetchone()
-        assert row["permission_state"] == "revoked"
-
-        events = db.conn().execute(
-            "SELECT event_kind FROM permission_events "
-            "WHERE event_kind = 'permission_revoked' AND subject_user_id = 50"
-        ).fetchall()
-        assert len(events) == 1
-
-
-def test_permission_flip_refuses_self(app_with_fake_gitea):
-    """Symmetric to set_mute / set_role: an admin can't self-flip.
-    The state-change channel for one's own grant is somebody else's
-    hand."""
-    from fastapi.testclient import TestClient
-
-    app, _fake = app_with_fake_gitea
-    with TestClient(app) as client:
-        provision_user_row(user_id=60, login="selfflipper", role="admin")
-        sign_in_as(
-            client, user_id=60, gitea_login="selfflipper",
-            display_name="Self Flipper", role="admin",
-        )
-        r = client.post(
-            "/api/admin/users/60/permission",
-            json={"state": "revoked"},
-        )
-        assert r.status_code == 422
-
-
-def test_permission_flip_refuses_non_admin(app_with_fake_gitea):
-    """The endpoint is admin-only (§17 admin/* requires require_admin).
-    A contributor caller is refused 403; an anonymous caller 401."""
-    from fastapi.testclient import TestClient
-
-    app, _fake = app_with_fake_gitea
-    with TestClient(app) as client:
-        provision_user_row(user_id=70, login="target", role="contributor")
-        provision_user_row(user_id=71, login="contrib", role="contributor")
-        sign_in_as(
-            client, user_id=71, gitea_login="contrib",
-            display_name="Contrib", role="contributor",
-        )
-        r = client.post(
-            "/api/admin/users/70/permission",
-            json={"state": "granted"},
-        )
-        assert r.status_code == 403
-
-        client.cookies.clear()
-        r = client.post(
-            "/api/admin/users/70/permission",
-            json={"state": "granted"},
-        )
-        assert r.status_code == 401
-
-
-def test_permission_flip_refuses_invalid_state(app_with_fake_gitea):
-    """Pydantic regex pattern refuses anything outside the three
-    canonical states with 422."""
-    from fastapi.testclient import TestClient
-
-    app, _fake = app_with_fake_gitea
-    with TestClient(app) as client:
-        provision_user_row(user_id=80, login="targetx", role="contributor")
-        provision_user_row(user_id=81, login="adminx", role="admin")
-        sign_in_as(
-            client, user_id=81, gitea_login="adminx",
-            display_name="Admin X", role="admin",
-        )
-        r = client.post(
-            "/api/admin/users/80/permission",
-            json={"state": "banished"},
-        )
-        assert r.status_code == 422
-
-
-def test_permission_flip_no_op_when_state_already_matches(app_with_fake_gitea):
-    """An admin flipping a granted user to granted gets 200 with
-    `changed: false` — no audit row, no decided_at update."""
-    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=90, login="alreadygranted", role="contributor")
-        provision_user_row(user_id=91, login="adminN", role="admin")
-        sign_in_as(
-            client, user_id=91, gitea_login="adminN",
-            display_name="Admin N", role="admin",
-        )
-
-        before_events = db.conn().execute(
-            "SELECT COUNT(*) AS n FROM permission_events"
-        ).fetchone()["n"]
-
-        r = client.post(
-            "/api/admin/users/90/permission",
-            json={"state": "granted"},
-        )
-        assert r.status_code == 200
-        body = r.json()
-        assert body["changed"] is False
-
-        after_events = db.conn().execute(
-            "SELECT COUNT(*) AS n FROM permission_events"
-        ).fetchone()["n"]
-        assert after_events == before_events

backend/tests/test_device_trust_vertical.py

@@ -0,0 +1,494 @@
+"""End-to-end integration tests for the v0.11.0 trust-device vertical
+(§6.2, roadmap item #9).
+
+After a successful OTC or passcode sign-in with `trust_device=true`
+on the body, the server mints a fresh `device_trust` row and sets the
+`rfc_device_trust` cookie. On a subsequent visit, the cookie carries
+a session re-established by `POST /auth/device-trust/start`. The
+tests below prove:
+
+  * `trust_device=false` (default, including omitted) on OTC verify
+    does NOT set the device-trust cookie and does NOT insert a row.
+  * `trust_device=true` on OTC verify DOES set the cookie (HttpOnly +
+    Secure + SameSite=Lax + 30-day Max-Age) and DOES insert a row.
+    The row's hash is NOT the raw token; only the hash lives in the
+    database.
+  * Same shape for passcode verify.
+  * On a returning visit with the cookie, `POST /auth/device-trust/start`
+    re-establishes the session — `GET /api/auth/me` reads the right
+    user without an OTC roundtrip.
+  * `last_seen_at` refreshes on a successful lookup.
+  * `POST /auth/device-trust/start` with no cookie returns 401.
+  * `POST /auth/device-trust/start` with a forged / unknown cookie
+    returns 401 + clears the cookie.
+  * A revoked row refuses the cookie (401) and clears it.
+  * An expired row refuses the cookie (401) and clears it.
+  * `GET /api/auth/me/devices` lists the user's active rows.
+  * `DELETE /api/auth/me/devices/{id}` revokes a single row.
+  * `DELETE /api/auth/me/devices/{id}` for another user's row reads 404.
+  * `DELETE /api/auth/me/devices` revokes every active row.
+  * Constant-time path: bcrypt.checkpw guards lookup; the raw token
+    is never written to logs or to the DB.
+
+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.
+# ---------------------------------------------------------------------------
+
+
+COOKIE_NAME = "rfc_device_trust"
+
+# The device-trust cookie is set with Secure=True, which httpx (the
+# TestClient's underlying transport) will only return on an https
+# scheme. We use a `base_url="https://testserver"` so the cookie
+# roundtrips faithfully — that mirrors how production deployments
+# serve the framework (per the v0.11.0 upgrade-step requiring HTTPS).
+HTTPS_BASE = "https://testserver"
+
+
+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, *, trust_device: bool = False) -> None:
+    r = client.post("/auth/otc/request", json={"email": email})
+    assert r.status_code == 200, r.text
+    code = _outbound_otc_codes(email)[-1]
+    body = {"email": email, "code": code, "trust_device": trust_device}
+    r = client.post("/auth/otc/verify", json=body)
+    assert r.status_code == 200, r.text
+
+
+def _device_rows_for_email(email: str) -> list[dict]:
+    from app import db
+    rows = db.conn().execute(
+        """
+        SELECT dt.*
+          FROM device_trust dt
+          JOIN users u ON u.id = dt.user_id
+         WHERE u.email = ? COLLATE NOCASE
+         ORDER BY dt.id
+        """,
+        (email,),
+    ).fetchall()
+    return [dict(r) for r in rows]
+
+
+# ---------------------------------------------------------------------------
+# trust_device flag controls cookie issuance
+# ---------------------------------------------------------------------------
+
+
+def test_otc_verify_without_trust_device_does_not_issue_cookie(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app, base_url=HTTPS_BASE) as client:
+        _reset_outbound()
+        _sign_in_via_otc(client, "alice@example.com", trust_device=False)
+        # No cookie set on the response.
+        assert COOKIE_NAME not in {c.name for c in client.cookies.jar}
+        # No row inserted.
+        assert _device_rows_for_email("alice@example.com") == []
+
+
+def test_otc_verify_with_trust_device_issues_cookie_and_row(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app, base_url=HTTPS_BASE) as client:
+        _reset_outbound()
+        r = client.post("/auth/otc/request", json={"email": "alice@example.com"})
+        assert r.status_code == 200, r.text
+        code = _outbound_otc_codes("alice@example.com")[-1]
+        r = client.post(
+            "/auth/otc/verify",
+            json={"email": "alice@example.com", "code": code, "trust_device": True},
+            headers={"User-Agent": "Mozilla/5.0 (TestBrowser)"},
+        )
+        assert r.status_code == 200, r.text
+
+        # Cookie present on the response.
+        set_cookie = r.headers.get("set-cookie", "")
+        assert COOKIE_NAME in set_cookie
+        # Cookie attribute set asserts the spec'd shape. Starlette emits
+        # the attribute names case-insensitively (`samesite=lax`,
+        # `httponly`); we normalize when asserting.
+        lower = set_cookie.lower()
+        assert "httponly" in lower
+        assert "secure" in lower
+        assert "samesite=lax" in lower
+        assert "max-age=" in lower
+
+        # Row inserted; hash is not the raw token.
+        rows = _device_rows_for_email("alice@example.com")
+        assert len(rows) == 1
+        row = rows[0]
+        assert row["revoked_at"] is None
+        assert row["user_agent"] == "Mozilla/5.0 (TestBrowser)"
+        cookie_token = client.cookies.get(COOKIE_NAME)
+        assert cookie_token
+        assert cookie_token != row["device_token_hash"]
+        # bcrypt hash shape (starts with $2)
+        assert row["device_token_hash"].startswith("$2")
+
+
+def test_passcode_verify_with_trust_device_issues_cookie(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app, base_url=HTTPS_BASE) as client:
+        _reset_outbound()
+        _sign_in_via_otc(client, "alice@example.com")
+
+        # Set a passcode.
+        r = client.post("/auth/passcode/set", json={"passcode": "secret123"})
+        assert r.status_code == 200, r.text
+
+        # Sign out so the passcode verify path is the active sign-in.
+        client.cookies.clear()
+
+        # Passcode verify with trust_device=true issues a row.
+        r = client.post(
+            "/auth/passcode/verify",
+            json={"email": "alice@example.com", "passcode": "secret123", "trust_device": True},
+            headers={"User-Agent": "Test/Phone"},
+        )
+        assert r.status_code == 200, r.text
+        set_cookie = r.headers.get("set-cookie", "")
+        assert COOKIE_NAME in set_cookie
+
+        rows = _device_rows_for_email("alice@example.com")
+        assert len(rows) == 1
+        assert rows[0]["user_agent"] == "Test/Phone"
+
+
+# ---------------------------------------------------------------------------
+# /auth/device-trust/start
+# ---------------------------------------------------------------------------
+
+
+def test_device_trust_start_with_no_cookie_returns_401(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app, base_url=HTTPS_BASE) as client:
+        r = client.post("/auth/device-trust/start")
+        assert r.status_code == 401
+
+
+def test_device_trust_start_with_valid_cookie_establishes_session(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app, base_url=HTTPS_BASE) as client:
+        _reset_outbound()
+        # Trust the device.
+        r = client.post("/auth/otc/request", json={"email": "alice@example.com"})
+        assert r.status_code == 200, r.text
+        code = _outbound_otc_codes("alice@example.com")[-1]
+        r = client.post(
+            "/auth/otc/verify",
+            json={"email": "alice@example.com", "code": code, "trust_device": True},
+        )
+        assert r.status_code == 200, r.text
+        trust_cookie = client.cookies.get(COOKIE_NAME)
+        assert trust_cookie
+
+        # Clear the session cookie so only the device-trust cookie is in
+        # play. We keep `rfc_device_trust` and drop `rfc_session`.
+        for cookie in list(client.cookies.jar):
+            if cookie.name != COOKIE_NAME:
+                client.cookies.jar.clear(cookie.domain, cookie.path, cookie.name)
+
+        # The session cookie is gone — /api/auth/me reads anonymous.
+        me = client.get("/api/auth/me").json()
+        assert me["authenticated"] is False
+
+        # Hit the trust-start endpoint; the cookie re-establishes the session.
+        r = client.post("/auth/device-trust/start")
+        assert r.status_code == 200, r.text
+        assert r.json()["user"]["email"] == "alice@example.com"
+
+        # /api/auth/me now reads authenticated.
+        me = client.get("/api/auth/me").json()
+        assert me["authenticated"] is True
+        assert me["user"]["email"] == "alice@example.com"
+
+
+def test_device_trust_start_refreshes_last_seen_at(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+    from app import db
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app, base_url=HTTPS_BASE) as client:
+        _reset_outbound()
+        r = client.post("/auth/otc/request", json={"email": "alice@example.com"})
+        assert r.status_code == 200, r.text
+        code = _outbound_otc_codes("alice@example.com")[-1]
+        r = client.post(
+            "/auth/otc/verify",
+            json={"email": "alice@example.com", "code": code, "trust_device": True},
+        )
+        assert r.status_code == 200, r.text
+
+        # Force the existing row's last_seen_at into the past so we can
+        # assert the refresh moved it forward.
+        db.conn().execute(
+            """
+            UPDATE device_trust
+               SET last_seen_at = datetime('now', '-7 days')
+            """
+        )
+
+        # Hit the start endpoint.
+        r = client.post("/auth/device-trust/start")
+        assert r.status_code == 200, r.text
+
+        # last_seen_at is now recent (within the last minute).
+        row = db.conn().execute(
+            "SELECT last_seen_at, datetime('now') >= datetime(last_seen_at, '-1 minute') AS fresh FROM device_trust LIMIT 1"
+        ).fetchone()
+        assert row["fresh"] == 1
+
+
+def test_device_trust_start_with_revoked_row_refuses_and_clears(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+    from app import db
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app, base_url=HTTPS_BASE) as client:
+        _reset_outbound()
+        r = client.post("/auth/otc/request", json={"email": "alice@example.com"})
+        assert r.status_code == 200, r.text
+        code = _outbound_otc_codes("alice@example.com")[-1]
+        r = client.post(
+            "/auth/otc/verify",
+            json={"email": "alice@example.com", "code": code, "trust_device": True},
+        )
+        assert r.status_code == 200, r.text
+
+        # Revoke the row out-of-band.
+        db.conn().execute(
+            "UPDATE device_trust SET revoked_at = datetime('now')"
+        )
+
+        # Now the start endpoint refuses + clears the cookie.
+        r = client.post("/auth/device-trust/start")
+        assert r.status_code == 401
+        # The cookie is cleared via a Set-Cookie header with Max-Age=0
+        # (Starlette's `delete_cookie` shape).
+        set_cookie = r.headers.get("set-cookie", "")
+        assert COOKIE_NAME in set_cookie
+        assert "Max-Age=0" in set_cookie or 'expires=Thu, 01 Jan 1970' in set_cookie.lower().replace("expires=thu", "expires=Thu")
+
+
+def test_device_trust_start_with_expired_row_refuses_and_clears(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+    from app import db
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app, base_url=HTTPS_BASE) as client:
+        _reset_outbound()
+        r = client.post("/auth/otc/request", json={"email": "alice@example.com"})
+        assert r.status_code == 200, r.text
+        code = _outbound_otc_codes("alice@example.com")[-1]
+        r = client.post(
+            "/auth/otc/verify",
+            json={"email": "alice@example.com", "code": code, "trust_device": True},
+        )
+        assert r.status_code == 200, r.text
+
+        # Backdate the expiry into the past.
+        db.conn().execute(
+            "UPDATE device_trust SET expires_at = datetime('now', '-1 day')"
+        )
+
+        r = client.post("/auth/device-trust/start")
+        assert r.status_code == 401
+        set_cookie = r.headers.get("set-cookie", "")
+        assert COOKIE_NAME in set_cookie
+
+
+def test_device_trust_start_with_forged_cookie_refuses_and_clears(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app, base_url=HTTPS_BASE) as client:
+        # No real row; just paste a cookie value.
+        client.cookies.set(COOKIE_NAME, "definitely-not-a-real-token-value-xxx")
+        r = client.post("/auth/device-trust/start")
+        assert r.status_code == 401
+        set_cookie = r.headers.get("set-cookie", "")
+        assert COOKIE_NAME in set_cookie
+
+
+# ---------------------------------------------------------------------------
+# /api/auth/me/devices — list + revoke
+# ---------------------------------------------------------------------------
+
+
+def test_list_devices_requires_session(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app, base_url=HTTPS_BASE) as client:
+        r = client.get("/api/auth/me/devices")
+        assert r.status_code == 401
+
+
+def test_list_devices_returns_active_rows_only(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+    from app import db
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app, base_url=HTTPS_BASE) as client:
+        _reset_outbound()
+        _sign_in_via_otc(client, "alice@example.com", trust_device=True)
+
+        # Add a second trusted device by re-running the verify flow.
+        # OTC has a per-email cooldown, so drop the cooldown rather
+        # than waiting it out.
+        db.conn().execute("UPDATE otc_codes SET consumed_at = datetime('now', '-1 hour'), created_at = datetime('now', '-1 hour')")
+        r = client.post("/auth/otc/request", json={"email": "alice@example.com"})
+        assert r.status_code == 200, r.text
+        code = _outbound_otc_codes("alice@example.com")[-1]
+        r = client.post(
+            "/auth/otc/verify",
+            json={"email": "alice@example.com", "code": code, "trust_device": True},
+            headers={"User-Agent": "Test/Tablet"},
+        )
+        assert r.status_code == 200, r.text
+
+        # Revoke one row directly.
+        db.conn().execute(
+            "UPDATE device_trust SET revoked_at = datetime('now') WHERE id = 1"
+        )
+
+        # /api/auth/me/devices returns only the un-revoked one.
+        r = client.get("/api/auth/me/devices")
+        assert r.status_code == 200, r.text
+        items = r.json()["items"]
+        assert len(items) == 1
+        assert items[0]["user_agent"] == "Test/Tablet"
+
+
+def test_revoke_single_device_kills_the_row(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+    from app import db
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app, base_url=HTTPS_BASE) as client:
+        _reset_outbound()
+        _sign_in_via_otc(client, "alice@example.com", trust_device=True)
+
+        r = client.get("/api/auth/me/devices")
+        assert r.status_code == 200, r.text
+        items = r.json()["items"]
+        assert len(items) == 1
+        device_id = items[0]["id"]
+
+        # Revoke it.
+        r = client.delete(f"/api/auth/me/devices/{device_id}")
+        assert r.status_code == 200, r.text
+
+        # List is empty.
+        r = client.get("/api/auth/me/devices")
+        assert r.json()["items"] == []
+
+        # The row in the table has revoked_at populated.
+        row = db.conn().execute(
+            "SELECT revoked_at FROM device_trust WHERE id = ?", (device_id,)
+        ).fetchone()
+        assert row["revoked_at"] is not None
+
+
+def test_revoke_other_users_device_reads_404(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+    from app import db
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app, base_url=HTTPS_BASE) as client:
+        _reset_outbound()
+        # Alice trusts a device.
+        _sign_in_via_otc(client, "alice@example.com", trust_device=True)
+        alice_device_id = client.get("/api/auth/me/devices").json()["items"][0]["id"]
+
+        # Bob signs in (without a trusted device of his own).
+        client.cookies.clear()
+        db.conn().execute("UPDATE otc_codes SET consumed_at = datetime('now', '-1 hour'), created_at = datetime('now', '-1 hour')")
+        _sign_in_via_otc(client, "bob@example.com", trust_device=False)
+
+        # Bob tries to revoke Alice's row by id.
+        r = client.delete(f"/api/auth/me/devices/{alice_device_id}")
+        assert r.status_code == 404
+
+        # Alice's row is still active.
+        row = db.conn().execute(
+            "SELECT revoked_at FROM device_trust WHERE id = ?", (alice_device_id,)
+        ).fetchone()
+        assert row["revoked_at"] is None
+
+
+def test_revoke_all_devices_kills_every_active_row(app_with_fake_gitea):
+    from fastapi.testclient import TestClient
+    from app import db
+
+    app, _fake = app_with_fake_gitea
+    with TestClient(app, base_url=HTTPS_BASE) as client:
+        _reset_outbound()
+        _sign_in_via_otc(client, "alice@example.com", trust_device=True)
+
+        # Add a second device.
+        db.conn().execute("UPDATE otc_codes SET consumed_at = datetime('now', '-1 hour'), created_at = datetime('now', '-1 hour')")
+        r = client.post("/auth/otc/request", json={"email": "alice@example.com"})
+        assert r.status_code == 200, r.text
+        code = _outbound_otc_codes("alice@example.com")[-1]
+        r = client.post(
+            "/auth/otc/verify",
+            json={"email": "alice@example.com", "code": code, "trust_device": True},
+        )
+        assert r.status_code == 200, r.text
+
+        # Two active rows.
+        assert len(client.get("/api/auth/me/devices").json()["items"]) == 2
+
+        # Revoke all.
+        r = client.delete("/api/auth/me/devices")
+        assert r.status_code == 200, r.text
+        assert r.json()["revoked"] == 2
+
+        # List is empty.
+        assert client.get("/api/auth/me/devices").json()["items"] == []

frontend/package-lock.json

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

frontend/src/App.css

@@ -455,6 +455,65 @@
 .otc-fallback a:hover { color: #1a1a1a; text-decoration: underline; }
 .otc-fallback-sep { color: #ccc; }
 
+/* v0.11.0 — "trust this device for 30 days" checkbox on the verify
+   step. Sits above the action row, padded so it doesn't crowd the
+   passcode/code input. */
+.otc-trust-device {
+  display: flex; align-items: center; gap: 8px;
+  font-size: 13px; color: #444;
+  margin: 8px 0 4px;
+  cursor: pointer;
+  user-select: none;
+}
+.otc-trust-device input[type="checkbox"] {
+  width: auto; margin: 0; cursor: pointer;
+}
+
+/* v0.11.0 — /settings/devices revoke-device UI. */
+.device-list {
+  list-style: none; padding: 0; margin: 12px 0 0;
+}
+.device-list-item {
+  display: flex; align-items: center; justify-content: space-between;
+  gap: 12px;
+  border: 1px solid #eee; border-radius: 6px;
+  padding: 10px 12px; margin: 0 0 8px;
+  background: #fafafa;
+}
+.device-list-item .device-meta {
+  flex: 1; min-width: 0;
+}
+.device-list-item .device-ua {
+  font-size: 13px; color: #1a1a1a;
+  white-space: nowrap; overflow: hidden; text-overflow: ellipsis;
+}
+.device-list-item .device-stamps {
+  font-size: 12px; color: #777;
+  margin-top: 2px;
+}
+.device-list-item button {
+  font-size: 12px; padding: 4px 10px;
+  border: 1px solid #ccc; border-radius: 4px;
+  background: white; cursor: pointer;
+}
+.device-list-item button:hover:not(:disabled) {
+  background: #f5f5f5;
+}
+.device-revoke-all {
+  margin-top: 8px;
+  font-size: 13px; padding: 6px 12px;
+  border: 1px solid #cb6a6a; border-radius: 4px;
+  background: white; color: #cb6a6a; cursor: pointer;
+}
+.device-revoke-all:hover:not(:disabled) {
+  background: #fff5f5;
+}
+.device-empty {
+  font-size: 13px; color: #777;
+  background: #fafafa; border: 1px solid #eee; border-radius: 6px;
+  padding: 12px;
+}
+
 /* --- Beta-pending page (post-OAuth-rejection) --- */
 
 .beta-pending {
@@ -1889,54 +1948,6 @@
   display: inline-flex; align-items: center; gap: 6px;
   font-size: 13px; cursor: pointer;
 }
-
-/* v0.9.0 — admin user-management surface (roadmap item #7). */
-.admin-filter-chips {
-  display: flex; gap: 6px; margin-bottom: 16px; flex-wrap: wrap;
-}
-.admin-chip {
-  display: inline-flex; align-items: center; gap: 6px;
-  background: #fff; border: 1px solid #d1d5db; border-radius: 999px;
-  padding: 4px 12px; font-size: 12px; color: #374151; cursor: pointer;
-}
-.admin-chip:hover { background: #f9fafb; }
-.admin-chip.active {
-  background: #111; color: #fff; border-color: #111;
-}
-.admin-chip-count {
-  font-size: 11px; opacity: 0.7;
-}
-.admin-users-table td { vertical-align: top; padding-top: 10px; padding-bottom: 10px; }
-.permission-cell { display: flex; flex-direction: column; gap: 4px; }
-.permission-actions { display: flex; gap: 6px; }
-.permission-badge {
-  display: inline-block;
-  font-size: 11px; font-weight: 600;
-  padding: 2px 8px; border-radius: 999px;
-  text-transform: uppercase; letter-spacing: 0.04em;
-  width: max-content;
-}
-.permission-badge-pending {
-  background: #fef3c7; color: #92400e;
-}
-.permission-badge-granted {
-  background: #dcfce7; color: #166534;
-}
-.permission-badge-revoked {
-  background: #fee2e2; color: #991b1b;
-}
-.permission-decided { font-size: 11px; }
-.user-row-reason td {
-  background: #fffbeb; border-top: none !important;
-  padding: 0 16px 12px !important;
-}
-.user-reason-block {
-  border-left: 3px solid #f59e0b;
-  padding: 8px 12px; font-size: 13px;
-  background: #fffbeb;
-}
-.user-reason-block strong { display: block; margin-bottom: 4px; color: #92400e; }
-.user-reason-block p { margin: 0; white-space: pre-wrap; color: #374151; }
 .grad-queue { list-style: none; padding: 0; margin: 8px 0 24px; }
 .grad-queue li { padding: 8px 0; border-bottom: 1px solid #f3f4f6; }
 .grad-queue-link { color: #111; text-decoration: none; font-size: 14px; }

frontend/src/api.js

@@ -40,11 +40,16 @@ export async function requestOtc(email) {
   return jsonOrThrow(res)
 }
 
-export async function verifyOtc(email, code) {
+export async function verifyOtc(email, code, { trustDevice = false } = {}) {
+  // v0.11.0 — `trustDevice` is the "trust this device for 30 days"
+  // checkbox on the Login.jsx OTC step. When true, the server mints
+  // a fresh device-trust row and sets the long-lived cookie; on
+  // subsequent visits, the cookie skips the OTC roundtrip via
+  // `startDeviceTrust()`.
   const res = await fetch('/auth/otc/verify', {
     method: 'POST',
     headers: { 'Content-Type': 'application/json' },
-    body: JSON.stringify({ email, code }),
+    body: JSON.stringify({ email, code, trust_device: !!trustDevice }),
   })
   return jsonOrThrow(res)
 }
@@ -82,15 +87,44 @@ export async function checkPasscode(email) {
   return jsonOrThrow(res)
 }
 
-export async function verifyPasscode(email, passcode) {
+export async function verifyPasscode(email, passcode, { trustDevice = false } = {}) {
+  // v0.11.0 — same trust-device opt-in as `verifyOtc`.
   const res = await fetch('/auth/passcode/verify', {
     method: 'POST',
     headers: { 'Content-Type': 'application/json' },
-    body: JSON.stringify({ email, passcode }),
+    body: JSON.stringify({ email, passcode, trust_device: !!trustDevice }),
   })
   return jsonOrThrow(res)
 }
 
+// ── v0.11.0: trust device for 30 days (§6.2, roadmap item #9) ─────────────
+//
+// On a returning visit with a valid device-trust cookie, `startDeviceTrust`
+// re-establishes the session without an OTC / passcode roundtrip. The
+// cookie is HttpOnly so the client cannot read it; the call is a pure POST
+// that the browser attaches the cookie to automatically.
+//
+// `listMyDevices`, `revokeMyDevice`, and `revokeAllMyDevices` drive the
+// /settings/devices revoke-device UI. The signed-in user is the implicit
+// subject; the cookie carries the session.
+
+export async function startDeviceTrust() {
+  const res = await fetch('/auth/device-trust/start', { method: 'POST' })
+  return jsonOrThrow(res)
+}
+
+export async function listMyDevices() {
+  return jsonOrThrow(await fetch('/api/auth/me/devices'))
+}
+
+export async function revokeMyDevice(deviceId) {
+  return jsonOrThrow(await fetch(`/api/auth/me/devices/${deviceId}`, { method: 'DELETE' }))
+}
+
+export async function revokeAllMyDevices() {
+  return jsonOrThrow(await fetch('/api/auth/me/devices', { method: 'DELETE' }))
+}
+
 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
@@ -661,19 +695,6 @@ export async function setUserMute(userId, muted) {
   }))
 }
 
-// v0.9.0 — roadmap item #7. Flip a user's permission_state between
-// 'pending', 'granted', and 'revoked'. The Users tab on the admin
-// page wires Grant / Revoke buttons against this endpoint; the
-// returned `changed` flag is false when the requested state already
-// matched the row.
-export async function setUserPermission(userId, state) {
-  return jsonOrThrow(await fetch(`/api/admin/users/${userId}/permission`, {
-    method: 'POST',
-    headers: { 'Content-Type': 'application/json' },
-    body: JSON.stringify({ state }),
-  }))
-}
-
 export async function listAuditLog({ actionKind, actorUserId, rfcSlug, beforeId, limit } = {}) {
   const params = new URLSearchParams()
   if (actionKind) params.set('action_kind', actionKind)

frontend/src/components/Admin.jsx

@@ -16,7 +16,6 @@ import {
   listAdminUsers,
   setUserRole,
   setUserMute,
-  setUserPermission,
   listAuditLog,
   listPermissionEvents,
   listGraduationQueue,
@@ -69,26 +68,12 @@ export default function Admin({ viewer }) {
   )
 }
 
-// ── Users + role + write-mute + permission grant/revoke (§6.1 / §6.2) ──────
-//
-// v0.9.0 (roadmap item #7) lands the user-management surface. The table
-// shows every user with their permission_state, sign-up reason (when
-// pending), role, write-mute, and Grant / Revoke controls. State filter
-// chips above the table narrow to one bucket — the "Pending" chip is the
-// admin's daily inbox shape.
-
-const STATE_CHIPS = [
-  { value: 'all', label: 'All' },
-  { value: 'pending', label: 'Pending' },
-  { value: 'granted', label: 'Granted' },
-  { value: 'revoked', label: 'Revoked' },
-]
+// ── Users + role + write-mute (§6.1 / §6.2) ────────────────────────────────
 
 function UsersTab() {
   const [users, setUsers] = useState(null)
   const [busy, setBusy] = useState({})
   const [error, setError] = useState(null)
-  const [stateFilter, setStateFilter] = useState('all')
 
   async function refresh() {
     setError(null)
@@ -128,193 +113,68 @@ function UsersTab() {
     }
   }
 
-  async function flipPermission(userId, state) {
-    setBusy(b => ({ ...b, [userId]: true }))
-    setError(null)
-    try {
-      await setUserPermission(userId, state)
-      // Refresh the full row so permission_decided_{at,by_*} update too.
-      await refresh()
-    } catch (e) {
-      setError(e.message)
-    } finally {
-      setBusy(b => ({ ...b, [userId]: false }))
-    }
-  }
-
-  const counts = useMemo(() => {
-    const c = { all: 0, pending: 0, granted: 0, revoked: 0 }
-    if (users) {
-      c.all = users.length
-      for (const u of users) {
-        const s = u.permission_state || 'granted'
-        if (s in c) c[s] += 1
-      }
-    }
-    return c
-  }, [users])
-
   if (users == null) return <p className="muted">Loading users…</p>
 
-  const filtered = stateFilter === 'all'
-    ? users
-    : users.filter(u => (u.permission_state || 'granted') === stateFilter)
-
   return (
     <div className="admin-tab">
       <header className="admin-tab-header">
         <h2>Users</h2>
         <p className="muted">
-          The pending bucket is the beta-access review queue (§6.1 /
-          v0.8.0). Grant or revoke writes to <code>permission_events</code>
-          and stamps <code>permission_decided_by</code> +{' '}
-          <code>permission_decided_at</code>. Role and write-mute controls
-          retain their v0.7.0 semantics — promote to admin to remove a
-          user's ability to write without silencing them.
+          Role changes write to <code>permission_events</code>. The §6.2
+          write-mute applies to contributors only — promote to admin to
+          remove a user's ability to write without silencing them.
         </p>
       </header>
       {error && <p className="settings-note warning">{error}</p>}
-
-      <div className="admin-filter-chips">
-        {STATE_CHIPS.map(chip => (
-          <button
-            key={chip.value}
-            type="button"
-            className={`admin-chip${stateFilter === chip.value ? ' active' : ''}`}
-            onClick={() => setStateFilter(chip.value)}
-          >
-            {chip.label} <span className="admin-chip-count">{counts[chip.value] ?? 0}</span>
-          </button>
-        ))}
-      </div>
-
-      {filtered.length === 0 ? (
-        <p className="muted">No users in this bucket.</p>
-      ) : (
-        <table className="admin-table admin-users-table">
-          <thead>
-            <tr>
-              <th>User</th>
-              <th>State</th>
-              <th>Role</th>
-              <th>Write-muted</th>
-              <th>Signed up</th>
-              <th>Last seen</th>
+      <table className="admin-table">
+        <thead>
+          <tr>
+            <th>User</th>
+            <th>Role</th>
+            <th>Write-muted</th>
+            <th>Last seen</th>
+          </tr>
+        </thead>
+        <tbody>
+          {users.map(u => (
+            <tr key={u.id}>
+              <td>
+                <div className="user-cell">
+                  <span className="user-handle">@{u.gitea_login}</span>
+                  <span className="muted">{u.display_name}</span>
+                </div>
+              </td>
+              <td>
+                <select
+                  value={u.role}
+                  onChange={e => changeRole(u.id, e.target.value)}
+                  disabled={!!busy[u.id]}
+                >
+                  <option value="contributor">Contributor</option>
+                  <option value="admin">Admin</option>
+                  <option value="owner">Owner</option>
+                </select>
+              </td>
+              <td>
+                {u.role === 'contributor' ? (
+                  <label className="mute-toggle">
+                    <input
+                      type="checkbox"
+                      checked={!!u.muted}
+                      onChange={e => toggleMute(u.id, e.target.checked)}
+                      disabled={!!busy[u.id]}
+                    />
+                    {u.muted ? 'Muted' : 'Active'}
+                  </label>
+                ) : (
+                  <span className="muted">N/A</span>
+                )}
+              </td>
+              <td className="muted">{u.last_seen_at}</td>
             </tr>
-          </thead>
-          <tbody>
-            {filtered.map(u => (
-              <UserRow
-                key={u.id}
-                user={u}
-                busy={!!busy[u.id]}
-                onChangeRole={role => changeRole(u.id, role)}
-                onToggleMute={muted => toggleMute(u.id, muted)}
-                onFlipPermission={state => flipPermission(u.id, state)}
-              />
-            ))}
-          </tbody>
-        </table>
-      )}
-    </div>
-  )
-}
-
-function UserRow({ user: u, busy, onChangeRole, onToggleMute, onFlipPermission }) {
-  const state = u.permission_state || 'granted'
-  const fullName = [u.first_name, u.last_name].filter(Boolean).join(' ').trim()
-  const handle = u.gitea_login ? `@${u.gitea_login}` : (u.email || u.display_name)
-  return (
-    <>
-      <tr>
-        <td>
-          <div className="user-cell">
-            <span className="user-handle">{handle}</span>
-            <span className="muted">
-              {fullName || u.display_name}
-              {u.email ? ` · ${u.email}` : ''}
-            </span>
-          </div>
-        </td>
-        <td>
-          <PermissionCell user={u} busy={busy} onFlipPermission={onFlipPermission} />
-        </td>
-        <td>
-          <select
-            value={u.role}
-            onChange={e => onChangeRole(e.target.value)}
-            disabled={busy}
-          >
-            <option value="contributor">Contributor</option>
-            <option value="admin">Admin</option>
-            <option value="owner">Owner</option>
-          </select>
-        </td>
-        <td>
-          {u.role === 'contributor' ? (
-            <label className="mute-toggle">
-              <input
-                type="checkbox"
-                checked={!!u.muted}
-                onChange={e => onToggleMute(e.target.checked)}
-                disabled={busy}
-              />
-              {u.muted ? 'Muted' : 'Active'}
-            </label>
-          ) : (
-            <span className="muted">N/A</span>
-          )}
-        </td>
-        <td className="muted">{u.created_at || '—'}</td>
-        <td className="muted">{u.last_seen_at || '—'}</td>
-      </tr>
-      {state === 'pending' && u.beta_request_reason ? (
-        <tr className="user-row-reason">
-          <td colSpan={6}>
-            <div className="user-reason-block">
-              <strong>Why they want access:</strong>
-              <p>{u.beta_request_reason}</p>
-            </div>
-          </td>
-        </tr>
-      ) : null}
-    </>
-  )
-}
-
-function PermissionCell({ user: u, busy, onFlipPermission }) {
-  const state = u.permission_state || 'granted'
-  const decidedSuffix = u.permission_decided_at
-    ? ` · by ${u.permission_decided_by_login ? '@' + u.permission_decided_by_login : '—'} at ${u.permission_decided_at}`
-    : ''
-  return (
-    <div className="permission-cell">
-      <span className={`permission-badge permission-badge-${state}`}>{state}</span>
-      <div className="permission-actions">
-        {state !== 'granted' && (
-          <button
-            type="button"
-            className="btn-link-quiet"
-            disabled={busy}
-            onClick={() => onFlipPermission('granted')}
-          >Grant</button>
-        )}
-        {state === 'granted' && (
-          <button
-            type="button"
-            className="btn-link-quiet"
-            disabled={busy}
-            onClick={() => {
-              if (confirm(`Revoke access for ${u.display_name || u.email}?`)) {
-                onFlipPermission('revoked')
-              }
-            }}
-          >Revoke</button>
-        )}
-      </div>
-      {decidedSuffix && (
-        <div className="permission-decided muted">{decidedSuffix.replace(/^ · /, '')}</div>
-      )}
+          ))}
+        </tbody>
+      </table>
     </div>
   )
 }

frontend/src/components/BetaPending.jsx

@@ -27,11 +27,8 @@ export default function BetaPending({ viewer }) {
         {isPending ? (
           <>
             <p>
-              Thanks for telling us a bit about yourself. The deployment's
-              admins are notified by email as soon as a request lands;
-              we don't commit to a fixed SLA — turnaround depends on
-              operator availability — and the deployment operator is
-              the right person to ask if a wait runs long.
+              Thanks for telling us a bit about yourself. An admin will
+              review your request and get back to you as soon as we can.
             </p>
             <p>
               While you wait, the catalog on the left lists every super-draft

frontend/src/components/Login.jsx

@@ -72,6 +72,7 @@ import {
   checkPasscode,
   verifyPasscode,
   setPasscode as apiSetPasscode,
+  startDeviceTrust,
 } from '../api'
 
 export default function Login() {
@@ -84,6 +85,13 @@ export default function Login() {
   const [code, setCode] = useState('')
   const [passcode, setPasscode] = useState('')
   const [newPasscode, setNewPasscode] = useState('')
+  // v0.11.0 — "trust this device for 30 days" checkbox, shared by the
+  // OTC and passcode verify steps. The flag rides on the verify POST;
+  // a checked box mints a device-trust row server-side and sets the
+  // long-lived `rfc_device_trust` cookie. Defaults off so the user
+  // makes an explicit choice — auth credentials shouldn't persist by
+  // default.
+  const [trustDevice, setTrustDevice] = useState(false)
   // v0.8.0 — capture-profile fields.
   const [firstName, setFirstName] = useState('')
   const [lastName, setLastName] = useState('')
@@ -105,6 +113,28 @@ export default function Login() {
     else if (step === 'set-passcode') newPasscodeRef.current?.focus()
   }, [step])
 
+  // v0.11.0 — on mount, try the device-trust cookie path. If the
+  // browser still carries a valid `rfc_device_trust` cookie from a
+  // prior "trust this device" gesture, the server re-establishes the
+  // session without any user input and we redirect home. The cookie
+  // is HttpOnly so we can't peek at it; we just call the endpoint and
+  // see whether it returns 200. 401 (no cookie / invalid / revoked)
+  // is the structural-silent case — the user proceeds to the email
+  // step normally. We do not surface any UI about the attempt; a
+  // failure should be invisible.
+  useEffect(() => {
+    let cancelled = false
+    ;(async () => {
+      try {
+        await startDeviceTrust()
+        if (!cancelled) window.location.assign('/')
+      } catch (_) {
+        // No trusted device — fall through to the email step.
+      }
+    })()
+    return () => { cancelled = true }
+  }, [])
+
   async function submitEmail(e) {
     e.preventDefault()
     if (!email.trim() || !email.includes('@')) {
@@ -143,7 +173,7 @@ export default function Login() {
     setBusy(true)
     setStatus('')
     try {
-      await verifyPasscode(email.trim(), passcode.trim())
+      await verifyPasscode(email.trim(), passcode.trim(), { trustDevice })
       // Reload so App.jsx's getMe() picks up the fresh session. A
       // returning passcode user is by definition already past the
       // §6.1 capture step (they couldn't have set a passcode while
@@ -189,7 +219,7 @@ export default function Login() {
     setBusy(true)
     setStatus('')
     try {
-      await verifyOtc(email.trim(), code.trim())
+      await verifyOtc(email.trim(), code.trim(), { trustDevice })
       // OTC verified — the server has signed in the user. Fetch the
       // canonical /api/auth/me to decide where to land:
       //   * needs_profile  → §6.1 capture (then /beta-pending).
@@ -378,6 +408,19 @@ export default function Login() {
               required
               disabled={busy}
             />
+            {/* v0.11.0 — trust device for 30 days. The checkbox lives
+                on the verify step so the user makes the trust gesture
+                in the same breath as signing in. Off by default; the
+                user opts in deliberately. */}
+            <label className="otc-trust-device">
+              <input
+                type="checkbox"
+                checked={trustDevice}
+                onChange={e => setTrustDevice(e.target.checked)}
+                disabled={busy}
+              />
+              <span>Trust this device for 30 days</span>
+            </label>
             <div className="otc-actions">
               <button type="submit" disabled={busy || !passcode.trim()}>
                 {busy ? 'Signing in…' : 'Sign in'}
@@ -420,6 +463,17 @@ export default function Login() {
               required
               disabled={busy}
             />
+            {/* v0.11.0 — trust device for 30 days. Same shape as the
+                passcode step; the user opts in deliberately. */}
+            <label className="otc-trust-device">
+              <input
+                type="checkbox"
+                checked={trustDevice}
+                onChange={e => setTrustDevice(e.target.checked)}
+                disabled={busy}
+              />
+              <span>Trust this device for 30 days</span>
+            </label>
             <div className="otc-actions">
               <button type="submit" disabled={busy || code.length !== 6}>
                 {busy ? 'Signing in…' : 'Sign in'}

frontend/src/components/NotificationSettings.jsx

@@ -32,6 +32,9 @@ import {
   getMe,
   setPasscode,
   clearPasscode,
+  listMyDevices,
+  revokeMyDevice,
+  revokeAllMyDevices,
 } from '../api.js'
 import { getConsent, onConsentChange, hydrateFromServer } from '../lib/consent.js'
 
@@ -54,11 +57,126 @@ export default function NotificationSettings({ viewer }) {
       <WatchesSection />
       <MutesSection viewer={viewer} />
       <SignInSection />
+      <DevicesSection />
       <PrivacyCookiesSection />
     </div>
   )
 }
 
+// ── v0.11.0: trusted devices (§6.2, roadmap item #9) ──────────────────────
+//
+// Lists the user's active device-trust rows and lets them revoke any
+// or all. A revoke marks the row dead server-side; the matching
+// device's next visit will be refused and the cookie cleared. The
+// surface intentionally does not single out the row whose cookie the
+// current request carries — every row reads identically, so the user
+// can revoke "this device" alongside any other from a single page.
+
+function DevicesSection() {
+  const [devices, setDevices] = useState(null)
+  const [error, setError] = useState(null)
+  const [busy, setBusy] = useState(false)
+
+  useEffect(() => {
+    refresh()
+  }, [])
+
+  async function refresh() {
+    try {
+      const { items } = await listMyDevices()
+      setDevices(items || [])
+      setError(null)
+    } catch (e) {
+      setError(e.message || 'Could not load trusted devices.')
+    }
+  }
+
+  async function onRevoke(deviceId) {
+    setBusy(true)
+    try {
+      await revokeMyDevice(deviceId)
+      await refresh()
+    } catch (e) {
+      setError(e.message || 'Could not revoke device.')
+    } finally {
+      setBusy(false)
+    }
+  }
+
+  async function onRevokeAll() {
+    if (!confirm('Revoke trust on every device, including this one? You will be asked to sign in via email next time.')) {
+      return
+    }
+    setBusy(true)
+    try {
+      await revokeAllMyDevices()
+      await refresh()
+    } catch (e) {
+      setError(e.message || 'Could not revoke devices.')
+    } finally {
+      setBusy(false)
+    }
+  }
+
+  return (
+    <SectionShell
+      title="Trusted devices"
+      subtitle="Devices where you've checked “Trust this device for 30 days.” Sign-in is automatic on these devices until the trust expires or you revoke it."
+    >
+      {devices === null && <p className="settings-note">Loading…</p>}
+      {devices !== null && devices.length === 0 && (
+        <p className="device-empty">
+          No trusted devices. Sign in and check “Trust this device for 30 days”
+          to add the device you're on now.
+        </p>
+      )}
+      {devices !== null && devices.length > 0 && (
+        <>
+          <ul className="device-list">
+            {devices.map(d => (
+              <li key={d.id} className="device-list-item">
+                <div className="device-meta">
+                  <div className="device-ua">{d.user_agent || 'Unknown device'}</div>
+                  <div className="device-stamps">
+                    Trusted {formatStamp(d.created_at)} · last seen {formatStamp(d.last_seen_at)} · expires {formatStamp(d.expires_at)}
+                  </div>
+                </div>
+                <button
+                  type="button"
+                  onClick={() => onRevoke(d.id)}
+                  disabled={busy}
+                  title="Revoke trust on this device"
+                >
+                  Revoke
+                </button>
+              </li>
+            ))}
+          </ul>
+          <button
+            type="button"
+            className="device-revoke-all"
+            onClick={onRevokeAll}
+            disabled={busy}
+          >
+            Revoke all devices
+          </button>
+        </>
+      )}
+      {error && <p className="settings-note warning">{error}</p>}
+    </SectionShell>
+  )
+}
+
+function formatStamp(stamp) {
+  // The server emits SQLite `datetime('now')` strings (UTC, no
+  // timezone marker). Parse defensively; fall back to the raw stamp
+  // if Date can't make sense of it.
+  if (!stamp) return '—'
+  const d = new Date(stamp.replace(' ', 'T') + 'Z')
+  if (Number.isNaN(d.getTime())) return stamp
+  return d.toLocaleString()
+}
+
 // ── §6.2 sign-in (v0.10.0 / roadmap item #8): passcode management ──────────
 
 function SignInSection() {