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

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

@@ -12,7 +12,7 @@ OpenXiangda 2.0 的运行语义采用三层模型：
 2. **环境选择层**：最终的 `app_runtime_environment_heads_v2` 是某个原生环境当前运行哪个 AppVersion/DeploymentRun 的唯一指针。预发和生产可以选择不同修订；晋级仍使用同一个 AppVersion，不重建制品。现有 `app_environment_heads_v2` 的 `environment_id` 外键指向 legacy `app_environments`，只作为 alpha 历史审计事实，不能原地改造成最终 Head。
 3. **环境运行态层**：RoleMembership、manual role、业务范围 grant、RelationshipGrant、RoleSession、Workflow 实例、Event receipt、OAuth client 和 Secret 等可变状态绑定远程环境。生产运行态不能被预发部署覆盖。
 
-2.0 只有一套远程环境身份模型：一个稳定 `tenant + appCode` 下恰好包含 `preproduction`、`production` 两个原生运行环境，每个环境有稳定 UUID 和不可变 route key。同一个 AppVersion 先部署到预发，再原样晋级生产。`local` 是开发机上的运行模式，不注册环境 UUID、不创建远程 Head/OAuth/Secret/RoleSession，也不能作为 deploy/promote 目标。现有 `app_environment_sets/app_environments` 用“不同 appType 分别代表预发和生产”的模型保留给 1.x 发布治理，不再由 2.0 CLI、AppVersion 或 native runtime 使用。
+2.0 只有一套远程环境身份模型：一个稳定 `tenant + appCode` 下恰好包含一个 `preproduction`，并在首次明确晋级时最多创建一个 `production` 原生运行环境；每个已创建环境有稳定 UUID 和不可变 route key。同一个 AppVersion 先部署到预发，再原样晋级生产。`local` 是开发机上的运行模式，不注册环境 UUID、不创建远程 Head/OAuth/Secret/RoleSession，也不能作为 deploy/promote 目标。现有 `app_environment_sets/app_environments` 用“不同 appType 分别代表预发和生产”的模型保留给 1.x 发布治理，不再由 2.0 CLI、AppVersion 或 native runtime 使用。
 
 物理存储和逻辑运行契约必须分开：Data API 的物理表与新增列是应用级、单调扩展的共享基础设施，业务行继续通过 `environment_key` 隔离；当前允许访问哪些字段、capability、字段策略和 data policy，则由请求环境 Head 选择的不可变 config revision 投影决定。contracts revision 用于证明前端、后端与配置引用的是同一组稳定代码，不保存完整字段 schema。
 
