Revert "Restore staging payment and package management"

This reverts commit 751dee39dc, reversing
changes made to 43581ac0f7.

docs/BUG_HISTORY.md

@@ -1553,77 +1553,28 @@
 
 - 状态：investigating
 - 首次发现：2026-07-27
-- 最近更新：2026-07-28
-- 影响面：生时校正聊天 Surface、事件语义、后台 Job、候选计算、诊断、Reasoner、Renderer 与持久化主链
+- 最近更新：2026-07-27
+- 影响面：生时校正 V4 聊天界面、历史恢复、模型选择、下一问规划与 staging 验收
 - 用户现象：进入生时校正后看到独立的校正面板、证据区域和固定问题；交互不像普通 session，领域也不再根据用户刚讲的经历动态选择。
-- 触发条件：旧 V4 既在界面层使用独立校正结构，又让 `question-planner.ts` 和 `question-author.ts` 直接决定领域顺序与问题文案；模型只负责写下一问，后台没有形成完整 Agent 决策闭环。
-- 根因：产品状态被压缩成“下一问字符串”，事件语义、候选特征、诊断结果、问题机会、模型决策和公开消息之间没有受约束的 durable contract；因此即使替换提示词，系统仍会沿用问卷式控制流，且无法审计模型为何选题或安全重放已完成 Job。
-- 修复：删除旧 `question-planner.ts` 与 `question-author.ts`，将回答处理重构为完整 V5 主链：保存回答并创建后台 Job → Evidence Reconciliation → Candidate Engine / Feature Snapshot → Diagnostics → Opportunity Builder → Bounded Reasoner → Decision Validator → Renderer → Atomic Job Completion。可见层继续复用普通 session 聊天 Surface；Reasoner 只能选择服务端生成的 opportunity 或受约束动作，不能注入分钟、分数、事件或任意问题；Renderer 只表达已验证决定，候选范围不得表述为已确认出生分钟。Agent Run、Public Message、Diagnostics、Feature Snapshot、Pending Evidence 和事件修订均作为一等产物持久化。
-- 验证：67 个 TypeScript 聚焦合同全部通过，覆盖普通 session UI、完整 V5 artifact chain、Reasoner 单次诊断预算、Opportunity 选择、shadow/legacy 隔离和 range-only 输出；7 个 Python 服务合同通过。真实 PostgreSQL 14 已按 V4 → V5 顺序完成 migration dry-run，并跑通 `processing → reasoning → rendering → complete`、五类 artifact 各一条落库和 completed Job 幂等重放。`tsc --noEmit` 未出现 V5 新错误，只剩 `birth-time-journey-engine`、`identity-auth-integration`、`onboarding-route` 三处无关基线错误。当前完成边界为本地可测，尚未提交、推送、迁移 staging 或执行登录态 smoke。
-- 防复发：生时校正不得再次把模型降级为“问题文案生成器”；所有可见动作必须来自 server-owned opportunity，经 bounded reasoner、decision validator 和 renderer 后原子持久化。测试必须同时锁定 legacy/shadow 隔离、artifact 完整性、候选范围边界和 completed-job replay 指纹。
-- 相关记录：BUG-020、BUG-075、BUG-080、BUG-081、BUG-082、BUG-083、BUG-084、BUG-086
-- 修复版本：本地 V5 重构，待提交与 staging 验收
+- 触发条件：V4 页面入口渲染旧式 `RectificationV4Panel` 视觉结构，页面给会话容器添加 `is-rectification`，同时问题规划器按硬编码领域顺序和模板生成下一问。
+- 根因：组件 wrapper 无条件绕过原普通聊天 Surface；普通 session CSS 又显式排除 `is-rectification`；`question-planner.ts` 把教育、迁移、关系、事业、财务、健康压力和家庭写成固定顺序与固定文案，测试还把这些实现细节当成产品合同。
+- 修复：V4 复用普通 session 的消息列表、输入框和模型选择器，并从持久化 turns 恢复完整对话；回答时原子保存所选模型 ID，Worker 将完整 turns、事件台账、日期精度、已追问事件与候选范围交给模型动态生成下一问。确定性 planner 只保留日期修订和开放叙述降级，不再轮询领域或输出固定问卷；候选范围仍不得表述为已确认出生分钟。
+- 验证：聚焦 V4/domain/service/replay/handoff/migration、普通 session UI 合同和 consultation entrypoint 共 59 个测试通过；staging 构建、迁移和登录态 smoke 完成后更新为 resolved 并填写精确提交与部署 SHA。
+- 防复发：可见生时校正必须复用普通聊天 Surface；测试应锁定自然语言消息、turn 恢复、模型 ID 传递和无固定领域控件，不得锁定领域顺序或问题模板。模型只负责选择和表达下一条高信息量问题，证据修订、评分、稳定性门、范围接受、handoff 与扣费继续由确定性后端负责。
+- 相关记录：BUG-020、BUG-075、BUG-080、BUG-081、BUG-082、BUG-083、BUG-084
+- 修复版本：待提交（staging 验收中）
 
 ## BUG-086 | 模型下一问可绕过当前事件而跳成领域问卷
 
 - 状态：investigating
 - 首次发现：2026-07-27
