openxiangda-skill-kit 2.0.0-alpha.23 → 2.0.0-alpha.25

package/docs/architecture/admin-shell-v2.md

@@ -42,9 +42,9 @@ OpenXiangda 2.0 已经具备可运行的 Admin 基础，不应再引入一套新
 | 缺口 | 当前表现 | 架构风险 |
 | --- | --- | --- |
 | 身份展示资料缺失 | Principal 只有 `userId`，个人中心和头像只能显示 ID | 每个应用自行调用旧用户 API，产生权限、隐私和实现分叉 |
-| 身份响应携带授权明细 | bootstrap 的每个 `RoleAssignment` 直接返回 `scopeGrants.values[]`，角色选择器和个人中心逐值渲染 | 仪器、学院、项目等授权增长后，身份响应、下拉框和 DOM 一起无界膨胀；且只展示 assignment 内联授权，不能代表用户+角色的完整有效范围 |
+| 身份响应携带授权明细 | bootstrap 的每个 Native `RoleSubject` 直接返回 `scopeGrants.values[]`，角色选择器和个人中心逐值渲染 | 仪器、学院、项目等授权增长后，身份响应、下拉框和 DOM 一起无界膨胀；且只展示 membership 内联授权，不能代表用户+角色的完整有效范围 |
 | 跨浏览器标签失效缺失 | 后端每个 loginSession/app/environment 只有一个 active RoleSession，但前端标签之间不通知 | 一个标签切换角色后，另一个标签仍展示旧身份数据，直到下一次请求被服务端拒绝 |
-| 本地偏好作用域不完整 | 标签和数据页主要按 `appCode + roleAssignmentId` 保存 | 同浏览器切换租户、用户或环境时可能复用错误偏好或路径 |
+| 本地偏好作用域不完整 | 标签和数据页主要按 `appCode + roleSubjectKey` 保存 | 同浏览器切换租户、用户或环境时可能复用错误偏好或路径 |
 | 页面保活默认过宽 | 除 `cache: false` 外，打开标签通常保持挂载 | 长时间使用后内存增长；旧身份组件可能短暂存活 |
 | 菜单协议较弱 | 单 capability、无 manifest 校验、父菜单空分支语义不完整 | 复杂权限组合和错误路由只能在应用代码中补丁化处理 |
 | Shell 与领域能力耦合 | 个人中心直接包含流程代理 | 不使用 Workflow 的应用仍承担领域依赖和产品假设 |
@@ -64,7 +64,7 @@ OpenXiangda 2.0 已经具备可运行的 Admin 基础，不应再引入一套新
 | 标签与页面实例 | 固定/关闭/关闭其他/刷新/会话恢复和最多 12 个标签已实现 | `cache` 同时控制恢复与挂载；除 `cache:false` 外页面全部保活；无最多 6 个保活页和 LRU；存储键缺 tenant/user/environment | 拆分 tab persistence 与 keepAlive，身份 epoch 改变时同步卸载旧实例 |
 | 个人中心 | 当前角色、业务范围、角色切换和 Workflow 代理均可用 | 姓名和头像退化为 userId；核心包直接依赖 Workflow；退出登录仍是可选回调 | 增加只读资料协议，把 Workflow 代理改成显式贡献，并提供默认安全退出适配器 |
 | 主题与视觉 | 响应式侧栏、390px 抽屉导航、高密度列表和 Ant Design 状态组件已经稳定 | Provider 硬编码绿色；应用无法声明 light/dark/system 和 compact | 只增加 token/algorithm 主题协议，不改现有布局语义 |
-| 数据管理 | Data API 服务端分页、明确字段搜索、排序、字段权限、CRUD、详情、审计、CSV、文件字段、慢请求序列保护和角色切换清选择均已实现 | 偏好键仍是 `appCode + roleAssignmentId`；查询生命周期未形成可复用 controller；单文件约 1700 行 | 先接入 identity epoch，再做保持外部行为的 controller/UI 拆分 |
+| 数据管理 | Data API 服务端分页、明确字段搜索、排序、字段权限、CRUD、详情、审计、CSV、文件字段、慢请求序列保护和角色切换清选择均已实现 | 偏好键仍是 `appCode + roleSubjectKey`；查询生命周期未形成可复用 controller；单文件约 1700 行 | 先接入 identity epoch，再做保持外部行为的 controller/UI 拆分 |
 | 可选模块 | `workflow`、`operations`、`credentials` 已有独立包入口，模板使用静态 lazy route | 个人中心仍静态导入 Workflow；无 Workflow 应用缺少 bundle 负向证据 | Core 不再 import Workflow；模板显式装配贡献，构建门禁验证无意外 chunk |
 | 模板与黑盒 | 模板已经覆盖桌面 Shell、移动导航、列表操作、身份失败恢复及两条 Workflow 浏览器链路；生产 chunk 预算通过 | 缺跨 tenant/user/environment 的偏好隔离、keepAlive 淘汰、标准退出和路由 manifest 负向场景 | 保留已有 E2E，补充针对新协议的可证伪场景，不重写业务演示 |
 | Ant Design 6 | 6.4.2 + React 19.2.8；离线扫描 37 类组件、143 处导入 | 本次 `antd lint` 无 deprecated、a11y、usage、performance 告警 | 不引入 Pro Components 运行时；后续修改继续按精确 6.4.2 API 查询和 lint |
@@ -270,7 +270,7 @@ OpenXiangda 2.0 已经具备可运行的 Admin 基础，不应再引入一套新
 | 问题与证据 | 平台当前分别从 v2 和 1.x 表各取 `limit` 条再在内存截断，`engineCounts` 只是截断页数量；相同 `updated_at` 没有稳定次序，Admin 无法展示真实页码和总数。模板因此一次读取 100 条，并明确禁用了分页。 |
 | 能力所有权 | Workflow Kernel/平台 PostgreSQL 查询是工作项范围、排序、总数和分页的唯一事实源；contracts 定义 wire shape；devkit/Nest 只传输 `limit/offset`；Admin 只把页码转换成 offset，不在浏览器筛选、计数或重排。 |
 | 2.0 隔离 | `/openxiangda-api/v2/.../workflow/kernel/*` 只读取 `workflow2_*` 表并只返回 `engineVersion: "2.0"`。平台仍可为旧应用保留独立 1.x 入口和兼容性报告，但 2.0 Native 应用不再查询或拼接旧流程实例。 |
