weaver-work-cli 0.1.26 → 0.1.29

package/skills/weaver-e10-workflow/references/todo-smart-convert.md

@@ -0,0 +1,282 @@
+# todoSmartConvert：待办智能汇总
+
+`workflow.todoSmartConvert` 是 workflow 模块的只读 operation，用于跨条目取数、首次分组、校验 AI 分组计划、按需取详情和回填单条摘要。固定的组摘要由 CLI 生成，普通列表查询使用 `workflow.search`；批量提交、置已读、催办、共享、转发、退回使用 `workflow.batch*`；不要把这些链路混用。
+
+## 0. 术语（改代码、写文档、对话都用这套说法）
+
+| 名词 | 含义 | 对应实现 |
+| --- | --- | --- |
+| `workflowName` | 工作流名称 | 大组的 `title` 就是它 |
+| **第一次分组** | 按 `workflowName` 把条目分到各个工作流；得到的每个组叫**工作流分组** | `runGroup` → `wfIdGroup[]` |
+| **ai二次分组** | 在工作流分组**内部**再切子组的过程；**只有这一步需要 AI 计划** | `smartGroup` + `aiGroups` |
+| **原始列表数据** | `/getTodoListData` 返回的待办条目集合，**整条链路的唯一数据源**（每条对应一个 `requestId`） | `collect` 的 `items[]` |
+| **流程标题** | 条目标题 `requestNameTitle`；没有**流程详情数据**时，AI 只能靠它做语义判断，也是摘要的兜底文案 | `requestData.requestNameTitle` |
+| **流程详情数据** | `/getWorkflowRequest` 返回的表单字段 + 基础信息；用于 a) 分组素材 b) 摘要素材 c) 阈值指标（请假天数/报销金额/到期时间） | `DetailFact { context, metrics }` |
+| **requestDatas** | 一个工作流分组内的条目集合；既是大组自身的条目容器，也是汇总项（`type:"group"`）内部的条目容器 | `wfIdGroup[].requestDatas` / `displayItems[group].requestDatas` |
+| `requestId` | 请求 ID；`getTodoListData` 返回的每条数据对应一个，回灌摘要与定位条目都以它为主键 | `requestData.requestId` |
+| `getWorkflowRequest` | 返回**流程详情数据**（表单字段 + 基础信息） | `endpoints.ts` 的 `REQUEST_DETAIL` |
+
+约定：不带限定语说「分组」= 第一次分组；说「二次分组」= **ai二次分组**。产出物里 `displayItems[].type === 'group'` 的即 ai二次分组的结果；**平铺**指条目作为 `displayItems[]` 里 `type:"request"` 的单条输出（不是留在 `requestDatas` 里）。
+
+## 1. 调用链
+
+| 阶段 | 作用 |
+| --- | --- |
+| `collect` | 调列表接口取数，并生成首次分组和 `groupingBrief` |
+| `group` | 对已传入的 `items` 重新做首次分组 |
+| `smartGroup` | 校验 `aiGroups`，组装最终三键结构 |
+| `summaryContext` | 拉详情并生成单条摘要素材 |
+| `summary` | 回填 `aiSummaries`，可同时生成组摘要素材 |
+| `groupSummaryContext` | 生成汇总项摘要素材 |
+| `groupSummary` | 回填 `aiGroupSummaries` |
+| `aggregate` | 兼容旧调用的本地去重、分组和金额合计 |
+
+推荐调用顺序：
+
+```text
+collect
+  -> smartGroup（可传 withDetailContext:true）
+  -> summary（可传 withGroupSummaryContext:true）
+  -> groupSummary（仅存在待回填组摘要时）
+```
+
+未传 `stage` 时，没有 `items` 进入 `collect`；传入 `items` 进入兼容的本地汇总；回灌带有最终结构的数据时由 CLI 推断后续阶段。显式 `stage` 优先。
+
+每次模型调用由调用方把 AI 耗时追加到 `skillTiming`；CLI 会把当前阶段耗时追加到 `meta.timing.steps`。不要为没有执行的 AI 阶段填入耗时。
+
+## 2. 取数和详情
+
+### 取数
+
+- 默认 `category=todo`，只调用对应分类的列表接口；待办接口为 `getTodoListData`。collect 不调用总数、分组统计或详情接口。
+- 时间范围一次传入，通过 `current` 递增翻页。默认 `limit=200`，最大 `limit=500`；单页最多 100 条，最多 5 页。`pageSize` 是兼容参数，实际大小由 `limit` 推导。
+- 达到 limit、页内没有新增数据或返回空页时停止；跨页按 `requestId` 去重。超过上限会在 warnings 中说明。
+- 只使用响应中的 `displayData`，不把技术行当作回退数据。长 ID 始终按字符串处理。
+- `items` 只保留稳定业务字段；`workflowName`、接收时间、金额等辅助字段只用于本地分组、指标和兼容 `aggregate`，不会泄漏到最终 `requestData`。
+- collect 会刷新本地查询快照，但本 operation 不执行写操作。
+
+### 详情和缓存
+
+- 详情请求固定使用 `isReadRequest:false`，默认并发 10、单条超时 10 秒；单条失败不会拖垮整批。
+- 详情字段先清洗 HTML/CSS，再应用业务字段规则；正文全量传给模型，不做固定字数截断。
+- **两个持久化缓存**，key 都是 `requestId__lastFeedBackDateTime`，有效期 7 天、清理间隔 3 天：
+  - 详情缓存：正文 / 阈值指标 / 分组字段，**详情为空也写**；
+  - 摘要缓存：单条摘要文本。
+  记录里带 `lastFeedBackDateTime` 就是为了这个 key：**流程有新反馈 ⇒ key 变 ⇒ 缓存自然失效**，不需要另设版本号。
+- 详情取数时机：`collect` 只为「用户给了 `groupFocus` 且意图适用于本组」的组预取字段；`smartGroup` 对全部条目走一次「缓存优先」的取数（命中零请求）。因此**冷缓存下详情请求集中在 `smartGroup`，`summary` 阶段通常 0 请求**。
+- 摘要缓存**只省 AI、不省详情**：阈值指标只认流程详情数据，所以命中摘要的条目仍会查一次详情缓存；摘要为空的条目用标题兜底。
+
+## 3. 首次分组
+
+- `groupBy` 支持 `workflow`、`urgency`、`date`、`none`，默认 `workflow`。
+- 优先组固定为 `id=priority`、标题“建议优先处理的流程”，排在第一位。超时条目必入；没有级别 2 时才使用级别 1，级别 0 不因等级入选。
+- 优先组是**叠加视图**，不是筛选：入选条目**仍保留在各自的工作流分组里**（优先组只是置顶入口）。因此 `Σcount` 会大于 `totalCount`，**`totalCount` 一律按去重条数计（= collect 取到的全部条数），不做分组求和**。
+- 普通组保持接口返回的首次出现顺序。只有调用方明确给出排序意图时才传 `groupOrder`；`topN` 只影响中间 Markdown，不裁剪最终数组。
+- `groupingBrief` 用组内 1-based `idx` 标识条目。AI 生成 `aiGroups` 时优先用 `seq`，不要手抄长 `requestId`。
+
+## 4. `smartGroup` 和 `aiGroups`
+
+`aiGroups` 是扁平数组，每项只允许 `groupId`、`title`、`requestIds` 或 `seq`：
+
+```json
+[
+  { "groupId": "workflow-id", "title": "安全通知", "seq": [1, 3] },
+  { "groupId": "workflow-id", "title": "制度通知", "seq": [2, 4] }
+]
+```
+
+- `requestIds` 与 `seq` 二选一，不能同时出现，也不能都为空。
+- 优先组不可二次分组。
+- 组内少于 3 条时**一律平铺单条**，不产生任何汇总项——阈值组（1天以内 / 100元以内）、问题支持过期组、内部留言整组都不例外；**即使给了 `aiGroups` 也忽略**（CLI 写 warning）。这条是硬门槛，没有例外。
+- 组内至少 3 条时，完全省略 `aiGroups` 走 CLI 确定性分组；显式传入后，未知 `groupId`、未知 `requestId`、重复分配和越界序号直接失败（**仅在本组计划会被采纳时校验**：意图适用于本类型，或本组是内部留言）。
+- `aiGroups` 不是必填，**而且只有两种情形该给**：
+  - ① 用户给了侧重点（`groupFocus`），且侧重点**按意图表适用于本组类型**；
+  - ② 本组是**内部留言** —— 而且**≥3 条时是必须给**：没有侧重点（或侧重点不适用）就按**流程标题**分组，缺计划直接报 `ai_groups_required`。
+  其他类（`other`）在无侧重点时**不要给**：给了也会被忽略，且该组**全部平铺单条**（会写 warning）；请假/财务/客户问题支持按各自的阈值 / 过期规则分，不需要计划。
+- **意图按表判定，不是「随便一句中文都算」**（`INTENT_RULES`）：专属意图（请假维度 / 财务维度 / 问题支持维度）只作用于对应类型；通用意图（客户 / 发起人 / 时间 / 紧急 / 标题主题 / 类型…）只作用于内部留言与其他类。意图不适用于本组时，CLI 按「没有意图」处理并写 warning，**不会硬失败**。
+- 意图适用于本组、却没给本组计划 ⇒ 按「没有意图」处理（确定性规则），不再报 `ai_groups_missing_group`。
+  **例外：内部留言 ≥3 条没有这个退路**——必须给计划（按标题或按侧重点），缺计划报 `ai_groups_required`，并把可用 `groupId` 与 `1..N` 序号回传。
+- 无 `groupFocus` 时，子组按条数降序；有 `groupFocus` 时，子组沿用 AI 数组顺序。侧重点只作用于匹配的业务类型。
+- 请假类和财务类在无侧重点时使用 CLI 阈值兜底：分别合并不超过 1 天、不超过 100 元的条目，其余单条；**指标只取流程详情字段**，取不到就平铺并点名，不猜。
+- **阈值分组与「传不传 `aiGroups`」无关**：只要本组没拿到生效计划、且没有匹配的侧重点，就始终按阈值分组。阈值组的 `summary` 由 CLI 固定生成，即使本轮传了 `aiGroups` 也不会留空——**不要把阈值组当成需要 AI 写摘要的组**。
+- `1天以内` / `100元以内` 是**保留标题**：模型把它们当子组名时，CLI 会逐条核阈值，超阈值的条目被剔出、按单条展示并写 warning。
+- **客户问题支持类**（`workflowName` **精确等于** `Ecology客户问题支持解决流程` / `E10客户问题支持解决流程`，不含 new / 明细 / 重庆机构 / FWSX-老客户）：
+  - **无侧重点**：CLI 固定产出一个汇总项「已过期及今天即将过期的流程」（判定 `overdue || expiringToday`），其余按单条展示；**一条都没命中就不产这个子组**，全部单条。
+  - **有侧重点**：`collect` 会为这类流程额外拉一次详情，把字段键值放进 `groupingBrief.items[].fields`（最多 8 个字段、每个值截 80 字），模型按意图指向的字段值分桶（如"按问题小分类"→ 用 `问题所属模块` 的取值做子组名）。
+  - `groupingBrief.items[]` 带 `overdue` / `expiringToday` / `userOverTime`，**不要自己解析「11-30到期」这类文案**。
+- **默认不二次分组**：没有生效计划时，只有两类会产汇总项——请假/财务的阈值组、客户问题支持类的过期组；**其他一律平铺单条**，不造「与父组同名」的整组汇总项，也**不造 `other`**。满意度类全单条，`summary` 用条目标题兜底（不调 AI、不为空）。AI 路径的漏分、子组只剩 1 条、保留标题里超阈值的条目，**一律落成单条**（不丢数据）并写 warnings。
+
+最终业务对象只能有三个键：
+
+```json
+{
+  "smartSummaryTitle": "您当前有 N 条待办，清单如下：",
+  "totalCount": 0,
+  "wfIdGroup": []
+}
+```
+
+每个大组包含 `id`、`topPriority`、`title`、`count`、`defaultExpanded`、`displayItems`。`displayItems` 是以下两种对象之一：
+
+```json
+{ "type": "request", "requestData": {} }
+```
+
+```json
+{
+  "type": "group",
+  "id": "workflow-id-1",
+  "title": "子组名称",
+  "count": 0,
+  "summary": "",
+  "defaultExpanded": false,
+  "requestDatas": []
+}
+```
+
+`totalCount` = **按 `requestId` 去重后的条数**（= collect 取到的全部条数），**不是** `wfIdGroup[].count` 之和：优先组是叠加视图，Σ`count` 会大于 `totalCount`。只有优先组默认展开；普通组先放汇总项，再放单条。漏分、缓存命中、详情失败等诊断信息放在信封或 `meta`，不放进业务对象。
+
+## 5. 摘要阶段
+
+### 单条摘要
+
+- `summaryContext` 输出 `summaryBatches`，每个批次带组信息、条目标题、清洗后的 `context` 和 `contextAvailable`。
+- 批次不跨组；默认按 24,000 字或 100 条切分。摘要默认建议 50 字，可用 `summaryMaxChars` 覆盖。
+- 调用方只提交本轮有效的 `aiSummaries:[{requestId,summary}]`。未知或重复 ID 失败；漏写保留空串并告警。CLI 不截断或改写摘要。
+
+### 组摘要
+
+- 确定性路径下 `smartGroup` 只为请假、财务、客户问题支持三类产固定组摘要；其他类与内部留言没有汇总项，也就不存在组摘要。显式 AI 分组路径的组摘要先为空，由 `groupSummaryContext` / `groupSummary` 回填。
+- 组摘要素材只包含标题、发起人和单条摘要，不重复拉详情。组摘要默认建议 100 字，可用 `groupSummaryMaxChars` 覆盖。
+- 回填使用汇总项自身的 id（例如 `workflow-id-1`），不是父组 id。未知或重复 ID 失败，漏写保留空串并告警。
+
+## 6. 输出和兼容字段
+
+- 最终业务数组完整返回，不因输出大小裁剪或改写；warnings 可在 operation 信封和 `meta.warnings` 中出现，其他诊断字段只放在 `meta`，不混入业务对象。
+- `detailPrefetch`、`pageSize` 和旧拼写 `smartSmmaryTitle` 仅为兼容，新调用使用当前字段。
+- 复杂批次可以使用仓库提供的 `scripts/todo-summary.cjs`，但脚本只是 CLI 编排器，不能绕过本 operation 的校验和输出契约。
+
+### 6.1 交付形态：内联 `<browsertool>` + 另存无标签 JSON（硬规则）
+
+**用户 2026-10-27 定稿：不区分宿主与 agent 类型**（小e / WorkBuddy / Codex / 终端全部同一套规则），交付**固定两份、缺一不可**：
+
+- **① 回复正文里直接内联完整的 `<browsertool>...</browsertool>` 块**（不省略、不用路径代替）+ 各阶段耗时。
+- **② 同时另存一份不带标签的纯 JSON 文件**（内容 = 同一个载荷对象），路径 `~/Downloads/待办汇总-<范围>-<条数>条-<YYYYMMDD>.json`，落盘后立刻用 `present_files` 打开。
+- 标签**必须成对**：`<browsertool>` 开头、`</browsertool>` 结尾；漏标签或只贴裸 JSON 都算交付失败。
+- `params.data` 的值就是最终三键对象（`smartSummaryTitle` / `totalCount` / `wfIdGroup`）**原样**：不裁剪、不改字段名、不再外包一层。
+- 载荷里除 `params.data` 外**不要**再带 `schemaVersion` / `ok` / `operation` / `meta` / `warnings` 等信封字段。
+- 外框字段全部固定，只有 `src` 与 `params.data` 会变：
+
+```text
+<browsertool>
+{
+  "version": "1.0",
+  "callId": "call-1",
+  "toolId": "todo_summary",
+  "arguments": {
+    "type": "e10",
+    "title": "待办摘要汇总",
+    "src": "<当前认证环境的 baseUrl>/workflow/list/todo",
+    "sdkRenderType": "drawer",
+    "sdkOptions": {
+      "compName": "ui.CorsComponent",
+      "routerType": "MemoryRouter",
+      "routerProps_pc": { "initialEntries": ["/"] },
+      "routerProps_mobile": { "initialEntries": ["/"] },
+      "params_pc": { "app": "@weapp/workflow", "compName": "Comp.WflTodoSummary", "clientType": "pc" },
+      "params_mobile": { "app": "@weapp/workflow", "compName": "Comp.WflTodoSummary", "clientType": "mobile" },
+      "params": { "data": { } }
+    }
+  }
+}
+</browsertool>
+```
+
+- `src` 取**当前认证环境**的 `baseUrl`（`weaver-work-cli --json auth status` 的 `baseUrl`）拼 `/workflow/list/todo`，不要写死某个租户。脚本已用 `state.json` 缓存 `baseUrl`，同一轮流水线不会重复启动 CLI。
+- `params_pc` / `params_mobile` 必须放在 `sdkOptions` 内、与 `routerProps_pc/mobile` 同级，**不要放进 `arguments` 层**。
+- `app` 的值按原始字符写 **`@weapp/workflow`**（`@` 后面**没有**斜杠，共 15 个字符）：**不要写成 `@//weapp/workflow`、不要转义成 `@\/\/weapp\/workflow`、也不要加前导空格**——带前导空格会导致 app 解析失败（用户 2026-10-27 以截图校正）。
+- 脚本 `exportFinal` 已在 stdout 的 `[JSON_BEGIN]`/`[JSON_END]` 之间直接输出**带标签的整块载荷**，原样粘贴即可；交付时**要传 `--file`**，它会另存一份**不带标签的纯 JSON**（同一载荷）供 `present_files` 打开。
+- 体积见 §6.2：**不能按组拆成多个 `<browsertool>` 块**（拆开就不是合法载荷）；超限时先在正文说明条数与预计体积，建议缩小范围，用户坚持再照做。
+
+
+交付约束：**不改写条目字段、不做体积裁剪**（载荷里必须是完整明细）。
+
+#### 6.1.3 耗时口径（只在回复里用文字报出，不产出 md）
+
+用户 2026-10-27 要求：**取消「耗时说明 md」这份交付物**，交付物只有那一块 `<browsertool>` 载荷；耗时仍照常统计，但只在回复正文里用文字给出。下面两个口径要分开报，**不要把两个数混成一个**：
+
+| 口径 | 取法 | 含义 |
+| --- | --- | --- |
+| 墙钟 | `/usr/bin/time -p` 包住整次调用 | 含 node 启动 + 模块加载 + 业务 |
+| CLI 内部 | `meta.timing.steps[].durationMs` | 只含业务（请求 + 计算） |
+
+- **请求级埋点已移除**（2026-10-27 用户定：`internal/e10/requestTiming.ts` 模块及 `client.ts` / `request-runtime.ts` 的接线一并删除，`meta.timing` 现在只有 `startedAt / finishedAt / stage / steps / durationMs`）。不要再读 `meta.timing.requests`，也不要写 `WEAVER_WORK_CLI_TIMING=1`。
+- 常见误读：`collect` 的墙钟含进程启动（沙箱下 5~7s），真实取数只有 0.2~0.3s。脚本已分列输出 `collect 内部 / 含进程启动`。
+- **不落任何耗时文件**：`--timing-report` 只在控制台打两行「耗时摘要」（总墙钟+业务占比、以及一条"只统计 CLI 链路"的提示），不再写 md、不要 `present_files` 它；回复里用文字给出总墙钟与真实业务耗时可。
+
+**端到端要分四层报，不要只报一个数**（实测 2026-10-26 近一年：端到端 4m58s，而 CLI 只占 23s）：
+
+| 层 | 典型量级 | 来源 |
+| --- | --- | --- |
+| CLI 内部（业务） | 1~3s | `meta.timing.steps` |
+| CLI 墙钟 | 20~25s（3 次进程 × 5~7s 启动） | `/usr/bin/time` |
+| 脚本与工具 | 2~3s | 探查命令、写文件 |
+| **模型往返** | **200~270s** | 每次工具结果后 20~35s |
+
+⇒ 端到端提速最有效的不是优化 CLI，而是**减少往返次数**：
+
+- 用 `run --days N --limit N --out DIR --file --timing-report` 一次跑完 `prep + build`（无待写摘要时连 `finish` 一起），别一步步手动跑。
+- **有侧重点（`--focus`）时的最短路径是 4 轮**，多一轮就多 5~7s：
+  ```
+  R1  prep  --days N --focus "请假类型、报销类型"          # 输出组/行/序号，以及 collect 已预取的「请假类型 / 金额 / 费用说明」
+  R2  写 aiGroups.json && build --plan aiGroups.json      # 同一条命令里完成
+  R3  写 aiSummaries.json && finish --summaries …           # 输出组摘要素材
+  R4  写 aiGroupSummaries.json && finish --group-summaries … # 同一条命令内回填单条 + 组摘要并导出
+  ```
+  - `prep` 的每行后面会带 `‹字段=值›`（最多 3 个、相同值只留一个）：**据此分桶，不要再自己去翻详情缓存**。
+  - `--group-summaries` 让 `finish` 在同一次调用里跑完 `summary` + `groupSummary`，省掉「读完素材再单独调一次 groupSummary」那一轮。
+- **启动开销的真相（2026-10-27 实测）**：宿主给每个 node 子进程注入 `NODE_OPTIONS=--require=…/node-language-shim.cjs`，它对**每次 fs 读取**加 ~10ms 审计；本 CLI 启动要读 387 个模块 ⇒ 每次 ~4s（负载高时 25s）。
+  `todo-summary.cjs` 启动 CLI 时**只摘掉 shim 这一项**（`cliEnv()`），实测 `--version` 4.96s→0.16s、`workflow schema` 7.23s→0.19s、脚本 spawn 6.46s→0.56s。
+  需要保留 shim 时设 `WEAVER_WORK_CLI_KEEP_NODE_SHIM=1`；手工单次调用想提速可用 `env -u NODE_OPTIONS weaver-work-cli …`。
+- **不要把工具改造夹进跑数流程**：脚本/规则有问题先按业务跑完（或单独一轮改完），别边跑边改——实测一次任务里这样做掉了 6 轮、约 40s。
+- 加了 `--timing-report` 就**不要**再自己 `node -e` 反复查中间产物——每次探查等于一次额外往返（≈30s）。
+- 交付回复里同时给「CLI 执行 X 秒 / 端到端 Y 秒（含模型推理）」，只报其中一个都算口径错误。
+
+### 6.2 载荷体积
+
+本分支**不走**公共输出层的 24 KB 落盘投影：`workflow/index.ts` 对 `workflow.todoSmartConvert` 显式传 `persist: false`（注释写明「业务契约要求直接返回完整 `requestDatas`/`displayItems`；禁止公共输出层按 24 KB 预算递归折叠该分支」）。因此不会产生 `refId` / `resultFile`，也不会被折叠或裁剪，体积全部由调用方承担。
+
+- 体积按 **约 700 B/条** 估算：1 条 ≈ 750 B，30 条 ≈ 21 KB，70 条 ≈ 49 KB，300 条 ≈ 210 KB。
+- **唯一交付路径（不区分宿主）**：组件要求**一个**块内联完整 `data`，所以**不能按组拆块**（拆开就不是合法载荷）；超过约 80 KB（≳110 条）时先在正文说明条数与预计体积，并建议缩小范围或排除某个流程，用户坚持再照做。实测 320 条 = 176 KB，已超出单条消息容量。
+- **其他客户端路径**：落文件即可，体积不受对话限制；只有回复里的说明文字要短。
+
+## 7. 常用命令
+
+macOS/Linux：
+
+```bash
+weaver-work-cli --json workflow run workflow.todoSmartConvert --input-json '{"stage":"collect","limit":100}'
+```
+
+Windows PowerShell：
+
+```powershell
+weaver-work-cli --json workflow run workflow.todoSmartConvert --input-json '{"stage":"collect","limit":100}'
+```
+
+大 payload 使用 `--input <path>` 或受支持的输入回灌方式，内容必须来自上一阶段返回值，不要手工重算 `wfIdGroup`。
+
+## 8. 错误处理
+
+| 错误 | 处理 |
+| --- | --- |
+| `stage_invalid` / `input_unknown_key` | 按错误中的允许字段修正 |
+| `items_required` / `items_invalid` / `items_too_many` | 先执行 `collect`，再回灌原始 `items` |
+| `ai_groups_invalid` / `ai_group_*` | 检查 `groupId`、`title`、`seq`/`requestIds` 和覆盖范围 |
+| `final_groups_required` / `wfidgroup_invalid` | 原样回灌上一步 `wfIdGroup` |
+| `ai_summaries_required` / `ai_summary_*` | 只提交本轮有效 `requestId`，不能重复 |
+| `ai_group_summaries_required` / `ai_group_summary_*` | 使用汇总项 id，不使用父组 id |
+| `forbidden_endpoint` | 只允许列表取数接口，检查是否误用了辅助分页接口 |
+| `authentication` / `network` | 按共享 skill 的认证和失败规则处理，不盲目重试 |
+
+最终交付固定两份：**回复里内联的 `<browsertool>` 载荷** + **同名的不带标签纯 JSON 文件**（`present_files` 打开），耗时以文字写在回复里；不要用 Markdown 报告或摘要清单替代载荷，也不要再产出「耗时说明 md」这类附加文件（见 §6.1、§6.1.3）。