-- 最近更新：2026-07-28
-- 影响面：生时校正 V5 的当前事件延续、问题机会构建、诊断工具预算、模型决策验证和 Job replay
+- 最近更新：2026-07-27
+- 影响面：生时校正 V4 的模型提问规划、事件日期补全和 staging 对话体验
 - 用户现象：用户回答“2016 年离家去外地上大学”后，下一问直接变成“请说一次影响较大的搬家或长期迁居”，看起来仍按“升学 → 搬家”模板轮询，而没有承接刚才的具体经历。
-- 触发条件：当前事件仍缺必要精度，但旧 Worker 只校验模型返回结构；只要模型输出一个格式合法的新领域问题，就可以绕过当前事件和服务端已知证据缺口。
-- 根因：旧方案把“required continuation”作为给模型的提示，而不是服务器拥有的候选动作和最终决策约束；诊断结果也没有独立工具预算、持久化产物和可回放选择依据，无法阻止合法 JSON 携带错误业务路由。
-- 修复：Opportunity Builder 将未解决的当前目标设为独占路由，并只发布带稳定 ID、目标事件、效用分解和隐私成本的问题机会；Bounded Reasoner 最多执行一次只读诊断，最终只能选择活动 opportunity 或受限状态动作；Decision Validator 拒绝不存在、跨 Case、非活动或越权的机会，也禁止模型直接写问题、分钟、分数和事件。Reasoner 不可用、返回非最终诊断或耗尽预算时走同一确定性 fallback policy；Renderer 根据 validated decision 生成自然语言承接，Worker 再通过单一 completion RPC 原子保存全部产物。
-- 验证：对抗合同覆盖“当前目标独占下一问”“只能选择服务端活动 opportunity”“诊断预算耗尽 fail closed”“模型不得注入问题/分钟/事件/分数”和“Reasoner/Renderer 不可用时确定性降级”。真实 PostgreSQL completed-job replay 已验证：相同完整 payload 指纹返回既有 Case；任一 artifact 改变且指纹不同会抛出 `rectification_v5_replay_payload_mismatch`，不会二次写入或接受漂移结果。当前仅完成本地验证，staging 行为仍待发布后验收。
-- 防复发：当前事件延续必须是服务端 opportunity 所有权规则，而不是 prompt 建议；模型输出即使结构合法，也必须经过 bounded tool budget、active-opportunity lookup、decision validation 和 completion payload hash 四层门控。
+- 触发条件：最新可评分事件只有年份精度，但模型返回新的领域和空 `targetEventId`；Worker 直接接受格式合法的模型结果。
+- 根因：模型提示虽然要求优先延续当前事件，但 Worker 只校验了输出结构，没有把确定性 planner 识别出的必要日期补全当作服务端路由约束；因此模型可越过仍缺月份的当前事件。旧测试只证明模型拿到了完整上下文，没有覆盖模型违反路由建议的情况。
+- 修复：planner 将月份视为足够的首选精度；年份、季度或范围精度仍产生必要的当前事件补全。问题作者收到 `requiredContinuation`，必须围绕该事件自然追问月份或日期；Worker 在信任边界拒绝模型切换事件或领域，并回退到同一事件的开放式日期追问。当前事件达到月份精度后，模型才可根据上下文自由选择下一条高信息量问题，不设领域顺序。
+- 验证：新增用户原句回归，模拟模型错误返回搬家问题，断言 Worker 仍追问“离家去外地上大学”的月份且不出现搬家模板；同时锁定月份精度后模型可自由选题。聚焦 domain/service/replay 共 18 个测试通过；staging 部署与真实登录态 smoke 完成后更新状态。
+- 防复发：模型可以表达和选择下一题，但不能绕过服务端判定的当前事件必要补全；测试必须包含“模型输出合法但路由错误”的对抗用例，不能只测 happy path。
 - 相关记录：BUG-075、BUG-085