@@ -94,7 +94,7 @@ app_runtime_environment_heads_v2
 ```
 
 - 一个 2.0 app 固定两个长期远程环境；不支持 development 远程环境、任意自定义 key、同 kind 多环境或 key rename。
-- 新应用 provision 事务一次创建 preproduction/production；任一创建失败整笔回滚。部署请求不能隐式补环境，生产环境必须有更严格 side-effect policy 与管理员确认。
+- 新应用 provision 事务只创建 preproduction；首次 promotion 在唯一约束下惰性创建 production。普通部署请求不能隐式补环境，生产环境必须有更严格 side-effect policy 与管理员确认。
 - `environmentId` 进入 OAuth client、Secret、RoleSession、Workflow/Event、DeploymentRun 和授权运行态；对外 DTO 同时返回 id/key/kind，但任何写请求中的 id/key 必须与认证 Principal、app 和 registry 相互匹配。
 - 旧 `app_environment_sets/app_environments` 的跨 appType swap、attach 和 policy 接口不再出现在 openxiangda-v2 CLI/Skill。旧 CLI 和 1.x 应用保持原行为。
 - 原生 Head 不重复保存 frontend/backend/config/contracts revision。AppVersion 是组件组合的唯一事实，`app_version_projection_bindings_v2` 是 AppVersion 到编译后配置闭包的唯一映射；读取方通过它们解析。数据库复合外键必须证明 Head、AppVersion、DeploymentRun 与 environment 属于同一个 tenant/app，不能只靠服务层比较 UUID。

package/docs/architecture/implementation-roadmap.md

@@ -18,6 +18,7 @@
 
 | 能力主题 | 唯一事实来源 | 当前状态 | 已有证据 | 尚缺内容与下一道门 |
 | --- | --- | --- | --- | --- |
+| 按需生产环境与运行启停 | Platform Server Native 环境 registry + Environment Head + DeploymentRun；K3s 只执行平台期望状态 | 已实现待线上验收 | provision 仅创建预发、promotion 惰性创建唯一生产、`runtime_state` CAS、start/stop durable run、停止网关 503、ReplicaFailure 快速诊断、CLI/MCP/Contracts 与能力协商均已实现；平台 targeted 测试、构建、101 条 migration 静态校验和 47 条 Native migration 真实 PostgreSQL 幂等应用通过 | 完成工具链正式发包和 prod-1 migration/image 部署；以全新应用证明初始无 production、预发 stop→0/start→ready、首次 promotion 才出现 production，并停止闲置旧测试环境释放配额 |
 | OAuth2 外部应用身份 | Platform Server OAuth2 服务与数据库；Nest SDK 只消费 token | 已交付 | Client Credentials、租户/应用/环境/scope 绑定、一次性 Secret、轮换宽限、撤销、审计、跨环境拒绝、应用 Principal；平台 unit/持久化/真实 HTTP 和 Nest 测试通过 | 后续只按新 scope 或凭据策略单独设计，不与 Admin 用户会话混合 |
 | 平台托管后端运行凭据 | Platform Server credential 状态 + Environment Head/DeploymentRun | 已交付功能基线，E4 激活语义待收敛 | CAS 暂存、同 AppVersion 滚动部署、旧凭据宽限、重试幂等、CLI 不获得明文；真实 HTTP 两轮通过 | 当前候选凭据仍可能在 Head 前进入可用链路。E4 改为 pending→active→retiring→revoked，业务 token/后台 lease 只授予当前 Head 对应 run；配额、告警另做运维主题 |
 | 应用 Secret | Platform Server Secret 版本与审计表 + runtime activation policy | 已交付功能基线，active-only 注入待收敛 | 环境级 AAD、只写值、不可变版本、CAS 幂等、required/optional 部署语义、删除和审计测试 | P0 只校验所需版本存在，不向 pending runtime 提前注入 active-only Secret；E4 通过短时 runtime identity 按需读取并受 egress policy 约束。KMS 替换保持同一协议，不在应用端增加第二套存储 |
@@ -28,13 +29,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/architecture/native-configuration-projection-v2.md

@@ -205,7 +205,7 @@ app_runtime_environments_v2
 
 - key/kind/tenant/app 创建后不可修改；环境不物理删除，只能在满足无活动 Head、runtime、数据和安全状态引用的独立计划中 decommission。
 - native UUID 只由新应用的显式环境创建事务生成；旧 alpha Head/environment UUID 不复用、不映射。
-- 新应用 provision 事务一次创建 preproduction/production；任一创建失败整笔回滚。部署请求不能隐式补环境，local 不进入 registry。
+- 新应用 provision 事务只创建 preproduction；首次 promotion 在唯一约束下惰性创建 production。普通部署请求不能隐式补环境，local 不进入 registry。
 
 ### 5.3 Minimal native Head
 

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

@@ -1,6 +1,6 @@
 # OpenXiangda 2.0 按需正式环境
 
-状态：2026-08-16 已确认，作为 2.0 新应用的目标生命周期。尚未实现。
+状态：2026-08-16 已实现平台与工具链候选，等待正式发包和 prod-1 在线验收。
 
 ## 问题证据
 
@@ -18,8 +18,8 @@
 
 1. `app provision` 幂等创建应用身份、应用最高管理员授权和预发环境，不创建正式环境。
 2. 日常 `deploy` 只向预发部署新的不可变 AppVersion。
-3. 首次 `release production` 选择一个已在预发成功运行的 AppVersion，创建正式环境并把同一个 AppVersion 发布到正式环境。发布过程不重新构建制品。
-4. 后续 `release production` 复用已有正式环境，只更新其环境 Head。
+3. 首次 `promote <preproduction-deployment-id> production` 选择一个已在预发成功运行的 AppVersion，创建正式环境并把同一个 AppVersion 发布到正式环境。发布过程不重新构建制品。
+4. 后续 `promote` 复用已有正式环境，只更新其环境 Head。
 5. 预发和正式工作负载均支持显式启动、停止。停止只把期望运行副本降为零，不删除环境、业务数据、审计、Secret 元数据或历史 DeploymentRun。
 6. 从未正式发布的应用永远没有正式环境、正式 RoleSession、正式 OAuth/Secret 运行态或正式后端 Pod。
 
@@ -39,7 +39,7 @@
 | `app provision` | 创建应用身份和预发环境 |
 | `deploy preproduction` | 构建或提交 AppPackage，并把候选 AppVersion 部署到预发 |
 | `environment start/stop preproduction` | 启停预发工作负载，环境事实保持不变 |
-| `release production` | 首次惰性创建正式环境，或复用已有正式环境，发布预发验证过的同一 AppVersion |
+| `promote <deployment-id> production` | 首次惰性创建正式环境，或复用已有正式环境，发布预发验证过的同一 AppVersion |
 | `environment start/stop production` | 显式启停正式工作负载，不删除正式环境 |
 
 管理端应用列表至少显示“仅预发、预发运行中、预发已停止、正式发布中、已发布、正式发布失败”，并提供与状态匹配的确定性操作。普通用户页面不展示环境 UUID、AppVersion ID、workflow code 或内部错误码；这些信息只进入应用管理员诊断面板。
@@ -77,3 +77,11 @@
 4. 首次发布因资源不足或 readiness 失败时，预发 Head 不变化，正式环境没有活动 Head，也没有残留运行 Pod。
 5. 停止预发后副本数为零，再次启动恢复相同环境和活动版本。
 6. 1.x 发布、流程和自动化回归测试结果不受影响。
+
+## 当前实现
+
+- Platform Server migration 为 Native 环境增加 `runtime_state`，并把 `start`、`stop` 纳入同一 DeploymentRun 状态机和并发唯一约束。
+- provision 默认只创建 `preproduction`；首次 promotion 由平台事务性确保唯一 `production` 环境。
+- K3s 执行器只缩放当前 Head 指向的 Deployment。状态只在目标副本就绪或归零且 Head 未变化后提交；停止后的 App API 返回稳定的 503 错误码。
+- CLI 提供 `environment status/start/stop`；MCP 提供只读环境资源以及 `environment_status`、`start_environment`、`stop_environment` 三个工具。
+- AppPackage 自动要求 `environment.on-demand-production` 与 `environment.runtime-lifecycle`，旧平台会在上传制品前被能力协商拒绝。

package/docs/delivery.md

@@ -38,6 +38,8 @@ stateDiagram-v2
 
 失败默认不切换当前版本。重试复用同一 AppVersion 和幂等键。promotion 复用同一 AppVersion；rollback 是激活历史版本的新 DeploymentRun，不在服务器上现场改文件。
 
+新应用 provision 只创建预发环境。生产环境在首次 promotion 时由平台惰性创建；CLI 和 AI 不预先生成生产 UUID，也不自行补写环境记录。`environment start/stop` 同样创建平台持久化的 DeploymentRun，停止只把当前 Head 的 K3s 工作负载缩容为零并保留环境、数据、配置、密钥元数据与历史。客户端先用 `environment status` 读取权威 revision，并把 revision 纳入默认幂等键；并发操作由平台唯一约束和 Head/环境 CAS 仲裁。
+
 ## 版本管理
 
 Changesets 管理各个 `openxiangda-*` 包、CLI、MCP 与 skill-kit 的独立版本和内部依赖传播。官方模板固定经过同一候选矩阵验证的精确 BOM。文档参考从命令和 MCP 注册表生成，避免文档与实现漂移。

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/docs/getting-started.md

@@ -128,15 +128,18 @@ openxiangda workflow provider list --environment preproduction
 openxiangda build --backend-image registry.example.com/apps/my-app@sha256:...
 openxiangda deploy preproduction --backend-image registry.example.com/apps/my-app@sha256:...
 openxiangda status <deployment-id>
+openxiangda environment status
 ```
 
 CLI 上传应用包并创建 DeploymentRun；部署、重试、健康检查和激活都由平台执行。CLI 退出不影响发布继续进行。生产只晋级预发已验证的同一不可变 AppVersion，不重新构建。
 
