openxiangda-skill-kit 2.0.0-alpha.30 → 2.0.0-alpha.31

package/docs/architecture/implementation-roadmap.md

@@ -28,13 +28,14 @@
 | 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 命令 |
-| 确定性工具链发布 | Changesets 版本提交、冻结工件清单、release receipt | 已实现待发布 | `verify:release` 已成为唯一候选验证入口并产出绑定 HEAD/registry/模式/工件摘要的 `validated` receipt；`release:publish` 无凭据即拒绝写入，只复查不可变与并发条件并可按阶段恢复，不再调用正式门禁或写 reference 仓库；38 个状态/工件/渠道策略测试、工作区单写者门禁与文档/Skill 构建通过，详见[发布验证凭据](./release-verification-receipt-v2.md) | 物化并发布本轮 Skill Kit 候选，以真实“verify 一次→publish 复用 receipt”记录闭环；公开包成功后再显式同步 reference lock |
+| 确定性工具链发布 | Changesets 版本提交、冻结工件清单、release receipt | 已交付 | `verify:release` 已成为唯一候选验证入口并产出绑定 HEAD/registry/模式/工件摘要的 `validated` receipt；`release:publish` 已以同一冻结工件完成真实候选发布，未重跑正式门禁，并在发布后显式同步 reference lock；工作区单写者、不可变工件、可恢复阶段、Skill 与文档门禁均通过，详见[发布验证凭据](./release-verification-receipt-v2.md) | 后续发布继续只消费机器计划与 Changesets，不新增 AI 临场选包、升版或跳过门禁路径 |
 | 环境配置内核 E0-E6 | AppVersion/component revision + native Runtime Environment + minimal Environment Head + 环境运行态 | E1-C0/C1/S0/S1/T0 已完成 | breaking config/contracts v3、平台纯编译器、六领域不可变投影、聚合投影、AppVersion binding、compile receipt、精确 artifact shadow prepare 与真实 PostgreSQL 并发/来源防伪/绑定后不可变已经通过；全新 `openxiangda-v2-native-reference-app` 由候选 tarball 创建并完成 check/test/build，连续构建逐字节一致，config/contract v3 闭包和 artifact/manifest 篡改拒绝已进入发布门禁 | 下一步进入 A0 Native 环境授权；随后实现 Data physical/logical、最小 Head CAS、pending credential、调用委托/网关断言、runtime lease、候选 GC 与 generation cutover。旧 alpha 只留审计历史，不做双读、双写或导入 |
 | 授权内核 A0-N/C/P | 不可变 authz revision + 环境 authz state + native role/scope 表 | 已确认实施；N0/N1/N2/C1/C2/P 完成 | N1/C1 建立不可变定义、两环境 state 与原子版本；N2 建立独立 Native 运行表与局部撤权；C2 建立 DB-authoritative evaluator、request cache、环境/版本 cache namespace、边界 TTL 与 RelationshipGrant 直读；P 升级 `native-2` 配置契约并建立 source definition、projection state/job/receipt/value/closure/effective grant、Data API 与 membership 原子失效、冷启动恢复与 strict gate；89 个 SQL migration 校验、35 个 2.0 migration 真实 PostgreSQL 幂等应用、39 个平台套件 / 263 项测试和工具链全 workspace 测试通过 | 当前推进 N3-N5。alpha membership/grant 不复制、不迁移，禁止给 legacy 表补 environmentKey 或建立长期双读/双写 |
 | Ant Design Pro v6 Admin 全量切换 | Ant Design Pro v6 承担通用 Admin；`openxiangda-admin` 承担平台集成 | 已交付基线 | Vite/旧自研 Shell 与仪器示例已从模板删除；React 19、Ant Design 6、Umi Max 4、ProComponents 3、utoopack、ProLayout、ProTable、ProForm、Field Kit 和企业采购参考应用已落地。桌面 Chromium 单链路通过工作台、菜单、会话标签、稳定角色切换、列表/详情、独立供应商表单、工作中心、单按钮流程提交和个人中心；正式包已发布，仓库外参考应用使用 registry lock 构建，并以同一 AppPackage 完成 preproduction→production 晋级 | 移动用户端 Field Kit 已有独立 renderer；完整移动页面模板与设备 Chromium 验收另列后续主题，不回填到 PC Admin |