-- 修复版本：本地 V5 重构，待提交与 staging 验收
-
-## BUG-087 | self-hosted staging 管理员看不到独立后台入口
-
-- 状态：superseded by BUG-092
-- 首次发现：2026-07-29
-- 最近更新：2026-07-29
-- 影响面：self-hosted staging 账户菜单、`GET /api/account`、独立后台入口；不影响后台独立登录与 `requireAdminSession`
-- 用户现象：身份库已持久化 `admin` 或 `viewer` 角色的用户登录主站后，账户菜单不显示后台入口；即使显示旧入口，主站 `/admin` 路径也会返回 404。
-- 触发条件：`AUTH_PROVIDER=self-hosted`，后台部署在与主站不同的 `AUTH_ADMIN_ORIGIN`，用户角色以逗号分隔形式持久化在 `identity.users.role`。
-- 根因：主站 `isAdminUser` 对 self-hosted 模式直接返回 `false`，没有读取持久化角色；侧栏又把入口写死为主站相对路径 `/admin/codes`。既有后台鉴权已按持久化角色执行，但主站入口发现逻辑没有复用同一授权事实，独立域名部署合同也没有进入账户响应。
-- 修复：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-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
-- 修复版本：`435e628806390e7ae138363491e7bae63ee801d4`，staging 已验收
-
-## BUG-093 | 后台支付入口分散且界面风格不一致
-
-- 状态：investigating
-- 首次发现：2026-07-29
-- 最近更新：2026-07-30
-- 影响面：后台 Refine 侧栏、`/admin/payments`、`/admin/packages`、易支付配置与对话页充值入口。
-- 用户现象：支付记录与支付配置占用两个导航项，页面仍使用主站 `standalone-page/admin-header/admin-section` 样式；套餐新增表单常驻页面，后台默认退出入口还会触发登出，管理员难以直接返回对话；对话页支付入口缺少安全默认关闭和服务端创建订单硬门禁。2026-07-29 复发时，Z-Pay 配置不能折叠且占据长页面，后台受全局 `html/body overflow:hidden` 限制无法纵向滚动，套餐 API 与易支付配置 API 仍调用 self-hosted adapter 不支持的 Supabase builder/RPC。2026-07-30 部署 `dd8e2ad9c7e76d0152b4563c43a45b1e26137035` 后，`GET /api/admin/payments` 与套餐管理仍返回 500。
-- 触发条件：进入同域 `/admin` 后管理支付记录或套餐，或点击 Refine 侧栏底部默认 Logout；复发条件为进入支付管理、展开长配置或调用套餐 CRUD / 易支付配置读写。2026-07-30 的数据库权限复发在 `admin_runtime` 通过 `ADMIN_DATABASE_URL` 查询支付表时稳定触发。
-- 根因：首轮支付后台实现依赖 Supabase 专用关联 select、分页、计数和 Admin Auth 查询；self-hosted staging 的本地 PostgreSQL adapter 不支持这些 builder 能力，支付记录因此统一降级为“支付记录服务暂时不可用”。同页套餐设计也不符合最新后台信息架构，易支付配置响应漏投影 `chat_enabled`，chat 创建订单又依赖服务端提交网关后猜测跳转地址，不兼容标准易支付收银台表单页。复发遗漏源于上轮只把支付记录切换到 PostgreSQL，套餐与配置契约测试没有锁定 self-hosted 数据链，且未覆盖聊天全局滚动边界下的后台专用滚动容器。2026-07-30 的直接根因是 `20260727020000_epay_packages_orders.sql` 只向 Supabase 的 `service_role` / `authenticated` 授权，未向 self-hosted 后台实际使用的 `admin_runtime` 授予 `payment_packages`、`payment_orders` 权限，也未添加对应 RLS 策略；因此数据库健康且新 SHA 已部署，后台 SQL 仍被 PostgreSQL 权限门禁拒绝。
-- 修复：支付记录改为通过 `queryAdminRows` 执行参数化 SQL，联表 `public.payment_orders`、`public.payment_packages` 和 `identity.users`，以窗口计数保留分页合同并用独立聚合 SQL输出统计；不再使用 Supabase builder 或 Admin Auth。后台在支付管理之后新增独立“套餐管理”资源和页面，套餐新增、编辑、停用、错误重试及原字段保持完整，支付页只保留概览、Z-Pay（易支付）渠道配置和支付记录。配置读取补回 `chat_enabled` 与 `chatEnabled`。创建订单完成登录、开关、配置、SSRF、套餐和订单校验后，直接返回带 `sign/sign_type` 的标准 `submit.php` 收银台 URL，不服务端请求网关、不返回商户密钥；对话页用浏览器打开该 URL，套餐加载异常显示安全错误，正常 `enabled=false` 仍静默隐藏。复发修复将 Z-Pay 配置改为默认收起的 Ant Design `Collapse`，展开后才显示表单和操作；为 AdminApp 增加 `admin-app-shell` 的 `100dvh` 独立纵向滚动边界而不改聊天全局规则；套餐 CRUD 全部改用 `queryAdminRows` 参数化 SQL、UUID 校验、`returning` 与 404；易支付读取仅在 PostgreSQL `42P01` 时回退环境变量，保存直接参数化调用 `public.admin_save_epay_settings` 并使用函数返回行，保留原子审计和脱敏响应。2026-07-30 新增前向迁移 `20260730010000_admin_payment_permissions.sql`，向 `admin_runtime` 最小授予套餐读写、订单只读、易支付配置读取及保存函数执行权限，并为启用 RLS 的支付表补齐角色策略；不授予订单写入或删除权限。
-- 验证：`frontend/tests/admin-contracts.test.ts` 锁定支付、套餐资源顺序；`frontend/tests/admin-payments-contract.test.ts` 锁定本地参数化 SQL、`identity.users` 联表、套餐 SQL CRUD/UUID/404、独立套餐页面、默认折叠和后台专用滚动容器；`frontend/tests/epay-settings.test.ts` 锁定 `chatEnabled` 回显、`queryAdminRows` 读取、参数化 `admin_save_epay_settings`、不依赖 Supabase builder/RPC、默认折叠和不泄露 key。2026-07-29 运行三份契约测试共 27 项全部通过；ESLint、TypeScript 与 `git diff --check` 结果记录在本次交付报告。2026-07-30 线上健康响应证明部署 SHA 为 `dd8e2ad9c7e76d0152b4563c43a45b1e26137035` 且本地业务库、身份库均健康；静态权限审计确认支付迁移缺少 `admin_runtime` grant/RLS。新增权限迁移契约后，支付、套餐、配置三组 21 项回归全部通过；生产态最终验证仍等待迁移应用和已登录 smoke，因此状态保持 `investigating`。
-- 防复发：self-hosted staging 后台查询不得依赖 LocalPostgresDataClient 未实现的 Supabase builder、RPC 或 Admin Auth 能力；支付与套餐必须保持独立资源顺序。套餐与易支付配置契约必须显式拒绝 Supabase builder/RPC 并锁定参数化 SQL、404、原子函数写入和安全错误响应；支付配置必须默认折叠，后台必须拥有独立滚动容器且不得放宽聊天的全局 `overflow:hidden`。易支付配置读写测试必须同时覆盖数据库列和公开字段；创建订单只生成经公网 SSRF 校验的签名收银台 URL，商户密钥只能参与服务端签名，不得进入 URL、响应、日志或审计。对话支付默认关闭，UI 与创建订单 API 必须共享服务端开关；可用性测试不得提交伪订单或返回 URL、PID、密钥、headers/body。
-- 相关记录：BUG-087、BUG-092
-- 复发自：BUG-093
-- 修复版本：待提交（本地可测）
+- 修复版本：待提交