-`app provision` 只用于首次创建平台中的稳定 2.0 应用身份，并在同一事务中补齐稳定的 `preproduction`、`production` 原生环境；命令可安全重试，且需要平台管理员身份。日常 CI 使用该应用的发布权限即可，不需要平台管理员。
+`app provision` 只用于首次创建平台中的稳定 2.0 应用身份和默认 `preproduction` 环境；命令可安全重试，且需要平台管理员身份。首次执行 `openxiangda promote <preproduction-deployment-id> production` 时，平台才惰性创建唯一的 `production` 环境并发布相同 AppVersion。
+
+测试应用不使用时可执行 `openxiangda environment stop preproduction` 把当前工作负载缩容为零；环境、业务数据、Secret 元数据、Head 和发布历史都会保留。需要继续测试时执行 `openxiangda environment start preproduction`。正式环境使用相同命令，但不会由平台自动停止。
 
 ## AI 入口
 
-AI 先读取 `openxiangda://workspace/context`，再使用 MCP 的 `check_app`、`run_tests`、`build_app` 等结构化工具。会改变环境的工具必须在用户明确授权后调用。
+AI 先读取 `openxiangda://workspace/context` 和 `openxiangda://environments`，再使用 MCP 的 `check_app`、`run_tests`、`build_app` 等结构化工具。`start_environment`、`stop_environment` 等会改变环境的工具必须在用户明确授权后调用。
 CI 或非交互环境不写用户会话文件，必须成对提供短期凭据：
 
 ```bash

package/docs/reference/cli.md

@@ -9,7 +9,7 @@
 | `auth logout` | write-local | 删除当前登录会话 |
 | `app create` | write-local | 从官方模板创建 2.0 应用 |
 | `app link` | write-local | 绑定平台地址和应用环境 |
-| `app provision` | deploy | 在平台幂等创建 2.0 应用身份和预发/生产环境 |
+| `app provision` | deploy | 在平台幂等创建 2.0 应用身份和默认预发环境 |
 | `app info` | read | 读取应用工作区上下文 |
 | `authz membership list` | read | 查询 Native 应用角色成员 |
 | `authz membership grant` | deploy | 授予 Native 应用业务角色 |
@@ -58,6 +58,9 @@
 | `build` | write-local | 构建并密封一个 AppPackage |
 | `deploy` | deploy | 创建平台持久执行的 DeploymentRun |
 | `promote` | deploy | 以同一 AppVersion 晋级目标环境 |
+| `environment status` | read | 查询应用环境、运行状态和活动版本 |
+| `environment start` | deploy | 从活动版本启动应用环境 |
+| `environment stop` | deploy | 停止应用环境并保留数据与配置 |
 | `status` | read | 查询 DeploymentRun 状态 |
 | `logs` | read | 查询部署检查点和关联日志 |
 | `retry` | deploy | 重试可恢复的 DeploymentRun |

package/docs/reference/mcp.md

@@ -8,6 +8,7 @@
 - `openxiangda://workspace/contracts`
 - `openxiangda://platform/capabilities`
 - `openxiangda://deployments/latest`
