weaver-e10-builder 1.1.9 → 1.2.3

package/skill-docs/actionflows/references/components/workflow/ApproveTrigger.md

@@ -1,84 +1,99 @@
-# 流程触发（`ApproveTrigger`）
-
-## 同一流程的多条触发规则
-
-平台的“动作执行节点/出口”窗口可为同一个流程添加多行规则；不要把它误拆成多个动作流。计划用 `triggerRules` 表达：
-
-```json
-{
-  "workflowPath": {"id":"<流程id>","name":"<流程名>"},
-  "triggerRules": [
-    {"triggerTiming":"leave","approveNode":{"id":"<发起节点id>","name":"发起节点"}},
-    {"triggerTiming":"arrive","nodeTime":"2","approveNode":{"id":"<发起节点id>","name":"发起节点"}},
-    {"triggerTiming":"workflow_completed","approveNode":{"id":"<结束节点id>","name":"结束节点"}}
-  ]
-}
-```
-
-CLI 会逐条校验真实节点/出口及其允许的执行时间，并写入同一流程的 `singleApproveConfigs[workflowId]` 数组。未传 `triggerRules` 时，才使用原来的单条 `triggerTiming` 写法。
-
-## 多时机触发不同动作时，先按触发上下文分支
-
-多条规则触发的仍是**同一张动作流画布**，因此不能把“新增 / 删除 / 更新”三个动作直接串在主链上。应在事件后的第一个节点放 `Condition`，用流程触发器实时输出的字段路由：
-
-- `triggerType`：`pre`（节点前）、`after`（节点后）、`link`（出口）等；
-- `executeTime`：例如 `2` 表示返回到达；
-- `triggerNodeOrLinkId`：实际触发的节点或出口 ID。
-
-例如“发起节点离开新增、返回到达删除、结束节点正向到达更新”写成三条互斥分支：
-
-```text
-triggerNodeOrLinkId = 发起节点 AND triggerType = after AND executeTime = 1  -> 新建
-triggerNodeOrLinkId = 发起节点 AND triggerType = pre   AND executeTime = 2  -> 删除
-triggerNodeOrLinkId = 结束节点 AND triggerType = pre   AND executeTime = 1  -> 更新
-```
-
-以上三个字段必须从当前流程触发器的 `getComponentContext` 返回结果取真实 `paramKey`，不要手写成业务表单字段。
-
-## 何时使用
-
-由流程提交、审批、结束等时机触发动作流。
-
-## 先查询
-
-查询真实流程、节点和当前时机的 `workflow-context-fields`。
-
-## 不可猜测
-
-后续动态引用只使用本次返回的 `paramKey`；多流程触发按组件契约提供真实列表。
-
-## 最小计划
-
-`workflowPath`、`triggerTiming`；节点型时机提供真实 `approveNode`，出口型时机提供真实 `approveLink`。
-
-## 触发时机
-
-plan 统一使用：`arrive`（节点前/到达）、`submitted`（流程提交）、`approve_passed`（审批通过）、`workflow_completed`（流程结束）、`leave`、`link`、`delete`、`save`、`revert`、`pause`、`cancel`。中文界面名称可输入，CLI 会归一为上述值后再查询并校验对应的真实流程节点；不能按“第一个节点”猜测时机。
-
-## 类型联动：可选节点/出口与执行时间
-
-| `triggerTiming` | 可选对象 | `nodeTime` |
-|---|---|---|
-| `submitted` | 仅发起节点（nodeType=0） | 仅正向到达（1） |
-| `approve_passed` | 审批/中间节点（1/2/5） | 不使用 |
-| `workflow_completed` | 仅结束节点（3） | 仅正向到达（1） |
-| `arrive` | 当前流程真实节点（0/1/2/3/5） | 结束节点可选 1/2/3/4/5/6；其他节点 1/2/3/4/6 |
-| `leave` | 当前流程真实节点（0/1/2/3/5） | 1/2/3/6 |
-| `link` | 仅当前流程真实出口 `approveLink` | 不使用 |
-| `pause` | 发起/审批/中间节点（0/1/2/5） | 1/2 |
-| `cancel` | 当前流程真实节点（0/1/2/3/5） | 1/2 |
-| `delete` / `save` / `revert` | 当前流程真实节点（0/1/2/3/5） | 不使用 |
-
-出口不能使用 `approveNode`，也不自动选择“第一条出口”；需求未指定出口时必须先查并追问。
-
-## 执行时间（节点前 / 节点后）
-
-节点型触发可传 `nodeTime`，其值和设计器下拉框一致：`1` 正向流转到达、`2` 返回到达、`3` 强制收回到达、`4` 撤回到达、`5` 强制结束到达、`6` 干预到达。
-
-例如，要在某节点**返回到达**时触发，使用真实节点和 `nodeTime:"2"`：
-
-```json
-{"workflowPath":{"id":"<流程ID>","name":"<流程名>"},"triggerTiming":"arrive","approveNode":{"id":"<真实节点ID>","nodeType":1},"nodeTime":"2"}
-```
-
-`revert` 是“流程还原时”，与节点执行时间中的“返回到达”不是同一事件。
+# 流程触发（`ApproveTrigger`）
+
+## 同一流程的多条触发规则
+
+平台的“动作执行节点/出口”窗口可为同一个流程添加多行规则；不要把它误拆成多个动作流。计划用 `triggerRules` 表达：
+
+```json
+{
+  "workflowPath": {"id":"<流程id>","name":"<流程名>"},
+  "triggerRules": [
+    {"triggerTiming":"leave","approveNode":{"id":"<发起节点id>","name":"发起节点"}},
+    {"triggerTiming":"arrive","nodeTime":"2","approveNode":{"id":"<发起节点id>","name":"发起节点"}},
+    {"triggerTiming":"workflow_completed","approveNode":{"id":"<结束节点id>","name":"结束节点"}}
+  ]
+}
+```
+
+CLI 会逐条校验真实节点/出口及其允许的执行时间，并写入同一流程的 `singleApproveConfigs[workflowId]` 数组。未传 `triggerRules` 时，才使用原来的单条 `triggerTiming` 写法。
+
+## 活动版本
+
+动作执行节点/出口窗口里的“活动版本”对应触发规则中 `nodeOrLinkName[0].versionId`。可在计划中传 `workflowVersionId` 指定真实版本 ID：
+
+```json
+{
+  "workflowPath": {"id":"<流程id>","name":"<流程名>"},
+  "workflowVersionId": "<流程节点浏览接口返回的真实versionId>",
+  "triggerTiming": "submitted",
+  "approveNode": {"id":"<真实发起节点id>","name":"发起节点"}
+}
+```
+
+`workflowVersionId` 只能使用流程节点浏览接口返回的真实 `versionId`，CLI 会按流程、节点和版本一起校验；不传时沿用真实 `approveNode` 携带的版本。不会猜测或生成版本 ID。出口规则同样把真实版本写入 `nodeOrLinkName[0]`。
+
+## 多时机触发不同动作时，先按触发上下文分支
+
+多条规则触发的仍是**同一张动作流画布**，因此不能把“新增 / 删除 / 更新”三个动作直接串在主链上。应在事件后的第一个节点放 `Condition`，用流程触发器实时输出的字段路由：
+
+- `triggerType`：`pre`（节点前）、`after`（节点后）、`link`（出口）等；
+- `executeTime`：例如 `2` 表示返回到达；
+- `triggerNodeOrLinkId`：实际触发的节点或出口 ID。
+
+例如“发起节点离开新增、返回到达删除、结束节点正向到达更新”写成三条互斥分支：
+
+```text
+triggerNodeOrLinkId = 发起节点 AND triggerType = after AND executeTime = 1  -> 新建
+triggerNodeOrLinkId = 发起节点 AND triggerType = pre   AND executeTime = 2  -> 删除
+triggerNodeOrLinkId = 结束节点 AND triggerType = pre   AND executeTime = 1  -> 更新
+```
+
+以上三个字段必须从当前流程触发器的 `getComponentContext` 返回结果取真实 `paramKey`，不要手写成业务表单字段。
+
+## 何时使用
+
+由流程提交、审批、结束等时机触发动作流。
+
+## 先查询
+
+查询真实流程、节点和当前时机的 `workflow-context-fields`。
+
+## 不可猜测
+
+后续动态引用只使用本次返回的 `paramKey`；多流程触发按组件契约提供真实列表。
+
+## 最小计划
+
+`workflowPath`、`triggerTiming`；节点型时机提供真实 `approveNode`，出口型时机提供真实 `approveLink`。
+
+## 触发时机
+
+plan 统一使用：`arrive`（节点前/到达）、`submitted`（流程提交）、`approve_passed`（审批通过）、`workflow_completed`（流程结束）、`leave`、`link`、`delete`、`save`、`revert`、`pause`、`cancel`。中文界面名称可输入，CLI 会归一为上述值后再查询并校验对应的真实流程节点；不能按“第一个节点”猜测时机。
+
+## 类型联动：可选节点/出口与执行时间
+
+| `triggerTiming` | 可选对象 | `nodeTime` |
+|---|---|---|
+| `submitted` | 仅发起节点（nodeType=0） | 仅正向到达（1） |
+| `approve_passed` | 审批/中间节点（1/2/5） | 不使用 |
+| `workflow_completed` | 仅结束节点（3） | 仅正向到达（1） |
+| `arrive` | 当前流程真实节点（0/1/2/3/5） | 结束节点可选 1/2/3/4/5/6；其他节点 1/2/3/4/6 |
+| `leave` | 当前流程真实节点（0/1/2/3/5） | 1/2/3/6 |
+| `link` | 仅当前流程真实出口 `approveLink` | 不使用 |
+| `pause` | 发起/审批/中间节点（0/1/2/5） | 1/2 |
+| `cancel` | 当前流程真实节点（0/1/2/3/5） | 1/2 |
+| `delete` / `save` / `revert` | 当前流程真实节点（0/1/2/3/5） | 不使用 |
+
+出口不能使用 `approveNode`，也不自动选择“第一条出口”；需求未指定出口时必须先查并追问。
+
+## 执行时间（节点前 / 节点后）
+
+节点型触发可传 `nodeTime`，其值和设计器下拉框一致：`1` 正向流转到达、`2` 返回到达、`3` 强制收回到达、`4` 撤回到达、`5` 强制结束到达、`6` 干预到达。
+
+例如，要在某节点**返回到达**时触发，使用真实节点和 `nodeTime:"2"`：
+
+```json
+{"workflowPath":{"id":"<流程ID>","name":"<流程名>"},"triggerTiming":"arrive","approveNode":{"id":"<真实节点ID>","nodeType":1},"nodeTime":"2"}
+```
+
+`revert` 是“流程还原时”，与节点执行时间中的“返回到达”不是同一事件。

