weaver-e10-builder 1.6.4 → 1.6.6

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

@@ -4,7 +4,7 @@
 
 ## 1. 「数据ID」paramKey 格式因触发器而异（最关键）
 
-「按数据ID更新/引用当前数据」场景中，数据ID 字段的 paramKey **不是统一的 `{formId}.id`**，三种触发器各不相同：
+「按数据ID更新/引用当前数据」场景中，paramKey 随触发器和租户返回的上下文而异。下表只记录曾见过的形式，**不得作为生成依据**：
 
 | 触发器 | 数据ID 的 paramKey | 说明 |
 |---|---|---|
@@ -12,15 +12,15 @@
 | `DateTrigger` | `dataResponse.id` | 前缀是 `dataResponse.`，不是表单 id |
 | `EventFormData` | `{formId}.5` | **数据ID 是数字 `5`，不是 `.id`！** 极易踩坑 |
 
-生成 plan 时，`mapping` 源侧引用「数据ID」必须按上表写真实 paramKey，否则 preflight 的源字段校验会报「源字段 paramKey 未在真实上下文中找到」。
+生成 plan 时必须先实际查询当前触发器的上下文；上表中的历史形式不能替代当前接口响应。`mapping` 源侧仅能使用本次 `getComponentContext` 返回的 `paramKey`。
 
-> 最稳妥的做法：先跑 `workflow-context-fields` 查该触发器在当前数据源下的真实上下文，从返回里确认「数据ID」的精确 paramKey，再写入 plan，不要凭记忆猜格式。
+`ApproveTrigger` 使用 `workflow-context-fields`。其他触发器使用 `component-context-fields`，传入真实组件参数和当前动作流 ID（新建流程传 `0`）；接口没有返回该字段时，不得按表格补造。
 
-## 2. queryFields 需包含系统字段
+## 2. queryFields 的可用输出必须经上下文接口确认
 
-定时/批量/日期触发器的 `queryFields` 全选时，除了业务字段，还必须包含**平台系统字段**（数据ID / 标题 / 创建者 / 创建时间 等 9 个）。否则 `getComponentContext` 返回的上下文中**缺少「数据ID」**，导致「按数据ID更新」引用失败。
+定时/批量/日期触发器的可用字段以 `getComponentContext` 当前响应为准。是否包含数据 ID、系统字段或业务字段都必须从响应核对；`queryFields` 配置或字段选择器的结果不能代替上下文查询结果。
 
-系统字段的 `id` 是英文字符串（`id`/`name`/`creator`/`createTime`/`lastUpdateTime`/`lastUpdater`/`dataStatus`/`myTag`/`publicTag`），`content` 是中文名。宿主 agent 侧无需手动列全，但需知晓：**数据ID 属于系统字段，不随业务字段自动出现**。
+系统字段的显示名、ID 和是否出现在当前上下文都以接口响应为准；不要仅凭字段选择器或既有字段清单推断。
 
 ## 3. 动态人员引用用 `context`，不要用 `{userid}`
 

package/skill-docs/references/common/ref-cli-commands.md

@@ -301,6 +301,7 @@
 | `e10-cli wf-form add-detail-table <formId> <明细表名> [首字段名] [--init]` | 给流程表单加明细子表（saveSubForm+首字段+可选 init 放入布局）。机制同 eb 表 `form add-detail-table` |
 | `e10-cli wf-form field-options <formId> <fieldId> --options '[{"name":"事假"},...]' [--default <序号>]` | 给流程表单 Select/SelectMultiple 配选项（read-modify-write：getFormField 读全字段→改 options→saveFormFieldNew 重存）。`--options` 支持 `@文件`；`--default` 默认选项 valueKey |
 | `e10-cli wf-form layout init <formId> [--layout-id <布局ID>]` | 初始化/重建流程表单布局（initLayout，按 layoutType 选模板，默认 FLOW）。**`--layout-id` 指定要重建哪一套**（节点独立布局的 layoutId），不传则重建默认布局；字段属性用 `--read-only`/`--required`/`--single-row` 覆盖 |
+| `e10-cli wf-form layout init-reviewed <formId> [--layout-id <布局ID>] --style-template <名称或ID> [--preview-only --out <计划文件>\|--preview @<计划文件>]` | 原生流程表单（含公文流程）PC 布局的审阅式模板应用：按 FLOW/EXCEL 类型查询并校验模板，预览后执行，保存后独立回读组件和模板效果。表格式简易模板用 `--easy-template` 替代 `--style-template`；不传模板则采用该布局类型默认模板。 |
 | `e10-cli wf-form layout add <formId> --name <布局名>` | 新增一套流程表单布局。`--layout-type FLOW|EXCEL`（默认 FLOW）、`--terminal-type PC|MOBILE`（默认 PC）、`--describe`、`--workflow-id`；返回 `layoutId`，多套布局并存且不覆盖原布局 |
 | `e10-cli wf-form code layout read/set <formId> --layout-id <id> --terminal PC\|MOBILE [--js <文件>] [--css <文件>]` | 读取或写入指定原生工作流程表单布局源码；代码写法读代码块指南。**源码 ecode 必须用 `encodeURI`，不能用 `encodeURIComponent`（设计器 `decodeURI` 读取）** |
 | `e10-cli wf-form code layout preview/apply <formId> --layout-id <id> --terminal PC\|MOBILE [--js <文件>] [--css <文件>]` | 流程表单布局代码块的独立预览与回读写入；预览用 `--out`，应用用 `--preview @<文件>`。 |
@@ -447,18 +448,19 @@
 
 | 命令 | 说明 |
 |------|------|