+| 独立移动用户端标准页面 | `openxiangda-user` 拥有用户端身份生命周期和页面组合；Field Kit 拥有移动字段值/控件；平台拥有身份、数据、流程和文件事实 | 已实现，待线上验收 | 已新增无 UI Native RoleSession Provider，以及移动工作台、数据列表/表单/详情、流程提交/工作中心/任务/实例页面；同一 AppPackage 内 `/admin` 与 `/m` 是两个独立懒加载 UI 树，根入口只做一次设备选择；流程预览只在业务保存和 prepare 后弹出，字段统一经过 `openxiangda-field-kit/mobile`；模板 check/test/build、桌面/移动 Chromium、创建器快照和 `verify:affected` 通过；14 个候选 tarball 已在仓库外创建全新应用，完成确定性 AppPackage、真实 PostgreSQL/NestJS/本地平台、桌面/移动 Chromium、工作流/事件/定时/并发/重放与资源限制验收 | 发布正式候选并用 prod-1 preproduction 验证真实 OAuth2、RoleSession、Data API、Workflow 和文件链路；不复用 PC Admin DOM 或样式树 |
 | 前端动态挂载路径 | Platform Server 注入 runtime base；`openxiangda-admin` 适配 Umi basename | 已交付 | `openxiangda-admin@2.0.0-alpha.26` 与 `create-openxiangda@2.0.0-alpha.27` 已发布；参考应用的同一前端 digest 先部署 preproduction 再晋级 production。正式根入口和业务深链均返回 200、`application-v2`、production 环境修订和正确 runtime base，全部 JS/CSS 资源 200；Chrome 保持 `/view/openxiangda-v2-reference-app/` 并显示应用标题 | 后续路由能力只按独立需求增加；不改 hash history，不增加环境专用构建或第二套路由状态 |
 | 稳定字段值合同与服务端 UI 依赖边界 | `openxiangda-contracts` 拥有值形状；Field Kit 拥有 codec/平台控制器/renderer | 已交付 | 稳定值类型已移到无依赖 contracts，Field Kit 保留前端重导出，模板 domain 删除 Field Kit；13 个对应 npm 候选已发布并打 Git tag。参考应用 amd64 镜像约 63.8MB、生产依赖 85 包且不含 Field Kit/React/Ant Design；同一 AppPackage 已完成 prod-1 preproduction→production 晋级，正式根路由、深链和六个首屏资源均返回 200，详见[稳定字段值合同与 UI 依赖边界](./field-value-contract-boundary.md) | 后续只按新字段合同或后端制品边界独立演进，不把 UI 运行时重新引入 Nest 镜像 |