docs/adr/0001-separate-agent-failures-from-reply-ratings.md

@@ -1,7 +0,0 @@
----
-status: accepted
----
-
-# 分离 Agent 执行故障与回复评价
-
-所有 Agent 会话使用稳定的会话、轮次、回复、执行尝试和请求标识建立关联，但将技术执行故障与用户对完整回复的质量评价建模为两类记录；服务端和客户端故障按请求标识关联去重，重复执行按轮次聚合展示。这样可以分别衡量系统可用性与回答质量，并保留重试轨迹，而不会把业务拒绝、技术失败和内容不满意混成同一种“报错”。

docs/adr/0002-minimize-and-expire-conversation-quality-content.md

@@ -1,7 +0,0 @@
----
-status: accepted
----
-
-# 最小化并限期保留对话质量正文
-
-对话质量记录按排错需要最小化收集：执行故障保存实际使用的上下文，负向评价保存对应 Agent 对话轮次，正向评价只保存脱敏统计元数据；禁止保存密钥、认证信息、系统提示词、原始第三方响应和完整堆栈。故障及负向评价正文最多保留 90 天，用户删除会话或撤回负向评价时提前清除相关正文；不可还原对话的聚合数据、审计轨迹和脱敏管理员备注可以长期保留，以平衡问题追踪与用户隐私。

