weaver-work-cli 0.1.24 → 0.1.25

package/skills/weaver-e10-builder/references/workflow/guide-opinion-settings.md

@@ -0,0 +1,126 @@
+# 拟签意见、节点转发与节点签字意见
+
+本地开发使用 `node dist/index.js` 替换下文的 `e10-cli`。先运行 `npm run build`，使用目标测试环境的已有登录态；不需要打包或重新全局安装。所有长 ID 都使用字符串。
+
+三个命令都先读取服务端现有值或默认值，再合并 `--data` 中明确指定的项，保存一次后回读核对。未指定项保留；未知字段、无效枚举、未匹配名称提前报错。`--data` 支持 JSON 或 `@文件`，`--out` 保存不含认证信息的结果。`create` 对单份配置表示初始化/保存，不新增第二份同类配置。
+
+## 拟签意见：workflow draft-opinion
+
+```bash
+# 流程展现设置及环境支持的选项
+e10-cli workflow draft-opinion get <workflowId> --schema
+# 查询布局中已保存的拟签控件，取得 widgetId（不是普通字段ID）
+e10-cli workflow draft-opinion fields <workflowId>
+e10-cli workflow draft-opinion get <workflowId> --widget-id <widgetId> --schema
+# 修改控件的意见显示方式
+e10-cli workflow draft-opinion update <workflowId> --widget-id <widgetId> \
+  --data '{"typeAfSign":"显示全部意见"}'
+# 开启流程自定义展现，弹窗填写，正序显示
+e10-cli workflow draft-opinion update <workflowId> \
+  --data '{"openCustomSet":true,"pcFillMethod":"弹窗填写","opinionOrder":"正序"}'
+```
+
+流程展现参数（枚举支持 ID 或服务端完整中文名称，以 `get --schema` 为准）：
+
+| 参数 | 含义 |
+|---|---|
+| openCustomSet | 启用本流程自定义展现；关闭时读取应用级默认设置 |
+| openTextarea | 是否使用纯文本意见输入框 |
+| defautFont / defaultFontSize | 意见默认字体/字号；defautFont 是接口原拼写 |
+| showBlank / openSearch | 显示空的意见/启用意见搜索 |
+| opinionOrder | 0正序、1倒序 |
+| showLog | 显示操作日志 |
+| pcFillMethod | 1弹窗填写、2直接填写 |
+| alertEndCountersign | 提交流程时弹出结束拟签提示 |
+
+控件参数：
+
+| 参数 | 含义 |
+|---|---|
+| opinionType | 0多人编辑同一条意见、1一个人一条意见 |
+| enableCountersign | 启用组织意见拟签；开启前需已有结束拟签操作者或节点配置 |
+| conterSignType | 拟签组织维度，按环境 schema 选择（接口原拼写） |
+| typeBfSignDepart / typeBfSignSubcom | 结束拟签前的查看方式；按当前部门/分部维度使用对应参数，两项对应同一存储字段 |
+| typeAfSign | 意见展示方式，例如显示最后一次意见/显示全部意见，以 schema 为准 |
+| enableCopyClear / copyClearOperate / copyClearNode | 启用抄清、抄清操作者模式、节点名称或字符串 ID 数组 |
+| enableGenerateRecord / agentRecordOperate / agentRecordNode | 启用代录、代录操作者模式、节点名称或字符串 ID 数组 |
+
+既有的结束拟签操作者、抄清/代录人员范围引用会保留。选择节点操作者时，必须已有对应节点及人员范围。组织拟签结束人员、抄清/代录范围子弹窗的新增尚未接入此命令。切换“多人编辑同一条意见”不会悄悄关闭抄清/代录，须显式关闭后二次设置。
+
+本命令配置**已存在并保存的拟签控件**，不向节点布局自动插入新控件。尚无控件时先在布局设计器添加并保存，再执行 `fields` 查询。
+
+### 显示内容与按钮样式
+
+```bash
+e10-cli workflow draft-opinion content get <workflowId>
+e10-cli workflow draft-opinion content update <workflowId> \
+  --data '{"displayContent":"<p>$f_opinionContent$</p>"}'
+e10-cli workflow draft-opinion style get <workflowId>
+e10-cli workflow draft-opinion style update <workflowId> \
+  --data '{"fontSize":"14","buttons":[{"menuKey":"fill","customName":"填写拟签","menuColor":"#336699"}]}'
+```
+
+`content` 的 `displayContent` 是 HTML 模板，不是对运行中流程填写意见；可用占位符由 `content get` 返回。CLI 负责 URL 编码。模板/样式首次保存前会读取主配置以完成服务端初始化。
+
+`style` 可写 `menuFont`、`fontSize`、`buttons`。每个按钮以 `menuKey` 定位，可改 `customName`、`menuColor`、`menuFontColor`、`menuBorderColor`、`menuOrderNum`。未指定按钮和属性保留，调序不得重复。`fill` 为填写意见，其他 key 以查询结果为准。
+
+模板和按钮样式的保存不隐式开启 `openCustomSet`，需要采用流程自定义展现时明确开启。`fieldSet/displayContent/menuStyle/logviewer` 在流程配置中只是齿轮状态，不能当开关写入。日志查看人员权限、应用全局设置不在本命令范围内。
+
+## 节点转发：workflow node forward-setting
+
+```bash
+e10-cli workflow node forward-setting get <workflowId> <nodeId>
+e10-cli workflow node forward-setting update <workflowId> <nodeId> \
+  --data '{"todo":{"isForward":true,"allowSubOpt":false},"done":{"isForward":true,"allowSubOpt":true}}'
+```
+
+顶层三组：`todo` 待办、`done` 已办、`end` 结束。每组支持：
+
+| 参数 | 含义 |
+|---|---|
+| isForward | 是否允许转发 |
+| allowSubOpt | 转发接收人是否可提交意见 |
+| allowForward | 转发接收人是否可继续转发 |
+| allowSubOptCusName | “可提交意见”自定义名称，空串恢复默认名称 |
+| allowForwardCusName | “可转发”自定义名称，空串恢复默认名称 |
+
+开关用 true/false 或 0/1。开启转发时不会顺便重置未指定的接收人权限。这个命令与 `forward-circulate-back`（收回设置）不同。节点转发菜单的启用仍用 `workflow node menu`；本命令不修改接收人范围，不执行“保存并同步”。
+
+## 节点签字意见：workflow node sign
+
+原命令及 `--all-required`、`--none-required`、`--select` 保留。
+
+```bash
+e10-cli workflow node sign <workflowId> <nodeId> --schema
+e10-cli workflow node sign <workflowId> <nodeId> --options viewTypeDto
+e10-cli workflow node sign <workflowId> <nodeId> --options signOperateTypeList
+e10-cli workflow node sign <workflowId> <nodeId> --select '退回,加签'
+e10-cli workflow node sign <workflowId> <nodeId> \
+  --data '{"hideInput":true,"viewTypeSelectDto":"1","viewTypeDto":["批准/确认","拟签意见"],"viewEmptyNotShow":true,"signOperateTypeSelect":"1","signOperateTypeList":["批准/确认"]}'
+```
+
+| 参数 | 含义 |
+|---|---|
+| mustInputDto | 0全部不必填、1全部必填、2按操作类型 |
+| inputOperateTypeSelectDto + inputOperateTypeDto | 意见必填操作类型的模式与列表 |
+| hideInput | 意见输入框不显示（只对不必填的操作生效） |
+| signOperateTypeSelect + signOperateTypeList | 必须使用签批或签名的操作类型 |
+| hideArea | 意见及评论区域不显示 |
+| viewTypeSelectDto + viewTypeDto | 意见列表显示类型 |
+| viewEmptyNotShow | 空意见不显示 |
+| viewRangeSelectDto + viewRangeDto | 意见显示节点范围 |
+| notSeeEachOther | 当前节点操作者不可互相查看意见 |
+| feedback / nullNotFeedback | 意见反馈/意见为空时不反馈 |
+
+四个 Select 模式字段均为 `0全部/1选择/2排除`（以当前 schema 为准）；列表传完整名称或字符串 ID 数组。完整候选通过 `--options <对应列表字段>` 获取，会保留节点类型等过滤条件。部分名称命中失败会整体拒绝，不静默丢失。
+
+`signOperateTypeSelect=1` 且 `signOperateTypeList=[]` 表示不指定必须签批的操作。全部节点模式须同时显式清空已有节点列表。全部操作意见必填与隐藏输入框冲突时，须显式设置 `hideInput:false`。不修改其他节点，不执行同步。
+
+## 自然语言测试话术
+
+- “使用 107 测试环境，查询流程【ID】已有拟签字段，把【控件ID】改为显示全部意见，其他保持原样，保存后回读。”
+- “流程【ID】开启拟签自定义展现，填写方式改为弹窗、意见正序排列；不要改字体、模板和按钮。”
+- “流程【ID】节点【ID】，待办允许转发但接收人不能提交意见；已办允许转发且可提交意见，结束流程设置保持不变。”
+- “流程【ID】节点【ID】，签字意见只展示批准和拟签意见、隐藏空意见，批准时必须使用签批或签名，其余配置不变。”
+
+执行前先查询真实 workflowId/nodeId/widgetId、环境枚举和操作候选；自然语言由 AI 映射为上面的 CLI 参数。验证完成应区分配置回读通过和前台运行行为通过。