-| Admin A1 RoleSession 上下文 | Native RoleSession bootstrap 是唯一身份资料/role subject/scope 来源 | 已设计待确认 | SubjectProfile 字段白名单、tenant 联合查询、非 active scope=null、capability=`authz.role-session-context`、有界 role subject 分页与切换 CAS 已定义 | A0 native cutover 后实现；A1 自身不再增加身份存储，但不得建立在 alpha 全局 assignment 上；平台先发，工具链后要求 capability |
+| Admin A1 RoleSession 上下文 | Native RoleSession context/switch 是唯一身份资料、RoleSubject 与 scope 来源 | 已实现，待 Native K4 线上激活验收 | Platform Server 已提供有界 RoleSubject 分页、稳定身份资料、非 active scope=null、切换 expected RoleSession CAS 与 identityScope；桌面 Admin 和 `openxiangda-user` 均只消费该 Native 合同，并以 identity epoch 清理页面生命周期 | 不再实现第二套身份接口；待同一切换窗口机器验证 DB/K3s/drain 证据后再执行 K4，随后完成 preproduction/production 真实角色切换验收 |
 | Admin B0-O 租户公共 Origin | Platform Server Origin module + 版本/head/hostname claim registry | 已设计待确认 | 全仓确认多套模糊解析和广泛 URL 调用者；prod-1 证实 HTTPS/HTTP 配置差异、未登记 vhost 别名，且生产 `default_configs` 没有源码宣称的复合唯一约束；稳定租户 UUID、不可变 staged→challenge→verified→active、head revision CAS、hostname claim、事务审计、全局兼容阶段+单租户事实源状态、无长期双写和[逐文件实施蓝图](./tenant-public-origin-implementation-blueprint.md)已定义 | 确认后先做 O0 只读 inventory/digest 与 plan validator；操作者显式决定 migrate/decommission，所有服务实例同版后进入 migrating，再逐租户冻结/验证/切换，单租户失败不阻塞全平台；B0-R 不得绕过该阶段 |
 | Admin B0-C Cookie 安全 | Platform Server `AuthCookieService` + 无状态 policy resolver | 已设计待确认 | 已确认当前 DOMAIN JSON 同时决定 Cookie Domain 且 `secure:false`；共享会话/协议 Cookie 所有权、HTTPS Secure/`__Host-`/host-only、版本化名称、legacy scope manifest、C0/C1/C2 状态机和旧 host retirement 已定义 | B0-O registry 稳定后独立实现；首期不支持跨子域共享；C1 后只能回滚到理解 v2 Cookie 的兼容镜像，不和 Origin 数据迁移、return target 或 OAuth state 混发 |
 | Admin B0-R 登录 return target 安全 | 平台通用登录代理和服务端 CAS 校验 | 已设计待确认 | 全仓审计确认平台、1.x View、流程、旧编辑器和 CLI 合法生产者均可归入同源；一次解析、8 KiB 上限、精确 origin、CAS 双阶段规范化、错误链路 fail closed 及回归向量已定义 | 明确确认后作为独立平台安全提交，不和 Shell 改造、OAuth state 或身份协议混发 |

package/docs/architecture/mobile-user-standard-pages-v2.md