package/skills/weaver-e10-workflow/references/workflow-create.md

@@ -15,19 +15,19 @@
 
 | 步 | 命令 | 做什么 |
 | --- | --- | --- |
-| 1 | `workflow.createForm` | 用用户说法解析可发起的工作流并**加载表单字段**：拿回 `fields`（**每个能填的字段一行**，有默认值的字段带 `initialValue`）、`continuation`（下一步的 `context`）。**把 `userQuestion` 一起传进去**（一句话概括用户要发起什么）——命令会按你的意图把字段值直接算好放在 `data` 里返回，此时**不再返回** `historyRequestData` / `systemFields` |
-| 2 | `workflow.createRequest` | **返回里有 `data` 就直接用它**（见「`data` 已填好时怎么用」）：没有发票/附件意图就原样传；有就先上传、把返回对象替换进 `data` 再传。**只有在返回里没有 `data` 时**才按「填值纪律」自己拼 |
+| 1 | `workflow.createForm` | 用用户说法解析可发起的工作流并**加载表单字段**：拿回 `fields`（**每个能填的字段一行**，有默认值的字段带 `initialValue`）、`historyRequestData`（历史参考值）、`systemFields`（标题/紧急程度/密级的默认值与选项）、`continuation`（下一步的 `context`）。**它只取数、不填参**——字段值由你按「填值纪律」自己拼 |
+| 2 | `workflow.createRequest` | 按「填值纪律」把第 1 步取到的字段拼成 `data`（附件/发票字段先上传，再把返回对象放进 `data`），连同 `context` 一起传 |
 | 3 | —（无命令） | **把第 2 步的返回结果输出给用户**：返回结果里有 `finalMarkdown` 就把**它的内容整段原样输出**——**不要解释、不要改写、也不要补内容**。小e 环境（`BROWSER_FILL`）的 `finalMarkdown` 是一段 `<browsertool>` 标签块，同样**整段原样输出**（从 `<browsertool>` 到 `</browsertool>`：**不要用代码块（三反引号）包裹、不要加任何前后说明、不要解析它**）；没有 `finalMarkdown`（如 `NEEDS_CONFIRMATION`）才按「主表（已填内容）展示规则」+「明细表（子表单）展示规则」自己拼。**不要重跑任何命令、不要自己再去查一遍流程。** |
 
 澄清、必填缺失、幂等重放等分支见下「发起链路」。
 
 ## 发起链路（两条命令的完整分支）
 
