weaver-work-cli 0.1.28 → 0.1.31

package/skills/weaver-e10-meeting/references/meeting-invitation.md

@@ -0,0 +1,113 @@
+# 生成会议邀请函（docx）
+
+> operation：`meeting.invitation.render`　风险等级：`read`（只读服务端，只在本地落一个 docx，**不发消息、不写任何接口**）
+> 底层数据源：`meeting.eb.meeting.list` 单查（EB 版会议列表，47 个字段）
+
+## 用途与边界
+
+- **只生成、不发送**：在智能体工作台里按会议真实数据产出一份邀请函 docx，项目人员拿到后自行修改再对外发出。
+- 邀请对象是**一个组织**（客户单位），因此**一份文档对应一个会议**，不做逐人循环、不做定向推送。
+- 模板固定为「泛微标准模板」（随 CLI 包分发，位于 CLI 安装目录 `templates/meeting/invitation.docx`），**不支持替换模板**。
+
+## 入参
+
+| 参数 | 必填 | 说明 |
+| --- | --- | --- |
+| `mtId` | ✓ | 会议 id（EB 版会议主键，长 id 用字符串） |
+| `extra` |  | 键值对。**① 租户自定义字段**，如 `{"guest_org":"某某集团"}`——会议接口不会返回这类字段，只能从这里传；**② 保留键 `agenda`** 手动指定议程（见下文「议程表」），仅在会议没有议题时生效 |
+| `outputPath` |  | 输出文件完整路径；缺省写到 `~/.weaver-work-cli/meeting/invitations/邀请函-{会议名}-{yyyyMMdd}.docx` |
+
+## 出参
+
+`filePath` / `fileName` / `bytes` / `meetingId` / `meetingName` / `filledFields[]` / `pendingFields[]`，以及 `warnings`（有待补充字段时会列出）。
+
+议程相关三个字段：
+
+| 字段 | 含义 |
+| --- | --- |
+| `agendaSource` | `meeting.topic`=按会议议题自动填 / `extra`=调用方传入 / `template`=**没有议题，保留模板示例行** |
+| `agendaRows` | 实际写入议程表的行数（`template` 时为 0） |
+| `agendaTableFilled` | 是否真的重建了议程表 |
+
+> ⚠️ `agendaSource=template` 时会同时给一条 `warnings`：议程表里还是模板的示例行
+> （“15分钟/泛微公司介绍”），提醒人工改成真实议程 —— 客户看到的邀请函不该印着别人的议程。
+
+## 占位符（模板里写这些）
+
+| 层 | 占位符 | 取值来源 | 取不到时 |
+| --- | --- | --- | --- |
+| 标准字段 | `{mt_name}` `{address}` `{hrm_members}` `{total_member}` `{mt_desc}` `{video_url}` `{caller}` `{contacter}` `{company_name}` `{org_members}` `{issuer_company}` `{begin_datetime}` `{end_datetime}` | 会议接口 / CLI 内置 | 高亮【待补充】 |
+| 派生字段 | `{begin_date}` `{begin_weekday}` `{begin_time}` `{end_date}` `{end_time}` `{time_range}` `{issue_date}` | CLI 计算（`issue_date` = **生成当天**，不是会议日期） | 高亮【待补充】 |
+| **同日智能时间** | `{begin_datetime}` `{end_datetime}` | 同日会议：begin=完整、end=**只给时间**，拼出 `2026-10-28 09:00~10:16`；跨日时 end 带完整日期 | 高亮【待补充】 |
+| 外挂字段 | `{guest_org}` 或 `{extra.任意键}` | 入参 `extra` | 高亮【待补充】 |
+| **接口任意字段** | `{该字段的 dataKey}`（如 `{name}` `{updater}`） | 会议接口返回的原始行 | 高亮【待补充】 |
+
+> ⭐ **新增自定义字段不需要改 CLI**：`meeting.eb.meeting.list` 读侧**不投影、不过滤字段**，返回什么就原样带出；
+> 渲染侧对「派生 → 标准 → extra → **接口原始字段**」四级兜底，所以只要在 eBuilder 接口里把字段加进返回列，
+> 模板写 `{该字段的 dataKey}` 就能取值。对象型字段（人员/部门/关联记录）自动取 `name`；多选用「、」拼接。
+> 前提是拿到**字段的 dataKey**（不是中文显示名）。
+
+口径细节：
+
+- **落款单位用 `{company_name}`（公司全称）**：模板落款行就是它。取值顺序为
+  `extra.company_name`（调用方指定，**对外开放时客户传自己的公司名**）→ CLI 内置默认
+  （「上海泛微网络科技股份有限公司」）。E10 组织树里只有「泛微网络」，没有工商全称，所以默认值写在 CLI 里而不是查接口。
+- 另有两个备用占位符：`{org_members}`（会议参会部门，为空时回落到**发起人部门**再回落上级公司，见输出 `orgSource`）、`{issuer_company}`（发起人上级公司）。需要"部门级落款"时改用它们。
+- 发起人部门/公司取会议行的 `creator`（人员 id），调 `hrm.employee.batch` 反查；查人失败**静默降级**，不影响邀请函生成。
+- `{hrm_members}` 接口给的是**英文逗号**分隔的姓名串，CLI 会转成「、」。
+- **取不到值的占位符不会留下 `{xxx}` 字面量**：会渲染成**黄色高亮**的 `【待补充】：字段名`，便于人工定位。
+
+## 议程表：有议题就自动填，没有就保留原样
+
+模板里的议程表是「表头 + 2 行示例数据」的固定结构。渲染时按下面的顺序取议程：
+
+```
+① 会议议题（meeting.eb.topic.list，按 mt_id 过滤）
+     ↓ 有议题就用议题，行数随议题数量增减（多余示例行会被裁掉）
+② extra.agenda（调用方直传，仅在会议没有议题时生效）
+     ↓ 也没有
+③ 保留模板里的示例行（agendaSource=template，并给一条 warning）
+```
+
+议题 → 列的映射（列顺序与模板一致，**表头不动**）：
+
+| 模板列 | 取值 | 来源 |
+| --- | --- | --- |
+| 议程安排 | **议题名称** `topic_title` | 议题库（**不能**用 `name`——那是 eBuilder 自动标题「议题库-某人 时间戳」） |
+| 议程内容 | **议题内容概要** `topic_content` | 议题库 |
+| 议程时间 | `09:00-09:15` | **会议议题明细** `meeting.eb.meeting.detail` → `details.detail1`（议题库表没有 start/end），按 `topic_num` ↔ `detail1.topic_no` 匹配；匹配不上留空 |
+
+- 议题按开始时间升序排，没有时间的排最后（保持接口原顺序）。
+- 建议题时**提议人员/提议单位会自动补默认值**：`proposal_person`=当前操作人、
+  `proposal_dept`=当前操作人所属部门 id（`hrm.employee.batch` 的 `departmentId`，查不到则留空不阻塞）。
+- **行格式继承模板**：第 N 行沿用模板第 N 行的底纹/字体/对齐，超出时克隆最后一行，所以版式不变。
+- `extra.agenda` 的写法是**每行一条、换行或分号分隔**，格式 `议程安排|议程内容|议程时间`
+  （即 `议题名称|内容概要|时间段`）：
+
+```json
+{ "extra": { "guest_org": "某某集团", "agenda": "公司介绍|泛微整体介绍|14:00-14:30\n方案讲解|产品方案演示|14:30-16:00" } }
+```
+
+- **议题表在部分租户未注册**（返回空数组属正常），此时会静默走 ②③，不会报错。
+
+## 示例
+
+Windows PowerShell：
+
+```powershell
+weaver-work-cli --json meeting run meeting.invitation.render --input-json '{"mtId":"<会议id>","extra":{"guest_org":"某某集团"}}'
+```
+
+macOS/Linux：
+
+```bash
+weaver-work-cli --json meeting run meeting.invitation.render --input-json '{"mtId":"<会议id>","extra":{"guest_org":"某某集团"}}'
+```
+
+## 注意事项
+
+- **不要用 `meeting.eb.meeting.detail` 取数据**：该接口**在部分环境只返回 `{id}`**（部分环境），取不到字段；
+  邀请函统一走 `meeting.eb.meeting.list` 单查。⚠️ 但另一类环境（部分环境）detail 会返回完整 51 个字段 ——
+  所以**不能一概而论，跨环境稳妥做法仍是 list 单查**。
+- 生成后如需把文件发给对方，**本 operation 不提供发送能力**（IM/邮件都不走这里），由使用者自行处理。
+- 模板出错时会在本地抛 `template_missing`，提示 CLI 包缺少 `templates/meeting/invitation.docx`；此时重装 CLI 即可，不要手工改模板路径。

