weaver-e10-builder 1.5.1 → 1.5.3

package/skill-docs/references/form/guide-form-physical-table.md

@@ -0,0 +1,146 @@
+# 多物理表（一个表单的字段分散到多张物理表）
+
+设计器里「表单 → 字段管理」有三个页签：**主表 | 明细表 | 其他**。本文说的是**「其他」** —— 同一个表单的字段分散在多张**物理表**上。
+
+## 什么时候用
+
+**字段数过多时的容量兜底**（单表字段超过 100 个左右）。正常表单用不到，属于偶尔一用的结构级能力。业务上要「一行对多行」请用**明细表**，那是另一回事（见 `guide-form-sub-detail.md`）。
+
+## ⚠ 和「明细表」是两根轴，别混
+
+| | 明细表 | **物理表（本文）** |
+|---|---|---|
+| 建表命令 | `form add-detail-table` | **`form add-physical-table`** |
+| 加字段命令 | `form add-field --sub-form-id` | **`form add-physical-field`** |
+| 建表端点 | `saveSubForm` | **`saveFormTable`** |
+| 标志 | `isSubForm: true` | **`isSubForm: false`** |
+| `tableType` | `MAIN` | **`SUBSIDIARY`** |
+| 布局里 | `DetailTable` 组件 | 无（不自动进布局，见下） |
+| 语义 | 一对多业务建模 | 一个表单自己的字段拆到多张表 |
+
+## 命令
+
+```shell
+# 1) 列出表单的全部物理表（含主表）—— 忘掉 formTableId 时就用它
+e10-cli form physical-table list <objId> <appId>
+
+# 2) 建一张附属物理表 —— 输出 formTableId，后面都要用它
+e10-cli form add-physical-table <objId> <appId> \
+  --name 物理表A \
+  --table-name uf_ryxxb_6_1
+
+# 3) 往那张表里加字段（任意类型，能力同 form add-field）
+e10-cli form add-physical-field <objId> <appId> <formTableId> <字段名> <类型> [标题] [选项]
+
+# 4) 改名
+e10-cli form rename-physical-table <objId> <appId> <formTableId> \
+  --name 新名字 --table-name uf_ryxxb_6_1
+
+# 5) 删除（可一次删多张；表里的字段一并删除，不可逆）
+e10-cli form delete-physical-table <objId> <appId> <formTableId...>
+```
+
+`add-physical-field` 的选项与 `form add-field` 同名同义（`--precision` / `--format` / `--default` / `--data-key` / `--column-name` / `--multiple` / `--option-template` / `--browser-type` / `--sform-id` …）—— 两者**共用同一份字段构造器**，所以字段形状是同一套，不存在「这个命令能建那个命令不能建」的差异。
+
+| 参数 | 说明 |
+|---|---|
+| `--name <名>` | 物理表**显示名**，设计器里那排 chip 上的字 |
+| `--table-name <名>` | **数据库表名**（如 `uf_ryxxb_6_1`）。⚠ 平台的建议命名规则未抓到报文，**必填**；改名时也要原样回传 |
+
+## 表 id 从哪来
+
+建表输出里就带着：
+
+```
+物理表已建: 物理表A  formTableId=1323895867900731392  tableName=uf_ryxxb_6_1
+```
+
+事后想找回，用 `form physical-table list`（走 `getFormAGroupList`，就是设计器那排 chip 的数据源）：
+
+```
+$ e10-cli form physical-table list 1323898521989193728 1323897873591762945
+表单 1323898521989193728 共 3 张物理表:
+  多物理表测试表单  [主表]  formTableId=1323898521989193731  库表=uf_dwlbcsbd_5766  字段2
+  表1  [附属]  formTableId=1323898595055067136  库表=uf_dwlbcs_t1  字段3
+  表2  [附属]  formTableId=1323898612300947456  库表=uf_dwlbcs_t2  字段3
+```
+
+⚠ 注意这只列**物理表**。`form detail-table list`（走 `querySubForms`）是另一回事，只列**明细表**。
+
+字段**归属**也随时可读：`form read <objId> --app-id <appId>` 每个字段后面会带 `· 物理表: 表1`。
+
+> 读 `getFormAGroupList` 时别碰那条记录里的 `id` 键 —— 它是 **formId**，`formTableId` 才是表 id。这个子系统里 `id` 反复是这个陷阱。
+
+## ⚠ `add-physical-field` **不碰布局**
+
+字段建在这张物理表上，但**不会自动进表单布局**——它是否需要在布局里出现、怎么放，尚未抓到报文。别默认它已经挂在表单上了；要不要进布局请在设计器里确认。
+
+（`form add-field` 会做布局插入，是因为它落在主表/明细表这些**本来就在布局里**的落点上。）
+
+## 报文契约
+
+### 建表 / 改名 —— 同一个端点，带不带 `id` 决定是哪种
+
+```
+POST /api/ebuilder/form/form/field/manage/saveFormTable?apid=<appId>
+header ebbusinessid: <formId>
+```
+
+```json
+{"module":"ebuilderform",
+ "formTable":{"id":"<表id：改名时带，新建时不带>",
+              "name":"物理表A",
+              "tableName":"uf_ryxxb_6_1",
+              "tableType":"SUBSIDIARY",
+              "form":{"id":"<formId>"},
+              "otherProperties":"{}"},
+ "customParam":{"appId":"...","objId":"..."}}
+```
+
+响应：`{"code":200,"status":true,"data":{"formTableId":"..."}}` —— 新表的 id 在 `data.formTableId`。
+
+### 加字段 —— **不是**批量端点
+
+```
+POST /api/ebuilder/form/form/field/manage/saveFormFieldNew
+body {"formId":...,"module":"ebuilderform","jsonObj":"{... 带 \"formTableId\":\"<表id>\" ...}"}
+```
+
+字段落点由 **jsonObj 里的 `formTableId`** 决定。这条与「建表时连字段一起建」的 `batch/save/formField` + `formTableList` **不是同一条路**。
+
+### 删表
+
+```
+POST /api/ebuilder/form/form/field/manage/deleteFormTable?apid=<appId>
+body {"module":"ebuilderform","formId":"<formId>","ids":["<表id>"],"customParam":{...}}
+```
+
+### 列表（`form physical-table list`）
+
+```
+POST /api/ebuilder/form/form/field/manage/getFormAGroupList?apid=<appId>
+body {"module":"ebuilderform","formId":"<formId>","customParam":{...}}
+```
+
+响应 `data.formList[]` 每条：`name`（显示名）/ `tableName` / `tableType`（`MAIN` | `SUBSIDIARY`）/ `formTableId` / `systemTable` / `dataCount`；
+另外 `data.groupList[]` 是字段分组。**主表也在 `formList` 里**（`tableType: MAIN`）。
+
+⚠ 记录里的 `id` 键是 **formId**，不是表 id。
+
+## 踩过的两条坑（都别再走）
+
+**1. 不能把已有字段搬到另一张表。** 试过把字段的 `formTableId` 改成新表再整份写回，平台明确拒绝：
+
+```
+【备注】此字段不属于当前物理表，不能更改位置
+```
+
+所以**别指望「字段超 100 之后把老字段挪走」**——至少这条路径不行。能做的只有：**一开始就把新字段建到新表上**。这也解释了设计器的真实用法：先建附属表，后续新增的字段直接落在它上面。
+
+**2. 平台会对形状不认的字段回 `200` 但静默不落库。** 在 `batch/save/formField` 那条路上，`DateTime` / `Percent` / `Browser` 三种就是这样——接口回成功，字段根本没建出来。所以 `add-physical-field` **每次写完都回读确认**，「接口回 200」不等于「建上了」。带配置的类型（如 Select 的选项）建完再用对应命令补。
+
+## 注意事项
+
+1. **删除不可逆**，表里的字段一并删除。执行前先确认表 id。
+2. **`--table-name` 必填**。设计器用的是 `uf_<表单名拼音>_<n>_<m>` 这类命名，但规则没抓到报文，CLI 不替你猜 —— 重名/非法由平台报错（`此表的数据库表名称与数据库现有表存在冲突`）。
+3. **建完的空表照样存在**于「其他」页签里；要清掉用 `delete-physical-table`。

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

