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
-- 修复版本：待提交（本地可测）
+- 修复版本：待提交