-| `e10-cli menu list <appId>` | 列出当前Ebuilder应用下的菜单。**递归展开嵌套菜单**（如「设置 → 个人设置 → 个人菜单设置」），列表即全量 —— 在这里没找到就是真没有，不必再怀疑被折叠。`--raw [菜单ID]` 打印菜单的**原始报文**（读侧记录与写侧报文形状不同，核对某一项到底存了什么时看它） |
-| `e10-cli menu rename <appId> <菜单ID或名称> <新名>` | 重命名已有菜单（含嵌套菜单）。名称在应用内重复时必须改用 ID，命令会列出候选让你选。平台系统菜单（回收站/设置等）不能改。**改父级用 `menu move`** |
-| `e10-cli menu add <name> <path> <appId> [--parent <父菜单ID或名称>] [--first\|--show-order <n>]` | 将页面加入左侧导航（LINK 类型，URL path）。ecode 页面 path 如 `/sp/custom/ecode/project-list`。**表单台账/流程发起菜单用下面两条专用命令**（VIEWPORT/LAYOUT 类型，非 URL）。`--parent` 挂到父菜单下做子菜单（缺省 `0`=顶级）。**排序**：平台按同级 `showOrder` 升序显示，新建默认 1（落在最后）；`--first` 排到同级最前，`--show-order <n>` 指定任意排序号。**建完会回读确认**菜单 ID、层级与排序；回读不到就报错退出，不谎报成功 |
-| `e10-cli menu add-dir <appId> <name> [--parent <父菜单ID或名称>] [--first\|--show-order <n>]` | 加**上级目录**菜单 —— **空链接**的纯分类节点，只用来给子菜单分组，点它不跳页面。设计器里建「上级目录」就是这个（存下来 `pageType=EMPTY`、`pageId/pageName` 空、**没有 `menuUrl`**、`menuType="0"`）。`--parent` 支持菜单 ID 或名称（缺省 `0`=顶级），排序参数同上。**建完回读确认**并核对层级与排序，另外**核对 `pageType` 确实是 `EMPTY`** —— 不是就说明链接没留空，直接报错而不是谎报成功。⚠ 与 `menu add` 的区别：要指向某个页面的父菜单（点得开）用 `menu add`，纯分组的用这条 |
-| `e10-cli menu add-table <appId> <objId> [name] [--parent <父菜单ID或名称>] [--first\|--show-order <n>]` | 给表单加**台账菜单**（VIEWPORT，指向数据列表页）。`form create --menu` 才自动加（默认不加），此处用于事后补加。**`--parent` 挂到某个父菜单下做子菜单**（缺省 `0`=顶级；既收菜单 ID 也收名称，同名多条会报错并列 ID），`--first`/`--show-order` 控制同级顺序。**建完回读确认**，并**核对层级与排序** —— 只确认菜单存在不够，`pid` / `showOrder` 没生效时菜单照样建出来、只是跑到顶级或最后 |
-| `e10-cli menu add-start <appId> <formObjId> [name] [--parent <父菜单ID或名称>] [--first\|--show-order <n>]` | 给流程绑定的表单加**发起菜单**（LAYOUT，指向表单新建页，点开触发流程）。`workflow create --menu` 才自动加（默认不加）。`--parent` / 排序参数同上。**建完回读确认**并核对层级与排序 |
-| `e10-cli menu order <appId> <menu> [--first\|--show-order <n>]` | **调整已有菜单在同级里的顺序**（不改父级）。`--first` 排到同级最前（排序号取同级非系统菜单最小值 - 1）；`--show-order <n>` 直接指定整数排序号，越小越靠前。改完回读 `showOrder` 与同级位置，并确认名字/页面/链接等其它字段没被改动。系统菜单（设置/回收站）拒绝调整 |
-| `e10-cli menu move <appId> <menu> --parent <父菜单ID或名称> [--first\|--show-order <n>]` | **把已有菜单移动到另一个父级下**（名称、页面不变）。`--parent 0` 移到顶级；可同时用 `--first` / `--show-order <n>` 调整在新同级里的顺序。拒绝系统菜单、拒绝移到自身或自己的子菜单下（防成环）；已在目标父级且排序未变时提示无需移动。写 `savePublishMenu` 的 `pid`，回读父级、排序与同级位置，并确认其它字段未被改动 |
+| `e10-cli menu list <appId> [--terminal pc\|mobile]` | 列出当前Ebuilder应用下的菜单。**递归展开嵌套菜单**（如「设置 → 个人设置 → 个人菜单设置」），列表即全量 —— 在这里没找到就是真没有，不必再怀疑被折叠。`--raw [菜单ID]` 打印菜单的**原始报文**（读侧记录与写侧报文形状不同，核对某一项到底存了什么时看它）。PC 与移动端是**两套独立菜单**，移动端要加 `--terminal mobile` |
+| `e10-cli menu rename <appId> <菜单ID或名称> <新名> [--terminal pc\|mobile]` | 重命名已有菜单（含嵌套菜单）。名称在应用内重复时必须改用 ID，命令会列出候选让你选。平台系统菜单（回收站/设置等）不能改。**改父级用 `menu move`**；**改打开方式用 `menu open-mode`** |
+| `e10-cli menu add <name> <path> <appId> [--parent <父菜单ID或名称>] [--first\|--show-order <n>] [--open-mode default\|new-window] [--terminal pc\|mobile]` | 将页面加入左侧导航（LINK 类型，URL path）。ecode 页面 path 如 `/sp/custom/ecode/project-list`。**表单台账/流程发起菜单用下面两条专用命令**（VIEWPORT/LAYOUT 类型，非 URL）。`--parent` 挂到父菜单下做子菜单（缺省 `0`=顶级）。**排序**：平台按同级 `showOrder` 升序显示，新建默认 1（落在最后）；`--first` 排到同级最前，`--show-order <n>` 指定任意排序号。**打开方式**：缺省「默认窗口」，`--open-mode new-window` 点击后在新窗口打开。**建完会回读确认**菜单 ID、层级、排序与打开方式；回读不到就报错退出，不谎报成功 |
+| `e10-cli menu add-dir <appId> <name> [--parent <父菜单ID或名称>] [--first\|--show-order <n>] [--terminal pc\|mobile]` | 加**上级目录**菜单 —— **空链接**的纯分类节点，只用来给子菜单分组，点它不跳页面。设计器里建「上级目录」就是这个（存下来 `pageType=EMPTY`、`pageId/pageName` 空、**没有 `menuUrl`**、`menuType="0"`）。`--parent` 支持菜单 ID 或名称（缺省 `0`=顶级），排序参数同上。**建完回读确认**并核对层级与排序，另外**核对 `pageType` 确实是 `EMPTY`** —— 不是就说明链接没留空，直接报错而不是谎报成功。⚠ 与 `menu add` 的区别：要指向某个页面的父菜单（点得开）用 `menu add`，纯分组的用这条 |
+| `e10-cli menu add-table <appId> <objId> [name] [--parent <父菜单ID或名称>] [--first\|--show-order <n>] [--open-mode default\|new-window] [--terminal pc\|mobile]` | 给表单加**台账菜单**（VIEWPORT，指向数据列表页）。`form create --menu` 才自动加（默认不加），此处用于事后补加。**`--parent` 挂到某个父菜单下做子菜单**（缺省 `0`=顶级；既收菜单 ID 也收名称，同名多条会报错并列 ID），`--first`/`--show-order` 控制同级顺序，`--open-mode` 选打开方式。**建完回读确认**，并**核对层级与排序** —— 只确认菜单存在不够，`pid` / `showOrder` 没生效时菜单照样建出来、只是跑到顶级或最后 |
+| `e10-cli menu add-start <appId> <formObjId> [name] [--parent <父菜单ID或名称>] [--first\|--show-order <n>] [--open-mode default\|new-window] [--terminal pc\|mobile]` | 给流程绑定的表单加**发起菜单**（LAYOUT，指向表单新建页，点开触发流程）。`workflow create --menu` 才自动加（默认不加）。`--parent` / 排序参数同上，`--open-mode` 选打开方式。**建完回读确认**并核对层级与排序 |
+| `e10-cli menu open-mode <appId> <menu> <default\|new-window> [--terminal pc\|mobile]` | **改已有菜单的打开方式**：`default`=默认窗口、`new-window`=新窗口。只改这一项，改完回读打开方式，并确认名字/页面/链接等其它字段未被改动。系统菜单与上级目录（无页面）拒绝设置 |
+| `e10-cli menu order <appId> <menu> [--first\|--show-order <n>] [--terminal pc\|mobile]` | **调整已有菜单在同级里的顺序**（不改父级）。`--first` 排到同级最前（排序号取同级非系统菜单最小值 - 1）；`--show-order <n>` 直接指定整数排序号，越小越靠前。改完回读 `showOrder` 与同级位置，并确认名字/页面/链接等其它字段没被改动。系统菜单（设置/回收站）拒绝调整 |
+| `e10-cli menu move <appId> <menu> --parent <父菜单ID或名称> [--first\|--show-order <n>] [--terminal pc\|mobile]` | **把已有菜单移动到另一个父级下**（名称、页面不变）。`--parent 0` 移到顶级；可同时用 `--first` / `--show-order <n>` 调整在新同级里的顺序。拒绝系统菜单、拒绝移到自身或自己的子菜单下（防成环）；已在目标父级且排序未变时提示无需移动。写 `savePublishMenu` 的 `pid`，回读父级、排序与同级位置，并确认其它字段未被改动 |
 | ↳ 搭「父菜单 + 子菜单」 | 设计器里的二级菜单 = 先建父菜单（**纯分组用 `menu add-dir`**；父菜单自己也要指向某页才用 `menu add`），再把台账/发起菜单用 `--parent <父菜单>` 挂上去。父菜单 ID 从 `menu list` 拿（输出就是完整菜单树）。新建的子菜单默认排在同级最后；要放第一个加 `--first`，已建好的用 `menu order <appId> <menu> --first` |
