weaver-work-cli 0.1.29 → 0.1.31

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

@@ -17,11 +17,12 @@
 | 列表/总数 | 筛选条件走 **URL query**（参数名为 eBuilder 配置的占位符名，如 `hrmmember`、`mt_status`，**不是表 dataKey**）；body 必须带 `datajson`；CLI 先 count 再 list（同条件），`total` 来自 count |
 | 详情 | `getFormDataByPk`，body 顶层 `mainTable.id` |
 | 写操作 | body 用 **`datas` 数组**包裹 `mainTable`（缺 `datas` 会报"datas节点未找到"），`header.operator` 为当前用户 |
-| 日期字段（**两种格式并存，务必看清**） | **① 多数不带秒 `yyyy-MM-dd HH:mm`**：会议 `begin_datetime` / `end_datetime`、决议明细 `begin_datetime` / `end_datetime`；**② 少数必须带秒 `yyyy-MM-dd HH:mm:ss`**：决议任务 `finish_date`、签到 `sign_time` / `signback_time` / `allow_late_time`。传错会报「传入字段:xxx…不满足传入格式」（2026-09-21 真机实测）|
-| **写/改操作的主键** | **update 的主键必须走 URL**（形如 `POST /updateFormData/{interfacePk}?id=<主键>`）：只放在 body 的 `datas[].mainTable.id` 会被拒，报「**主键传入不能为空**」（2026-09-21 真机实测 `update_meeting_sign_info`）。CLI 已按接口声明自动携带，body 里同时保留 `id` 以满足文档「id 必填」。|
-| 人员 id（**分场景，勿混**） | **决议 / 冲突检测 / 会议人员 → HRM 员工 id**（形如 `1305319992400396336`）：`executors`、`rummager`、`hrm_members`、`signMember` 筛选用；**签到表的 `user_id` → 实测存的是 E10 userId**（形如 `6788539829119521816`），补签匹配按它比对。姓名→员工 id 用 `weaver-e10-hrm`。⚠️ 传错**不报错**，但会静默查不到 / 冲突漏检 |
+| 日期字段（**两种格式并存，务必看清**） | **① 多数不带秒 `yyyy-MM-dd HH:mm`**：会议 `begin_datetime` / `end_datetime`、决议明细 `begin_datetime` / `end_datetime`；**② 少数必须带秒 `yyyy-MM-dd HH:mm:ss`**：决议任务 `finish_date`、签到 `sign_time` / `signback_time` / `allow_late_time`。传错会报「传入字段:xxx…不满足传入格式」|
+| **写/改操作的主键** | **update 的主键必须走 URL**（形如 `POST /updateFormData/{interfacePk}?id=<主键>`）：只放在 body 的 `datas[].mainTable.id` 会被拒，报「**主键传入不能为空**」。CLI 已按接口声明自动携带，body 里同时保留 `id` 以满足文档「id 必填」。|
+| 人员 id（**分场景，勿混**） | **决议 / 冲突检测 / 会议人员 → HRM 员工 id**（形如 `1300000000000000000`）：`executors`、`rummager`、`hrm_members`、`signMember` 筛选用；**签到表的 `user_id` → 实测存的是 E10 userId**（形如 `6789000000000000000`），补签匹配按它比对。姓名→员工 id 用 `weaver-e10-hrm`。⚠️ 传错**不报错**，但会静默查不到 / 冲突漏检 |
+| 邮箱样式的账号（`user1@example.com`） | **是真实员工**（批量导入时账号名即邮箱）。查法：`hrm.employee.query {username:'user1@example.com'}` → `user1@example.com (1300000000000000005)`，该 id 与 IM `from_uid` **一致**。⛔ 用 `email` 或 `keyword` 查会得到 **0 条**，别误判成"人不存在" |
 | 新建/更新 | create 不传 id（系统生成）；update/delete 必传 id |
-| **⚠️ 返回结构（必读）** | **人员 / 关联 / 状态 / 选择类字段返回的是「对象数组」，不是字符串**，形如 `[{"name":"崔智友","id":"1305319807700025376"}]` —— 取 id 读 `[0].id`、取显示名读 `[0].name`；**禁止**把整个数组直接当字符串拼接（会显示成 `System.Object[]`，看起来像"字段为空"）。已实测这类字段：`executors` / `rummager` / `mt_id` / `relate_decision` / `decision_status` / `detail1[].executor` / `detail1[].finish_status`；而 `finish_date` / `id` / 日期 / 普通文本字段是字符串 |
+| **⚠️ 返回结构（必读）** | **人员 / 关联 / 状态 / 选择类字段返回的是「对象数组」，不是字符串**，形如 `[{"name":"王五","id":"1300000000000000001"}]` —— 取 id 读 `[0].id`、取显示名读 `[0].name`；**禁止**把整个数组直接当字符串拼接（会显示成 `System.Object[]`，看起来像"字段为空"）。已实测这类字段：`executors` / `rummager` / `mt_id` / `relate_decision` / `decision_status` / `detail1[].executor` / `detail1[].finish_status`；而 `finish_date` / `id` / 日期 / 普通文本字段是字符串 |
 | **⚠️ 写操作失败语义（必读）** | **EB 写接口"报错"≠"没有写入"**：实测 `create_mt_decision` 因字段校验失败（传了不被接受的 `data_status`）返回错误，但主表与明细**已经落库**，重试后产生了**重复决议 + 重复任务**。因此：写操作失败后**必须先回查**（`list` / `detail`）再决定重试或删除；CLI 的语义化写操作（`decision.publish` 等）在拿不到明确成功证据时会抛 **`partial`** 而非普通失败，并按此提示调用方 |
 
 ## operation 清单
@@ -33,17 +34,17 @@
 | 占用 5.x | `meeting.eb.roomUsage.list` / `.detail` | `meeting.eb.roomUsage.create` / `.delete` | query_roomusage_list(+count) / query_roomusage / create_roomusage / delete_roomusage |
 | 签到 1.x | `meeting.eb.sign.list` / `.detail` | `meeting.eb.sign.create` / `.update` | query_meeting_sign_list(+count) / query_meeting_sign_info / create_meeting_sign / update_meeting_sign_info |
 | 回执 4.x | `meeting.eb.receipt.list` / `.detail` | `meeting.eb.receipt.create` / `.update` | query_meeting_receipt_list(+count) / query_meeting_receipt / create_meeting_receipt / update_meeting_receipt |
-| 纪要 3.x | `meeting.eb.minute.list` | **创建未实现**（走 OpenAPI，无自定义 interfacePk） | query_meeting_minute_list(+count) |
+| 纪要 3.x | `meeting.eb.minute.list` / `.detail` / `.create` / `.update` / `.delete` | 写操作走 prepare→apply | query_meeting_minute_list(+count) / query_mt_minute_info / create_mt_minute / update_mt_minute / delete_mt_minute |
 | 会议类型 3.5 | `meeting.eb.type.list` | `meeting.eb.type.create` / `.delete` | query_mt_type_list(+count) / create_mt_type / delete_mt_type |
 | 议题类型 8.x | `meeting.eb.topicType.list` / `.detail` | `meeting.eb.topicType.update` / `.delete` | query_mt_topicType_list(+count) / query_mt_topicType_info / update_mt_topicType_info / delete_mt_topicType_info |