-| 身份与权限 | 每次查询重新验证当前 RoleSession、环境和单一 active role assignment。`created` 同样绑定发起人的角色绑定，不把同一用户其他角色发起的实例混入当前身份；应用最高管理员保持业务数据绕过能力。分页参数不能扩大工作项范围。 |
+| 身份与权限 | 每次查询重新验证当前 Native RoleSession、环境和单一 active RoleSubject。`created` 同样绑定发起人的 RoleSubject，不把同一用户其他角色发起的实例混入当前身份；应用最高管理员保持业务数据绕过能力。分页参数不能扩大工作项范围。 |
 | 一致性与并发 | 每页数据和精确总数由一个 CTE 聚合查询产生；排序以更新时间和实例/任务 UUID 双键确定。队列在两次翻页之间变化时允许总数变化，Admin 使用最新响应，并在当前 offset 已越界时回到最后一个有效页重新读取。分类、分页或身份切换会使旧响应失效。 |
 | 资源上限 | `limit` 默认 50、范围 1-100；`offset` 默认 0、范围 0-100000。新增针对实例发起列表、任务状态排序和任务 assignment actor 的组合索引；不轮询、不预取全部页、不持久化列表响应。 |
 | 上下游契约 | `WorkflowKernelWorkCenter` 增加必填 `total/limit/offset`；`engineCounts["2.0"]` 改为当前身份与分类的精确总数。devkit、Nest SDK、本地平台、Admin、官方模板测试和文档同批升级；这是仅面向 2.0 alpha 线的显式 breaking contract，不向 1.x 发兼容适配器。 |
@@ -296,16 +296,20 @@ OpenXiangda 2.0 已经具备可运行的 Admin 基础，不应再引入一套新
 
 ### 3.15 2026-08-15 标准 Admin 设计基线
 
-本轮按产品界面而非营销页面审视 Admin。设计对象是高校与组织内部的应用管理员、学院管理员、仪器管理员和审批人，目标语言为克制、清晰、可信的桌面 B 端产品。设计参数固定为 `DESIGN_VARIANCE 4 / MOTION_INTENSITY 3 / VISUAL_DENSITY 5`，继续使用 Ant Design 6.4.2，不引入第二套组件运行时。
+本轮按产品界面而非营销页面审视 Admin。设计对象是高校与组织内部的应用管理员、学院管理员、仪器管理员和审批人，目标语言为克制、清晰、可信的桌面 B 端产品。设计参数固定为 `DESIGN_VARIANCE 4 / MOTION_INTENSITY 2 / VISUAL_DENSITY 5`，继续使用 Ant Design 6.4.2，不引入第二套组件运行时。
 
-设计稿：
+六类标准页面已分别生成并完成设计评审，不用一张拼贴图代替页面级评审。完整记录与实现映射见 [Admin v2 标准页面设计基线](../design/admin-v2/README.md)：
 
-- [Admin Shell 与工作台](../design/admin-shell-dashboard-v2.png)
-- [数据、表单、详情与流程标准页面](../design/admin-standard-pages-v2.png)
+- [工作台与壳层](../design/admin-v2/workbench.png)
+- [数据管理](../design/admin-v2/data-management.png)
+- [表单提交](../design/admin-v2/form-submit.png)
+- [表单详情](../design/admin-v2/form-detail.png)
+- [流程提交](../design/admin-v2/workflow-submit.png)
+- [流程详情与任务处理](../design/admin-v2/workflow-detail.png)
 
 设计评审通过以下决定：
 
-1. Shell 使用浅色三层表面：布局底色、内容容器、浮层。单一钴蓝用于主要动作、选中导航和当前标签；语义色只表达真实状态。
+1. Shell 使用纯深海军蓝固定侧栏作为稳定导航锚点，主内容仍使用浅色三层表面：布局底色、内容容器、浮层。侧栏不得使用渐变；单一钴蓝用于主要动作、选中导航和当前标签，语义色只表达真实状态。应用可以显式切回 light navigation，但 2.0 新应用默认使用 dark navigation。
 2. 左侧菜单来自应用静态 route manifest。设计稿中的示例栏目不进入框架默认值，没有声明的页面不占导航空间。
 3. 顶部只承载组织入口、进入用户端、通知和当前稳定角色。角色范围只在切换浮层中用于同名角色消歧。
 4. 标签存在、会话恢复和页面保活继续分别建模。固定首页不可关闭，业务标签按路由声明决定是否恢复或保活。
@@ -313,7 +317,7 @@ OpenXiangda 2.0 已经具备可运行的 Admin 基础，不应再引入一套新
 6. 数据管理页固定为页头、搜索、工具栏、表格、分页五层。服务端查询和权限仍由 Data API 负责；列设置、密度和排序只操作声明允许的字段。
 7. 标准编辑表单默认一到两列，窄屏收敛为单列。只有字段短、语义独立且空间充足时才允许三列；主操作位于固定底栏且每个区域只有一个 primary 按钮。
 8. 详情页把业务摘要、附件和关联记录分层，不展示内部 workflow code、nodeId、版本号或权限事实。
-9. 流程详情采用业务字段主区加审批轨迹侧栏。按钮集合完全来自 Kernel 返回的 action surface，标准组件只定义按钮优先级、确认、意见输入和错误恢复，不硬编码业务可用操作。
+9. 流程提交采用业务字段主区加审批预览侧栏；流程详情采用业务字段与审批记录主区加当前任务侧栏。按钮集合完全来自 Kernel 返回的 action surface，标准组件只定义按钮优先级、确认、意见输入和错误恢复，不硬编码业务可用操作。
 10. 所有标准页面必须具备 loading、empty、error、permission denied 和 stale identity 状态；动画限于 0.1-0.3 秒的状态反馈，不增加装饰性动效。
 
 图片稿用于确定布局和视觉语义，不作为像素级实现资源。实现必须优先使用 Ant Design token、算法和组件 API；图片中的示例内容、菜单数量和字段数量不构成框架默认数据。

package/docs/architecture/environment-configuration-kernel-v2.md

@@ -2,6 +2,8 @@
 
 状态：方案已确认并按 Native 实施顺序推进。2026-08-15 已完成 E4 运行时闭环：应用身份和预发/生产原生环境成对创建、Native DeploymentRun、按 run 隔离的候选 workload、`pending -> active -> retiring -> revoked` 运行凭据、凭据与 Head CAS 同事务激活、旧 token 随 Head 变化立即失效；App Gateway 使用最长 60 秒 invocation token + 最长 30 秒 Ed25519 请求 assertion，官方 NestJS 全局 transport guard 绑定当前 Native Head 与完整 HTTP 请求，本地平台使用同构协议且拒绝重放。单体 Nest 的后台消费由短租约选出一个活动实例，应用 Secret 只允许当前 Head 身份按声明读取，terminal/cancelled/超时候选由精确 GC 回收，`alpha -> native-2` 切换必须通过全平台实例 release/capability 门禁。Native production 仍须完成后续 E5 和真实预发 E2E 后再开放。
 