docs/agents/domain.md

@@ -1,51 +0,0 @@
-# Domain Docs
-
-How the engineering skills should consume this repo's domain documentation when exploring the codebase.
-
-## Before exploring, read these
-
-- **`CONTEXT.md`** at the repo root, or
-- **`CONTEXT-MAP.md`** at the repo root if it exists — it points at one `CONTEXT.md` per context. Read each one relevant to the topic.
-- **`docs/adr/`** — read ADRs that touch the area you're about to work in. In multi-context repos, also check `src/<context>/docs/adr/` for context-scoped decisions.
-
-If any of these files don't exist, **proceed silently**. Don't flag their absence; don't suggest creating them upfront. The `/domain-modeling` skill (reached via `/grill-with-docs` and `/improve-codebase-architecture`) creates them lazily when terms or decisions actually get resolved.
-
-## File structure
-
-Single-context repo (most repos):
-
-```
-/
-├── CONTEXT.md
-├── docs/adr/
-│   ├── 0001-event-sourced-orders.md
-│   └── 0002-postgres-for-write-model.md
-└── src/
-```
-
-Multi-context repo (presence of `CONTEXT-MAP.md` at the root):
-
-```
-/
-├── CONTEXT-MAP.md
-├── docs/adr/                          ← system-wide decisions
-└── src/
-    ├── ordering/
-    │   ├── CONTEXT.md
-    │   └── docs/adr/                  ← context-specific decisions
-    └── billing/
-        ├── CONTEXT.md
-        └── docs/adr/
-```
-
-## Use the glossary's vocabulary
-
-When your output names a domain concept (in an issue title, a refactor proposal, a hypothesis, a test name), use the term as defined in `CONTEXT.md`. Don't drift to synonyms the glossary explicitly avoids.
-
-If the concept you need isn't in the glossary yet, that's a signal — either you're inventing language the project doesn't use (reconsider) or there's a real gap (note it for `/domain-modeling`).
-
-## Flag ADR conflicts
-
-If your output contradicts an existing ADR, surface it explicitly rather than silently overriding:
-
-> _Contradicts ADR-0007 (event-sourced orders) — but worth reopening because…_

docs/agents/issue-tracker.md