-| 会议议题 9.x | `meeting.eb.topic.list` / `.detail` | `meeting.eb.topic.update` / `.delete` | query_mt_topic_list(+count) / query_mt_topic_info / update_mt_topic_info / delete_mt_topic_info |
+| 会议议题 9.x | `meeting.eb.topic.list` / `.detail` | `meeting.eb.topic.create` / `.update` / `.delete` | query_mt_topic_list + query_mt_topic_count_new / query_mt_topic_info_new / update_mt_topic_info_new / delete_mt_topic_info_new |
 | 应用设置 7.x | `meeting.eb.baseSet.get` | — | query_meeting_baseset |
 | 冲突检测 | `meeting.eb.conflict.room` / `.member`（只读） | — | query_roomusage_list / query_mtDetail_list + query_meeting_receipt_list(+count) |
 | **决议概述** | `meeting.eb.decision.list` / `.detail` | `meeting.eb.decision.create` / `.delete` / **`.publish`（推荐）** | query_mt_decision_list(+count) / query_mt_decision_info / create_mt_decision / delete_mt_decision / update_mt_isdecision |
 | **决议任务** | `meeting.eb.decisionTask.list` | `meeting.eb.decisionTask.update` | query_mt_decision_task_list(+count) / update_mt_decision_task |
 | **补签（语义化）** | — | `meeting.eb.sign.mark` | update_meeting_sign_info（自动定位签到记录 id）|
 
-> ⚠️ **补签务必带时间（或让 CLI 补当前时间）**：2026-10-08 真机实测，只传 `mt_id` + `user_id` 时 update 里没有任何
+> ⚠️ **补签务必带时间（或让 CLI 补当前时间）**：实测，只传 `mt_id` + `user_id` 时 update 里没有任何
 > 时间字段，**服务端照样返回成功、CLI 也报 COMPLETE，但签到记录一点没变**（静默无效）。现 CLI 已兜底：
 > 未传 `sign_time` / `signback_time` / `sign_out_status` 时按"补签"语义**自动补当前时间**（带秒）并写入 `warnings`，
 > 实际写入值在 `preview.after` 里可见；要指定时间请显式传 `sign_time`（`yyyy-MM-dd HH:mm:ss`，带秒）。
@@ -56,7 +57,7 @@ Windows PowerShell：
 weaver-work-cli --json meeting run meeting.env.detect --input-json '{"refresh":true}'
 weaver-work-cli --json meeting run meeting.eb.baseSet.get --input-json '{}'
 weaver-work-cli --json meeting run meeting.eb.meeting.list --input-json '{"hrmmember":"100","mt_status":"2","pageSize":20}'
-weaver-work-cli --json meeting run meeting.eb.meeting.detail --input-json '{"id":"1306126102057902085"}'
+weaver-work-cli --json meeting run meeting.eb.meeting.detail --input-json '{"id":"<会议id>"}'
 weaver-work-cli --json meeting run meeting.eb.meeting.create.prepare --input-json '{"mt_creator":"100","mt_name":"周会","begin_datetime":"2026-09-20 09:00","end_datetime":"2026-09-20 10:30","mt_status":"2","operate_type":"ADD"}'
 ```
 
@@ -66,7 +67,7 @@ macOS/Linux（bash/zsh）：
 weaver-work-cli --json meeting run meeting.env.detect --input-json '{"refresh":true}'
 weaver-work-cli --json meeting run meeting.eb.baseSet.get --input-json '{}'
 weaver-work-cli --json meeting run meeting.eb.meeting.list --input-json '{"hrmmember":"100","mt_status":"2","pageSize":20}'
-weaver-work-cli --json meeting run meeting.eb.meeting.detail --input-json '{"id":"1306126102057902085"}'
+weaver-work-cli --json meeting run meeting.eb.meeting.detail --input-json '{"id":"<会议id>"}'
 weaver-work-cli --json meeting run meeting.eb.meeting.create.prepare --input-json '{"mt_creator":"100","mt_name":"周会","begin_datetime":"2026-09-20 09:00","end_datetime":"2026-09-20 10:30","mt_status":"2","operate_type":"ADD"}'
 ```
 
@@ -77,6 +78,98 @@ weaver-work-cli --json meeting run meeting.eb.meeting.create.prepare --input-jso
 - write prepare：`{ status: 'AWAITING_CONFIRMATION', preview: { interfacePk, kind, body, path, notes }, continuation }`——**先向用户摘要 body 内容再确认**。
 - write apply：`{ status: 'COMPLETE', interfacePk, dataIds }`；回读用对应 list/detail 核对。
 
+## 会议字段全集（依据最新接口文档）
+
+`query_mtDetail_info`（详情）与 `query_mtDetail_list`（列表）**暴露同样 50 个字段**；
+实测详情实际返回 **51 个**（多一个 `qr_code`，文档未收录）。
+
+```
+id, name, creator, create_time, update_time, updater, data_status,
+mt_creator, agenda_id, imchat_groupid, inviters, topic_presenter, project, mt_address_hrms,
+mt_name, decision_Id, quicktimedesc, operate_type, is_decision, mt_type, video_url, with_secauth,
+caller, contacter, project_files, mt_format, mt_desc, mt_accessorys, begin_datetime, end_datetime,
+all_day, mt_hours, address, customize_address, org_members, hrm_members, total_member,
+other_members, crm_members, crm_total_member, next_occur_date, repeat_status, repeat_id,
+request_id, mt_status, attend_user, attending_units, reporting_user, reporting_unit, other_remark
+（实测额外：qr_code）
+```
+
+几组容易搞混的字段：
+
+| 字段 | 含义 | 备注 |
+| --- | --- | --- |
+| `name` vs `mt_name` | `name` 是 eBuilder 记录名（如"会议-张三 2026-10-26"），`mt_name` 才是**会议名称** | 写操作一律用 `mt_name` |
+| `address` vs `customize_address` | 会议室（选中会议室时）+ 自定义地点 | 线上会议一般只填 `customize_address` |
+| `hrm_members` / `attend_user` / `reporting_user` | 参会人员 / 列席人员 / 出席人员（汇总明细） | 传 **HRM 员工 id** |
+| `org_members` / `attending_units` / `reporting_unit` | 参会部门 / 列席单位 / 出席单位（汇总明细） | 传部门 id |
+| `mt_accessorys` / `project_files` | 会议附件 / 项目会议材料 | 值是文件 id（同纪要 `doc_file` 口径） |
+| `crm_members` / `crm_total_member` | 参会客户 / 客户人数 | |
+| `repeat_status` / `repeat_id` / `next_occur_date` | 周期会议三件套 | |
+| `mt_hours` | 时长选项（0:30分钟 1:1小时 2:2小时 3:3小时 4:自定义） | CLI 建会时按 begin/end 自动算成小时数，**不要手填选项值** |
+| `is_decision` / `decision_Id` | 决议状态 / 关联决议 | 由 `meeting.eb.decision.publish` 维护，别手写 |
+
+### 建会 / 变更的可写字段
+
+此前 CLI 的白名单不全（建会只开放 17 个、变更缺 3 个），`customize_address`、`other_remark`、
+`attending_units`、`reporting_unit` 这类字段**根本传不进来**。现已按接口文档补齐到 40 个：
+
+- **建会**：`mt_creator` `mt_name` `begin_datetime` `end_datetime` `mt_status` `operate_type`
+  `is_decision` `mt_type` `caller` `contacter` `mt_format` `mt_desc` `mt_hours` `address`
+  `customize_address` `org_members` `hrm_members` `total_member` `inviters` `topic_presenter`
+  `project` `mt_address_hrms` `quicktimedesc` `video_url` `with_secauth` `project_files`
+  `mt_accessorys` `all_day` `other_members` `crm_members` `crm_total_member` `next_occur_date`
+  `repeat_status` `repeat_id` `request_id` `attend_user` `attending_units` `reporting_user`
+  `reporting_unit` `other_remark`
+- **变更**：同上 + `id` / `decision_Id`（不含 `request_id` 之外的建会专属项）
+
+**不开放**的是系统字段：`id`（变更除外）/`creator`/`create_time`/`update_time`/`updater`/
+`data_status`/`agenda_id`（关联日程）/`imchat_groupid`（群聊 id）/`qr_code`/`name`（用 `mt_name`）。
+
+> 实测验证：建会写入 `customize_address` / `other_remark` / `all_day` 后
+> 回读一致；变更写入 `customize_address` / `other_remark` 回读一致（789 ms）。
+
+## 会议附件（`mt_accessorys`，实测摸清）
+
+### ⭐ 这个字段"写读不对称"
+
+| 方向 | 存的是什么 |
+| --- | --- |
+| **写入** | **文件 id 列表**，逗号分隔（如 `<附件id>`） |
+| **读回** | **文件名列表**，逗号分隔（如 `2023-12-05会议重点.docx`） |
+
+实测验证：建会时写 `mt_accessorys='<附件id>'` → 回读 `"2023-12-05会议重点.docx"` ✅。
+反过来写文件名会得到空槽（`","`），**不是**"存名字"。
+
+### 文件怎么真正归属到会议
+
+上传时带 `refId=<会议 id>`（`meeting.attachment.upload` 的 `refId` 参数），上传返回的 `fileObj.refId`
+就是该会议 id —— 这是文件与记录的绑定；`mt_accessorys` 只是那条记录的**附件 id 列表**。
+
+### ⛔ 无法自动"追加"
+
+读回来只有文件名、**拿不到 id**，而且没有可用的"按 refId 列附件"接口（实测
+`/api/file/queryFileObjects` 传 `refId` 直接 500，`getByRefId` 404）。
+所以 CLI 无法在保留旧附件的前提下自动累加：`meeting.attachment.attach` 提供两种模式：
+
+| mode | 行为 | 注意 |
+| --- | --- | --- |
+| `replace`（默认） | 用本次文件覆盖整个列表 | 会丢原附件，返回 `warnings` 明确列出被覆盖的名字 |
+| `append` | 追加 | **必须传 `existingFileIds`**（调用方自己维护的现有附件 id），否则直接报 `existing_ids_required` |
+
+```bash
+# 挂一个文件（替换）
+weaver-work-cli --json meeting run meeting.attachment.attach --input-json '{"id":"<会议id>","file":"./a.docx"}'
+
+# 追加（需自己带上现有 id）
+weaver-work-cli --json meeting run meeting.attachment.attach --input-json '{"id":"<会议id>","file":"./b.docx","mode":"append","existingFileIds":["<旧文件id>"]}'
+```
+
+### 实测耗时
+
+- 上传（19KB docx，走真实传输）：约 1.4–1.8 s
+- 写 `mt_accessorys`（change_meeting）：约 0.4–0.8 s
+- `fileId` 模式（跳过上传）：约 0.4 s
+
 ## 会议决议与决议任务（EB 版，2026-09-21 新增）
 
 **用途**：把会议成果（结合会议议题、纪要、用户提供的文档/信息）**汇总成决议**，系统按决议明细**自动生成待办任务**，后续可跟踪完成情况。