-1. `workflow.createForm`：按用户说法解析可发起的工作流并载入表单，拿回 `continuation`（表单会话短句柄，载荷由 CLI 托管在本机）与 `fields`（**每个能填的字段一行**：`id` + 中文名 `name` + 所属明细 `subFormId`（主表字段省略该键）+ `componentKey`；**有默认值的字段直接带 `initialValue`**）。**把 `userQuestion` 一起传进来**：
-   - 传了 `userQuestion` 且返回里带 `data` ⇒ **`data`** 就是按用户意图已经识别好的字段值（结构就是 `createRequest` 的入参），**此时的返回里没有** `historyRequestData` / `systemFields`；
-   - 返回里没有 `data` ⇒ 用 **`historyRequestData`**（本表单要落值的字段在历史流程里的取值参考，`null` = 没有可参考的）+ `systemFields`。
+1. `workflow.createForm`：按用户说法解析可发起的工作流并载入表单，拿回 `continuation`（表单会话短句柄，载荷由 CLI 托管在本机）与 `fields`（**每个能填的字段一行**：`id` + 中文名 `name` + 所属明细 `subFormId`（主表字段省略该键）+ `componentKey`；**有默认值的字段直接带 `initialValue`**），同时带回 `historyRequestData`（历史参考值）与 `systemFields`（系统字段的默认值与选项）。**它只取数、不填参**：
+   - 字段值由你按「填值纪律」自己拼：用户说了的照用户说的填；带 `initialValue` 的可以干脆不传（CLI 自动并入）；其余字段按「历史流程数据参考规则」判断能不能落值；
+   - 拼之前先看 **`historyRequestData`**（本表单要落值的字段在历史流程里的取值参考，`null` = 没有可参考的）与 `systemFields`（标题/紧急程度/密级的默认值与选项）；
    - 返回 `NEEDS_CLARIFICATION` 时按 `candidates` 向用户确认（只问完整名称或其它可用于检索的关键词，**不要向用户索取 ID**），确认后由你按 `名称(ID)` 拼好、重发**同一条命令**。