package/skills/weaver-e10-meeting/references/meeting-lifecycle.md

@@ -21,18 +21,18 @@
 Windows PowerShell：
 
 ```powershell
-weaver-work-cli --json meeting run meeting.cancel.prepare --input-json '{"id":"1305624900858404950"}'
+weaver-work-cli --json meeting run meeting.cancel.prepare --input-json '{"id":"<会议id>"}'
 # 用户确认后（continuation 原样传入）：
-weaver-work-cli --json meeting run meeting.cancel.apply --input-json '{"confirm":true,"continuation":"<prepare返回>","id":"1305624900858404950"}'
-weaver-work-cli --json meeting run meeting.delete.prepare --input-json '{"id":"1305624900858404950"}'
+weaver-work-cli --json meeting run meeting.cancel.apply --input-json '{"confirm":true,"continuation":"<prepare返回>","id":"<会议id>"}'
+weaver-work-cli --json meeting run meeting.delete.prepare --input-json '{"id":"<会议id>"}'
 ```
 
 macOS/Linux（bash/zsh）：
 
 ```bash
-weaver-work-cli --json meeting run meeting.cancel.prepare --input-json '{"id":"1305624900858404950"}'
-weaver-work-cli --json meeting run meeting.cancel.apply --input-json '{"confirm":true,"continuation":"<prepare返回>","id":"1305624900858404950"}'
-weaver-work-cli --json meeting run meeting.delete.prepare --input-json '{"id":"1305624900858404950"}'
+weaver-work-cli --json meeting run meeting.cancel.prepare --input-json '{"id":"<会议id>"}'
+weaver-work-cli --json meeting run meeting.cancel.apply --input-json '{"confirm":true,"continuation":"<prepare返回>","id":"<会议id>"}'
+weaver-work-cli --json meeting run meeting.delete.prepare --input-json '{"id":"<会议id>"}'
 ```
 
 ## 输出处理

package/skills/weaver-e10-meeting/references/meeting-minute-file.md