package/skill-docs/actionflows/references/dynamic_capability_matrix.md

@@ -0,0 +1,39 @@
+# 动作流组件属性级动态赋值矩阵
+
+这份矩阵约束 Skill 的决策方式：**是否支持动态赋值取决于具体组件的具体属性**，不是取决于属性名里是否出现 Browser。矩阵只记录已经在 CLI 编译器和测试中接通的能力；平台新版本新增能力时，先补组件契约、编译器和测试，再把状态改为“已接通”。
+
+## 已接通
+
+| 属性类型 | 代表组件/属性 | 支持的动态来源 | 编译结果 |
+| --- | --- | --- | --- |
+| 普通字段赋值 | `ActionEbAdd`、`ActionEbUpdate`（含密级、密级有效期）、`HrmEmployeeUpdate.fieldAssignments`、`PersonnelOnboarding.fieldAssignments` | 上下文、循环当前行、系统变量、变量、常量、函数/公式 | 按目标字段类型生成 `type=3/5/6/7/8/9/10` 等 FormulaBean |
+| 查询结果字段 | `EnquiryForm` 输出被后续动作引用 | 查询结果字段、第一条记录 `index:0`、函数参数 | 使用查询节点真实 `source`、字段真实 ID 和平台结果字段对象 |
+| 查询分页与动态条件 | `EnquiryForm.formPageNo`、`formPageSize`、`conditionFormula` | 固定值、上下文、系统变量、变量、常量、函数/公式 | 页码/条数为 FormulaBean；动态条件使用 `conditionType:"assign"`，不能和普通 `filter` 并存 |
+| HTTP 请求参数 | `Http.inputParams.formulaData` | 固定值、上下文、系统变量、变量、常量、函数/公式 | 写入接口详情对应参数行的 FormulaBean，不改写接口参数定义 |
+| MQ 发送参数 | `InnerMQSend.queueName`、`inputParams` | 固定值、上下文、系统变量、变量、常量、查询结果、函数/公式 | 保留原生 `sendParams` 参数定义，只向命中的参数行写入 `formulaData` |
+| DML SQL 参数 | `DMLExecute.fieldSet.assign` | 固定值、上下文、系统变量、变量、常量、查询结果、函数/公式 | 按 SQL 占位符生成 FormulaBean 数组，同时保留原生 FormulaBean 兼容入口 |
+| 消息模板 | `SendMessage.title/content.parts` | 上下文、系统变量、变量、常量 | 消息正文占位符与独立绑定；接收人上下文也保留为动态人员 FormulaBean |
+| 消息接收人 | `SendMessage.receiver` | 当前用户、上游人员上下文、固定人员 | 动态人员使用真实上下文 `paramKey`，固定人员使用当前租户 Browser 对象 |
+| 人员参数 | 表单数据动作、流程动作、文档动作、`HrmEmployeeUpdate`、`PersonnelOnboarding`、`AlterPersonStatus`、会议/日程中的人员属性 | 当前用户、上游人员上下文、动作流变量/常量/函数 | 不再强制走固定人员查询；动态引用保持人员 FormulaBean，固定人员仍要求真实 Browser 对象 |
+| 会议和日程运行时字段 | `MeetingCreate` 的标题/密级/人员，`ScheduleCreate` 的标题/时间/内容/其他地点/人员 | 上下文、系统变量、变量、常量、函数/公式 | 普通字段生成对应 FormulaBean；人员使用人员 FormulaBean；会议室、日程类型、关联流程等设计期资源仍保持 Browser 对象 |
+| 流程和文档运行时字段 | 流程实例 ID、标题、意见、公文正文 ID、关联数据 ID、时间、文档/附件 ID、布尔开关等 `formula_or_reference` 属性 | 固定值、上下文、系统变量、变量、常量、查询结果、函数/公式 | 统一经共享公式编译器生成 FormulaBean；固定流程定义、节点、目录 DTO 不在此列 |
+| 循环参数 | `MultipleExecution.cycleTimes`、列表/明细来源 | 上下文、变量、常量、当前循环上下文 | 按循环模式生成对应 `CycleParams`/FormulaBean |
+| 条件右值 | `Condition` | 固定值、上下文、系统变量、变量、常量、函数 | 右值保留为公式树，不把动态字段名转成固定字符串 |
+| 终止节点动态输出 | `finalOutput.params.reminderMsgFormula`、`basisValue` | 固定值、上下文、系统变量、变量、常量、查询结果、函数/公式 | 自动补充的 `Output` 节点保留高级设置，无需在 `actions` 中手写终止节点 |
+
+## 需要按组件协议单独判定
+
+以下不是“永远不支持动态”，而是平台 DTO 对资源对象有额外约束，不能使用普通字段公式规则直接套用：
+
+- 流程定义/流程节点/退回节点/干预节点：通常需要当前租户真实流程 Browser 对象或节点对象；只有 `requestId`、标题、意见等字段类属性按组件契约支持动态。
+- 文档、目录、附件、共享权限、按钮、规则：固定对象需要当前租户真实 Browser/权限对象；如果组件说明或回读结构提供动态公式入口，必须单独实现该属性的编译器和回读校验。
+- 会议、日程、HRM 选择器的结构化对象：人员属性与会议/日程资源属性分开判断。`MeetingCreate.flag`、日程类型、会议室和 `Output.jumpUrl` 均只接受前端允许的固定选择/固定文本，不能因为底层存储字段是 FormulaBean 就推导其支持动态。
+- 触发器配置、接口定义、连接器/资源/接口选择：这些是设计期平台资源，默认必须实时发现真实对象，不能把运行时上下文当成连接器或接口定义。
+
+## 处理规则
+
+1. 先执行 `component-describe <type>`，读取该属性的 `valueType`、`referenceType`、`valueShape`、`propertySources` 和运行时上下文。
+2. 若属性是字段值、人员值或公式值，优先调用共享公式编译器；不得在组件内部另写“只接受固定值”的分支。
+3. 若属性是平台资源对象，必须查看该组件前端回读/保存 DTO 是否有动态入口；没有证据就保留固定对象约束，并明确指出是平台协议限制，而不是 Skill 偷懒。
+4. 每新增一个动态属性，至少增加一个上下文用例和一个固定值回归用例；涉及数组/循环时再增加数组或当前循环用例。
+5. 生成成功不等于动态赋值正确：正式回读必须确认参数仍为对应 FormulaBean，来源 `paramKey`、`source/frontId`、变量/常量 ID 和循环作用域没有丢失。