-| `e10-cli menu permission list <appId> <menuId>` | 列菜单可见范围授权（**默认所有人**；无输出=全可见） |
-| `e10-cli menu permission add <appId> <menuId> <目标> --type role\|dept\|user\|all` | 给菜单授权。默认语义：**加角色/人/部门后自动撤「所有人」→ 只有授权对象可见**；`--keep-all` 保留所有人；`--type all` 恢复"所有人可见" |
-| `e10-cli menu permission remove <appId> <menuId> <目标> --type role\|dept\|user\|all` | 撤销菜单授权（撤销所有人用 `--type all`） |
+| `e10-cli menu permission list <appId> <menuId>` | 列菜单可见范围，**分「可见」与「可见范围内禁用」两栏**输出（可见栏为空 = 默认所有人可见）。授权对象支持人员 / 部门 / 角色 / 岗位 / 所有人 |
+| `e10-cli menu permission add <appId> <menuId> <目标> --type role\|dept\|user\|position\|all [--scope visible\|disabled]` | 给菜单授权。`--scope` 缺省 `visible`（可见栏）：**加角色/人/部门后自动撤「所有人」→ 只有授权对象可见**；`--keep-all` 保留所有人；`--type all` 恢复"所有人可见"。`--scope disabled` 加到「可见范围内禁用」栏（在可见人群里排除这些对象），不触发收窄。写入后回读该栏确认 |
+| `e10-cli menu permission remove <appId> <menuId> <目标> --type role\|dept\|user\|all [--scope visible\|disabled]` | 撤销菜单授权（撤销所有人用 `--type all`）。不给 `--scope` 时先找可见栏、找不到再找禁用栏；撤销后回读确认该行已消失 |
 | `e10-cli menu delete <menuId> <appId>` | 删除菜单项 |
 
 ---

package/skill-docs/references/form/guide-browser-definition.md

@@ -58,42 +58,26 @@ e10-cli form-engine browser-definition scope set <formId> <fieldId> --module <mo
 
 `records` 是完整范围记录，按 `get` 回读的 ID 更新既有项。人员范围与流程操作者的选项概念相近，但并非全量相同，必须以 `describe` 返回的可选布局为准。加入多项范围时，其可选数据取并集；未设置范围时不应把它误判为“空范围”。
 
-### 自定义浏览框
+### 关联 EBuilder：先选配置方式
 
-先用 `inspect` 找出目标字段及其 `bcw/customBrowser_*` 来源，再用 `describe` 或 `scope get` 读取当前配置和 `conditionLayout`。候选布局按当前浏览框动态返回，每个字段提供 `id/text/type/compType/conditionType` 等信息；条件树叶节点的字段 ID 与操作符须来自这份布局。`scopeInfoRender` 使用平台的完整条件树 JSON 字符串，组节点的 `datas` 可嵌套 AND／OR 条件。日期区间在候选操作符中记作 `between`，已见保存条件采用 `conditions.func="range"` 且 `value` 为两个日期值；其他操作符和值结构按该字段实际候选及现有配置填写。高级搜索同样先读该浏览框返回的 `layout.items`，再构造 `commonLines/commonCells/lines/cells/searchValue`。Tab 是否可配以 `inspect` 的 `tabs.platform` 为准。
+关联 EBuilder 的数据范围决定**目标表单的哪些记录可以在浏览弹窗中选择**。先按规则复杂度选择命令：
 
-### 关联 EBuilder 的嵌套条件
+| 需求 | 配置方式 | 适用范围 |
+| --- | --- | --- |
+| 按目标表单字段设置一层“且／或”条件 | `form ebuilder-scope get/set/clear` | 可使用固定值、目标字段选项、当前表单字段或目标表单字段作条件值 |
+| `A OR (B AND C)` 等混合嵌套条件 | `form-engine browser-definition scope get/set` | 读取候选布局后编写完整条件树 |
 
-关联 EBuilder 的数据范围使用 `scopeType=scopeSql` 的条件树。`form ebuilder-scope set --rules ... --logic and|or` 适合一层平铺条件；需要 `A OR (B AND C)` 等混合逻辑时，使用本命令的完整 `records[].scopeInfoRender`。先用 `scope get` 读取原配置，按目标表实际字段、字段类型和可选操作符调整条件树，再保存并回读。
+先区分两张表单：**当前表单**是用户正在填写、包含关联 EBuilder 字段的源表单；**目标表单**是该关联字段打开浏览弹窗后列出记录的 EBuilder 表单。每条条件的左侧 `field` 始终选择**目标表单字段**，右侧取值来源决定比较方式：
 
-条件树中的 `datas` 可以同时包含字段条件和子条件组；组的 `relationship` 为 `1`（AND／所有条件）或 `0`（OR／任一条件）。每个组有唯一 `key`，子项的 `parentNode` 指向直接父组的 `key`。例如 `A OR (B AND C)` 的结构是：
+| 右侧取值方式 | 左侧 `field` | 右侧字段 | 适用场景 |
+| --- | --- | --- | --- |
+| 固定值 `value` | 目标表单字段 | 手工输入的值或目标字段的选项 | 只允许选择状态为“启用”的目标记录 |
+| 变量字段 `valueFrom: "currentFormField"` | 目标表单字段 | 当前表单字段 `valueField` | 只允许选择“所属项目”等于当前申请“相关项目”的任务；当前表单字段值作为筛选变量 |
+| 本表字段 `valueFrom: "targetFormField"` | 目标表单字段 | 同一目标表单的另一个字段 `valueField` | 在每条目标记录内部比较两个字段；不引用当前表单的值 |
 
-```json
-{
-  "key": "root", "relationship": "0", "isParent": true, "parentNode": "",
-  "isNewFilter": true, "version": 1, "showFilterIsNull": false,
-  "datas": [
-    { "key": "a", "parentNode": "root", "isParent": false, "type": "condition",
-      "id": "name", "fieldName": "name", "fieldType": "String", "compType": "Text", "text": "标题",
-      "conditions": { "func": "eq", "value": "A", "selectValue": { "id": "manualInput", "content": "手动输入", "type": "SELECTION_CUSTOM" }, "customValue": "A", "customBrowserValue": [] } },
-    { "key": "group-bc", "parentNode": "root", "relationship": "1", "isParent": true,
-      "datas": [
-        { "key": "b", "parentNode": "group-bc", "isParent": false, "type": "condition",
-          "id": "name", "fieldName": "name", "fieldType": "String", "compType": "Text", "text": "标题",
-          "conditions": { "func": "eq", "value": "B", "selectValue": { "id": "manualInput", "content": "手动输入", "type": "SELECTION_CUSTOM" }, "customValue": "B", "customBrowserValue": [] } },
-        { "key": "c", "parentNode": "group-bc", "isParent": false, "type": "condition",
-          "id": "name", "fieldName": "name", "fieldType": "String", "compType": "Text", "text": "标题",
-          "conditions": { "func": "eq", "value": "C", "selectValue": { "id": "manualInput", "content": "手动输入", "type": "SELECTION_CUSTOM" }, "customValue": "C", "customBrowserValue": [] } }
-      ] }
-  ]
-}
-```
-
-上面展示的是 `scopeInfoRender` **解码后的条件树**，用于说明嵌套关系；实际 `scope.json` 须把整棵树序列化为 JSON 字符串，放入 `{"records":[{"scopeType":"scopeSql","scopeInfoRender":"<序列化后的条件树>"}]}`。字段 `id/fieldName/fieldType/compType`、`conditions` 的操作符和值结构要按目标字段和 `scope get` 返回的同类条件填写；选项、表单字段、变量字段等值的配置形状与示例的手动文本值不同。更新已有规则时保留其记录 ID（CLI 在未给 ID 时也会按 `scopeType` 查找并沿用已有 ID）。保存后再次 `scope get`，核对树层级、每层 `relationship`、字段和值及记录 ID。工作流程场景还须传 `--workflow-id`，并在所属工作流程的实际使用场景核对筛选效果。
+“本表字段”的“本表”指**被浏览的目标表单**。如果需求写着“关联任务只能选当前所选项目的任务”，右侧应选**变量字段**，不能选本表字段。空值判断 `isnull`、`notnull` 没有右侧取值。旧 `form ebuilder-filter` 修改的是字段布局中的过滤参数，不保证被浏览数据定义识别；设置浏览弹窗可选记录使用本节的数据范围命令。
 
