ai-contract-platform/project-docs/V2-product-audit-and-development-backlog-2026-08-01.md

钰麒合同 V2 产品审计与开发 Backlog

日期：2026-08-01 角色：产品经理、运营质量负责人、测试复核负责人

一、审计结论

当前 V2 的合同业务骨架已接近企业 UAT 水平，但尚不具备“面向个人、团队与企业的公开 SaaS”发布条件。主要阻断项不是模板或审查能力，而是：

1. 服务端角色授权没有真正落到合同写接口。
2. 未登录页面展示管理员导航和模拟业务数据。
3. 产品承诺包含个人用户，但身份模型只闭环了“公司租户”。
4. 平台超级管理员并非独立身份，而是依靠默认租户和固定用户 ID 推断。
5. 真实 AI、内容签批、服务协议和运营交付仍是既有文档明确记录的 No-Go 项。

现有实现已经覆盖：30 个模板、模板起草、合同编辑、审批退回重提、异步 AI 审查、结构化风险与引用、条款修复、PDF 审查报告、Word 下载、文件仓库、版本、签署证据、履约和归档。

二、三类用户模型与关键旅程

2.1 个人用户

目标定义：独立自然人账号，默认拥有一个个人工作空间，不要求提供公司信息。

关键旅程：

1. 注册账号并验证身份。
2. 系统自动创建个人工作空间。
3. 选择模板起草，或上传已有合同。
4. 发起 AI 审阅，查看风险、依据和修改建议。
5. 下载合同或审阅报告。
6. 查看个人用量、订阅与历史记录。

当前状态：产品定位明确包含个人用户，但没有个人注册或个人空间创建路径。

2.2 企业租户用户

目标定义：组织工作空间中的成员，按管理员、法务、业务、审批人、观察者角色协作。

关键旅程：

1. 平台管理员或自助流程创建组织工作空间。
2. 组织管理员邀请成员。
3. 员工通过邀请设置密码并登录。
4. 业务人员起草或上传合同。
5. 法务发起审查和修订，审批人处理审批。
6. 合同完成签署、履约和归档，保留审计证据。

当前状态：流程基本闭环，但角色授权主要停留在展示层，登录多空间体验较差。

2.3 平台超级管理员

目标定义：平台级主体，负责租户、套餐、全局安全、AI 质量、运营和交付管理；默认不得参与客户合同流程或查看客户正文。

关键旅程：

1. 安全 bootstrap 或受控邀请创建平台管理员。
2. 创建、停用和审计工作空间。
3. 管理 Provider、Prompt、全局知识资产和质量门。
4. 监控安全事件、容量、失败任务和交付状态。
5. 通过显式授权和完整审计执行租户支持操作。

当前状态：没有显式平台角色；依靠 default 租户和固定用户 ID 判断。

三、P0 问题与验收标准

P0-1 服务端合同角色授权缺失

问题：详情和工作台接受客户端 role 参数，合同编辑、审批、审查、归档等写接口没有统一按照当前会话用户角色复核。

验收标准：

• 角色必须由服务端根据当前 tenant_id、user_id 查询，不信任 URL、请求体或公开环境变量。
• 业务用户直接调用审批、归档、规则发布等接口返回 403。
• 审批人不能编辑合同，观察者不能修改或发起审查。
• 客户端传入 role=admin 不影响服务端权限。
• 所有读写权限边界都有 API 级回归测试。

P0-2 未登录页面展示管理员工作台

问题：前端角色默认 admin，无会话时页面请求失败后回退模拟合同和待办，登录只表现为可选入口。

验收标准：

• 未登录访问业务页和管理页统一跳转登录，API 返回 401。
• 登录、注册、密码重置和邀请页使用独立认证布局，不展示业务和后台导航。
• 实际会话角色驱动导航和页面守卫。
• 未登录、接口故障、真实空数据三种状态严格分离。

P0-3 真实空待办被替换成模拟待办

问题：只要 pending_tasks 为空就回退到模拟任务，真实零待办会显示虚假业务数据。

验收标准：

• 合法的零待办显示空状态。
• 接口超时或失败显示明确错误和重试入口。
• 模拟数据只能在显式 demo 模式出现，并带清楚的演示标识。

P0-4 平台超级管理员身份不可治理

问题：平台管理员由默认租户和固定用户 ID 推断，无法规范支持多人、停用、轮换和审计。

验收标准：

• 增加显式平台权限声明或平台角色。
• 支持多名平台管理员、停用、凭据轮换和完整审计。
• 平台权限不依赖固定字符串 ID。
• 企业管理员不能访问跨工作空间数据和平台级配置。

P0-5 AI 与内容交付不满足公开生产承诺

验收标准：

• 真实 Provider 启用，生产 fallback 关闭。
• 审查、法律问答、生成和条款推荐黄金样本通过。
• 高风险模板完成具名法务签批。
• 引用准确率、无依据响应、幻觉和低置信度结果有明确门禁。

P0-6 公开产品缺法定信任页面

验收标准：

• 上线用户协议、隐私政策、服务协议、数据处理规则和 AI 免责声明。
• 注册、上传、AI 问答和报告交付可访问相关协议。
• 用户同意记录包含协议版本、时间和主体。

四、P1 Backlog

P1-1 将租户产品语义统一为工作空间

• 普通页面不再出现“租户 ID”。
• “公司”只用于组织类型工作空间。
• 平台运维页面可以保留租户技术字段。

P1-2 建立个人工作空间

• 个人注册后原子创建账号、个人空间和 owner 成员。
• 个人用户可以立即起草、上传、审查和下载报告。
• 个人空间隐藏成员邀请、SSO 和复杂企业治理能力。

P1-3 增加工作空间切换器

• 同一账号加入多个空间时无需手填工作空间 ID。
• 登录后可以查看并切换有权访问的空间。
• 切换后会话、权限、缓存和导航同步刷新。

P1-4 分离平台后台与企业管理区

• 企业管理员只见成员、审批、企业资产和企业审计。
• 平台管理员才见跨租户、安全、Provider、全局 AI 质量和运行配置。
• 平台支持进入租户数据时需要显式授权并记录审计。

P1-5 修正身份页和导航

• 登录页标题和品牌口径统一为“登录钰麒合同”。
• 未登录不显示后台导航。
• SSO 实际登录闭环完成前不得包装为可用能力。
• 公开注册关闭时提供清晰的申请试用或联系服务入口。

P1-6 收口主流程语义

• “起草新合同”进入模板起草，不进入合同台账。
• 文件上传后提供“创建合同并发起审查”。
• 去除用户可见的“V1/V2”等工程文案。
• 合同状态、生命周期、下一步动作使用统一中文口径。

P1-7 AI 结果风险沟通

• 问答页和合同审查结果页常驻人工复核提示。
• 低置信度结果不得使用成功色。
• 无引用或依据不足时不得包装成可靠结论。
• 普通用户不能进入平台 AI Trace 管理页。

P1-8 账号恢复与邀请运营

• 明确邀请到期、重发、撤销和可信渠道交付。
• 覆盖员工离职、管理员转移和唯一管理员保护。
• 无邮箱模式提供明确账号支持 SLA。

五、P2 Backlog

• 套餐、配额与用量：个人、试用、团队、企业套餐，审查量、存储、成员、报告水印和超限提示。
• 运营与客户成功：试点周期、负责人、活跃用户、起草/审查/报告转化、失败任务和续费风险。
• 通知中心：审批、审查、履约、邀请和安全提醒形成可到达的入口与已读闭环。
• 文档治理：功能状态、RC 结论、测试证据和运行环境保持一致，废止陈旧结论。

六、个人工作空间兼容方案

6.1 第一阶段：保持现有 tenant_id 边界

将现有 TenantModel 解释为通用工作空间，在现有 settings 或后续显式字段中加入：

workspace_type: system | personal | organization
owner_user_id: string | null
legal_name: string | null

迁移规则：

• 现有客户租户默认标记为 organization。
• default 标记为 system。
• 个人注册创建 personal 空间。
• 继续复用合同、文件、审查、知识库和审计表中的 tenant_id，不重写业务外键。
• 个人空间中的 admin 在产品上显示为“所有者”。

6.2 第二阶段：全局账号与成员关系

引入：

• accounts：全局唯一账号和凭据。
• workspace_memberships：账号与工作空间的成员关系、角色和状态。
• 现有 tenant_users 通过 account_id 兼容迁移，或逐步演化为 membership 表。

目标：解决同一邮箱在多个租户中拥有多套凭据、登录时必须输入空间 ID、密码策略不一致等问题。

七、回归测试清单

身份与会话

• 未登录访问全部业务与管理路由。
• 个人注册、企业邀请、密码设置和登录。
• 多空间查看和切换。
• 停用用户、停用空间、邀请过期和管理员转移。
• 平台管理员 bootstrap、停用和轮换。

权限与隔离

• 五类企业角色逐项验证读取、编辑、上传、审查、审批、下载、归档和规则发布。
• 同时覆盖 UI、同源代理和直接 API 绕过。
• 个人与企业、两个企业、平台后台三组交叉访问合同、文件、报告、搜索、审计和 AI Trace。

模板与合同

• 30 个模板全量生成。
• 必填项、可选项、特殊字符、长文本和重复提交。
• 草稿、审查、提交审批、退回、重提、签署、履约和归档的合法与非法状态转换。

AI 审查与报告

• 上传后建合同、排队、运行、失败和重试。
• 结构化风险、引用、条款修复、报告生成下载及旧版本一致性。
• 无依据、低置信度、Provider 不可用和 fallback 禁用场景。

空态与故障

• 零合同、零待办、零文件和零通知。
• API 401/403/500、超时和服务不可用。
• 任何故障都不得出现模拟业务数据或虚假成功。

运营交付

• 试用额度、报告水印和超限行为。
• 协议版本、用户同意记录、数据导出和删除。
• 客服升级、人工复核和交付审计证据。

八、开发执行顺序

1. P0 服务端授权与未登录边界。
2. 移除隐式模拟数据和客户端角色来源。
3. 引入工作空间类型和显式平台权限。
4. 打通个人工作空间注册与多空间会话。
5. 收口导航、身份文案和主流程入口。
6. 补齐协议、运营、套餐和客户成功能力。
7. 运行全量回归、真实 Provider 质量验收和生产发布门禁。

九、自动化开发阶段状态（2026-08-01）

本轮已启动三个智能 Agent，分别负责服务端授权、前端身份边界和个人工作空间后端；随后追加个人/组织注册前端接入。所有改动保留在当前工作树，尚未提交、部署或应用到生产数据库。

9.1 已完成

• P0-1 服务端角色授权：新增统一 capability 授权层。代理认证开启时，角色只从当前 tenant_id、user_id 对应的活跃成员关系解析；客户端 role=admin 不再影响权限。合同、审批、审查、报告、下载、文件、归档、签署、履约、备份、模板、法务资产和审批规则接口已接入授权守卫。
• P0-2 未登录边界：Next.js 请求代理验签会话 cookie；未登录访问业务路由跳转 /login，无权访问管理路由跳转 /workspace。认证页、邀请页、密码重置页和政策页使用独立外壳，不再显示业务后台导航。
• P0-3 隐式模拟数据：合同列表、合同详情和工作台待办已移除生产路径中的模拟回退；合法零待办返回空列表，接口失败抛出错误，不再显示虚假合同或待办。
• P0-4 显式平台权限第一阶段：tenant_users.platform_permissions 支持显式 platform_admin，运行时判断不再比较固定用户 ID。历史 default/user-current-admin 仅在迁移和 bootstrap 中用于给既有记录回填显式权限。
• P1-1/P1-2 工作空间与个人注册第一阶段：保留全部 tenant_id 外键，新增 workspace_type、owner_user_id、legal_name；个人注册原子创建 personal 工作空间、owner/admin 成员、账户设置和密码凭据；组织注册继续创建 organization 工作空间。
• 个人/组织注册入口：注册页默认提供个人模式，并可切换组织模式；个人模式不要求公司名称或技术空间 ID。成功注册复用现有签名会话进入工作台。
• P1-5/P1-6/P1-7 部分项：导航使用会话角色；“起草新合同”进入模板起草；用户可见的 V1/V2 工程文案已移除；法律问答和合同审查增加人工复核边界；低、中、高置信度使用警告、主色和成功色分级。
• 法定信任页面载体：已增加用户协议、隐私政策、服务协议和 AI 使用说明入口，并明确标注为产品草案、正式发布前需具名法务审核。

9.2 验证证据

• Contract API 按四个隔离数据库分片执行 182 个测试用例；发现 2 个本地兼容模式回归后已修复，相关防滥用、代理认证和越权测试 16 项复跑通过。
• 服务端越权测试覆盖业务用户审批/归档、审批人编辑、观察者上传/审查以及 role=admin 伪造，均返回预期 403；缺少身份上下文返回 401。
• 身份定向测试覆盖个人空间 owner、密码登录、企业/个人同邮箱多空间、重复注册冲突、事务回滚和显式平台权限。
• AI Platform API 全量 93 项测试通过，包含新增生产发布就绪门禁测试。
• npm run web:typecheck 通过；npm run web:build 通过，共生成 94 个路由并识别 Next.js Proxy。
• Playwright 真实浏览器验证：未登录 /workspace 跳转 /login；登录页无业务侧栏且含四类政策链接；注册页个人/组织分段可切换；政策页显示草案和法务审核状态。
• 新版 Contract API 临时实例完成一次真实个人注册和指定工作空间登录：返回 workspace_type=personal、owner 与用户一致、成员角色为 admin、认证方式为 password。
• 迁移 20260801_0033 已由开发 Agent 在全新 SQLite 上完成 upgrade、downgrade、re-upgrade 验证。

9.3 仍未完成或不得作为上线完成项

• P0-5 的真实 AI Provider 单场景联网验收已通过：当前 Codex Provider/模型在隔离内存实例中完成法律问答端到端运行，未使用 fallback，质量与引用门禁均通过。该运行尚未持久化到共享或生产数据库，且审查、生成、条款推荐等完整黄金套件仍待执行，因此不得据此将 P0-5 整体标记为生产交付完成。
• 协议版本与同意记录已持久化，但四份协议仍是产品草案，尚未经过具名法务审核和正式生效；草案留痕不得被解释为正式法律文本已发布。
• 平台管理员的多人开通、停用、轮换和支持访问审计仍需补齐运营管理入口；当前完成的是显式权限数据和运行时识别。
• 多工作空间兼容层与可视化切换器已完成，登录页不再要求填写工作空间 ID；但当前仍复用各 tenant_user 的历史凭据进行候选校验，尚未完成统一全局凭据、已验证邮箱归并和账号合并/拆分治理，因此不得把兼容层解释为最终账号体系。
• 个人空间的套餐、配额、用量、支付、成员功能隐藏和数据退出仍属于后续 P1/P2。
• 本地验收预览已使用隔离 SQLite 在 8100 重启当前 Contract API，并在 3011 启动当前 Web；这不代表生产或共享数据库已迁移。生产/共享环境启用前必须备份数据库、依次执行 Alembic 0033、0034 与 0035、配置代理认证并重启服务。