package/skill-docs/references/common/guide-plan-template.md

@@ -11,6 +11,8 @@
 4. 用户确认后逐项执行，每做完一项、验证通过，改 `[x]` 并填 ID——完成一条打勾一条
 5. **执行每项前，先按 SKILL.md 决策树读对应 `references` 指南**——命令的完整参数/边界/坑/示例都在指南里，认真阅读再动手，不要凭印象直接调命令
 
+流程明确使用权责表时，在对应流程下列明搭建方式、新建或复用的权责表、变量与字段映射，以及各分支的场景说明、条件、经过节点和顺序；详细配置读取 `references/workflow/guide-workflow-auth-resp.md`。
+
 ---
 
 ## plan.md 骨架
@@ -39,6 +41,7 @@
 
 ##### 3.1 字段定义（按[新建 EBuilder 表单](../form/guide-create-form.md)整理，建表时通过 `form create --fields` 一次创建）
 - [ ] <表单名> | ID: 待创建
+  类型: 普通 EB 表单 / 虚拟表（虚拟表按[虚拟表创建与维护](../form/guide-virtual-form.md)记录来源和字段映射）
   布局: FLOW（流式）/ EXCEL（表格，缺省）
   字段:
     1. 名称(Text, 必填)
@@ -55,8 +58,15 @@
   - **字段多语言**：需求写成 `中文/English` 时，字段清单保留两种名称并注明“多语言”；创建时字段名只用中文，建成取得 fieldId 后执行 `form field-lang set --zh <中文> --en <English>`，不可把斜杠名称原样落库
   - 公式/值带出可 inline：`formula` / `relateFrom`
   - **Flow 字段**：`sformId` 是流程表单 objId（不是 workflowId），建表时写进 fields.json 即自动绑定——关联到哪个流程表单就只能选该范围的流程数据，无需单独配数据范围