@@ -0,0 +1,88 @@
+# OpenXiangda 2.0 移动用户端标准页面
+
+状态：2026-08-16 已确认并进入实现
+
+适用范围：OpenXiangda 2.0 新应用的移动用户端、`openxiangda-user/mobile`、生成模板和移动 Chromium 验收。PC Admin、1.x View、稳定字段数据协议和平台数据库不在本轮修改范围内。
+
+## 1. 实现门禁
+
+| 项目 | 决策 |
+| --- | --- |
+| 问题证据 | `openxiangda-field-kit/mobile` 已覆盖移动字段交互，但 2.0 只有 PC Admin 标准页面。应用若直接组合桌面 ProForm、原生 `select/file` 或临时流程页面，会重新产生字段值漂移、移动端难用、审批预览常驻和操作协议分叉。 |
+| 能力所有者 | Platform Server 继续唯一拥有身份、授权、Data/App API、Workflow Surface 和文件/目录能力；`openxiangda-user` 只持有当前 React 页面生命周期内的身份快照和 UI 状态；Field Kit 唯一拥有平台字段值归一化及移动控件。 |
+| 稳定不变量 | 移动端与 PC Admin 提交完全相同的稳定字段值；页面必填不冒充服务端业务校验；一个用户同时只使用一个稳定 RoleSubject；应用管理员仍由平台授权；Workflow 业务字段始终由 Data/App API 保存，Kernel 只保存流程状态和字段策略。 |
+| 上下游契约 | Provider 只消费 Native RoleSession context/switch；数据页面只消费 Data API 的服务端分页、revision/CAS 与审计；流程提交先保存业务数据，再 prepare，点击提交后才打开审批预览；任务/实例页只解释 Workflow Surface 的可见操作和 JSON input schema。 |
+| 并发与失败 | 身份请求以 generation 丢弃迟到响应，RoleSubject 切换使用 expected RoleSession CAS 并推进 identity epoch；列表分页请求丢弃旧响应；更新带 revision；流程命令带 task/instance version 和幂等键；页面卸载后不提交状态。 |
+| 安全与资源上限 | 浏览器不保存平台 Token、授权结论、服务地址或业务响应；最多展示 50 条移动列表、30 条审计和 100 条工作中心记录；文件、人员、部门、地址和关联数据必须走 Field Kit/平台 API；移动包不得依赖 `antd`、`@ant-design/pro-components` 或 `openxiangda-admin`。 |
+| 回滚边界 | 本轮是新增前端包和生成模板能力，不改平台表或远端 API。可回滚移动 AppVersion 或移除模板入口；字段协议、PC Admin 和 1.x 不受影响。 |
+| 可证伪验收 | 静态依赖扫描证明移动包没有桌面 UI；SSR/单测覆盖身份 gate、角色选择、字段渲染、列表和流程操作协议；真实移动 Chromium 覆盖工作台、列表、表单、提交后审批预览、详情和流程任务；桌面 Admin 回归通过。 |
+
+## 2. 产品与视觉基线
+
+本轮先生成并评审了五屏移动设计板：工作台、数据列表、表单提交、提交后的审批预览、流程任务详情。实现采用其中的信息架构，而不是逐像素复制生成图：
+
+- 接受白底卡片、浅灰页面底色、中低信息密度、44px 以上触摸目标和底部安全区；
+- 接受首页指标与快捷入口、记录卡片列表、分区表单、底部主操作、纵向审批路径和任务页固定操作栏；
+- 流程预览只在点击“提交”并完成业务保存/prepare 后出现，不能常驻表单；
+- 页面只保留一个主操作。退回、拒绝、转交、代理、加签等由 Surface 决定，并收纳到任务页底部操作区或“更多”；
+- 不采用设计图中偶发的渐变按钮，正式实现使用单色主按钮；不把设计图中的示例字段、状态或角色名称写死到框架；
+- 不使用桌面侧栏、缩小后的 ProTable/ProForm、玻璃拟态、大面积装饰插画或以颜色替代文字状态。
+
+基础 token：页面背景 `#f5f7fa`、卡片 `#ffffff`、主文字 `#172033`、次文字 `#667085`、边框 `#e6eaf0`、主色 `#1677ff`、成功 `#12a594`、警告 `#ed8b2c`、危险 `#e5484d`；卡片圆角 12px，页面水平间距 12px，区块间距 12px，底部操作栏包含 `env(safe-area-inset-bottom)`。
+
+## 3. 包和运行时边界
+
+新增 `openxiangda-user`：
+
+- 包根导出无 UI 的 `OpenXiangdaUserProvider`、context/types 和身份生命周期；
+- `openxiangda-user/mobile` 导出独立的 Mobile Identity Gate、App Shell、Workbench、Data List/Form/Detail、Workflow Submission/Work Center/Task/Instance；
+- `openxiangda-user/mobile.css` 只提供移动 token、页面结构和安全区样式；
+- Mobile 子入口可以依赖 `antd-mobile` 与 `openxiangda-field-kit/mobile`，不得引用 PC Admin；
+- 后续 Desktop 用户端使用独立子入口。自动识别入口只动态加载一个 UI 子树，并在一次页面会话内固定 experience；窗口缩放不把已填写表单热切到另一棵 UI。
+
+Provider 不建立第二套身份事实源。它只缓存平台返回的当前 context，暴露 `loading/error/identity/identityEpoch/reloadIdentity/switchRole/appApi`；所有授权仍由服务端重新判断。
+
+## 4. 标准页面合同
+
+### 4.1 工作台
+
+工作台只做展示组合：问候、最多四个指标、最多八个快捷入口和有界最近事项。指标由应用通过受限聚合/App API 加载；框架不生成假统计，也不按角色名称推断数字。
+
+### 4.2 数据列表、表单与详情
+
+移动列表使用搜索、可选状态筛选、卡片和游标式“加载更多”体验；底层仍是 Data API `limit/offset`，不会把全量记录拉到浏览器。列表字段、标题字段、摘要字段和状态字段由页面 Surface 指定，所有值使用 `MobileFieldValue`。
+
+表单用移动分区和固定底部提交栏，所有持久化字段用 `MobileFieldControl`。创建调用 Data API create；编辑先读当前记录并以 revision 更新。页面层 required 只负责即时提示，服务端字段错误仍需原样呈现。
+
+详情按 Field Kit 只读 renderer 展示业务字段，并显示有界审计时间线。附件/图片的下载预览继续由 Field Kit 和平台 API 负责。
+
+### 4.3 流程提交与详情
+
+流程提交页初始只显示业务表单和一个“提交”按钮。点击后顺序固定为：
+
+1. 归一化字段值并通过应用提供的 `saveBusiness` 保存业务记录；
+2. 使用同一稳定保存幂等键准备流程；
+3. 在底部弹层展示 Kernel 返回的审批节点、条件说明、候选审批人与主部门问题；
+4. 需要输入时提交答案并重新 prepare；ready 后使用 preparation token 和独立 start 幂等键确认发起。
+
+任务/实例页同时展示流程摘要、业务数据、审批时间线和 Surface 允许的操作。框架不复制同意、拒绝、退回、转交、加签或代理规则；操作输入只按后端 JSON schema 构建基础移动表单，复杂业务操作由应用通过 `app_action` 扩展且不能覆盖 Kernel 操作。
+
+## 5. 分阶段交付
+
+1. 新增 `openxiangda-user` Provider、移动标准页面、样式、单测和包边界门禁；
+2. 生成模板新增独立用户端入口和通用采购申请示例，不复用 PC Admin 页面；
+3. 启动本地平台/PostgreSQL/NestJS，在移动 Chromium 验收真实字段、角色切换、Data API 和 Workflow；
+4. 经 Changeset、正式 release receipt 发布，再以全新应用在 prod-1 预发验收；只有明确发布时才创建/晋级 production。
+
+## 6. 生成模板接入门禁
+
+| 项目 | 决策 |
+| --- | --- |
+| 问题证据 | AppPackage v3 只有一个不可变 `frontend` 制品和入口文件；为移动端另建第二个前端根会迫使编译器、部署状态和网关同时理解两套制品，超出页面问题本身。现有 Umi 已支持顶层路由懒加载，可在一个制品中承载互不嵌套的 Admin 与移动用户端 UI 树。 |
+| 能力所有者 | `apps/web` 仍是唯一 frontend 构建和制品根；`Application` 只拥有桌面 Admin 树，新增 `MobileApplication` 只拥有移动用户树；`openxiangda.config.ts` 是 admin/user route surface 的发布事实源；平台继续只部署一个 frontend digest。 |
+| 稳定不变量 | 两棵 UI 树不互相包裹或复用 DOM；移动路由不得进入 `AdminLayout`；显式 `/m` 路由始终选择移动 UI；自动识别只在应用根入口执行一次，表单填写期间的缩放或旋转不切换 UI；现有显式桌面业务 URL 始终进入 Admin。 |
+| 上下游契约 | Umi 顶层路由分别挂载 `Application` 和 `MobileApplication`；移动树使用同一个平台相对 `/service` 客户端、Native RoleSession、Data/App API 与 Workflow 合同；AppPackage route manifest 为移动路由声明 `surface: user`。 |
+| 并发与失败 | 入口识别为同步纯函数，不请求远端、不持久化选择；无法识别时默认桌面 Admin。身份、列表、详情和流程请求继续使用 `openxiangda-user` 的 generation/CAS/idempotency 语义；移动路由卸载不得接收迟到响应。 |
+| 安全与资源上限 | 自动识别不参与授权，任何 route 仍由平台 capability/Data/Workflow 授权；不保存 Token 或设备指纹；移动树路由级懒加载，首屏不得渲染 `.oxa-admin-root`，标准列表/审计/工作中心上限保持不变。 |
+| 回滚边界 | 仅新增模板移动路由、页面和同一 frontend 制品内的入口选择；不改平台数据库、网关或 AppPackage 格式。可回滚 `create-openxiangda`/`openxiangda-user` 候选和目标 AppVersion，桌面 Admin 与 1.x 不变。 |
+| 可证伪验收 | 纯函数测试覆盖手机、触屏窄屏、普通桌面与缺失浏览器信息；桌面 Chromium 继续通过原套件；移动 Chromium 从根入口自动进入 `/m`，覆盖工作台、列表、详情、字段表单、角色切换和“提交前无审批预览”；完整本地模式再验证业务保存、prepare/start 与任务操作；构建门禁验证 user surface 和路由拆分。 |