@@ -0,0 +1,425 @@
+# 给纪要挂附件并回填文字（上传 → 解析 → 写回）
+
+> 涉及 operation：`meeting.attachment.upload`（新增，2026-10-26）、`meeting.eb.minute.create` / `.update`
+> 风险等级：`read-before-write`（只写文件服务和纪要字段，不动会议主表）
+
+## 为什么要这套东西
+
+纪要的两个"内容"字段含义不同，别混：
+
+| 字段 | 含义 | 谁生成 |
+| --- | --- | --- |
+| `minutes_content` | **原始文字**：文档 OCR/文字提取结果，或音频转写原文（带 `角色1/角色2` 说话人） | 智能体解析附件后写入 |
+| `parse_content` | **会议纪要文案**：按"生成纪要"提示词产出的结构化纪要（HTML 富文本） | 智能体根据 `minutes_content` 生成后写入 |
+
+`doc_file` / `video_file` 存的是**附件 id**（接口文档口径：「按文件id」），不是 URL、不是路径。
+
+## ⛔ 接口不会触发解析
+
+实测验证：
+
+- `create_mt_minute` / `update_mt_minute` **只写字段**，`video_taskId` / `parse_content` 始终为空；
+- 服务端 ASR / 文字提取由**会议详情页**触发，接口调不动；
+- 所以 CLI 建的音频/文档纪要，**不要对用户说"已开始解析"**。
+
+## ✅ 正确分工：CLI 管传输与落库，智能体管解析
+
+```
+① meeting.attachment.upload                    本地文件 → 附件 id
+      ↓
+② meeting.eb.minute.create / .update           写 file_type + doc_file/video_file
+      ↓
+③ 智能体自己解析（见下表）                       得到原文
+      ↓
+④ meeting.eb.minute.update                     minutes_content = 原文
+      ↓
+⑤ 智能体按"生成纪要"提示词生成结构化纪要
+      ↓
+⑥ meeting.eb.minute.update                     parse_content = 纪要文案
+```
+
+### 第 ③ 步：不同类型的附件用什么解析
+
+| 附件类型 | 怎么解析 | 说明 |
+| --- | --- | --- |
+| `.mp4` / `.mp3` / `.m4a` / `.wav` / `.amr` … | **智能体自带的音频转写能力** | 支持 mp4，最大 1GB / 5 小时，带说话人分离与时间轴，无需本地 ffmpeg |
+
+#### ⚠️ 说话人分离 ≠ 认人：转写结果里没有姓名
+
+转写输出的形如 `[起始秒,结束秒,说话人编号]`，**第三个字段只是"同一个人"的聚类编号**（0/1/2…），
+不是姓名、也不是账号 id。E10 平台自己的纪要同样如此 —— 现有数据的 `minutes_content` 里写的就是
+`角色1：…` / `角色2：…`。
+
+**所以：不许把编号直接写成真人姓名。** 没有声纹注册就没有身份对应关系，硬写就是编造。
+
+可用但不保证准确的推断方式（必须标"待确认"，不能当事实写进纪要）：
+
+1. **点名 + 紧随回应**：A 喊了某人名字，紧接着编号 N 应答 → N 大概率是那个人
+   （例："哎，韩超，你来操作吗？" → 下一位说话的编号多半是韩超）；
+2. **参会人名单收敛**：把候选限制在 `hrm_members` 名单内，编号数量若等于名单人数，可按"主持/被点名"辅助排序；
+3. **自我介绍**："我是 XX" 这类自报家门最可靠，优先采信。
+
+工程上最稳的做法：`minutes_content` 保留 `角色N` 原样，在纪要末尾附一张**待确认对照表**
+（`角色1 = ______`），让人工一次性填完；或让主持人开场各自报名。
+**`parse_content` 里凡涉及"谁说的"，只要来源是推断，就必须写明"（据对话推断，待确认）"。**
+
+| `.docx` | 直接解包读 `word/document.xml` 的文本（CLI 侧有零依赖 ZIP 读取器，也可在智能体侧读） | 表格按 Markdown 还原 |
+| `.pdf` / 图片 / 扫描件 | 智能体直接读该文件（多模态 + OCR） | 逐页提取 |
+| `.xlsx` / `.pptx` | 按工作表 / 幻灯片顺序提取 | |
+
+> 要点：**CLI 不需要内置 ASR/OCR**。解析交给智能体，CLI 只负责"文件进得去、文字写得回"。
+
+## `meeting.attachment.upload`
+
+### 入参
+
+| 参数 | 必填 | 说明 |
+| --- | --- | --- |
+| `file` | ✓ | 本地文件绝对路径 |
+| `name` |  | 附件显示名，默认取文件名 |
+| `module` |  | 文件归属模块，默认 `meeting` |
+| `fileFrom` |  | 来源标记，默认 `meeting_info` |
+| `permission` |  | 文件权限，默认 `3` |
+| `shareUsers` / `shareGroups` |  | 额外分享给的用户/群（可选） |
+| `timeoutMs` |  | 上传超时，默认 300000（5 分钟）。大文件别调小 |
+
+### 出参
+
+`fileId`（**这就是要塞进 `doc_file` / `video_file` 的值**）/ `name` / `size` / `md5` / `module` /
+`uploadType` / `reused` / `recovered` / `durationMs` / `next`
+
+### 两个保护行为（都是实测踩出来的）
+
+- **秒传**：同 md5 的文件已在文件服务里，直接返回已有 `fileId`（`reused: true`），不再传文件体。
+- **超时复核**：实传超时/断连后会自动再预检一次；若按 md5 查到文件已落地，按成功返回
+  （`recovered: true` + warning）。**避免"报错但其实成功了"导致重复上传。**
+  ⚠️ 拿到 `recovered: true` **绝对不要重试上传**。
+
+### 限制
+
+- 上传前会把整个文件读进内存，**>256MB 直接拒绝**（`file_too_large`）。
+- 大文件上传耗时只受网络上行限制，接口本身很快（预检热态约 1s）。
+
+## 示例
+
+Windows PowerShell：
+
+```powershell
+# ① 上传音频，拿附件 id
+weaver-work-cli --json meeting run meeting.attachment.upload --input-json '{"file":"./rec.mp4"}'
+
+# ② 建音频纪要并挂上附件（file_type=1 音频 / 0 文档）
+weaver-work-cli --json meeting run meeting.eb.minute.create.prepare --input-json '{"mt_id":"<会议id>","mt_minutes_subject":"周会录音","file_type":"1","video_file":"<上一步 fileId>"}'
+weaver-work-cli --json meeting run meeting.eb.minute.create.apply --input-json '{"confirm":true,"continuation":"<上一步 continuation>"}'
+
+# ③ 智能体解析音频 → 把原文写回 minutes_content
+weaver-work-cli --json meeting run meeting.eb.minute.update.prepare --input-json '{"id":"<纪要id>","mt_id":"<会议id>","minutes_content":"<解析出的原文>"}'
+```
+
+macOS/Linux：
+
+```bash
+# 命令与 Windows PowerShell 完全一致，仅路径写法不同
+weaver-work-cli --json meeting run meeting.attachment.upload --input-json '{"file":"./rec.mp4"}'
+```
+
+## 判断解析状态（别信 `minutes_status`）
+
+全库 33 条纪要中 28 条 `minutes_status=1（生成中）`，但内容早就有了 —— 该字段不推进。按这个判：
+
+```
+video_taskResult == '1' 且 parse_content 非空   → 已完成
+video_taskResult == '2'                        → 生成失败
+两者皆空                                        → 从未触发解析
+```
+
+## 文件模块（module）怎么选 —— 实测
+
+| module 值 | 结果 |
+| --- | --- |
+| `meeting` | ✅ 合法，上传成功（17291B 文档约 0.93s 返回 fileid） |
+| `meetingeb` | ❌ `code:20005 模块参数错误` |
+| `im` / `mail` | ✅ 合法，但属于别的业务线 |
+
+**结论：EB 版会议不需要单独的模块名，就用 `module=meeting`。** 文件模块是「业务模块」维度，不是「应用版本」维度。
+
+其余实测口径：
+
+- 纪要 `doc_file` / `video_file` 里存的就是**一个纯 id**（无 URL、无 JSON）。
+  对比页面创建的纪要（`doc_file=<页面创建的doc_file>`）与本 CLI 上传后写入的（`doc_file=<CLI写入的doc_file>`），
+  字段形态完全一致。
+- 秒传返回结构与 im 不同：业务模块走 `data.uploadModuleDto.fileid`，im 走 `data.imUploadInfoDto.fileObj.id`。
+  **两套都要认**，否则会出现"秒传成功却取不到 id"。
+- ⚠️ 秒传不是每次都命中：同一文件按 `module=meeting` 传过一次后再预检，仍可能返回 `uploadType=common`。
+  去重维度不只看 md5（可能还带 refId/permission），**不要依赖秒传来保证不产生重复文件**。
+
+## ESB 解析链路
+
+三个动作流都可用 `esbFlowId` 或 `uniqueIndent` 触发，走 `esb.trigger.prepare → apply`。
+
+> ⚠️ **表里的 id / primary_key 都是租户级配置**，各环境不同，换租户必须替换。
+> `meeting.minute.fromGroupChat` 内置了参考租户的默认值（生成纪要 / 生成文档两条），
+> 其他租户用入参 `flowGenerateMinutes` / `flowGenerateDocument` 覆盖；解析附件那条由调用方显式传 `esbFlowId`。
+
+| 用途 | esbFlowId | primary_key | mainTable |
+| --- | --- | --- | --- |
+| **解析附件**（文档同步 / 音视频异步） | `<解析附件flowId>` | `<解析附件uniqueIndent>` | `mtAIMinutePageID*`、`minuteId*`、`mt_id*`；可选 `doc_file` / `video_file` / `file_type` |
+| **保存解析并生成文档** | `<生成文档flowId>` | `<生成文档uniqueIndent>` | `parse_content*`、`mt_minute_id*` |
+| 解析文本生成智能纪要（备用） | `<生成纪要flowId>` | `<生成纪要uniqueIndent>` | `minuteId*` |
+
+调用示例（解析附件）：
+
+```bash
+weaver-work-cli esb run esb.trigger.prepare --input-json '{"employeeId":"<员工id>","esbFlowId":"<解析附件flowId>","customParams":{"mainTable":{"minuteId":"<纪要id>","mt_id":"<会议id>","file_type":"1","video_file":"<附件id>","mtAIMinutePageID":""}}}'
+weaver-work-cli esb run esb.trigger.apply --input-json '{"continuation":"<上一步返回值>","confirm":true}'
+```
+
+### ⚠️ 音频：不要同步等，也**不要**去调「获取解析纪要音频结果」
+
+- 那个流程是**1 分钟一轮的定时任务**，它会自己把结果写回表单；
+- 我们再去调 = 第二个消费者，可能重复处理/覆盖；
+- 正确做法：触发后立刻返回，**60 秒后用 `meeting.minute.parseStatus` 查一次**。
+
+### 状态推进规则（全链路实测验证后的口径）
+
+| 阶段 | `minutes_status` | 谁写的 |
+| --- | --- | --- |
+| 刚挂附件、未解析 | `0` 解析中 | CLI（建纪要时传） |
+| 音频解析中 | `3` 文字提取中 | **服务端**，同时写 `video_taskId`、`video_taskResult=0` |
+| 原文就绪（文档/音频**都一样**） | `4` 文字提取完成 | **服务端**（文档同步、音频异步，都会写 4） |
+| 纪要文案已生成 | `1` 生成中 | **ESB「解析文本生成纪要」`…633`** |
+| 文档已生成并回写 OA | `2` 已完成 + `mt_minutes=<文档id>` | **ESB「保存解析并生成文档」`…628`** |
+
+`meeting.minute.writeContent` 的自动规则（只在你自己写内容时用，正常 ESB 链路不用它）：
+
+| 写入内容 | 自动置为 |
+| --- | --- |
+| `parse_content`（纪要文案） | **1 生成中**（2 留给 ESB 在生成文档后写） |
+| `minutes_content`（原文，文档和音频都一样） | **4 文字提取完成** |
+
+> ⚠️ 两条实测更正：
+> ① 音频原文就绪是 **4**，不是 2（此前按"音频终态=2"实现，实测推翻）；
+> ② 写完纪要文案是 **1 生成中**，不是 2 —— 2 由 ESB `…628` 在文档生成后自己写。
+> 照这两个口径走，才不会出现"同一平台两种状态"的矛盾。
+
+### 单次查进度：`meeting.minute.parseStatus`
+
+返回 `state` 与**下一步动作** `nextAction`，Agent 照 `nextAction` 做即可，不用自己推理：
+
+| `state` | `nextAction` | 含义 / 该做什么 |
+| --- | --- | --- |
+| `idle` | `trigger_parse` | 未触发解析：确认已挂附件后调 ESB「解析附件」`<解析附件flowId>` |
+| `pending` | `wait_then_check` | 后台在跑：**60 秒后再查一次**，不要连续轮询 |
+| `extracted` | `generate_minutes` | 原文就绪（状态 4）：调 ESB「解析文本生成纪要」`<生成纪要flowId>`，只传 `minuteId` |
+| `minutes_ready` | `generate_document` | 纪要文案就绪（状态 1）：**直接调 ESB「保存解析并生成文档」`<生成文档flowId>`**，不用问用户 |
+| `done` | `none` | 文档已生成（`mt_minutes` 有值、状态 2），链结束 |
+| `failed` | `manual_check` | 后台失败：到会议详情页看原因，**不要标成已完成** |
+
+另有 `contentReady` / `minutesReady` / `documentReady` 三个布尔，**判断进度用它们，不要用 `minutes_status`**。
+
+### 实测
+
+**文档路径已跑通，实测时序：**
+
+```
+① attachment.upload       2.3 s   → fileId
+② minute.create.apply     8.1 s   ← 带 doc_file 附件时明显变慢（纯文本纪要仅 0.1 s）
+③ esb.trigger.apply      >60 s    ← 超时！但动作流仍在后台跑完（文档解析是**同步**的）
+④ 约 1 分钟后查纪要          minutes_content 559 字 ✅ / minutes_status "4" ✅（服务端写的）
+⑤ writeContent 写纪要文案   0.7 s   → status 自动 2，回读一致
+```
+
+**音频路径实测时序（同一环境，23.3MB mp4）：**
+
+```
+① attachment.upload      10.3 s   → fileId（真实传输，约 2.3 MB/s）
+② minute.create.apply     0.1 s   ← 音频纪要反而快
+③ esb.trigger.apply       8.9 s   ✅ **没有超时**（异步流程立即返回）
+④ +31 s   status=3 文字提取中 | video_taskId 已生成 | video_taskResult=0 | 原文 0 字
+   +111 s  status=4 | video_taskResult=1 | 原文 3986 字
+```
+
+⇒ **文档是同步的（会顶到 60s 超时），音频是异步的（8.9s 返回）**，
+两者在"原文就绪"后服务端都写 `status=4`。
+
+**收尾两步（同一音频纪要实测，全链路闭环）：**
+
+```
+⑥ ESB …633「解析文本生成纪要」mainTable: {minuteId}
+     → 返回 resultCode 200 执行成功
+     → parse_content 2733 字（结构化纪要：会议主题/时间/地点/召集人/参会人员…）
+     → minutes_status **1（生成中）**
+
+⑦ ESB …628「保存解析并生成文档」mainTable: {parse_content, mt_minute_id}
+     → 返回 resultCode 200，responseData.customData.mainTable.wdID = <wdID>
+     → 纪要的 mt_minutes 被回写为该文档 id
+     → minutes_status **2（已完成）**
+```
+
+⇒ 所以这两个 ESB **自己做完了全部写入与状态推进**，CLI 不需要写 `parse_content`、也不需要改状态。
+
+三条必须记住的结论：
+
+1. **`esb.trigger.apply` 是同步阻塞的**：它等动作流跑完才返回。文档解析也可能超过 60 秒上限。
+   ⇒ 超时报 `write_uncertain` **不代表没执行**，必须查纪要字段，不能盲目重试。
+2. **服务端自己会推进状态**（这里写成了 `4 文字提取完成`）——
+   所以 `writeContent` 的自动状态只是兜底，**不要硬改成与事实不符的值**。
+3. **`mtAIMinutePageID` 在本租户是 `<智能纪要页面id>`**（从页面创建的纪要反查得到）。
+   传给解析动作流后流程正常执行 ⇒ 它是一个**固定的页面 id**，不是每条纪要各自生成的。
+   对外开放时这个值随应用走，需按租户配置，不要写死成泛微的。
+
+### ✅ 生成文档不用问用户
+
+用户原话："肯定要生成的啊，不要问"。所以 `minutes_ready` 状态下**直接**调 ESB `…628`，
+生成完把结果（文档 id、状态 2）告诉用户即可，**不要停下来问"要不要生成"**。
+
+（此前版本要求"先问用户"，已按用户最新指令撤销。）
+
+## 从群聊消息生成纪要
+
+**入口是会议，不是群**：正常场景是"拿着会议生成纪要"，群 id 从会议记录里取。
+
+**现在一条命令搞定**：`meeting.minute.fromGroupChat`（`pipeline` = `text`/`minutes`/`document`）。
+实测 pipeline=text 全流程 **0.5–1.2 秒**（读会议 0.2s + 拉消息 0.13s + 建纪要 0.11s），
+换成 scripts 里手动串命令要 6 秒 —— 进程内调用省掉了 5 次 CLI 冷启动。
+
+### ⚠️ 权限边界（别误判成接口问题）
+
+读消息用的是**当前登录账号的会话**调 E10 自己的接口：
+
+```
+POST /api/em/msg/executeIm/chat/syncGroupMsg
+```
+
+所以：
+
+- 只能读到**这个账号所在的群**；
+- 会议关联的群如果当前账号不在里面（别人建的群），**返回空** —— 这是权限，不是 bug；
+- 客户环境里用小E 服务账号跑时，要确认该账号在会议群里。
+
+### 消息量大（几千/几万条）怎么办
+
+真正的瓶颈不是拉取，是 **ESB 633 要把 `minutes_content` 整段喂给模型**，几十万字会失败或效果崩。
+所以分三层挡：
+
+| 层 | 手段 | 说明 |
+| --- | --- | --- |
+| **拉取收敛** | 默认时间窗 = `max(会议创建时间, 开始前 7 天)` ~ `min(现在, 结束后 2 小时)` | 会前在群里分工的那几天会被覆盖；跨度受 im 侧 7 天上限约束 |
+| **采样去噪** | 条数 > `sampleThreshold`（默认 200）时自动采样 | 必留：被 @ 的、含"负责/决定/截止/完成/风险/方案"等关键词的；丢弃：单字回复（嗯/好/收到）、纯表情、连续同人复读；每人非关键消息最多 `perSenderLimit` 条（默认 60），防止刷屏者淹没别人 |
+| **摘要版兜底** | 原文超 `maxTranscriptChars`（默认 20000 字）时自动降级 | 只保留**分工/结论/待办**类发言，表头写明"共 N 条、仅保留 K 条"；完整原文另存文件；`digest=false` 可关（不推荐） |
+| **分层生成** | `pipeline` 分档 | `text` 只出原文（秒级），确认无误再 `minutes`/`document` |
+
+#### 实测
+
+| 场景 | 拉取耗时 | 端到端 | 结果 |
+| --- | --- | --- | --- |
+| 默认（阈值 200 + 摘要 20000） | **2.36s**（1200 条 / 24 页） | **2.9s** | 采样保留 **114** 条、丢弃 1086；原文 11035 字 → 未触发摘要 |
+| 关采样（`sampleThreshold:100000`） | 2.03s | 2.3s | 原文 **145,034 字** → 摘要版压到 **19,969 字**，完整原文落盘 |
+
+⇒ **拉取不是瓶颈**（约 1.7–2ms/条，5000 条约 9s），真正要控的是喂给 ESB 的长度。
+⇒ 采样后原文基本稳定在 1 万字上下（与消息总数几乎无关），所以"几千条"不会把纪要撑爆；
+只有**关掉采样**时才需要摘要版兜底。
+
+采样是**显式**的：返回 `sampled` / `sampledDropped`，`warnings` 里写明"已采样，保留 X 条、丢弃 Y 条"——
+**必须如实告诉用户"这份纪要是采样后生成的"**，不能让他以为是全量。
+
+### 摘要版（超长兜底，约定）
+
+采样压完仍超 `maxTranscriptChars` 时，**不硬塞全文**，改为只保留有决策价值的发言：
+
+| 返回字段 | 含义 |
+| --- | --- |
+| `digestMode` | 是否走了摘要版 |
+| `digestDropped` | 摘要阶段丢弃的闲聊条数 |
+| `digestTruncated` | 摘要本身仍超长、已按时间截断（保留最早发言，通常是分工与背景） |
+| `fullTranscriptPath` | **完整原文落盘路径**（`<CLI state>/state/transcripts/<会议id>-<时间>.txt`） |
+| `transcriptLength` / `fullTranscriptLength` | 实际写进纪要的字数 / 完整原文字数 |
+
+写进 `minutes_content` 的内容长这样（实测，11 条消息里 5 条闲聊被过滤）：
+
+```
+【群聊摘要：共 10 条消息，仅保留与分工/结论/待办相关的 5 条，省略 5 条】
+2026/10/26 17:09:51 张三：@李四  你负责 测试
+2026/10/26 17:10:04 张三：@user1@example.com   你负责会议纪要的功能开发
+2026/10/26 17:10:12 张三：@user3@example.com  你负责 会议日历的开发
+2026/10/26 17:10:20 张三：@user2@example.com  你负责 整体的进度跟进
+2026/10/26 17:10:35 张三：然后 所有的功能 都需要 实时汇报进度
+```
+
+⛔ **`digestMode=true` 时必须告诉用户"这是摘要口径，不是逐字全文"，并给出 `fullTranscriptPath`。**
+否则用户会以为纪要漏了内容，而实际上是我们主动省略的。
+
+需要全量时：调大 `sampleThreshold`、或传更窄的 `from`/`to`、或 `sampling=false`（几千条会非常慢，慎用）。
+`maxTranscriptChars` 也可调大，但**超过模型上下文长度时 ESB 633 会直接失败**，不是慢的问题。
+
+下面是它内部的口径（保留下来便于排错）：
+
+```
+会议 id
+ → meeting.eb.meeting.list 单查（按 mt_id）取 imchat_groupid
+ → im.msg.sync.group { groupId, num: 50 }
+ → 按 msgtime **升序重排**（接口返回是倒序：新→旧）
+ → 过滤 typeName='通知'（入群/改名等系统消息），但要统计条数告诉用户
+ → 拼原文："时间 说话人：内容" 逐行
+ → meeting.eb.minute.create（minutes_content=原文, minutes_status=4, mt_minutes_ai_page）
+ → ESB 633（minuteId）→ parse_content + 状态 1
+ → ESB 628（parse_content + mt_minute_id）→ 文档 + mt_minutes + 状态 2
+```
+
+**⚠️ 群聊与用户材料是「合并」而不是二选一**：只要会议有 `imchat_groupid`，
+即便用户另外给了 `files`（本地材料，能抽文本就抽）或 `content`（直接给的正文），
+群聊记录照样并入，材料排在群聊前面（`===== 用户提供的会议材料 =====` / `===== 群聊记录（N 条）=====`）。
+只有既没有群、也没有材料时才报 `group_missing`；有群但窗内无消息时只 warning、仍用材料建纪要。
+
+### `im.msg.sync.group` 的返回口径
+
+| 字段 | 说明 |
+| --- | --- |
+| `msgid` / `msgtime` / `time` | 消息 id / 秒级时间戳 / 显示时间 |
+| `sender` | **自己发的消息返回 `我`**，别人的返回姓名 |
+| `from_uid` | 发送人 **IM uid**（不是 HRM 员工 id） |
+| `typeName` | `文本` / `通知`（系统消息）/ 图片、文件等 |
+| `content` | 文本内容；非文本消息可能为空，请看 `media` |
+
+参数：`groupId`（必填）、`num`、`latest`、`from`/`to`（时间范围）、`startId`/`endId`。
+
+### ⚠️ 三个坑
+
+1. **顺序是倒的**：接口按新→旧返回，拼原文前必须按 `msgtime` 升序重排，否则纪要时间线是反的。
+2. **`sender='我'` 不是人名**：要显示真名得拿 `from_uid` 调 `im.person.resolveByIds` 换。
+3. **IM uid ≠ HRM 员工 id**：从群消息里提任务、要写 `executors` 时，必须先 uid → 实名 → HRM id 两步转换；
+   而且**邮箱样式的账号（如 `user1@example.com`）也是真实员工**（批量导入的账号名就是邮箱）——
+   **必须用 `username` 查 HRM**：`hrm.employee.query {username:'user1@example.com'}`
+   → `user1@example.com (1300000000000000005)`，且该 id **正好等于 IM 的 `from_uid`**。
+   ⚠️ 用 `email` 或 `keyword` 查**查不到**（实测 0 条），别因此误判"这个人不存在"。
+
+### 实测耗时（会议 AAAAAA / 群 1790…003 / 11 条消息）
+
+```
+读会议+取群 id        2.2 s
+拉群消息              2.1 s
+拼原文（365 字）       1.3 s
+建纪要                0.6 s
+ESB 633 生成纪要文案   37.4 s   ← AI 生成，最慢的一步，不要以为卡死
+ESB 628 生成文档       3.0 s
+--------------------------------------------------
+端到端                约 46 s（不含人工确认）
+```
+
+### 决议任务怎么落
+
+用户口径：任务**统一走决议任务**，由 ESB 自动生成督办任务，CLI 只需生成决议：
+
+```
+meeting.eb.decision.publish（mt_content + detail1，每条 detail1 = 一项任务）
+  → 内部写决议 + 回写会议（is_decision=2 / mt_status=8）
+  → ESB 自动按明细生成「决议任务」
+meeting.eb.decisionTask.list  ← 核对任务是否生成（实测 5 s 内可见）
+```
+
+⚠️ `decision.publish` 会把会议 `mt_status` 置成 **8（结束）** —— 对未来的会议也一样，属于服务端口径。
+
+### ❗待办：`mtAIMinutePageID`
+
+它是"发消息提醒时拼接跳转链接"用的页面 id（对应纪要表 `mt_minutes_ai_page`），
+用户确认**可以先忽略、不影响主逻辑**，暂时传空串；后续由 ESB 侧回写或约定生成规则后再补。