9.4 第二阶段已完成

• AI 生产发布门禁：新增 GET /api/v1/quality/release-readiness 和可供 CI 调用的 python -m yuqei_ai_platform_api.release_readiness_gate。生产环境必须启用非占位 Provider、可解析 URL 与凭据、关闭 fallback、通过黄金资产和引用策略检查，并提供共享预发布持久化的完整 Provider 验收清单 acceptance_run_id。单条审计运行 ID、缺少 10+8 样本、10 张知识卡、资产哈希或结构化具名法务审批证据时均失败关闭。离线黄金资产结果明确标记为不验证 Provider 输出。
• 协议版本与同意留痕：新增公开协议目录和受控同意记录查询接口。个人与组织注册必须逐项提交服务端目录中的当前精确版本；缺失、重复、额外或客户端自定义版本均被拒绝。
• 注册事务一致性：工作空间、owner/admin、账户、凭据和四条同意记录在同一事务中创建，任一写入失败整体回滚。20260801_0034 新增 identity_agreement_consents，记录工作空间、用户、协议类型、版本、服务端同意时间、注册来源、客户端 IP 和 User-Agent。
• 注册前端闭环：个人与组织模式均从同源协议目录加载必签项，逐项展示政策链接、精确版本和“草案未生效”状态；未全部勾选时提交禁用，模式切换清空已有同意。
• 扩展角色权限矩阵：补充法务备份、内部 review worker、业务用户管理审批规则、审批人创建合同、观察者发布模板等直接 API 越权场景，均要求返回 403。

9.5 第二阶段验证证据

• Contract API 当前完整 185 项按四个隔离数据库分片通过：合同工作流 78 项、核心治理 36 项、领域模块 40 项、身份/权限/迁移 31 项。
• Contract API 身份管理 9 项通过；身份安全、代理权限和角色授权组合 21 项通过；0034 升级/降级自动化测试 1 项通过，共 31 项定向回归通过。
• 0034 在完整 SQLite 迁移链执行 upgrade、downgrade、re-upgrade 通过；表结构、唯一约束及新增请求来源字段均有断言。
• AI Platform API 全量 93 项通过；生产默认 mock/fallback 配置被门禁判定为 blocked，CLI 返回退出码 1。
• Web 类型检查和生产构建通过，构建包含 /api/auth/agreements/current、个人注册和组织注册路由，共生成 94 个路由。
• 隔离实例真实注册验证返回 workspace_type=personal、角色 admin、4 条同意记录；版本、注册来源、服务端采集的 IP 和 User-Agent 均与请求上下文一致。
• Playwright 在无网络 mock 的本地预览验证：四项协议和政策链接可见；未勾选时提交禁用；全部勾选后启用；切换到组织模式后全部恢复未选；稳定页面控制台无错误。

9.6 下一阶段优先项

1. 真实 Provider 验收固定覆盖实际调用模型的 10 条法律问答与 8 条合同审查，并在共享预发布环境持久化完整验收清单；合同生成与条款推荐继续由独立确定性产品黄金套件验证，不伪装为 Provider 调用。单场景或单条审计运行 ID 不得替代完整发布证据。
2. 完成四份政策的具名法务审核、正式版本号、生效时间、历史版本查询和再次同意策略。
3. 在现有全局账号兼容层上收口统一凭据、已验证邮箱归并、账号合并/拆分和成员关系恢复流程，避免仅凭相同邮箱长期承担跨空间身份绑定语义。
4. 补齐平台管理员多人治理、支持访问授权审计，以及个人套餐、配额、用量和数据退出能力。

9.7 真实 AI Provider 联网验收证据（2026-08-01）

• 参数来源：仅在单次验收子进程中读取 Codex 当前 Provider 配置和凭据；Provider、模型和端点按运行时配置解析，不作为固定产品参数写入仓库、.env、数据库或日志。验收期间未输出任何密钥值。
• 协议兼容性：当前 Provider 的 /v1/responses 与 /v1/chat/completions 均完成真实联网调用；项目现有 Chat Completions 适配器可正常调用当前 Provider，无需为本次验收改写协议。
• 端到端用例：向隔离内存知识库加入《中华人民共和国劳动合同法》第十九条和第二十条，询问三年以上固定期限劳动合同的试用期上限及试用期工资下限。模型准确返回“六个月”“80%（百分之八十）”和“当地最低工资标准”，并正确列出对应法条。
• 审计证据：运行 ID run-06172b83f530；Provider ccswitch；模型 gpt-5.6-sol；Provider 与运行状态均为 succeeded；fallback 未使用；响应引用 4 条；检索来源 2 个；总 token 4855；延迟 6258 ms；质量状态 passed，质量分 100。
• 门禁结果：以该运行 ID 调用生产规则 GET /api/v1/quality/release-readiness，返回 ready、release_allowed=true、provider_acceptance_verified=true，无失败检查。
• 证据边界：该运行 ID 属于验收进程内的隔离内存仓库，进程退出后不会出现在共享或生产数据库。它证明当前动态 Provider 参数、项目适配器、检索引用、质量评估和发布门禁能够端到端工作，但不构成生产部署、生产数据迁移、完整黄金套件通过或具名法务签批的证据。

9.8 第三阶段自动化开发结果（2026-08-01）

• 全局账号兼容层：新增 identity_accounts 与 workspace_memberships，保持合同、文件、审查和审计等业务表继续使用 tenant_id。同一标准化邮箱可关联个人与组织工作空间，每个成员关系保留目标空间中的 tenant_user_id、角色、状态和 owner 标记。
• 迁移与旧数据回填：新增 20260801_0035，从现有有效 tenants 与 tenant_users 回填全局账号和成员关系，不读取或搬运密码凭据；迁移支持 upgrade、downgrade、re-upgrade，并断言同邮箱只生成一个全局账号及多个空间成员关系。
• 登录与空间切换：登录页只提交邮箱与密码，不再暴露工作空间 ID。服务端在同邮箱多空间候选中校验实际匹配凭据后建立会话；登录后通过 GET /api/v1/identity/workspaces 获取有效成员空间，通过 POST /api/v1/identity/workspaces/switch 切换。目标空间必须属于同一有效全局账号，且工作空间、成员和用户均为有效状态，否则统一返回 403。
• 前端会话闭环：新增同源 workspace 列表和切换代理，均要求有效签名会话；切换成功后重新签发包含目标 tenant_id、user_id 和角色的前端会话。顶栏单空间保持紧凑展示，多空间显示选择器；失败时保留当前会话和当前空间。
• Provider 验收工具加固：run-ai-provider-acceptance.py 默认将证据写入 .runtime，持久化字段限制为 Provider、模型、状态、计数和问题代码；不写入完整模型响应、合同内容、问题文本、引用 ID、审计 ID、tenant 或法务姓名。工具同时限制 URL、header、密钥文件大小、超时、用例数量和响应体，并显式使用 UTF-8。
• 离线完整用例准备：隔离 HTTP 服务已跑通 Phase13 的 10 条法律问答与 8 条合同审查，18/18 技术通过，法律状态均保持 needs_legal_review；该结果仅验证验收工具和样本编排，不代表真实 Provider 完整黄金套件通过。

9.9 第三阶段验证证据

• Contract API 186 项按四个独立 SQLite 分片全部通过：合同工作流 92 项、核心治理 45 项、领域模块 21 项、身份/权限/迁移 28 项。
• 身份定向覆盖：同邮箱个人/组织空间归并、免工作空间 ID 的凭据匹配登录、空间列表、合法切换、跨账号/系统空间拒绝、成员状态过滤、注册事务回滚，以及 0035 升级/降级/再升级与旧数据回填。
• Web 类型检查和生产构建通过，共生成 96 个路由，新增 /api/auth/workspaces 与 /api/auth/workspaces/switch；切换器状态测试 2/2 通过。
• Provider 验收及 Bandit 相关测试 7 项通过；中文请求 UTF-8、证据脱敏、参数安全和 18 条隔离黄金用例均有自动化断言。
• git diff --check 通过，仅存在 Windows 工作树 LF/CRLF 转换提示；未提交、未部署、未执行共享或生产数据库迁移。

9.10 第四阶段自动化开发结果（2026-08-02）

• 统一全局凭据与邮箱验证：新增迁移 20260802_0036、identity_account_credentials 和 identity_accounts.email_verified_at。一个全局账号最多保留一条全局密码凭据；同邮箱使用不同密码重复注册返回 409 并完整回滚，同一密码可继续创建或关联个人、组织工作空间。
• 旧账号渐进兼容：仅对“单成员、单凭据”的无歧义旧账号回填全局密码；历史 tenant_user_credentials.email_verified_at 不直接提升为全局邮箱验证。多空间、多凭据旧账号继续走兼容登录，完成邮箱验证或密码重置后再归并，避免迁移阶段错误合并账号。
• 跨空间安全边界：未验证全局邮箱只允许访问当前工作空间；验证后才开放同账号的有效工作空间列表与切换。全局密码登录只选择 active 用户，邀请未接受成员不能提前登录。密码重置旋转唯一全局密码后，新密码可登录全部成员空间，旧密码失效。
• 动态 Provider 协议兼容：AI Platform 新增 responses 与 chat_completions 可配置 wire API。Responses 适配支持 /responses、output_text/output 以及 input_tokens/output_tokens，HTTP 错误信息执行脱敏；当前参数仍从 Codex 运行时动态读取，不固定写入产品配置。
• 多工作空间浏览器闭环：个人/组织注册、四份协议、免工作空间 ID 登录、同邮箱候选凭据匹配、顶栏空间切换、非法切换、退出和并行会话隔离均通过真实浏览器验证。前端增加 127.0.0.1 开发资源允许来源，并将登录 401/429 稳定映射为不泄露账号状态的中文提示。

9.11 第四阶段真实 Provider 与回归证据

• 当前动态 Provider 摘要为 ccswitch / gpt-5.6-sol / responses。Key 只注入 8123 隔离内存进程，验收后进程和一次性服务密钥均已清理；安全扫描中 Provider Key、真实网关 URL、运行时 Authorization 均为 0 命中。
• 真实法律问答和合同审查各执行 1 条，外部调用、运行审计和 Provider 状态均为 succeeded，无 Provider 错误，共计 3357 tokens。这证明当前鉴权、Responses 协议、模型和联网链路可用。
• 黄金产品门禁结果为 failed、技术门禁 0/2：两条均出现 expected_source_not_retrieved，合同审查另有 missing_citations 与 severity_below_expected。根因是隔离内存知识文档使用随机 doc-*，未保留清单要求的 LAW-* 稳定 source ID；同时合同审查结构化 risk_items 仍由规则函数生成，Provider 目前只替换摘要。该结果不得表述为完整真实 Provider 验收通过。
• 脱敏证据位于 .runtime/v2-ai-provider-acceptance/2026-08-02-codex-current-full/ai-provider-acceptance-summary.json，仅保留 Provider、模型、状态、计数和问题代码。
• Contract API 最终 186/186 通过：工作流 97、治理 52、领域 5、身份/权限/迁移 32。0036 已在隔离 SQLite 完成 upgrade、downgrade、re-upgrade；未在共享或生产数据库执行迁移。
• AI Platform API 94/94 通过；Provider/发布工具定向 7/7 通过。生产预检仍因仓库示例配置包含 placeholders 而失败，这是有效发布阻断项，不能绕过。
• Web workspace 状态测试 2/2、TypeScript 类型检查、生产构建均通过，共生成 96 个路由。重启后的 Playwright 复核显示登录页和注册页 ready=complete、注册策略已加载、控制台 0 error。
• 本地服务已使用当前代码重启：Contract API http://127.0.0.1:8110、AI Platform http://127.0.0.1:8111、Web http://127.0.0.1:3021/login，均返回 200。后端 schema-check 的 warning 来自本地 SQLite、内存仓库和 Provider disabled，符合隔离开发运行边界。

9.12 下一阶段优先项（2026-08-02 更新）

1. P0 AI 黄金门禁：为 Phase13 知识资产建立稳定 LAW-* source ID 装载；让 Provider 结构化输出参与合同审查 risk_items、严重度和引用生成；先通过 10 条法律问答与 8 条合同审查，再扩展合同生成和条款推荐，最后在共享预发布环境持久化验收运行 ID。
2. P1 账号治理：增加账号合并、拆分、争议恢复、成员关系恢复的运营 API/UI；历史多密码账号需要明确的邮箱验证/密码重置引导；正式定义全局登录邮箱变更，避免与工作空间 AccountSettings.email 混淆。
3. P1 邀请与恢复：已有全局账号接受邀请时要求已认证会话或显式恢复确认，避免邀请 token 被解释为无条件密码轮换授权。
4. P1 发布与法务：完成四份政策的具名法务审核、正式版本、生效时间、历史版本和再次同意策略；清除生产示例占位符后重新执行严格预检。
5. P2 运营能力：补齐平台管理员多人治理、支持访问审计、个人套餐/配额/用量/支付、成员功能隐藏和数据退出。

9.13 第五阶段自动化开发结果（2026-08-02）

• P0 AI 黄金技术门禁通过：LegalCitation 从知识文档 reference 提取稳定 LAW-* 外部 source ID，memory/SQLite 内部仍使用原有随机 doc-* 主键，不改表、不迁移。Phase13 的 10 张知识卡以幂等方式装载到固定 phase13-golden 知识库，并明确标注为待法务复核材料、不是法条原文或法律批准。
• Provider 结构化合同审查：合同审查提示词要求严格 JSON；服务端以 extra=forbid 模型校验摘要、总体风险、风险项、严重度、建议和 citation_source_ids。每个风险项至少引用一个本次实际检索 source ID，总体风险必须等于最高风险项严重度；自由文本、未知引用和严重度不一致均不进入业务风险对象，而是按现有 fallback/failed 策略处理并留痕。
• 普通用户自助邮箱验证闭环：普通有效成员只能为当前会话邮箱和当前工作空间发送、确认验证码；越权确认在消费验证码前被拒绝，不消耗失败次数。租户管理员保留本工作空间成员管理能力，平台管理员保留全局能力。确认成功返回刷新后的全局账号会话。
• Web 邮箱验证与会话刷新：新增 /verify-email、/api/auth/email-verification/send 和 /api/auth/email-verification/confirm。同源代理强制使用签名会话中的邮箱，只有返回会话与当前工作空间、用户完全一致时才重写 cookie。所有登录、注册、邀请、密码重置和工作空间切换入口统一携带 email_verified_at；旧 cookie 兼容为未验证状态。
• 账号设置权威边界收口：个人设置 PATCH 只接受显示名、语言、时区、通知和偏好；tenant_id、user_id、登录邮箱、成员角色和审计操作者均由服务端上下文决定，客户端越权字段返回 422。读取设置时以全局账号邮箱和当前成员角色覆盖设置表中的历史副本，保持现有表结构兼容，不新增迁移。
• 密码与邀请语义：组织注册、邀请接受和密码重置统一要求 12-128 位密码；密码重置不再要求技术工作空间 ID。已有全局账号接受邀请时必须输入当前密码，不能借邀请 token 轮换全局凭据；邀请页同步区分“新用户设置密码”和“已有账号输入当前密码”，并提供密码重置入口。