@@ -1,45 +0,0 @@
-# Issue tracker: GitHub
-
-Issues and PRDs for this repo live as GitHub issues. Use the `gh` CLI for all operations.
-
-## Conventions
-
-- **Create an issue**: `gh issue create --title "..." --body "..."`. Use a heredoc for multi-line bodies.
-- **Read an issue**: `gh issue view <number> --comments`, filtering comments by `jq` and also fetching labels.
-- **List issues**: `gh issue list --state open --json number,title,body,labels,comments --jq '[.[] | {number, title, body, labels: [.labels[].name], comments: [.comments[].body]}]'` with appropriate `--label` and `--state` filters.
-- **Comment on an issue**: `gh issue comment <number> --body "..."`
-- **Apply / remove labels**: `gh issue edit <number> --add-label "..."` / `--remove-label "..."`
-- **Close**: `gh issue close <number> --comment "..."`
-
-Infer the repo from `git remote -v` — `gh` does this automatically when run inside a clone.
-
-## Pull requests as a triage surface
-
-**PRs as a request surface: no.** _(Set to `yes` if this repo treats external PRs as feature requests; `/triage` reads this flag.)_
-
-When set to `yes`, PRs run through the same labels and states as issues, using the `gh pr` equivalents:
-
-- **Read a PR**: `gh pr view <number> --comments` and `gh pr diff <number>` for the diff.
-- **List external PRs for triage**: `gh pr list --state open --json number,title,body,labels,author,authorAssociation,comments` then keep only `authorAssociation` of `CONTRIBUTOR`, `FIRST_TIME_CONTRIBUTOR`, or `NONE` (drop `OWNER`/`MEMBER`/`COLLABORATOR`).
-- **Comment / label / close**: `gh pr comment`, `gh pr edit --add-label`/`--remove-label`, `gh pr close`.
-
-GitHub shares one number space across issues and PRs, so a bare `#42` may be either — resolve with `gh pr view 42` and fall back to `gh issue view 42`.
-
-## When a skill says "publish to the issue tracker"
-
-Create a GitHub issue.
-
-## When a skill says "fetch the relevant ticket"
-
-Run `gh issue view <number> --comments`.
-
-## Wayfinding operations
-
-Used by `/wayfinder`. The **map** is a single issue with **child** issues as tickets.
-
-- **Map**: a single issue labelled `wayfinder:map`, holding the Notes / Decisions-so-far / Fog body. `gh issue create --label wayfinder:map`.
-- **Child ticket**: an issue linked to the map as a GitHub sub-issue (`gh api` on the sub-issues endpoint). Where sub-issues aren't enabled, add the child to a task list in the map body and put `Part of #<map>` at the top of the child body. Labels: `wayfinder:<type>` (`research`/`prototype`/`grilling`/`task`). Once claimed, the ticket is assigned to the driving dev.
-- **Blocking**: GitHub's **native issue dependencies** — the canonical, UI-visible representation. Add an edge with `gh api --method POST repos/<owner>/<repo>/issues/<child>/dependencies/blocked_by -F issue_id=<blocker-db-id>`, where `<blocker-db-id>` is the blocker's numeric **database id** (`gh api repos/<owner>/<repo>/issues/<n> --jq .id`, _not_ the `#number` or `node_id`). GitHub reports `issue_dependencies_summary.blocked_by` (open blockers only — the live gate). Where dependencies aren't available, fall back to a `Blocked by: #<n>, #<n>` line at the top of the child body. A ticket is unblocked when every blocker is closed.
-- **Frontier query**: list the map's open children (`gh issue list --state open`, scoped to the map's sub-issues / task list), drop any with an open blocker (`issue_dependencies_summary.blocked_by > 0`, or an open issue in the `Blocked by` line) or an assignee; first in map order wins.
-- **Claim**: `gh issue edit <n> --add-assignee @me` — the session's first write.
-- **Resolve**: `gh issue comment <n> --body "<answer>"`, then `gh issue close <n>`, then append a context pointer (gist + link) to the map's Decisions-so-far.

docs/agents/triage-labels.md

@@ -1,15 +0,0 @@
-# Triage Labels
-
-The skills speak in terms of five canonical triage roles. This file maps those roles to the actual label strings used in this repo's issue tracker.
-
-| Label in mattpocock/skills | Label in our tracker | Meaning                                  |
-| -------------------------- | -------------------- | ---------------------------------------- |
-| `needs-triage`             | `needs-triage`       | Maintainer needs to evaluate this issue  |
-| `needs-info`               | `needs-info`         | Waiting on reporter for more information |
-| `ready-for-agent`          | `ready-for-agent`    | Fully specified, ready for an AFK agent  |
-| `ready-for-human`          | `ready-for-human`    | Requires human implementation            |
-| `wontfix`                  | `wontfix`            | Will not be actioned                     |
-
-When a skill mentions a role (e.g. "apply the AFK-ready triage label"), use the corresponding label string from this table.
-
-Edit the right-hand column to match whatever vocabulary you actually use.

docs/operations/self-hosted-identity.md

@@ -4,27 +4,29 @@ Staging uses Better Auth and the private local PostgreSQL cluster for both ident
 
 ## Staging mode
 
-Keep these values exactly as shown:
+Keep these two values exactly as shown:
 
 ```dotenv
 AUTH_PROVIDER=self-hosted
 SELF_HOSTED_IDENTITY_ENABLED=true
-AUTH_USER_ORIGIN=https://staging.jyotisha.chat
 ```
 
-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`.
+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.
 
 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 `BETTER_AUTH_USER_SECRET` locally on the server:
+Generate separate secrets locally on the server:
 
 ```bash
 openssl rand -base64 32
+openssl rand -base64 32
 ```
 
-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.
+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.
 
-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.
+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.
 
 Validate without printing values:
 
@@ -36,17 +38,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. 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. 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.
 
-After deployment, verify the single-domain contract:
+After deployment:
 
 ```bash
-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
+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
 ```
 
-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.
+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.
 
 ## Optional import rehearsal
 
@@ -73,8 +75,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 requires a separate reviewed data-reconciliation and provider-switch change.
+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.
 
-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.
+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.
 
 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,5 +1,3 @@
-> 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,5 +1,3 @@
-> 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