-2. **返回里有 `data` 就直接用它**（见「`data` 已填好时怎么用」：没有发票/附件意图就原样传；有就先上传替换）。**只有在没有 `data` 时**，才按用户意图把字段值填进 `data`（键用字段 id）：**照「填值纪律」的优先级逐个字段一遍定案**——用户说了的照用户说的填；用户没说到、而该字段带 `initialValue` 的就用默认值（也可以干脆不传，CLI 会自动并入）；其余字段按「历史流程数据参考规则」判断能不能落值。
+2. 按用户意图把字段值填进 `data`（键用字段 id）：**照「填值纪律」的优先级逐个字段一遍定案**——用户说了的照用户说的填；用户没说到、而该字段带 `initialValue` 的就用默认值（也可以干脆不传，CLI 会自动并入）；其余字段按「历史流程数据参考规则」判断能不能落值。
 3. `workflow.createRequest`：`context` 传第 1 步返回的 `continuation`，`action` 按用户意图取 `draft`/`submit`。
    - `action: "submit"` 且仍有必填缺失 → **命令不会创建流程**，返回 `NEEDS_INPUT` + `missingFields` + **渲染好的 `finalMarkdown`**（已填内容 + 明细 + 待补必填项清单；**历史取值一致的待补字段，命令已附一行 `历史推荐值`**）；**不做任何值推断**——**把这份 `finalMarkdown` 原样发出**（与成功时完全同一口径：不弹窗、不挑字段、不自己列待补项、不解释），带同一 `context` 重发 `action: "submit"`。
    - `action: "draft"` 且仍有必填缺失 → 照常建草稿，`missingFields` 只作提醒（必须原样转述给用户）。