package/skills/weaver-e10-meeting/references/meeting-queries.md

@@ -20,9 +20,9 @@ weaver-work-cli --json meeting run meeting.list --input-json '{"filterDate":"202
 weaver-work-cli --json meeting today
 weaver-work-cli --json meeting run meeting.room.list --input-json '{"beginDate":"2026-09-11 09:00","endDate":"2026-09-11 10:00","onlyAvailable":true}'
 weaver-work-cli --json meeting run meeting.type.list --input-json '{"name":"项目","includeCount":true}'
-weaver-work-cli --json meeting run meeting.room.usage --input-json '{"roomid":"1297870848451641350","bywhat":4,"currentdate":"2026-09-11"}'
+weaver-work-cli --json meeting run meeting.room.usage --input-json '{"roomid":"<会议室id>","bywhat":4,"currentdate":"2026-09-11"}'
 weaver-work-cli --json meeting run meeting.calendar.base --input-json '{}'
-weaver-work-cli --json meeting run meeting.detail.field --input-json '{"id":"1305624900858404950"}'
+weaver-work-cli --json meeting run meeting.detail.field --input-json '{"id":"<会议id>"}'
 ```
 
 macOS/Linux（bash/zsh）：
@@ -33,9 +33,9 @@ weaver-work-cli --json meeting run meeting.list --input-json '{"filterDate":"202
 weaver-work-cli --json meeting today
 weaver-work-cli --json meeting run meeting.room.list --input-json '{"beginDate":"2026-09-11 09:00","endDate":"2026-09-11 10:00","onlyAvailable":true}'
 weaver-work-cli --json meeting run meeting.type.list --input-json '{"name":"项目","includeCount":true}'
-weaver-work-cli --json meeting run meeting.room.usage --input-json '{"roomid":"1297870848451641350","bywhat":4,"currentdate":"2026-09-11"}'
+weaver-work-cli --json meeting run meeting.room.usage --input-json '{"roomid":"<会议室id>","bywhat":4,"currentdate":"2026-09-11"}'
 weaver-work-cli --json meeting run meeting.calendar.base --input-json '{}'
-weaver-work-cli --json meeting run meeting.detail.field --input-json '{"id":"1305624900858404950"}'
+weaver-work-cli --json meeting run meeting.detail.field --input-json '{"id":"<会议id>"}'
 ```
 
 ## 输出处理

