openxiangda-skill-kit 2.3.112 → 2.3.114

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda-skill-kit",
-  "version": "2.3.112",
+  "version": "2.3.114",
   "description": "OpenXiangda 2.0 中文 AI 技能的校验、分发与安装。",
   "type": "module",
   "main": "./dist/index.js",
@@ -17,7 +17,7 @@
     "README.md"
   ],
   "dependencies": {
-    "openxiangda-devkit-core": "2.65.0"
+    "openxiangda-devkit-core": "2.66.0"
   },
   "devDependencies": {
     "tsx": "4.23.12",

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

@@ -230,7 +230,7 @@ await saveWorkflowNodeConfiguration('requests', node.nodeId, {
 
 打包和目标预检自动将含 `routing` 的 binding 纳入该能力的使用摘要，与平台编译结果严格对齐；无需应用手工填写能力清单或额外开启开关。
 
-标准管理页的“流程定义 / 审批人路由”提供策略检索、规则维护和分页历史。应用工具页可直接嵌入 `WorkflowAssignmentRoutingManager`（`openxiangda/react`）；单策略编辑可使用 `WorkflowAssignmentRoutingEditor`。放在现有 App/UI 作用域内，保留后台路由和入口权限。读写都使用当前用户及当前挂载环境，首版与节点配置一样要求应用 superAdmin，角色维护委派不授予路由管理权。
+标准管理页的“流程定义 / 审批人路由”提供策略检索、规则维护和分页历史。应用工具页可直接嵌入 `WorkflowAssignmentRoutingManager`（`openxiangda/react`）；单策略编辑可使用 `WorkflowAssignmentRoutingEditor`。放在现有 App/UI 作用域内，保留后台路由和入口权限。读写都使用当前用户及当前挂载环境，该专项路由入口仍要求应用 superAdmin，角色维护委派不授予路由管理权。
 
 规则核对只计算内容变化，打开规则表单后原样加入草稿不会产生多余修改。发生修订冲突时载入最新基准并保留整组草稿，再逐项核对；这个操作不会自动合并其他管理员的修改。窄屏工具栏允许换行，表格在内部滚动，规则表单按单列显示。
 
@@ -257,3 +257,23 @@ const history = await loadWorkflowAssignmentRoutingHistory('college-review', { l
 保存的是整组规则，最多 256 条/256 KiB；最多 8 个维度、16 个来源，每维度 64 个匹配值。维度间同时满足、值内任意匹配，空 matches 为通用。可限定流程和审批节点，节点须带流程代码。时间为 `[validFrom,validTo)`。唯一最高优先级替换优先，`replace_then_append` 随后追加，`replace_only` 命中替换时忽略追加；没有替换时均采用默认来源再追加。追加按优先级降序、通用先专项、稳定代码排序，同来源同次只解析一次。
 
 64 条以上规则同时命中、最高替换同级冲突、缺少事实、替换无人或候选越界都会明确阻塞，不自动通过或隐式兜底。预览和执行复用同一解析器；任务冻结规则修订和分派，管理员调整只影响未来进入。修改与发布使用同一环境锁，CAS 冲突重新读取基准、保留草稿并核对前后差异；未知结果保留完整原请求及 operationId 后显式重试。清空 rules 也产生修订和审计。发布不得改变在途同名策略语义，即便尚无补充规则；非空规则引用的来源和节点必须保留。
+
+
+## PC 流程管理委派 {#workflow-management}
+
+配套平台可为明确环境启用流程管理委派，再给应用角色授予指定流程的动作。平台部署开关 `OPENXIANGDA_WORKFLOW_MANAGEMENT_ENVIRONMENTS` 默认空，只接受真实环境UUID；它不是应用开发者可修改的授权声明。未启用时保留原管理员边界，装了新SDK不等于目标已开放。
+
+| 动作 | 可执行范围 |
+| --- | --- |
+| `definition.read` | 查看已发布流程 |
+| `draft.edit` | 读取并编辑共享草稿 |
+| `publication.publish` | 读取共享草稿并正式发布；不隐含编辑权 |
+| `handling.configure` | 维护已发布节点允许的办理配置；不授予拓扑/共享草稿编辑权 |
+
+写动作包含必要的查看范围，但不相互授予其他写动作，也不授予成员管理、数据读写或再次委派权限。真实有效角色、有效期、流程目标和环境由平台重新核验；界面隐藏按钮只是呈现，不能替代服务端准入。
+
+`WorkflowDesigner` 的已发布读面与共享草稿读面分开：只读/仅办理配置用户不读取草稿修订、草稿诊断或编排目录；编辑/发布用户按各自动作显示界面。流程设计和授权管理本轮只针对PC，移动审批办理页保持其独立业务范围。
+
+权限失效时停止写操作并保留未保存输入。原操作结果未知时保留完整原请求/operationId，查询原结果；不因刷新、关闭窗口或换新键重发。确认成功的最小结果不冒充可读取的完整草稿；确认冲突后重新读取基线并由用户处理差异。仅因权限正在变更而明确未写入时，稍后仍沿原请求重试；其他未知不能当作未写入。
+
+原管理员配置与新委派能力必须使用同批contracts、服务端、浏览器SDK和平台管理前端。不要复制授权判断、使用超管身份代验受委派角色，或把组件fixture验证当成目标实际授权验收。

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

@@ -27,6 +27,12 @@
 - 标准审批、待办与通知：按需声明平台能力，见[工作流](workflow-events.md)。
 - 真实事务或外部集成：使用[按需后端](backend.md)，不为每张表重写 CRUD 控制器。
 
+### 按任务读取声明前提
+
+用契约读取入口的 `selector=prerequisites` 查看当前完整编译器推导的平台能力、资源、具名操作、流程和事件消费声明；再用返回的 `prerequisites:类型:代码` 选择器读取具体项。MCP `contract_describe` 使用该投影，按 `offset/limit` 分页；CLI 的日常 `check` 仍沿原编译与目标预检路径。
+
+这一步只证明本地声明通过原编译器，保留配置/契约/编译摘要，不访问平台。具名授权、目录、文件、事务与流程前提沿原任务声明中的引用核对，不能从名称猜依赖；目标能力和当前用户权限仍分别由原平台预检与真实角色验证。原编译器报错时先修正其pointer，不能把未继续检查的部分当作通过。
+
 ### 判定是否真的需要 Nest 后端 {#backend-decision}
 
 想写后端接口时，先按顺序核对平台已有的声明式答案；命中前几行的需求不得启用 Nest。
@@ -60,3 +66,5 @@
 正式激活和业务运行证据分别记录，不用通过的 fixture 替代真实业务验收。
 
 [AppSpec](appspec.md)保存业务意图、设计与交付记录，不复制字段 Schema、生成契约和部署状态。新应用维护具体设计和评审，复杂度随业务展开；既有小变更沿用有效设计，仅修订受影响记录，无行为变化可引用已有记录。每轮先读取当前规则、澄清业务、评估架构、权限和性能，随后实施与验证，发布后更新当前规格及交接。测试部署前需要设计和验收计划，生产晋级前需要绑定测试运行及包摘要的实际验收报告。
+
+迁移已有1.x应用时，先补齐[业务迁移矩阵](upgrading.md#business-migration)，再按模型、任务、角色、状态、文件和外部效果组织实施。不要只按表单字段清单判断迁移完成。Connected Dev可投影与需TEST正式部署的边界见[连接开发变化矩阵](getting-started.md#connected-development)。

package/skills/openxiangda-v2/references/getting-started.md

@@ -137,6 +137,21 @@ AppSpec 随开发持续维护：测试发布前补齐总纲、关联变更与验
 不兼容声明会明确报错，不能把旧流程偷偷当作本地新流程。共享测试数据的真实写入仍会影响同一数据集，
 配置隔离不等于数据隔离。
 
+按改动选择开发路径：
+
+| 改动 | 当前支持路径 |
+| --- | --- |
+| React 页面与本地 Nest 实现 | 继续本地源码联调；是否启用 Nest 由业务需要决定 |
+| 已有模型新增字段、页面声明、具名操作配置 | 由平台校验后投影到开发会话；不切换已发布 TEST Head |
+| 新模型、已有字段类型/约束、数据策略、角色和流程定义 | 先核对差异，在 TEST 正式部署后再创建开发会话 |
+| 后台事件、Timer、DateTrigger、浏览器文件流 | 通过已部署 TEST 制品验收；本地会话不接管线上后台执行 |
+| 显式连接生产环境 | 使用已发布配置和真实生产数据；本地配置不投影，持续显示生产提示 |
+
+支持新反馈的配套平台会给出 `developmentFeedback`：需要修改配置、重建会话、核对原运行或安排 TEST 发布。
+CLI 保留字段 `pointer`、原 `configurationRunId`、`causeCode` 与 `requestId`；字段位置与HTTP端点分开显示。
+进行中或结果不明时先核对原运行，不换随机键重建。下一步中的命令是固定建议，不会自动执行发布或重试；
+未知反馈只提供排查指引，不推定原输入可以直接重试。
+
 本地 Nest 使用开发会话自身的短期 OAuth 凭证，凭证只进入 Nest 环境。
 它不会读取、旋转或撤销已部署后端的凭证。普通浏览器联调保留实际登录人的身份与角色；
 loopback 代理仅注入配置选择证明，平台和 Nest 将该证明与签名调用中的 sessionId 核对。

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

@@ -98,7 +98,7 @@ MCP 使用项目锁定的根包；在客户端配置下列 stdio 启动参数，
 
 ## contract_describe
 
-查看应用契约。默认返回有界索引；用 selector 读取模型、流程、能力，或 navigation/permissions。菜单建议只复制一次，运行时不自动应用。
+查看应用契约。默认返回有界索引；用 selector 读取模型、流程、能力，或 navigation/permissions/prerequisites。任务前提来自原编译器，不代表目标或角色可用。菜单建议只复制一次，运行时不自动应用。
 
 - 只读：是
 - 可替换文件或改变远端状态：否
@@ -112,7 +112,7 @@ MCP 使用项目锁定的根包；在客户端配置下列 stdio 启动参数，
   "type": "object",
   "properties": {
     "selector": {
-      "description": "index、navigation、permissions、all 或索引给出的选择器",
+      "description": "index、navigation、permissions、prerequisites、all 或索引给出的选择器",
       "type": "string",
       "maxLength": 200
     },

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

@@ -49,3 +49,28 @@
 保留失败指针和变更差异。资料缺失或摘要不符时重新安装该精确版本，不能复制其他版本的文档掩盖问题。应用版本回滚、依赖降级和数据/迁移恢复分别处理；降级 npm 包不等于撤回已经发生的业务写入。
 
 平台能力不足时交由平台维护者升级，不通过删除字段、改生成契约或退回 1.x 接口绕过。开发者无需执行工具链 npm 发包或平台数据库迁移。
+
+## 从 1.x 迁移业务到 2.0 {#business-migration}
+
+迁移按用户任务验收，不能只以“字段已搬过来、CRUD 页面能打开”为完成。1.x 继续使用独立维护工具；在原业务尚未完成切换时保留它的入口、数据和恢复路径，不让 V2 编译器兼容或发布 V1 工作区。
+
+先在 AppSpec 的当前迁移变更中保存下列矩阵，引用原资料/页面/流程的精确来源及现行版本；Schema、Head、部署状态仍从原平台读取，不复制为另一份权威。已有确认可引用，不重新编造用户确认。
+
+| 核对维度 | 必须记录 | 完成证据 |
+| --- | --- | --- |
+| 用户任务与入口 | 谁、何时、从哪个入口完成什么；原入口与新入口映射 | 对应角色走通完整任务，结果读回 |
+| 页面与设备 | 列表、详情、编辑、自定义报表及必要设备范围 | 真实平台入口交互；未要求移动的管理页面不额外扩范围 |
+| 角色与数据范围 | 角色并集、组织/部门/本人范围、字段读写与越权拒绝 | 至少允许和拒绝各一条；超管不能代验普通角色 |
+| 模型与历史数据 | 原字段含义、精度、空值、子表、关系、状态及历史记录归属 | 原样本与新结果逐项对照；原ID映射和不可迁移项明确 |
+| 流程与状态分支 | 发起、办理、转交、退回、撤回、补正、抄送及终态 | 必要正常/异常分支、实际办理人、待办和业务状态一致 |
+| 文件与附件 | fileId、记录绑定、原存储位置、下载权限、引用关系 | 历史样本可授权读取；不能按当前存储默认值猜归属 |
+| 后台与外部集成 | 事件、Timer、通知、外部订单/账务等效果及原键 | 原操作回执、外部读回、失败和未知结果恢复路径 |
+| 并发和恢复 | 重复提交、版本冲突、网络丢响应、处理中退出 | 沿原键查询和恢复；无重复副作用、不丢已确认结果 |
+| 发布与切换 | TEST版本、验收人、停写/流量切换、旧系统职责、回退边界 | TEST成功版本原样晋级，关键数据与任务再读回 |
+| 测试收尾 | 新测试记录来源、允许清理的域、保留证据和未知效果 | 原owner核对并清理；不支持的域标为未回收，历史数据不批量删除 |
+
+每一行绑定验收用例ID、来源、目标TEST版本/包摘要、实际角色、结果和证据。使用“通过、失败、未覆盖、不适用（附原因）”区分状态，不能把未实现分支写成通过。临时脚本或模拟接口只证明其覆盖的行为；真实角色、原文件与外部效果另行验收。
+
+建议先选代表任务覆盖公共边界，再批量迁移相同能力；无需为每条流程重复平台完整数据库/队列矩阵。存在未知外部写入时，先按原请求键与业务编号读回，不切换身份、换键重发或回放整个流程。数据库/外部业务效果已提交后，回滚代码不等于撤销效果；按原恢复方案处理。
+
+迁移方案和实施记录属于应用项目，通用规则从本专题引用。最后按[验收](testing.md)和[交付](delivery.md)关闭原TEST版本；不能用新构建替换已验收候选。

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

@@ -1250,3 +1250,14 @@ pnpm openxiangda workflow sync request-review --from production --to test \
 `--copy-handling-defaults` 可复制办理模式、按钮和角色覆盖；两边的指定人员覆盖都保持环境所有。源环境不被修改。同步后的目标画布草稿若基线已经过时，需要重读或合并，不能覆盖新的 Head。请求不确定时，保留相同操作标识、两个修订号和完整参数重试；不要换标识重做。CLI 与 MCP 共用这些权限、校验、幂等和发布入口。
 
 部署前记录目标流程修订号，激活前再次核对。期间若有人发布了画布，激活返回 `WORKFLOW_SOURCE_HEAD_CHANGED`，应用 Head 与流程 Head 在同一事务回滚；已准备的不可变登记保留。同步成功、源码检查成功、包发布与真实审批验收分别核对。
+
+
+## 条件人员规则的 PC 编辑 {#conditional-people-editor}
+
+配套平台返回已发布的条件人员上下文，且当前目录声明 `conditionalAssignments: true` 时，PC流程编辑器可维护审批/办理节点的有序条件规则与必选“否则”。缺少上下文或能力提示时保留只读/原范围，不把条件规则拆成平铺人员来源。共享草稿的读写权限遵循[流程管理委派](administration.md#workflow-management)。
+
+标准人员/角色来源只能在原上限内修改，复杂来源使用精确发布或冻结引用；连续主管叶子要求sequence。抄送、嵌套条件、发起自选与应用provider不在该编辑范围。变量必须在进入节点的所有路径上可用；可选事实只用于存在性判断。条件数、表达式与输入字节预算沿原契约执行。
+
+新节点尚未填完标准成员/角色时可以保存草稿；正式发布与办理覆盖仍完整校验。服务端重新读取实际上下文，不信任浏览器自报目录或已校验标志。AI提案同样经过原binding/canvas门禁；不能把草稿可保存解释为可发布。
+
+冲突、失权或结果未知时保留整个assignment及原operationId，不自动合并分支、不静默丢失条件。已进入流程的任务仍使用原冻结快照，新的规则不回写历史任务。源码同步、配置与发布分别核对原Head/版本和操作回执。