@@ -45,44 +45,22 @@
 
 **输出纪律（与上面的省时纪律同理：多写的每一句都在拖长回复，并让用户看不懂）**：① 面向用户**只给三样**——"这次做了什么、结果如何" ＋ "**已填内容预览**"（展示口径见下文「主表（已填内容）展示规则」）＋ "需要用户提供什么"，其余不说——**尤其不要交代"用了哪个流程 / 编号是多少 / 我是怎么判断的"这类内部依据**；② **不要复述自己的判断过程、取舍与推演**，也不要写自我批评或事后反省——用户要的是结果，不是你怎么想的；③ **不要把澄清分支的区别讲给用户**（如"不是有多个候选要挑，而是一条都没命中"）：该报"系统里没有「XX」"就按下文浏览按钮口径直接说结论，**不要解释你是怎么判定出来的**；④ 需要用户给值时**只说清"要什么值"**，不要顺带解释"我为什么判断不出来"。
 
-## `data` 已填好时怎么用
+## 附件 / 发票字段怎么填
 
-`createForm` 传了 `userQuestion`、返回里带 `data` 时：**它就是按用户意图已经识别好的字段值**，结构与 `createRequest` 的 `data` 入参**完全一致**（`{main: {<字段id>: <值>}, details: {<子表单id>: [{...}]}}`）。
+`fields` 里 `isEinvoice=true` 的是发票字段、带 `fileUploadParams` 的是附件字段。给它们落值时**不要写字符串**，按类型走对应技能，把返回的对象直接放进 `data` 的该字段：
 
-**这时不要再重新推演字段值**——不要逐字段对照 `fields`、不要翻历史、不要把"我理解的意图"再拼一遍。直接基于这份 `data` 往下走，只有下面两种情况需要动手。
-
-### 情况一：用户本次没有发票 / 附件填写意图
-
-`data` **原样**作为 `createRequest` 的 `data` 传进去，一个键都不用改、也不用补——字段值、明细行、标题都已经算好。
-
-### 情况二：用户本次要传发票 / 附件
-
-`data` 里对应字段的值会是一个**占位符**（原样字符串）：
-
-- `"file"` —— 这个附件字段需要你先上传文件再填入
-- `"invoice"` —— 这个发票字段需要你先从票夹取发票再填入
-
-**占位符不是真实值，直接提交会失败。**按类型走对应技能，再把返回的对象**原位替换**回 `data` 的该字段：
-
-| 占位符 | 怎么做 | 替换成什么 |
+| 字段类型 | 怎么做 | 填什么 |
 | --- | --- | --- |
-| `"file"` | 用 `weaver-e10-caizhilian` 技能上传用户给的文件（`caizhilian.file-upload.prepare` → `.upload.prepare` → `.upload.apply`），拿到 `file_id` | `[{ "optionId": "<file_id>", "content": "<文件名>", "type": "file" }]`（多个文件就多项） |
-| `"invoice"` | 用 `weaver-e10-yepiaotong` 技能：用户发了票就上传（`invoice.upload`）；用户说"从票夹取"就查票夹拿 `fid`，再取完整发票对象 | `[{ "optionId": "<fid>", "type": "einvoice", "optionObj": { <完整发票对象> } }]` |
+| 附件 | 用 `weaver-e10-caizhilian` 技能上传用户给的文件（`caizhilian.file-upload.prepare` → `.upload.prepare` → `.upload.apply`），拿到 `file_id` | `[{ "optionId": "<file_id>", "content": "<文件名>", "type": "file" }]`（多个文件就多项） |
+| 发票 | 用 `weaver-e10-yepiaotong` 技能：用户发了票就上传（`invoice.upload`）；用户说"从票夹取"就查票夹拿 `fid`，再取完整发票对象 | `[{ "optionId": "<fid>", "type": "einvoice", "optionObj": { <完整发票对象> } }]` |
 
-三条纪律：
+两条纪律：
 
 1. **上传前必须先告诉用户「文件会先经过公网大模型」，并等用户确认**——不能默默上传。
-2. **替换完把整个 `data` 交给 `createRequest`**，其余字段保持 `createForm` 给的 `data` 原值，不要重算。
-3. 用户**没提到**的附件 / 发票字段，`data` 里本来就不会有，**不要自己去补**。
-
-### 没有 `data` 的时候
-
-返回里**没有** `data`（没传 `userQuestion`，或这次没能算出字段值），就按下面的「填值纪律」自己拼（此时会照常返回 `historyRequestData` / `systemFields`）。
+2. 用户**没提到**的附件 / 发票字段**不要自己去补**（空着就行）。
 
 ## 填值纪律（一遍定案，不许回头）
 
-> **仅在返回里没有 `data` 时适用**。有 `data` 就直接用（见「`data` 已填好时怎么用」），不要走下面这套逐字段推演。
-
 拼 `data` 只走一遍：**按字段逐个落值，每个字段只做一次取舍、取完不再回头看**；落到值就离开这个字段，不在同一字段上比较第二轮。
 
 **一趟走完、一个字段一行**——照这个形状（`<…>` 是占位，实写时换成本次的真字段与真值）：