package/skills/weaver-e10-meeting/references/meeting-receipts-signs.md

@@ -9,12 +9,12 @@
 ### 回执
 
 - 回执更新**必须传回执记录主键 `id`**（不是 `memberId`）；`prepare` 会自动按 `memberId` 回查定位。
-- ⚠️ **`memberId` 字段语义（2026-10-08 真机实测，两个环境一致）**：`meeting.receipt.list` 返回的一条回执里，
+- ⚠️ **`memberId` 字段语义**：`meeting.receipt.list` 返回的一条回执里，
   **`memberId` 是「姓名」、`memberIdId` 才是「人员 id」**。因此 `receipt.update.prepare` 的 `memberId`
   **两种写法都接受**（人员 id 或姓名）；CLI 会按 `memberIdId` / `memberId` 依次匹配，并在写请求 body 里统一带上**解析后的人员 id**。
   列表输出的原始字段保持原样（`memberId`=姓名、`memberIdId`=人员 id），**不要**把 `memberId` 当成 id 使用。
 - `attendStatus` 枚举：`0`=未填写、`1`=参加、`2`=不参加（回执"否/请假"传 2）。
-- 回执列表接口必须带 `isMobile`（CLI 缺省 `false`）**与 `memberType`（CLI 缺省 `1`）**：2026-10-08 真机实测
+- 回执列表接口必须带 `isMobile`（CLI 缺省 `false`）**与 `memberType`（CLI 缺省 `1`）**：实测
   **不传 `memberType` 必报 500「系统内部错误」**（此前只挡住了 `isMobile`），两者均已由 CLI 托管，调用方无需显式传。
 
 ### 签到