+  - **二级明细**：逐条列出“父明细 → 子明细”、父级行标识、子级文本行标识和是否默认展开；执行时先读取父明细的可选子明细，再按[二级明细表配置](../form/guide-form-sub-detail.md)创建并回读。
   > 不要先建空表再 add-field——add-field/edit-field 只是**罕见补救手段**
 
+虚拟表补充清单（普通 EB 表单删除本段）：
+- [ ] 数据源定位 | 来源类别: EB 表单 / 系统业务表 / 数据加工 | 名称/ID: <来源>
+- [ ] 数据源预检 | 稳定 ID 校验通过
+- [ ] 字段映射 | <来源字段(dataKey/sourceFieldType)> → <虚拟表字段及兼容展示类型>
+- [ ] 虚拟表创建 | `form virtual create` | objId/formId: 待回填
+
 ##### 3.1.1 表单布局蓝图（按[表单布局规划](../form/guide-form-layout-planning.md)识别；需求提供完整布局样表时必填，否则标“— 未提供，使用默认布局”）
 - [ ] 布局类型：EXCEL / FLOW
 - [ ] 来源：<需求文档章节或表格标题>
@@ -136,6 +146,16 @@
 - [ ] 节点3 | 条件: <字段>=<值> 才走到，否则跳过/直达<节点>
 - [ ] 节点4 | 操作者: 角色X ｜ 动作流: → <目标表>(add/update/delete, 映射: 源→目标)
 - [ ] 连线 | `workflow add-link/add-links <wf> <from> <to> <label>` [--reject 退回] [--default 默认]