@@ -42,7 +42,7 @@
 | 数字 | `Number` | `precision`、`delimiter`、`percent`、`capital` |
 | 金额 | `Money` | `precision`、`delimiter`、`capital` |
 | 开关 | `Switch` | 开关值 |
-| 附件 | `FileComponent` / `Attachment` | 附件上传设置 |
+| 附件 | `FileComponent` | 附件上传设置（**没有 `Attachment` 这个类型名**） |
 | 图片 | `Image` | 图片上传设置 |
 | 语音 | `AudioRecord` | 语音录制与上传 |
 | 视频 | `VideoRecord` | 视频录制与上传 |

package/skill-docs/references/hrm/guide-org-employee.md

@@ -9,6 +9,16 @@
 |------|------|
 | `e10-cli org employee template [--out <路径>]` | 导出人员导入模板（xlsx）。默认输出到当前目录的 `人员导入模板.xlsx` |
 | `e10-cli org employee import <file>` | 从 Excel 导入人员。`--dry-run` 只预览不导入；`--mode add\|update`（默认 `add`）；`--find-by <字段>`（更新时按哪个字段认人，默认 `username`）；`--review <n>` 预览行数（默认 100） |
+| `e10-cli org employee task <taskId>` | 查某个导入任务的结果（没等、或等超时了，用这个补看） |
+
+导入默认**等结果**：打完 `已导入 N 条 / 失败 M 条` 才结束，**有失败行时退出码非 0**，脚本可以直接判。
+
+| 选项 | 说明 |
+|---|---|
+| `--no-wait` | 提交后立刻返回。⚠ 不等就等于不校验 —— **「已提交」不代表导入成功**，要自己再用 `task` 查 |
+| `--wait-timeout <ms>` | 等结果的超时（默认 60000）。超时不编成功，如实报「仍在处理中」并给 taskId |
+| `--error-file <路径>` | 失败数据的保存路径。默认与源文件同目录、同名 + `.错误数据.xlsx` |
+| `--no-error-file` | 不保存失败数据文件（原因仍会打出来） |
 
 ## ⚠ 先 `--dry-run`，再真导
 