@@ -32,28 +32,28 @@
 Windows PowerShell：
 
 ```powershell
-weaver-work-cli --json meeting run meeting.receipt.list --input-json '{"mtId":"1305624900858404950"}'
-weaver-work-cli --json meeting run meeting.receipt.update.prepare --input-json '{"mtId":"1305624900858404950","memberId":"101","attendStatus":2,"remark":"请假"}'
+weaver-work-cli --json meeting run meeting.receipt.list --input-json '{"mtId":"<会议id>"}'
+weaver-work-cli --json meeting run meeting.receipt.update.prepare --input-json '{"mtId":"<会议id>","memberId":"101","attendStatus":2,"remark":"请假"}'
 # 用户确认后：
 weaver-work-cli --json meeting run meeting.receipt.update.apply --input-json '{"confirm":true,"continuation":"<prepare返回的continuation>"}'
-weaver-work-cli --json meeting run meeting.sign.list --input-json '{"mtId":"1305624900858404950"}'
+weaver-work-cli --json meeting run meeting.sign.list --input-json '{"mtId":"<会议id>"}'
 # 补签（id 取 sign.list 里的 signs[].id）：
-weaver-work-cli --json meeting run meeting.sign.mark.prepare --input-json '{"id":"1305624900858404951"}'
-weaver-work-cli --json meeting run meeting.sign.mark.apply --input-json '{"confirm":true,"continuation":"<prepare返回的continuation>","id":"1305624900858404951"}'
+weaver-work-cli --json meeting run meeting.sign.mark.prepare --input-json '{"id":"<签到记录id>"}'
+weaver-work-cli --json meeting run meeting.sign.mark.apply --input-json '{"confirm":true,"continuation":"<prepare返回的continuation>","id":"<签到记录id>"}'
 # 补签退 / 清除签到（同构，换 operation）：
-weaver-work-cli --json meeting run meeting.sign.back.prepare --input-json '{"id":"1305624900858404951"}'
-weaver-work-cli --json meeting run meeting.sign.clear.prepare --input-json '{"id":"1305624900858404951"}'
+weaver-work-cli --json meeting run meeting.sign.back.prepare --input-json '{"id":"<签到记录id>"}'
+weaver-work-cli --json meeting run meeting.sign.clear.prepare --input-json '{"id":"<签到记录id>"}'
 ```
 
 macOS/Linux（bash/zsh）：
 
 ```bash
-weaver-work-cli --json meeting run meeting.receipt.list --input-json '{"mtId":"1305624900858404950"}'
-weaver-work-cli --json meeting run meeting.sign.list --input-json '{"mtId":"1305624900858404950"}'
-weaver-work-cli --json meeting run meeting.sign.mark.prepare --input-json '{"id":"1305624900858404951"}'
-weaver-work-cli --json meeting run meeting.sign.mark.apply --input-json '{"confirm":true,"continuation":"<prepare返回的continuation>","id":"1305624900858404951"}'
-weaver-work-cli --json meeting run meeting.sign.back.prepare --input-json '{"id":"1305624900858404951"}'
-weaver-work-cli --json meeting run meeting.sign.clear.prepare --input-json '{"id":"1305624900858404951"}'
+weaver-work-cli --json meeting run meeting.receipt.list --input-json '{"mtId":"<会议id>"}'
+weaver-work-cli --json meeting run meeting.sign.list --input-json '{"mtId":"<会议id>"}'
+weaver-work-cli --json meeting run meeting.sign.mark.prepare --input-json '{"id":"<签到记录id>"}'
+weaver-work-cli --json meeting run meeting.sign.mark.apply --input-json '{"confirm":true,"continuation":"<prepare返回的continuation>","id":"<签到记录id>"}'
+weaver-work-cli --json meeting run meeting.sign.back.prepare --input-json '{"id":"<签到记录id>"}'
+weaver-work-cli --json meeting run meeting.sign.clear.prepare --input-json '{"id":"<签到记录id>"}'
 ```
 
 ## 输出处理