openxiangda-skill-kit 2.0.0-alpha.22 → 2.0.0-alpha.24

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/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/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-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.22",
+  "version": "2.0.0-alpha.24",
   "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.19"
+    "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