@@ -34,19 +44,77 @@ e10-cli org employee import 人员.xlsx --dry-run
 | ④ | `POST /api/ebatch/uploadFileId` | `taskId` |
 | ⑤ | `POST /api/ebatch/getExcelData` | 预览行（**不落库**） |
 | ⑥ | `POST /api/ebatch/importExcelData` | 真正执行 |
+| ⑦ | `POST /api/ebatch/getByTaskId` | **导入结果**：条数 / 失败原因 / 错误文件 |
 
 - **⓪ 把 ④ 要的元数据全给了** —— moduleName / functionName / handlerName / serviceName / dataType
   都不是 CLI 硬编码的，`bizId` 更是每次调用现生成。
 - **①② 的 multipart 字段逐字相同**，② 只多 `preUploadId` 与 `uploadType=common`。
-- ⑤⑥ 的参数全在 **query string**，body 为空。
+- ⑤⑥⑦ 的参数全在 **query string**，body 为空。
+
+## 导入结果（⑥ 只是「提交了」，结论在 ⑦）
+
+**⑥ 的响应体只有一个 `true`** —— 条数、失败原因、错误文件**全都不在里面**。只发 ⑥ 就报成功，
+会让**整批失败也显示成「导入已提交」**，所以命令发完 ⑥ 会去轮询 ⑦。
+
+```json
+{"status": -1,
+ "msg": "存在错误数据，下载错误文件查看",
+ "callbackData": "{\"msg\":\"导入失败\",\"errorFileId\":\"...\",\"module\":\"hrm\",\"successCount\":0,\"errorCount\":\"1\"}"}
+```
+
+- **`callbackData` 是一个 JSON 字符串**，要二次解析 —— 条数和错误文件 id 都在里面。
+- ⚠ **`successCount` 是数字、`errorCount` 是字符串**（`1` / `"0"`），同一段 JSON 里类型不一致，两边都得转一遍。
+- ⚠ **`status: 0` 不是「成功」** —— 它是个**中途值**：同一个任务先读到 `status: 0` + `msg: 成功`、
+  `callbackData` 还是空的，几秒后才落成 `-1` + 失败 1 条。**判完成的依据是 `callbackData` 能不能解出来，不是 `status`**；
+  按 `status` 收工就会把失败读成成功。
+- `status: -1` = 存在错误数据，可以直接当终态（命令也这么处理）。
+
+### 失败原因在**单元格批注**里，不在任何一列
+
+导出的失败数据文件里**只有出错的那几行，没有「原因」列** —— 用表格软件打开看值，看不出为什么失败。
+原因挂在**出错单元格的批注（Excel comment）**上，形态是：
+
+| 单元格 | 值 | 批注 |
+|---|---|---|
+| A2 | 人员A | **姓名 重复** |
+
+所以 `import` / `task` 会把批注读出来直接打给你：
+
+```
+导入结果: 人员A.xlsx
+  已导入     0 条
+  失败       1 条
+  平台说明   存在错误数据，下载错误文件查看
+  失败原因
+    第 2 行 · 姓名（人员A）: 姓名 重复
+  失败数据   1323916251655815168 → 人员A.错误数据.xlsx
+```
+
+### 失败数据怎么下来的
+
+```
+GET /api/file/remotedownload/<fileId>/token/true?authModule=ebatch
+  → 302 → 对象存储的签名地址（文件真身在这边，文件名也在这一步给）
+```
+
+下载按**两步**取：先带鉴权拿到 302，再**不带任何鉴权头**去对象存储取字节 ——
+会话凭证不跟着跳转发到第三方域名上。
 
 ## 几个坑
 