package/docs/frontend.md

@@ -1,6 +1,6 @@
 # 前端架构
 
-状态：2026-08-16 已实现待发布。旧自研 Shell 与 Vite 模板已经删除，企业采购参考应用已通过类型检查、测试、Umi production build 与桌面 Chromium 验收。完整决策见[Ant Design Pro v6 Admin 全量切换](/architecture/ant-design-pro-v6-admin-foundation)，状态证据见[实施路线图](/architecture/implementation-roadmap)。
+状态：2026-08-16 桌面 Admin 已发布；独立移动用户端标准页面包和生成模板双入口已经实现，移动 Chromium 已覆盖身份、数据与流程提交主链路。旧自研 Shell 与 Vite 模板已经删除，企业采购参考应用已通过类型检查、测试、Umi production build 与桌面/移动 Chromium 验收。完整决策见[Ant Design Pro v6 Admin 全量切换](/architecture/ant-design-pro-v6-admin-foundation)、[移动用户端标准页面](/architecture/mobile-user-standard-pages-v2)，状态证据见[实施路线图](/architecture/implementation-roadmap)。
 
 ## 默认技术栈
 
@@ -56,11 +56,11 @@ OpenXiangda 2.0 桌面管理端采用 React 19、Ant Design 6、Umi Max 4、ProC
 所有平台字段使用 `openxiangda-field-kit` 的稳定值协议。人员、部门、单选、多选、单选框、复选框、日期、日期区间、地址、关联、图片、附件、数值等都由统一定义驱动存储与显示。
 
 - 桌面 Admin 从 `openxiangda-field-kit/desktop` 使用 Ant Design 控件。