+生命周期修订：2026-08-16 已确认新应用默认只创建预发环境，正式环境在首次明确发布时惰性创建。本文中“provision 成对创建预发/生产”的既有实现描述由[按需正式环境](./on-demand-production-environment-v2.md)取代；环境隔离、不可变 AppVersion、Head CAS 和预发/正式运行态分离等不变量保持不变。
+
 ## 1. 决策摘要
 
 OpenXiangda 2.0 的运行语义采用三层模型：

package/docs/architecture/implementation-roadmap.md

@@ -23,7 +23,7 @@
 | Data API / App API | Platform Server 物理 schema + 环境 Head 选择的逻辑 config projection；应用后端承载业务逻辑 | Native 调用委托与请求路径证明已交付；逻辑配置投影继续收敛 | 用户与服务 Principal、PostgREST RLS、字段/行权限、受限事务批处理、最长 60 秒 invocation token、最长 30 秒 Ed25519 assertion、Nest 全局 transport guard 与同构本地平台已通过 | 继续完成 E2 physical/logical 分离和 E4 runtime lease；NodePort/NetworkPolicy 只缩小暴露面，不参与授权正确性 |
 | RBAC + 业务关系权限 | Platform Server 原生 authz revision、环境 state、RoleMembership、RelationshipGrant、RoleSession | A0-N0/N1/N2/C1/C2/P 已实现 | N2 新建环境级 manual role/membership/delegation/relationship、应用级 super-admin grant、Native RoleSession 与不可变 mutation receipt；C2 每请求先以 PostgreSQL 校验 session/state/主体，再使用环境、authz/scope 版本与主体 revision 隔离的 Redis summary；P 以 `scopeSources` 将学院管理员、仪器管理员等业务表映射为环境范围 grant，Data API 同事务置 stale/建任务，Worker 提供 lease/retry/DLQ/replay/receipt/closure，strict 投影失败关闭且恢复扫描不依赖 Redis | 下一步 A0-N3/N4 完成全实例 gate、Native generation switch 与真实 PostgreSQL/PostgREST/K3s 验收；Admin A1 只消费 native kernel |
 | Events/Automation v2 | Platform Server delivery/receipt 状态；Nest handler 承担业务副作用 | 已交付 | CloudEvents 签名、claim lease、重复投递、进程崩溃接管、stale token 隔离、重试/DLQ/replay、双密钥、重启恢复与持久 receipt 真实链路两轮通过；Native 本地层已由 CLI 新建独立应用，在真实 PostgreSQL 上覆盖 503 + Retry-After、确定性 400 死信、幂等重放和成功回执；Timer 使用严格六段 Cron + IANA 时区，调度、事件、outbox 与下一触发点在同一事务提交，并通过同一计划时间并发 claim、重启恢复与 reset 验收 | 外部副作用仍必须使用 event id 做下游幂等；不承诺跨系统 exactly-once；停机期间的 Timer 采用合并补偿而非历史洪峰补发 |
-| Workflow Kernel v2 | Platform Server 持久状态机；Admin 只解释 Surface 协议 | 进行中 | 本地独立应用已在真实 PostgreSQL 验证预览令牌单次消费、实例/任务/参与者链/时间线/回执事务提交、跨重启幂等回放、实例与任务版本 CAS、并发审批唯一成功和 reset 清理；转交与任务代理真实切换 RoleAssignment 待办归属，前/后加签使用有序参与者链，目标身份按角色和数据 scope 校验；长期代理按半开时间窗和不重叠规则解析，在预览与任务创建间 CAS 校验，把规则、有效期、原审批人及代理身份冻结进参与者链，撤销仅影响新任务；浏览器使用独立测试用户覆盖代理待办归属与冻结审计 | 远端 Kernel 与 1.x 双核运行、远端长期代理事务和过期任务管理员重分派仍需继续验收 |
+| Workflow Kernel v2 | Platform Server 持久状态机；Admin 只解释 Surface 协议 | 进行中 | 已完成 Kernel Native RoleSession/RoleSubject 数据模型切换；打包后的 CLI 已创建全新独立应用，并在真实 PostgreSQL、平台、NestJS 与 Chromium 中通过预览令牌单次消费、实例/任务/参与者链/时间线/回执事务提交、跨重启幂等回放、实例与任务版本 CAS、并发审批唯一成功和 reset 清理；转交与任务代理真实切换 Native RoleSubject 待办归属，前/后加签使用有序参与者链，目标身份按 membership 修订、角色和数据 scope 校验；长期代理按半开时间窗和不重叠规则解析，在预览与任务创建间 CAS 校验，把规则、有效期和原/代理 RoleSubject 快照冻结进参与者链，撤销仅影响新任务；8 条浏览器场景覆盖角色切换、代理冻结、完整审批动作和管理员终止 | 下一步执行远端 2.0 Kernel 离线切换、预发/生产冒烟和过期任务管理员重分派验收。1.x 双核运行路径保持不变 |
 | Workflow Kernel v2 | Kernel 状态机与平台持久实例；业务字段仍在 Data/App API | 已交付基线 | 同意/拒绝、转交、回退、撤回、加签、代理、两种退回语义、重新提交、长任务委托、Provider 恢复与并发 CAS/lease 真实链路通过 | 可视化编辑器和更多业务协议按独立需求设计；不把业务字段迁入流程库 |
 | 独立 NestJS 后端与应用交付 | 应用 Git/AppPackage；Platform Server DeploymentRun/Environment Head | 已交付功能基线，E4 激活边界待实现 | 不可变包摘要、后端 OCI digest、版本化 Kubernetes workload、readiness、重试/取消/回滚/晋级和资源限制已有证据 | 候选当前可能先取得可用 runtime credential，同进程 Worker/Scheduler 缺活动 Head lease，共享 NodePort 缺强路径证明。E4 以 pending credential、短租约、gateway assertion、failed candidate GC 收敛；仍保持每应用独立容器，不拆成多应用 Node 进程或强制三个 Deployment |
 | 2.0 CLI/MCP/Skills/模板 | 独立 `openxiangda-v2` 仓库与已发布 npm 工件 | 已交付基线 | 16 包 check/test/build、边界扫描、真实 tarball 新应用、持久 reference app、Chromium、Skills、文档全部通过；2026-08-15 再以 12 个候选 tarball 经临时本地 registry 安装到仓库外参考应用，生成、类型检查、单测、真实 NestJS OAuth2/Native 身份联调与生产构建全部通过；不调用 1.x | 新能力必须同时更新命令/MCP/Skill/模板消费证据，禁止只写 CLI 命令 |