-### 关联 EBuilder 的简便规则
-
-关联 EBuilder 字段的数据范围决定**目标表单的哪些记录可以在浏览弹窗中选择**。只需按目标表单主表字段给出一层 AND／OR 条件时，可使用 `form ebuilder-scope`；复杂嵌套条件使用上面的完整条件树。
+#### 常用规则：查询、设置与清空
 
 ```bash
 e10-cli form ebuilder-scope get <源objId> <appId> <EBuilder字段fieldId>
@@ -101,7 +85,11 @@ e10-cli form ebuilder-scope set <源objId> <appId> <EBuilder字段fieldId> --rul
 e10-cli form ebuilder-scope clear <源objId> <appId> <EBuilder字段fieldId>
 ```
 
-`源objId` 是包含关联字段的表单对象 ID；`appId` 是应用 ID；`fieldId` 是该关联字段的 ID。规则中的 `field` 指**被关联的目标表单主表字段**，可用字段名或 ID；名称重名时使用 ID。`--logic and|or` 控制所有规则的关系，缺省为 `and`。`--fill-null` 可在需要关联字段为空时填充的场景下使用，缺省关闭。配置文件是规则数组，例如：
+`源objId` 是包含关联字段的表单对象 ID；`appId` 是应用 ID；`fieldId` 是该关联字段的 ID。规则中的 `field` 指目标表单主表字段，可填字段名或 ID，重名时用 ID。`--logic and|or` 控制所有规则的关系，缺省为 `and`。`--fill-null` 可在需要关联字段为空时填充的场景下使用，缺省关闭。
+
+规则文件是 JSON 数组。操作符与条件取值写法如下：
+
+例如，同时按客户状态和名称设置固定值条件：
 
 ```json
 [
@@ -110,13 +98,16 @@ e10-cli form ebuilder-scope clear <源objId> <appId> <EBuilder字段fieldId>
 ]
 ```
 
-| 规则项 | 可用写法 |
-| --- | --- |
-| `operator` | `eq` 等于、`neq` 不等于、`like` 包含、`isnull` 为空、`notnull` 不为空 |
-| `value` | 文本、数字和日期填写目标值；选项类字段填写选项名或唯一的选项值 ID，由 CLI 匹配目标字段的实际选项；`isnull`、`notnull` 不填写 |
-| `valueFrom` + `valueField` | 不填固定 `value`。`currentFormField` 为“变量字段”，引用当前表单的主表字段；`targetFormField` 为“本表字段”，引用被浏览目标表单的主表字段。`valueField` 可写字段名或 ID，重名用 ID。 |
+| 项目 | 写法 | 含义与限制 |
+| --- | --- | --- |
+| `operator` | `eq`、`neq`、`like`、`isnull`、`notnull` | 等于、不等于、包含、为空、不为空；空值条件不填条件值 |
+| 固定值 | `"value":"上海"` | 文本、数字、日期填目标值；选项类字段可填选项名或唯一选项值 ID，CLI 按实际选项匹配 |
+| 当前表单字段 | `"valueFrom":"currentFormField","valueField":"相关项目"` | 选择“变量字段”：左侧仍是目标表单字段，右侧引用源表单主表字段的当前值 |
+| 目标表单字段 | `"valueFrom":"targetFormField","valueField":"项目简介"` | 选择“本表字段”：左侧和右侧均来自被浏览的目标表单主表字段，逐条目标记录内部比较 |
+
+字段引用时不填固定 `value`；`valueField` 可填字段名或 ID，重名时用 ID。CLI 先查询字段候选，再分别生成变量字段或本表字段的配置。目前字段引用只验证了**条件左侧为关联浏览字段**的情况；简便规则只读取源表单和目标表单的主表字段，不用于目标明细字段。
 
-例如，浏览“关联项目”时，让目标表的“关联合同”等于当前表单的“关联合同”；或者让目标表的“关联客户”等于目标表自己的“项目简介”：
+例如，浏览“关联项目”时，让目标表的“关联合同”等于当前表单的“关联合同”；再让目标表的“关联客户”等于目标表自己的“项目简介”：
 
 ```json
 [
@@ -125,15 +116,57 @@ e10-cli form ebuilder-scope clear <源objId> <appId> <EBuilder字段fieldId>
 ]
 ```
 
-这两种字段引用的保存结构不同。CLI 会先查字段候选，再分别生成变量字段或本表字段的配置；已有范围规则保存前用 `get` 确认，`set --rules` 会以本次规则数组重建这棵简便条件树。当前仅验证了以关联浏览字段作为筛选条件，且简便写法只支持当前表单和目标表单的主表字段。复杂嵌套条件仍使用上节的完整条件树。
+例如，浏览“关联任务”时，只允许选择“所属项目”等于当前申请的“相关项目”、且“任务状态”不为“已完成”的任务，`scope-rules.json` 可写为：
+
+```json
+[
+  {"field":"所属项目","operator":"eq","valueFrom":"currentFormField","valueField":"相关项目"},
+  {"field":"任务状态","operator":"neq","value":"已完成"}
+]
+```
+
+此例须先确认“所属项目”是关联浏览字段、“任务状态”的选项中确有“已完成”，再用 `--logic and` 写入。选项名称或值 ID 均由 CLI 对照目标字段的实际选项。另一个字段引用例子是 `{"field":"关联客户","operator":"eq","valueFrom":"targetFormField","valueField":"项目简介"}`，表示目标表单内两个字段相比较。
+
+`set --rules` 会按本次数组重建整组简便规则，修改前先 `get` 并保留仍需生效的条件。写入后再次 `get` 回读，并在实际表单的浏览弹窗核对可选记录。字段引用已验证写入与回读；随当前表单字段值变化的实时筛选效果仍须在实际场景核对。
 
-例如，只允许选择状态为“启用”的客户：
+只允许选择状态为“启用”的客户时，也可直接传规则数组：
 
 ```bash
 e10-cli form ebuilder-scope set <源objId> <appId> <EBuilder字段fieldId> --rules '[{"field":"客户状态","operator":"eq","value":"启用"}]'
 ```
 