+- [ ] 结构改完补排版 | `workflow auto-layout <wf>`（**加/删节点、加/删连线之后必跑**；建流程时自动跑过的那一次不算）
+
+###### 权责表设计（搭建方式为权责表时填写，替代普通节点与连线清单）
+- [ ] 权责表来源 | 流程内新建 / 复用已有 | 权责表：<名称> | authRespId：待回填
+- [ ] 首尾设置 | 发起：<类型及操作者> | 结束：<类型及操作者>
+- [ ] 中间节点 | <节点名称、类型、操作者>
+- [ ] 分支路径 | <场景说明> | 条件：<条件> | 路径：<节点及顺序>
+- [ ] 嵌套权责表 | <适用分支> | 引用：<权责表及版本> | 顺序：<序号>
+- [ ] 变量映射 | <权责表变量> → <当前流程表单字段> / 无需映射
+> 权责表方式流程的节点、分支条件和流转路径统一在权责表设计中维护；复用独立权责表时逐项列出变量映射。
 
 ##### 4.3 出口条件清单（来源: 本流程 <流程名A>；必填，动手前逐条列出，防遗漏）
 段② 执行到条件时，先按此表列出所有连线的完整条件，逐条确认后再 `workflow condition add`：
@@ -203,12 +223,13 @@
 以确认后的 `plan.md` 为执行清单，按资源依赖顺序逐项读取相关指南并完成配置；完成并核验一项，就立即勾选对应项并回填实际 ID 或结果。每段结束前检查本段应完成项是否全部销号，依赖后续资源的项目保留 `[ ]` 并注明依赖，不得提前勾选。
 
 - **段①：应用、角色、表单与视图。** 完成应用、角色、全部表单和表单布局，并配齐字段属性、关联、公式、联动、校验、权限、默认台账、新增视图、显示列、搜索排序、筛选统计、分组、上下级、按钮和关联页签等表单及视图相关配置。依赖流程 ID 的配置在 plan 中列明，待段②创建流程后回填。