package/docs/architecture/on-demand-production-environment-v2.md

@@ -0,0 +1,79 @@
+# OpenXiangda 2.0 按需正式环境
+
+状态：2026-08-16 已确认，作为 2.0 新应用的目标生命周期。尚未实现。
+
+## 问题证据
+
+当前 `app provision` 会同时创建预发和正式环境，参考应用部署后也容易同时保留两套后端工作负载。大多数 2.0 应用长期处于开发或试验阶段，不会正式投入使用。提前创建正式环境、运行凭据、环境状态和 Kubernetes 工作负载没有业务价值，还会增加资源占用、运维噪音和发布失败面。
+
+## 能力归属
+
+- 应用身份、环境注册、DeploymentRun、环境 Head 和运行期启停状态由平台控制面唯一拥有。
+- Git 仓库和 AppPackage 只拥有源码、声明与不可变 AppVersion，不保存环境是否已创建或正在运行的事实。
+- CLI、MCP、AI 和 Admin 管理端只是控制面客户端，不自行推导或补写正式环境。
+
+## 决策
+
+一个 2.0 逻辑应用默认只创建稳定的 `preproduction` 环境。`production` 是可选的长期环境，仅在开发者首次执行明确的“发布正式版”操作时惰性创建。
+
+1. `app provision` 幂等创建应用身份、应用最高管理员授权和预发环境，不创建正式环境。
+2. 日常 `deploy` 只向预发部署新的不可变 AppVersion。
+3. 首次 `release production` 选择一个已在预发成功运行的 AppVersion，创建正式环境并把同一个 AppVersion 发布到正式环境。发布过程不重新构建制品。
+4. 后续 `release production` 复用已有正式环境，只更新其环境 Head。
+5. 预发和正式工作负载均支持显式启动、停止。停止只把期望运行副本降为零，不删除环境、业务数据、审计、Secret 元数据或历史 DeploymentRun。
+6. 从未正式发布的应用永远没有正式环境、正式 RoleSession、正式 OAuth/Secret 运行态或正式后端 Pod。
+
+## 稳定不变量
+
+- 一个应用始终恰好有一个预发环境，最多有一个正式环境；环境 key 创建后不可改。
+- 同一个 AppVersion 从预发发布到正式，前端、后端镜像、配置和数据契约摘要保持完全一致。
+- 预发与正式的业务数据、角色成员、范围授权、OAuth 客户端、Secret 值、Workflow 实例和 Event receipt 相互独立。
+- 首次正式发布不复制预发业务数据。需要初始化数据时使用应用明确声明、可审计且可重试的 seed/import 操作。
+- 环境不存在、环境已停止和环境发布失败是三种不同状态，网关和管理端必须返回可区分的结果。
+- 1.x 应用、流程、自动化和既有发布模型不读取也不写入该生命周期。
+
+## 控制面契约
+
+| 操作 | 结果 |
+|---|---|
+| `app provision` | 创建应用身份和预发环境 |
+| `deploy preproduction` | 构建或提交 AppPackage，并把候选 AppVersion 部署到预发 |
+| `environment start/stop preproduction` | 启停预发工作负载，环境事实保持不变 |
+| `release production` | 首次惰性创建正式环境，或复用已有正式环境，发布预发验证过的同一 AppVersion |
+| `environment start/stop production` | 显式启停正式工作负载，不删除正式环境 |
+
+管理端应用列表至少显示“仅预发、预发运行中、预发已停止、正式发布中、已发布、正式发布失败”，并提供与状态匹配的确定性操作。普通用户页面不展示环境 UUID、AppVersion ID、workflow code 或内部错误码；这些信息只进入应用管理员诊断面板。
+
+## 失败与并发
+
+- 首次正式发布使用稳定 operation/idempotency key，并以 `tenant + app + production` 唯一约束防止双击或并发会话创建两个正式环境。
+- 发布先验证源 DeploymentRun、AppVersion 摘要、平台 capability、必需 Secret 和集群资源，再创建 Kubernetes 工作负载。
+- 数据库注册与 Kubernetes 就绪不能伪装成一个跨系统事务。正式环境先进入 `provisioning`，只有候选工作负载通过 readiness 后，才在一个数据库事务中激活环境 Head 和发布成功状态。
+- 候选失败时不产生正式活动 Head，不影响预发，也不覆盖既有正式版本。首次失败可以保留同一个正式环境身份和失败记录，重试继续使用该身份。
+- 资源不足必须在创建 Pod 前返回明确的 CPU、内存或配额诊断，不能停留在无提示的 Pending。
+
+## 资源边界
+
+| 应用状态 | 默认运行后端数 |
+|---|---:|
+| 预发已停止且从未发布 | 0 |
+| 正在预发验证 | 1 |
+| 已发布且预发已停止 | 1 |
+| 正式运行并同时进行预发验证 | 临时 2 |
+
+平台可以为长期未访问的预发应用提供自动停止策略，但不能自动删除环境或业务数据。正式环境不做自动停止，除非开发者明确配置。
+
+## 回滚边界
+
+- 该变化只调整 2.0 新应用的环境创建时机和控制面命令语义，不删除已经存在的正式环境。
+- 已有双环境 2.0 测试应用可以继续运行，后续通过显式清理任务停止或删除无用的正式工作负载。
+- 实现阶段必须采用可独立回滚的数据库和 API 变更；回滚时允许恢复“provision 同时创建两环境”的旧行为，但不得删除惰性创建后产生的正式环境事实。
+
+## 可证伪验收
+
+1. 新应用执行 `app provision` 后，数据库和控制面查询只返回预发环境，Kubernetes 中没有正式 Deployment 或 Pod。
+2. 预发部署成功后首次执行 `release production`，平台创建唯一正式环境，并发布与预发完全相同摘要的 AppVersion。
+3. 并发执行两次首次正式发布，只能产生一个正式环境和一个活动 Head；另一个请求幂等复用或返回稳定冲突。
+4. 首次发布因资源不足或 readiness 失败时，预发 Head 不变化，正式环境没有活动 Head，也没有残留运行 Pod。
+5. 停止预发后副本数为零，再次启动恢复相同环境和活动版本。
+6. 1.x 发布、流程和自动化回归测试结果不受影响。