@@ -90,12 +183,104 @@ weaver-work-cli --json meeting run meeting.eb.meeting.create.prepare --input-jso
 ② （用户配置的 ESB 联动）按决议明细生成「决议任务」数据 —— CLI 不参与、不写任务表
 ③ meeting.eb.decisionTask.list      查任务（按会议 / 执行人 / 状态）
 ④ meeting.eb.decisionTask.update    按执行人更新任务完成状态
+⑤ meeting.eb.decisionTask.create / .delete   直建 / 删除单条任务（create **只做兜底**：常规链路 ESB 已自动生成，勿手工再建）
+⑥ meeting.eb.decision.update / .delete       改 / 删决议概述（改概述与明细；**不会**同步到已生成的任务）
+```
+
+### 触发点
+
+| 动作 | 任务生成 |
+| --- | --- |
+| 只调 `create_mt_decision` | **0 条**（不触发） |
+| 再调 `update_mt_isdecision`（`is_decision=2`） | **1 条明细 → 1 条任务** |
+
+⇒ **任务是被"标记已决议"这一步触发的**，不是被建决议触发的。所以：
+
+- **不要把"建任务"当成链路里的一步**：`publish` 之后任务由 ESB 自动补齐，CLI **不调用** `create_mt_decision_task`；
+  手工再建一条 = 同一件事两个任务。
+- 只建决议不标记 ⇒ 决议有了、任务没有（页面看不到任务，属正常）；
+- 别重复调 `markDecided` —— 每调一次都会再生成一轮任务（重复触发）。
+
+⚠️ **曾被取消的会议会重复生成任务**
+
+实测 6 组对照（每组独立新建会议）：
+
+| 会议状态 | 「建决议 → 标记已决议」间隔 | 1 条明细得到的任务数 |
+|---|---|---|
+| 正常（未开始） | 立刻 | **1** ✅ |
+| **曾被取消** | 立刻 | **2** ❌（同秒、同标题、两条不同 id） |
+| 曾被取消 | 500ms / 1s / 2s / 3s | **1** ✅ |
+| 曾取消但先只建决议、隔 3s 再标记 | — | **1** ✅ |
+| 正常发布后再取消（不再发布） | — | **1** ✅（取消本身不重触发） |
+
+⇒ 触发条件是 **「会议被取消过」+「两步几乎同时」**（窗口 <500ms）。
+判定"取消过"只能看 `operate_type`（实测取消后 `mt_status` 会被写成"结束"，只剩 `operate_type=CANCEL` 留着）。
+
+**CLI 已内置规避**：`meeting.eb.decision.publish.apply` 会先读会议状态，命中"曾取消"就在两步之间插 800ms，
+并返回 warning 说明；正常会议不加延迟（实测 publish 404ms → 曾取消时约 1.2s）。
+若你手工拆成 `decision.create` + `markDecided` 两步，请自己留 ≥500ms 间隔。
+
+### 决议概述的增 / 删 / 改
+
+- 新建：`meeting.eb.decision.create.prepare → apply`（`mt_content` + `detail1 ≥1`）；或直接 `publish`（多一步标记已决议）。
+- 删除：`meeting.eb.decision.delete.prepare → apply`（传概述 id）。
+  ⛔ **删概述不会回收已生成的任务**（实测：删完 决议数 0、任务仍 4 条），任务要另外用 `decisionTask.delete` 删。
+- 更新：`meeting.eb.decision.update.prepare → apply`（`update_mt_decision`，2026-10-27 新增并实测验证）。
+
+#### 更新决议（`update_mt_decision`）实测口径
+
+| 场景 | 传法 | 结果（实测 16:46） |
+|---|---|---|
+| 只改概述文本 | `{id, mt_content}` | ✅ 文本更新，**明细原样保留** |
+| 想改某条明细（默认） | `{id, detail1:[{sort_number:"1", ...}]}` | ❌ **不是改，是又加一行**：明细 2 → 3，两行 `sort_number` 都是 1 |
+| 整组替换明细 | `{id, detail1:[...], detail1Mode:"cover"}` | ✅ 3 → 2 行，明细 id 全换新（删除式覆盖，漏行即丢数据） |
+
+```powershell
+# 只改概述
+weaver-work-cli --json meeting run meeting.eb.decision.update.prepare --input-json '{"id":"<决议id>","mt_content":"<新概述>"}'
+# 整组替换明细（cover）
+weaver-work-cli --json meeting run meeting.eb.decision.update.prepare --input-json '{"id":"<决议id>","detail1":[{"sort_number":"1","decision_title":"<标题>","executors":"<员工id>","begin_datetime":"2026-10-28 09:00","end_datetime":"2026-11-03 18:00","decision_status":"0"}],"detail1Mode":"cover"}'
 ```
 
+⚠️ **两个必须知道的后果**（实测验证）：
+
+1. **改决议不会同步已生成的任务**：概述和明细都改了，任务列表里仍是旧标题、旧时间，任务数也不变。
+   任务要跟着改只能 `decisionTask.delete` 删掉 + `decisionTask.create` 重建。
+2. **更新不会触发 ESB 再生成任务**：两次更新前后任务数都是 2 —— 可以放心改文本，不会糊出重复任务。
+
+> 所以"改一条明细"没有原地更新这条路：要么接受多一行（再用 cover 收拾），要么直接 cover 整组重传。
+
+### 直建 / 删除单条任务
+
+**先看这句**：正常链路（`publish` 写决议 + 标记已决议）之后，ESB 已经自动生成任务了，**不需要、也不应该**再手工建。
+本接口只在「ESB 没触发 / 临时追加一条」时用；建完务必 `decisionTask.list` 回查，避免与 ESB 的任务重复。
+
+```powershell
+# 直建（兜底用）：executor 必须放在 detail1，不要放主表
+weaver-work-cli --json meeting run meeting.eb.decisionTask.create.prepare --input-json '{"mt_id":"<会议id>","relate_decision":"<决议概述id>","decision_title":"<任务>","executors":"<员工id>","rummager":"<员工id>","begin_datetime":"2026-10-28 09:00","end_datetime":"2026-11-03 18:00","detail1":[{"executor":"<员工id>","finish_status":"0"}]}'
+# 删除（传任务 id）
+weaver-work-cli --json meeting run meeting.eb.decisionTask.delete.prepare --input-json '{"id":"<任务id>"}'
+```
+
+#### 字段节点
+
+| 位置 | 字段 | 说明 |
+|---|---|---|
+| `mainTable` | `mt_id` / `relate_decision` / `decision_title` / `executors` / `rummager` / `begin_datetime` / `end_datetime` | `executors` 是执行人**集合**；`rummager` 服务端**必填**（即使实际数据里常为空数组） |
+| `detail1[]` | **`executor`（必填）** / `finish_status` / `finish_date` | 「执行人跟进」子表；**`executor` 放主表会报 `dataKey:executor,该字段不存在`** |
+
+实测（会议 `<会议id>`）：上面这组参数 → `dataIds:["<任务id>"]`，`decisionTask.list` 立即可见。
+这条探针任务随后已用 `delete_mt_decision_task` 删掉（列表回到 1 条）。
+
+> 📌 我此前写"`create_mt_decision_task` 配置自相矛盾、表单缺 `executor`/`finish_status`"是**错的**：
+> 那两个字段在 `detail1` 子表里是有的，是我把 `executor` 拼到了 `mainTable` 才报"字段不存在"。
+> 接口文档本身没错，已按真实节点修正 CLI 与文档。
+
+
 ### 关键字段口径（务必按此传）
 
 - **`mt_content`**：决议概述文本（一段话），由调用方汇总后传入，CLI 不生成内容。
-- **不要传 `data_status`**：`create_mt_decision` **不接受**该字段（真机报 `DataError:dataKey:data_status,该字段不存在`），提交状态由系统自动置 `1`（回查列表 `data_status=1`，ESB 联动照常触发）。
+- **不要传 `data_status`**：`create_mt_decision` **不接受**该字段（实测报 `DataError:dataKey:data_status,该字段不存在`），提交状态由系统自动置 `1`（回查列表 `data_status=1`，ESB 联动照常触发）。
 - **`detail1`（决议明细，至少 1 条）**：
   | 字段 | 必填 | 说明 |
   |---|---|---|
@@ -110,26 +295,26 @@ weaver-work-cli --json meeting run meeting.eb.meeting.create.prepare --input-jso
 - **会议侧**：`is_decision=2`（决议提交完成）+ `decision_Id=<决议概述 id>` + `mt_status=8`（结束）。**产生决议后会议即视为结束**，这是服务端口径（服务端源码 `decisionStatus==2` 时 `isover=true`）。
 - **任务侧**：`mainTable` = 一条任务（含 `decision_title` / `executors` / `decision_status` / `mt_id` / `relate_decision`）；`detail1` = 各执行人的 `finish_status`（0未完成/1已完成/2已延期）+ `finish_date`。
 
-### 返回结构（解析前必读，2026-09-21 真机实测）
+### 返回结构（解析前必读，实测）
 
 `decision.list` / `decisionTask.list` / `decision.detail` 中，**人员、关联、状态类字段返回的是「对象数组」而不是字符串**：
 
 ```json