-- **取 id 的层级三步三样**：① 在 `data.uploadModuleDto.fileid`、② 在 `data.fileid`（**小写 d**）、
-  ④ 在 `data.data.taskId`（多一层）。照着别的接口的写法套会静默取到空。
+- **取 id 的层级三步三样**：① 在 `data.preUploadId`（**有的环境**是 `data.uploadModuleDto.fileid`）、
+  ② 在 `data.fileid`（**小写 d**）、④ 在 `data.data.taskId`（多一层）。照着别的接口的写法套会静默取到空。
+- **① 的返回形状随环境变**：有的环境 `preUploadCheck` 只回 `data.preUploadId`
+  （`data` 下就 `preUploadId` / `uploadType` / `permissionType` 三个键，**没有** `uploadModuleDto`）。
+  两种写法语义相同，命令都认；一个都没有才报错。只认其中一种的话，那条环境整条导入链**第①步就断**。
 - **⑤ 的参数是 `rerviewNum`** —— 平台把 review 拼错了，别"顺手改正"成 `reviewNum`。
 - **`weaTable[0].total` 是 `-1`**，不能拿来当行数；行数看 `data` 数组长度。
 - **`rerviewNum` 只是一次取多少行**，预览到的未必是全部 —— 行数刚好等于上限时命令会提示。
+- **⚠⚠ 分部名写错不会报错 —— 平台会静默新建一个分部，把人放进去。**
+  「分部（必填）」填一个机构里不存在的名字（例如把「泛微北京」写成「泛微北金」），导入**照样回成功**，
+  然后机构里会多出一个同名分部（父级 = 操作者所在组织），人落在里面。**没有报错、没有警告**，
+  `--dry-run` 的预览也看不出来 —— 预览只是把单元格原样回显，**不做任何校验**。
+  所以：**分部名必须是机构里已有的名字**，导之前自己核一遍 —— 一次手误就是一条脏组织数据 + 一个错位的人。
 - **模板里的示例行**（`user001`~`user008`）是平台放的演示数据，**导入前务必删掉**，否则会被当成真人建进去。
 - **`importType` 在 ④ 的报文里出现两次**：顶层是空串、真正生效的在 `uploadSet.customObj` 里。
 

package/skill-docs/references/report/cell-config-echo-guide.md

@@ -28,7 +28,7 @@
 **指纹示例**：`formatterType[0] + '|' + formatter + '|' + font + '|' + backColor`
 相同指纹 → 直接复用已通过的 style 对象引用（或深拷贝），**不再**走 JSON 样例确认。
 
-## 二、数字格式目录（工具栏回显金标准）
+## 二、数字格式目录（工具栏回显参照）
 
 > 来源：设计器静态资源 `main.js` 中格式下拉 `g()` 目录。`￥` 为全角 `U+FFE5`（JSON 中写 `\uFFE5`）。
 

package/skill-docs/references/report/dataset-query-filter-guide.md

@@ -1,7 +1,7 @@
 # 数据集筛选（queryInfoSave）API 写入规范
 
 > **适用场景**：设计器左侧「数据集 → 筛选条件」、行级数据权限、整表预过滤。 
-> **金标准报表**：`1304979556231593985`（EBU 经营数据统计） 
+> **参考报表**：`1304979556231593985`（EBU 经营数据统计） 
 > **代码实现**：`本地工作目录` → `build_*_dataset_query_filter()` / `ensure_*_dataset_filter()` 
 > **执行**：`python 本地工作目录`
 
@@ -160,7 +160,7 @@ def _build_compare_form_field(origin_field):
 
 ---
 
-## 七、EBU 金标准示例
+## 七、EBU 参考示例
 
 报表 `1304979556231593985`
 