-设置后用 `get` 回读规则，再在设计器和实际浏览弹窗核对可选数据；`clear` 清空这些规则。简便规则只读取目标表单主表字段，不用它筛选目标明细字段。旧 `form ebuilder-filter` 修改的是字段布局中的过滤参数，不保证被浏览数据定义识别；新增数据范围使用本节命令。
+#### 复杂规则：完整条件树
+
+关联 EBuilder 使用 `scopeType=scopeSql` 的条件树。需要 `A OR (B AND C)` 等混合逻辑时，使用 `form-engine browser-definition scope get/set` 读写完整 `records[].scopeInfoRender`。先用 `scope get` 读取原配置和候选布局，按目标表实际字段、字段类型与可选操作符调整条件树，再保存并回读。
+
+条件树中的 `datas` 可以同时包含字段条件和子条件组；组的 `relationship` 为 `1`（AND／所有条件）或 `0`（OR／任一条件）。每个组有唯一 `key`，子项的 `parentNode` 指向直接父组的 `key`。例如 `A OR (B AND C)` 的结构是：
+
+```json
+{
+  "key": "root", "relationship": "0", "isParent": true, "parentNode": "",
+  "isNewFilter": true, "version": 1, "showFilterIsNull": false,
+  "datas": [
+    { "key": "a", "parentNode": "root", "isParent": false, "type": "condition",
+      "id": "name", "fieldName": "name", "fieldType": "String", "compType": "Text", "text": "标题",
+      "conditions": { "func": "eq", "value": "A", "selectValue": { "id": "manualInput", "content": "手动输入", "type": "SELECTION_CUSTOM" }, "customValue": "A", "customBrowserValue": [] } },
+    { "key": "group-bc", "parentNode": "root", "relationship": "1", "isParent": true,
+      "datas": [
+        { "key": "b", "parentNode": "group-bc", "isParent": false, "type": "condition",
+          "id": "name", "fieldName": "name", "fieldType": "String", "compType": "Text", "text": "标题",
+          "conditions": { "func": "eq", "value": "B", "selectValue": { "id": "manualInput", "content": "手动输入", "type": "SELECTION_CUSTOM" }, "customValue": "B", "customBrowserValue": [] } },
+        { "key": "c", "parentNode": "group-bc", "isParent": false, "type": "condition",
+          "id": "name", "fieldName": "name", "fieldType": "String", "compType": "Text", "text": "标题",
+          "conditions": { "func": "eq", "value": "C", "selectValue": { "id": "manualInput", "content": "手动输入", "type": "SELECTION_CUSTOM" }, "customValue": "C", "customBrowserValue": [] } }
+      ] }
+  ]
+}
+```
+
+上面展示的是 `scopeInfoRender` **解码后的条件树**，用于说明嵌套关系；实际 `scope.json` 须把整棵树序列化为 JSON 字符串，放入 `{"records":[{"scopeType":"scopeSql","scopeInfoRender":"<序列化后的条件树>"}]}`。字段 `id/fieldName/fieldType/compType`、`conditions` 的操作符和值结构要按目标字段和 `scope get` 返回的同类条件填写；选项、表单字段、变量字段等值的配置形状与示例的手动文本值不同。更新已有规则时保留其记录 ID（CLI 在未给 ID 时也会按 `scopeType` 查找并沿用已有 ID）。保存后再次 `scope get`，核对树层级、每层 `relationship`、字段和值及记录 ID。工作流程场景还须传 `--workflow-id`，并在所属工作流程的实际使用场景核对筛选效果。
+
+### 自定义浏览框
+
+先用 `inspect` 找出目标字段及其 `bcw/customBrowser_*` 来源，再用 `describe` 或 `scope get` 读取当前配置和 `conditionLayout`。候选布局按当前浏览框动态返回，每个字段提供 `id/text/type/compType/conditionType` 等信息；条件树叶节点的字段 ID 与操作符须来自这份布局。`scopeInfoRender` 使用平台的完整条件树 JSON 字符串，组节点的 `datas` 可嵌套 AND／OR 条件。日期区间在候选操作符中记作 `between`，已见保存条件采用 `conditions.func="range"` 且 `value` 为两个日期值；其他操作符和值结构按该字段实际候选及现有配置填写。高级搜索同样先读该浏览框返回的 `layout.items`，再构造 `commonLines/commonCells/lines/cells/searchValue`。Tab 是否可配以 `inspect` 的 `tabs.platform` 为准。
 
 ### 人员范围码表与简化规则
 

package/skill-docs/references/form/layout/code-block/layout-css.md

@@ -77,6 +77,20 @@ e10-cli form code layout apply <表单objId> --layout-id <布局ID> --terminal P
 
 多行文本、日期、下拉、浏览框可能由 `textarea`、`.ui-input-wrap`、`.ui-select-input`、`.ui-browser` 或更外层绘制边框；逐个定位实际画线元素。避免对 `.ebpage input` 或 `.ebpage *` 一次性去边框，这会误伤选择标记、上传区和表格线。
 
+### 流式 PC 布局：分组与下拉框
+
+已确认的流式 PC 页面以 `.weapp-ebpv-styled-flow` 标识布局容器。分组使用 `.weapp-form-widget__Collapse`；标题下方的蓝线是 `.weapp-form-collapse .ui-collapse-panel__title` 的 `border-bottom`，已观察到 `1px solid #1C69DB`。这条线也可由分组标题的布局样式设置产生；需要统一外观时优先检查分组标题配置，不要把设计器选中时的蓝色虚线框当成运行时边框。
+
+下拉字段外层带 `.weapp-form-widget__Select`。实际画出灰色外框的是其 `.weapp-form-widget-content-container`：四侧计算样式均为 `1px solid #E2E2E2`。内部的 `.ui-select-input` 和 `.ui-input-wrap.ui-select-input` 四侧边框为 `none`；只修改内部节点的 `border` 无法替换可见外框。若目标布局需要给下拉外框单独配色，可在布局 CSS 中限定字段类型：
+
+```css
+.weapp-ebpv-styled-flow .weapp-form-widget__Select .weapp-form-widget-content-container {
+  border-color: #2F6FED;
+}
+```
+
+此选择器依据页面 DOM 和计算样式确定，写入后的覆盖效果仍需在目标布局检查。不要把具体 `#widget_…` 或 `.weapp-form-layout_…` 的生成 ID 写进可复用规则。流式明细表已观察到 `.weapp-form-detail-table--FLOW`、`.weapp-form-detail-table-field-header` 和 `td.weapp-form-detail-table-column`；表头和格线的绘制节点尚需分别核对，不能直接套用表格式的 `.excelTableView-content-excel-table` 规则。
+
 ### 表格式布局的明细表
 
 以下规则针对已识别的表格式 PC 明细表结构。流式明细表只有在实际存在这些类和表格元素时才可复用。
@@ -97,6 +111,33 @@ e10-cli form code layout apply <表单objId> --layout-id <布局ID> --terminal P
 
 明细表标题对齐与基础边框先用布局网格设置。需要 CSS 补充表头配色时，同时检查内容表与固定表头 `.excelTableView-content-excel-table-fixed-first-row`。把背景写到 `td` 上，是为了避免单元格自带背景遮住整行状态色。
 
+## 常见样式场景
+
+以下按视觉目标选择写法。除了前文已识别的表格式组件路径，`.wea-form-*`、`.wea-detail-*` 等类名只作结构示意；使用前要从目标布局的实际 DOM 中取得选择器。优先用布局样式、排版、网格和字段属性完成平台已有的设置，CSS 负责其余视觉细节。
+
+| 场景 | 写法与检查点 |
+| --- | --- |
+| URL／长文本限制行数 | 若目标页面确有 `.wea-url > span > p` 路径，可对其使用 `display:-webkit-box; -webkit-box-orient:vertical; -webkit-line-clamp:3; overflow:hidden`。要只影响明细表时，在选择器前加实际明细容器作用域；检查悬停、编辑态与完整内容的可访问方式。 |
+| 只读态视觉区分 | 找到真实的只读状态标记与输入框包裹层，再调整背景、边框和字色。隐藏清除按钮或下拉箭头只改变外观，不改变字段权限；先检查布局样式中已有的只读背景选项。 |
+| 明细表表头与行 | 可设置表头配色、隔行色、悬停与数字对齐；表格式布局沿用上节的真实 DOM 路径，同时检查固定表头。数字列须用实际列标记限定，避免把文本列也右对齐。 |
+| 按钮与表头 | 可补充品牌色、圆角、阴影或渐变；先检查布局样式中的按钮及表头配置，并确认选择器只覆盖目标布局与目标按钮，不误改弹窗按钮。 |
+| 紧凑排版 | 可微调标题、字段间距和字号；列数、标题位置及网格尺寸仍用布局配置。不要通过 `float` 等规则重排字段。 |
+| 必填与错误提示 | 可强化已有必填标记和错误状态的颜色、边框；先确认平台是否已经绘制星号，避免用 `::before` 重复生成。CSS 不代替必填和校验规则。 |
+| 打印 | 用 `@media print` 隐藏实际页面的工具栏与操作按钮，并检查表头对比度、分页、固定表头及打印预览；不要假定屏幕上的按钮类名适用于打印页面。 |
+
+例如，已确认目标布局存在 `.wea-url > span > p` 时，可在该布局的 CSS 文件中加入：
+
+```css
+.wea-url > span > p {
+  display: -webkit-box;
+  -webkit-box-orient: vertical;
+  -webkit-line-clamp: 3;
+  overflow: hidden;
+}
+```
+
+其他场景先取目标元素及其父层的 DOM，再把上表中的目标映射为实际选择器；不要把示意类名直接保存到布局源码。获取 DOM 时，记录布局类型、终端以及普通／只读／报错等对应状态即可，不需要整页源码。
+
 ## 表格式与流式如何选规则
 
 | 对象 | 表格式布局 | 流式布局 |