9.14 第五阶段验证证据

• Contract API 使用全新隔离 SQLite 执行全量 189/189 通过；账号设置定向回归中身份管理 11/11、代理权限 6/6 通过。未执行共享或生产数据库迁移。
• AI Platform API 全量 99/99 通过；Provider/发布工具全量 13/13 通过。Phase13 专项覆盖 memory/SQLite source ID 兼容、虚构引用拒绝、结构化输出失败策略和 Provider URL 日志脱敏。
• 当前动态 Codex Provider 为 ccswitch / gpt-5.6-sol / responses。隔离内存实例执行法律问答 10 条、合同审查 8 条，技术门禁 18/18、问题数 0；状态为 needs_legal_review，法律批准 0/18。脱敏摘要位于 .runtime/v2-ai-provider-acceptance/2026-08-02-phase13-structured-full/ai-provider-acceptance-summary.json，不包含密钥、真实端点、完整提示词或完整响应。
• Web 会话映射测试 2/2、工作空间状态测试 2/2、TypeScript 类型检查和生产构建通过；构建生成 99 个页面/路由，包含新的邮箱验证页面和代理入口。
• Provider 验收临时端口和一次性服务密钥已清理；Provider Key 与真实 Provider URL 在修改代码和验收证据中均为 0 命中。常驻开发 AI 服务继续使用 Provider disabled，避免把真实凭据持久化到开发运行态。
• 最终运行态已重启：Contract API http://127.0.0.1:8110、AI Platform http://127.0.0.1:8111、Web http://127.0.0.1:3021/login 均返回 200。

9.15 后续优先项（取代 9.12 的当前执行顺序）

1. P0 法律与预发布交付：由具名法务复核 10 张知识卡及 18 条黄金结果，建立权威法条原文库、正式版本和生效记录；在共享预发布数据库持久化通过的验收运行 ID。当前隔离 memory 证据只能证明技术链路，不代表法律正确性或生产发布批准。
2. P1 邮件与账号恢复运营：接入真实 SMTP/邮件服务并执行浏览器端到端验收；定义全局登录邮箱变更的旧邮箱确认、新邮箱验证、冲突检查和恢复流程。当前仅完成开发挑战码与 API/UI 闭环，尚未验收真实邮件投递。
3. P1 账号争议治理：先建设 platform-only 只读冲突诊断列表和详情，再设计带 preview、幂等 operation ID、双人审批和完整审计的账号合并、拆分及成员关系恢复；不得直接以破坏性写接口起步。
4. P1 平台管理员治理：增加平台管理员只读名册和“不得停用最后一名有效平台管理员”保护；随后补充授予/撤销、支持访问时限与原因、双人审批和专用 before/after 审计。
5. P2 运营能力：补齐个人套餐、配额、用量、支付、成员功能隐藏、数据导出/删除和客户成功指标；四份公开政策仍需具名法务审核、正式版本、生效时间、历史版本与再次同意策略。

9.16 第六阶段自动化开发结果（2026-08-02）

• 平台管理员只读名册：新增 GET /api/v1/identity/platform-administrators，只返回管理员身份、工作空间、状态和最近登录等非凭据信息。后端以显式 platform_admin 权限为唯一跨空间边界；企业工作空间管理员返回 403，不能依赖固定用户 ID 或前端角色判断。
• 最后有效管理员保护：内存和 SQL 仓储均在成员状态更新时阻止停用最后一名有效平台管理员，API 返回 409。SQL 路径在同一事务内使用 SELECT ... FOR UPDATE 锁定有效管理员集合；Web 对该冲突显示中文运营提示。两名管理员时可停用其中一名，停用后其平台权限立即失效，独立凭据轮换不影响另一名管理员。
• 平台专属账号冲突诊断：新增 GET /api/v1/identity/account-conflicts 和详情路由。诊断复用现有全局账号、工作空间成员、租户用户和凭据表，不新增迁移、不写身份数据；支持严重度、冲突码、精确规范化邮箱和分页筛选。稳定 diagnostic_id 只由实体 ID 哈希生成，不把邮箱写入 URL 资源 ID。
• 冲突分类与最小披露：首期覆盖重复全局账号、缺失/孤立/重复成员关系、身份或状态漂移、所有者漂移、停用账号仍有有效成员、凭据身份/算法异常、有效身份无凭据和历史多凭据未归并。响应仅包含凭据作用域、状态、算法、更新时间和是否需要重置，禁止返回密码哈希、token、验证码或会话数据。相关访问纳入 identity.account_conflicts、S3、sensitive=true 的反滥用与访问留痕策略。
• Web 运营入口：新增 /admin/identity/conflicts 只读列表与详情工具页。只有平台名册请求成功时，身份管理页才显示诊断入口；企业管理员直接访问时不渲染跨空间统计或邮箱。页面提供严重度、冲突类型和精确邮箱筛选，不提供合并、拆分或恢复写操作。
• 工作空间语义收口：身份管理、管理首页和侧栏的面向用户文案从“用户与租户/公司租户”改为“用户与工作空间/组织工作空间”；技术 tenant_id 继续保留在内部 API 和平台治理详情，兼容现有数据模型和个人工作空间方案。

9.17 第六阶段验证证据

• 平台管理员治理定向用例 8/8、身份管理/安全/代理鉴权组合回归 31/31 通过；加入账号冲突诊断后，身份域组合回归为 35/35。
• Contract API 从仓库根目录首次执行全量时为 191/193，两项失败均因 Alembic 相对路径把 migrations 解析到仓库根目录，属于测试命令工作目录错误，不是业务断言失败。随后从 services/contract-api 目录、使用全新隔离 SQLite .test-runtime/contract-full-phase6-20260802-1332.sqlite3 重新执行，最终 195/195 通过，退出码为 0。未执行共享或生产数据库迁移。
• 账号冲突专项 4/4 通过：健康身份零误报；平台管理员 200、企业管理员 403、缺代理凭据 401；重复账号、状态/所有者漂移、异常算法和缺失成员关系可稳定定位；未知详情 404、page_size=101 为 422；响应递归扫描不含密码哈希、token 或验证码字段。
• Web 会话映射 2/2、工作空间状态 2/2、TypeScript 类型检查和生产构建通过；构建生成 100 个页面/路由，包含 /admin/identity/conflicts。
• git diff --check 通过，仅有工作区既有 CRLF 提示。Contract API、AI Platform 和 Web 已重启并分别在 8110、8111、3021 返回 200。
• 重启前在已登录 Codex 内置浏览器检查 /legal-documents、/workspace、/verify-email、/admin/identity 和 /admin，数据加载成功且控制台无 error；发现已登录访问 /login 仍显示登录表单，以及平台管理界面仍存在“租户”历史文案。后者本阶段已收口。Web 运行脚本每次启动随机生成会话签名密钥，因此重启后既有 cookie 失效；新诊断页的登录态可视化复核需用户重新登录后继续，不能把未完成的浏览器复核写成通过。

9.18 后续优先项（取代 9.15 的当前执行顺序）

1. P0 法律与预发布交付：仍需具名法务复核 10 张知识卡和 18 条黄金结果，并在共享预发布环境持久化批准记录；当前技术门禁不代表法律正确性或生产批准。
2. P1 邮件与账号恢复运营：接入真实 SMTP，完成发送、退信、限流、旧邮箱确认、新邮箱验证、冲突检查和恢复流程的浏览器端到端验收。
3. P1 账号争议写操作：以本阶段只读诊断为入口，设计账号合并、拆分和成员恢复的 preview、幂等 operation ID、双人审批、回滚策略和完整 before/after 审计；不得直接增加破坏性写接口。SQL 诊断当前按需聚合全表，进入大规模预发布前应增加候选集查询和性能基线。
4. P1 平台管理员完整治理：补充受控授予/撤销、支持访问原因和时限、双人审批及专用审计；最后管理员并发保护仍需真实 PostgreSQL 双请求集成验收。
5. P1 产品语义与会话体验：将开发环境的“默认租户”种子名称改为系统工作空间口径；明确已登录访问 /login 时是重定向工作台还是提供显式“切换账号”，避免当前重复登录表单语义。
6. P2 运营与测试效率：补齐个人套餐、配额、用量、支付、数据导出/删除和客户成功指标；在不降低密码哈希参数的前提下并行化身份测试夹具，缩短当前约 6 分钟的 Contract API 全量回归。

9.19 平台管理员登录态浏览器实测与修复复核（2026-08-02）

• 使用已登录平台管理员 admin@example.com 的 Codex 内置浏览器会话实测，/workspace、/admin/identity、/admin/identity/conflicts 和 /verify-email 均正常加载；本轮未伪造会话、未绕过服务端权限，也未执行账号合并、拆分、恢复或其他争议身份写操作。
• 身份管理页的平台管理员名册显示共 1 人、有效 1 人，平台专属账号冲突诊断入口可见；这与当前单管理员开发数据一致，但不替代多人治理、授权审批或并发保护验收。
• 账号冲突列表显示严重冲突 0、提醒 2。精确邮箱筛选以包含大写字母和首尾空格的输入执行，服务端按既有规则规范化后只返回目标项；切换到“严重”筛选时显示明确的零结果空状态，没有把提醒误计为严重冲突。
• 冲突详情可查看全局账号、租户用户、工作空间成员和凭据元数据。对页面返回对象执行递归字段扫描，未发现 password_hash、credential_hash、verification_code、access_token 或 refresh_token；该证据证明当前页面和 API 响应满足本阶段最小披露要求，不代表底层数据库不存在受控凭据字段。
• 全程浏览器控制台 error 和 warning 均为 0，仅出现开发环境 HMR 信息；未观察到页面加载、筛选、详情请求或权限请求错误。
• 首次实测发现三项产品质量问题：顶栏和管理员名册仍显示“默认租户”、组织注册按钮仍写“创建公司”、管理员初始密码被浏览器自动填入。另一开发 Agent 已将前两项统一为“系统工作空间”和“创建组织工作空间”，并将密码输入保持空值、设置为 new-password 自动填充语义，避免展示或复用已有凭据。
• 已登录访问 /login 的语义确定为自动返回 /workspace。真实浏览器复核确认最终 URL 为 /workspace、工作台标题存在且登录表单不再渲染，控制台 error/warning 为 0；未登录 /login 及注册、密码重置、邀请和政策页继续保持公开访问。
• 修复后 Web 路由测试 4/4、工作空间状态测试 3/3、身份页敏感默认值源码测试 1/1、会话映射测试 2/2 均通过，TypeScript 类型检查通过；浏览器刷新复核确认“系统工作空间”“创建组织工作空间”、密码空值和登录重定向均已生效。该复核只覆盖当前开发登录态和可见交互，不等同于真实 SMTP、共享预发布数据库或生产环境验收。

9.20 后续优先项（取代 9.18 的当前执行顺序）

1. P0 法律签批与共享预发布交付：仍需具名法务复核 10 张知识卡和 18 条黄金结果，建立权威法条原文、正式版本、生效记录和批准责任人，并在共享预发布环境持久化验收运行 ID。当前技术门禁和浏览器实测均不能替代法律正确性确认或生产发布批准。
2. P1 真实邮件与账号恢复运营：接入真实 SMTP/邮件服务，完成发送、退信、重试、限流、旧邮箱确认、新邮箱验证、冲突检查和恢复流程的浏览器端到端验收；当前开发挑战码闭环不得表述为真实邮件交付完成。
3. P1 账号争议写操作设计：以已通过登录态实测的只读冲突列表和详情为入口，设计账号合并、拆分及成员关系恢复的 preview、幂等 operation ID、双人审批、回滚策略和完整 before/after 审计；在方案和验收标准明确前不得直接增加破坏性写接口。SQL 诊断进入大规模预发布前仍需候选集查询和性能基线。
4. P1 平台管理员完整治理与并发验收：继续补充受控授予/撤销、支持访问原因和时限、双人审批及专用审计。最后有效管理员保护虽已通过本地定向回归，但仍需在真实 PostgreSQL 上执行双请求并发集成验收，不能以 SQLite 或单请求结果替代。
5. 原 9.18 第 5 项已完成并移出阻断：开发环境工作空间口径、组织创建命令和管理员密码输入语义已修正；已登录访问 /login 自动返回工作台，未登录及其他公开身份入口保持原行为。Web 路由 4/4、工作空间状态 3/3、身份页源码 1/1、会话映射 2/2、TypeScript 和登录态浏览器刷新复核均通过；后续如改变登录或切换账号策略，应作为独立会话需求重新评审，不回退本次已验收语义。
6. P2 运营与测试效率：补齐个人套餐、配额、用量、支付、数据导出/删除和客户成功指标；在不降低密码哈希参数的前提下并行化身份测试夹具，并建立账号冲突诊断的规模化查询和回归性能基线。

9.21 第七阶段自动化开发结果（2026-08-02）

• 账号冲突诊断扩展性收口：SQL 仓储不再把全局账号、租户用户、成员关系、工作空间和两类凭据整表加载为 ORM 对象，而是先以 SQL 发现异常候选，再沿账号、用户、成员关系和规范化邮箱组成的关系图加载候选详情。健康规模数据保持零误报，异常详情继续复用原冲突码、严重度、稳定诊断 ID 和最小披露模型，不增加身份写操作或迁移。
• 规范化与高基数边界：数据库诊断表达式使用与 Python str.strip() 等价的完整 Unicode 首尾空白集合；SQLite 对非 ASCII 大小写差异增加兼容候选扩展，PostgreSQL 使用 lower(btrim(...))。账号、用户、成员、凭据、邮箱和工作空间关联加载统一按每批 400 个值执行，避免大量异常候选超过 SQLite/PostgreSQL 绑定参数上限。缺失全局账号发现由相关子查询改为规范化账号邮箱集合的反连接，避免 SQLite 对每个用户重复扫描账号表。
• SMTP 协议与配置安全：验证码和邀请统一走一条 SMTP 发送路径；STARTTLS 与 SMTPS 互斥，生产禁止明文 SMTP，用户名与密码必须成对出现，环境密码与密码文件必须二选一。密码文件必须为可读、非空 UTF-8，SMTP 密码不进入对象 repr；发件人、收件人和显示名执行地址及头注入校验，邮件增加 Date、Message-ID、自动回复抑制头，底层 SMTP、网络和 Unicode 编码错误统一脱敏为 SMTP delivery failed.。
• 生产 SMTP secret 闭环：默认 disabled 模式继续使用管理员线下交付邀请链接，不要求 SMTP secret。新增可选 docker-compose.production.smtp.yml，仅在启用 SMTP 时把宿主机受保护密码文件只读挂载到固定容器路径，并清空直接密码环境变量。生产 preflight 同步校验 TLS 模式、主机、端口、超时、发件邮箱、头注入、HTTPS 非 loopback 公网地址、宿主机 secret 的绝对路径、非空和 POSIX owner-only 权限。
• 组织工作空间代开权限闭环：产品语义确定为“管理后台仅由平台管理员代开组织工作空间”，不改变公开自助注册这一独立旅程。签名 Web 会话兼容携带 platform_permissions；身份页只有会话能力与平台管理员名册实时验证同时成功时才显示代开表单，提交函数再次防护，Next.js 身份代理对 register-company 再执行实时平台权限复核。企业和个人工作空间管理员仍可管理本空间成员，但不能从管理后台代开新组织后落入旧会话导致 403。

