fix: unify staging admin access

docs/BUG_HISTORY.md

@@ -1581,7 +1581,7 @@
 
 ## BUG-087 | self-hosted staging 管理员看不到独立后台入口
 
-- 状态：resolved
+- 状态：superseded by BUG-092
 - 首次发现：2026-07-29
 - 最近更新：2026-07-29
 - 影响面：self-hosted staging 账户菜单、`GET /api/account`、独立后台入口；不影响后台独立登录与 `requireAdminSession`
@@ -1591,6 +1591,23 @@
 - 修复：self-hosted 分支通过现有 `ADMIN_DATABASE_URL` 管理只读连接查询当前用户的 `identity.users.role`，仅 `admin` 或 `viewer` 可见入口，且不使用 `ADMIN_EMAILS` 替代角色授权；`GET /api/account` 在服务端解析身份配置并返回 `AUTH_ADMIN_ORIGIN + /admin/codes`，Supabase 模式继续返回 `/admin/codes`；账户与侧栏类型透传该 URL，并将文案改为“后台管理”。后台独立登录和 `requireAdminSession` 保持不变。
 - 验证：`frontend/tests/admin-contracts.test.ts`、`frontend/tests/admin-users-contract.test.ts`、`frontend/tests/account-api.test.ts`、`frontend/tests/sidebar-contract.test.ts` 锁定持久化角色、独立后台 URL、服务端环境边界和后台写权限门禁；目标 TypeScript、构建与 staging 登录态 smoke 结果另行记录。
 - 防复发：self-hosted 主站入口发现必须以 `identity.users.role` 为授权事实，不能退回邮箱 allowlist；客户端不得读取后台 origin 环境变量或硬编码主站 `/admin` 路径；后台 API 必须继续独立执行 `requireAdminSession`，入口可见性不得被当作授权。
-- 相关记录：BUG-010、BUG-083、BUG-084
+- 相关记录：BUG-010、BUG-083、BUG-084、BUG-092
 - 复发自：BUG-010
-- 修复版本：待提交（本地可测）
+- 修复版本：已由 BUG-092 的同域单会话架构取代
+
+## BUG-092 | self-hosted staging 双域后台与主站会话模型冲突
+
+- 状态：resolved
+- 首次发现：2026-07-29
+- 最近更新：2026-07-29
+- 影响面：staging Better Auth 配置、后台页面与 API、登录、账户入口、Caddy、部署校验和 smoke；生产配置不变。
+- 用户现象：管理员需要第二套后台域名和浏览器会话才能进入后台，主站登录态不能直接使用；`viewer` 还被当作后台只读角色，与仅数据库 `admin` 可进入的产品合同冲突。
+- 触发条件：self-hosted staging 同时配置用户与后台 origin/secret、Caddy 拆分两个站点，并按 Host 选择 Better Auth 实例。
+- 根因：早期隔离设计把后台浏览器 surface 当成第二套身份系统，导致入口发现、登录、Cookie、部署变量和授权策略重复；同时把入口可见性与 API 权限错误扩展到 `viewer`。
+- 架构决策：后台复用主站 Better Auth user session；`identity.users.role` 的持久化 `admin` 是唯一后台授权事实。Better Auth 插件的 `/api/auth/admin` endpoint 继续在主站 fail-closed `404`，未知 Host 继续 `421`。
+- 修复：删除活动运行时后台 origin/secret 与 `services.admin`，服务端数据 client 和 `requireAdminSession` 统一读取 user session；后台 layout 增加服务端 gate，匿名转 `/login`、非 admin 不渲染；所有后台 API 保留独立 guard，payments/packages 改用 `requireAdminSession`；`isAdminUser`、账户入口和 Refine policy 收敛为 admin-only；登录取消 Host 分流；staging Caddy、Compose、环境校验、部署脚本、工作流和 smoke 收敛为同域。
+- 验证：身份 config/host/auth、admin policy/contracts、account/sidebar/login、部署/工作流与 admin layout/API guard 合同更新；针对性测试、TypeScript、Next build 与 `git diff --check` 结果记录在本次交付报告。生产部署未执行。
+- 防复发：活动运行配置和测试不得重新引入独立后台域名、`AUTH_ADMIN_ORIGIN`、`BETTER_AUTH_ADMIN_SECRET` 或浏览器 admin auth service；`viewer` 对后台入口、页面、读 API 和写 API 均必须为 `403`；入口可见性不能替代 route guard。
+- 相关记录：BUG-010、BUG-083、BUG-084、BUG-087
+- 复发自：BUG-087
+- 修复版本：本地实现，待 staging 验收