@@ -106,7 +84,7 @@
 字段走完 → 拼 data → createRequest。
 ```
 
-- **判决只有三种**：`填 "<值>"` / `不传` / `留空`——一行里只出现一个，不并列两个候选、不写"或者 / 可能 / 我倾向"。**唯一例外是附件 / 发票这两类**：它们的判决取决于"用户本轮有没有给文件"，按下面「附件 / 发票字段」写在**同一行**里（条件 ＋ 各自一个结果），不拆成两行、不留到下一轮。
+- **判决只有三种**：`填 "<值>"` / `不传` / `留空`——一行里只出现一个，不并列两个候选、不写"或者 / 可能 / 我倾向"。**唯一例外是附件 / 发票这两类**：它们的判决取决于"用户本轮有没有给文件"，按上面「附件 / 发票字段怎么填」写在**同一行**里（条件 ＋ 各自一个结果），不拆成两行、不留到下一轮。
 - **一行只看这个字段自己**：依据取用户本轮原话 / 它自己的 `initialValue` / 它自己的历史取值；这个字段的事在这一行里判完就离开，不顺手推演别的字段。
 - **要按历史推演的，就在它这一行里推**：推出式子直接代成值写进判决，推完即走。
 - **一个字段只出现一次判决**，后面不再回头改；字段过完就拼 `data`（判决为"填"的进 `data`，`不传` / `留空` 都不写），**紧接着 `createRequest`**。
@@ -167,8 +145,6 @@
 | 参数 | 类型 | 必填 | 说明 |
 | --- | --- | --- | --- |
 | `workflow` | `string[]` | 是 | 工作流条件——`"名称(ID)"` / 纯名称 / 纯数字 ID；**可一次给多个说法**：数组多元素，或一个元素内用英文逗号分隔（两者完全等价） |
-| `relatesTo` | `string` | 否 | 关联对象 id，**仅透传**，不影响表单初始化 |
-| `userQuestion` | `string` | 否 | **用户的填单意图**（一句话概括，可以是多轮对话汇总后的最终需求，如"帮我发起一条9月手机话费报销流程，报销金额是100元"）。**传了才可能拿到 `data`**（返回里带 `data` 就直接用它；不带就自己拼）。**强烈建议每次发起都传**。**只在这里传这一次**，后续 `createRequest` 不要再传 |
 
 - **自带显式 ID（`"名称(ID)"` 或纯数字）时不查可发起列表**：流程名与"你能不能发起"都由表单载入接口直接给出，因此比"按名称解析"少一整次往返。该 ID 不可用时仍回澄清，但会带 `clarificationReason` 说明是**哪一种**（见下）。
 - **纯名称**按当前用户**可发起**的工作流做模糊匹配，**可一次给多个说法**：数组多个元素（`["<说法1>","<说法2>"]`）与一个元素内用英文逗号分隔（`["<说法1>,<说法2>"]`）**完全等价**，CLI 会把各说法拆成关键词、命中取并集去重。
@@ -196,8 +172,8 @@
 | `data` | `object` | 是 | 表单字段值，结构 `{"main":{...},"details":{"<subFormId>":[{...}]}}`；键**必须是字段 id** |
 | `action` | `"draft"` \| `"submit"` | 是 | `submit`=提交审批（必填缺失阻断，返回 `NEEDS_INPUT`，**不创建流程**）；`draft`=仅保存草稿（必填缺失不阻断、状态仍是 `CREATED`，但 `missingFields` 仍随结果返回） |
 | `requestName` | `string` | 否 | 流程标题。**通常不用传**——`createForm` 已给出标题、CLI 会自动并入；只有用户本次明确改写了标题时才传 |
-| `requestLevel` | `string` | 否 | 紧急程度，取 `systemFields.levelOptions` 的 code |
-| `secLevel` | `string` | 否 | 密级，取 `systemFields.secLevelOptions` 的 id |
+| `requestLevel` | `string` | 否 | 紧急程度：用户原话即可（如「紧急」「普通」），CLI 按 `systemFields.levelOptions` 的选项名归一成 code；说不出就不传，走表单默认值 |
+| `secLevel` | `string` | 否 | 密级：用户原话即可（如「机密」「公开」），CLI 按 `systemFields.secLevelOptions` 的选项名归一成 id；说不出就不传，走表单默认值 |
 | `remark` | `string` | 否 | 签字意见 |
 | `verificationConfirmed` | `boolean` | 否 | 节点字段校验需用户确认时显式确认继续提交 |
 
@@ -216,15 +192,14 @@
 | `workflow` | `{id, name, description, type_name, selectionSource}`；`selectionSource` 见「输入」 |
 | `form` | `{id, layout_id}` |
 | `fields` | **字段清单（唯一一份）**：所有「可编辑 ∪ 必填且可见」的字段，每个字段一条记录（**整块在 stdout 上压成单行**，见下），见下 |
-| `data` | **★ 按用户意图已经识别好的字段值**，结构就是 `createRequest` 的 `data` 入参（`{main:{<字段id>:<值>}, details:{<子表单id>:[{...}]}}`）。**传了 `userQuestion` 且这次算出了字段值才有**；有它时 `historyRequestData` / `systemFields` / `systemFieldWarning` **都不出现**。怎么用见「`data` 已填好时怎么用」 |
-| `historyRequestData` | **仅在返回里没有 `data` 时出现**：本表单**要落值的字段**（口径同 `fields`）在历史流程里的取值参考（`null` = 没有可参考的），见下 |
-| `systemFields` | **仅在返回里没有 `data` 时出现**：`{permissions, defaults, levelOptions, secLevelOptions}`——系统字段的权限与默认值，见下 |
-| `systemFieldWarning` | **仅在返回里没有 `data` 时出现**：系统字段权限读取失败时的提示文本（正常为 `null`） |
+| `historyRequestData` | 本表单**要落值的字段**（口径同 `fields`）在历史流程里的取值参考（`null` = 没有可参考的），见下 |
+| `systemFields` | `{permissions, defaults, levelOptions, secLevelOptions}`——系统字段的权限与默认值，见下 |
+| `systemFieldWarning` | 系统字段权限读取失败时的提示文本（正常为 `null`） |
 | `requiredInfoWarning` | OA 未下发静态字段权限时的告警文本（正常为 `null`），见「注意」 |
 | `workflowMemory` | 这条工作流维度的记忆（一段 Markdown 文本）；**读不到时没有这个键**，见下 |
 | `fileUploadParams` | 附件字段的上传限制，挂在对应字段的 `fields[].fileUploadParams` 上 |
 
-**stdout 紧凑形态**：`fields` / `data` / `historyRequestData` / `systemFields` 这几个键在 stdout 上是**压成单行的**——只去掉缩进空白，**内容、结构、键序一字不改**（`parse` 出来与多行版完全一致，可以直接读）。所以 `fields` 那一行字段多时可能上万字符：**这是正常的，不是被截断、也不是数据缺失**，照常按 JSON 解析即可。**不要**因为"这一行太长 / 看着不像完整 JSON"就去读 `resultFile` 或重跑命令；`contextId` / `workflow` 等其余键仍是正常的多行缩进。
+**stdout 紧凑形态**：`fields` / `historyRequestData` / `systemFields` 这几个键在 stdout 上是**压成单行的**——只去掉缩进空白，**内容、结构、键序一字不改**（`parse` 出来与多行版完全一致，可以直接读）。所以 `fields` 那一行字段多时可能上万字符：**这是正常的，不是被截断、也不是数据缺失**，照常按 JSON 解析即可。**不要**因为"这一行太长 / 看着不像完整 JSON"就去读 `resultFile` 或重跑命令；`contextId` / `workflow` 等其余键仍是正常的多行缩进。
 
 **`fields[]` 每个字段的键**（**能出现在这里就是能填的字段**）：
 
@@ -245,14 +220,14 @@
 
 **`fields` 为什么不区分必填**：它就是「可编辑 ∪ 必填且可见」的全集，**「哪些字段可以落值」= 本清单，「哪个必填还没值」= `createRequest` 的 `missingFields`**，只有这两句口径。用户看不到、改不了的字段（只读 / 禁止编辑 / 联动隐藏 / 落在布局隐藏行上 / 落在明细表隐藏列上 / 落在多内容单元格的隐藏格上 / 不在当前布局的展示配置里）**不下发**——所以**条数不多是正常的**，不要拿它当"页面上肉眼可见的字段数"，也不要因为"表单上看着没这么多"就怀疑字段清单不对。
 
-**`historyRequestData`（历史参考值，仅在没有 `data` 时才有）**：范围是**本工作流**、**近一年、非草稿、按发起时间倒序的前 5 条**「我发起的」流程——不是"所有流程混在一起"，所以里面每条都是同一张表单的单据，字段可直接对照；形如 `[{requestName, requestId, createdatetime, fieldValues: {<字段id>: <值>}}]`——`fieldValues` 是**「字段id → 值」的映射**（字段名不随每条记录重复下发：同一个名字要在每条记录里打印一遍，要名字请用 `fields`）；值已按字段类型给出**可直接复用**的写法——浏览按钮 / 选项类为 `名称(id)`（多值以 `、` 分隔）；**附件类为对象**（形如 `{"formField":{"id":"<字段id>"},"dataOptions":[{"optionId":"<附件ID>","content":"<文件名>","type":"<文件类型>"}]}`，可整块放进 `data`，见「历史流程数据参考规则」第三条）；其余为普通字符串。**`null` 表示没有可参考的历史数据**（不返回空数组）；某条历史流程在这批字段上一个值都没命中时会被整条剔除（所以条数可能少于 5）。**你不需要自己再去查历史流程。** 它给的是**本表单要落值的字段**（口径同 `fields`）的取值——填 `data` 时用它把能补的字段补上，判断口径见「历史流程数据参考规则」。
+**`historyRequestData`（历史参考值）**：范围是**本工作流**、**近一年、非草稿、按发起时间倒序的前 5 条**「我发起的」流程——不是"所有流程混在一起"，所以里面每条都是同一张表单的单据，字段可直接对照；形如 `[{requestName, requestId, createdatetime, fieldValues: {<字段id>: <值>}}]`——`fieldValues` 是**「字段id → 值」的映射**（字段名不随每条记录重复下发：同一个名字要在每条记录里打印一遍，要名字请用 `fields`）；值已按字段类型给出**可直接复用**的写法——浏览按钮 / 选项类为 `名称(id)`（多值以 `、` 分隔）；**附件类为对象**（形如 `{"formField":{"id":"<字段id>"},"dataOptions":[{"optionId":"<附件ID>","content":"<文件名>","type":"<文件类型>"}]}`，可整块放进 `data`，见「历史流程数据参考规则」第三条）；其余为普通字符串。**`null` 表示没有可参考的历史数据**（不返回空数组）；某条历史流程在这批字段上一个值都没命中时会被整条剔除（所以条数可能少于 5）。**你不需要自己再去查历史流程。** 它给的是**本表单要落值的字段**（口径同 `fields`）的取值——填 `data` 时用它把能补的字段补上，判断口径见「历史流程数据参考规则」。
 - **`createRequest` 一侧没有它**：`NEEDS_INPUT` / `NEEDS_CONFIRMATION` 时**手上没有任何历史值**，必填缺失直接**一次问齐用户**（`NEEDS_INPUT` 用命令给的 `finalMarkdown`，见「createRequest 返回后的处置」）——**不要**回头翻 `createForm` 阶段那份历史值、也不要凭印象补值。
 
-**`systemFields`（仅在返回里没有 `data` 时出现）**：`permissions` 给各系统字段的 isview/isedit/ismandatory，`defaults` 是默认值，`levelOptions`/`secLevelOptions` 是紧急程度/密级选项。**只有 `isview=true` 且 `isedit=true` 的系统字段才需要填**；紧急程度/密级**只从这两个 options 取**（不得使用记忆、表单字段或其他来源）；**`defaults` 已有非空值即视为已满足，不要询问用户、直接采用**；仅当 ismandatory=true 且默认值为空时才需要用户提供。
+**`systemFields`**：`permissions` 给各系统字段的 isview/isedit/ismandatory，`defaults` 是默认值，`levelOptions`/`secLevelOptions` 是紧急程度/密级选项。**只有 `isview=true` 且 `isedit=true` 的系统字段才需要填**；紧急程度/密级**用户说了原话就直接传原话**（CLI 会按选项名归一成编码），CLI 归不出来时会原样透传；**不得用记忆里的常用值、其它字段内容或自行编造的编码代替用户原话**；**`defaults` 已有非空值即视为已满足，不要询问用户、直接采用**；仅当 ismandatory=true 且默认值为空时才需要用户提供。
 
 **`workflowMemory`**：这条工作流维度的记忆，一段 Markdown 文本。它**只含该工作流那一段**——全局画像 / 全局别名（`user.md` / `memory.md`）已由入口的 `workflow.memoryPrompt`（无参）给过，这里不再重复下发，所以**不要再调一次无参 `memoryPrompt` 来"补全"、也不要把两份拼接**（会重复）。**返回里没有这个键** ⇒ 该工作流还没有记忆（或没读到）——**按新用户处理，不要重试读取**。有这个键时，**只能用它补用户没提到的非必填字段或口径类信息**（如签字意见口径、展示偏好）；**必填字段一律不得用它里面的"常用值"补**——必填缺失只由 `missingFields` 告知、直接一次问齐用户（见「createRequest 返回后的处置」），不要为"能不能用记忆里的值"反复权衡；与用户本次明说的冲突时以用户本次为准。
 
-**大表单超线形态**（`createForm` 输出**超过 20,000 字符**时才有）：此时 stdout **只回一句话**——「当前表单内容较大，已临时写入文件 `resultFile路径`，请直接读取 `resultFile路径` 获取完整结果」。**`fields`、`data`、`contextId` 一个都不在 stdout 里**，它们全都在那个文件里（未裁剪的完整 pretty JSON，与 stdout 同口径）：`fields` / `data` / `contextId` / `continuation` 一样不少（没有 `data` 时则是 `fields` / `historyRequestData` / `systemFields`）。所以：**先按 `resultFile` 把该文件一次读完**（整份读，不要只给个小的 `limit` 再分段；宿主若报单次读取超限，按报错提示调整），拿到字段清单与 `contextId` 之后再拼 `data`、走 `createRequest`。**不要重跑 `createForm`、不要分段读、不要用 `head`/`tail` 截断、也不要用脚本去挖文件。**
+**大表单超线形态**（`createForm` 输出**超过 20,000 字符**时才有）：此时 stdout **只回一句话**——「当前表单内容较大，已临时写入文件 `resultFile路径`，请直接读取 `resultFile路径` 获取完整结果」。**`fields`、`historyRequestData`、`systemFields`、`contextId` 一个都不在 stdout 里**，它们全都在那个文件里（未裁剪的完整 pretty JSON，与 stdout 同口径）：`fields` / `historyRequestData` / `systemFields` / `contextId` / `continuation` 一样不少。所以：**先按 `resultFile` 把该文件一次读完**（整份读，不要只给个小的 `limit` 再分段；宿主若报单次读取超限，按报错提示调整），拿到字段清单与 `contextId` 之后再拼 `data`、走 `createRequest`。**不要重跑 `createForm`、不要分段读、不要用 `head`/`tail` 截断、也不要用脚本去挖文件。**
 - 结果里 `persistedResult: true` 表示走了落盘档；`outputChars` 是本次输出那份最终文本的字符数。
 - **输出被宿主截断时**（只看到一小段预览、出现「已截断…字符」字样）：**不要去读宿主的工具结果目录**（`~/.workbuddy/projects/**/tool-results/**`：没有读权限，去了必白跑一轮），按同一份输出里的 `resultFile` 取完整结果。
 
@@ -284,7 +259,7 @@
 
 ## 历史流程数据参考规则
 
-本节**只适用于 `createForm` 之后组装首次 `data` 那一步，而且只在返回里没有 `data` 时**（有 `data` 就直接用，本节整套都不要走）——`createRequest` 返回 `missingFields`（必填缺失）后**一律不看历史值、直接问用户**（见「createRequest 返回后的处置」）。历史流程数据有两个来源：命令随 `createForm` 给的 `historyRequestData`，以及你自己按它的范围说明核对过的同类历史流程。**历史流程里的字段值只能按下面六条使用**——六条之外一律不推算、不拼接、不凭印象补值：
+本节**只适用于 `createForm` 之后组装首次 `data` 那一步**——`createRequest` 返回 `missingFields`（必填缺失）后**一律不看历史值、直接问用户**（见「createRequest 返回后的处置」）。历史流程数据有两个来源：命令随 `createForm` 给的 `historyRequestData`，以及你自己按它的范围说明核对过的同类历史流程。**历史流程里的字段值只能按下面六条使用**——六条之外一律不推算、不拼接、不凭印象补值：
 
 1. **取值一致、且能推断与本次业务同类 → 可直接采用**：某个字段在**命中的历史流程里取值完全一致**（**一条也算**），并且对照这些历史流程的**其他字段值**，能推断它们和本次要填写的表单属于同一类业务时，直接把这个值填进 `data`，不必再问用户；**取值不一致**时，才需要**三条及以上**取值相同（同样要满足"能推断与本次同类业务"），否则按规则 2 处理或问用户。
 2. **看得出规律 → 按规律生成新值**：历史取值呈现可推断的规律（如编号递增、日期递推、金额分档）时，按该规律生成本次的新值；**规律推不出来就不要用**，照常问用户。
@@ -298,9 +273,9 @@
 - 不传凭据：业务输入禁止出现 Cookie/ETEAMSID/Token/`header.operator`（CLI 托管）。
 - **`data` 的键只能取 `fields` 里的字段 id**（那就是可写字段的全集）。**唯一例外：`missingFields` 点名的字段**——`missingFields` 是**按你本次实际填的值、结合显示属性（联动）规则实时算出来的"最新缺失必填项"**，而 `fields` 是 `createForm` 那一刻的**静态快照**：那时联动还没跑，联动命中后才变成必填的字段当时可能既不在 `fields` 里（若原被联动隐藏）、也不在你的视野里。所以补值**一律以 `missingFields` 为准**，不要因为"它不在 `fields` 里"就把用户给的这条值丢掉。`readOnly` / `disableEdit` / 不可见字段**一个都不要传**——传了整单会被拒（`notEditable`），得把只读字段全部摘掉重跑一轮。**看到 `notEditable` 不要重试、不要换字段 id 绕过**，移除这些字段后重跑。
 - 大表单超线时（stdout 只有一句话、没有 `fields`），**先按 `resultFile` 把那个文件一次读完**再拼 `data`（见「返回」的大表单超线形态）；未超线时 `fields` 就在 stdout 里，不必读文件。
-- 附件/文件：附件字段需上传本地文件时，口径见「填值纪律」的「附件 / 发票字段」——先提醒用户"上传的附件会先经过公网大模型，请谨慎操作"，用户确认后用 **`weaver-e10-caizhilian` 技能**（`caizhilian.file-upload.*`）上传取 `file_id`。**不要另走独立的文件上传技能**（那套双登录模式不属于本 CLI 上传接口）。
+- 附件/文件：附件字段需上传本地文件时，口径见「附件 / 发票字段怎么填」——先提醒用户"上传的附件会先经过公网大模型，请谨慎操作"，用户确认后用 **`weaver-e10-caizhilian` 技能**（`caizhilian.file-upload.*`）上传取 `file_id`。**不要另走独立的文件上传技能**（那套双登录模式不属于本 CLI 上传接口）。
 - 附件上传限制：上传前核对该字段的上传限制，不满足先告知用户、不执行上传。看该字段的 `fileUploadParams` 三项——`sizeLimit`（MB）、`formatLimit`（`mode` + `formats`；`formats` 为 `*.*` / `*` 表示不限制后缀）、`maxNum`（数量上限），在 `fields` 里该字段那一条上。
-- 发票字段（componentKey `EinvoiceComponent`）：口径见「填值纪律」的「附件 / 发票字段」，支持两种赋值方式：① 从票夹选取：使用 `weaver-e10-yepiaotong` 技能查询票夹里已有的发票对象（拿 `fid` 后 `invoice.browse-field.data` 取对象）；② 使用 `weaver-e10-yepiaotong` 技能上传本地发票文件（`invoice.upload`）并取上传后的发票对象。方式 ② 在真正上传前必须先提醒用户"上传的发票文件会先经过公网大模型，请谨慎操作"，用户明确确认后才执行；方式 ① 无需这句提醒。用户未明确发票字段如何赋值时，先反问用户，不需要提前检测 `weaver-e10-yepiaotong` 技能是否可用，真正需要使用上述两种方式给发票赋值时，workbuddy环境下可直接到技能市场搜索【泛微E10业票通发票管理】并自动安装，搜索不到时反馈给用户，其余环境遇到技能缺失时直接反馈给用户。
+- 发票字段（componentKey `EinvoiceComponent`）：口径见「附件 / 发票字段怎么填」，支持两种赋值方式：① 从票夹选取：使用 `weaver-e10-yepiaotong` 技能查询票夹里已有的发票对象（拿 `fid` 后 `invoice.browse-field.data` 取对象）；② 使用 `weaver-e10-yepiaotong` 技能上传本地发票文件（`invoice.upload`）并取上传后的发票对象。方式 ② 在真正上传前必须先提醒用户"上传的发票文件会先经过公网大模型，请谨慎操作"，用户明确确认后才执行；方式 ① 无需这句提醒。用户未明确发票字段如何赋值时，先反问用户，不需要提前检测 `weaver-e10-yepiaotong` 技能是否可用，真正需要使用上述两种方式给发票赋值时，workbuddy环境下可直接到技能市场搜索【泛微E10业票通发票管理】并自动安装，搜索不到时反馈给用户，其余环境遇到技能缺失时直接反馈给用户。
 - 发票类字段的历史值不可照抄。
 - 发票值拿不到时直接问用户。
 - **日期 / 时间字段按用户说的填即可，不要管格式**：CLI 会按字段自带格式自动归一化（`2026-8-21` / `2026年8月21日 9:5` 都会规整成字段要求的写法；日期+时间控件只给到日期时补 `00:00`）。**不要为格式反复权衡，也不要手工补时间**。
@@ -340,21 +315,21 @@
 
 ## 示例
 
-### ① 解析工作流并载入表单（拿到 fields / data / continuation）
+### ① 解析工作流并载入表单（拿到 fields / historyRequestData / systemFields / continuation）
 
 Windows PowerShell：
 
 ```powershell
-weaver-work-cli --json workflow run workflow.createForm --input-json '{"workflow":["<工作流名称>"],"userQuestion":"<用户的填单意图原文>"}'
+weaver-work-cli --json workflow run workflow.createForm --input-json '{"workflow":["<工作流名称>"]}'
 ```
 
 macOS/Linux（bash/zsh）：
 
 ```bash
-weaver-work-cli --json workflow run workflow.createForm --input-json '{"workflow":["<工作流名称>"],"userQuestion":"<用户的填单意图原文>"}'
+weaver-work-cli --json workflow run workflow.createForm --input-json '{"workflow":["<工作流名称>"]}'
 ```
 
-返回里 `data` 就是按 `userQuestion` 算好的字段值；没有 `data` 时改用 `historyRequestData` 自己拼。
+返回里是字段清单 + 历史参考值 + 系统字段；字段值按「填值纪律」自己拼成 `data` 再交给 `createRequest`。
 
 ### ② 填好字段后一次完成发起（action 必填）