9.22 第七阶段验证证据与后续优先项

• Contract API 使用全新隔离 SQLite 执行全量 211/211 通过；最终账号冲突、SMTP 和身份安全定向回归 32/32，生产发布工具 24/24，Web 定向回归 14/14，TypeScript 类型检查和实现 Agent 的 100 路由生产构建均通过。Python 编译、三份 Compose YAML 解析、生产示例 preflight 和 git diff --check 通过；差异检查仅有工作区既有 CRLF 提示。
• 账号冲突回归覆盖 300 组健康身份零误报、孤立成员、孤立全局/旧凭据、多旧凭据无统一凭据、Unicode/NBSP/Tab 规范化、关系图闭包稳定性，以及 1,001 个同时冲突候选。高基数用例确认单条 SELECT 绑定参数保持在分片上限内；响应递归检查继续不含密码哈希、token、验证码或会话秘密。
• SMTP 验收使用本机 TCP 假 SMTP 服务与真实 Python smtplib 完成协议命令和邮件内容往返；这证明应用 SMTP 客户端路径可运行，不代表外部邮件服务已接受、送达、退信或重试成功。当前机器没有 Docker CLI，未执行真实 docker compose config 或容器 secret 挂载；没有生产 SMTP 主机和凭据，未进行外部邮件投递。
• P0 法律签批与共享预发布交付仍未完成：需具名法务复核知识卡和黄金结果，建立权威法条、正式版本、生效记录、批准责任人，并在共享预发布环境持久化验收运行 ID。技术门禁、开发浏览器和本机协议测试均不能替代法律批准。
• P1 外部邮件与账号恢复运营：接入实际选定的 SMTP/邮件服务后，执行发送、送达、退信、重试、限流和浏览器端注册/验证/邀请/重置全旅程；继续设计全局登录邮箱变更的旧邮箱确认、新邮箱验证、冲突检查和恢复流程。
• P1 PostgreSQL 性能与并发验收：在共享预发布 PostgreSQL 上记录账号候选 SQL 的 EXPLAIN (ANALYZE, BUFFERS)、排序规则和高冲突基数基线，按证据决定是否新增规范化邮箱列或表达式索引；同时执行最后有效平台管理员保护的真实双请求并发测试。当前 SQLite、SQL 编译和分片测试不能替代该验收。
• P1 高权限写操作治理：账号合并、拆分、成员恢复以及平台管理员授予/撤销仍必须先定义 preview、幂等 operation ID、支持访问原因与时限、双人审批、回滚策略和 before/after 审计，不得从当前只读诊断直接扩展为无审批破坏性写接口。
• P2 产品表达与自动化：工作空间类型在单空间和多空间状态下仍需以独立“系统/个人/组织”标签一致表达；平台专属诊断页应增加前端精确路由守卫和真实 Route Handler 测试，覆盖当前权限、已撤权、旧会话和后端不可用四种状态。

9.23 第八阶段自动化开发结果（2026-08-02）