package/skill-docs/references/form/layout/initialization.md

@@ -37,3 +37,5 @@ e10-cli form layout init-reviewed <objId> --config @init-config.json --preview @
 ```
 
 初始化会重建整套布局，即使只覆盖一个字段也是如此。对已有布局的单字段属性调整，应先评估是否有更局部的字段属性命令；不要为了一个开关重建已精细设计的布局。`display/show` 会影响显示状态，执行后还应在实际表单预览中核对可见性。
+
+原生工作流程表单及公文流程的 PC 布局使用 `wf-form layout init-reviewed` 完成同类模板的预览、应用和回读；参数与适用范围见[流程表单布局](workflow-layout.md)。EB 表单的 `form layout init-reviewed` 不接受流程表单 ID。

package/skill-docs/references/form/layout/layout-overview.md

@@ -52,6 +52,8 @@
 
 高级表格式模板的网格、模板 CSS 与实际布局 CSS 是不同的保存对象。模板被应用后，仍需回读实际布局并检查页面效果。当前 PC 流式模板的独立编辑、启停及删除不作为可用能力；按[流式模板指南](template/flow.md)中已经确认的能力操作。
 
+创建或编辑布局时，应先把用户期望的**整体效果**拆成结构、单元格、组件、通用样式和运行状态，再选择相应能力组合完成。表格式的行列、合并、字段位置及单元格字体、背景、边框由网格或模板设置承担；组件的通用属性按已支持的布局样式设置；主题色、悬停、高亮及控件的特殊呈现可由 CSS 补足；需要交互逻辑时再使用 JS。一个效果涉及多个层级时，应把相关配置一起完成并在实际布局中核对，不应只修改其中一个层级就认为整体效果已经实现。
+
 ## 通用核对顺序
 
 1. 查询目标表单、布局 ID、布局类型、终端及字段；已有精细布局先导出底稿。
@@ -60,6 +62,12 @@
 4. 按原配置与预览结果应用，随后独立回读。布局代码还须在实际页面检查运行效果；CSS 还须检查 PC／移动端和组件状态。
 5. 若目标布局或字段在预览后发生变化，重新读取并预览，不沿用旧报告。
 
+## 问题反馈
+
+创建模板、创建或调整布局时，正常的配置选择、预览和回读按任务连续完成；**一般情况不需要停下来要求用户确认，也不需要逐项报告无问题的检查结果**。
+
+遇到冲突、校验失败或预览效果异常时，应向用户说清楚：**哪个模板或布局、哪个区域／字段／单元格出了什么问题，对保存或实际显示有什么影响，准备如何修正**。例如列宽总和不符、组件位置重叠、分组或明细区域落在窄列、模板与布局类型不匹配、草稿引入新的结构问题。可修正的问题先依据预览和现有配置修正，再重新核对；无法继续时说明具体阻断原因及所需信息。不要只转述 `canApply=false`、`issues` 或笼统地说“布局有问题”。
+
 各命令的完整参数见[CLI 命令参考](../../common/ref-cli-commands.md)。
 
 ## 相关能力

package/skill-docs/references/form/layout/template/advanced.md

@@ -101,6 +101,27 @@
 
 字体、字号等独立项只修改指定部分；完整 `font` 值与这些独立项不能同时写。颜色可用 `#RGB`、`#RRGGBB` 或 `#RRGGBBAA`。只能向**没有字段组件**的单元格写静态文字或系统参数。合并范围不能覆盖字段组件、重复标记或非左上角文字；拆分按现有合并区域的左上角定位，不能拆分包含组件的区域。修改单元格样式始终保留原有的字段组件关联。完整示例见[网格配置示例](../../../../assets/form-template/style-templates-advanced-grid-example.json)。
 
+**表单标题下边框**：先用 `headerTitle: "formTitle"` 放置标题；若 `headerTitlePlacement: "content"`，双列六列网格中的标题位于第 0 行，合并范围为第 1–4 列（`spans` 中 `row: 0, col: 1, colCount: 4`）。要让蓝色下边线覆盖整个标题宽度，在 `grid.main.cells` 中对这四个列坐标逐格设置同样的 `borders.bottom`：
+
+```json
+{
+  "headerTitle": "formTitle",
+  "headerTitlePlacement": "content",
+  "grid": {
+    "main": {
+      "cells": [
+        { "row": 0, "col": 1, "borders": { "bottom": { "color": "#2F6FED", "line": "medium" } } },
+        { "row": 0, "col": 2, "borders": { "bottom": { "color": "#2F6FED", "line": "medium" } } },
+        { "row": 0, "col": 3, "borders": { "bottom": { "color": "#2F6FED", "line": "medium" } } },
+        { "row": 0, "col": 4, "borders": { "bottom": { "color": "#2F6FED", "line": "medium" } } }
+      ]
+    }
+  }
+}
+```
+
+上述坐标只适用于该六列结构；标题跨列变化时，按实际 `spans` 覆盖的列重算。只设置合并区域左上角的下边框，实际显示的线条会不完整。创建后应在目标表单核对视觉效果，不能仅以配置回读或不落库的布局数据预览判断边框已正确呈现。
+
 为标题和字段内容留出相同的左侧空隙时，在主表重复行的四个占位单元格分别写 `style.textIndent`。[基础双列完整模板](../../../../assets/form-template/style-templates-advanced-base-example.json)的 `layoutInfo.pageLayouts[0].config.workbook.Sheet1.cells` 中，第 4 行的第 1、2、3、4 列均设为 `2`，依次对应标题 1、字段 1、标题 2、字段 2。修改完整配置时，找到这四个单元格各自的 `style`，按所需缩进量调整 `textIndent`；不要把属性写到 `cellType` 中，也不要删掉 `cellType.comId`。重复行内的样式会随字段对迭代。分组名称也可另设缩进；行列坐标取决于模板结构，调整分组或字段排布后，应按实际网格重新定位。
 
 ## 二、组件设置

package/skill-docs/references/form/layout/template/easy.md

@@ -11,6 +11,8 @@ e10-cli form layout init-reviewed <objId> --easy-template <名称或ID> --previe
 
 应用会按简易模板重新生成整个布局。执行报告核对主网格列宽、行高以及标题／字段的底色和边框色；如需保留当前排版，先导出布局底稿。
 
+原生流程表单及公文流程的 PC 表格式布局可使用 `wf-form layout init-reviewed <formId> --easy-template <名称或ID>`，同样先 `--preview-only --out`，再以 `--preview @计划文件` 应用；指定非默认布局时加 `--layout-id`。
+
 ## 模板类型与新建
 
 - **预设模板：**平台提供 6 种系统模板，可预览，不可编辑。