docs/operations/self-hosted-identity.md

@@ -4,29 +4,27 @@ Staging uses Better Auth and the private local PostgreSQL cluster for both ident
 
 ## Staging mode
 
-Keep these two values exactly as shown:
+Keep these values exactly as shown:
 
 ```dotenv
 AUTH_PROVIDER=self-hosted
 SELF_HOSTED_IDENTITY_ENABLED=true
+AUTH_USER_ORIGIN=https://staging.jyotisha.chat
 ```
 
-This makes both login hosts use isolated Better Auth surfaces. Public and admin sessions have different secrets and host-only cookie prefixes. Server routes translate the Better Auth session into PostgreSQL request claims and use the reviewed existing RLS/RPC business contract. The browser uses only same-origin APIs and does not need Supabase configuration.
+Staging has one browser identity surface on the main site. The same Better Auth user session serves ordinary pages and `/admin`; there is no independent admin origin, secret, cookie, or login host. Server routes translate that session into PostgreSQL request claims. Admin authorization then reads the persisted `identity.users.role` value and permits only `admin`; `viewer` and ordinary users receive `403`. The main auth route continues to return `404` for Better Auth `/api/auth/admin` plugin endpoints, and unknown hosts fail closed with `421`.
 
 Use [the tracked staging identity example](../../deploy/.env.staging.identity.example) as a list of names only. Replace bracketed values directly on the server and keep `/opt/jyotisha-staging/.env.staging` owned by `deploy` with mode `0600`.
 
-Generate separate secrets locally on the server:
+Generate `BETTER_AUTH_USER_SECRET` locally on the server:
 
 ```bash
 openssl rand -base64 32
-openssl rand -base64 32
 ```
 
-Do not reuse either value as a PostgreSQL password. `IDENTITY_DATABASE_URL`, `APP_DATABASE_URL`, and `ADMIN_DATABASE_URL` use their matching passwords from `.env.staging.database`, percent-encoded only in each URL password component. All three must point to the private Compose hostname `postgres:5432/jyotisha`; never publish PostgreSQL on a host port.
+Do not reuse it as a PostgreSQL password. `IDENTITY_DATABASE_URL`, `APP_DATABASE_URL`, and `ADMIN_DATABASE_URL` use their matching passwords from `.env.staging.database`, percent-encoded only in each URL password component. All three must point to the private Compose hostname `postgres:5432/jyotisha`; never publish PostgreSQL on a host port.
 
-The Resend key must be staging-only. `RESEND_FROM_EMAIL` must use a sender/domain verified in Resend. CI never receives this key and uses an in-memory sender.
-
-Set `ADMIN_EMAILS` to the staging administrator allowlist. Generate an independent `JYOTISH_DYNAMIC_RECTIFICATION_TOKEN` and place the same value in the shared application env consumed by the web and private API containers; do not reuse a database or Better Auth secret.
+The Resend key must be staging-only. `RESEND_FROM_EMAIL` must use a sender/domain verified in Resend. CI never receives this key and uses an in-memory sender. `ADMIN_EMAILS` remains relevant only to the legacy Supabase production path; it is not self-hosted admin authorization.
 
 Validate without printing values:
 
@@ -38,17 +36,17 @@ bash deploy/validate-staging-env.sh .env.staging
 
 ## Migration and smoke checks
 
