openxiangda 2.59.3-http.0 → 2.60.0

package/documentation/workflow-events.md

@@ -1,3 +1,14 @@
+# 标准审批页面的值联动
+
+应用可给 `OpenXiangdaApplication` 传入 `workflowTaskForms`，按流程代码注册同步
+`valueLinkage(changed, values, { workflowCode, nodeId, pageCode })`。例如会议日期变化
+时生成可编辑意见。日期等输入已规范化为平台值；只响应用户修改，加载、草稿恢复和
+重读不会覆盖已有输入。独立手改意见是否保留由应用规则决定。
+
+回调只能读取和更新当前任务可见、可编辑的普通字段；子表、附件、只读、隐藏和
+未声明字段不参与。规则必须同步返回patch，不能发请求。规则失败保留输入并提示，
+整patch不会部分应用。保存、审批、CAS、权限、原命令恢复和固定流程仍由平台拥有。
+
 # Workflow 与 Notification Hub 2.0 边界
 
 标准 Workflow 与 Notification Hub 已作为 OpenXiangda 2.0 可选平台模块重新开放。它们不属于默认 CRUD 模板，也不兼容或复用 1.x 工作流、消息中心、模板、卡片、回调、表和 API。
@@ -238,7 +249,8 @@ copy: {
 接收 binding 支持 `fixed_users`、`initiator`、`input_users`、`form_field_users`、
 `app_role`、`app_role_in_scope`、`previous_node_actor`。仅使用事务内原生来源，
 不支持 `application_provider` 或需要申请人交互的 `initiator_select`。名单按用户去重，
-每次进入最多 20 人；`min/max` 默认 1/20，非空名单仍必须符合声明的下限。
+每次进入最多 200 人；`min/max` 默认 1/20，超过20人须由开发者显式声明更大的 `max`。
+未声明及既有显式20人预算保持；非空名单仍必须符合声明的下限。
 角色查询超过 200 条有效成员行时明确拒绝，不能使用截断后的名单。
 范围角色要求对应范围的 `cc` 授权（或未限制操作、`*`），仅 `approve` 不满足。
 抄送不套用审批代理。
@@ -350,7 +362,7 @@ Native Data 事件的 capture plan 由当前 Head 的 Event、Data、AuthZ revis
 `acceptedCommandDeactivationPolicy`：`finish-pinned` 让已接受的 durable process
 command 按固定版本完成，`cancel-on-deactivate` 在声明删除后取消尚未启动的命令；
 既有 Workflow instance 始终按固定版本继续。审批人 Provider 的 `min/max`
-默认 1/200，最大 200；自动抄送默认 1/20，最大 20。
+默认 1/200，最大 200；自动抄送默认 1/20，显式声明最大 200。
 需要按流程实例串行投递时只声明 `ordering: 'workflow-instance'`，不接受下划线别名。
 
 平台按 desired set 直接覆盖环境 Head，不做版本比较。因此 `openxiangda deploy`
@@ -496,8 +508,11 @@ return <WorkflowSubmissionPage workflowCode="reinstatement" variant="mobile" for
 
 初值仅在当前匹配的发起合同内应用到未触碰字段，每字段一次；后到资料和父组件重新渲染
 不会覆盖已填写或手动清空的内容。日期和范围使用canonical值，标准页通过原codec转换。
-`fieldState`读取canonical值，`required`只能增加校验，不能撤销原必填或隐藏原必填字段；
+条件隐藏同步也读取表单当前值，避免预填或联动刚写入的来源行被旧显隐投影清空。
+`fieldState`读取canonical值，`required`只能增加校验，不能撤销原必填；
 可选字段隐藏时清为`hiddenValue`或undefined，提交也使用同一投影，不发送旧材料/人员。
+
+必填字段也可以隐藏，但必须提供非null/undefined的规范`hiddenValue`，例如表单外已经选定的业务对象。0与false是有效输入；平台仍核验类型、必填和授权，应用须重新核验对象。未提供值时表单继续阻断。
 初值或规则引用范围外字段会阻断表单。`intro`只提供页面说明，不拥有身份、授权或提交。
 资料加载/失败或业务资格提示可传`preparation`内容，它仅阻断尚未提交的表单；原请求查询
 及已接受命令的展示优先于该提示。应用应始终挂载标准页，避免当前资格变化遮蔽原结果恢复。
@@ -511,6 +526,10 @@ return <WorkflowSubmissionPage workflowCode="reinstatement" variant="mobile" for
 联动；PC/手机规则一致。异常保留输入并阻断新提交，下一次成功输入可恢复，原提交结果
 查询及已接受命令仍优先。异步资料读取放准备阶段，服务器仍校验资格和业务不变量。
 
+对已有台账等来源固定的子表，可以传 `subtableFixedRows: ['existingPositions']`，关闭新增、删除和导入，并保留允许字段的编辑、上传和分页。此项仅限制页面操作；业务动作仍须后台重读来源，核验行集合与来源版本，不能把它作为数据授权或防篡改守卫。
+
+当只读来源标识或版本需要发给后台核对时，使用 `subtableReadonlyInputFields: { existingPositions: ['ledgerId', 'ledgerRevision'] }`。字段必须属于当前操作的子表白名单；这些值仅在页面只读，仍是未经信任的输入，后台必须重读并执行版本／集合守卫。不得与同字段的 `subtableReadonlyFields` 混用，后者会省略派生输入。
+
 具名owned新建表单可传`subtableReadonlyFields: { lines: ['employeeNumber'] }`，
 把当前子行的派生值显示为只读，并从提交输入排除。表名与字段必须属于当前sealed
 owned闭包；配置错误会拒绝新表单。值仍可供应用联动展示，Server应重新计算可信值。
@@ -940,7 +959,14 @@ append 处理签名或 HTML。当前任务、实例、记录或字段改变时
 
 ### 审批人为空时的节点策略
 
-审批节点可声明 `emptyPolicy: 'skip'`，省略或声明 `block` 时保持阻塞。第一版 skip 支持 fixed_users、input_users、form_field_users、app_role、app_role_in_scope；编译器拒绝其他来源与 skip 组合。表单人员明确为 `[]`，或存在的角色在有效范围内没有成员，且解析成功、没有警告，才允许自动继续到 `onApprove`。缺失/null 字段、不存在的角色、无效账号、缺少范围、解析失败和非零人数不满足 min/max 都不能跳过。
+审批节点可声明 `emptyPolicy: 'skip'`，省略或声明 `block` 时保持阻塞。第一版 skip 支持 fixed_users、input_users、form_field_users、app_role、app_role_in_scope；编译器拒绝其他来源与 skip 组合。表单人员明确为 `[]`，或存在的角色在有效范围内没有成员，且解析成功、没有警告，才允许自动继续到 `onApprove`。
+
+`form_field_users` 也支持主体投影的可选单人为空：固定 Native 主体的
+`factProjection` 必须准确指向非必填 `user.single`，并且保存值明确为 `null`。
+平台核验主体、定义与资料修订后，仅在审批空人策略解析中把该值视为已核实空名单；
+限定候选仍核验当前范围与授权。此规则不增加开关，也不改变节点的 skip/block/兜底策略。
+字段缺失、必填人员为 null、无主体或无准确投影、类型错误、无效账号、缺少范围、
+解析失败和非零人数不满足 min/max 都不能跳过；普通选人及 `input_users` 不接受 null。
 
 该策略由代码固定。每次实际跳过记录节点访问、当时配置、解析依据和 `openxiangda.workflow.node.skipped.v2` 事件；图和 PC/手机历史显示“已跳过”。连续节点推进受 200 节点上限约束，业务步骤仍等待其正式结果。后续失败与业务变更在原事务一起回滚，重试沿用原命令。
 
@@ -1110,10 +1136,25 @@ nodes: {
 
 标准 PC/手机任务页根据当前 Surface 调用该具名操作；应用不复制审批流转或预测下游
 动态人员。处理器先调用 `businessProcess.resolveOriginalTaskCommand(invocation)` 查询原结果，
+具名批准需要业务派生值与任务表单同事务保存时，可在固定定义声明
+`commandHandlers.approve: { operationCode: '...', transitionPolicy: 'workflow' }`，
+并调用 `commandWithData` 的 `expectedTransition: { kind: 'approval-projection' }`。
+平台核验原任务／令牌／修订／字段和候选人，保存数据并刷新事实，由内核处理
+会签等待及晚分支；任何未解析审批人都使事务失败。只允许显式 opt-in 的 approve
+handler；默认精确流转模式不变，旧站点须支持 `workflow.approval-business-command`。
+
 再合并受限任务字段、重验当前业务规则和资料，最后调用 `commandWithData`，
 使用 `expectedTransition: { kind: 'correction-replay' }`。平台验证真实本人补正、原任务与
 资料修订，在同一事务保存字段、刷新事实、核验 Native guards、关闭退回会话并重新计算。
-业务 mutation 仅写非事实的可信快照或审计字段，不能直接改变 `factProjection` 字段。
+业务 mutation 默认只写非事实的可信快照或审计字段。指导老师、部门或场馆等来源更正
+需要重算审批事实时，在固定`commandHandlers.resubmit`声明
+`derivedSubjectFields: ['instructorPerson']`：最多32个唯一、实际投影的顶层非system
+字段，且所有任务页面都不能将其设为可编辑。应用从当前可信来源重新计算，用原
+subject update和来源guards提交实际改变的派生字段；普通补填仍放在原任务表单。
+平台权威重读后原子刷新事实、修订和摘要，验证失效代码步骤能沿固定路径重放。
+其他事实与身份保持原保护，不允许在approve/reject/withdraw复用此权限。自动要求
+`workflow.correction-derived-subject-facts@1.0.0`，旧平台会拒绝新增声明，无额外开关。
+原实例继续固定旧定义；未改变的派生字段不回写，无声明时不能更换派生审批事实。
 
 `save_form` 仍可保存未填完的资料；只有通过业务重校验才能重提。直接调用原 Workflow
 重提入口会被拒绝，管理员不能替原发起人绕过该处理器。仅声明 resubmit 的流程可保留
@@ -1121,3 +1162,30 @@ nodes: {
 自动协商 `workflow.correction-business-command@1.0.0`，无需额外开启功能。
 本人标量补正支持 Native 写入，owned 子表补正仍不支持；原已成功结果先于当前资料重验
 恢复，不因日期推移或资料后来停用而被误报为失败。接入方法见[后端](backend.md#correction-business-command)。
+
+具名来源行需要展示原资源的材料时，表单可提供 `fileResourceCodes: { [fileId]: resourceCode }`。PC/手机按来源选择 Native 附件读取入口；这是展示提示，平台仍检查当前用户对每个原文件的权限。新上传保留声明的目标资源，提交后台仍须验证来源并使用原复制回执，不能直接绑定另一资源文件。
+
+角色绑定 `app_role` / `app_role_in_scope` 可声明 `selectedInputPath`，从固定代码步骤输出或流程事实中读取人员数组（用户ID或 `{ value, label }`）。平台按当前角色和范围重新核验，再按输入顺序保留其职责出处。越权、失效或重复人员整体拒绝；缺值阻断，只有显式 `[]` 可以消费节点已声明的无人策略。不可与 `routing`、`candidateField`、`inputPath` 混用。编译器要求 `workflow.role-input-selection@1.0.0`；该路径属于代码定义，不是管理员可改的连接或条件。
+
+### 申请人补正中的非流转子表
+
+固定 `correction` 任务可以包含一层 owned 子表，只要这些子表不在
+`subject.factProjection` 中。页内的 `subtable.create/delete/reorder` 和子字段
+白名单、只读、必填及模型 `minRows/maxRows` 仍生效。使用原任务的
+`key/state/values/id/revision` 编辑，不把新建申请的 `data` 行结构套到原行。
+平台把父子修改与 `resubmit` 放在同一授权、版本校验和事务中，应用的业务重提
+只需重核自身业务不变量，不能另写一次子行。投影为流程事实的子表暂不支持此
+补正形式，仍返回 `WORKFLOW_CORRECTION_OWNED_FACTS_UNSUPPORTED`；不能通过
+移除真实流转事实来绕过。原返回、重走首节点、职责和原命令恢复规则保持。
+
+具名新建的 owned 子表可以用 `formOptions.subtableFieldState(values)` 返回按子表字段
+和子列编码的 `{ visible, required }`，例如 `{ relatives: { extraFact: { visible: false } } }`。
+状态只调整页面展示与可见输入校验，不改变流程、读写授权或子表数据；隐藏旧值会保留，
+重新显示后恢复。列必须已在具名操作的 sealed child closure 内，未知表/列与非布尔状态
+拒绝；`required: false` 不能撤销声明的必填，服务端业务仍独立验证实际提交值。
+
+生成提交页的 `formOptions.dateTimeConstraints` 可按已匹配的 `datetime` 或
+`datetime-range` 字段提供 `timeZone`、范围、步长和 `disabledWeekdays`（ISO周一1
+至周日7）。这只控制新选择，保留已有值，不能当成服务端提交门禁。
+`formOptions.fieldHints(values)` 返回按已匹配字段的提示内容，用于时段或业务说明，
+它不改变必填和数据；PC/手机均显示在字段旁。未知字段和无效约束阻止新表单。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda",
-  "version": "2.59.3-http.0",
+  "version": "2.60.0",
   "description": "OpenXiangda 2.0 的统一命令、应用 SDK、MCP 与中文 AI 技能资料。",
   "type": "module",
   "main": "./dist/index.js",
@@ -64,6 +64,7 @@
   ],
   "dependencies": {
     "@js-temporal/polyfill": "0.5.1",
+    "@noble/hashes": "2.0.1",
     "@rc-component/async-validator": "6.0.0",
     "@rc-component/picker": "1.10.0",
     "@xyflow/react": "12.12.0",
@@ -71,15 +72,14 @@
     "dayjs": "1.11.18",
     "docx-preview": "0.3.7",
     "elkjs": "0.12.0",
-    "openxiangda-cli": "2.7.3-http.0",
-    "openxiangda-contracts": "2.70.0",
-    "openxiangda-devkit-core": "2.52.0",
+    "openxiangda-cli": "2.8.5",
+    "openxiangda-contracts": "2.73.0",
+    "openxiangda-devkit-core": "2.55.0",
     "openxiangda-legacy": "npm:openxiangda@1.0.269",
-    "openxiangda-mcp": "2.0.109",
-    "openxiangda-nest": "2.16.0",
-    "openxiangda-skill-kit": "2.3.90",
-    "xlsx": "https://github.com/1377385356/openxiangda/releases/download/vendor-mirror/xlsx-0.20.3.tgz",
-    "@noble/hashes": "2.0.1"
+    "openxiangda-mcp": "2.1.4",
+    "openxiangda-nest": "2.16.5",
+    "openxiangda-skill-kit": "2.3.95",
+    "xlsx": "https://github.com/1377385356/openxiangda/releases/download/vendor-mirror/xlsx-0.20.3.tgz"
   },
   "peerDependencies": {
     "@ant-design/icons": ">=6 <7",
@@ -144,32 +144,41 @@
   },
   "openxiangdaRelease": {
     "schemaVersion": "openxiangda.release-notes/v1",
-    "version": "2.59.3-http.0",
+    "version": "2.60.0",
     "status": "reviewed",
-    "title": "内网 HTTP 标准审批与签名兼容修复",
-    "summary": "基于已发布 2.59.2 的精确工具组合，修复内网 HTTP 缺少 SubtleCrypto 导致审批请求无法发送及手写签名摘要失败的问题。",
-    "newFeatures": [],
+    "title": "OpenXiangda 2.60.0：OSS 应用制品直传",
+    "summary": "开发工具可使用平台已配置的阿里云 OSS 直接上传应用构建包及镜像分块，服务器校验后按原摘要和进度导入，减轻客户 VPN 的大文件传输压力。",
+    "newFeatures": [
+      "新增独立 artifact-transfer/v1 能力协商，平台启用后自动使用限时、精确对象范围的签名直传。",
+      "镜像沿用原 OCI 摘要、预算、断点及受管仓库，已有 Registry 层在直传前复用。",
+      "平台存储设置支持前端 OSS/CDN 静态分发；登录、HTML 及 API 入口保持平台地址。"
+    ],
     "fixes": [
-      "标准审批及手写签名共用浏览器 SHA-256；原生 Web Crypto 不可用时采用 @noble/hashes 2.0.1，保持同一摘要和原操作恢复。"
+      "同时收录本次物化前主线已有 Changeset：按真实构建输入复用后端镜像、HTTP 环境浏览器 SHA-256、较大声明的有界容量协商。",
+      "收录主线已有标准流程页面整理、补正派生事实、补填值联动、日期辅助、提交后导航及子表展示修正。"
     ],
     "affectedUsers": [
-      "使用 HTTP 内网应用的 V2 审批人和手写签名用户。"
+      "使用 OpenXiangda V2 发布应用且平台已配置 OSS 的开发者与管理员。"
     ],
     "upgradeSteps": [
-      "精确安装 openxiangda@2.59.3-http.0，其他工具依赖保持 2.59.2 的已发布组合；重新部署测试环境并验收实际 HTTP 审批。"
+      "按平台正式升级入口部署配套服务器和管理界面。",
+      "将项目 openxiangda 升至 2.60.0，按锁文件安装依赖并刷新项目同版本资料。",
+      "管理员按需启用存储设置中的开发工具直传及静态分发，核验 GET/HEAD CORS 和目录权限。"
     ],
     "knownLimitations": [
-      "这是 http 专用兼容通道，保留 npm latest/stable-v2；不包含主线尚未发布的流程与共享契约增强。",
-      "保留原权限、幂等恢复、测试环境及 HTTP 传输方式。未知审批结果不得重新发起。"
+      "首轮仅支持阿里云 OSS；COS、MinIO、旧平台及关闭开关的站点保留原通道。",
+      "OSS 分发不等于 CDN 加速；CDN 域名需要独立配置，实际性能以部署样本为准。",
+      "暂存目录建议由管理员配置 1 天生命周期，平台不会覆盖整桶生命周期或 ACL。",
+      "本次以官方 Changeset 物化主线待发包内容，未新实现上述既有流程改动；所有版本与共享编译器需按平台组合配对。"
     ],
-    "issues": [],
     "compatibility": {
       "node": ">=24",
-      "platform": "contracts 2.70.0 / devkit-core 2.52.0，同源校验器摘要保持原 2.59.2 组合",
-      "v1": "V1不消费本修复"
+      "platform": "配套平台 artifact-transfer/v1 可选接口；应用/编译器契约不变",
+      "v1": "V1不消费新增 OSS 制品传输协议。"
     },
-    "sha256": "de5b032901bf648ae2d4497d8314c4745af1f10c170313d9661c5cee0c65c2f6",
-    "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.59.3-http.0"
+    "issues": [],
+    "sha256": "1becf5ff798495bf650c87783f0714ccaa1f5dd2d1edab1b93eccfdfbea6edde",
+    "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.60.0"
   },
   "scripts": {
     "build": "node ../../scripts/prune-package-dist.mjs && tsc -p tsconfig.json && node scripts/copy-assets.mjs",

package/releases/2.20.2.json

@@ -0,0 +1,30 @@
+{
+  "schemaVersion": "openxiangda.release-notes/v1",
+  "version": "2.20.2",
+  "status": "reviewed",
+  "title": "OpenXiangda 2.20.2：应用制品断线去重修复",
+  "summary": "Devkit 按平台制品收据的规范分类复用已验证的 Application v2 制品。修复 frontend/config/contracts/manifest 在平台已有相同摘要时仍重复完整上传的问题，保持 AppPackage 字节、权限和部署状态的原有权威边界。",
+  "newFeatures": [],
+  "fixes": [
+    "断线恢复时，仅在摘要、平台规范分类、Content-Type 和字节大小都匹配时复用已存制品；已存的大前端制品不再重复上传。"
+  ],
+  "affectedUsers": [
+    "经慢速或易断网络向支持 Application v2 制品收据的私有平台部署应用的 OpenXiangda 2.0 开发者。"
+  ],
+  "upgradeSteps": [
+    "将应用钉扎的 openxiangda-devkit-core 更新到 2.18.2，并按锁文件安装；如统一入口也被钉扎则升级到 openxiangda 2.20.2。",
+    "先回读原 DeploymentRun 和环境 Head；若此前失败仅发生在制品上传且无新运行，按 CLI 的可重试指针从原候选执行 deploy。"
+  ],
+  "knownLimitations": [
+    "平台尚未存储的制品仍需完整上传；本修复不能改善首次传输的链路速度或替代真实角色、CAS、人事与通知业务验收。"
+  ],
+  "issues": [],
+  "compatibility": {
+    "node": ">=24",
+    "workspaceGenerations": "v2",
+    "platform": "复用需要平台 Application v2 GET 制品收据返回规范分类、摘要、媒体类型和字节大小；无新数据库迁移。",
+    "v1": "V1 工作区与维护引擎不受影响。"
+  },
+  "sha256": "f5a6101d822234b7f1bf093c878692b94144f64dd829e99e72dc241780d5909e",
+  "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.20.2"
+}

package/releases/2.20.3.json

@@ -0,0 +1,29 @@
+{
+  "schemaVersion": "openxiangda.release-notes/v1",
+  "version": "2.20.3",
+  "status": "reviewed",
+  "title": "OpenXiangda 2.20.3：标准日期时间选择修复",
+  "summary": "修复指定时区的 PC 标准日期时间控件缺少小时和分钟列的问题，普通字段、生成表单、筛选与范围共用修复，不改变 UTC 存储和移动端协议。",
+  "newFeatures": [],
+  "fixes": [
+    "分钟精度显式显示时、分列，秒精度显式显示时、分、秒列。CLI 新应用模板同步钉扎修复后的根包。"
+  ],
+  "affectedUsers": [
+    "使用 Field Kit 指定时区日期时间输入的 OpenXiangda 2.0 应用。"
+  ],
+  "upgradeSteps": [
+    "将应用精确依赖升级到 openxiangda 2.20.3，按锁文件安装并验证日期选择后发布预发布版本。"
+  ],
+  "knownLimitations": [
+    "服务端业务时间窗、权限、DST 不存在和重复墙上时间校验保持原约束。本修复不替代应用真实角色验收。"
+  ],
+  "issues": [],
+  "compatibility": {
+    "node": ">=24",
+    "workspaceGenerations": "v2",
+    "platform": "无需服务端或数据库迁移。",
+    "v1": "V1 工作区与维护引擎不受影响。"
+  },
+  "sha256": "bd5d7d513df7ccc123d949842a5a987e585002848e98d52569190a687b212464",
+  "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.20.3"
+}

package/releases/2.60.0.json

@@ -0,0 +1,38 @@
+{
+  "schemaVersion": "openxiangda.release-notes/v1",
+  "version": "2.60.0",
+  "status": "reviewed",
+  "title": "OpenXiangda 2.60.0：OSS 应用制品直传",
+  "summary": "开发工具可使用平台已配置的阿里云 OSS 直接上传应用构建包及镜像分块，服务器校验后按原摘要和进度导入，减轻客户 VPN 的大文件传输压力。",
+  "newFeatures": [
+    "新增独立 artifact-transfer/v1 能力协商，平台启用后自动使用限时、精确对象范围的签名直传。",
+    "镜像沿用原 OCI 摘要、预算、断点及受管仓库，已有 Registry 层在直传前复用。",
+    "平台存储设置支持前端 OSS/CDN 静态分发；登录、HTML 及 API 入口保持平台地址。"
+  ],
+  "fixes": [
+    "同时收录本次物化前主线已有 Changeset：按真实构建输入复用后端镜像、HTTP 环境浏览器 SHA-256、较大声明的有界容量协商。",
+    "收录主线已有标准流程页面整理、补正派生事实、补填值联动、日期辅助、提交后导航及子表展示修正。"
+  ],
+  "affectedUsers": [
+    "使用 OpenXiangda V2 发布应用且平台已配置 OSS 的开发者与管理员。"
+  ],
+  "upgradeSteps": [
+    "按平台正式升级入口部署配套服务器和管理界面。",
+    "将项目 openxiangda 升至 2.60.0，按锁文件安装依赖并刷新项目同版本资料。",
+    "管理员按需启用存储设置中的开发工具直传及静态分发，核验 GET/HEAD CORS 和目录权限。"
+  ],
+  "knownLimitations": [
+    "首轮仅支持阿里云 OSS；COS、MinIO、旧平台及关闭开关的站点保留原通道。",
+    "OSS 分发不等于 CDN 加速；CDN 域名需要独立配置，实际性能以部署样本为准。",
+    "暂存目录建议由管理员配置 1 天生命周期，平台不会覆盖整桶生命周期或 ACL。",
+    "本次以官方 Changeset 物化主线待发包内容，未新实现上述既有流程改动；所有版本与共享编译器需按平台组合配对。"
+  ],
+  "compatibility": {
+    "node": ">=24",
+    "platform": "配套平台 artifact-transfer/v1 可选接口；应用/编译器契约不变",
+    "v1": "V1不消费新增 OSS 制品传输协议。"
+  },
+  "issues": [],
+  "sha256": "1becf5ff798495bf650c87783f0714ccaa1f5dd2d1edab1b93eccfdfbea6edde",
+  "url": "https://github.com/1377385356/openxiangda/releases/tag/v2.60.0"
+}

package/skills/manifest.json

@@ -4,7 +4,7 @@
     {
       "name": "openxiangda-v2",
       "description": "使用 OpenXiangda 2.0 从模糊业务想法、已有资料或具体变更出发，通过对话发现模块、完成详细产品设计，由当前 AI Agent 按需用 Image 2.5 等图片能力形成视觉参考，直接实现真实页面并在浏览器修正，再检查和交付应用；维护 1.x 应用时使用对应的 1.x 技能。",
-      "sha256": "e1292ebb4ca443992cffae317c5e76c87a4b57bc8612a73fcf7dc1924393b406"
+      "sha256": "6707f3d401dda7e99ac0aa6fcad2b2fb106017a3821c974620150bacfa6ee5ee"
     }
   ]
 }

package/skills/openxiangda-v2/SKILL.md

@@ -40,10 +40,10 @@ AI 接到新应用、页面或改版任务时，在同一个 OpenXiangda 工作
 未创建工作区时使用本 Skill 随根包发布的精确版本：
 
 ```bash
-pnpm dlx openxiangda@2.59.3-http.0 auth status --cwd <应用目录> --base-url <平台地址> --json
-pnpm dlx openxiangda@2.59.3-http.0 login --cwd <应用目录> --base-url <平台地址>
-pnpm dlx openxiangda@2.59.3-http.0 create <应用目录> --base-url <同一平台地址>
-pnpm dlx openxiangda@2.59.3-http.0 skill install --force
+pnpm dlx openxiangda@2.60.0 auth status --cwd <应用目录> --base-url <平台地址> --json
+pnpm dlx openxiangda@2.60.0 login --cwd <应用目录> --base-url <平台地址>
+pnpm dlx openxiangda@2.60.0 create <应用目录> --base-url <同一平台地址>
+pnpm dlx openxiangda@2.60.0 skill install --force
 ```
 
 创建前把产品要求的目标平台明确带入命令，不从旧登录态推断站点。已有工作区从原绑定恢复，平台不一致时先解决登录与目标，不改 link 文件跨站创建。
@@ -77,6 +77,7 @@ pnpm dlx openxiangda@2.59.3-http.0 skill install --force
 | 热点读取、抢票、排队、名额预占与原结果恢复 | [缓存、排队与配额](references/managed-concurrency.md) |
 | 报名按钮、表单排队、短确认页、预占倒计时与前端恢复 | [并发前端接入](references/managed-concurrency-frontend.md)：按六种形式选择；仅使用已导出的 API，区分待实现封装 |
 | 管理成员或查看有效流程参数 | [应用管理](references/administration.md) |
+| 高水位/死信、正式环境缺密钥、通知未发送或收件人错误 | [AI 应用自助操作](references/application-operations.md)；先读 `admin operations --json` 或 MCP `application_operations`，在已有授权范围内直接执行，沿用当前平台账号，无需人工打开管理页 |
 | 检查、部署、生产发布与故障恢复 | [验收](references/testing.md)、[交付](references/delivery.md) |
 | 需求记录与版本升级 | [全流程记录](references/appspec.md)、[升级](references/upgrading.md) |
 | 选择 CLI/MCP 操作 | [命令](references/cli.md)、[MCP](references/mcp.md) |

package/skills/openxiangda-v2/references/administration.md

@@ -1,5 +1,8 @@
 # 应用管理与有效配置
 
+事件高水位、正式环境缺凭据或消息未发送时，开发者AI直接读取[应用自助操作](application-operations.md)
+并使用 `admin operations` / MCP `application_operations` 发现和执行已有管理能力，无需人工管理页面。
+
 平台的应用管理控制台维护应用成员、角色授权和流程运行参数。应用自身声明的 `/admin` 业务菜单展示业务页面，两者职责不同。可见入口和可执行操作以当前用户与目标环境返回结果为准。
 
 角色成员的范围维度也支持模型字段的 `userCandidates.scope` 引用，不要求为审批人职责增加无关的数据读写策略。目录 `scopeDimensions[].applicability.candidateFields` 返回字段所在的资源、数据修订、字段、角色与操作；当前环境及仍在办理的历史流程所引用的字段均可贡献范围适用性。实例完成或发起命令取消后，旧字段不再单独贡献适用性。配置成员的范围不会自动授予数据读写、菜单或应用管理权限；实际选人与提交仍核验范围、操作、成员有效期及账号状态。
@@ -111,7 +114,7 @@ jointReviewers: {
 管理员仅在代码开放人员来源配置的节点中调整职责组合；单选仍保存 `roleCode`，
 多选保存 `roleCodes`。保存、版本激活均检查所有职责，任何职责失效或查询失败都不能
 变成部分名单。总候选最多 200 个成员身份；去重后的审批上限仍受原 binding 限制，
-自动抄送最多 20 人。声明自动协商 `workflow.role-union@1.0.0`，无需初始化开关。
+自动抄送遵守原binding人数预算，默认20、显式最大200人。声明自动协商 `workflow.role-union@1.0.0`，无需初始化开关。
 
 管理范围检索使用 `listRoleManagementScopeValues(dimensionCode, { keyword, limit, offset })`，返回 `NativeRoleManagementScopeValuePage` 的 `id/label` 与 `limit/offset`。它使用 `openxiangda.native-role-management-scope-value-page/v2`，与 Data 字段选择器的 `value/label/cursor` 协议分开。权限仍要求对成员的分配或更新能力；只读权限不因此扩张。
 
@@ -199,7 +202,7 @@ export function ReadableWorkflow({ workflowCode, version }: {
 
 模式为 `single/any/all/sequence` 的允许子集；可维护来源限 `fixed_users/app_role/app_role_in_scope`，范围角色必须已有代码声明的 scope。按钮 code 保持同意、拒绝、退回、转交、委托、加签的稳定语义；同意和拒绝不能关闭。只有同意/拒绝支持意见规则；拒绝默认必填，固定节点代码可用 operationPolicy.reject.commentRequired: false 显式选填。管理员可收紧选填规则，也可恢复代码明确允许的选填；不能放宽代码必填或未声明时的拒绝默认必填。已进入的任务保留冻结规则。字段显隐、填写与必填行为由应用页面和代码维护，不提供流程节点的字段管理覆盖。可编译声明见 `examples/workflow-administration/declaration.ts`。
 
-自动抄送节点仅开放名称、说明和显式声明的 `administration.assigneeProviders`；未开放时接收来源只读。共享编辑器显示“抄送人”，不显示审批方式或审批按钮，固定名单最多20人。`next`、空人策略和通知策略仍归代码；新配置只影响以后进入，过去抄送名单保持冻结。完整例子见 `examples/workflow-administration/automatic-cc.ts`，执行及读取边界见[自动抄送](workflow-events.md#automatic-cc)。
+自动抄送节点仅开放名称、说明和显式声明的 `administration.assigneeProviders`；未开放时接收来源只读。共享编辑器显示“抄送人”，不显示审批方式或审批按钮，固定名单遵守原binding的 `min/max`，默认1–20、显式最大200人；管理员不能扩大该预算。`next`、空人策略和通知策略仍归代码；新配置只影响以后进入，过去抄送名单保持冻结。完整例子见 `examples/workflow-administration/automatic-cc.ts`，执行及读取边界见[自动抄送](workflow-events.md#automatic-cc)。
 
 应用自定义管理页可使用 `WorkflowNodeConfigurationEditor`（`openxiangda/react`），输入同一读面中的节点、principals 和 context.headRevision，放在平台 App/UI 作用域内。它复用下列当前用户 SDK：
 

package/skills/openxiangda-v2/references/application-operations.md

@@ -0,0 +1,150 @@
+# AI 应用运行自助操作
+
+开发者 AI 使用当前平台账号和工作区绑定直接完成事件、环境凭据和消息中心维护。
+用户已授权的诊断及修复无需再让用户点击管理页面。平台仍核验已有应用管理权限；
+首次账号登录沿用原认证流程，开发者身份不自动获得管理员权限。
+
+## 发现和执行 {#discovery}
+
+```bash
+pnpm openxiangda context --json
+pnpm openxiangda admin context --environment production --json
+pnpm openxiangda admin operations --json
+pnpm openxiangda docs application-operations
+printf '%s' '{}' | pnpm openxiangda admin execute events.status --environment production --input - --json
+```
+
+`admin operations` 读取本地目录，每项给出 `operation/inputSchema/effect/permission/recovery`。
+`admin execute <operation> --environment <test|production> --input <file|-> --json` 直接执行。
+输入文件或标准输入只放目录中的 **input** 对象，最多32KiB，不放密码。
+执行必须明确环境；test映射平台preproduction。应用、站点和身份来自当前工作区及会话，
+拒绝任意路径、自报appCode、tenantId、actor和environmentKey。
+
+MCP先调用 `application_operations`，再调用 `application_operation`：
+
+```json
+{"operation":"events.status","environment":"production","input":{}}
+```
+
+CLI与MCP共用输入Schema、服务和平台错误。成功结果在 `data.result`，环境在 `data.environment`。
+配置与恢复在已授权范围内直接执行；health访问外部健康接口并保存元信息。
+操作目录不证明远端接口已部署或当前用户有权，执行结果由平台决定。
+
+## 事件高水位与指定恢复 {#events}
+
+遇到 `EVENT_V2_BACKPRESSURE_HIGH_WATER` 先读 `events.status` 的admission：采样新鲜度、
+触发条件、当前值、阈值、恢复条件和消费者健康。再用 `events.subscriptions`、
+`events.deliveries`、`events.journal`、`events.audit` 定位订阅、原事实及投递。
+分页默认20/最大100，按服务器cursor继续，不无限遍历历史。
+按原requestId或commandId核对事务，见[部署与诊断](delivery.md)。未观测到、超时或503
+不能证明未提交，不换键重建业务数据。
+
+Native记录事件才能使用 `ordering:record`。订阅错误先修正应用声明并正常部署，
+再用 `events.replay` 恢复指定原deliveryId：
+
+```json
+{
+  "deliveryId":"11111111-1111-4111-8111-111111111111",
+  "reason":"原订阅配置已修复并部署，恢复该投递",
+  "idempotencyKey":"event-recovery:original-operation-id",
+  "useCurrentSubscription":true
+}
+```
+
+示例UUID换成实际查询结果。false使用原订阅规格，必须显式选择。
+平台核对类型、过滤和排序事实，只恢复该订阅投递并保留历史审计，不重建会员。
+未知结果先查投递/审计，保留同键同请求。低于阈值且取得新鲜采样后自动恢复写入；
+没有清队列或提高容量阈值的应用操作。验证单笔事务回执及列表后再继续授权导入。
+
+## 环境凭据复用 {#secrets}
+
+遇到 `APPLICATION_V2_SECRET_NOT_CONFIGURED`，分别在test及production执行 `secrets.list`。
+只返回名称、状态、revision、hasValue和有效期等元信息。来源用途已经验证且有效时，
+在目标production执行 `secrets.copy`，首次正式部署前也可操作，无需询问或读取明文：
+
+```json
+{
+  "sourceEnvironment":"test",
+  "reason":"正式环境复用已验证的集成凭据",
+  "idempotencyKey":"secret-copy:original-operation-id",
+  "secrets":[{"name":"integration-client-secret","sourceRevision":3,"expectedRevision":0}]
+}
+```
+
+名称和修订取自两侧实时列表；目标不存在用0，覆盖用目标实际revision。最多50个唯一名称，
+同应用跨环境原子复制，任一冲突拒绝整批。目标拥有独立加密版本，来源轮换不自动覆盖。
+未知结果保留原键和完整请求，先回读，必要时显式同键重试。确认的409先刷新两侧基准、
+核对后形成新操作，不能只递增revision强行覆盖。
+随后执行 `deploy --environment production --from <成功测试运行ID> --dry-run`。
+环境变量注入需新部署才读取目标版本；动态Secret服务沿用原读取规则。
+工具不会自动复制所有项；测试凭据是否适用于真实生产由已确认的集成用途决定。
+
+## 通知渠道与默认路由 {#channels}
+
+先读 `notifications.diagnostics/channels/rules`。缺少标准模板/规则时执行
+`notifications.bootstrap` 再回读。已有健康渠道可直接选默认，不必重新配置或获取密码。
+新增/更新分别用 `notifications.configure-external-http` 和 `notifications.configure-dingtalk-oa`。
+完整参数见目录inputSchema；新渠道revision用0，更新用实时revision。配置只接受Secret引用，
+不接受token、明文clientSecret或收件身份。External HTTP支持HMAC、OAuth2客户端凭据和mTLS。
+正式启用沿用服务器 `confirmProduction:true`，表示该请求明确选择正式环境，无需管理页。
+
+以下仅演示结构，真实providerCode、baseUrl、identityRealm、功能和Secret引用来自已授权集成，
+不能直接把示例地址发送到生产：
+
+```json
+{
+  "bindingCode":"organization.default","expectedRevision":0,"status":"active","confirmProduction":true,
+  "config":{
+    "schemaVersion":"openxiangda.notification.external-http-channel/v2",
+    "providerCode":"organization","baseUrl":"https://notify.example.com","identityRealm":"organization",
+    "auth":{"mode":"HMAC_SHA256","keyId":"primary","secretRef":"notification-hmac"},
+    "callback":{"enabled":false,"maxSkewSeconds":300,"actionTokenTtlMinutes":60},
+    "features":{"interactiveActions":false,"readReceipt":false,"todoSemantics":true},
+    "requestTimeoutMs":10000
+  }
+}
+```
+
+配置后执行 `notifications.test`：
+
+```json
+{"bindingCode":"organization.default","channel":"external-http"}
+```
+
+这是协议/凭据健康检查，不发实际收件通知。随后执行 `notifications.set-default`：
+
+```json
+{"bindingCode":"organization.default","expectedRevision":2,"expectedBindingRevision":1}
+```
+
+两个revision分别来自workflow.standard规则和渠道。冲突先回读核对。默认只影响当前环境
+的标准工作流通知；自定义规则仍由原owner维护。正式隐式路由不选Fake，Fake成功只证明模拟。
+
+## 原通知失败与恢复 {#notification-recovery}
+
+`notifications.messages` 按correlationId或recipientUserId查原消息，默认20/最大100；
+`notifications.message` 传原messageId，读取recipients/deliveries/attempts/审计。
+平台受理、渠道发送、已读和待办关闭分别核对，不能把受理当成老师已经收到。
+
+| 证据 | AI下一步 |
+| --- | --- |
+| 凭据缺失/禁用/过期 | secrets.list核对；用途合适时secrets.copy，随后test |
+| 默认未设置或规则缺少 | rules/channels核对，必要时bootstrap，再set-default |
+| 通道协议或联通失败 | 核对原集成接口、鉴权引用和功能，configure修正后test |
+| RECIPIENT_CHANNEL_IDENTITY_NOT_FOUND | 核对目标平台用户及identityRealm对应外部账号；由现有身份目录/消息服务owner维护映射，不创建虚假老师身份 |
+| 共享队列、数据库或网络故障 | 保存requestId、环境、消息/投递ID及状态证据，交给平台基础设施owner |
+| 403权限不足 | 由应用管理员授予已有管理权限，不获取服务器root或密码替代 |
+| 404新接口不存在 | 核对工具及平台版本，升级对应能力，不用临时SQL绕过 |
+
+修复后查 `notifications.dead-letters`，可按messageId限定。确认原任务仍有效且授权包括
+实际通知恢复，再执行 `notifications.replay`，只传指定deadLetterId。这可能真正发送通知。
+平台保留原消息、目标和审计；不重建通知或批量恢复历史待办。
+网络中断后查询原死信/消息；已恢复后的404不能当成未执行，不自动连续重放。
+已投递或被新修订取代的消息遵守服务器原有规则。
+
+## 升级与验收 {#verification}
+
+已有项目使用精确锁定版本；升级后运行 `skill install --workspace <应用目录> --force` 并
+重启MCP。应用AI不需要本地平台、数据库、Docker或学校服务器账号。
+先做只读诊断、无实际收件人的健康测试及CAS拒绝验证，再验收单笔回执/落库/实际投递。
+不要用批量导入或历史群发测试恢复。首次会话授权、权限委托和外部身份owner边界沿用原合同。

package/skills/openxiangda-v2/references/appspec.md

@@ -172,7 +172,7 @@ ADR 状态支持 `proposed`、`accepted`、`superseded`、`rejected`；按真实
 
 ### 按 ID 读取
 
-`context` / `workspace_context` 默认返回总纲、相关变更索引、阶段缺口和下一步。`spec context` / `appspec_context` 的 context v4 默认只返回总纲正文及有界索引，按稳定 ID 加载相关能力、变更、ADR 和 DES-* 设计正文及 documents 传递引用。product/experience/design/reviews 的单层 Markdown 也进入当前资料与原测试提交读取；非 Markdown 原型只引用不执行。当前资料最多 128 文件、2 MiB，正文上下文最多 256 KiB，超出时明确诊断。
+`context` / `workspace_context` 默认返回总纲、相关变更索引、阶段缺口和下一步。`spec context` / `appspec_context` 的 context v4 默认只返回总纲正文及有界索引，按稳定 ID 加载相关能力、变更、ADR 和 DES-* 设计正文及 documents 传递引用。product/experience/design/reviews 的单层 Markdown 也进入当前资料与原测试提交读取；非 Markdown 原型只引用不执行。当前资料最多 512 文件、2 MiB，正文上下文最多 256 KiB，超出时明确诊断。较大的应用可保留各批次的产品、架构、变更与评审，不需要删除历史来容纳新模块；增加文件数量不放宽字节或上下文预算。
 
 历史与当前资料独立预算，每页 50 条，使用 `--history-offset 50` 或 MCP `historyOffset` 翻页。历史索引仅读取头部，稳定历史 ID 可直接读取页外正文；归档增加不会挤掉当前资料。索引读取上限为 256 个年份目录、10 万个记录名和 5 秒，达到预算给出提示，文件不会删除。`workspaceDigest` 对应当前资料与实时契约，分页不改变它；`selectionDigest` 对应选中的具体正文与契约。
 

package/skills/openxiangda-v2/references/backend.md

@@ -16,6 +16,19 @@ operation、事件消费者、人员提供器，然后运行 `pnpm openxiangda c
 工具从当前版本的内置模板初始化后端源码并安装依赖；后续不会覆盖业务代码。
 标准表单、流程定义/激活和平台待办通知使用平台运行时，不会隐式启用 Nest。
 
+当前官方 Dockerfile 保留原 package.json，使用 `--frozen-lockfile` 安装后端和共享契约
+依赖；锁文件与源码不一致会明确失败，请在本地更新并提交锁文件。pnpm store、registry
+metadata 与 Corepack 使用当前 BuildKit builder 的持久缓存，依赖层失效时优先复用已有包。
+生产依赖整理也使用同一包和 metadata 缓存及 `--prefer-offline`；首次 legacy deploy
+仍需读取 registry metadata，缓存命中后减少重复联网。首次构建或 builder 缓存被回收后
+仍需要下载依赖。不要求应用更改本地 workspace 链接方式。
+
+随模板生成的 `Dockerfile.dockerignore` 仅包含后端必需输入，避免前端/文档变化使
+依赖层失效。已有后端源码归应用所有，不自动覆盖旧 Dockerfile；升级时可对照
+工具包 `openxiangda-devkit-core/templates/backend/` 更新 Dockerfile 和专用 ignore，
+并保留自己的业务构建步骤及依赖。需要额外目录时同步加入 ignore 白名单，重新验证。
+纯前端发布的镜像复用与重建选项见[交付](delivery.md#测试部署)。
+
 依赖安装失败会保留新源码并报告 `OPENXIANGDA_BACKEND_INSTALL_FAILED`；重试相同命令
 即可继续。关闭 backend 不自动删除用户源码。仅删除已经确认不用的后端目录和其依赖。
 开发者本地 `/api` 经过 connected proxy 进入 Nest；普通浏览器身份经过平台实时授权，
@@ -91,6 +104,14 @@ return businessProcess.commandWithData({
 `not_observed` 仅表示尚未看到确定回执；保留原输入、原 token 和原键，按用户显式操作恢复。
 声明及限制见[工作流](workflow-events.md#correction-business-command)。
 
+更正指导老师、申报部门或预约场馆时，可在固定resubmit handler声明
+`derivedSubjectFields`白名单。处理器恢复原结果后，按当前可信字典和资料计算实际
+改变的字段，将它们与非事实审计值放入同一次subject update并携带来源guards；
+用户输入不能直接提供派生审批人，页面仍只提交原补正表单。平台从权威Native记录
+重读事实，与任务、数据和回执同事务更新；无法安全重放、来源/CAS或类型变化整笔
+回滚。未变化字段省略，确保已固定的无此声明旧实例仍可做普通更正。完整限制与
+自动能力协商见上述工作流专题，不另建重算API、事务或权限状态。
+
 ### 数据修改的原结果恢复 {#data-business-commands}
 
 仅修改业务资料的具名动作，在 `platformAccess` 声明

package/skills/openxiangda-v2/references/cli.md

@@ -7,7 +7,7 @@
 | `pnpm openxiangda auth` | 只读 | 只读核验指定平台授权，不登录或刷新会话 |
 | `pnpm openxiangda context` | 只读 | 只读查看工作区、版本与平台绑定 |
 | `pnpm openxiangda docs` | 只读 | 按主题和章节读取当前版本中文资料 |
-| `pnpm openxiangda admin` | 只读 | 只读查看应用管理能力和流程节点运行配置 |
+| `pnpm openxiangda admin` | 远端变更 | 查看管理能力、自助操作契约，或按明确环境执行事件、密钥及通知操作 |
 | `pnpm openxiangda create` | 远端变更 | 创建、绑定并初始化应用 |
 | `pnpm openxiangda source` | 远端变更 | 配置应用源码仓库、查看状态或提交推送 |
 | `pnpm openxiangda dev` | 本地写入 | 连接平台测试数据启动本地 Web，按需启动 Nest |