package/skill-docs/references/form/layout/template/flow.md

@@ -6,6 +6,8 @@
 
 `form layout init-reviewed --style-template <名称|ID>` 会读取目标表单的布局类型，按已启用的流式模板列表解析和校验名称或 ID，再初始化表单布局。不同布局类型可能有同名模板，以目标表单的 `FLOW` 类型查询结果为准。
 
+原生流程表单及公文流程的 PC 流式布局使用 `wf-form layout init-reviewed <formId> --style-template <名称|ID>`；先传 `--preview-only --out <计划文件>`，再传 `--preview @<计划文件>`。可用 `--layout-id` 限定非默认布局。
+
 ```bash
 e10-cli form-engine layout-template catalog --kind flow --enabled-only
 e10-cli form-engine layout-template flow get <模板ID>

package/skill-docs/references/form/layout/template/template-guide.md

@@ -16,7 +16,7 @@
 4. 预览或初始化接口用于核对生成结果，**不代表模板已保存**。模板保存后回读；应用到表单后再次回读表单布局，确认结构和样式生效。
 5. 模板定义布局与外观；实际表单的业务字段和字段状态来自目标表单。图片或 Excel 还原出的实际表单布局，需映射到模板规则，不能整份作为模板保存。
 
-设计高级 PC 表格式模板时，先在**模板设置**中确定结构、网格和单元格，再用 **CSS** 调整主题、组件状态和高亮；仅在需要设计器通用属性或行为设置时补充**布局样式**。同一外观尽量在一处维护，具体配置见[高级模板](advanced.md)。
+设计高级 PC 表格式模板时，以目标效果为单位统筹各层配置：先在**模板设置**中确定重复结构、网格、合并和单元格样式，再用 **CSS** 完成主题、组件状态、高亮等网格设置无法表达的视觉效果；需要设计器通用属性或行为设置时补充**布局样式**。同一外观尽量在一处维护，但一个效果需要多个层级配合时，应把这些配置一起完成。保存后既核对模板内容，也通过应用预览和实际表单检查整体效果，不能只因某一层已设置就视为完成。具体配置见[高级模板](advanced.md)。
 
 当前 CLI 支持表格式简易模板管理、高级 PC 表格式模板的新建与编辑，以及将 PC 流式布局另存为模板。先用统一目录核对模板类别、终端、启用状态与 ID：
 
@@ -41,6 +41,8 @@ e10-cli form layout init-reviewed <objId> --easy-template <简易模板名称或
 
 命令按目标布局类型解析模板，重建该布局并独立回读。显式指定模板时，预览记录模板样式指纹；执行前会重新核对模板未变。执行报告的 `saved:true` 表示布局身份、组件和配置回读通过；`templateEffectVerified:true` 进一步表示流式模板的标题及通用样式、高级表格式模板的通用字段样式及主网格列宽，或简易模板的主网格列宽、行高、标题／字段底色及边框色，与应用后的布局一致。该核对不覆盖每个单元格及 CSS 的最终浏览器呈现，重要版式仍应打开实际表单检查。
 
+原生工作流程表单（包括公文流程绑定的原生表单）可用 `wf-form layout init-reviewed <formId>` 执行同类 PC 模板的预览和应用；指定布局用 `--layout-id`，高级表格式／流式模板用 `--style-template`，简易模板用 `--easy-template`。该流程同样在保存前核对目标、模板类型、字段配置及快照，保存后回读模板效果。详见[流程表单布局](../workflow-layout.md)。
+
 `--read-only`、`--required` 等选项控制字段状态，不属于布局模板的样式设置。
 
 ## 将已有布局另存为模板

package/skill-docs/references/form/layout/workflow-layout.md

@@ -11,7 +11,19 @@ e10-cli wf-form layout add <formId> --name "审批节点专用布局" --layout-t
 e10-cli wf-form layout init <formId> --layout-id <布局ID>
 ```
 