package/docs/architecture/repository-and-release.md

@@ -23,7 +23,7 @@
 1. 提交与 PR 使用 `pnpm verify:affected`，只运行受影响包及其依赖任务。
 2. 已评审 Changesets 先由 `pnpm release:version` 在干净且已同步远端的 `master` 上物化；人工只审核生成的版本、内部依赖与模板 BOM，不手改版本。版本 diff 必须提交并推送后才成为候选源码事实。
 3. 发布候选运行 `pnpm release:plan`，由真实候选 tarball 差异和包依赖图确定门禁；待消费 Changesets 未物化时在任何构建前失败。
-4. `pnpm release:publish` 从干净的远端 `master` 生成一次带摘要的候选工件清单；候选安装、reference 验证和 npm publish 复用相同 tarball，禁止重新打包，并且只执行一次正式验证。`pnpm verify:release` 只用于需要提前获得无发布验收证据的演练，不是正式发布前必须重复执行的步骤。
+4. `pnpm release:publish` 从干净的远端 `master` 生成一次带摘要的候选工件清单；候选安装、reference 验证和 npm publish 复用相同 tarball，禁止重新打包，并且只执行一次正式验证。公开 registry 确认收到相同 tarball 后，发布命令会从公开包自动同步 reference 仓库锁文件并执行 frozen install；锁文件不再从发布前的临时 registry 生成。`pnpm verify:release` 只用于需要提前获得无发布验收证据的演练，不是正式发布前必须重复执行的步骤。
    从源码创建候选 tarball 前，制品入口按候选包及其 workspace 依赖统一执行一次 Turbo 增量构建；不能直接打包工作区里可能过期的 `dist`。如果输入已经是带摘要的 release artifact manifest，则跳过构建并只消费冻结制品。
 5. 每次候选都在全新独立项目安装真实 tarball 并完成 generate/check/test/build；浏览器相关变化再执行完整 Chromium E2E。
 6. 平台集成测试部署到测试环境；只有平台协议或部署能力变更才需要阻塞核心发布。
@@ -43,6 +43,7 @@ reviewed Changesets
   -> deterministic affected validation plan
   -> candidate closure + independent tarball verification
   -> npm publish of the exact validated tarballs
+  -> published reference lock synchronization + frozen install
   -> independent-project acceptance
   -> immutable promotion
 ```

package/docs/backend.md

@@ -59,7 +59,7 @@ OpenXiangdaModule.forRoot({
 
 ## 运行与 Secret
 
-容器必须提供 liveness/readiness，支持优雅退出和结构化日志。事件签名密钥、工作流 provider 密钥及外部系统凭证由平台生成 Kubernetes Secret，并通过 `valueFrom.secretKeyRef` 注入；不会写入 AppPackage 或返回给浏览器。
+容器必须提供 liveness/readiness，支持优雅退出和结构化日志。`/__platform/health` 只检查进程存活，`/__platform/ready` 只检查应用本地启动和注入的 Native Head 运行身份，不请求平台控制面，避免平台滚动更新时所有应用被 Kubernetes 同时摘流。平台连通性和运行时契约兼容性由已鉴权的 `/__platform/dependencies/platform` 独立诊断；不兼容 AppPackage 仍由构建和部署激活门禁拒绝。事件签名密钥、工作流 provider 密钥及外部系统凭证由平台生成 Kubernetes Secret，并通过 `valueFrom.secretKeyRef` 注入；不会写入 AppPackage 或返回给浏览器。
 
 外部凭证只在配置中声明逻辑名和环境变量名，值由目标环境独立维护：
 

package/docs/delivery.md

@@ -72,4 +72,4 @@ pnpm distribution:smoke
 npm run verify:openxiangda-v2:release
 ```
 
-该门禁固定执行一次平台 SQL migration、全部 2.0 测试、共享出站 HTTP/存储安全测试和平台编译，再连续执行两次真实 OAuth2、Data API、App API、Events 与 Workflow HTTP 纵向链路。根平台发布器只在 Platform Server 进入最终镜像构建计划时自动调用，并保证它发生在第一个 Docker build 之前。它与 `pnpm verify:release` 分工明确：前者证明平台实现，后者证明独立 SDK、CLI、技能、模板和真实 tarball 新应用。两边都通过后才可进入人工发布确认；任何一个命令都不会自动提交、发包或部署。
+该门禁固定执行一次平台 SQL migration、全部 2.0 测试、共享出站 HTTP/存储安全测试和平台编译，再执行一次真实 OAuth2、Data API、App API、Events 与 Workflow HTTP 纵向链路。纵向链路内部已经覆盖多次进程重启、持久事件 receipt 接管和 Workflow 并发命令，不重复运行同一套测试。干净提交通过后会获得绑定提交、门禁步骤和本机 Node 运行时的 24 小时本地验收凭据；精确候选不变时发布器复用凭据，任何指纹变化都重新完整运行。根平台发布器只在 Platform Server 进入最终镜像构建计划时自动调用，并保证它发生在第一个 Docker build 之前。它与 `pnpm verify:release` 分工明确：前者证明平台实现，后者证明独立 SDK、CLI、技能、模板和真实 tarball 新应用。两边都通过后才可进入人工发布确认；任何一个命令都不会自动提交、发包或部署。

package/docs/design/admin/README.md