@@ -186,7 +186,7 @@ rootStr：`( 负责人姓名 等于 '{lastname}' ) AND ( 创建者 等于 '{user
 
 rootStr：`(( 核算机构 不等于合同种类 ) 或 ( 创建时间 开头包含 '{thisyear}' ))`
 
-### 7.3 历史验证过的其他写法（按需）
+### 7.3 其他可用写法（按需）
 
 | 场景 | func | value |
 |------|------|-------|

package/skill-docs/references/report/date-range-query-reference.md

@@ -1,6 +1,6 @@
 # 日期区间查询条件选项参考（已验证样例）
 
-> **金标准来源**：报表 `1304979556231593985`（EBU 经营数据统计）· 查询条件「入职时间」 
+> **来源**：报表 `1304979556231593985`（EBU 经营数据统计）· 查询条件「入职时间」 
 > **完整规范**：`query-condition-api-guide.md`（条件字段形态、系统参数默认值、验证清单） 
 > **filterParam 快照**：`outputs/join_date_filterparam.json`（运行 `本地工作目录` 可重新导出） 
 > **代码实现**：`本地工作目录` → `_default_date_filter_param()`
@@ -97,6 +97,6 @@
 | 文件 | 用途 |
 |------|------|
 | `query-condition-api-guide.md` | 查询条件总规范 |
-| `outputs/join_date_filterparam.json` | filterParam 金标准 |
+| `outputs/join_date_filterparam.json` | filterParam 参考样本 |
 | `本地工作目录` | 生成/修复 |
 | `本地工作目录` | 扫描导出 |

package/skill-docs/references/report/query-condition-api-guide.md

@@ -1,7 +1,7 @@
 # 查询条件 API 写入规范
 
 > **适用场景**：通过 `saveQueryItem` / `saveQueryConfig` API 或脚本添加、修复报表查询条件。
-> **金标准报表**：`1304979556231593985`（EBU 经营数据统计）
+> **参考报表**：`1304979556231593985`（EBU 经营数据统计）
 > **代码实现**：`本地工作目录` → `ensure_query_conditions()`；执行 `python 本地工作目录`
 > **核心规则**：数据集合选取后，**选择类型未特别指定 SQL 时，一律默认为「条件字段」**。
 
@@ -43,7 +43,7 @@
 
 ## 二、条件字段标准形态（saveQueryItem）
 
-设计器 save 后回读的金标准结构：
+设计器 save 后回读的基准结构：
 
 | 字段 | 条件字段正确值 |
 |------|----------------|
@@ -118,7 +118,7 @@ await saveQueryItem({ reportId, queryItems: '{}' }); // conditions 缺失 → 50
 
 ### 2.1 显示方式（强制 · 不可不选）
 
-> **✅ 终局定案（2026-09-11 · 以「设计器手工配置的真实条件」为金标准反推）**
+> **✅ 终局定案（2026-09-11 · 以「设计器手工配置的真实条件」为基准反推）**
 >
 > 条件级「显示方式」的正确落库值是 **JSON 数组字符串**：
 >
@@ -278,7 +278,7 @@ Content-Disposition: form-data; name="queryItems"
 | 条件级与报表级是两个独立字段，互不影响 | ❌ 错。`updateQueryType` 用 `queryType` **批量覆盖所有条件**（§2.1.3 真正根因） |
 | `updateQueryType` 只改报表级「高级搜索显示形式」 | ❌ 错。它会把入参写进每条条件 → 长码一键摧毁全表回显 |
 
-**旧结论怎么来的 / 为什么错**：早期用 JS 合成事件点击条件 tag，实际点到了**左侧字段面板**的「显示方式」（那是字段属性，非条件显示方式），读取勾选态得到假信号；且未把「人工配置的条件」作为金标准对照。**修复方式**：改用 **CDP `Input.dispatchMouseEvent` 真实鼠标事件**点条件 tag，读「编辑查询条件」弹窗，并以人工条件为参照。
+**旧结论怎么来的 / 为什么错**：早期用 JS 合成事件点击条件 tag，实际点到了**左侧字段面板**的「显示方式」（那是字段属性，非条件显示方式），读取勾选态得到假信号；且未把「人工配置的条件」作为基准对照。**修复方式**：改用 **CDP `Input.dispatchMouseEvent` 真实鼠标事件**点条件 tag，读「编辑查询条件」弹窗，并以人工条件为参照。
 
 **真正根因的发现路径**：给 `save` 加「落库后回读自检」时，发现**刚写入的数组被回读成长码** → 隔离实验证明只有 `saveQueryItem` 时数组完好，一旦再调 `updateQueryType` 即被批量覆盖 → 穷举入参证明 `updateQueryType` 是「全表条件 `queryType` 批量写」。**AI 自检回读是抓到它的关键手段**，务必保留。
 
@@ -297,7 +297,7 @@ e10-cli report query fix-echo <reportId> --app-id <appId>   # 长码/空值 →
 e10-cli report query verify <reportId> --app-id <appId> --fix # 体检 Q1~Q10 + 幂等修复
 ```
 