-- 移动用户端从 `openxiangda-field-kit/mobile` 使用 Ant Design Mobile 的独立交互，不把桌面 Select、DatePicker 或 Cascader 缩小后复用。
+- 移动用户端由 `openxiangda-user/mobile` 提供工作台、数据列表/表单/详情和流程提交/任务/实例页面，并从 `openxiangda-field-kit/mobile` 使用 Ant Design Mobile 的独立字段交互；不把桌面 Select、DatePicker 或 Cascader 缩小后复用。
 - 人员、部门、行政区、关联数据、上传、下载和预览都通过平台 API；应用不自行复制平台目录或文件协议。
 - UI 必填、默认值、显隐、布局和帮助文本属于页面层；后端业务不应假设自定义页面一定执行了前端校验。
 
-完整移动用户端页面模板和移动 Chromium 设备验收仍是下一阶段交付；不能用桌面 Admin 的响应式效果冒充完成。
+生成模板将桌面 Admin 与移动用户端放在同一个 AppPackage 的两个独立懒加载路由树中；`/admin` 只加载 Pro 页面，`/m` 只加载 `openxiangda-user/mobile`，根入口按设备能力一次性选择。移动 Chromium 已验证两棵树不混用 DOM，并覆盖稳定角色切换、列表/详情、流程发起与平台特殊字段。
 
 ## 本地开发与门禁
 