• 工作空间类型一致表达：签名 Web 会话兼容携带 workspace_type；单空间顶栏显示“系统/个人/组织工作空间”，多空间选择器为每一项显示“系统/个人/组织”标签。default 继续映射为系统工作空间，技术 tenant_id 和既有业务外键不变。旧会话缺少类型时，前端优先采用 /api/auth/workspaces 返回的当前工作空间类型，避免个人空间在最长七天的旧 cookie 生命周期内被误标为组织。
• 实时平台权限为最终依据：组织代开 BFF 不再让陈旧 cookie 权限反向否决后端实时授权。登录后新授予权限可立即通过实时平台名册校验，已撤权、后端不可用或实时校验失败均 fail closed 返回 403；未登录返回 401。会话权限只承担快速入口和路由预判，不能替代服务端实时授权。
• 平台身份路由可达性：平台管理员即使当前工作空间角色不是 admin，只要签名会话仍携带 platform_admin 声明，也可先进入 /admin/identity/**，再由页面和 BFF 执行实时平台权限复核；撤权后的陈旧声明最多允许到达守卫，不会读取跨工作空间数据或执行组织代开。
• 冲突页精确守卫：/admin/identity/conflicts 通过可执行保护资源编排先验证平台管理员名册，再加载冲突列表和详情。未授权或实时校验异常时，不调用任何冲突列表或详情函数，页面仅显示统一拒绝状态；授权成功后仍由每个后端接口独立执行平台权限校验。
• 高权限写操作治理方案：新增 V2-privileged-identity-operations-governance-2026-08-02.md，覆盖账号合并、账号拆分、成员关系恢复、平台管理员授予/撤销和受限支持访问五类操作，定义 preview、幂等 operation ID、双人审批、状态机、事务并发、回滚、before/after 审计、P0/P1/P2 Backlog、验收标准及回归清单。本阶段没有新增破坏性身份写接口、数据库迁移或生产操作。

9.24 第八阶段验证证据与后续优先项

• Web 定向回归 27/27 通过，覆盖登录入口、会话映射、工作空间类型回退、平台路由可达性、新授予、已撤权、旧会话、后端不可用、未授权不加载诊断数据和组织代开保护。TypeScript 类型检查通过，Next.js 生产构建通过并生成 100 个页面/路由；git diff --check 通过，仅有工作区既有 CRLF 提示。
• 已登录平台管理员浏览器刷新复核 /workspace、/admin/identity 和 /admin/identity/conflicts：顶栏显示“系统工作空间”，身份管理同时展示系统、个人和组织标签，组织代开表单只对当前平台管理员可见，冲突页显示严重 0、提醒 2；控制台无应用 error，代码热更新后仅出现一次开发环境 Fast Refresh 全量刷新 warning。Web、Contract API、AI Platform 分别在 3021、8110、8111 返回 200。
• P0 法律签批与共享预发布交付仍是发布阻断：具名法务复核、正式法律版本、生效记录、批准责任人和共享环境验收运行 ID 尚未完成，技术回归和浏览器实测不能替代法律批准。
• P1 特权身份操作实现：下一阶段按治理方案先实现只读 preview、幂等操作记录和审批状态机，再实现双人审批后的受控执行；回滚和 before/after 审计未通过验收前，不开放账号合并、拆分、成员恢复、平台权限授予/撤销或支持访问写操作。
• P1 真实外部依赖验收：仍需在共享 PostgreSQL 完成候选 SQL EXPLAIN (ANALYZE, BUFFERS)、最后有效平台管理员双请求并发验证，并在实际邮件服务上完成送达、退信、重试和限流。当前 SQLite、本地浏览器和本机假 SMTP 证据不能替代这些验收。
• P2 Route Handler 集成覆盖：当前授权核心和保护资源执行顺序已有运行时纯函数测试，仍应增加真实 Next.js Route Handler 级测试，覆盖签名 cookie 解析、代理头、401/403 状态码和成功转发，作为后续重构的回归保护。

9.25 第九阶段自动化开发结果（2026-08-02）

• 只读特权操作预览：新增平台管理员专属 POST /api/v1/identity/privileged-operations/preview，覆盖账号合并、账号拆分、成员关系恢复、平台管理员授予/撤销和限时支持访问六类预览。响应包含规范化目标、证据引用、preview_hash、expected_revisions、影响摘要、警告和到期时间；预览不修改账号、成员关系、凭据或权限。
• 幂等治理操作记录：新增 privileged_identity_operations。首次登记返回 201，同一操作 ID 与相同载荷重试返回原记录和 200，不同载荷复用同一 ID 返回 409 idempotency_conflict。提交时重新计算预览并校验哈希和版本，过期或陈旧预览不能登记。
• 双人审批状态机：新增 privileged_identity_operation_approvals。请求人不能自审批；审批人按全局账号去重；同一审批人重复同一决定保持幂等，不同决定返回冲突；两个不同且当前有效的平台管理员批准后进入 approved，任一拒绝进入 rejected。同审批人并发重放由唯一约束和冲突回读收口，不产生重复记录或 500。
• 执行边界保持关闭：后端只注册 preview、create、list、detail 和 approvals；没有 /execute、rollback、merge、split、recover、grant 或 revoke 身份写路由。前端只提供预览、治理登记和审批，不提供身份执行按钮；approved 仅表示审批完成，不改变任何身份数据。
• 治理运营页面：新增 /admin/identity/privileged-operations，支持六类动态预览字段、预览影响、审批登记、记录列表、详情和批准/拒绝；身份管理页只在平台管理员区域展示入口。客户端请求移入浏览器专用服务层，避免客户端组件导入依赖 next/headers 的服务端模块。
• 平台权限与旧会话收口：实时平台管理员名册继续作为组织代开的最终授权依据；身份治理路径允许携带平台声明但工作空间角色非 admin 的管理员先进入，再由页面/BFF/后端实时复核。单空间类型优先使用工作空间 API 结果，旧会话缺少 workspace_type 时不再把个人空间误标为组织。
• 兼容现有工作空间模型：迁移 20260802_0037 仅新增治理操作和审批表；TenantModel、tenant_id、个人/组织工作空间、全局账号、成员关系、凭据及业务数据归属均保持不变。账号合并只允许在未来执行阶段重映全局身份/成员归属，不得合并个人与组织工作空间业务数据。

9.26 第九阶段验证证据与后续优先项

• Contract API 使用全新隔离 SQLite 执行治理与迁移专项 9/9、身份/权限组合回归 45/45、全量 220/220；Python 编译通过。全新数据库从空库升级到 Alembic 单一 head 20260802_0037，迁移专项同时覆盖 downgrade 和再次 upgrade。
• Web 联合定向回归 34/34 通过；客户端模块边界修复后页面专项 2/2 和 TypeScript 再次通过。Next.js 生产构建成功生成 101 个页面/路由，包含 /admin/identity/privileged-operations；git diff --check 无错误，仅有既有 LF/CRLF 提示。
• 本地运行库 .runtime/contract-api-20260802.sqlite3 已先备份到 .runtime/db-backups/contract-api-20260802-before-0037-20260802-1900.sqlite3。该历史库由 create_all 建立且没有 Alembic 版本表；确认其具备 0036 身份表且不含治理表后，先标记 0036，再只执行 0037。Contract API 重新加载后，Web 3021、Contract API 8110、AI Platform 8111 均返回 200；Web 与 AI 服务未重启，现有登录会话保留。
• 已登录浏览器验收确认身份管理页存在“特权操作”入口；治理页展示六类预览、动态字段、执行关闭说明、空记录状态和禁用的审批提交初态。对现有普通成员执行平台管理员授予的只读预览，成功显示预览 ID、可提交状态和 platform_permissions_changed=1，但没有登记操作；尝试预览撤销唯一平台管理员时稳定阻断。页面全部交互控件只有返回、生成预览、提交双人审批和刷新，没有身份执行或直接写按钮；控制台 error/warning 为 0。
• P0 发布阻断仍不变：具名法务签批、正式法律版本与共享预发布验收运行 ID 尚未完成；本阶段身份治理能力不改变 AI 黄金门禁、外部邮件交付或法律正确性状态。
• P1 治理审计与执行器：下一步先增加追加式状态事件、稳定 trace_id、脱敏 before/after 快照和审计完整性，再在真实 PostgreSQL 验证并发提交、审批唯一约束、锁顺序和最后管理员保护。上述完成前不得实现或开放身份执行器。
• P1 执行与回滚后续阶段：账号合并、拆分、成员恢复、平台权限变更和支持访问必须通过统一执行器、固定锁顺序、版本复核、outbox、在线授权检查、自动到期和独立回滚审批；任何直连身份表的管理写接口继续作为 P0 阻断项。
• P1/P2 运营缺口：仍需真实工单校验、审批提醒、结果通知、审计导出、支持访问使用审计、审批 SLA/过期率仪表盘，以及真实邮件服务送达/退信/重试和全局邮箱恢复旅程。

9.27 第十阶段自动化开发结果（2026-08-02）

• 追加式治理状态事件：新增迁移 20260802_0038 和 privileged_identity_operation_events。每个操作使用唯一 (operation_id, sequence_no) 形成递增事件序列；提交、审批、拒绝和过期物化均与操作状态在同一事务追加事件。幂等提交重放和同审批人重复决定不会重复追加事件。
• 请求追踪持久化：治理事件保存既有请求上下文 trace_id。标准追踪值原样保存；异常或不受信任格式只保存不可逆指纹，避免把任意请求头写入审计记录。事件只读接口为 GET /api/v1/identity/privileged-operations/{operation_id}/events。
• 脱敏审计快照：snapshot_before / snapshot_after 仅保存存在标记、操作类型、状态、审批计数、引用数量、告警数量和目标引用指纹，不保存邮箱、姓名、凭据、token、secret、password 或原始目标值；前后快照分别保存 SHA-256 哈希供完整性复核。
• 过期状态落库：到期的 pending_approval 或 approved 操作在首次列表、详情、事件读取或审批触发时，在行锁保护下物化为 expired 并追加一次 operation_expired；后续读取不重复写事件。
• 只读审计时间线：特权操作详情页新增事件时间线，展示事件类型、状态转换、序号、时间、trace_id、脱敏计数摘要和快照哈希前缀。页面仍没有身份执行、回滚、合并、拆分、恢复、授予或撤销按钮。
• 身份执行器继续关闭：后端仍只注册 preview、create、list、detail、events 和 approvals；approved 只表示双人审批完成，不修改账号、成员关系、凭据、平台权限、支持访问授权或业务数据。

9.28 第十阶段验证证据与后续优先项

• SQLite 治理与迁移专项 9/9 通过；Contract API 全量 220 passed, 1 skipped，跳过项为需要显式连接参数的 PostgreSQL 专项。该 PostgreSQL 专项随后在 192.168.3.90:5432/yuqei_contract 的唯一临时 schema 中单独执行并 1/1 通过。
• 真实 PostgreSQL 证据覆盖：并发相同操作只创建 1 条操作和 1 条提交事件；同一审批人并发只创建 1 条审批和 1 条决定事件；两个不同审批人并发形成两条有序事件并最终进入 approved；拒绝保持终态；过期只物化一次；事件序号、trace_id、快照哈希和脱敏规则均通过；最后有效平台管理员撤销预览继续被阻断。
• PostgreSQL 测试按阶段运行 Alembic 到单一 head 20260802_0038，仅在 pg_trgm 索引迁移期间临时把 public 加入 search_path，其余迁移和运行时连接只使用测试 schema。夹具在 finally 中精确删除测试 schema。诊断试跑曾只推进公共 Alembic 标记而未创建事件表；已恢复公共标记为原基线 20260802_0037，确认公共事件表不存在、残留治理/诊断 schema 数量为 0。
• Web 治理定向回归 28/28、TypeScript 和 Python 编译通过；Next.js 生产构建成功生成 101 个页面/路由；git diff --check 无错误，仅有既有 LF/CRLF 提示。Alembic 当前代码 head 为 20260802_0038。
• 后续 P1 门槛：统一身份执行器、执行前版本复核、固定实体锁顺序、outbox、支持访问在线鉴权与自动到期、失败补偿、独立回滚预览/审批/演练、真实工单校验和通知仍未实现。在这些门槛通过前，身份执行器必须继续关闭。

9.29 第十阶段最终交付复核（2026-08-02）

• 已登录平台管理员浏览器复核 /admin/identity/privileged-operations 的合成治理记录 op_browser_events_20260802。详情按纵向分组显示“登记操作”、初始状态 -> 待审批、序号/时间、脱敏审批与引用计数、trace_id: trace-browser-submit-20260802 和快照哈希前缀；桌面全页截图未发现文字重叠或元数据挤压，控制台 error/warn 为 0。
• 浏览器页面持续明确“治理记录不执行身份变更”，且只存在 preview、登记、列表、详情、events 与 approvals 交互。运行中 Contract API OpenAPI 复核得到破坏性身份写路径数量 0，未暴露 execute、rollback、merge、split、recover、grant 或 revoke 路径。
• 独立质量复核后新增迁移 20260802_0039：SQLite 使用两个拒绝触发器、PostgreSQL 使用单一 BEFORE UPDATE OR DELETE 触发器，数据库层直接修改或删除治理事件均失败；本地自动建库路径同步安装等价保护。列表与详情也统一映射过期物化等治理异常，避免极端并发冲突退化为 500。
• 最终本地复核新增执行 Web 全部 *.test.mjs，结果 34/34；治理迁移、不可变触发器、错误映射与操作专项在隔离内存数据库下 10/10；TypeScript、Python 编译、101 路由 Next.js 生产构建和 git diff --check 通过。Web 3021、Contract API 8110、AI Platform 8111 均返回 200，Alembic 代码为单一 head 20260802_0039。
• 本阶段交付结论不变：追加式事件、追踪、脱敏快照和真实 PostgreSQL 并发门槛已完成；身份执行器仍为关闭状态。下一阶段不得直接开放破坏性写入口，必须先单独评审统一执行器、固定锁顺序、版本复核、outbox、失败补偿、支持访问在线鉴权和独立回滚治理。

9.30 第十一阶段 transactional outbox 最小切片（2026-08-02）

• 新增 20260802_0040 加法迁移、ORM 和 privileged_identity_outbox_messages。操作与事件外键均为 NO ACTION；状态、尝试次数、唯一事件/effect 和唯一幂等键由数据库约束，投递扫描与操作详情均有索引。
• 0040 不回填 0038/0039 的历史事件，避免旧治理状态在部署后被重新投递；投递状态从升级后新事件开始记录。
• 提交、批准、拒绝和过期事件与脱敏 outbox 消息在同一事务写入。相同操作或审批幂等重放不新增事件或消息；消息 payload 不包含原始身份目标、操作者信息或凭据类字段。
• worker repository 已具备 PostgreSQL FOR UPDATE SKIP LOCKED、租约、过期重领、指数退避、最大重试和 dead_letter 基座；SQLite 使用 BEGIN IMMEDIATE 防重复领取且部署明确限制单进程单 worker。当前未接任何外部 transport。
• 平台管理员详情新增只读 delivery-status，前端只展示投递状态和尝试次数；API 不返回 payload、lease owner 或错误详情，且未增加发送、重试或执行控件。
• 回归门槛：SQLite 治理与迁移专项 18/18（包含底层并发认领互斥）、页面专项 Node 2/2、Web 全量 Node 34/34、TypeScript、Python compileall 和 101 路由生产构建已通过。PostgreSQL 专项已在 192.168.3.90:5432/yuqei_contract 的隔离临时 schema 中 1/1 通过，校验 0040 head、outbox/事件数量一致、并发认领不重复、租约恢复、稳定幂等键、重试和 dead-letter；测试 schema 已精确清理。
• 身份执行器继续关闭；execute、rollback、merge、split、recover、grant、revoke、真实 support access 写入及人工 outbox retry 仍属禁止范围。

9.31 第十二阶段：全局 outbox 只读可观测与死信排查（已交付，2026-08-02）

本阶段优先级为 P1 运营可观测，仅复用 0040 数据模型，不新增迁移。目标是让有效平台管理员在不触发任何数据库写入、消息认领或外部副作用的前提下判断 outbox 全局健康并定位 dead-letter；它不是 transport、人工重试或身份执行器的发布阶段。

可执行 Backlog：

1. P1-OBS-1 后端只读聚合（完成）：已增加状态计数、活跃总数、最老活跃消息年龄、超龄活跃数、过期 processing 租约数、临近最大尝试数和 dead-letter 稳定错误码聚合。活跃状态固定为 queued/processing/retry_scheduled，默认超龄阈值 900 秒。
2. P1-OBS-2 独立只读 API（完成）：已增加 GET /api/v1/identity/privileged-outbox/overview 和 GET /api/v1/identity/privileged-outbox/dead-letters；只允许实时有效的平台管理员，禁止调用过期物化、claim、retry 或状态迁移方法。
3. P1-OBS-3 死信分页排查（完成）：已按 updated_at DESC, message_id DESC 稳定排序，支持稳定错误码过滤和有上限的分页；operation type、effect type 作为只读上下文返回，本切片未增加对应组合筛选。响应只返回不透明关联 ID、安全 trace_id、类型、尝试次数、稳定错误码和时间字段。
4. P1-OBS-4 前端只读运营区（完成）：特权身份治理页已增加全局投递健康摘要和 dead-letter 排查区，覆盖 loading、healthy/degraded/critical、空队列、空筛选结果、分页和后端失败状态；不存在 retry、ack、requeue、send、execute 或其他消息/身份动作按钮。
5. P1-OBS-5 回归与泄露门禁（完成）：已覆盖平台管理员 200、个人/企业管理员 403、空队列、阈值边界、健康优先级、聚合、稳定分页/过滤/排序、GET 前后数据库完全不变、禁用 transport 不 claim、OpenAPI 破坏性路径扫描、S3 反滥用策略和响应敏感字段扫描。
6. P1-OBS-6 PostgreSQL 证据补齐（完成）：已在 192.168.3.90:5432/yuqei_contract 的隔离临时 schema 中复跑并 1/1 通过，覆盖 0040 迁移、并发认领、租约恢复、重试/dead-letter、稳定错误码聚合/过滤，以及 overview/dead-letter 查询前后 operation、approval、event、outbox 全字段快照完全一致；测试后已精确清理 schema。

本地验收结果：治理与迁移专项 20/20、反滥用专项 9/9、Web 全量 Node 36/36、页面专项 4/4、真实 PostgreSQL 0040/并发/租约/死信/只读一致性专项 1/1、TypeScript、Python compileall、单一 Alembic head 20260802_0040、101 路由生产构建及 git diff --check 通过；运行时两个新 GET 各注册 1 条，outbox 写方法数量为 0，桌面与 390px 移动视图加载成功且浏览器控制台 error 为 0。Contract API 全量测试未在本检查点复跑，仍作为独立发布证据缺口保留。

验收标准：

• 空队列为 healthy；存在 dead letter 或过期 processing 租约为 critical；否则存在超龄活跃消息或临近最大尝试消息为 degraded；其余为 healthy。
• 两个 GET 前后 operation、approval、event、outbox 的行数、状态、attempt、lease、时间戳、payload 和 hash 完全不变；实现不得调用 _materialize_expired_operations。
• 响应不得包含 payload、payload hash、idempotency key、lease owner/token、原始错误详情、目标指纹、快照/哈希、actor、邮箱、姓名、账号/成员身份、工单正文、凭据或 secret；空错误码聚合为固定 unknown。
• dead-letter 分页无重复或遗漏，组合过滤准确，同时间记录排序确定；非法分页和阈值参数返回稳定 422。
• transport disabled 时发送和认领数量继续为 0；OpenAPI 只新增两个 GET，破坏性身份写路径和人工 outbox 写路径数量均为 0。
• 后端和 Web 定向测试、TypeScript、Python 编译、生产构建及 git diff --check 通过；PostgreSQL 专项必须单列真实结果，本阶段真实结果为 1/1 通过且测试 schema 已清理，未以 SQLite 结果代替。

运营 SOP：先在 overview 记录查询时刻、阈值和风险计数，再在 dead-letters 按稳定错误码及类型过滤，使用安全 trace_id 和不透明 ID 在受控日志中关联部署/消费者/依赖证据。不得把 payload、原始目标、actor 或错误详情复制到普通工单，不得直接修改 outbox 或人工发送。critical 立即升级身份治理与平台值班负责人；修复必须走独立代码/配置变更评审，历史 dead-letter 继续保留为证据，当前阶段不提供 retry/ack。

明确非目标：不新增 0041，不回填历史事件，不启用 transport，不接 SMTP/工单/Webhook，不新增 POST retry/requeue/ack，不开放身份执行器、支持访问或 execute/rollback/merge/split/recover/grant/revoke。真实 PostgreSQL 0040 并发验证虽已完成，但在 transport 选择、消费者幂等契约和外发关联风险评审完成前，仍不得推进多 worker 或真实副作用投递。

9.32 第十三阶段：outbox 数据完整性加固（已交付，2026-08-03）

9.31 的“不新增 0041”是只读可观测阶段的范围约束。本阶段根据独立质量复核结果，以新的加法迁移 20260803_0041 单独处理两个数据库完整性缺口，不修改 0040 历史迁移，也不扩大产品能力。

1. P1-INT-1 事件归属复合约束（完成）：事件表增加唯一 (operation_id, event_id) 索引；outbox 增加同列复合外键并使用 ON DELETE NO ACTION。SQLite 默认可能关闭外键执行，迁移与自动建库路径另安装 INSERT/UPDATE 拒绝触发器；PostgreSQL 由复合外键执行。两种数据库均拒绝跨 operation/event 拼接，避免详情、死信上下文和未来消费者看到错误审计归属。
2. P1-INT-2 租约状态约束（完成）：processing 必须同时存在 lease owner/expiry，其他状态必须同时清空两项。暂不扩大到 delivered timestamp、last attempt 或 error code 状态机，避免在未完成设计前增加额外语义。
3. P1-INT-3 升级预检与回滚（完成）：0041 升级最先只读统计跨操作错配和非法租约行；任一计数非零立即拒绝，不自动修复、删除或重排。downgrade 只移除本阶段约束和索引，不改写业务数据。
4. P1-INT-4 SQLite/PostgreSQL 一致性（完成）：SQLite batch-recreate outbox 并安装关联拒绝触发器，0039 事件不可变触发器继续有效；PostgreSQL 使用复合外键与 CHECK。发布时须短暂停止治理写流量，避免索引/约束验证锁与新治理提交竞争。
5. P1-INT-5 自动化证据（完成）：SQLite 迁移 2/2、治理/worker 19/19、真实 PostgreSQL 1/1，组合专项 22/22。真实 PostgreSQL 覆盖 0041 head、约束元数据、非法关联/租约拒绝、并发 claim、租约恢复、重试/dead-letter、只读快照不变和隔离 schema 清理。
6. P1-INT-6 全模块回归（完成）：Contract API 单进程运行在 10 分钟命令上限处终止且无失败堆栈，不据此宣称通过；随后四个隔离进程覆盖全部 24 个测试模块，收集并执行 234/234 项全部通过。分组结果为合同工作流 91/91、身份与授权 83/83、0041/特权身份/PostgreSQL 22/22、基础设施与迁移 38/38。

当前单一 Alembic head 为 20260803_0041；Python compileall 和 git diff --check 通过。本阶段不新增 API、DTO、Web 或 transport 逻辑，身份执行器、真实 support access、人工 outbox retry 及 execute/rollback/merge/split/recover/grant/revoke 继续关闭。下一阶段仍须先完成 transport 选择、消费者幂等契约与外发关联风险评审，不得把数据库完整性加固解释为真实副作用或身份写入获准上线。

本地运行库已在停服备份后由 0040 升级到 0041；升级前 outbox、跨操作错配和非法租约计数均为 0，备份文件为 .runtime/db-backups/contract-api-20260802-before-0041-20260803-012502.sqlite3。补充 SQLite 触发器后已完成 0041 downgrade/upgrade 循环，复合索引、复合外键、租约 CHECK 和两条关联拒绝触发器复核通过；Contract API 重启并在 8110 返回 200，Web 3021 与 AI Platform 8111 保持运行，现有 Web 会话未因本次迁移重启。

9.33 第十四阶段：外发安全契约与消费者幂等参考实现（已交付，2026-08-03）

本阶段完成 9.32 要求的 transport 前置契约，但不选择或连接真实 provider。目标是冻结外发最小字段、认证和 ACK 语义，并用无网络参考消费者验证 at-least-once 重投不会重复业务副作用；它不是 transport、通知或身份执行器上线阶段。

1. P0-EGRESS-1 最小安全 envelope（完成）：新增 privileged-identity-egress.v1，只包含 contract/key ID、外部 delivery key、effect/event/operation type、状态转换和发生时间。禁止外发 message/event/operation ID、内部幂等键、trace ID、目标指纹、快照及哈希、actor、工作空间/用户 ID、reason、ticket、邮箱和凭据。
2. P0-EGRESS-2 域隔离认证（完成）：外部 delivery key 由独立、稳定的幂等密钥对内部幂等键执行域隔离 HMAC；规范化 envelope 生成 SHA-256 body digest，再由带 key ID 的可轮换签名密钥签名。两类密钥均少于 32 bytes 时在消息 claim 前拒绝启动；签名轮换会改变 key ID/signature，但同一消息的 delivery key 在租约重领和 worker 重启后保持不变。
3. P0-EGRESS-3 类型化 receipt（完成）：transport 契约从 deliver(message) -> None 收口为 deliver(envelope) -> receipt，结果固定为 accepted/duplicate/retryable_failure/permanent_failure。只有 delivery key 与 digest 同时匹配的 accepted/duplicate 才确认 delivered；retryable 进入既有退避，permanent、未知 receipt 或 ACK 不匹配进入 dead-letter，并仅保存稳定错误码。
4. P0-EGRESS-4 消费者幂等参考（完成）：参考消费者按 (consumer_id, delivery_key) 保存 receipt；相同 key/digest 返回 duplicate，不重复副作用；相同 key/不同 digest 永久拒绝为 idempotency_conflict。签名失败、未知 schema major 和载荷超限均永久拒绝；可重试依赖失败返回稳定 consumer_unavailable。该内存实现只用于契约和 ACK 丢失测试，生产消费者必须将 receipt 与业务副作用置于同一持久化事务。
5. P0-EGRESS-5 封闭测试旁路（完成）：移除 worker 的 run_once(deliver=...) 回调旁路，所有启用场景必须显式注入类型化 transport 和 delivery contract。默认 transport 继续 disabled，run_once() 返回 0 且不 claim；未配置 contract 的 enabled transport 在 claim 前失败。
6. P0-EGRESS-6 回归证据（完成）：新增契约与 worker 定向 8/8，特权身份操作 20/20，SQLite 0041 迁移 2/2，真实 PostgreSQL 隔离 schema 1/1。PostgreSQL 覆盖并发认领、租约恢复前后 envelope/delivery key/digest/signature 稳定、敏感关联字段不外发、重试/dead-letter、0041 完整性和 schema 清理。

明确非目标：不增加迁移、API 或 Web 页面；不连接 SMTP、工单、Webhook 或其他真实网络端点；不新增人工 retry/requeue/ack；不回填历史消息；不开放 execute、rollback、merge、split、recover、grant、revoke、真实 support access 或任何身份写入口。发送语义仍为 at-least-once，不宣称 exactly-once。

下一阶段候选必须单独评审：一是审批 SLA/临期与超期只读队列，二是统一身份执行器的只读 preflight 和固定锁计划。任何真实 transport 仍须先完成固定目标 allowlist、TLS/服务认证、持久化消费者 inbox、背压/保留、访问审计、密钥轮换与外部 provider 验收；SMTP 不直接消费治理 outbox。

9.34 第十五阶段：统一执行器只读 preflight 与固定锁计划（已交付，2026-08-03）

本阶段完成未来统一执行器的只读验证契约，不增加 execute API，不获取真实数据库写锁，不写账号、工作空间、成员关系、凭据、权限、operation、approval、event 或 outbox。

1. P0-PREFLIGHT-1 可验证 preview 材料（完成）：新增加法迁移 20260803_0042，新操作保存原始 preview_expires_at；历史操作保持 NULL，不推测回填并返回 preview_verification_material_missing。
2. P0-PREFLIGHT-2 审批时效与权限复核（完成）：复核 operation 状态/到期、两名不同有效审批人、请求人隔离、approval expiry、preview hash、审批时 permission revision，以及审批人当前账号、用户、成员和平台权限状态。
3. P0-PREFLIGHT-3 revision 与当前状态复核（完成）：重新构建原始 preview，比较 expected/current entity revision，并再次执行当前目标校验；缺失/非法 revision 材料、revision scope 不一致、漂移、缺失资源或当前状态非法均返回稳定 blocker，ready=false。
4. P0-PREFLIGHT-4 固定锁计划（完成）：描述性顺序固定为 operation、approval set、identity account、workspace、tenant user、workspace membership、global credential、legacy credential；同类按 ID 排序。GET 始终返回 locks_acquired=false，未来执行事务不得复用 GET 结果代替锁内复核。
5. P0-PREFLIGHT-5 只读 API 与 Web（完成）：只增加 GET .../{operation_id}/execution-preflight；页面展示 readiness、blockers、revision 和锁计划，同时明确 executor_enabled=false。没有执行、回滚或身份动作按钮。
6. P0-PREFLIGHT-6 自动化证据（完成）：SQLite 特权操作 23/23、安全投递契约 6/6、迁移 2/2（组合 31/31）、Web 全量源码测试 37/37、页面 5/5、TypeScript、Python compileall、Alembic head 20260803_0042 和真实 PostgreSQL 隔离 schema 1/1 通过。PostgreSQL 验证 ready、revision 漂移、查询前后治理/身份全字段快照不变并清理测试 schema。

验收语义：ready=true 仅表示查询时刻审批、preview、权限、revision 和当前状态检查均通过，不是执行授权票据，不表示锁已持有或身份已变更；approved 仍只表示治理审批完成。preflight 不物化过期状态、不追加事件/outbox，OpenAPI 中该路径无 POST/PUT/PATCH/DELETE，全局破坏性身份写路径仍为 0。

后续 P0 backlog：独立评审真实事务执行状态机、execution attempt 幂等记录、固定锁真实获取、锁内二次复核、失败补偿、outbox 副作用、support access 在线鉴权/自动到期和独立 rollback 治理。在这些门槛完成前，身份执行器、真实 support access、execute/rollback/merge/split/recover/grant/revoke 和人工 outbox 写入口继续关闭。

运行环境已在停服备份后由 0041 升级到 0042，备份为 .runtime/db-backups/contract-api-20260802-before-0042-20260803-041600.sqlite3；Contract API 8110 重启健康，Web 3021 和 AI Platform 8111 保持运行。运行态 OpenAPI 复核 preflight 只有 GET，身份域破坏性路径数量为 0。

9.35 第十六阶段：审批 SLA 临期与超期只读队列（已交付，2026-08-03）

本阶段完成剩余 P1 运营可见性切片，不新增迁移或写入口，不物化超期状态。

1. P1-SLA-1 只读 overview（完成）：新增 GET /identity/privileged-approval-sla/overview，按可控观察窗口和临期阈值返回 on_track/due_soon/breached 总量，不返回操作正文或身份信息。
2. P1-SLA-2 稳定分页队列（完成）：新增 GET-only queue，支持三档状态筛选和有界分页；按风险、到期时间、operation ID 确定排序，返回有效/所需/剩余审批数和时间字段。
3. P1-SLA-3 当前有效审批语义（完成）：审批过期、preview hash 不一致、permission revision 漂移或审批人当前失权均不计入有效审批；不披露审批人、评论或身份字段。
4. P1-SLA-4 严格只读（完成）：查询不调用 _materialize_expired_operations，超期只报告 breached；operation、approval、event、outbox 与身份数据不变，不 claim、retry 或产生外部副作用。
5. P1-SLA-5 Web 与 S3 门禁（完成）：治理页增加摘要、筛选和分页队列，客户端仅发 GET；两个路由纳入敏感 S3 反滥用策略，没有审批、处置、执行或消息动作。
6. P1-SLA-6 自动化证据（完成）：SQLite 组合 45/45、真实 PostgreSQL 隔离 schema 1/1、Web 全量 38/38、页面 6/6、TypeScript、Python compileall、Alembic head 20260803_0042 和 diff-check 通过。

运营口径：默认观察最近 7 天创建的 pending approval，临期阈值 1 小时；可将窗口扩至 31 天。窗口外记录继续存在于操作、事件和审计证据中，值班人员应定期扩大窗口复核历史积压。breached 只表示当前查询时刻已超过审批期限，不等于数据库状态已物化为 expired。

后续仍不得直接开放身份执行。下一阶段优先评审 execution attempt 的追加式幂等记录和失败状态机，或补齐长期积压跨窗口汇总；任一方向均不得引入真实身份写入、support access 或 execute API，除非另行完成锁内复核、补偿、outbox、回滚和安全评审。

9.36 第十七阶段：跨时间窗长期审批积压只读可见性（已交付，2026-08-03）

本阶段补齐第十六阶段窗口外长期待审批记录的运营盲区，只扩展既有 overview/queue 的只读查询口径，不增加迁移、状态物化、处置动作或身份写入口。

1. P1-SLA-AGE-1 全量与窗口外 overview（完成）：overview 在既有窗口内三档计数之外，返回 all_pending_total、outside_window_pending_count、outside_window_breached_count 和 oldest_pending_age_seconds。所有指标基于 stored pending_approval 直接只读统计，不调用 list_operations 或 _materialize_expired_operations。
2. P1-SLA-AGE-2 queue scope（完成）：queue 新增 scope=window|all，默认 window，响应回显 scope；all 可查看窗口外长期积压，继续支持三档筛选、有界分页及风险/到期时间/operation ID 的确定性排序。非法 scope 返回 422。
3. P1-SLA-AGE-3 最小披露与权限（完成）：两个 scope 均只向当前有效平台管理员返回既有最小字段；禁止 reason、ticket、target/evidence、actor、审批人/评论、邮箱、姓名、账号/成员 ID、preview/revision、payload 和凭据字段。个人用户、企业成员/管理员及失权管理员不能读取全量积压。
4. P1-SLA-AGE-4 严格只读与 S3（完成）：overview/queue 查询前后 operation、approval、event、outbox 和身份全字段快照一致，不物化超期、不 claim/retry、不产生外部副作用；两个 GET 继续受 identity.privileged_approval_sla.read 敏感 S3 策略保护。
5. P1-SLA-AGE-5 Web 分段口径（完成）：治理页提供“最近 7 天/全部积压”分段控件，展示全量、窗口外、窗口外超期和最老积压年龄；scope 切换重置分页并只发 GET，不增加 approve/reject、execute、retry、requeue 或其他处置按钮。
6. P1-SLA-AGE-6 自动化证据（完成）：SQLite/API 组合 45/45、真实 PostgreSQL 隔离 schema 1/1、Web 全量 39/39、页面专项 7/7、TypeScript、Python compileall、Alembic 单一 head 20260803_0042 和 git diff --check 通过。运行态 OpenAPI 中两个 SLA 路由均为 GET-only，身份破坏性写路径为 0；桌面与 390x844 浏览器回归通过，控制台 error 为 0。

验收口径：all_pending_total = window_pending_total + outside_window_pending_count；outside_window_breached_count <= outside_window_pending_count；空队列的最老年龄为 null，非空时为非负秒数。scope=all 只扩大待审批记录的时间范围，不扩大字段、租户、角色或动作权限。breached 仍只是查询时刻的运营告警分类，不等于数据库状态已写成 expired。

明确非目标：不新增数据库迁移，不回填、归档、删除或修改历史 operation/approval/event/outbox；不启用 transport、support access、身份执行器或人工消息/审批处置；不新增 execute/rollback/merge/split/recover/grant/revoke。下一阶段真实身份执行仍需独立完成 execution attempt 幂等、固定锁真实获取、锁内二次复核、失败补偿、outbox 副作用和 rollback 安全评审。

9.37 第十八阶段：追加式执行尝试账本与失败状态机（已交付，2026-08-03）

本阶段只建设未来统一执行器的内部持久化和只读观测基础，不实现身份 mutation，不启用执行器，不新增运行时 attempt 写入口或 execute API。

1. P0-ATTEMPT-1 不可变 attempt 根（完成）：新增 privileged_identity_execution_attempts，保存 operation 关联、递增 attempt number、幂等键、request/preview/preflight SHA-256、脱敏 trace_id 和创建时间。仅已审批且未过期、request/preview 与 operation 一致的内部调用可以登记。
2. P0-ATTEMPT-2 追加式状态事件（完成）：新增 privileged_identity_execution_attempt_events，保存确定性事件 ID、sequence、固定 event/status 映射、稳定错误码、脱敏前后快照及哈希、event payload hash 和 trace_id。current status 只从最后事件派生，不新增可变 current-status 列。
3. P0-ATTEMPT-3 精确失败状态机（完成）：合法转换冻结为 prepared -> running|aborted、running -> succeeded|failed|compensation_required、compensation_required -> compensated|compensation_failed；所有其他转换拒绝，五个终态不可继续迁移。
4. P0-ATTEMPT-4 并发幂等与数据库保护（完成）：相同幂等材料重放不增行，不同材料冲突；相同 event payload 重放不增行。数据库唯一约束保护 attempt number、idempotency key、event sequence 和 event payload；SQLite/PostgreSQL 触发器禁止 attempt/event UPDATE 与 DELETE，外键为 NO ACTION。
5. P0-ATTEMPT-5 脱敏快照与最小披露（完成）：快照只接受固定状态、类型、计数、哈希、结果码和布尔字段；原始错误、target/evidence、actor、邮箱、身份详情和凭据被拒绝。只读 GET 仅返回 attempt 摘要，固定 executor_enabled=false，不返回幂等键、哈希或快照。
6. P0-ATTEMPT-6 GET-only Web 可见性（完成）：治理详情页读取 execution attempts 并展示序号、派生状态、事件数、稳定错误码、trace_id 和时间；具备加载/空/不可用状态，无 execute/retry/compensate/abort/rollback 按钮。OpenAPI execution-attempts 只有 GET，内部 register/append 未暴露为 route。
7. P0-ATTEMPT-7 自动化证据（完成）：SQLite/API 组合 47/47、迁移专项 2/2、真实 PostgreSQL 隔离 schema 1/1、Web 全量 40/40、页面专项 8/8、TypeScript、Python compileall 和 git diff --check 通过。Alembic 单一 head 升至 20260803_0043；PostgreSQL 并发覆盖相同幂等键和相同事件仅落一份，隔离 schema 已清理，凭据未落盘。

验收口径：attempt 根与事件只能追加，不能 UPDATE/DELETE；状态、事件数、最后错误码和最近时间从事件派生；重放不增加行；非法转换、原始错误和敏感快照返回稳定错误；GET 前后 operation、approval、operation event、outbox、身份实体及 execution ledger 全字段快照一致；普通用户和失权管理员不可读；响应不含幂等键、request/preview/preflight hash、快照、raw error、target/evidence、actor 或凭据。

明确非目标：本阶段不获取真实身份资源锁，不执行 lock 内二次 preflight，不修改全局账号、工作空间投影、成员、凭据或平台权限，不投递 attempt outbox，不执行补偿/rollback，不启用 support access、transport 或 identity executor，不新增 execute/rollback/merge/split/recover/grant/revoke/retry/requeue/ack API。下一阶段优先建设内部固定锁真实获取与锁内二次复核，仍保持验证事务无身份写入且不提供 execute API。

9.38 第十九阶段：固定锁真实获取与锁内二次复核（已交付，2026-08-09）

本阶段只把既有只读 preflight 和描述性 lock plan 落为内部 PostgreSQL 验证事务，不开放 execute API，不修改身份实体、operation、approval、event、outbox 或 execution ledger。

1. P0-LOCK-1 内部锁事务（完成）：新增内部 recheck_execution_preflight_under_lock()；仅当前有效平台管理员上下文可调用，方法未注册为 route。PostgreSQL 先设置 50-10000ms 有界 lock_timeout，再按固定 rank 获取 operation、approval set、身份主体和 preview revision 资源行锁，同类按 ID 排序。
2. P0-LOCK-2 权限主体保护（完成）：实际锁集合补充调用者和审批人的账号、工作空间、用户及成员关系保护行，避免权限在锁内失效；公开 GET lock plan 仍保持最小披露，不将内部主体扩展伪装为执行授权。
3. P0-LOCK-3 锁内新鲜复核（完成）：锁获取后失效 ORM identity map，再复核 operation 到期、审批 quorum/expiry、preview hash、permission revision、expected/current revision 和当前目标状态；ready 结果不是执行票据，executor_enabled 仍为 false。
4. P0-LOCK-4 只读与释放（完成）：事务只允许 SELECT、SET LOCAL lock_timeout 和内存校验；检测 session 无新增/脏/删除对象。ready、blocker、422 参数错误和 423 锁超时均不产生身份或治理写入，超时回滚并释放已取得锁。
5. P0-LOCK-5 并发证据（完成）：真实 PostgreSQL 隔离 schema 1/1 覆盖真实 FOR UPDATE 顺序、反向账号合并输入无死锁、50ms 锁超时、超时后锁释放、revision 漂移、审批过期、审批人失权和全字段快照不变；随机 schema 已清理，凭据未落盘。
6. P0-LOCK-6 运行态守卫（完成）：Web 全量 41/41、页面专项 9/9、TypeScript、Python compileall 和 git diff --check 通过；运行态 execution-attempts 仅 GET，身份破坏性写路径 0。桌面和 390x844 窄屏页面无水平溢出，详情页显示执行尝试历史及“只读 · 执行器关闭”，控制台无应用 error。

验收口径：锁前检查不得替代锁内复核；锁后读取必须使用新鲜 ORM/数据库状态；锁集合必须按固定 rank 和同类 ID 顺序获取；任何 blocker 或锁超时都 fail closed；验证事务前后 operation、approval、event、outbox、execution ledger 及身份表全字段快照一致。

明确非目标：本阶段不编译或执行真实身份 mutation，不生成或投递 attempt outbox，不启用 support access、transport、补偿执行或 rollback，不新增 execute/rollback/merge/split/recover/grant/revoke/retry/requeue/ack API。下一阶段先建设确定性身份变更计划与逆向补偿计划的内部生成和哈希，再进行隔离 PostgreSQL 事务演练、故障注入、原子回滚和 outbox 一致性验证。

9.39 第二十阶段：确定性身份变更与逆向补偿计划（已交付，2026-08-09）

1. P0-PLAN-1 纯内存计划模型（完成）：新增不可变 Pydantic 计划模型和纯函数，覆盖五类身份变更；不增加 FastAPI 路由、execute API、迁移或身份写路径。
2. P0-PLAN-2 输入边界与最小披露（完成）：严格校验 operation type、target refs、expected revisions 和固定锁计划；拒绝未知/不完整/敏感字段、重复 revision、同账号 partition、非法恢复类型、stale 或 blocked lock。计划不记录原始 target ref 值，仅保存字段指纹。
3. P0-PLAN-3 确定性步骤与锁序（完成）：五类操作各有固定正向步骤；锁按既有 rank 与同类 ID 稳定排序；输入 map/list 顺序变化不影响 plan hash。
4. P0-PLAN-4 逆向补偿与双 hash（完成）：补偿步骤严格为正向步骤逆序，正向 plan_hash 与独立 compensation_plan_hash 均由 privileged_payload_hash 计算；校验函数可检测步骤、锁或 hash 篡改。
5. P0-PLAN-5 内部接入与证据（完成）：repository 增加无路由 build_internal_change_plan()，仅从 fresh ready preflight 构造计划；专项 9/9（含 repository 前后全字段快照不变）、Python compileall、git diff --check 通过。

验收口径：相同 operation/target/revision/lock 材料必须产生完全相同的步骤和双 hash；任何 blocker、revision/lock 漂移或敏感数据均不得生成计划；计划构建前后治理、身份、event、outbox 和 execution ledger 全字段快照不变；support access、transport、execute、rollback 和补偿执行继续关闭。下一阶段进入隔离 PostgreSQL 事务演练、故障注入、原子回滚和 outbox 一致性验证。

9.40 第二十一阶段：隔离 PostgreSQL 事务演练与 outbox 原子性（已交付，2026-08-09）

1. P0-TXN-1 随机 schema 演练（完成）：只在 192.168.3.90:5432/yuqei_contract 的随机隔离 schema 中运行真实 PostgreSQL 事务；运行库、公共 schema 和生产身份数据不参与。
2. P0-TXN-2 计划前置校验（完成）：演练前从已审批 operation 生成第 20 阶段确定性正向/补偿计划，确认执行器关闭和双 hash 有效，不把 plan 当作运行授权票据。
3. P0-TXN-3 双故障点原子回滚（完成）：分别在身份投影 flush 后、event/outbox 前，以及 event/outbox 均 flush 后注入异常；两种情况下身份、治理、event、outbox 和 execution ledger 全字段快照均恢复到事务前状态。
4. P0-TXN-4 outbox 同事务一致性（完成）：成功演练在同一事务提交身份投影、operation event 和 outbox；同一 operation 的 event/outbox 数量一一对应，失败演练不留下孤立 event、孤立 outbox 或部分身份状态。
5. P0-TXN-5 安全边界与证据（完成）：真实 PostgreSQL 专项 1/1 通过，结束后 privileged_governance_% schema 残留 0。仅新增测试，不增加迁移、运行时 executor、execute/rollback/compensate API、transport、support access 或人工账本入口；凭据未落盘。

验收口径：隔离演练允许在随机测试 schema 内提交和回滚测试身份投影，但不代表真实身份执行获准上线；计划 hash 不替代锁内二次 preflight；任何故障必须让身份、event 和 outbox 同时回滚。下一阶段按顺序推进 support access 在线鉴权、自动到期、紧急撤销和独立安全评审，通用代入、共享密码/会话及真实支持访问继续禁止。

9.41 第二十二阶段：support access validation-only 安全策略（已交付，2026-08-09）

1. P0-SUPPORT-1 审批与范围绑定（完成）：只接受 approved、两名有效审批和 preview hash 当前有效的材料；账号、工作空间、固定 allowlist scope、revision、起止时间和 operation ID 绑定确定性 policy hash，原始 subject reference 仅保留指纹。
2. P0-SUPPORT-2 在线状态检查（完成）：每次检查账号/工作空间匹配、scope、当前 active 状态和 current revision；主体不匹配、停用或 revision 漂移均返回稳定阻断码。
3. P0-SUPPORT-3 自动到期（完成）：不依赖后台物化，checked_at >= expires_at 立即失效；TTL 强制不超过 24 小时，所有时间必须带时区。
4. P0-SUPPORT-4 紧急撤销（完成）：固定原因码和 revocation hash 绑定撤销材料；相同撤销幂等，不同撤销重写拒绝，在线检查先验证 policy/revocation hash 再判定 revoked。
5. P0-SUPPORT-5 执行器继续关闭（完成）：所有结果固定 access_granted=false，模块没有 activation flag、token/session/impersonation 或 API 绑定。专项 15/15、与计划层组合 24/24、compileall 和 diff-check 通过；无迁移、路由或持久化 grant/revoke 写入口。

验收口径：policy_satisfied=true 只表示 validation-only 材料在检查时刻满足策略，不是访问授权；任何调用方不得把该字段映射为放行。下一步必须完成独立安全评审和真实 enforcement 设计，至少覆盖 TOCTOU、可信时钟、撤销传播、持久化、强认证、会话绑定、审计与最小 scope；评审通过前真实 support access 继续关闭。

9.42 第二十三阶段：特权身份与 support access 独立安全评审（已完成，No-Go，2026-08-09）

评审报告：V2-privileged-identity-security-review-2026-08-09.md。当前实现获准继续作为 validation-only 和隔离演练基础，但真实身份执行与 support access 发布被拒绝。

P0 后续 backlog：建立 durable grant/revocation 与跨节点一致性；绑定可信数据库/服务端时间；在统一 deny-by-default enforcement point 内闭合 TOCTOU；实现 step-up/MFA、设备/会话和短时凭证绑定；演练撤销传播 SLA 与 kill switch；建立逐请求不可变审计/outbox、异常告警和隐私/法律审批。上述全部验收前不得增加 support access、execute、rollback、grant、revoke、impersonation、共享密码/会话或人工绕过入口。

9.43 第二十四阶段：support access 不可变账本与数据库可信时间（已交付，2026-08-09）

1. P0-SUPPORT-LEDGER-1 加法迁移（完成）：新增 20260809_0044 和 policy/revocation 两张表；policy 对 operation 唯一，revocation 对 grant 唯一，外键均为 NO ACTION。
2. P0-SUPPORT-LEDGER-2 数据库不可变与硬关闭（完成）：SQLite/PostgreSQL 触发器拒绝两张表 UPDATE/DELETE；CHECK 强制 access_enabled=false、policy version 1 和有效时间顺序，数据库层不存在启用开关。
3. P0-SUPPORT-LEDGER-3 幂等并发（完成）：内部 repository 在 operation/policy 行锁下登记和撤销；同一 operation 并发只创建一条 policy，同一撤销并发只创建一条 revocation，不同撤销原因不能改写历史。
4. P0-SUPPORT-LEDGER-4 可信时间与当前状态（完成）：登记、检查、撤销统一使用数据库 CURRENT_TIMESTAMP；检查当前 operation/审批 quorum、账号/工作空间状态、policy 材料和 revision，仍固定 access_granted=false。
5. P0-SUPPORT-LEDGER-5 验收（完成）：SQLite support access 19/19、组合 44/44、迁移 2/2、真实 PostgreSQL隔离并发 1/1、compileall 和 diff-check 通过；本地运行库备份后升级到 0044 并重启健康。

明确非目标：没有 API、Web、token/session、impersonation、transport、真实 grant/revoke 或身份执行入口。No-Go 继续生效；下一 P0 应优先设计统一 deny-by-default enforcement point 和同一请求内的 TOCTOU 闭合，同时保留强认证、撤销传播、逐请求审计及隐私/法律门禁。

9.44 第二十五阶段：deny-only enforcement point 与锁内资源复核（已验收，2026-08-09）

1. P0-ENFORCEMENT-1 固定动作契约（完成）：动作只能来自闭合集合，由服务端映射到 scope/resource；未知动作不能构造请求。
2. P0-ENFORCEMENT-2 锁内复核（完成）：内部 repository 在同一事务中按固定顺序锁 policy、operation、审批主体、support principal、撤销记录和合同/审查资源锚点，锁后刷新并重新使用可信数据库时间检查。
3. P0-ENFORCEMENT-3 deny-only 状态机（完成）：决策只允许 denied，即使策略材料满足也只返回 support_access_enforcement_disabled；模板等暂不可锁定资源固定拒绝。
4. P0-ENFORCEMENT-4 回归门禁（完成）：enforcement 与 support access 持久化专项 5/5，计划/特权身份/投递/反滥用组合 59/59，真实 PostgreSQL 隔离专项 3/3，compileall、diff-check、危险路由扫描通过，随机 schema 残留 0。

明确非目标：不增加 enforcement/support-access/execute/grant/revoke API，不读取或返回合同内容，不创建 token/session，不启用身份执行器。

闭环边界：本阶段只验收 deny-only validation 契约和锁内资源锚点复核，不构成真实资源访问、support access 发布或身份执行批准。后续仍须依次完成强认证与会话/设备绑定、跨节点撤销传播与 kill switch、逐请求不可变审计/告警，以及隐私和法律门禁。具名法务签批只能由实际承担责任的法务人员基于正式版本和可核验证据作出；AI、研发、测试或运营人员不得代签、推定已签批，或伪造法务姓名、签批日期、签名、批准记录和生效版本。缺少真实签批证据时必须继续标记为未完成和发布阻断。

9.45 第二十六阶段：support access 安全控制账本与逐请求审计（代码验收，外部门禁阻断，2026-08-10）

1. P0-SUPPORT-SEC-1 全局 fail-closed 控制（完成）：迁移 20260809_0045 增加 singleton control 和追加式控制事件，默认 kill_switch_engaged=true、external_idp_ready=false、privacy_legal_gate_approved=false、executor_enabled=false；数据库 CHECK 禁止打开执行器。
2. P0-SUPPORT-SEC-2 撤销 epoch 与并发启动（完成）：policy 撤销在同一事务递增 control version/revocation epoch 并追加不可变事件；PostgreSQL 并发 bootstrap 通过 INSERT ... RETURNING 只产生一条 baseline 事件。revocation_sla_seconds<=5 是策略目标，不是跨节点实测结论。
3. P0-SUPPORT-SEC-3 强认证输入契约（内部完成，外部未验收）：内部请求要求受信认证边界传入 IdP assertion、WebAuthn/硬件 OTP 类型、step-up 时间、session/device hash、固定 audience 和 revocation epoch。当前没有外部 IdP/WebAuthn/session API 集成，调用方布尔值或 hash 不能被解释为真实 MFA 已完成。
4. P0-SUPPORT-SEC-4 TOCTOU 与逐请求证据（完成于 deny-only 范围）：合同/审查资源使用 tenant/deleted 过滤并在 FOR UPDATE 后生成脱敏 anchor hash；同一事务先追加不可变 request audit，再追加 outbox，外键或 outbox 失败整体回滚。模板继续稳定返回 support_access_resource_not_lockable，任何结果仍固定 access_granted=false。
5. P0-SUPPORT-SEC-5 回归门禁（完成）：SQLite support/persistence/migration 24/24，真实 PostgreSQL 随机 schema 3/3，全量 Contract API 281 passed, 3 skipped；3 个 skip 均为 opt-in PostgreSQL 专项且已单独真实运行通过。Alembic 单一 head 20260809_0045，随机 schema 残留 0，运行态 support access API 0、危险身份写路由 0。

发布结论仍为 No-Go：尚缺真实外部 IdP/MFA 与会话生命周期集成、两个以上真实服务节点的撤销传播时延测量、kill switch 运维控制面和告警演练、真实资源内容的授权后读取路径，以及具名隐私/法务批准。身份执行器和 support access API 继续关闭。

9.46 第二十七阶段：动态 Provider 故障门禁与产品黄金套件分界（技术验收，外部审批阻断，2026-08-10）

1. P0-AI-PROVIDER-1 超时与降级（完成）：真实 loopback HTTP 服务注入延迟，验证稳定超时错误和脱敏审计；staging 仅在显式开关下允许 fallback，production 即使误配 fallback flag、缺密钥或返回非法结构也不得 fallback。
2. P0-AI-PROVIDER-2 验收边界（完成）：真实 Provider acceptance 只覆盖实际调用 Provider 的 10 条 Legal QA 和 8 条合同审查，不再把确定性产品生成伪装为 /legal/qa。
3. P0-AI-GOLDEN-3 产品黄金套件（完成）：独立脚本直接调用 Contract API 模板渲染和条款推荐逻辑，23 个合同生成与 8 个条款推荐共 31/31 技术通过；缺失必填业务值保留为明确占位符。
4. P0-AI-LEGAL-4 法务与预发布证据（阻断）：10 张知识卡、10 条问答、8 条审查及 31 条产品黄金资产均未具备真实具名审批证据，自动化结果保持 needs_legal_review、legal_approved=0。当前本机没有共享预发布 Provider 凭据或已批准的运行证据，因此未生成、伪造或持久化 acceptance_run_id。

自动化证据：AI Platform 113/113、Infra 32/32、产品黄金门禁 31/31 技术通过；本地运行 AI Platform 使用 mock/disabled Provider，provider_acceptance_verified=false，不得作为真实联网验收。

9.47 第二十八阶段：Provider 整套验收清单与共享预发布持久化门禁（技术完成，外部法务审批阻断，2026-08-10）

1. P0-AI-MANIFEST-1 独立追加式验收清单（完成）：新增 provider_acceptance_runs、Alembic 20260810_0023 至 20260810_0025，持久化租户、共享预发布来源、Provider 配置、10 条问答、8 条审查、10 张知识卡、18 条逐样本审计绑定、两类资产哈希、具名法务审批时间、共享证据引用/哈希及具名法务 Ed25519 审批信封元数据。整份清单使用规范化 SHA-256 生成幂等 ID，表无 update/delete 接口。
2. P0-AI-MANIFEST-2 失败关闭发布门禁（完成）：生产 release readiness 不再接受单条 AiRunAudit。每次检查重新核验租户、当前 Provider/模型、精确样本与知识卡集合、样本输入绑定、18 条无 fallback/错误且质量/引用达标的审计、资产哈希、清单哈希、具名审批人、带时区且晚于全部输出的审批时间及非占位共享证据。旧单审计 ID、缺字段、9/10、7/8、9/10、错绑、错 hash、跨租户和事后篡改均阻断。
3. P0-AI-MANIFEST-3 共享预发布受限登记（完成）：只在 environment=staging、repository_backend=sqlalchemy 且启用服务鉴权时开放内部登记；通用 service key 之外还必须提供受信 keyring 中具名法务 Ed25519 审批信封，服务端重新读取共享证据并校验真实内容 hash，旧 HMAC 直接拒绝。source_environment=shared_staging 和 policy version 由服务端写入，客户端不能自报。重复证据幂等返回同一 ID，并处理并发唯一键竞争。
4. P0-AI-MANIFEST-4 法务审批边界（阻断）：Provider acceptance CLI 默认仍只产出脱敏 needs_legal_review 证据且不登记 ID。只有显式提供覆盖 10+8+10 的结构化具名法务审批文件、Ed25519 签名和可信 keyring、共享证据 URI 与服务端重新计算的真实 SHA-256，且 18 条技术结果全部通过时，才调用共享预发布登记接口。当前未收到真实法务文件、共享 staging 真实运行或真实 acceptance_run_id，未生成或伪造任何外部证据。
5. P0-SUPPORT-TOCTOU-5 锁语义复核（完成于 deny-only 范围）：治理锁计划完成与资源锁内观察分别由 locks_acquired、resource_observed_under_lock 表示；kill switch 拒绝时前者为 true、后者为 false，资源存在且全部安全门满足时两者均为 true。真实 PostgreSQL 随机隔离 schema 的事务/故障回滚/support access 三项 3/3 和 SQLite support access 7/7 通过，schema 已清理；执行器、support access API 和真实资源授权后读取继续关闭。

自动化证据：AI Platform 149/149、Infra 64/64、产品黄金 31/31 技术通过；AI Platform 在全新 SQLite 验证 0023 至 0025 完整升级与回退，表、法务审批列、唯一约束和复合索引均存在。外部具名法务审批、真实共享预发布 Provider 全套运行、真实证据对象内容 hash、真实 acceptance_run_id、受保护 CI 签名收据和生产只读 canary 仍是发布阻断项。

9.48 第二十九阶段：共享预发布签名验收收据到生产只读验证（技术完成，真实证据阻断，2026-08-10）

1. P0-AI-PROMOTION-1 非对称签名收据 v2（完成）：共享预发布在完整 aggregate manifest、18 条 audit binding、10 张知识卡和具名法务 Ed25519 审批再校验通过后，导出规范化 receipt v2 payload；CI/预发布侧使用 Ed25519 私钥签名。生产只持公钥 keyring，不能生成或伪造收据。收据覆盖 tenant、目标 production audience、不可变 release ID、目标 image digest、Provider/model/base URL/wire API/temperature/max tokens、已发布 Prompt 内容 hash、质量策略 hash、资产与清单 hash、法务证据及签发/生效/到期时间。
2. P0-AI-PROMOTION-2 生产离线只读验证（完成）：生产 readiness 仅从只读 receipt/keyring 文件验证签名、部署 SHA-256 pin、租户、release、运行时指纹、有效期、最大 TTL、公钥生效期与撤销状态。有效收据可在 production acceptance/audit 空库下幂等复核；实现和 spy 回归均确认 get_provider_acceptance_run() 与 get_ai_run_audit() 调用为 0。缺失、未 pin、篡改、过期、未来签发、超长 TTL、未知/撤销 key、跨租户/release 或 runtime 漂移均失败关闭，且不得回退本地数据库。
3. P0-AI-PROMOTION-3 签发与部署隔离（完成）：Provider acceptance CLI 新增 receipt 私钥、key ID、目标 release/image digest 与独立输出路径四参数成组校验，仅在取得真实 acceptance_run_id 后从 shared staging GET payload、严格校验绑定并原子写出独立 JSON；摘要只记录 receipt_id 与文件 SHA-256。生产 Compose 只读挂载 receipt/keyring；preflight 强制 release/image digest、文件 hash pin、TTL/clock skew，并拒绝法务私钥、签名私钥和 staging 数据库凭据。
4. P0-AI-PROMOTION-4 API 与身份边界（完成）：仅增加 authenticated staging-only receipt payload GET；没有 receipt import/write、promotion POST、execute、support access 或身份写 API。身份执行器继续关闭，promotion 不引入生产状态消费写入；同一有效收据允许只读幂等复核，重放范围由 tenant、audience、release、runtime 与短有效期共同限制。
5. P0-AI-PROMOTION-5 外部门禁（阻断）：本阶段没有伪造具名法务审批、真实 Provider 结果、真实 acceptance_run_id、签名私钥或生产收据。上线仍需具名法务完成 10 张知识卡和 18 条 Provider 结果审批，共享预发布运行并持久化真实 manifest，由受保护 CI 签发 receipt v2，运营维护公钥轮换/撤销 keyring 后再执行生产 preflight 与只读 readiness。

自动化证据：AI Platform 全量 149/149、promotion/registration 定向测试通过，Infra 全量 64/64、产品黄金 31/31；Ed25519 真实签名/验签、服务端 evidence bytes/hash、生产空 acceptance/audit 数据库、零 repository 回查、tamper、tenant/release/runtime/image digest、时间边界、双 key 轮换/撤销、无效收据不回退、只读挂载、SHA-256 pin 和敏感生产配置拒绝均已覆盖。Python 编译与 git diff --check 通过；本机无 Docker CLI，因此 Compose 使用静态回归验证，未声称执行了 docker compose config。

9.49 第三十阶段：具名法务签名与真实证据内容绑定（技术完成，真实法务签批阻断，2026-08-10）

1. P0-AI-LEGAL-1 两阶段职责分离（完成）：collect 只运行 10 条法律问答和 8 条合同审查并生成确定性、脱敏技术包；finalize 只消费已收集的精确技术包、具名法务审批信封和 trusted keyring，不重新运行 Provider，也不允许 CI 代替法务作出审批决定。
2. P0-AI-LEGAL-2 Ed25519 具名审批（完成）：审批 payload 绑定 tenant、approver、role、organization、Provider 配置、10+8+10 清单、18 条 audit binding、技术包 hash、证据 URI/hash、批准与到期时间；服务端验证受信公钥、key 有效期/撤销、签名和全部字段绑定。旧 HMAC 在受保护登记 API 明确返回 422。
3. P0-AI-LEGAL-3 真实内容 hash（完成）：共享预发布服务端按 host allowlist、超时和大小上限读取 evidence bytes，并重新计算 SHA-256；只提交 URI 和调用方声明 hash 不能通过。18 条 audit 同时绑定精确 bundled sample question 与脱敏 audit snapshot hash。
4. P0-AI-LEGAL-4 追加式持久化（完成）：Alembic 20260810_0025 持久化 approval ID/key/signature/approver/role/organization/expiry/technical package hash；ORM 与迁移均保留 tenant+manifest 唯一约束，无 update/delete API。

9.50 第三十一阶段：受保护 promotion 与多节点控制（技术完成，现场演练阻断，2026-08-10）

1. P0-AI-CI-1 受保护 CI（完成）：.github/workflows/provider-promotion.yml 绑定受保护 shared-staging environment，执行 collect/finalize，只上传 allowlist promotion artifacts，并在 job 结束清理 service key、法务材料和 receipt 私钥。
2. P0-AI-CI-2 多节点只读 canary（完成）：新增 verify-provider-promotion-nodes.py 与 canary workflow，要求至少两个节点报告同一 release、receipt、key 和 image digest；远程 service-auth 节点强制 HTTPS，loopback 仅用于测试。
3. P0-AI-CI-3 撤销与 kill switch（完成）：支持 revoked key 传播 SLA 轮询、超时失败关闭、全局 promotion kill switch 及跨节点传播确认；readiness 暴露脱敏只读诊断，不输出 service key、私钥或本地文件路径。
4. P0-AI-CI-4 现场边界（阻断）：代码与自动化不能替代双节点真实部署、撤销时延测量和 kill switch 运维演练；未形成真实运行证据前不得标记运营门禁通过。

9.51 第三十二阶段：release/image 绑定与真实 promotion 闭环（技术完成，外部真实性阻断，2026-08-10）

1. P0-AI-IMAGE-1 receipt v2（完成）：receipt 强制绑定 target_image_digest=sha256:<64 hex>；production preflight 验证 AI_PLATFORM_RELEASE_IMAGE_DIGEST 与部署的 AI_PLATFORM_API_IMAGE@sha256:<digest> 一致，release 或 image 漂移均失败关闭。
2. P0-AI-IMAGE-2 运维诊断（完成）：readiness 返回 verification mode、verified、kill switch、release、image digest、receipt id、key id 和 expiry，不返回签名材料或内部路径。
3. P0-AI-IMAGE-3 API 边界（完成）：OpenAPI 仅保留共享预发布登记/读取、receipt payload GET 与 readiness GET；生产不提供 receipt import/write、promotion POST、Provider execute、support access 或身份写 API，身份执行器继续关闭。
4. P0-AI-IMAGE-4 真实闭环（阻断）：共享预发布目前仍未部署 0025 且真实 Provider/fallback 门禁未配置；尚无真实具名法务签名、共享 evidence object、acceptance_run_id、receipt v2、受保护 promotion bundle 或生产双节点 canary。不得用本机 memory/mock/loopback 结果补造这些证据。

本轮结论：六项顺序中的前五项已完成代码、迁移、CI 契约和自动化验证；第六项只能由真实法务与共享预发布/生产运维共同完成，当前保持 No-Go。下一次执行顺序固定为：部署当前代码及 Alembic 0025 到共享预发布，配置真实 Provider 并关闭 fallback，运行 collect，由具名法务签署精确技术包，运行 finalize 取得真实 acceptance_run_id 和 receipt v2，再执行生产只读双节点 canary、撤销 SLA 与 kill switch 演练。

9.52 第三十三阶段：真实 Provider 技术包与最终发布审查（技术闭环，生产 No-Go，2026-08-11）

1. P0-AI-LIVE-1 共享预发布与真实联网（完成）：共享预发布已升级至 Alembic 20260810_0025，真实动态 Provider 为 ccswitch / gpt-5.6-sol，调用开启、fallback 关闭、服务鉴权和反滥用开启。最终 collect 对 10 条法律问答和 8 条合同审查 18/18 技术通过、问题 0，状态为 needs_legal_review。
2. P0-AI-LIVE-2 精确技术包（完成）：远端技术包 provider-technical-review-package.json 大小约 195 KiB，SHA-256 为 ed1830430e8049397800cc75e9c24bac85a093a268bb669cf9d8db862adac9f2。首次复跑发现输出文件名意外带尾随 ?，安全扩展名校验按预期拒绝；修正命令后未放宽路径规则并成功构包。
3. P0-AI-PROMOTION-3 防绕过复核（完成）：底层 receipt 构造器不再允许旧 HMAC attestation 替代具名审批；shared staging readiness 在 fallback 开启时失败关闭；receipt payload 导出会从持久化字段重建并重新验证具名法务 Ed25519 签名、trusted keyring 和共享 evidence bytes/hash。即使直接篡改数据库并同步重算 acceptance manifest hash，也不能导出 receipt payload。
4. P1-WEB-MOBILE-4 窄屏导航（完成）：移动端改为菜单按钮和抽屉侧栏，补齐遮罩、关闭按钮、路由关闭、Esc、滚动锁、工作空间切换和退出；关闭态侧栏使用 visibility:hidden，不可被键盘焦点命中。390×844 页面宽度等于视口、控制台 0 error。
5. P0-REGRESSION-5 最终自动化（完成）：Python 454 passed, 3 skipped；3 个 opt-in PostgreSQL 项在真实随机隔离 schema 3/3；产品黄金 31/31；Web typecheck 与 101 路由 production build；npm audit、pip-audit、Bandit、待提交源码 secret 和 diff-check 均通过。
6. P0-PRODUCTION-6 正式上线门禁（阻断）：具名法务尚未对 10 张知识卡和 18 条真实结果签名，因此没有 acceptance_run_id、receipt v2 或 promotion bundle。服务器同时缺少 production env、production secrets、preflight 目录、异地备份挂载、TLS/DNS/不可变镜像/阿里云切流证据和双节点 canary；production 容器数为 0，根盘约 91% 使用。不得启动 production compose 或把 smoke 重命名为 production。

发布结论：当前代码、共享预发布技术验收和内部审查已达到可交付给具名法务及生产运维的候选状态，但正式生产仍为 No-Go。下一顺序不可跳步：具名法务签署精确技术包和共享 evidence -> finalize 生成真实 acceptance_run_id/receipt/promotion bundle -> 建立并通过 production preflight、备份恢复和容量门禁 -> 部署至少两个生产节点 -> 执行只读 canary、撤销 SLA、kill switch 与回滚演练 -> 全部门禁通过后才允许切流。

9.53 第三十四阶段：Provider promotion 现场闭环（已完成，公网发布仍受边界约束，2026-08-12）

1. P0-AI-FIELD-1 具名审批与 receipt（完成）：精确 payload c3246b5b7ba5b98604acf3e7f49c3186ad79a7e77426d272c0e2745e4e230702 已由具名法务 Ed25519 签署；共享预发布 acceptance_run_id=provider-acceptance-41663d1022d3f656769ed757、receipt 和 promotion bundle 已生成并 pin 到生产。
2. P0-AI-FIELD-2 生产基础设施与恢复（完成）：主节点 production API/worker、PostgreSQL、Redis、MinIO 健康；备份 backup-20260811T152805Z 的三库 dump、合同文件归档、manifest 校验和三次一次性恢复通过，临时恢复库已清理。
3. P0-AI-FIELD-3 双节点只读 canary（完成）：192.168.3.90 与 47.94.178.212 两节点均报告相同 release、receipt、key 和 AI image digest；第二节点 AI PostgreSQL 强制 default_transaction_read_only=on，AI API 未绑定公网。
4. P0-AI-FIELD-4 撤销 SLA 与 kill switch（完成）：receipt key 撤销在 2.64s 内传播并双节点阻断；临时关闭 kill switch 后 canary 2/2 ready；演练结束后双节点均恢复 kill_switch=true、blocked、release_allowed=false。
5. P0-AI-FIELD-5 代码回归与文档（完成）：生产工具/Provider promotion 72 passed，Contract Web URL 回归 6/6，typecheck、compileall 和 diff-check 通过；现场证据补录于 project-docs/V2-provider-promotion-field-evidence-2026-08-12.md。

本阶段只关闭动态 Provider 的 promotion、撤销和 kill-switch 现场门禁，不授权公网流量切换。edge、DNS 和业务流量保持未切换；support access 的真实 IdP/MFA、会话绑定、资源读取 TOCTOU、逐请求不可变审计、隐私/法律门禁，以及身份执行器和破坏性身份写 API 继续保持 No-Go。