-**设计器真实保存形态（金标准，从 `saveQueryItem` 实际请求）**
+**设计器真实保存形态（基准，从 `saveQueryItem` 实际请求）**
 
 ```json
 {
@@ -339,7 +339,7 @@ e10-cli report query verify <reportId> --app-id <appId> --fix # 体检 Q1~Q10 +
 | 唯一功能读点 | `SheetServiceImpl`：取**第一条**高级搜索条件的 `advancedSearchType`，`=='openCondition'` → `isOpenCondition=true` |
 | 页面效果 | `isOpenCondition=true` → 报表页查询区**展开铺开**（「展开条件」）；否则 → **默认样式**（右上角搜索图标，点击才展开） |
 | 设计器入口 | 报表级「查询设置」弹窗的 **高级搜索显示形式：默认样式 / 展开条件** |
-| 人工条件（金标准） | **该键不存在**（`undefined`），平台不主动写 |
+| 人工条件（基准） | **该键不存在**（`undefined`），平台不主动写 |
 
 **硬规则**
 
@@ -438,7 +438,7 @@ e10-cli report fix query-default --report-id <id> --app-id <appId> --all --show-
 
 > **事故**：同报表查询条件「销售部门」绑定字段 `originFieldType=Department`，但设计器关联类型显示为空/默认**人员**。**定案根因：`browserType` 写成了简写 `[{"id":"HrmDepartmentComInfo"}]`，缺少 `name`/`type` 等字段 → 前端无法解析显示名 → 退回默认「人员」标签页。**
 
-**设计器真实形态（金标准）**：`browserType` 是 **全字段富对象数组**，关键字段 `name`（显示名）、`type`（`department`/`employee`）、`module`、`groupId`、`tenantKey`、`dataId`、`labelId`、`id`。**`browserTypeStr` 才是落库判据**（服务端存 `[{"id":"HrmDepartmentComInfo"}]` 形式的字符串）。
+**设计器真实形态（基准）**：`browserType` 是 **全字段富对象数组**，关键字段 `name`（显示名）、`type`（`department`/`employee`）、`module`、`groupId`、`tenantKey`、`dataId`、`labelId`、`id`。**`browserTypeStr` 才是落库判据**（服务端存 `[{"id":"HrmDepartmentComInfo"}]` 形式的字符串）。
 
 | 字段 `originFieldType` | `displayType` | `browserTypeStr`（落库） | 设计器关联类型 |
 |------------------------|---------------|--------------------------|----------------|
@@ -490,7 +490,7 @@ queryType 以 "[" 开头 → 数组 → UI 勾选正常 ✅
 queryType 是其它字符串 → 退化 → UI 不勾选 ❌（改写为 '["advance"]'）
 ```
 
-> 复现路径存档：前端 bundle 经 CDP `Debugger.getScriptSource` 导出至 `本地工作目录`
+> 来源：前端 bundle 经 CDP `Debugger.getScriptSource` 导出至 `本地工作目录`
 > （`route_DatasetList.js` 179879B / `route_ReportDesigner.js` 702877B / `lib.js` 661658B）；
 > UI 回显用 `_q_real2.py`（CDP `Input.dispatchMouseEvent` 真实鼠标点击条件 tag + 读「编辑查询条件」弹窗 checkbox）。
 