@@ -0,0 +1,122 @@
+# OpenXiangda 2.0 Admin 设计基线
+
+## 设计判断
+
+OpenXiangda 2.0 Admin 面向应用开发者、应用管理员和业务角色用户。界面采用冷静、干净、中低密度的企业级产品语言，组件与交互基于 Ant Design 6，并吸收 ProComponents 的数据管理页面模式。
+
+设计参数：
+
+- `DESIGN_VARIANCE: 4`
+- `MOTION_INTENSITY: 2`
+- `VISUAL_DENSITY: 5`
+- 单一强调色：`#1677ff`
+- 输入框与按钮圆角：8px
+- 主内容容器圆角：12px
+- 页面间距：24px
+- 表格常规行高：约 48px
+
+## 设计稿
+
+### 应用壳与工作台
+
+![应用壳与工作台](./workbench-v1.png)
+
+评审结论：
+
+- 保留侧栏、顶栏、身份切换、缓存标签栏和三列洞察区的层级。
+- 指标区降低图标装饰，数字必须来自真实接口。
+- 快捷入口采用紧凑操作带或非等宽布局，避免三张装饰性等宽卡片。
+- 待办列表不使用无语义状态点。
+- 不实现设计稿中的伪监控数字。应用模板只能展示真实可获取的数据。
+
+### 标准数据管理页
+
+![标准数据管理页](./data-management-v1.png)
+
+评审结论：
+
+- 页面由紧凑标题区、搜索区、表格工具区、数据表格和分页组成。
+- 搜索字段使用上方标签，不使用占位符代替标签。
+- 批量操作只在已选择数据时出现。
+- 导入、导出、密度、列设置和刷新归入统一工具区。
+- 空、加载、错误是互斥运行状态，设计稿底部三态条仅用于评审说明。
+- 侧栏完全由应用路由清单生成，不采用设计稿自行扩展的菜单。
+
+### 流程详情与审批任务页
+
+![流程详情与审批任务页](./workflow-detail-v1.png)
+
+评审结论：
+
+- 业务字段始终放在申请信息区，由 Data API 或 App API 保存。
+- 流程状态、当前节点和审批记录放在审批进度区。
+- 同意、拒绝、转交、回退、加签和应用自定义操作都由后端协议返回。
+- 操作确认抽屉只在执行前展示动作、下一处理人、字段变化和审批意见。
+- 不显示 BPMN 画布、引擎内部节点或低代码配置细节。
+- 侧栏完全由应用路由清单生成。
+
+## 应用壳基线
+
+- 桌面侧栏宽度 232px，折叠宽度 68px。
+- 顶栏高度 56px，标题使用当前路由名称。
+- 稳定角色切换器必须始终可见，并明确显示当前角色与数据范围。
+- 缓存标签栏支持刷新、关闭当前、关闭其他和关闭全部。
+- 页面存在未保存内容时，导航、关闭标签、切换身份和退出都进入统一的脏状态确认流程。
+- 移动端使用抽屉导航，内容区域单列排列。
+
+## 标准页面协议
+
+### 数据管理页
+
+- 必需能力：搜索、排序、分页、列配置、密度切换、刷新。
+- 可选能力：创建、编辑、详情、删除、批量操作、导入、导出。
+- 权限决定能力是否出现，不在前端复制数据权限规则。
+- 列配置和表格密度按应用、身份、资源持久化。
+- 请求失败保留现有查询条件，并提供就地重试。
+
+### 表单提交页
+
+- 标题区包含返回、页面标题和简短说明。
+- 表单正文使用最大宽度约束，字段标签位于控件上方。
+- 主操作为保存或提交，取消为次操作。
+- 字段错误就地展示，服务器错误保留已填写内容。
+- 页面离开、标签关闭、身份切换时接入统一脏状态管理。
+
+### 表单详情页
+
+- 标题区包含业务标题、状态、关键元数据和允许的操作。
+- 字段信息按业务分组显示，不把所有字段堆进一个大表格。
+- 文件、长文本和子表拥有独立展示区。
+- 编辑入口由能力和字段策略共同决定。
+
+### 流程提交页
+
+- 业务字段表单和流程预览分区展示。
+- 提交前解析主部门、角色身份、审批人和条件分支。
+- 预览结果由后端返回，前端不自行模拟审批人解析。
+- 提交失败保留业务字段和准备阶段答案。
+
+### 流程详情页
+
+- 业务数据与流程状态分离。
+- 审批流只展示条件分支、审批节点、处理人、状态、时间和意见。
+- 当前允许操作完全由 Workflow Surface 协议返回。
+- 应用自定义操作与标准操作共享确认、幂等、审计和结果刷新机制。
+
+### 工作台
+
+- 指标、图表和待办必须来自真实 Data API、App API 或 Workflow API。
+- 快捷入口由应用声明，不在框架写死业务菜单。
+- 页面提供加载、空和错误状态。
+- 图表延迟加载，避免进入应用时加载全部 ECharts 代码。
+
+## 实现预检
+
+- 页面只使用一个主题和一个强调色。
+- 不使用渐变、玻璃效果、紫色光晕和装饰性状态点。
+- 卡片只用于表达层级，不给每个内容块套卡片。
+- 所有按钮文本在桌面端保持单行。
+- 表单标签、占位符、帮助文本和错误文本满足可读性要求。
+- 空、加载、错误、无权限和成功状态都可独立验证。
+- 所有 Admin 页面在 1440px、1024px 和移动端宽度下通过布局验证。
+- 所有新增 Ant Design API 在编码前通过本地 `antd` CLI 按 6.4.2 版本核对。

package/docs/design/admin-v2/README.md