-"executors":       [{ "name": "崔智友", "id": "1305319807700025376" }]
-"rummager":        [{ "name": "裴永俊", "id": "1305319812204708008" }]
-"mt_id":           [{ "name": "你好中国", "id": "1316455906280819022" }]
-"relate_decision": [{ "name": "会议决议概述表-…", "id": "1316456666740138910" }]
+"executors":       [{ "name": "王五", "id": "1300000000000000001" }]
+"rummager":        [{ "name": "赵六", "id": "1300000000000000002" }]
+"mt_id":           [{ "name": "示例会议", "id": "1300000000000000003" }]
+"relate_decision": [{ "name": "会议决议概述表-…", "id": "1300000000000000004" }]
 "decision_status": [{ "name": "未完成", "id": "0" }]
 ```
 
 ⇒ 取 id 读 `[0].id`、取显示名读 `[0].name`；**不要**把整个数组直接当字符串拼进回复（会显示成 `System.Object[]`）。
 `detail1[]` 里 **`executor` 是对象数组**，而 **`finish_status` 是字符串**（形如 `"未完成"` / `"已完成"`），`finish_date` / `id` 也是字符串。
-⚠️ **`decisionTask.list` 的 `detail1` 并非每行都返回**（真机实测：同一批任务里只有部分行带 `detail1`）—— 需要逐个执行人的完成状态时，不要假设每条都有 `detail1`；主表 `decision_status` 与 `detail1[].finish_status` 是两套状态（**主表归检查人维护，CLI 只更新 `detail1`**）。
+⚠️ **`decisionTask.list` 的 `detail1` 并非每行都返回**（实测：同一批任务里只有部分行带 `detail1`）—— 需要逐个执行人的完成状态时，不要假设每条都有 `detail1`；主表 `decision_status` 与 `detail1[].finish_status` 是两套状态（**主表归检查人维护，CLI 只更新 `detail1`**）。
 
-**筛选参数（已真机验证生效）**：
+**筛选参数（已实测验证生效）**：
 - `decision.list` / `decisionTask.list`：`mt_id` = **会议 id**（不是决议 id、不是任务 id）。用无关会议 id 查询返回 0 条、用真实会议 id 返回正确条数 ⇒ 参数确实生效。
 - `decisionTask.list` 另支持 `relate_decision`（决议概述 id）、`executors`（员工 id）、`decision_status`。
-- 实测样例：「你好中国」（`mt_id=1316455906280819022`）→ 决议 1 条 + 决议任务 2 条（「解决方案」「研究方案」，执行人崔智友、检查人裴永俊）；**证明 ESB 联动确实按决议明细生成了任务**。
+- 实测样例：「示例会议」（`mt_id=1300000000000000003`）→ 决议 1 条 + 决议任务 2 条（「解决方案」「研究方案」，执行人王五、检查人赵六）；**证明 ESB 联动确实按决议明细生成了任务**。
 
 ### 必须遵守的行为
 
@@ -140,12 +325,12 @@ weaver-work-cli --json meeting run meeting.eb.meeting.create.prepare --input-jso
 5. **部分失败必须如实转达**：
    - 决议已建但**写回会议失败** → 抛 `partial`，消息含 `decision_Id` —— **不要重复创建决议**，可稍后用 `meeting.eb.meeting.markDecided` 补标记（正文里说明了这点）。
    - 决议可能已写入但**没返回 `dataIds`** → 抛 `partial`，提示先用 `decision.list(mt_id)` 回查，**同样不要重复创建**。
-6. **任务与进度的读法（真机实测口径）**：
+6. **任务与进度的读法（实测口径）**：
    - **一条决议明细 = 一个任务**；明细里写多个执行人 ⇒ 该任务**多人共同跟进**（实测：1 明细 + 2 执行人 → 只生成 1 个任务）。
-   - ⚠️ **2026-10-08 复测出现「1 明细 + 1 执行人 → 生成 2 条任务」**：任务条数由**用户配置的 ESB 联动**决定，
+   - ⚠️ **复测出现「1 明细 + 1 执行人 → 生成 2 条任务」**：任务条数由**用户配置的 ESB 联动**决定，
      可能随模板/配置变化，**不要用「明细条数 = 任务数」推算**，一律以 `decisionTask.list` 的实际返回为准。
    - **更新**用 `meeting.eb.decisionTask.update`：按 `executor` 写 `detail1`（`finish_status` 未完成/已完成/已延期 + `finish_date` **带秒**）。
-   - ⚠️ **`markDecided` 的必填组合（2026-10-08 实测）**：`is_decision=2`（决议提交完成）时**必须同时传 `decision_Id` 与 `mt_status`**，
+   - ⚠️ **`markDecided` 的必填组合**：`is_decision=2`（决议提交完成）时**必须同时传 `decision_Id` 与 `mt_status`**，
      否则 `prepare` 能通过、`apply` 被服务端拒绝：原文 `DataError:存为未填写的必填字段: decision_Id,mt_status ,请确认`。
      正确样例：`{"id":"<会议id>","decision_Id":"<决议概述id>","is_decision":"2","mt_status":"8"}`（回读会议：`mt_status=结束`）。
      **`finish_date` 是服务端必填**；把任务改回「未完成」时传一个**空格**即可显式清空。
@@ -161,6 +346,226 @@ weaver-work-cli --json meeting run meeting.eb.meeting.create.prepare --input-jso
    - 查询：`meeting.eb.decisionTask.list`（按 `mt_id` 查某会议全部任务 / 按 `executors` 传员工 id 查某人的任务 / 分页 `pageNo`+`pageSize`）。
 7. **`executors` / `rummager` / `user_id` 一律传 HRM 员工 id**（不是 E10 userId）—— 传错不报错但会静默失效。
 
+### 任务推送到群聊（`meeting.decision.notifyGroup`）
+
+决议任务生成后，群里不会自动收到通知 —— 需要显式推送。这个操作把「会议 → 群 → 任务清单」串起来：
+
+```powershell
+# ① 先预览（默认行为，不会发出任何消息）
+weaver-work-cli --json meeting run meeting.decision.notifyGroup --input-json '{"mt_id":"<会议id>"}'
+
+# ② 确认内容无误后再真发
+weaver-work-cli --json meeting run meeting.decision.notifyGroup --input-json '{"mt_id":"<会议id>","confirm":true}'
+```
+
+**⛔ 必须两步走**：群消息对外可见、超时后撤不回，所以**不带 `confirm:true` 只返回预览**
+（`preview:true, sent:false`，正文放在 `text` 里）。把预览给用户看、确认后再发第二次。
+
+推送内容（实测样例，7 条任务 601 字）：
+
+```
+【会议任务通知】AAAAAA
+
+会议时间：2026-10-30 11:00 ~ 2026-10-30 13:30
+任务进度：共 7 项，已完成 0，待办 7
+
+各位，本次会议已明确以下任务，请按计划推进并在群内反馈进度：
+
+1. 测试
+   负责人：李四
+   计划：2026-10-27 09:00 ~ 2026-11-06 18:00
+...
+（本消息由会议助手自动推送）
+```
+
+口径要点：
+
+- **没有决议任务就不推送**：`decisionTask.list` 为 0 时直接返回 `sent:false` 并提示先
+  `decision.publish`（实测验证：会议 `<会议id>` 无任务，带 `confirm:true` 也不发）。
+  `pipeline` 里同样有门禁：建完任务先等它落地，**服务端仍是 0 条就跳过推送**（群里收到「共 0 项」比不发更糟）。
+- **默认只推未完成**（`onlyPending` 默认 true）：会议攒到后期时，天天把已完成项再刷一遍很烦；传 false 才列全部（已完成的会标「状态：已完成」）。
+- 未完成按计划开始时间正序；超过 `maxTasks`（默认 20）截断并写明「另有 N 项未列出」。
+- 执行人缺失写「未指派」，**不猜人**；任务全完成时给「本次会议的任务已全部完成，无需跟进」而不是空列表。
+- 群 id 默认取会议 `imchat_groupid`，也可显式传 `groupId`；会议没有群直接报 `group_missing`。
+- 发送复用 `im.msg.send.group` 的 prepare/apply，**实测 335 ms**（7 项 / 601 字）；发完可 `im.msg.sync.group` 回读核对。
+
+⚠️ 想「@到人」得走 `im.ding.send`（`toUids`），但**执行人存的是 HRM 员工 id，未必等于 IM uid**
+（本环境邮箱账号恰好相同，是特例）—— 需要先确认口径，别直接拿 HRM id 当 IM uid 用。
+
+> 想一条命令从群聊跑到「任务已发到群里」，用 `meeting.pipeline.run`（`level=notify` + `confirm:true`）。
+> 它会先提取分工、建决议任务、等任务落地（ESB 有 3~6 秒延迟）再推群，避免群里列的还是上一批任务。
+
+### @ 到执行人（默认开，实测 + 客户端双重确认）
+
+推送时默认把**任务执行人 @ 到**（`mention:false` 可关）。
+
+**关键结论：真 @ 靠请求体的 `atUsers`，不是靠文本，也不是靠自己拼 `aus`。**
+
+```json
+POST /api/em/msg/executeIm/send/sendGroupMsg
+{
+  "groupId": "...",
+  "txt": "@:<员工id>;  …",        // 占位符，服务端据此回填姓名
+  "atUsers": [{ "cid": "...", "uid": "..." }]  // ⭐ 决定"是不是真 @"的字段
+}
+```
+
+服务端收到 `atUsers` 后会自己生成落库的 `dt[0].txt.aus`（带 `cid/id/nm/ob/t`）。
+
+逐项实测（同一段文本，只改请求字段）：
+
+| 请求里的写法 | 客户端表现 |
+| --- | --- |
+| 文本里直接写 `@姓名` | **纯文本，不变蓝**，点不了 ❌ |
+| `txt` + 自己拼的 `aus` + `dt` | `aus` 被服务端丢掉，不变蓝 ❌ |
+| `txt` + **`atUsers`** | `aus` 落库，**蓝色可点** ✅（单人 1 条、双人 2 条、3 人 3 条都验过） |
+
+**判据**：回读消息看 `dt[0].txt.aus` 的条数 —— 有 N 条才是 N 个真 @；只有 `v` 里的 `:@uid;`
+占位符而没有 `aus`，客户端只会显示成普通文字（在客户端确认过这一点）。
+
+**@ 出现在两个位置**（都是占位符，都能点）：
+
+```
+@李四 @user2@example.com @user3@example.com 请关注以下任务      ← 开头汇总行
+
+1. 测试
+   负责人：@李四                                        ← 每条任务的负责人
+   计划：2026-10-27 09:00 ~ 2026-11-06 18:00
+```
+
+发送时同一句里会有 2×N 个占位符（N 个在汇总行、N 个在各自负责人行），
+`atUsers` 只需 N 条（人重复不重复不影响）。匹配不到的人仍写纯姓名、不 @。
+
+执行人必须是**群成员**：先用 `im.group.users` 拿 `{uid, cid, name}`，按姓名匹配任务 `executors`。
+匹配不到的会 warning 列出，只在正文里写名字、@ 不上，**不硬凑**。
+
+#### "到底有没有收到提醒"——能证明到哪一步
+
+| 层面 | 证据 | 结论 |
+| --- | --- | --- |
+| 服务端是否记住"@ 了谁" | 回读消息 `dt[0].txt.aus` = `[{cid,id:"<员工id>",nm:"李四",t:"1"}, {…yanfa3…}, {…yanfa2…}]` | ✅ 3 个 uid 精确落库，不是文本假 @ |
+| 消息是否投递到对方会话 | `im.msg.read.group.detail` 查同一条 msgid：`unreadCount=9、readCount=0`，items 里 9 个群成员逐个列出 | ✅ 9 人的会话里都有这条未读消息 |
+| 客户端是否显示成蓝色可点 | 实测确认（见上表） | ✅ 已验证 |
+| **是否弹通知 / 响铃** | 服务端没有"提醒记录"这类可查接口；`unreadCount` 只说明"进了收件箱" | ⚠️ **无法从单账号证明**，取决于收件人客户端（免打扰、是否在线、App 通知权限） |
+
+⇒ 我们能保证的是"**@ 名单正确落库 + 消息已投递 + 蓝色可点**"；
+"有没有弹提醒"只能由被 @ 的真人确认，**不要向用户承诺"对方一定收到提醒"**。
+
+```powershell
+# 预览：会告诉你将 @ 哪些人
+weaver-work-cli --json meeting run meeting.decision.notifyGroup --input-json '{"mt_id":"<会议id>"}'
+```
+
+## 会议议题（`uf_mt_topic`，2026-10-27 17:52 按文档 `RestfulDocumentation (14)` 切换到 `*_new`）
+
+| 能力 | operation | 接口标识 |
+| --- | --- | --- |
+| 列表（可按 `mt_id` 过滤） | `meeting.eb.topic.list` | `query_mt_topic_list` + **`query_mt_topic_count_new`** |
+| 详情 | `meeting.eb.topic.detail` | **`query_mt_topic_info_new`** |
+| **创建** | `meeting.eb.topic.create.prepare` → `apply` | `create_mt_topic` |
+| 更新 | `meeting.eb.topic.update.prepare` → `apply` | **`update_mt_topic_info_new`** |
+| 删除 | `meeting.eb.topic.delete.prepare` → `apply` | **`delete_mt_topic_info_new`** |
+
+> ⛔ **旧的 `query_mt_topic_info` / `update_mt_topic_info` / `delete_mt_topic_info` / `query_mt_topic_count`
+> 已被官方废弃**（确认）。它们的症状很好认：
+> 详情按 id 恒返回 `datas: []`、更新报「没有满足更新条件的数据」、还只认老表单字段
+> （`relate_topic` / `topic_status`），传 `topic_title` 报「该字段不存在」。
+> 这不是权限问题，也不是 id 传错 —— 是接口绑的表单跟 list 不是同一张，**换 `*_new` 即可**。
+
+### 字段：只认新版表单
+
+`topic_title`、`topic_presenter`、`allow_repeat`、`urgency`、`topic_type`、`topic_num`、
+`proposal_person`、`proposal_dept`、`proposal_date`、`related_materials`、`topic_status`、
+`tel`、`remark`、`topic_content`、`topic_text`、`request_id`、`mt_id`、`attend_num`
+
+- `proposal_date` 只接受日期（`2026-10-27`），不带时间；
+- `urgency`：0正常 / 1重要 / 2紧急；`topic_status`：1呈批中 / 2待上会 / 3已上会；
+- 老版字段（`relate_topic` / `topic_no` / `start_time` / `end_time` / `data_status` / `name` …）
+  已从 CLI 白名单移除 —— 传了会被**过滤掉**（不会报错，但也不会生效），别再用。
+
+### 接口可用性（实测）
+
+| 接口 | 结果 |
+| --- | --- |
+| `query_mt_topic_info_new` 按 id | ✅ 返回完整字段（`topic_title` / `remark` / `topic_num` / `proposal_date` …） |
+| `update_mt_topic_info_new` 改标题+备注 | ✅ 成功，回读 `update_time` 已变 |
+| `delete_mt_topic_info_new` 删自建议题 | ✅ 成功，删后详情返回 `datas: []`（CLI 报 `not_found`） |
+| `query_mt_topic_count_new` | ✅ 不带条件 = 全库条数；带 `?mt_id=` = 该会议条数（3 → 1，与 list 一致） |
+| `query_mt_topic_list` | ✅ 正常，可按 `mt_id` 过滤 |
+| `create_mt_topic` | ✅ 正常（`topic_title` + `mt_id` + `proposal_date`；`name` 服务端自动生成） |
+
+```powershell
+# 详情
+weaver-work-cli --json meeting run meeting.eb.topic.detail --input-json '{"id":"<议题id>"}'
+# 更新（改标题 + 备注）
+weaver-work-cli --json meeting run meeting.eb.topic.update.prepare --input-json '{"id":"<议题id>","topic_title":"<新标题>","remark":"<备注>"}'
+weaver-work-cli --json meeting run meeting.eb.topic.update.apply --input-json '{"confirm":true,"continuation":"<上一步>"}'
+# 创建 / 删除
+weaver-work-cli --json meeting run meeting.eb.topic.create.prepare --input-json '{"topic_title":"<标题>","mt_id":"<会议id>","proposal_date":"2026-10-27"}'
+weaver-work-cli --json meeting run meeting.eb.topic.delete.prepare --input-json '{"id":"<议题id>"}'
+```
+
+## 把议题挂到「会议议题明细」（change_meeting 的 detail1）
+
+`topic.create` 只是建了**议题库**里的一条记录（带 `mt_id` 表示归属哪场会议）；
+会议详情页那个「会议议题」列表是**另一个东西** —— 会议表单的 **detail1 子表**，要单独写。
+
+### 两个「议题」不是一张表
+
+| | 议题库 `uf_mt_topic` | 会议表单 detail1（会议议题） |
+| --- | --- | --- |
+| 接口 | `meeting.eb.topic.*` | `meeting.eb.meeting.change` 的 `detail1` |
+| 主键 | `id`（议题 id） | 明细行 id（服务端生成） |
+| 状态 | `topic_status`：1呈批中 / 2待上会 / **3已上会** | `topic_status`：0待开始 / 1进行中 / 2已结束（**会上进度**，不是上会与否） |
+| 时长 | ❌ 没有时长字段（只能写 `remark`） | ✅ `duration`（Number，**分钟**）+ `start_time` / `end_time` |
+
+### 落一条明细的字段口径
+
+| 字段 | 口径 |
+| --- | --- |
+| `relate_topic` | ⚠️ **必须是议题库 id**（跨表单关联键，`componentKey=Ebuilder` → `议题库信息表`）。传标题文本接口不报错，但页面上关联不出来 |
+| `topic_subject` / `topic_no` | 纯文本：议题标题 / 议题编号（`topic_num`） |
+| `topic_presenter` | 汇报人 **员工 id** |
+| `duration` | 分钟数，Number（`15` / `30` / `60`） |
+| `start_time` / `end_time` | `yyyy-MM-dd HH:mm`。**「时长」要落到这两个字段上**，由会议 `begin_datetime` 按各议题顺序累加推算 |
+
+### 顺序（不可颠倒）
+
+1. `meeting.eb.topic.create` × N（`mt_id` 指向会议、`topic_title`、`proposal_date`）；
+2. 按会议开始时间 + 各议题时长**顺次推算** `start_time` / `end_time`；
+3. `meeting.eb.meeting.change.prepare` → `apply`，带 `detail1`（`detail1Mode:"cover"` 整组替换 / 不传为追加）；
+4. ⛔ 写 detail1 会**重置议题的 `mt_id`**（ESB 联动副作用）→ 必须再用 `meeting.eb.topic.update` 把 `mt_id` 补回去；
+5. 需要「已上会」时，用 `meeting.eb.topic.update` 把议题 `topic_status` 置 **3**（不是 2；2 = 待上会）。
+
+```powershell
+# 3) 挂明细（时长 → start/end 顺次推算）
+weaver-work-cli --json meeting run meeting.eb.meeting.change.prepare --input-json '{"id":"<会议id>","operate_type":"CHANGE","detail1Mode":"cover","detail1":[{"relate_topic":"<议题id>","topic_no":"<编号>","topic_subject":"<标题>","topic_presenter":"<员工id>","duration":15,"start_time":"2026-10-28 09:00","end_time":"2026-10-28 09:15","topic_status":"0"}]}'
+# 4) 补回 mt_id
+weaver-work-cli --json meeting run meeting.eb.topic.update.prepare --input-json '{"id":"<议题id>","mt_id":"<会议id>","topic_status":"3"}'
+```
+
+### 明细回读
+
+- ✅ **`query_mtDetail_info`（`meeting.eb.meeting.detail`）能回读议题明细**：返回体 `data.details.detail1`
+  就是会议议题明细行（`topic_no` / `topic_subject` / `topic_presenter` / `duration` /
+  `start_time` / `end_time` / `topic_status` 等）。2026-10-28 之前 CLI 误把行内 mainTable 以外的
+  节点丢弃，造成"接口读不到明细"的误判，已修复并实测验证（写入的 4 行明细全部可回读）。
+- ✅ **`query_mtDetail_list`（`meeting.eb.meeting.list`）的行内同样带 `detail1`**（实测确认）：
+  list 处理器原样返回 `rows`（每行 = `mainTable` + 明细节点），没有丢数据；
+  但**只读 `row.mainTable` 的消费方会漏掉明细**——需要议题明细时优先用 `meeting.detail` 的
+  `data.details.detail1`，或自行取 `rows[].detail1`。
+- ✅ **该修复覆盖全部 9 个 `*.detail` 接口**（meeting/room/roomUsage/sign/receipt/minute/topicType/topic/decision
+  共用同一处理器）：接口配置了返回明细的（如决议详情的决议明细），明细都会透出到 `data.details`。
+- 明细行 `relate_topic` **回显为标题文本**（eBuilder 关联字段行为）；写的时候传议题库 id。
+- 明细行 `topic_status` 是**会中进度**：0 待开始 / 1 进行中 / 2 已结束——与议题库的
+  1 呈批中 / 2 待上会 / 3 已上会是两套取值，别混。
+- `change_meeting` 只回 `dataIds` + `status:true`，且服务端**对明细字段不做校验** ——
+  传一个根本不存在的字段也返回成功。**所以「返回 true」仍不能当作「明细已落库」的证据**；
+  落库与否一律用 `meeting.detail` 的 `details.detail1` 回读核对。
+- 主表 `topic_presenter` / `attend_user` / `reporting_user` 这些「汇总明细」字段是**页面保存**时回写的，
+  走接口写 detail1 **不会**刷新它们 → **它们为空不能反证明细没写进去**。
+- 交叉验证：`topic.list?mt_id=` 看「议题库 → 会议」反向关联（这一步也可回读）。
+
 ## 冲突检测（EB 版，强制）
 
 > 2026-09-20 补齐：此前 EB 版建会**没有任何冲突校验** —— 重复占用同一间会议室、参会人在同一时段撞会都不会被拦住。
@@ -175,7 +580,7 @@ weaver-work-cli --json meeting run meeting.eb.meeting.create.prepare --input-jso
   - 会议室：查占用视图 `query_roomusage_list`（**过滤参数 `address` = 会议室 id**；时间重叠：占用开始 < 我的结束 且 占用结束 > 我的开始；占用视图只对有效状态生成，无需再过滤状态）。⚠️ 该接口**返回体的 `address` 字段为空**，会议室要读 **`room_id`** —— 别据此误判成"检测失效"；
   - 参会人：**2 次请求方案（无 N+1）** —— `query_mtDetail_list`（时间范围 + `mt_status=1,2,8,9`）取候选会议 → `query_meeting_receipt_list?mt_id=<多值批量>`（分批 + 分页拉全）→ 本地求交集；**禁止**退回「逐场会议查回执」的旧做法；
   - 参会人以**回执表 `member_id`** 为准（会议表 `hrm_members` 是渲染文本，不可靠），且只统计 `member_type=1`（参会人员）；
-  - ⚠️ **传参口径（2026-09-20 实测）**：`hrm_members` 必须是 **HRM 员工 id**；传 E10 userId **不报错**，但与回执 `member_id` 比对不上 → **静默漏检**（表现为"无冲突"）。人员 → 员工 id 用 `weaver-e10-hrm`；
+  - ⚠️ **传参口径**：`hrm_members` 必须是 **HRM 员工 id**；传 E10 userId **不报错**，但与回执 `member_id` 比对不上 → **静默漏检**（表现为"无冲突"）。人员 → 员工 id 用 `weaver-e10-hrm`；
   - `org_members`（参会部门）CLI **不展开**成员，因此只有 `hrm_members` 参与人员冲突检测 —— 该情况会以 warning 如实说明，需要覆盖部门成员时请先把部门展开为员工 id。
 - **冲突处置的唯一依据就是应用设置**（`room_conflict` / `member_conflict`），CLI 不额外加码、也不引入任何隐藏校验：
   - `1`「禁止提交」→ 怎么都不允许提交，直接拒绝（`conflict_rejected`）；
@@ -199,7 +604,9 @@ weaver-work-cli --json meeting run meeting.eb.meeting.create.prepare --input-jso
    - 结果在 `apply` 返回的 **`data.association`**：`{ status: COMPLETE|PARTIAL, mtId, created: { roomUsage, receipt, sign }, warnings }`。
    - **补建失败不中断建会**（主写入已成功）→ 只进 `association.warnings` 并说明后果；**不要因补建失败而重试建会**（会重复建会）。
    - 未传 `address` → 跳过占用；未传 `hrm_members`（如仅用 `org_members` 指定部门，CLI 不展开部门成员）→ 跳过回执与签到，均在 warnings 中说明。
-   - 需要"取消会议释放占用"时用 `meeting.eb.meeting.delete`（会级联回收 占用/回执/签到）；`delete_roomusage` 在本环境报「主键传入不能为空」，不可用。
+   - 需要"取消会议释放占用"时可用 `meeting.eb.roomUsage.delete`（传 **`mt_id`**），或 `meeting.eb.meeting.delete`（会级联回收 占用/回执/签到）。
+     实测更正：该接口**不是按 id 删**，而是按 `mt_id` **批量删除该会议的全部占用**；
+     传 `id` 会报「批量操作数据条件不能为空」。实测一次删掉 4 条（含历史遗留）。
 
 ## 出席情况汇总（`data.progress`，2026-09-22）
 
@@ -242,15 +649,15 @@ EB 表 tag 映射（`meeting.link` 的 `type` 取值，也可用 `tag` 直接指
 Windows PowerShell：
 
 ```powershell