-Apply the reviewed PostgreSQL migrations through the existing `Migrate Staging Database` workflow before deploying the web image. The workflow first ensures the compatibility roles exist, then applies the identity schema, the local `auth` compatibility layer, and all reviewed business migrations under the migration ledger. Better Auth users are transactionally projected into `auth.users`, which creates their business profile through the existing trigger.
+Apply the reviewed PostgreSQL migrations through the existing `Migrate Staging Database` workflow before deploying the web image. Better Auth users are transactionally projected into `auth.users`, which creates their business profile through the existing trigger.
 
-After deployment:
+After deployment, verify the single-domain contract:
 
 ```bash
-curl -fsS https://admin.staging.jyotisha.chat/login >/dev/null
-curl -fsS https://admin.staging.jyotisha.chat/api/auth/get-session
-test "$(curl -sS -o /dev/null -w '%{http_code}' https://staging.jyotisha.chat/admin/codes)" = 404
+curl -fsS https://staging.jyotisha.chat/login >/dev/null
+test "$(curl -sS -o /dev/null -w '%{http_code}' https://staging.jyotisha.chat/api/admin/session)" = 401
+test "$(curl -sS -o /dev/null -w '%{http_code}' https://staging.jyotisha.chat/api/account)" = 401
 ```
 
-The admin root redirects to `/admin/codes`; the public host rejects `/admin` and `/api/admin` paths. An unknown or unpromoted email cannot create an admin session. Promote an imported staging user only through a reviewed database/admin operation; the persisted `identity.users.role` value must include `admin` before the admin OTP flow can issue a cookie.
+An anonymous `/admin` request redirects to `/login`. An authenticated non-admin, including a persisted `viewer`, must not render the admin layout and every `/api/admin/*` route must independently return `403`. Promote a staging user only through a reviewed database operation; the persisted role must include `admin` before the main-site session can enter the backend.
 
 ## Optional import rehearsal
 
@@ -75,8 +73,8 @@ Reruns are idempotent by UUID and the whole import is transactional. Duplicate c
 
 ## Rollback and rotation
 
-An application rollback must use a previously validated staging image and does not reverse database migrations. Existing self-hosted sessions and data remain in PostgreSQL; do not delete identity or business rows during application rollback. Returning staging to Supabase would require a separate reviewed data-reconciliation and provider-switch change, not an environment-only toggle.
+An application rollback must use a previously validated staging image and does not reverse database migrations. Existing self-hosted sessions and data remain in PostgreSQL; do not delete identity or business rows during application rollback. Returning staging to Supabase requires a separate reviewed data-reconciliation and provider-switch change.
 
-Rotating either Better Auth secret invalidates only that surface's existing sessions. Rotate user and admin secrets separately, restart the web service, and verify the corresponding host. Rotate a leaked Resend key in Resend first, replace the server value, then restart. Never print the old or new values.
+Rotating `BETTER_AUTH_USER_SECRET` invalidates all self-hosted browser sessions, including admins. Restart the web service and verify login, anonymous admin API rejection, admin access, and viewer rejection. Rotate a leaked Resend key in Resend first, replace the server value, then restart. Never print old or new values.
 
 Production `AUTH_PROVIDER=self-hosted` remains blocked until data reconciliation passes, production backups and restore drills exist, operational monitoring is ready, and a separate reviewed production cutover plan is approved.

docs/superpowers/plans/2026-07-21-self-hosted-identity.md

@@ -1,3 +1,5 @@
+> Superseded 2026-07-29: staging browser identity and admin access now use one main-site Better Auth user session; the dual-domain admin surface in this historical plan is inactive.
+
 # Self-Hosted Identity Implementation Plan
 
 > **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task.

docs/superpowers/specs/2026-07-20-supabase-exit-backend-design.md

@@ -1,3 +1,5 @@
+> Superseded 2026-07-29: staging browser identity and admin access now use one main-site Better Auth user session; the dual-domain admin surface in this historical specification is inactive.
+
 # Jyotisha Supabase Exit and Self-Hosted Backend Design
 
 Date: 2026-07-20