package/skills/weaver-e10-builder/references/workflow/guide-workflow-action.md

@@ -0,0 +1,174 @@
+# 流程动作流指南
+
+> 流程基础（建流程、节点、连线、审批人）见 `workflow/guide-workflow.md`，分支条件见 `workflow/guide-workflow-condition.md`。本指南专讲**节点提交事件**和**跨表单动作流**（本表数据 → 目标表 新增/更新/删除 记录）。
+>
+> **动作流新建走 `e10-cli actionflow generate`，已有动作流修改走 `e10-cli actionflow update`**。新建是语义 plan → 编译 → preflight → 保存并启用 → 正式回读；修改是精确 appId → 读取正式设计 → 备份 → 按原 ID 保留式修改 → `saveDesign` → 正式回读。`ApproveTrigger` 自带流程节点触发绑定，不走 pathdef/addaction。详见 `actionflows/SKILL.md` + `e10-cli actionflow component-describe <type>`。`e10-cli workflow action` 仅作动作流**管理**（`list-node`/`clear-node` 查清节点绑定、`delete`/`disable`/`batch-delete` 禁用删除动作流 app）。
+
+## 节点提交事件（字段更新）
+
+节点提交/到达时自动更新本表单字段值（actionType=0），如「审批状态置为审批中」。
+
+> CLI 接受简化 JSON，内部自动构造 `saveAddActionList` 正确 payload（`targetValue`/`firstValue:"custom"`/`customValue`/`actionType:0`/`triggerType:"pre"` 等）。也支持直接传完整 `data:[]` 结构（高级用法）——**传入的 `data:[]` 行会自动归一化**，把 `action list-node` 的读回结果原样回传是安全的。
+>
+> **合并语义**：写入前先读回节点已有动作并归一化，再追加新动作写回——不覆盖已有动作。可与节点上的 type2 动作流安全混用同一节点。若节点已被写坏（读动作恒 500），CLI 会明确提示用 `delete-node` 删节点重建（API 无法修复）。
+>
+> **fieldId 会校验**：简化 JSON 的 `fieldId` 必须是流程表单里真实存在的字段，CLI 写入前反查表单字段校验，无效会报错并列出可用字段。**切勿用占位 fieldId**（如 `"1"`）——无效 fieldId 会被服务端存成空字段映射，之后任何合并写回都会把节点写坏（读恒 500，只能 delete-node 重建）。
+
+**命令**：
+```bash
+e10-cli workflow save-action @action.json
+```
+> **只接 JSON 一个参数**：`workflowId` / `nodeId` 写在 JSON 内部，不是位置参数。写成 `save-action <wf> <node> @file` 会报错。
+
+### action.json 格式（常量赋值）
+
+```json
+{
+  "workflowId": "1296243932023734272",
+  "nodeId":     "1296243932023734278",
+  "nodeName":   "上级审批",
+  "fieldId":    "1296243579896791071",
+  "fieldName":  "审批状态",
+  "value":      "1296243644242280449"
+}
+```
+
+| 字段 | 必填 | 说明 |
+|------|------|------|
+| workflowId | 是 | 流程 ID |
+| nodeId | 是 | 节点 ID（即 `objId`） |
+| nodeName | 否 | 节点显示名（默认"节点"） |
+| fieldId | 是 | 要更新的目标字段 fieldId |
+| fieldName | 否 | 字段显示名（用于 `actionName` 展示） |
+| value | 是 | 常量值。Text/Number 字段用实际值；Select 用 option 的 valueKey |
+| trigger | 否 | 触发时机，默认 `"pre"`（到达节点时）；`leave` 离开 / `back-arrive` 退回到达 |
+
+---
+
+## 跨表单动作流（本表数据 → 目标表 新增/更新/删除 记录）
+
+跨表单动作流的**生成**统一走 `e10-cli actionflow generate`：写一份语义 plan（`event` + `actions`），CLI 编译、preflight、保存并启用、正式回读，返回设计器链接。组件参数、映射、条件的权威是 `e10-cli actionflow component-describe <type>`，参考 `actionflows/references/components/` 下对应组件 md。下面是平台机制要点，写 plan 时按此组织。
+
+除 e-builder/流程数据动作外，动作流还支持 HTTP/HTTPS 接口调用、DML 数仓 SQL/存储过程、自定义事件、内置 MQ 监听/发送、消息、文档、人员、会议和日程等组件。HTTP 必须先按“连接器 → 连接信息 → 接口 → 接口详情”读取当前环境对象；请求参数通过接口详情真实 `table`/`paramKey` 配置 `inputParams`，不要猜测或重建 `request.tables`。DML 的数据源连接必须先用 `e10-cli actionflow datasource-list` 查询，SQL 占位符与 `fieldSet` 必须一致；详细约束分别见 `actionflows/references/components/http/Http.md` 和 `actionflows/references/components/database/DMLExecute.md`。
+
+已有动作流的局部变更不要重新生成新应用；先用 `read-design --out` 保存正式设计，再按 `actionflows/SKILL.md` 的 `update` 计划格式提交显式 `operations`。更新器会自动备份原设计并保留未声明内容，不能按名称选择目标，也不会在保存/回读失败时自动回滚或删除目标。更新计划中的节点 ID 必须来自这次正式回读；保存新版时平台可能重分配动作/出口节点 ID，CLI 会按新版版本列表定位新场景并按动作树结构回读校验，不能把新 ID 变化误判为失败。更新时触发器 `event` 必须保持原样，不能修改触发类型、触发表单、触发时机或其他触发器参数；如果需求要变更触发器，必须改为新建动作流，CLI 会在检查/保存前明确拒绝。正常更新通过后调用 `saveDesign` 时固定使用 `saveNewVersion:true`，保存为该动作流的新版本。
+
+### 平台机制要点
+
+**目标表字段映射**：plan 的 `mapping` 是 `{源字段 paramKey: 目标字段 ID}`。目标字段 ID 支持 `+`/`-` 前缀做加减运算（赋值不加前缀、`+`累加、`-`扣减）。源字段用本次 `actionflow workflow-context-fields` 返回的原始 `paramKey`，不写死 `FormData.*`/`ApprovalData.*` 路径（编译器自动判定）。
+
+**明细表映射（明细→明细）**：`ActionEbAdd` 的 `insert`/`batchInsert` 支持源明细表逐行写入目标明细表。同一目标明细表的映射须来自同一张源明细表（作为该表「依据值」basisValue）。明细目标字段不支持 `+`/`-` 前缀。**明细 update/delete**（含 basisValue/rowId 行匹配/updateAdd、requestId 定位）走 `ActionEbUpdate`/`ActionEbDelete` 契约的 `filterCondition`（动态右值引用 requestId），`component-describe ActionEbUpdate` 看 detail + requestId 定位参数。
+
+**更新定位方式**：`ActionEbUpdate` 的 `opType`：`id`（按数据ID更新，配 EBuilder 关联字段其值=目标记录数据ID）/ `updateData`+`filterInput`（按「目标字段=源字段值」匹配，推荐）/ `fieldUpdate`（按字段匹配，保存后右侧条件会被清空，不可用）。匹配字段不要选 `*_name`/「名称」显示字段（标签文本非真值）。
+
+**常量值**：plan 里目标字段可用固定值（constants）而非映射字段；公式计算（加减乘除多字段）用 `formula`。mapping/constants/formula 可混合。详见 `component-describe ActionEbAdd/ActionEbUpdate`。
+
+---
+
+## 流程数据写入台账（数据来源落点）
+
+**场景**：流程发起时写入目标台账、归档/退回时更新/删除台账记录（如"流程数据写入项目台账"，发起写入、归档更新、退回删除）。
+
+**核心前提：目标台账必须建「数据来源」Flow 字段**（浏览-流程，`--sform-id` 指向流程绑定的表单 objId）。它存的是**流程实例 ID（requestId）**——add 时写入它，update/delete 靠它定位是哪次流程创建的记录，点击还能跳回流程。
+
+```bash
+# 台账建「数据来源」Flow 字段（只读，来源=项目立项流程）
+e10-cli form add-field <台账objId> <appId> "数据来源" Flow --sform-id <流程表单objId>
+```
+
+**① add（发起写入）**：plan 里把流程实例 ID（requestId 系统变量）写进台账「数据来源」字段，其余字段按 mapping 映射。
+
+**② update/delete（归档更新/退回删除）**：定位条件"**台账.数据来源 = 当前流程 requestId**"。`filterCondition` 动态右值引用 requestId，编译器自动判定为 `ApprovalData` 流程数据——`paramKey` 必须用本次 `actionflow workflow-context-fields` 返回的原始键，不要写死路径。示例 plan 结构：
+
+```json
+{
+  "event": {"type":"ApproveTrigger","params":{"workflowPath":{"id":"<流程id>"},"triggerTiming":"workflow_completed"}},
+  "actions":[
+    {"type":"ActionEbUpdate","params":{
+      "targetForm":{"groupId":"<appId>","id":"<台账objId>"},
+      "person":{"id":"<人员id>","name":"<姓名>"},
+      "opType":"updateData",
+      "filterCondition":{"field":{"id":"<台账数据来源字段ID>","label":"<数据来源字段名>"},"operator":"eq","right":{"type":"context","paramKey":"<workflow-context-fields 返回的流程ID paramKey>","label":"流程ID"}},
+      "mapping":{"<源paramKey>":"<目标字段ID>"}
+    }}
+  ]
+}
+```
+
+> `filterCondition` 格式**以 `actionflows/references/condition_rules.md` 为准**：`field` 必须为 `{id,label}` 对象、`operator` 用英文操作符（`eq/neq/gt/lt/gte/lte/contains/uncontains/empty/nempty`，`empty/nempty` 无右值）、右值键必须为 `right`。`value` 别名、`=`、裸字符串 `field`、数组根节点和 `relationship:"1|0"` 都会在编译前被拒绝。需求含条件/筛选时先翻 condition_rules.md 再下笔。
+
+> **关联流程左值特别注意**：不要因为字段 ID 是数字就套用普通 e-builder 的 `field_<id>`。`Workflow` 必须使用原始数字 `fieldName`、`fieldType:"String"`、空 `module`/`originBrowserType`，`formInfo.formId/layoutId`，顶层 `sformId` 和仅含 `fieldId` 的 `config`；`sformId` 从 `workflowPath.formIds` 反查流程表单对象，不能用目标表单版本 ID代替。
+
+> 也可直接给 `actionflow generate` 下自然语言 plan（"流程归档时按数据来源更新台账，项目状态置为立项"），由组件契约承载。`generate` 默认保存并启用设计（saveDesign saveAndStart=true，正式生效），返回 appId + 设计器链接，event 节点已含流程节点触发绑定。仅 `mode:"stash"` 时走暂存（需设计器手动发布）。
+
+**③ add 回写 dataId（源表存台账记录 ID）**：若后续 update/delete 想用"源表字段 = 台账 dataId"定位，`actionflow workflow-context-fields` 提供"回写数据ID对应字段"候选查询。
+
+---
+
+## 关联 EBuilder 更新目标表数据（跨表更新）
+
+**场景**：表A（带流程）通过 EBuilder 关联字段指向表B，流程到节点时动作流更新表B的目标记录字段。
+
+**机制**：表A 的 EBuilder 关联字段的值 = 表B 记录的数据ID。plan 里 `ActionEbUpdate` 的 `opType=id`（按数据ID更新）+ `filterCondition` 用表A的 EBuilder 关联字段 → 直接用关联值定位表B记录，无需字段值匹配。
+
+### 建两张表
+
+表B「客户台账表」（被更新）：客户名称(Text)、最后拜访日期(Date)、累计拜访金额(Money)
+```json
+[
+  {"componentKey":"Text","fieldName":"客户名称"},
+  {"componentKey":"Date","fieldName":"最后拜访日期"},
+  {"componentKey":"Money","fieldName":"累计拜访金额"}
+]
+```
+
+表A「拜访登记表」（带流程）：拜访日期(Date)、拜访金额(Money)、客户关联(EBuilder→表B)
+```json
+[
+  {"componentKey":"Date","fieldName":"拜访日期"},
+  {"componentKey":"Money","fieldName":"拜访金额"},
+  {"componentKey":"EBuilder","fieldName":"客户关联","sformId":"<表B objId>","dataTitle":"客户名称"}
+]
+```
+> EBuilder 字段：`sformId`=目标表 objId，`dataTitle`=目标表显示字段（填字段名或 fieldId，CLI 自动解析）。
+
+写 plan 时 mapping 目标ID 不加前缀=**直接赋值**（源值原样写入）；加 `+`=累加，`-`=扣减。直接赋值时按目标字段类型（日期/金额/文本等）自动匹配。
+
+---
+
+## 条件性动作流（同一节点按条件走不同动作）
+
+一个节点可挂**多个动作流，各自带触发条件**——提交时只有条件命中的动作才执行。典型场景「合同变更」：变更类型=续期 → 插入台账；变更/终止 → 更新+插入。
+
+在 plan 里用 `Condition` 组件（逻辑分支）表达条件，或多个 `ActionEb*` 配 `filterCondition`。条件规则语法见 `actionflows/references/condition_rules.md`。`actionflow component-describe Condition` 看条件组件契约。
+
+> **验证**：`e10-cli workflow action list-node <wf> <node>` 会标注 `⚠️条件` 的动作为带规则动作。条件内容在流程设计器节点 → 提交事件 → 动作的规则图标里查看。
+
+---
+
+## 动作流管理
+
+生成（`actionflow generate`）之后的查/清/删/禁用：
+
+```bash
+e10-cli workflow action list-node <wf> <node>    # 列节点绑定的动作（type0 常量赋值 + type2 动作流）
+e10-cli workflow action clear-node <wf> <node>  # 清空节点动作绑定（deleteAddAction，不删动作流实体）
+e10-cli workflow action disable <appId> <name>  # 禁用动作流（禁用后可删除）
+e10-cli workflow action delete <appId> <name>   # 删除动作流（自动先禁用再 batchAddRecycle）
+e10-cli workflow action batch-delete @list.json  # 批量删除（每项 {id,name}）
+```
+
+> **clear-node vs delete**：`clear-node` 只解绑节点（动作流实体仍在）；`delete` 删动作流 app（节点残留悬空引用，前端显示「被删除」，平台无按动作流反查节点接口，逐个 `clear-node` 清理）。
+>
+> **list-node 显示**：`type0 常量赋值`（本表字段赋值，`save-action` 写的）/ `type2 动作流`（`actionflow generate` 生成的，带 appId）。
+
+---
+
+## 角色管理
+
+```bash
+e10-cli role list                              # 查看角色树
+e10-cli role create <name> --parent <id> --code <code> --remark <text>
+e10-cli role delete <ids...>                   # 删除角色（可多个）
+e10-cli role add-member <roleId> <keyword>     # 搜索人员添加到角色
+```