@@ -579,7 +579,7 @@ POST /api/bs/edc/report/saveQueryItem (multipart: reportId + queryItems 单对
 | 3 | `conditions` | **非 null 数组**，至少 1 个 `{dataSetId, fieldId, relation}` |
 | 4 | Header | `ebBusinessId` = 报表所属 **appId**；`eteamsid` + Cookie |
 | 5 | 多条条件 | **多次** POST，每次一条；不要一次塞数组 |
-| 6 | 对照金标准 | 先 `getQueryItem` 拉已有报表一条，改 `text`/`fieldId` 再 save |
+| 6 | 对照基准 | 先 `getQueryItem` 拉已有报表一条，改 `text`/`fieldId` 再 save |
 
 **不要**：为排 500 去开浏览器扫页（浪费）；先按上表自检。仍 500 时看响应 `msg` 是否权限/报表不存在，再问用户。
 
@@ -803,7 +803,7 @@ function inferQueryDisplay(text, fieldMeta) {
 
 ## 七、数据集筛选（设计器左侧 · 行级权限）
 
-> **完整规范已独立成文**：`dataset-query-filter-guide.md`（func 对照、字段对比、日期 format、AND/OR、EBU 金标准、验证清单）。
+> **完整规范已独立成文**：`dataset-query-filter-guide.md`（func 对照、字段对比、日期 format、AND/OR、EBU 参考样本、验证清单）。
 > 本节仅保留与高级搜索的边界说明。
 
 **与高级搜索不同**：设计器左侧数据集右键「筛选条件」走 **`queryInfoSave` / `queryInfoGet`**（`conditionData` + `otherData`），**不是** `saveQueryItem`。
@@ -886,5 +886,5 @@ function inferQueryDisplay(text, fieldMeta) {
 | `report-building-guide.md` §6 | 设计器操作步骤 |
 | `report-config-schema.md` §五 | Schema 摘要 |
 | `SKILL.md` §6.3–§6.4 | Agent 步骤入口 |
-| `outputs/join_date_filterparam.json` | filterParam 金标准 |
+| `outputs/join_date_filterparam.json` | filterParam 参考样本 |
 | `本地工作目录` | 生成/修复实现 |

package/skill-docs/references/report/report-designer-feature-map.md

@@ -488,7 +488,7 @@ pageNo=1&pageSize=10&dateRange=["",""]&sheetId=<reportId>&versionName=&creators=
 | `designKey` | 设计器会话 UUID |
 | `pageSetting` | JSON 数组，含 `split`（分页/分栏）、`scrollPage` 等 |
 
-### 11.4 复现实际请求
+### 11.4 对照实际请求
 
 ```bash
 cd 本地工作目录

package/skill-docs/references/report/report-permission-guide.md

@@ -75,7 +75,7 @@ flowchart TB
 | 外部联系人 | `external` | `obj_id_external` | `external` | `7` | 外部人 ID | 须 browser 查真实 ID |
 | 所有外部人 | `allExternal` | （无） | `allExternal` | `12` | `0` | 无对象选择框 |
 
-> **targetType 金标准**（`edc_report_ph_report_view` 的 `org_config.typeEnum`，weaver-edcreportd SQL）：
+> **targetType 判断依据**（`edc_report_ph_report_view` 的 `org_config.typeEnum`，weaver-edcreportd SQL）：
 > 人员 `1|17` · 部门 `2|3|4|…` · 分部 `5|6|7|…` · **角色 `10`** · **群组(channel) `14|1411`** · 岗位 `12|13|…` · 外部 `110` · 所有人 `11`
 > 写入前务必 `table/list/new` 回读；**禁止**把角色写成 `targetType:3`、群组写成 `targetType:5`（会分别落库为部门/分部）。
 > **安全级别**：通用项均可带 `seclevel: {"min": -999, "max": 999}`（UI「安全级别」列）。
@@ -272,7 +272,7 @@ Content-Type: application/json
 ]
 ```
 
-> **矩阵字段 JSON 结构**因「矩阵表 vs e-Builder 表单」及租户配置而异，**必须以设计器 Network 实际请求为金标准**；Skill 禁止臆造 `matrixConditionData` / `matrixValueRelation` 内部键名。
+> **矩阵字段 JSON 结构**因「矩阵表 vs e-Builder 表单」及租户配置而异，**必须以设计器 Network 实际请求为准**；Skill 禁止臆造 `matrixConditionData` / `matrixValueRelation` 内部键名。
 
 ---
 

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

@@ -83,7 +83,7 @@ e10-cli workflow odoc setting set <workflowId> --config @odoc-setting.json
 |---|---|---|---|
 | 公文类型 | `officialType` | `1` 发文、`2` 收文、`3` 签报 | **CLI 已支持**：`--official-type 1|2|3` 或 JSON |
 | 流程标题 | `requestTitleField` | 单行或多行文本字段 | **CLI 已支持**：`--request-title-field <字段名或ID>` |
-| 正文字段 | `flowDocField` | 单选文档浏览框，候选项以 `setting get` 为准 | **CLI 部分支持**：JSON 写字段 ID，尚未实测非空字段 |
+| 正文字段 | `flowDocField` | 单选文档浏览框，候选项以 `setting get` 为准 | **CLI 部分支持**：JSON 写字段 ID，非空字段尚未验证 |
 | 正文标题 | `documentTitleField` | 单行或多行文本字段；`-102` 表示流程名称（系统） | **CLI 已支持**：JSON 写字段 ID 或 `-102` |
 | 默认存放目录 | `defaultCat` | 文档目录 | **CLI 未支持**：待补充目录查询和非空保存结构 |
 | 目录区分字段 | `flowDocCatField` | 表单选择字段 | **CLI 已支持**：JSON 写字段 ID |
@@ -132,10 +132,10 @@ e10-cli workflow odoc setting set <workflowId> --config @odoc-setting.json
 - `editTextInForm`：允许在表单中直接编辑正文。**CLI 已支持**：JSON。
 - `showTextNewColumn`：正文分栏显示。**CLI 已支持**：JSON。
 - `columnPosition`：正文位置，`1` 左侧、`2` 右侧。**CLI 已支持**：`--column-position`。
-- `textColumnSize`：正文栏占比。**CLI 部分支持**：JSON 可写；启用附件区后实测可能保留原值，须以回读为准。
+- `textColumnSize`：正文栏占比。**CLI 部分支持**：JSON 可写；启用附件区后可能保留原值，须以回读为准。
 - `openTextInFormSelect`、`openTextInFormNode`：正文显示应用节点，`1` 全部、`2` 选择。**CLI 已支持**：JSON 写节点 ID。
 - `showAttributeTab`：正文页面显示文档属性页签。**CLI 已支持**：JSON。
-- `reupload`：发起节点允许重新上传。**CLI 未支持**：实测写入后仍为关闭。
+- `reupload`：发起节点允许重新上传。**CLI 未支持**：写入后仍为关闭。
 - `reUploadSelect`、`reUploadNode`：允许重新上传正文的节点。**CLI 已支持**：JSON 写节点 ID。
 - `canChangeEditMould`：发起节点允许更换编辑模板。**CLI 已支持**：JSON。
 
@@ -150,7 +150,7 @@ e10-cli workflow odoc setting set <workflowId> --config @odoc-setting.json
 ## 其他设置
 
 - `extFileToDoc`：流程附件转为正文附件。**CLI 已支持**：JSON。
-- `extFileToDocSelect`：选择转为正文附件的字段。**CLI 部分支持**：可写字段 ID，待实测字段选择结构。
+- `extFileToDocSelect`：选择转为正文附件的字段。**CLI 部分支持**：可写字段 ID，字段选择结构待补。
 - `keepExtFile`：保留流程附件。**CLI 已支持**：JSON。
 - `defaultDocType`：默认文档类型。**CLI 部分支持**：可写类型值，待补充码表。
 - `printNodeSelect`：打印正文节点。**CLI 部分支持**：可写节点 ID，待补充完整选择结构。
@@ -205,7 +205,7 @@ e10-cli workflow odoc setting set <workflowId> --config @odoc-setting.json
 - `attachOpenDirection`：`1` 左侧、`2` 右侧。**CLI 已支持**：`attachmentArea` JSON。
 - `attachOpenNodeSelect`、`attachOpenNode`：默认展开节点。**CLI 已支持**：JSON 写节点 ID。
 - `attachProportion`：附件区占比。**CLI 已支持**：JSON 写百分比数值。
-- `odocProportion`：正文栏占比。**CLI 部分支持**：JSON 可写；启用附件区后实测可能保留原值，须以回读为准。
+- `odocProportion`：正文栏占比。**CLI 部分支持**：JSON 可写；启用附件区后可能保留原值，须以回读为准。
 - `allowAddFile`：允许上传新附件或添加新文档。**CLI 已支持**：JSON。
 - `attachSelect`、`attachField`：附件区展示字段。**CLI 部分支持**：选择范围可写，字段结构待补充。
 - `subscriptOpen`：启用角标。**CLI 已支持**：JSON。
@@ -225,7 +225,7 @@ e10-cli workflow odoc setting set <workflowId> --config @odoc-setting.json
 - `showAiOdoc`：启用公文助手。**CLI 已支持**：`--ai-odoc`。
 - `showOfficialDoc`：启用事务公文。**CLI 已支持**：JSON。
 - `openAiAbstract`：智能摘要。**CLI 已支持**：`--ai-abstract`。
-- `aiAbstractField`：摘要写入字段。**CLI 部分支持**：JSON 可写字段 ID；实测环境无可选字段，尚未验证非空写入。
+- `aiAbstractField`：摘要写入字段。**CLI 部分支持**：JSON 可写字段 ID；当前环境无可选字段，非空写入尚未验证。
 - `openAiFormat`：智能排版。**CLI 已支持**：`--ai-format`。
 - `autoAiFormat`：生成正文后自动排版。**CLI 已支持**：JSON。
 - `defaultFormatTemplate`：默认排版格式。**CLI 部分支持**：可写模板 ID，未提供名称查询。

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

@@ -178,7 +178,7 @@ e10-cli workflow operator-sign <workflowId> <nodeId> --sign-order 竞签 --group
 
 > ⚠️ `set-operator` 建的是**会签**；要改成非会签/竞签/依次/抄送，用 `operator-sign`（更新旧组，不重建，避免破坏关联）。`--group` 指定组名可只改某组。
 
-> 🚫 **操作者配置硬规则（防"兜底成具体人员"错配）**：需求里操作者是「角色 / 部门 / 岗位 / 发起人上级 / 本人 / 表单字段 / 矩阵 / 自由选择 / 所有人」时，**必须用对应 `--type`**（role / dept / position / superior / initiator / form / matrix / free / all），并按需求的关键词（角色名/部门名/岗位名/字段名…）配置；**名称解析不到就停下报告或确认，绝不退而求其次去指定某个具体人员顶替**（那会搭错组织权限，典型症状：节点操作者成了某测试同事）。只有需求明确写"指定某人/张三"时才用默认 `user`。配完用 `workflow nodes` / 节点操作者回读核对类型与需求一致。
+> 🚫 **操作者配置硬规则（防"兜底成具体人员"错配）**：需求里操作者是「角色 / 部门 / 岗位 / 发起人上级 / 本人 / 表单字段 / 矩阵 / 自由选择 / 所有人」时，**必须用对应 `--type`**（role / dept / position / superior / initiator / form / matrix / free / all），并按需求的关键词（角色名/部门名/岗位名/字段名…）配置；**名称解析不到就停下报告或确认，绝不退而求其次去指定某个具体人员顶替**（那会搭错组织权限，典型症状：节点操作者成了某个无关的具体人员）。只有需求明确写"指定某人/张三"时才用默认 `user`。配完用 `workflow nodes` / 节点操作者回读核对类型与需求一致。
 >
 > 🚫 **抄送组不能是节点唯一操作者**：抄送(含需批注)不产生审批，一个节点必须至少有 1 个审批/处理组；"某人审批 + 抄送xxx" = 先 `set-operator` 建审批组，再 `--append` 追加抄送组（如上方"结束归档"例子）。