@@ -0,0 +1,59 @@
+# OpenXiangda Admin v2 标准页面设计基线
+
+状态：2026-08-15 设计评审通过，作为 `openxiangda-admin` 与官方应用模板的实现基线。
+
+适用范围：OpenXiangda 2.0 新应用。本文和配套设计稿不承担 1.x 兼容，不改变 1.x 页面、流程或自动化运行时。
+
+## 1. 设计结论
+
+OpenXiangda 2.0 的 Admin 使用一套平台官方 React 管理端框架。应用声明路由、菜单、字段、数据资源、流程定义与业务扩展；框架提供壳层、身份、导航、标签、页面生命周期和标准页面。
+
+- 主设计系统：Ant Design 6.4.2。
+- 交互参考：ProLayout、ProTable、ProForm 的成熟模式；不引入与 Ant Design 6 没有声明兼容的 ProComponents 运行时，也不建立第二套查询和页面状态。
+- 视觉方向：企业级 B 端，低到中信息密度，单一蓝色主色，冷灰背景，白色内容面，边框优先、阴影克制。
+- 设计参数：视觉变化度 4/10、动效 2/10、信息密度 5/10。
+- 桌面基线：1440×900；侧栏 232px，顶栏 56px，标签栏 40px。中等宽度变为单列，移动端使用抽屉导航与非粘性操作区。
+- 圆角只使用两级：控件 6px、内容面 8px；不使用胶囊按钮、玻璃拟态、渐变背景或无业务含义的彩色图标。
+- 一个操作面只保留一个主按钮。危险操作、流程拒绝和高级操作使用语义样式与明确确认。
+
+## 2. 已评审页面
+
+| 页面 | 设计稿 | 实现归属 | 评审决定 |
+| --- | --- | --- | --- |
+| 工作台与壳层 | [workbench.png](./workbench.png) | `ApplicationShell`、`DashboardPage` | 固定导航、身份与范围、标签缓存、四项指标、趋势、待办、快捷入口和最近访问形成统一首屏。侧栏必须使用纯色 token。 |
+| 数据管理 | [data-management.png](./data-management.png) | `DataListPage` | 页头、显式搜索、工具栏、跨页选择、列设置、密度、服务端排序与分页属于一个标准工作台；Data API 是查询事实源。 |
+| 表单提交 | [form-submit.png](./form-submit.png) | `DataFormPage` | 支持分区、两列/整行字段、文件、字段帮助、脏状态和稳定操作区；右侧说明是可选 contribution，不强制简单表单双栏。 |
+| 表单详情 | [form-detail.png](./form-detail.png) | `DataRecordPage` | 业务字段、文件和操作记录分层；不显示 revision、数据库字段或内部协议值。快捷业务动作由应用贡献。 |
+| 流程提交 | [workflow-submit.png](./workflow-submit.png) | `WorkflowSubmissionPage` | 左侧保存业务数据，右侧预览审批节点、条件分支、审批人和主部门；隐藏事件、服务任务和内部自动化节点。 |
+| 流程详情/任务 | [workflow-detail.png](./workflow-detail.png) | `WorkflowSurfacePage` | 业务字段、审批记录与当前任务三层清晰；字段策略和允许操作只消费后端 Surface，前端不复制流程规则。 |
+
+设计图是信息架构和视觉协议，不是要求逐像素复制的静态页面。图片中的示例名字、数量和日期都是演示数据，不得进入平台默认业务事实。
+
+## 3. 组件与协议映射
+
+| 设计区域 | Ant Design 基础 | OpenXiangda 所有权 |
+| --- | --- | --- |
+| 应用壳 | `Layout`、`Menu`、`Tabs`、`Drawer`、`Dropdown`、`Avatar` | 路由 manifest、菜单裁剪、标签持久化、keepAlive、身份 epoch、个人中心 |
+| 页面标题 | `Typography`、`Button`、`Space/Flex` | `PageHeader`：返回、标题、描述、状态与单一主操作 |
+| 工作台 | `Statistic`、`Card`、`List`，ECharts 按需加载 | 指标独立请求/错误/重试，流程待办使用服务端 `total` |
+| 数据页 | `Form`、`Table`、`Pagination`、`Popover/Dropdown` | Data API 服务端筛选、排序、分页、字段策略、revision CAS、资源失效 |
+| 表单/详情 | `Form`、`Descriptions`、`Upload`、`Tabs`、`Timeline` | 字段声明、文件适配、脏状态、审计读取和应用动作 contribution |
+| 流程页 | `Steps/Timeline`、`Descriptions`、`Form`、`Alert`、`Button` | Workflow Kernel preview/surface、参与者解析、字段策略、后端允许操作 |
+
+## 4. 状态与可访问性
+
+每个标准页面都必须具备 loading、empty、error、retry、disabled 和 permission-denied 状态。加载失败不能伪装成空数据；权限隐藏不能替代后端授权。
+
+- 所有输入具备可见标签，必填、帮助和校验信息不只依赖颜色。
+- 表格行点击只能是鼠标快捷方式，必须提供可聚焦的“查看/处理”操作。
+- 图表必须有可访问名称，并在无数据或失败时回退为语义状态组件。
+- 隐藏保活页面必须同时 `hidden`、`inert` 与 `aria-hidden`。
+- 身份、角色、租户、环境或授权 epoch 变化时，旧页面实例、查询和选择状态必须失效。
+- 移动端不固定底部操作区，不让流程操作遮挡字段或浏览器安全区域。
+
+## 5. 设计生成与评审记录
+
+本组图片使用内置图片生成能力分别生成，每张图只对应一个标准页面。提示词共同约束为：`production-realistic Ant Design 6 enterprise admin UI, Chinese B2B, 1440x900, medium-low density, solid deep navy navigation, one cobalt primary color, flat-first borders, no gradients/glassmorphism/marketing hero`，再分别补充工作台、数据列表、表单提交、表单详情、流程提交和流程任务的真实字段与操作。
+
+工作台首稿在评审后又做了一次定向编辑：侧栏改为纯色，快捷入口去除绿/紫装饰色，指标只保留必要语义色。其余五张的结构与视觉约束一次通过；实现阶段仍以 Ant Design token、真实协议和响应式验收为最终证据。
+

package/docs/workflow-events.md

@@ -12,13 +12,13 @@ Native 本地运行与远端 Kernel 使用同一持久化边界：预览令牌
 
 任务级操作包含同意、拒绝、退回、重新提交、转交、任务代理和前/后加签；实例级操作包含发起人撤回和应用管理员终止。一个正在审批的任务 Surface 可以同时返回任务级与实例级操作，例如应用管理员在任务仍活动时仍能终止实例。Admin 执行器按操作类型选择任务或实例命令，不以“当前页面有没有任务”猜测请求目标；撤回和终止也不会被当前审批节点的必填业务字段误拦截。
 
-长期代理绑定委托人的当前 RoleAssignment，以及代理人的明确 RoleAssignment。平台提供代理目标身份查询，页面同时展示角色和 scope grant；多角色用户不会因为只选择了人员而获得错误的数据范围。规则采用半开有效期 `[validFrom, validTo)`；同一委托身份下，全局规则与流程专属规则不能在时间上重叠，避免一次任务解析出两个代理人。应用最高管理员身份不能被代理转授，代理身份必须保持相同业务角色并覆盖委托身份的审批 scope，规则时间窗不能超出目标 RoleAssignment 自身的有效期。
+长期代理绑定委托人的当前 Native membership RoleSubject，以及代理人的明确 membership RoleSubject。平台提供代理目标身份查询，页面同时展示角色和 scope grant；多角色用户不会因为只选择了人员而获得错误的数据范围。规则采用半开有效期 `[validFrom, validTo)`；同一委托身份下，全局规则与流程专属规则不能在时间上重叠，避免一次任务解析出两个代理人。应用最高管理员 `super_admin` 不能被代理转授，代理身份必须保持相同业务角色并覆盖委托身份的审批 scope，规则时间窗不能超出目标 membership 自身的有效期。
 