package/skills/weaver-e10-builder/references/workflow/guide-workflow-auth-resp.md

@@ -0,0 +1,224 @@
+# 权责表与权责表方式流程
+
+权责表把多个条件场景及其审批路径维护为“节点列 × 分支行”。它属于工作流公用流转资源，与 HRM 矩阵、普通公共片段和流程图布局分别管理。
+
+## 一、选择方式
+
+- **默认选择随流程新建权责表**：创建权责表方式流程时使用 `--new-table`，条件直接引用当前流程表单字段。这条路径配置更直接，不需要额外维护变量映射，适用于一般权责表流程。
+- 只有权责规则需要被多个流程复用时，才先创建独立权责表，再使用 `--reuse-table` 引用并映射变量。
+- 需要多重嵌套权责表时，独立创建可复用的中间片段型权责表，首尾位置使用审批、确认等中间节点类型，再由宿主权责表按分支引用。
+- 普通顺序、分支流程继续使用流程图方式；只有需求明确要求权责表时才使用本指南。
+
+## 二、独立权责表搭建顺序
+
+1. `workflow auth-resp create` 创建权责表并记录 `authRespId`。
+2. 条件可以直接使用系统字段；需要表达业务表单字段时，先用 `workflow auth-resp variable add` 创建变量。变量必须在某个分支条件里被引用，复用到流程后再映射为实际表单字段（见 §五）。
+3. 建立发起、结束设置和多个中间审批节点。中间节点统一作为列创建，操作者规则沿用工作流节点操作者规则。
+4. 为每个有效分支填写分支场景说明并创建条件。
+5. 每个分支从已有中间节点中选择自己的路径，通过顺序号表达串行或并行。
+6. `workflow auth-resp save-design --config @design.json` 保存并回读。
+
+从零完整搭建优先使用：
+
+```bash
+e10-cli workflow auth-resp configure <authRespId> --config @auth-resp.json
+```
+
+`auth-resp.json` 使用业务结构描述变量、节点、操作者、分支条件及路径：
+
+```json
+{
+  "baseId": "创建权责表返回的baseId",
+  "name": "合同分级审批权责表",
+  "workflowId": "-99999999",
+  "usage": "workflow",
+  "variables": [
+    { "id": "-自定义稳定ID", "name": "合同金额", "type": "wf_number" }
+  ],
+  "start": { "name": "开始节点", "operator": { "type": "all" } },
+  "end": { "name": "结束节点", "operator": { "type": "initiator" } },
+  "nodes": [
+    { "key": "manager", "name": "部门负责人审批", "type": "approve", "operator": { "type": "user", "keyword": "张三" } },
+    { "key": "finance", "name": "财务审批", "type": "approve", "operator": { "type": "user", "keyword": "李四" } }
+  ],
+  "branches": [
+    {
+      "scenario": "合同金额不超过5万元",
+      "condition": {
+        "relation": "AND",
+        "rules": [
+          { "source": "form", "field": "合同金额", "operator": "小于等于", "value": 50000 }
+        ]
+      },
+      "path": [
+        { "node": "manager", "order": 1 },
+        { "node": "finance", "order": 2 }
+      ]
+    }
+  ]
+}
+```
+
+流程内新建权责表时，`workflowId` 写真实流程 ID，`source=form` 直接解析当前流程表单字段；独立权责表使用 `workflowId=-99999999`，`source=form` 会解析为 `variables` 中的同名变量。系统字段统一使用 `source=system`。复杂条件也可直接提供平台原始 `childrens`。操作者类型直接支持 `all`、`user`、`initiator`；其他已有操作者类型使用 `raw` 并提供平台 `itemDatas`，结构与普通流程操作者一致。
+
+条件字段查询：
+
+```bash
+e10-cli workflow auth-resp condition-fields <authRespId> --source-id <分支sourceId> --workflow-id <流程ID|-99999999>
+```
+
+| 业务来源 | 随流程新建权责表 | 独立或复用权责表 |
+|---|---|---|
+| 系统字段 `system` | 直接选择并保存 | 直接选择并保存 |
+| 表单字段 `form` | 直接选择当前流程实际表单字段 | 选择权责表变量作为表单字段的抽象 |
+| 变量 `variable` | 一般不需要 | 创建后用于条件，复用流程时映射到实际表单字段 |
+
+因此两种搭建方式都可以配置系统字段和表单字段条件；区别是独立权责表尚未绑定具体表单，配置时以变量表示表单字段，并在流程引用该权责表后完成变量映射。
+
+`usage=workflow` 表示完整流转，首尾默认使用发起和结束节点。`usage=fragment` 表示供其他权责表路径引用的中间片段，`start.type` 与 `end.type` 均配置为 `approve`、`confirm` 等中间节点类型；首尾位置不能使用 `start` 或 `end`。
+
+```bash
+e10-cli workflow auth-resp create "合同分级审批权责表"
+e10-cli workflow auth-resp variable add <authRespId> "合同金额" wf_number
+e10-cli workflow auth-resp variable add <authRespId> "出行人" wf_browser --second-type wf_sub_company --detail
+e10-cli workflow auth-resp variable list <authRespId>
+e10-cli workflow auth-resp read <authRespId> --base-id <baseId> > design.json
+e10-cli workflow auth-resp save-design <authRespId> --config @design.json
+```
+
+变量类型码当前已确认：
+
+| 类型码 | 含义 | 补充配置 |
+|---|---|---|
+| `wf_string` | 字符串 | — |
+| `wf_number` | 数值 | — |
+| `wf_select` | 选项 | `--option-template '{"id":"...","name":"..."}'` |
+| `wf_browser` | 浏览 | `--second-type` |
+| `wf_browser_relate` | 关联浏览 | `--relate-browser @browser.json` |
+
+变量既可以属于主表，也可以通过 `--detail` 创建为明细变量。明细变量用于表达未来流程表单中的某个明细字段，分支条件必须同时指定行量词：
+
+```json
+{
+  "condition": {
+    "relation": "AND",
+    "rules": [
+      { "source": "form", "field": "出行人", "operator": "等于", "value": [{ "id": "分部ID", "name": "泛微西安" }], "detail": "any" },
+      { "source": "form", "field": "出行人", "operator": "不为空", "detail": "all" }
+    ]
+  }
+}
+```
+
+- `detail: "any"`：任一行满足该条件，保存为 `detailOption=1`。
+- `detail: "all"`：所有行满足该条件，保存为 `detailOption=2`。
+- 字符串规则也可在末尾写 `:任一` 或 `:所有`。
+- 独立权责表中的 `source=form` 会按变量解析；明细变量被分支条件引用后，复用到流程时映射至类型匹配的实际明细字段。
+
+## 三、表格设计结构
+
+`read` 返回的设计以 `columns` 和 `rows` 为核心：
+
+- 固定列：发起设置 `creator`、分支场景说明 `eventColumn`、条件 `condition`、结束设置 `endOperator`。
+- 动态节点列：名称为 `pubNode-<节点ID>`，`pubNodeInfo` 保存节点类型和操作者摘要。
+- 嵌套权责表列：名称为 `pubNode-<权责表sourceId>`，`addMethod=2`，同时保存被引用表的 `baseId` 和版本。
+- 分支行：保存场景说明、`conditionKey`、发起/结束配置及选中的节点单元格。
+- 节点单元格：`nodeInfo` 表示该分支经过此节点；`approveNum` 是执行顺序，相同值表示并行。
+
+每个有效分支必须有非空 `eventColumn` 和 `conditionKey`。界面用于继续录入的空白占位行不进入 CLI 保存数据。
+
+操作者和条件的业务规则与普通工作流一致，具体语法读取 [流程指南](guide-workflow.md) 和 [流程条件指南](guide-workflow-condition.md)。权责表命令自动补充 `belongScene=3`、权责表 ID、分支 ID 等上下文；独立权责表使用变量表达未来需要映射的表单字段。
+
+## 四、在分支中引用权责表
+
+先查询当前宿主权责表可以引用的中间型权责表：
+
+```bash
+e10-cli workflow auth-resp reference list <宿主baseId> --name "金额复核"
+```
+
+平台按首尾节点类型过滤可引用项，并排除自身和循环引用。添加时指定被引用权责表的具体版本，以及它出现在哪些分支和对应执行顺序：
+
+```bash
+e10-cli workflow auth-resp reference add <宿主sourceId> --base-id <宿主baseId> --workflow-id <流程ID> --reference @reference.json
+```
+
+```json
+{
+  "id": "被引用权责表sourceId",
+  "name": "金额复核权责表【V1】",
+  "baseId": "被引用权责表baseId",
+  "versionNum": 1,
+  "paths": [
+    { "branch": "金额超过50万元", "order": 2 }
+  ]
+}
+```
+
+相同顺序号表示并行，不同顺序号表示串行。移除引用时，同时删除节点列和各分支中的对应路径单元格：
+
+```bash
+e10-cli workflow auth-resp reference remove <宿主sourceId> <被引用sourceId> --base-id <宿主baseId> --workflow-id <流程ID>
+```
+
+## 五、权责表方式创建流程
+
+权责表是流程的搭建方式，流程表单来源仍按原生工作流程规则选择：自建流程表单、绑定已有流程表单或绑定 EB 表单。基础表单参数写入 `base.json`，其字段与 `workflow create-workflow` 的创建结构一致。
+
+一般需求默认使用“随流程新建权责表”；仅在需求明确要求复用已有权责规则，或需要以独立中间型权责表组成多重嵌套结构时，使用“复用已有权责表”。
+
+### 默认：随流程新建权责表
+
+```bash
+e10-cli workflow auth-resp-flow create "合同审批流程" --base @base.json --new-table "合同审批权责表"
+```
+
+服务端在创建流程时生成并返回 `workflowId`、`formId` 和 `newAuthRespId`。这种方式已确定实际表单，分支条件直接选择表单字段，不做变量映射；发起和结束位置直接设置操作者。
+
+### 按需：复用已有权责表
+
+```bash
+e10-cli workflow auth-resp-flow create "合同审批流程" --base @base.json --reuse-table <authRespId> --mappings @mappings.json
+```
+
+也可以对已经创建的流程分步执行：
+
+```bash
+e10-cli workflow auth-resp-flow bind <workflowId> <authRespId>
+e10-cli workflow auth-resp-flow mapping-read <workflowId>
+e10-cli workflow auth-resp-flow mapping-save <workflowId> --mappings @mappings.json
+```
+
+复用模式把独立权责表变量映射为当前流程表单字段。先用 `mapping-read` 取得平台返回的变量项和可用字段结构，在对应项补全 `fieldBrowser` 后整体保存；变量类型必须与表单字段匹配，明细变量必须选择实际表单的明细字段。
+
+> **前置条件：只有「已被分支条件引用」的变量才会出现在映射列表里。**
+>
+> `mapping-read` 返回的 `variableMappingList` 由平台按「该变量是否被本权责表的条件引用」筛出，未被引用的变量**不会出现**，因而无从映射 —— 列表为空不一定是故障。
+>
+> 自查：`e10-cli workflow auth-resp variable list <authRespId>` 里的 `referred` 字段，为 `false` 的变量不进映射列表。
+>
+> 由此推出搭建顺序：**变量 → 用条件引用它 → 再建/绑流程 → 映射**。反过来（先建流程、后补变量）不会自动补进列表，且 `auth-resp-flow bind` 对已引用过权责表的流程会拒绝重复绑定，只能重建流程。
+
+## 六、已有权责表流程的维护
+
+权责表方式流程的节点、分支条件、流转路径和生成出口统一通过绑定的权责表设计维护：
+
+```bash
+e10-cli workflow auth-resp-flow design-read <workflowId> --auth-resp-id <sourceId> --base-id <baseId> > design.json
+e10-cli workflow auth-resp-flow design-apply <workflowId> --auth-resp-id <sourceId> --config @design.json
+```
+
+权责表设计保存后，平台生成流程节点和出口。流程的出口列表用于查看生成结果及继续配置出口附加能力；改变分支、条件、经过节点和执行顺序时修改权责表设计。
+
+变量映射是独立的流程功能。复用权责表时，将权责表变量映射到当前流程实际表单字段：
+
+```bash
+e10-cli workflow auth-resp-flow mapping-read <workflowId>
+e10-cli workflow auth-resp-flow mapping-save <workflowId> --mappings @mappings.json
+```
+
+映射项保留变量的 `varId`、`varName`、`varType`、主表/明细位置和筛选参数，在 `fieldBrowser` 中写入实际字段；主表变量映射主表字段，明细变量映射明细字段，且变量类型与字段类型保持匹配。条件中的“任一行/所有行”属于权责表条件本身，映射后继续生效。流程内新建权责表并直接使用表单字段时无需变量映射。
+
+## 七、Plan 记录
+
+流程计划中写清搭建方式、新建或复用的权责表、变量及字段映射、每个分支的场景说明与条件、经过节点和顺序、中间节点类型及操作者。执行时按“表单确定 → 权责表/流程创建 → 变量或字段条件 → 中间节点 → 分支路径 → 映射 → 其他流程设置”的顺序逐项销号。