-`wf-form layout init` 按目标布局类型重建排版；不传 `--layout-id` 则处理默认布局。需要覆盖字段只读、必填或独占一行时，可按该命令的选项设置；只调整运行时字段属性可查看 `wf-form field-prop`，它同样会经初始化保存，应先核对当前分组、排版和目标布局。删除指定流程表单布局使用：
+`wf-form layout init` 按目标布局类型重建排版；不传 `--layout-id` 则处理默认布局。需要覆盖字段只读、必填或独占一行时，可按该命令的选项设置；只调整运行时字段属性可查看 `wf-form field-prop`，它同样会经初始化保存，应先核对当前分组、排版和目标布局。
+
+应用样式模板时，优先使用审阅式命令。它按目标 PC 布局的 `FLOW`／`EXCEL` 类型解析已启用的流式或高级表格式模板；表格式简易模板使用 `--easy-template`。预览不保存，执行前会重新核对布局、字段配置及模板样式，执行后独立回读组件和可核对的模板效果：
+
+```bash
+e10-cli wf-form layout init-reviewed <formId> --layout-id <布局ID> --style-template <模板名称或ID> --preview-only --out plan.json
+e10-cli wf-form layout init-reviewed <formId> --layout-id <布局ID> --style-template <模板名称或ID> --preview @plan.json
+# PC 表格式简易模板将 --style-template 换为 --easy-template
+```
+
+不传 `--layout-id` 时处理默认布局。当前审阅式模板应用只支持 PC；移动端仍按现有布局初始化和编辑能力操作。此命令会重建目标布局，应用后仍需检查实际页面；`templateEffectVerified` 不代表浏览器最终呈现已核对。公文流程使用同一原生流程表单 `formId` 和上述命令，其公文专属设置另行维护。
+
+删除指定流程表单布局使用：
 
 ```bash
 e10-cli wf-form layout delete <formId> <布局ID>

package/skill-docs/references/form/ref-form-fields.md

@@ -107,7 +107,7 @@
 | 关联绩效 | `Performance` | `KpiFlowComponent` | 绩效选择范围 |
 | 关联报告 | `Report` | `WorkreportComponent` | 报告选择范围 |
 | 关联考勤 | `Attend` | `AttendComponent` | `attendDateType` |
-| 关联浏览 | `Browser` / `RelateBrowser` | `RelateBrowser` | 通过 `browserType` 选择浏览子类 |
+| 关联浏览类型 | `Browser` / `RelateBrowser` | `RelateBrowser` | 必须明确具体浏览类型：系统 `browserType`，或目标环境中查询到的 `browserName` |
 | 电子发票 | `EInvoice` | `EinvoiceComponent` | 发票选择配置 |
 | 行车记录 | `DrivingRecord` | `DrivingRecord` | `defaultRows` |
 | 关联公文 | `RelateODoc` | `RelateODoc` | 公文选择范围 |
@@ -115,6 +115,8 @@
 
 #### 关联类型选型
 
+**需求明确要求“关联浏览类型”时，选择 `Browser`／`RelateBrowser`，并指定具体的浏览类型。不要因为浏览源涉及 EB 表单，就自动改选 `EBuilder`。**可用系统 `browserType`，也可查询目标环境后用 `browserName` 精确选择；只写“关联浏览”尚未确定数据源。`EBuilder` 是另一种字段类型，用于需求明确要求关联某张 EB 表单的场景。创建或修改后回读字段类型；关联浏览还应核对实际 `browserType`。
+
 | 需求语义 | 选择 |
 | --- | --- |
 | 关联电子发票 | `EInvoice` |
@@ -126,7 +128,7 @@
 | 浏览工作流定义 | `RelateBrowser`，`browserType: "workflow"` |
 | 关联业务表单或 EB 表单数据 | `RelateBrowser`，`browserType: "form"` |
 
-`FormData` 表示“关联上报”，与通用关联浏览中的表单浏览不是同一配置。`EBuilder` 用于关联明确的 EB 表单；`RelateBrowser + form` 用于通用表单浏览。
+`FormData` 表示“关联上报”，与关联浏览类型中的表单浏览不是同一配置。`EBuilder` 用于关联明确的 EB 表单；`RelateBrowser + form` 是**关联浏览类型选择了 `form` 浏览源**，不是 `EBuilder` 字段。即使浏览弹窗展示的是 EB 表单数据，也应按实际字段类型与具体浏览源选择后续配置能力。
 
 #### 关联 e-builder
 
@@ -163,6 +165,8 @@
 
 #### 通用关联浏览子类
 
+先确定要浏览的具体对象，再从下表选择 `browserType`；表外的系统类型及自定义浏览框按下一节查询后用 `browserName` 选择。不要只填写 `Browser`／`RelateBrowser` 而省略浏览源。
+
 | `browserType` | 作用 | 主要配置 |
 | --- | --- | --- |
 | `workflow` | 浏览工作流定义 | 工作流范围 |
@@ -173,13 +177,23 @@
 | `hrm_sex` | 浏览人事「性别」 | — |
 | `hrmJobcall` | 浏览人事「职称」 | — |
 
-先用 `form browser-source --keyword <关键词>` 查询当前环境的浏览数据源，再用 `browserName` 精确指定结果中的名称；CLI 创建字段时查询并写入完整 `browserType`。例如在 EB 表单的 `fields.json` 中写：
+##### 任意已开放类型与自定义浏览框
+
+上表是可直接写入 `browserType` 的常用别名，并非全部浏览源。需要使用其他系统浏览类型或自定义浏览框时，先在目标环境查询：
+
+```bash
+e10-cli form browser-source --keyword "合同类型"
+```
+
+从结果中确认准确的 `name`、`module` 和 `type`，再用 `browserName` 指定**完整且精确匹配**的名称。CLI 会按当前环境查询并写入该浏览源的实际 `id/module/type`；无需为新类型修改代码，也不要猜测或复用其他环境的 ID。查询不到或结果不符合预期时，先核对环境与浏览源名称；出现同名结果时应核对 CLI 选中的来源。此操作是创建**使用该浏览源的字段**，不创建浏览源本身。
+
+例如，在 EB 表单的 `fields.json` 中写：
 
 ```json
 {"fieldName":"合同类型","componentKey":"Browser","browserName":"CLM-合同类型","multiple":false}
 ```
 
-给已有 EB 表单追加字段可用 `form add-field <objId> <appId> 合同类型 Browser --browser-name "CLM-合同类型"`；原生流程表单对应 `wf-form add-field <formId> 合同类型 Browser --browser-name "CLM-合同类型"`。名称必须精确匹配；自定义浏览框的 ID 和类型以当前环境检索结果为准。
+给已有 EB 表单追加字段可用 `form add-field <objId> <appId> 合同类型 Browser --browser-name "CLM-合同类型"`；原生流程表单对应 `wf-form add-field <formId> 合同类型 Browser --browser-name "CLM-合同类型"`。创建后回读字段或布局组件的 `browserType`，核对名称、模块和类型。
 
 修改已有 EB 字段为关联浏览时，使用 `form edit-field <objId> <appId> <fieldId> --type Browser --browser-name "社保福利项"`。已有 Browser 字段只更换数据源时可省略 `--type Browser`；也可用 `--browser-type <系统浏览类型>` 选择内置源。改类型时必须明确指定浏览源，避免落成默认浏览源。保存后回读字段类型和布局组件中的 `browserType`，确认其名称、模块和类型。
 

package/skill-docs/references/menu/system-menus.md

@@ -2,7 +2,8 @@
 
 通过 `savePublishMenu` API 挂载系统内置页面到应用菜单。menuUrl 格式固定，禁止瞎编。
 
-> **暂不支持 H5/移动端菜单**。移动端是独立体系（不同 URL + 不同 pageId），目前尚未整理完整，禁止 AI 自行编造。
+> **移动端菜单是另一套记录**：同一个 `savePublishMenu` 接口，只把 `terminalType` 换成 `H5`；页面绑定与 `menuUrl` 与 PC 相同。菜单命令统一用 `--terminal mobile` 指定移动端（缺省 PC），两端互不影响。
+> 移动端**内置系统页**的 URL 尚未整理，不要自行编造。
 
 ---
 
@@ -85,3 +86,45 @@
 - 已建好的菜单调整：`e10-cli menu order <appId> <菜单ID或名称> --first`，或 `--show-order <n>`。
 
 命令在写完会回读：`showOrder` 必须落成请求值；`--first` 还会确认同级下标为 0。系统菜单不允许调整顺序。
+
+---
+
+## 打开方式
+
+菜单点击后在哪儿打开，由 `navigation.openMode` 决定：
+
+| 界面选项 | 值 |
+|---|---|
+| 默认窗口（缺省） | `1` |
+| 新窗口 | `2` |
+
+- 新建时指定：`menu add / add-table / add-start`、`page publish-menu` 加 `--open-mode new-window`。
+- 已建好的菜单：`e10-cli menu open-mode <appId> <菜单ID或名称> new-window`（改回用 `default`）。
+- 上级目录（空链接）没有页面，设置打开方式没有意义，命令会拒绝。
+- 改完回读打开方式，并确认名字、页面、链接等其它字段一个都没动。
+
+---
+
+## 可见范围（两栏）
+
+「可见范围」弹窗其实是**两栏**，各自一套授权对象：
+
+| 界面栏位 | 存储差异 |
+|---|---|
+| 可见 | `permissionType = 1` |
+| 可见范围内禁用 | `permissionType = -1` |
+
+两栏的写报文除这个字段外完全相同，所以命令必须显式分清栏位：
+
+```bash
+# 只让某部门可见（自动撤掉「所有人」）
+e10-cli menu permission add <appId> <menuId> 营销部 --type dept
+
+# 在可见人群里排除某人
+e10-cli menu permission add <appId> <menuId> 张三 --type user --scope disabled
+
+# 查看两栏
+e10-cli menu permission list <appId> <menuId>
+```
+
+授权对象五类：人员 `user` / 部门 `dept` / 角色 `role` / 岗位 `position` / 所有人 `all`。命令写完回读**同一栏**确认生效。

package/skill-docs/references/workflow/guide-workflow-odoc.md

@@ -27,7 +27,7 @@ e10-cli workflow create-workflow "公文审批流程" --odoc --form-id <formId>
 ## 完整搭建顺序
 
 1. 使用 `workflow create-workflow --odoc` 创建流程并取得 `workflowId`、`formId`。
-2. 使用 `wf-form` 创建主表字段、明细表及布局，先准备公文设置要引用的标题、正文、文号、目录区分等字段。
+2. 使用 `wf-form` 创建主表字段、明细表及布局，先准备公文设置要引用的标题、正文、文号、目录区分等字段。公文流程绑定的是原生流程表单，布局新建、编辑、模板应用和布局 JS/CSS 使用[流程表单布局指南](../form/layout/workflow-layout.md)中的同一组能力；PC 模板应用可用 `wf-form layout init-reviewed` 先预览后执行。
 3. 使用通用 `workflow` 命令配置节点、操作者、出口、条件、会签、退回、超时、消息、编号及动作流。
 4. 使用 `workflow odoc setting get <workflowId>` 读取当前环境提供的公文设置分组、字段候选项、节点候选项及默认值。
 5. 按需求使用 `workflow odoc setting set` 配置公文专属内容；字段选择使用字段 ID，节点选择可使用名称或 ID。