-长期代理是任务创建时的分派策略，不是读取待办时动态套用的过滤器。提交预览显示实际代理人；预览令牌同时绑定发起用户和活动 RoleAssignment，换人或切换身份后不能复用。正式创建任务时把原审批人标记为已代理，并把规则 ID、有效期和明确的代理 RoleAssignment 冻结为活动参与者。规则在预览后发生变化会让提交失败并要求重新预览；数据库事务再次锁定委托身份并核对整份参与者快照，防止创建任务与撤销规则并发时产生漂移。生效规则的目标身份若失去节点角色、有效期或业务 scope，预览/提交明确失败，不静默回退给原审批人。撤销只影响新任务，已创建任务继续按冻结快照处理；有效期届满后普通代理人不能继续操作遗留任务，应用管理员可根据审计链重新分派或接管。首期只允许单跳代理，不递归追踪代理人的其他代理规则。
+长期代理是任务创建时的分派策略，不是读取待办时动态套用的过滤器。提交预览显示实际代理人；预览令牌同时绑定发起用户、Native 环境、RoleSession 和活动 RoleSubject 的 key/revision，换人、切换身份或授权修订变化后不能复用。正式创建任务时把原审批人标记为已代理，并把规则 ID、有效期和原/代理 RoleSubject 快照冻结为活动参与者。规则在预览后发生变化会让提交失败并要求重新预览；数据库事务再次锁定委托身份并核对整份参与者快照，防止创建任务与撤销规则并发时产生漂移。生效规则的目标身份若失去节点角色、有效期或业务 scope，预览/提交明确失败，不静默回退给原审批人。撤销只影响新任务，已创建任务继续按冻结快照处理；有效期届满后普通代理人不能继续操作遗留任务，应用管理员可根据审计链重新分派或接管。首期只允许单跳代理，不递归追踪代理人的其他代理规则。
 
-任务内的参与者是一个持久化、有顺序、可审计的队列。原审批人、长期代理人、前/后加签人、转交人和任务代理人都记录 user、RoleAssignment、角色、来源参与者、状态与完成身份；长期代理参与者额外记录规则 ID 和冻结有效期。任务表的 `assignedRoleAssignmentId` 是当前活动参与者的索引投影：长期代理、转交或任务代理会切换待办归属；前加签先让加签人活动，后加签在原审批人通过后接棒；只有最后一个必需参与者通过，节点才继续流转。拒绝、退回、撤回和管理员终止会原子关闭剩余参与者，避免出现孤立待办。
+任务内的参与者是一个持久化、有顺序、可审计的队列。原审批人、长期代理人、前/后加签人、转交人和任务代理人都记录 user、RoleSubject key/kind/revision、角色快照、来源参与者、状态与完成身份；长期代理参与者额外记录规则 ID 和冻结有效期。任务表的 `assignedRoleSubjectKey` 是当前活动参与者的索引投影：长期代理、转交或任务代理会切换待办归属；前加签先让加签人活动，后加签在原审批人通过后接棒；只有最后一个必需参与者通过，节点才继续流转。拒绝、退回、撤回和管理员终止会原子关闭剩余参与者，避免出现孤立待办。
 
-任务级转交、代理和加签不能只提交 userId，必须提交从平台目标查询获得的具体 `roleAssignmentId`。Kernel 再校验其角色代码、审批操作权限和当前业务 scope；scope 值缺失时 fail-closed，主部门选择会规范化为实例的学院 scope。Admin 会按当前节点过滤可选身份，并展示完整参与者链。应用管理员仍可按既定规则绕过业务数据权限处理任务，但其操作会记录为真实完成身份，不会改写被代理人的身份。
+任务级转交、代理和加签不能只提交 userId，必须提交从平台目标查询获得的具体 `roleSubjectKey`。Kernel 再校验其 membership 修订、角色代码、审批操作权限和当前业务 scope；scope 值缺失时 fail-closed，主部门选择会规范化为实例的学院 scope。Admin 会按当前节点过滤可选身份，并展示完整参与者链。应用管理员仍可按既定规则绕过业务数据权限处理任务，但其操作会记录为真实完成 RoleSubject，不会改写被代理人的身份。
 
 ## Provider 与自定义操作
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda-skill-kit",
-  "version": "2.0.0-alpha.23",
+  "version": "2.0.0-alpha.25",
   "description": "Validation and deterministic packaging for OpenXiangda 2.0 AI skills.",
   "type": "module",
   "main": "./dist/index.js",
@@ -21,7 +21,7 @@
     "README.md"
   ],
   "dependencies": {
-    "openxiangda-devkit-core": "2.0.0-alpha.20"
+    "openxiangda-devkit-core": "2.0.0-alpha.21"
   },
   "devDependencies": {
     "tsx": "4.23.12",

package/skills/openxiangda-v2-delivery/SKILL.md

@@ -67,9 +67,13 @@ If the same release train changes the OpenXiangda 2.0 platform server, run its
 gate. It must validate SQL migrations, discover every platform v2 suite, run
 the shared HTTP/storage security suites, compile without pulling in the 1.x
 baseline, and complete the real OAuth2/Data API/App API/Events/Workflow HTTP
-chain twice. The platform root release script invokes this gate automatically
-only when Platform Server is in its resolved image build plan, before any
-Docker candidate is created.
+chain once. That live chain already contains backend/service restart recovery,
+receipt takeover and concurrent Workflow command scenarios, so repeating the
+same suite is not a substitute for deterministic tests. A successful clean
+commit may reuse its exact local verification receipt for 24 hours; any source,
+step plan or runtime fingerprint change reruns the complete gate. The platform
+root release script invokes this gate automatically only when Platform Server
+is in its resolved image build plan, before any Docker candidate is created.
 Passing either local gate is evidence for review, never authorization to commit,
 publish, or deploy.
 

package/skills/openxiangda-v2-workflow-events/SKILL.md

@@ -24,7 +24,7 @@ The workflow kernel owns definitions, instances, tasks, transitions, delegation,
 6. In full local development, persist preparation tokens, instances, tasks,
    timelines, delegations, and command receipts in PostgreSQL. Commit instance
    and task CAS updates atomically; scope idempotency to the command, request,
-   and RoleAssignment so restart replay cannot cross identities.
+   and immutable Native RoleSubject so restart replay cannot cross identities.
 7. Test approve, reject, transfer, return, resubmit, delegation, add-sign, initiator withdrawal, admin termination, duplicate requests, stale revisions, restart replay, and concurrent commands.
 8. Rotate application Provider signing keys with `workflow provider rotate`,
    then deploy. During that deployment the Nest adapter must accept both current