+- `openxiangda://environments`
 - `openxiangda://docs/index`
 
 ## Tools
@@ -20,6 +21,9 @@
 - `fire_local_timer`
 - `build_app`
 - `deployment_plan`
+- `environment_status`
+- `start_environment`
+- `stop_environment`
 - `deploy_app`
 - `deployment_status`
 - `deployment_logs`

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda-skill-kit",
-  "version": "2.0.0-alpha.30",
+  "version": "2.0.0-alpha.32",
   "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.24"
+    "openxiangda-devkit-core": "2.0.0-alpha.25"
   },
   "devDependencies": {
     "tsx": "4.23.12",

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

@@ -11,6 +11,7 @@ Deliver the whole application as one immutable version. The client submits inten
 
 1. Run `openxiangda doctor` and confirm client/platform contract compatibility.
 2. For a first deployment only, confirm an authorized platform administrator has run `openxiangda app provision`.
+   Provisioning creates only `preproduction`; do not assume `production` exists.
 3. Run `openxiangda generate --check`, `openxiangda check`, and `openxiangda test`.
 4. Build and push the backend image; use an immutable digest reference.
 5. Run `openxiangda build --backend-image <immutable-image>` and retain the returned package digest.
@@ -28,6 +29,9 @@ Deliver the whole application as one immutable version. The client submits inten
 - Use `openxiangda retry` only for retryable failed runs.
 - Use `openxiangda cancel <deploymentId>` to stop an obsolete or blocked run before submitting a replacement package.
 - Use `openxiangda promote` to move the exact same application version between environments.
+- Use `openxiangda environment status` as the authoritative environment inventory.
+- Use `openxiangda environment stop <environment>` to scale an idle environment to zero without deleting data, configuration, the active Head, or history. Use `start` to restore that same Head.
+- Production is created only by the first explicitly authorized promotion. Never create or infer it from workspace configuration.
 - Use `openxiangda rollback` to create a new run that activates a known historical version.
 
 Do not rebuild during promotion or rollback. Do not expose injected secrets in logs, manifests returned to clients, or package metadata.

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