-weaver-work-cli --json meeting run meeting.link --input-json '{"dataId":"1305624900858404950","type":"meeting","name":"周会"}'
-weaver-work-cli --json meeting run meeting.link --input-json '{"dataIds":["1305624900858404950","1305624900858404951"],"name":"周会"}'
+weaver-work-cli --json meeting run meeting.link --input-json '{"dataId":"<会议id>","type":"meeting","name":"周会"}'
+weaver-work-cli --json meeting run meeting.link --input-json '{"dataIds":["<会议id>","<会议id2>"],"name":"周会"}'
 ```
 
 macOS/Linux（bash/zsh）：
 
 ```bash
-weaver-work-cli --json meeting run meeting.link --input-json '{"dataId":"1305624900858404950","type":"meeting","name":"周会"}'
-weaver-work-cli --json meeting run meeting.link --input-json '{"dataIds":["1305624900858404950","1305624900858404951"],"name":"周会"}'
+weaver-work-cli --json meeting run meeting.link --input-json '{"dataId":"<会议id>","type":"meeting","name":"周会"}'
+weaver-work-cli --json meeting run meeting.link --input-json '{"dataIds":["<会议id>","<会议id2>"],"name":"周会"}'
 ```
 
 **输出与用法**：
@@ -265,6 +672,11 @@ weaver-work-cli --json meeting run meeting.link --input-json '{"dataIds":["13056
 
 ## 注意
 
+- **列表默认只返回第一页**：`meeting.eb.meeting.list` 默认 `pageSize=20`，`data.total` 才是全量条数。
+  要"全部会议"必须显式传大 `pageSize`（EB 服务端**不会**压低它，`pageSize=200` 可一次拿全）或翻页；
+  本页未取全时 `warnings` 会明确写「还有 N 条未取到」。
+  ⚠️ 另外 CLI 的 stdout 预览会把长数组**截到 10 条**（`previewTruncated`），
+  所以"终端里只看到 10 条"不等于"系统里只有 10 条" —— 一律以 `data.total` 为准。
 - **取消会议**用 `meeting.eb.meeting.change.prepare`（`operate_type=CANCEL` 且 `mt_status=4`），没有独立 cancel 接口。
 - `mt_status` 枚举：0草稿/1审批中/2未开始/3退回/4取消/5提前结束/6删除/7锁定/8结束/9进行中/10审批中(变更)/11审批中(取消)。
 - 议题表 `uf_mt_topic` 在部分租户未注册，`meeting.eb.topic.list` 返回空数组属正常。
@@ -281,3 +693,67 @@ weaver-work-cli --json meeting run meeting.link --input-json '{"dataIds":["13056
 - `partial/write_uncertain`：写请求发出后连接中断，**禁止自动重试**，先 list/detail 回查是否已生效。
 - `conflict_rejected`：命中冲突且应用设置为**禁止提交** —— 立即停止，建议用户换时间或换地点；若应用设置为**仅提醒**，则只写入 `warnings`（不抛错），**是否继续由用户决定**（CLI 不主动建议忽略冲突）。
 - `conflict_check_failed`：冲突检测接口调用失败（fail-closed，直接拒绝建会），核对占用/回执接口权限后重试。
+
+## 实测：耗时与已知限制
+
+### 一次完整链路各步实测耗时（服务端往返，不含 CLI 进程启动）
+
+| 步骤 | 耗时 | 说明 |
+|---|---|---|
+| 会议 `create.prepare` | ~1.0 s | 含冲突预检（占用 + 回执两次查询） |
+| 会议 `create.apply` | ~1.4 s | |
+| 纪要 `create.apply`（纯文本） | ~0.1 s | |
+| 纪要 `create.apply`（带 `doc_file` 附件） | **~3.9 s** | 附件触发服务端处理，慢 ~36 倍，属正常，别当失败重试 |
+| 纪要 `create.apply`（带 `video_file`，文件已存在） | ~0.1 s | 附件秒传时不慢 |
+| 纪要 `delete.apply` | ~0.9 s | |
+| 决议 `publish.apply` | **~4.0 s** | 内部两步串行（写决议 → 回写会议），非卡死 |
+| 决议任务 `list` | 冷 ~0.47 s / 热 ~0.06 s | |
+| 邀请函 `invitation.render` | ~0.24 s | 纯读 + 本地写文件 |
+| 文件上传 `preUploadCheck` | 热 ~1.1 s；**首次可能 >15 s** | 见下方「上传超时」 |
+
+> ⚠️ **给 Agent 的预期管理**：带附件的纪要、决议发布都要 4 秒左右，**不要因为"没立刻返回"就重复提交**（会产生重复数据）。
+
+### ⛔ 纪要解析（ASR / 文档文字提取）**不能由接口触发**
+
+实测结论（创建后连续观察 81 秒 + 多次改 `minutes_status`）：
+
+- `create_mt_minute` / `update_mt_minute` **只写字段，不触发解析流水线**：`video_taskId` 始终为空、`parse_content` 始终为空、`minutes_status` 停在你写进去的值。
+- 解析必须由**会议详情页**（或平台侧服务）触发。
+- 所以：通过 CLI 建的音频/文档纪要，**不要对用户说"已开始解析/稍后就有纪要"** ——
+  应明确告知"文件已挂到纪要上，需在会议详情页点解析/生成"。
+
+### ⛔ `minutes_status` 不能当"解析完成"的判据
+
+全库 33 条纪要中，**28 条**音频纪要 `minutes_status=1（生成中）`，但 `video_taskResult=1（生成成功）`
+且 `parse_content` 已有 1000+ 字内容 —— 状态字段**从不推进到 2（已完成）**。
+
+判断解析是否完成，按这个顺序看：
+
+```
+video_taskResult == '1'（生成成功）  且  parse_content 长度 > 0    → 已完成
+video_taskResult == '2'                                        → 生成失败
+video_taskResult 为空 且 parse_content 为空                     → 未触发解析
+```
+
+另有 2 条 `minutes_status=4（文字提取完成）` 但 `parse_content` 为空 —— 同样不可信。
+
+### 决议明细 `detail1` 的位置
+
+- **`decision.list` 与 `decisionTask.list` 的 `detail1` 在「行顶层」**（`rows[].detail1`），
+  **不在 `rows[].mainTable` 里** —— 取不到时先怀疑取错层级，不要断言"接口没返回"。
+- **`decision.detail`（单条）不返回 `detail1`**（只有 creator/create_time/mt_id/name/id/data_status/updater/mt_content 9 个字段）。
+  要明细请用 `decision.list` 按 `mt_id` 查。
+- 任务进度用 `data.progress.summary`（`total/done/overdue/pending`）与 `progress.items[].members[]`，
+  这是 CLI 按 `executors` × `detail1` 算好的，**不要自己拿 `decision_status` 判断**（该字段恒为「未完成」）。
+
+### 决议任务更新的两个坑
+
+- **服务端不校验 `executor` 是否属于该任务**：给「整理纪要模板（执行人=张三）」写一条
+  `executor=李四` 的跟进记录，接口照收，且**会计入该任务的 detail1** —— 但进度汇总按 `executors` 统计，于是这条记录
+  变成"看不见的孤儿数据"。**写之前必须先 `decisionTask.list` 核对 `executors` 里确实有这个人。**
+- `executor` 必须是**该任务 `executors[]` 里的员工 id**；传错人不会报错，只会静默多一条无效记录。
+
+### 写接口偶发 `java.lang.reflect.InvocationTargetException`
+
+实测遇到两次（`update_mt_decision_task` 首次调用、EB 列表接口），**重试即成功**，且数据未被写坏。
+判定方法：报这个错时先 `list` 回查；没写进去再重试一次，**不要连试三次以上**。