-- **段②：流程与自动化。** 完成流程创建、节点连线、操作者、出口条件、节点配置、流程级设置、矩阵和动作流，并回填段①中依赖流程 ID 的表单字段、表单按钮和视图按钮。完成后确认流程结构及关键条件。
+- **段②：流程与自动化。** 完成流程创建、节点连线、操作者、出口条件、节点配置、流程级设置、矩阵和动作流，并回填段①中依赖流程 ID 的表单字段、表单按钮和视图按钮。完成后**补跑一次 `workflow auto-layout`**，再确认流程结构及关键条件。
 - **段③：菜单与页面。** 完成台账、流程发起和自定义菜单，配置菜单权限，并按需求创建配置式页面或定制页面，绑定真实资源 ID 后完成保存、发布和整体收尾。
 - 简单单步需求（改字段、查数据）不分段，直接执行
 > **表单是流程的地基**：流程绑定表单、条件/动作流/操作者都引用字段，字段设计错了流程全返工——表单段必须确认后再进流程
 
 ## 规则备忘
+- **改完流程结构要补排版**：`workflow auto-layout <wf>` 只在 `create`/`create-workflow` 建流程时自动跑过一次，**之后一律不会顺带重跑**（add-node/add-link/delete-node/delete-link 都不跑）。所以 4.2 的最后一项别省 —— 加完分支线不补，图上就留着交叉。两个边界：① 它是**整图重排**，人在浏览器里拖过的坐标会被覆盖；② **不保证消除交叉**，跨层连线仍可能穿过中间层节点，跑完看一眼流程图，有交叉手工调。
 - **执行前读指南**：每个命令的完整参数/边界/示例在对应 `references` 文档（SKILL.md 决策树按关键词路由），动手前先读，勿凭印象调命令出错
 - Plan 阶段不调 e10-cli 写命令（可 list/read 查现状）；必须写 plan.md 落地，不要只在对话里列方案
 - 应用数量：默认全需求只建 1 个应用，不按功能点拆；确需多应用先跟用户确认