@@ -73,6 +73,6 @@ pnpm --filter @app/web test:e2e
 pnpm --filter @app/web build
 ```
 
-CLI 同时监督 Umi、NestJS、本地平台与工作区 PostgreSQL。UI-only 只用于非持久化界面预览。当前桌面 Chromium 链路覆盖工作台、菜单、标签、角色切换、数据列表/详情、供应商标准表单、流程工作中心、单按钮流程提交与个人中心，并断言没有浏览器运行时错误。
+CLI 同时监督 Umi、NestJS、本地平台与工作区 PostgreSQL。UI-only 只用于非持久化界面预览。桌面 Chromium 链路覆盖工作台、菜单、标签、角色切换、数据列表/详情、供应商标准表单、流程工作中心、单按钮流程提交与个人中心；移动 Chromium 链路覆盖自动入口、独立 UI 树、角色切换、数据列表/详情、流程发起和平台字段。两条链路都断言没有浏览器运行时错误。
 
 生产构建分别约束首屏脚本、异步 chunk 的 gzip/原始体积与开发标记；不得包含模板假用户、Umi Mock、开发 Secret、Vite 或旧 AdminShell。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda-skill-kit",
-  "version": "2.0.0-alpha.30",
+  "version": "2.0.0-alpha.31",
   "description": "Validation and deterministic packaging for OpenXiangda 2.0 AI skills.",
   "type": "module",
   "main": "./dist/index.js",

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

@@ -22,12 +22,14 @@ Build in `apps/web` with React 19, Ant Design 6, Umi Max 4 and ProComponents 3.
 
 ## Platform fields and mobile user UI
 
-1. Use `openxiangda-field-kit/desktop` in the desktop Admin and `openxiangda-field-kit/mobile` in mobile user pages. Mobile is a separate UI tree, not a CSS-responsive copy of the Admin.
+1. Use `openxiangda-field-kit/desktop` in the desktop Admin. Build the independent mobile tree with `OpenXiangdaUserProvider` from `openxiangda-user` and the standard pages from `openxiangda-user/mobile`; those pages consume `openxiangda-field-kit/mobile`. Mobile is not a CSS-responsive copy of the Admin.
 2. Platform fields include all supported kinds, not only personnel and files: text/textarea, number/money/percent, boolean, single/multiple select, radio/checkbox/cascade, date/datetime/date range, user/users, department/departments, relation, address/location, image/attachments, signature, subtable/JSON, serial and workflow status.
 3. Persist established stable values. Directory/option/relation values use `{ label, value }`; address, location and attachment values use the `openxiangda-field-kit` types. Never replace them with display-only strings or Ant Design component instances.
 4. Personnel, departments, administrative divisions, relations, uploads, downloads and previews must use platform APIs. Do not copy platform directory data or write a second upload protocol.
 5. Keep database declarations minimal: field code, storage type, nullability, index and storage constraints. Required/default/hidden/layout/help/conditional display are page behavior. A custom page may implement different UI validation, so critical business rules must also be enforced by NestJS/Data API policy.
 6. Render list/detail values by field kind. Show readable labels, tags, formatted dates/numbers/amounts, address text, user/department identity, image preview and attachment download instead of raw JSON or internal IDs.
+7. Prefer `MobileAppShell`, `MobileWorkbenchPage`, `MobileResourceListPage`, `MobileResourceFormPage`, `MobileResourceDetailPage`, `MobileWorkflowSubmissionPage`, `MobileWorkflowWorkCenterPage`, `MobileWorkflowTaskPage` and `MobileWorkflowInstancePage`. The Workflow submission page must show only the business form and one Submit action until save and prepare succeed; only then open the approval preview.
+8. Keep the mobile package out of NestJS dependencies. The browser may call only platform-relative Native clients under the current RoleSession; it must not persist platform tokens, service addresses, permission decisions or business responses.
 
 ## Verification