weaver-work-cli 0.1.33 → 0.1.36

package/dist/shortcuts/workflow/operations/form.js

@@ -26,6 +26,7 @@ import { continuationReplayError } from '../continuation.js';
 import { writeStateFileBestEffort } from '../state.js';
 import { buildHistoryRequestData, fetchHistoryListSnapshot, filterHistoryRequestData, pickUniqueMineWorkflow, prefetchHistoryDetails } from './read.js';
 import { hasXiaoEEnv } from '../../../internal/e10/auth/xiaoe.js';
+import { createFetchTimingSink, runWithFetchTiming } from '../../../internal/e10/fetch-timing.js';
 import { buildChatSceneInput, formatLocalNow, requestFormFill } from './chatscene.js';
 // ---------------------------------------------------------------------------
 // 常量（与 Python 源逐条对齐）
@@ -1485,7 +1486,23 @@ async function resolveCreateWorkflow(rawWorkflow, env) {
     // 澄清文案里回显的是**用户原话**（不是切分后的关键词）——用户要能认出自己给的条件
     const queryText = rawTerms.join('、');
     if (!rawTerms.length) {
-        throw workflowClarificationError('workflow', '', '要发起哪个流程？请提供该流程的完整名称（或其它可用于检索的关键词）后再继续。');
+        // ★ 2026-10-30 用户裁定：这一档不是「名称没匹配上」，而是**必填入参 `workflow` 根本没给**
+        // （缺键 / 空数组 / 空字符串都算）。原先与「只给了填充词」共用同一句澄清，模型看到的是
+        // 「请提供完整名称」，于是键名写错（如写成 `workflows`、`name`）时不知道自己漏了 `workflow`，
+        // 只会回头把锅甩给用户。现在单独标 `clarificationReason=workflow_required` 并下发
+        // `missingInput` + `requiredInput`，让模型知道「是我少传了入参、要按这个形态补」。
+        throw workflowClarificationError('workflow', '', '要发起哪个流程？请提供该流程的完整名称（或其它可用于检索的关键词）后再继续。', [], {
+            clarificationReason: 'workflow_required',
+            missingInput: ['workflow'],
+            requiredInput: {
+                workflow: {
+                    required: true,
+                    type: 'string | string[]',
+                    description: '要发起的工作流：完整名称、名称关键词，或「名称(ID)」；纯数字按工作流 ID 处理。',
+                    example: ['费用报销'],
+                },
+            },
+        });
     }
     // 先做**纯本地**的解析：显式 ID（`名称(ID)` / 纯数字）与名称关键词（一格可含多个，见
     // `splitCreateKeywords`）。这一步不依赖远端结果，于是能先判"到底有没有可用条件"——
@@ -1751,9 +1768,9 @@ function singleExplicitWorkflowId(rawWorkflow) {
     return parsed.id ?? (/^[0-9]+$/.test(terms[0]) ? terms[0] : '');
 }
 /** 表单载入 + 该工作流的记忆：两者只共享 `workflowId`，可以并行。 */
-async function loadCreateFormPack(workflowId, env) {
+async function loadCreateFormPack(workflowId, env, options = {}) {
     const [{ data }, workflowMemory] = await Promise.all([
-        buildCreateFormData(workflowId, env),
+        buildCreateFormData(workflowId, env, options),
         // 记忆读取是 best-effort（内部全 catch），不会把表单载入的错误顶掉。
         fetchWorkflowMemory(workflowId, env),
     ]);
@@ -1839,7 +1856,7 @@ async function resolveIntentFill(pack, userQuestion, baseUrl, env) {
  * 现在返回的就是纯取数结果：`fields` + `historyRequestData` + `systemFields` + 记忆，
  * 由模型自己拼 `data` 后交给 `createRequest`。
  */
-async function prepareCreateFormPayload(args, env) {
+async function prepareCreateFormPayload(args, env, options = {}) {
     // 会话是**惰性**加载的（`ensureSession` 只在首次调用时填充）。本命令随后会并发发起多个请求，
     // 先在这里显式取一次，避免并发首调各自走一遍会话初始化。
     //
@@ -1858,11 +1875,11 @@ async function prepareCreateFormPayload(args, env) {
         // `commonParam.authInfo` 给出；该 ID 不可用时由载入表单一侧的 `readCreateFormBlock`
         // 抛出**可判别**的澄清（不是把它伪装成"没有匹配到可发起的工作流"）。
         target = { id: explicitId, name: '', source: 'workflowId' };
-        pack = await loadCreateFormPack(explicitId, env);
+        pack = await loadCreateFormPack(explicitId, env, options);
     }
     else {
         target = await resolveCreateWorkflow(args.workflow, env);
-        pack = await loadCreateFormPack(target.id, env);
+        pack = await loadCreateFormPack(target.id, env, options);
     }
     // ★ 2026-10-15 用户裁定：`createForm` 改用**字符口径 20,000** 的**严格档**（见
     // `CREATE_FORM_STDOUT_SAFE_CHARS` / `compactFormOutput` 的 `charBudget`）。
@@ -1954,7 +1971,21 @@ async function commandCreateForm(args, env) {
  * 与旧版的差别只有一处：`workflowId` 由调用方（`resolveCreateWorkflow`）解析好后传进来，
  * 不再是本函数的入参校验点。
  */
-async function buildCreateFormData(workflowId, env) {
+async function buildCreateFormData(workflowId, env, options = {}) {
+    /**
+     * 明细字段的标记形态（2026-10-30 用户裁定）：
+     * - 缺省 `subFormId` —— `createForm` 口径，明细字段带 `subFormId`（`data.details` 的键）；
+     * - `isDetail` —— `createRequestDirect` 独有的口径，明细字段带 `isDetail: true`、不再下发 `subFormId`。
+     */
+    const detailMark = options.detailMark === 'isDetail' ? 'isDetail' : 'subFormId';
+    /**
+     * ★ 2026-10-30 用户裁定：`getHistory` 是 `createRequestDirect` 的**隐藏入参**（只在 CLI 实现层支持，
+     * 不进 `inputSchema`、不进 skill）。传 `false` 时「历史发起流程」这一段整块不做 ——
+     * 不发 `getMineListData`（列表）、不发明细，也不要组装；输出里 `historyRequestData` 直接给 `null`。
+     *
+     * 缺省（含 `createForm` 这一侧，它从不传）一律按 `true`，行为与从前一字不差。
+     */
+    const getHistory = options.getHistory !== false;
     const query = { workflowId, isCreate: 1, ...AJAX_QUERY };
     const body = { workflowId, isCreate: 1, isMobile: 0 };
     /**
@@ -1965,7 +1996,9 @@ async function buildCreateFormData(workflowId, env) {
      * `.catch(() => null)` 是必须的：这个 Promise 可能因为表单后续抛错而**没人 await**，
      * 兜住之后就不会留下未处理的拒绝；真要暴露的认证/网络错误由同批的载入请求抛出，不会被吞掉。
      */
-    const historyListSnapshot = fetchHistoryListSnapshot(env, { workflowId }).catch(() => null);
+    const historyListSnapshot = getHistory
+        ? fetchHistoryListSnapshot(env, { workflowId }).catch(() => null)
+        : Promise.resolve(null);
     /**
      * 明细请求紧跟着**列表**走（2026-10-29 用户口径）：它的入参只有 `requestId`（列表给的）与会话
      * `userId`，与 `getFormLayout` **没有任何参数依赖**；原先排在 layout 之后纯属写法问题，白等约
@@ -1976,7 +2009,9 @@ async function buildCreateFormData(workflowId, env) {
      * 空处理免得留下未处理的拒绝。真正的认证/网络错误仍由 `buildHistoryRequestData` 里那次 `await`
      * 决定去留（口径不变）。
      */
-    const historyDetails = historyListSnapshot.then(async (snapshot) => (snapshot && snapshot.requestIds.length ? prefetchHistoryDetails(env, snapshot) : null));
+    const historyDetails = getHistory
+        ? historyListSnapshot.then(async (snapshot) => (snapshot && snapshot.requestIds.length ? prefetchHistoryDetails(env, snapshot) : null))
+        : Promise.resolve(null);
     historyDetails.catch(() => { });
     // 2026-09-22：这四个接口**彼此没有数据依赖**（入参只需要 workflowId，见各自的 query/body），
     // 真机实测各 171–429 ms、串行合计约 1.1 s；并行后只受最慢的一个约束。
@@ -2254,12 +2289,20 @@ async function buildCreateFormData(workflowId, env) {
         // 不在当前布局上的字段不下发——模型既填不了也看不到。
         if (!modelFieldIds.has(String(field.id ?? '')))
             continue;
-        // 键序 id|name|subFormId|componentKey 是契约；`subFormId` **为空就整个省略**（缺该键＝主表字段）
-        // —— 主表字段占绝大多数，写 `""` 恒白占一条键（真机 278 字段表单：100 个主表字段 × 22 B ≈ 2.2 KB）。
+        // 明细标记**按命令分档**（2026-10-30 用户裁定：改成 isDetail 只对 `createRequestDirect` 生效）：
+        // - `createRequestDirect`：键序 `id|name|isDetail|componentKey`，明细字段带 `isDetail: true`，
+        //   主表字段**整个省略**该键（缺键＝主表；恒写 `isDetail:false` 白占体积），且**不下发** `subFormId`；
+        // - `createForm`（默认档）：维持原口径，明细字段带 `subFormId`（它就是 `data.details` 的键），
+        //   主表字段省略该键。
         const slimSubFormId = String(field.subFormId ?? '');
         const item = { id: field.id, name: field.name };
-        if (slimSubFormId)
+        if (detailMark === 'isDetail') {
+            if (slimSubFormId)
+                item.isDetail = true;
+        }
+        else if (slimSubFormId) {
             item.subFormId = slimSubFormId;
+        }
         item.componentKey = field.componentKey;
         // 表单初始化时就有的值（OA 预填 + onLoadForm 联动带出）——有才出现该键；**没有默认值的字段不带**。
         // CLI 拼 `data` 时会自动并入，模型**不必显式传**；用户本次明确改写了它才按用户说的覆盖（见
@@ -2335,7 +2378,7 @@ async function buildCreateFormData(workflowId, env) {
             ...requiredFieldsList.map((f) => String(f?.id ?? '')),
             ...Object.values(subFormRequired).flatMap((list) => list.map((f) => String(f?.id ?? ''))),
         ].filter(Boolean))];
-    const historyCache = fields.length
+    const historyCache = getHistory && fields.length
         ? await buildHistoryRequestData(env, fields, historyRequiredFieldIds.map((id) => ({ id, name: String((fieldsById.get(id) || {}).name ?? id) })), { allFormFields: true, workflowId }, 
         // 本命令开头就已并发发起的列表请求：这里只补「详情」那几步（P2）。
         historyListSnapshot, 
@@ -2407,7 +2450,9 @@ async function buildCreateFormData(workflowId, env) {
             // 历史参考值（近一年、非草稿、最近 5 条「我发起的」）——填值前先看它，能直接照用的字段就别去
             // 问用户。字段范围与 `fields` **同一口径**（见 modelFieldIds 注释）；完整结果（本表单全部字段）
             // 仍随句柄留给 `createRequest` 用（条件必填要到那边才现身）。
-            historyRequestData: filterHistoryRequestData(historyCache, modelFieldIds),
+            // `getHistory:false`（隐藏入参）时整段历史取数没做 ⇒ 这里给 `null`（不是空数组：空数组表示
+            // "查了但没数据"，两者含义不同）。
+            historyRequestData: getHistory ? filterHistoryRequestData(historyCache, modelFieldIds) : null,
             systemFields: {
                 permissions: minorInfo.permissions || {},
                 defaults: context.systemFields.defaults,
@@ -3821,9 +3866,11 @@ async function runFieldLinkage(env, ctx, entries, actionTypes, allDetails, isEdi
     }
     if (!dataList.length && !runDataList.length)
         return [];
+    // 建模表单的联动接口 `module` 是 `ebuilderform`（与布局 / 保存的 `ebuildercard` 不同，真机请求体实证）。
+    const linkageModule = formModuleName(ctx.frame && ctx.frame.relate_type, 'ebuilderform');
     const executeParam = {
         formId: ctx.layout.form_id,
-        module: 'workflow',
+        module: linkageModule,
         dataList,
         runDataList,
         moduleDataList: [],
@@ -3867,9 +3914,10 @@ async function runFieldLinkage(env, ctx, entries, actionTypes, allDetails, isEdi
         if (frame.layout_multi_id)
             executeParam.layoutId = frame.layout_multi_id;
     }
-    const payload = { formId: ctx.layout.form_id, module: 'workflow', executeParam };
+    const payload = { formId: ctx.layout.form_id, module: linkageModule, executeParam };
     const relateType = (ctx.frame && ctx.frame.relate_type) || '';
-    const endpoint = formApiUrl(FORM_ENDPOINTS.fdLinkage, relateType);
+    // 建模表单的联动接口在 `/api/ebuilder/form/` 下，与布局 / 保存的 `/api/ebuilder/flow/` 不同（真机实证）。
+    const endpoint = formApiUrl(FORM_ENDPOINTS.fdLinkage, relateType, '/api/ebuilder/form/');
     const response = await requestJson(env, 'POST', endpoint, AJAX_QUERY, payload);
     // requestJson 内部已解包一层（responseData），此处不可再取 .data
     const data = (response && typeof response === 'object') ? response : null;
@@ -4646,6 +4694,8 @@ function linkageResultNotice(linkageDetails, fields, hiddenSubforms, rowHidden,
  *   的就是与普通链路同一段代码），它们不是必填判定。
  * - 句柄**不消费**：本分支在任何写请求之前返回，同一个 `context` 之后仍可正常重发。
  * - `title` 取**工作流名称**；`src` 与两处 `routerProps_*` 的 `initialEntries` 用**工作流 id**；
+ *   `src` 末尾另按 `&<字段id>=<值>` 拼上本次要填的字段（2026-10-30 用户裁定，与下面
+ *   `params.customParams` 同一份数据）；
  *   `params.customParams` 取 `createRequest` **入参**经解析后的字段值（不含表单默认值、不含联动带出的值），
  *   同段 `fieldAssignKeys` 列出这次要填的**全部字段 id**（`,` 连接）。
  */
@@ -4798,10 +4848,31 @@ function xiaoECustomParams(preview) {
     }
     return { values, keys: ordered };
 }
+/**
+ * `src` 末尾的字段参数（2026-10-30 用户裁定）：`&<字段id>=<值>`，与 `params.customParams` 里那份
+ * 字段值**同一份数据、同一顺序**（`fieldAssignKeys` 是元信息，不进 URL）。
+ *
+ * 值**原样拼、不做任何百分号编码**：客户端自己解析这段 query（按 `&` 切键值对、再按 `=` 切第一个
+ * 等号），中文、空格、`,` / `;` / `#` 等都不需要转义，拼出来的字面值必须与 `params.customParams`
+ * 里逐字相同。唯一代价是值本身含 `&` 时会截断——按用户口径以此为准，不在此处兜底改写。
+ */
+function xiaoESrcFieldQuery(params) {
+    let query = '';
+    for (const fieldId of params.keys) {
+        const text = params.values[fieldId];
+        if (!text)
+            continue;
+        query += `&${fieldId}=${text}`;
+    }
+    return query;
+}
 /**
  * 渲染 `<browsertool>` 块（该块**整体**就是小e 环境下 `createRequest` 的 `finalMarkdown`）。
  *
  * 除 `title` / `src` / 两处 `routerProps_*` 的 `initialEntries` / `params.customParams` 外全部写死。
+ *
+ * `src` 形如 `…/flowpage/create/<workflowId>?workflowId=<workflowId>&isCreate=1&<字段id>=<值>&…`
+ * —— 末尾的字段参数与 `params.customParams` 同源（2026-10-30 用户裁定）。
  */
 function renderXiaoEFillFormMarkdown(params) {
     const base = String(params.baseUrl ?? '').replace(/\/+$/u, '');
@@ -4814,7 +4885,7 @@ function renderXiaoEFillFormMarkdown(params) {
         arguments: {
             type: 'e10',
             title: String(params.title ?? ''),
-            src: `${base}/sp/workflow${createPath}?workflowId=${workflowId}&isCreate=1`,
+            src: `${base}/sp/workflow${createPath}?workflowId=${workflowId}&isCreate=1${xiaoESrcFieldQuery(params.customParams)}`,
             sdkOptions: {
                 compName: XIAOE_FILL_FORM_SDK_OPTIONS.compName,
                 routerType: XIAOE_FILL_FORM_SDK_OPTIONS.routerType,
@@ -4840,7 +4911,8 @@ function renderXiaoEFillFormMarkdown(params) {
  * - `durationMs` = 命令入口 → 结果产出；
  * - `apiDurations` = 每个接口（并行批次合成一个 key，取墙钟、不叠加）；
  * - `apiSlowest` = 每个**真并行**批里谁最慢（`[{ batch, name, ms, items }]`，`ms` 是该接口自身耗时，
- *   `items` 是批内每个成员的 `{ name, at, ms }`，按 `ms` 降序）；
+ *   `items` 是批内每个成员的 `{ name, at, ms, fetchAt, fetchEnd, fetchCost }`，按 `ms` 降序；
+ *   `fetchAt`/`fetchEnd`/`fetchCost` 描述其中纯 fetch 那一段）；
  * - `authMs` = 登录取凭据（首次会话解析）的墙钟 —— 这一段走 auth 层自己的 fetch、不经
  *   `host.workflowRequest`，`apiDurations` 统计不到，单独给一个数才能对上账。
  *
@@ -5469,15 +5541,27 @@ function apiShortName(path) {
  * 给 host 套一层**逐接口计时**（只包请求，不改返回、不吞异常）。
  *
  * `finally` 里落片段：请求失败（超时 / 业务错误 / 抛错）同样要记 —— 恰恰是这类请求最需要看到耗时。
+ *
+ * 片段里除整段耗时外，还记**纯 fetch** 那一段（`fetchMs`，2026-10-30 用户要求）：它由
+ * `runWithFetchTiming` 开一个旁路 sink、`E10RequestRuntime` 在 fetch 前后各打一枪得到，
+ * 两条链路都只读不改请求/返回值。
  */
 function withApiTiming(host, spans) {
     const record = async (path, run) => {
         const start = Date.now();
+        const fetchTiming = createFetchTimingSink();
         try {
-            return await run();
+            return await runWithFetchTiming(fetchTiming, run);
         }
         finally {
-            spans.push({ name: apiShortName(path), start, end: Date.now() });
+            spans.push({
+                name: apiShortName(path),
+                start,
+                end: Date.now(),
+                fetchStart: fetchTiming.fetchStart,
+                fetchEnd: fetchTiming.fetchEnd,
+                fetchMs: fetchTiming.fetchMs,
+            });
         }
     };
     return {
@@ -5506,7 +5590,9 @@ function withApiTiming(host, spans) {
  * - 批内**全是同一个接口**时也不产（如 5 个并发的 `getWorkflowRequest` 取历史详情）：请求都一样，
  *   "谁最慢"没有区分意义，只有批的墙钟有用（2026-10-22 用户第二轮裁定）；
  * - `ms` 取该接口**自身**耗时（`end - start`），不是批墙钟；
- * - 每条另带 `items`：批内**每个**成员的 `{name, at, ms}`（`at` 相对批起点），按 `ms` 降序。
+ * - 每条另带 `items`：批内**每个**成员的 `{name, at, ms, fetchAt, fetchEnd, fetchCost}`（`at` 相对批
+ *   起点；`ms` 自身耗时；`fetchAt`/`fetchEnd` 是其中**纯 fetch**（发出请求 → 收到响应头）的起止偏移、
+ *   `fetchCost` 是它的耗时，2026-10-30 用户要求），按 `ms` 降序。
  *   2026-10-26 用户要求：只看最慢项判断不出「优化它值不值」——若批内多个接口耗时接近，
  *   砍掉最慢那个的收益有限，得看整条关键路径的分布；
  * - 顺序＝批的时间顺序，与 `apiDurations` 的 key 一一对应。
@@ -5541,13 +5627,17 @@ function summarizeApiSpans(spans) {
         // 批内全是同一个接口 ⇒ 不产最慢项（"5 个 getWorkflowRequest 里谁最慢"没有区分意义）。
         if (group.length > 1 && new Set(names).size > 1) {
             const origin = Math.min(...group.map((item) => item.start));
-            // 批内逐个成员都留一条（`at` 相对批起点，`ms` 自身耗时），按耗时降序；并列取先开始的
-            // （`at` 升序），保证同一份输入每次输出一致。`name`/`ms` 就取这一项。
+            // 批内逐个成员都留一条（`at` 相对批起点，`ms` 自身耗时；`fetchAt`/`fetchEnd` 是其中纯 fetch
+            // 的起止偏移、`fetchCost` 是它自身的耗时），按耗时降序；并列取先开始的（`at` 升序），
+            // 保证同一份输入每次输出一致。`name`/`ms` 就取这一项。
             const items = group
                 .map((item) => ({
                 name: item.name,
                 at: Math.max(0, Math.round(item.start - origin)),
                 ms: Math.max(0, Math.round(item.end - item.start)),
+                fetchAt: item.fetchStart === null ? null : Math.max(0, Math.round(item.fetchStart - origin)),
+                fetchEnd: item.fetchEnd === null ? null : Math.max(0, Math.round(item.fetchEnd - origin)),
+                fetchCost: Math.max(0, Math.round(item.fetchMs)),
             }))
                 .sort((a, b) => (b.ms - a.ms) || (a.at - b.at));
             slowest.push({ batch: key, name: items[0].name, ms: items[0].ms, items });
@@ -5555,6 +5645,26 @@ function summarizeApiSpans(spans) {
     }
     return { durations, slowest };
 }
+/**
+ * `createRequestDirect` 的**隐藏入参** `getHistory` 取值（2026-10-30 用户裁定）。
+ *
+ * 只在 CLI 实现层支持：**不写进** `inputSchema`、不写进 skill 文档，模型侧看不到、也没法从
+ * `workflow schema` 里读到；需要时由调用方（桌面端 / 脚本）自己塞进 `--input-json`。
+ *
+ * 口径：缺省、`null`、`undefined`、空串、其它非 `false` 的真值 ⇒ `true`（与从前的行为完全一致）；
+ * 只有明确表达"不要"的写法才关掉：`false` / `0` / `"false"` / `"0"`（大小写、首尾空格都不敏感）。
+ * 宽松接受字符串是为了调用方从环境变量或配置里透传时不必先转类型。
+ */
+function readHiddenGetHistory(value) {
+    if (value === false || value === 0)
+        return false;
+    if (typeof value === 'string') {
+        const text = value.trim().toLowerCase();
+        if (text === 'false' || text === '0')
+            return false;
+    }
+    return true;
+}
 /**
  * `workflow.createRequestDirect` —— **取数命令**（2026-10-22 用户裁定，语义已变）。
  *
@@ -5576,6 +5686,10 @@ function summarizeApiSpans(spans) {
  * 5. **输出降级**（按 20,000 **字符**，与 `createForm` 同一个宿主口径）：
  *    全量超线 ⇒ `historyRequestData` 留空数组（键还在）；仍超 ⇒ `userMemory` 留空串（键还在；小e 档没有
  *    这个键，不补）；**`fields` 自己也超线时不再裁**（宁大不丢）—— 它是唯一不可省的，砍了这条命令就没有意义。
+ * 6. **隐藏入参 `getHistory`**（2026-10-30 用户裁定）：只在实现层支持，**不进 schema、不进 skill**。
+ *    不传 = `true`（原行为）；传 `false` 时整段「历史发起流程」取数（`getMineListData` 列表 + 明细）
+ *    一次都不发，输出里 `historyRequestData` 直接是 `null`（不是空数组——空数组的意思是"查了但没数据"）。
+ *    这一档也不参与上面的输出降级。
  *
  * ## 耗时
  * 与 `createForm` 完全同口径，全部收在 `timing` 一个桶里：`durationMs`（整条命令）/
@@ -5588,9 +5702,15 @@ async function commandCreateRequestDirect(args, env) {
     // 计时从**命令入口**开始算（含会话解析、工作流消歧、表单载入）。
     const spans = [];
     const timedEnv = { ...env, host: withApiTiming(env.host, spans) };
+    // 隐藏入参（不进 schema / skill）：`false` 时不跑「历史发起流程」那段取数。
+    const getHistory = readHiddenGetHistory(args.getHistory);
     // 取数段本身已经不碰 `chatScene`（`createForm` 自 2026-10-23 起不再接 `userQuestion`），
-    // 这里不必再置空任何入参。
-    const { payload, authMs } = await prepareCreateFormPayload(args, timedEnv);
+    // 这里不必再置空任何入参。`detailMark` 也是**本命令独有**：明细字段标 `isDetail: true`、
+    // 不再下发 `subFormId`（`createForm` 仍走老口径，见 `buildCreateFormData`）。
+    const { payload, authMs } = await prepareCreateFormPayload(args, timedEnv, {
+        getHistory,
+        detailMark: 'isDetail',
+    });
     const contextId = String(payload.contextId ?? '');
     if (!contextId) {
         // `prepareCreateFormPayload` 正常返回时 contextId 必然存在；这里只用来判断
@@ -5625,8 +5745,10 @@ async function commandCreateRequestDirect(args, env) {
     const overLine = () => finalStdoutChars({ ...data, ...reserve }, 'workflow.createRequestDirect') > CREATE_FORM_STDOUT_SAFE_CHARS;
     // 两级降级：先砍历史（留空 key）→ 再砍记忆（留空 key）。`fields` 不参与裁剪。
     // 小e 档没有 `userMemory` 这个键，第二级跳过（不能借"写空串"把它重新加回来）。
+    // `getHistory:false` 时历史那一档本来就没查（值是 `null`）⇒ 不参与降级，否则会把"没查"说成"查了没数据"。
     if (overLine()) {
-        data.historyRequestData = [];
+        if (getHistory)
+            data.historyRequestData = [];
         if ('userMemory' in data && overLine())
             data.userMemory = '';
     }
@@ -5649,10 +5771,30 @@ function formatRemark(value) {
         return text;
     return `_weaverMte_<p>${text.replace(/&/g, '&amp;').replace(/</g, '&lt;').replace(/>/g, '&gt;')}</p>`;
 }
+/**
+ * 表单所属模块名：建模表单（`relateType=WEA_EBUILDER`）按接口取自己的 service 名，其余是 `workflow`。
+ *
+ * 服务端按请求体里的 `module` 解析 `@Service("<module>_FormCoreService")`：建模表单传 `workflow`
+ * 会直接 500「未找到名为 FormCoreService 的实例对象」（2026-10-29 e-cology 建模流程实测：只把该值
+ * 改成 `ebuildercard` 即 200）。所以凡是请求体带 `module` 的表单接口（布局 / 附件 / 保存 / 联动）
+ * 都必须按表单类型取值，不能硬编码。
+ *
+ * ⚠️ 建模表单内部**不是同一个值**，必须按接口分别给（均为真机请求体实证）：
+ * - `getFormLayout` / `saveFormData` / 附件上传 → `ebuildercard`
+ * - `executeFdLinkage` / `getFormDataAndLayout` → `ebuilderform`
+ *
+ * 注意这两个值**不按目录/同族划分**：`getFormDataAndLayout` 与 `getFormLayout` 同在 `form/core` 下，
+ * 前者是 `ebuilderform`、后者是 `ebuildercard`。所以只能按接口真机样例取值，不能靠推断。
+ */
+function formModuleName(relateType, ebModule = 'ebuildercard') {
+    return String(relateType ?? '').trim() === 'WEA_EBUILDER' ? ebModule : 'workflow';
+}
 function buildSaveBody(context, prepared) {
     const runtime = context.runtime;
+    // 顶层 `module` 与 `formData.module` 是同一条判据：建模表单的 saveFormData 也走 ebuilder 的服务。
+    const moduleName = formModuleName(context.frame?.relate_type);
     return {
-        module: 'workflow',
+        module: moduleName,
         customParam: {
             isCreate: true,
             requestId: runtime.request_id,
@@ -5670,7 +5812,7 @@ function buildSaveBody(context, prepared) {
         },
         employeeId: runtime.employee_id,
         formData: {
-            module: 'workflow',
+            module: moduleName,
             presetDataId: runtime.request_id,
             dataDetails: prepared.dataDetails,
             client: 'pc',
@@ -6171,12 +6313,15 @@ async function runCreateNodeFieldVerification(env, context, switches) {
 // ---------------------------------------------------------------------------
 // editLoad / editPrepare / editSave
 // ---------------------------------------------------------------------------
-function buildEditDataLayoutRequest(requestId, workflowId, nodeId, formId, dataId, layoutMultiId, viewFormNodeId, permissionType, runtime) {
+function buildEditDataLayoutRequest(requestId, workflowId, nodeId, formId, dataId, layoutMultiId, viewFormNodeId, permissionType, runtime, relateType) {
     return {
         terminalType: 'PC',
         dataId,
         formId,
-        module: 'workflow',
+        // 建模表单取 `ebuilderform`（2026-10-30 真机请求体实证），**不是** `ebuildercard`：
+        // 同为 `form/core` 下的接口，`getFormLayout` / `saveFormData` 是 `ebuildercard`，
+        // 本接口与 `executeFdLinkage` 是 `ebuilderform` —— 建模表单内部不能按"同族"推定。
+        module: formModuleName(relateType, 'ebuilderform'),
         newLayout: true,
         cacheUid: null,
         layoutMultiId,
@@ -6250,7 +6395,7 @@ async function commandEditLoad(args, env) {
         tenantSetting = {};
     }
     const dataId = requestId;
-    const dlResp = await requestJson(env, 'POST', formApiUrl(FORM_ENDPOINTS.formDataAndLayout, frame.relate_type), { formId: frame.form_id, dataId, ...AJAX_QUERY }, buildEditDataLayoutRequest(requestId, workflowId, runtime.node_id, frame.form_id, dataId, frame.layout_multi_id, frame.view_form_node_id, frame.permission_type, runtime));
+    const dlResp = await requestJson(env, 'POST', formApiUrl(FORM_ENDPOINTS.formDataAndLayout, frame.relate_type), { formId: frame.form_id, dataId, ...AJAX_QUERY }, buildEditDataLayoutRequest(requestId, workflowId, runtime.node_id, frame.form_id, dataId, frame.layout_multi_id, frame.view_form_node_id, frame.permission_type, runtime, frame.relate_type));
     const dlData = dlResp;
     if (!dlData || typeof dlData !== 'object')
         throw workflowApiError('format_error', 'getFormDataAndLayout 未返回有效 data');
@@ -6558,8 +6703,10 @@ async function commandEditPrepare(args, env) {
 }
 function buildEditSaveBody(context, prepared) {
     const runtime = context.runtime || {};
+    // 同 `buildSaveBody`：改已有表单时也按表单类型取 module，建模表单要 `ebuildercard`。
+    const moduleName = formModuleName(context.frame?.relate_type);
     return {
-        module: 'workflow',
+        module: moduleName,
         customParam: {
             isCreate: false,
             requestId: context.requestId ?? context.request_id,
@@ -6579,7 +6726,7 @@ function buildEditSaveBody(context, prepared) {
         formData: {
             id: context.data_id,
             updateTimeStamp: context.update_time_stamp || '',
-            module: 'workflow',
+            module: moduleName,
             dataDelRows: [],
             dataDetails: prepared.dataDetails || [],
             client: 'pc',

package/dist/shortcuts/workflow/operations.js

@@ -59,6 +59,12 @@ function clarificationEnvelope(error, operation) {
         ? details.clarificationQuestion
         : error.message;
     const reason = typeof details.clarificationReason === 'string' ? details.clarificationReason : '';
+    // 必填入参缺失（当前只有 `workflow_required` 一档）时，把「缺了哪个键、该按什么形态补」一并下发：
+    // 模型原先只能看到「请提供完整名称」，无法区分「用户没说要发起什么」与「我键名写错了」。
+    const missingInput = Array.isArray(details.missingInput) ? details.missingInput.map(String) : [];
+    const requiredInput = details.requiredInput && typeof details.requiredInput === 'object'
+        ? details.requiredInput
+        : null;
     return workflowSuccess(operation, {
         type: 'workflowClarification',
         status: 'NEEDS_CLARIFICATION',
@@ -66,6 +72,8 @@ function clarificationEnvelope(error, operation) {
         clarificationKeyword: details.clarificationKeyword ?? null,
         clarificationQuestion: question,
         ...(reason ? { clarificationReason: reason } : {}),
+        ...(missingInput.length ? { missingInput } : {}),
+        ...(missingInput.length && requiredInput ? { requiredInput } : {}),
         candidates,
         candidateCount: candidates.length,
         note: clarificationNote(reason, candidates.length),
@@ -80,10 +88,24 @@ function clarificationEnvelope(error, operation) {
  * - `no_create_right` —— 流程**存在**但当前账号没有发起权限，**绝不能**说成"不存在"
  *   （那正是把"没权限"伪装成"没有这条流程"，与项目纪律相反）。
  *
- * 无 `reason` 时（名称解析 0 / 多命中）保持原文案不变。
+ * 2026-10-30 新增一档：
+ * - `workflow_required` —— **必填入参没给**（缺键/空数组/空字符串）。它不是「名称匹配不到」，
+ *   而是调用方少传了入参；文案必须让模型先认账、再问用户要流程名，而不是让用户去"核对名称"。
+ *
+ * 无 `reason` 时（名称解析 0 / 多命中 / 只给了填充词）保持原文案不变。
  */
 function clarificationNote(reason, candidateCount) {
     const base = '这不是失败，也**不代表查询已执行**：本次查询已停止，没有返回任何流程数据。';
+    // ★ 2026-10-30：`workflow_required` = **必填入参没给**，与「名称匹配不到」性质完全不同。
+    // 这里要模型先认账（少传了入参），而不是去问用户「是不是名字打错了」。
+    if (reason === 'workflow_required') {
+        return '本次命令**没有拿到必填入参 `workflow`**（没写这个键、空数组、空字符串都算没给）——'
+            + '命令停在了查询之前：**没有发起任何流程**，也没有去查可发起列表，'
+            + '这既不是执行失败，也不代表「没有匹配的流程」。'
+            + '请先向用户确认要发起哪个流程（**必须问，不要自己猜，也不要拿相似的名字代替**），'
+            + '再按 `requiredInput.workflow` 给出的形态把入参补上、重发同一条命令。'
+            + '注意 `--input` 接收的是**文件路径**（`-` 表示标准输入），内联 JSON 要用 `--input-json`。';
+    }
     if (reason === 'workflow_not_exist') {
         return base + '请如实告知用户：该工作流不存在（可能已删除或被停用），'
             + '请用户改用该流程的完整名称（或其它可用于检索的关键词）重新指定——**不要向用户索取 ID**。'

package/docs/ehr.md

@@ -56,7 +56,7 @@ weaver-work-cli --json ehr run <operation> --input -
 
 CLI 原样透传整个响应对象，不做重命名；取用方按上表判断。
 
-**每页条数**：由服务端按接口独立配置，**`pageSize` 传参无效**（实测）：通讯录 100、出勤表格类 20、`worktime`/`leave.report` 10、hr 报表 20、薪酬 `bill.list`/`employee.list` 20、`empchange.list` 100。全量数据一律递增 `current` 翻页。
+**每页条数**：由服务端按接口独立配置，**`pageSize` 传参无效**（实测）：通讯录 100、出勤表格类 20、`worktime`/`leave.report` 10、hr 报表 20、薪酬 `bill.list` 20、`empchange.list` 100。全量数据一律递增 `current` 翻页。
 
 **成功响应的 `data` 恒存在**：业务数据为 `undefined` 时（如社保福利、调薪记录为空）统一补为 `null`，避免 `JSON.stringify` 省略该键导致调用方需判断键是否存在。
 

package/docs/fna.md

@@ -21,7 +21,7 @@
 | `fna.expense.reimbursed.sum` | read | POST `expense/center/getSumReimbursedAmountByAi`；body 可空 |
 | `fna.expense.loan.sum` | read | POST `expense/center/getSumLoanAmountByAi`；只认数字 ID；空 data 自动重试 2 次；已知仅统计首条记录缺陷 |
 | `fna.expense.prepay.writeoff.sum` | read | POST `expense/center/selectPrepayWriteOffAmountBySkill`；body 可空 |
-| `fna.expense.chart` | read | GET `getExpenseChart`（`/api/secondev/fna/`）；`userInput` 必填 ≤500 字；`maxRows` 本地截断 1-5000，默认 200；超时 180s；返回 `kind=rows/empty/clarify/blocked/unexpected` |
+| `fna.expense.chart` | read | GET `getExpenseChart`（`/api/secondev/fna/`）；`userInput` 必填 ≤500 字；`maxRows` 本地截断 1-5000，默认 200；超时 180s；返回 `kind=rows/empty/clarify/blocked/unexpected`；无权限文案额外返回 `meta.permissionDenied=true` |
 | `fna.loan.main.page` | read | POST `loanManagementMenu/mainPage` |
 | `fna.loan.main.list` | read | POST `loanManagementMenu/mainPageList`；`current`/`pageSize`/`menuCode`/`permissionSetCode` 必填 |
 | `fna.loan.remind.repay.prepare` | write | 校验 displayData 行并预览，不发送 |
@@ -65,6 +65,7 @@ weaver-work-cli --json fna run fna.invoice.writeoff.list --input-json '{"current
 - `menuCode`/`permissionSetCode` 环境相关，示例值需与环境核对。
 - 超 2^53 的 requestId 无法用 JS 数字精确表达，保留字符串并提示人工核验（真实环境 ID 一般在安全整数内，已按数字发送）。
 - `fna.expense.chart`：`code` 恒为 200，必须按 `data` 类型/`kind` 判成败；追问与安全拦截都是字符串 `data`，`meta.messageKindInferred=true` 表示归类为 CLI 推断。实测真实查询 3.3~66.6s，CLI 超时设 180s，禁止自动重试（每次都会消耗模型额度）。不做当前人强制过滤，结果可能是全租户范围；`userInput` 为商品化输入，个人口径必须改用 `fna.expense.reimbursed.sum`。二开包未安装时该 operation 会 404/500，需与其它 `fna.*` 正常但本 operation 失败区分。
+- `fna.expense.chart` 的权限语义：文案含「权限 / 越权」时 CLI 归类为 `clarify` 并置 `meta.permissionDenied=true`（纯权限提示不带「不明确」关键词也照样识别，避免落进 `unexpected` 被误判）。这是**终止信号**，不是换问法信号：Agent 必须直接告知权限边界，禁止改调 `fna.expense.reimbursed.sum`、`fna.budget.*`、借款 / 核销等接口按部门 / 人员 / 金额拼装同一份报表，也禁止自写 SQL 绕过。
 
 ## 验证
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "weaver-work-cli",
-  "version": "0.1.33",
+  "version": "0.1.36",
   "description": "面向泛微工作工具链的可扩展 TypeScript CLI 基础框架（E10 业票通等能力）",
   "type": "module",
   "main": "./dist/index.js",

package/skill-template/business-info.json

@@ -29,6 +29,24 @@
     "紧急程度",
     "参与人"
   ],
+  "weaver-e10-cowork": [
+    "协作",
+    "协作区",
+    "协作事项",
+    "工作协作",
+    "讨论",
+    "回复讨论",
+    "协作参与人",
+    "共享权限",
+    "申请加入",
+    "待我审批",
+    "我关注的",
+    "我收藏的",
+    "我的事项",
+    "相关我",
+    "结束协作",
+    "协作版块"
+  ],
   "weaver-e10-meeting": [
     "会议",
     "会议室",

package/skill-template/domains/cowork.md

@@ -0,0 +1,14 @@
+本业务域用于 E10 协作区（工作协作）。入口 `SKILL.md` 只做路由与执行纪律：CRITICAL 共享前置、命令面、按场景读 reference、写操作 prepare→确认→apply 协议、输出纪律。具体 operation、字段与失败处理拆到 `references/`：
+
+- `cowork-read.md`：13 类列表（scope）、搜索条件元数据、计数、详情、讨论记录、参与人、关联资源、投票日志、版块表单、元数据、共享权限列表。
+- `cowork-write.md`：新建/结束协作、隐藏/投票、发布讨论、讨论置顶/删除/审批、成员邀请/重新加入/申请加入、加入申请审批、事项与交流审批台、共享对象增删。
+- `safety-boundaries.md`：未实现能力（浏览选择器、点赞组件、权限单元高级配置、搜索 UI 元数据）、红线、能力边界与可见性。
+
+Agent 调优重点：
+
+- `weaver-work-cli cowork schema` 是 operation 合约第一信息源，契约外的命令与参数一律禁止。
+- 业务输入不得包含 Cookie、ETEAMSID、Token、UA；认证与请求头由 `weaver-e10-shared` 与 CLI 托管。
+- 列表筛选用「值字段 + 对应 `*Condition`」；`itemStatus` 取 `1` 进行中 / `2` 已结束（`0` 等于全部）。
+- 动作类写操作（审批、删除、置顶、审批台）的 id 必须先由对应列表查询取得，禁止凭示例或猜测提交。
+- 写操作只接受 CLI 生成的 `continuation`，`confirm=true` 必须在用户明确确认后传入；`partial/write_uncertain` 时先核对现状，禁止自动重试。
+- 查询为空如实说明「没有符合条件的协作或无权查看」，不要断言系统里没有，也不要改用相邻接口拼凑。