feat: 新增企业微信助手 Agent，并修正 wecom-cli 条目 ref 漂移 (#112)

## 概述 / Overview

两件事：新增「企业微信助手」Agent（自带 15 个技能），并修正 `wecom-cli` 条目钉在 6 月快照的 ref 漂移。

Two changes: adds the **WeCom Assistant** agent (bundling 15 skills),
and fixes the `wecom-cli` entry whose pinned ref was stuck on a June
snapshot.

## 1. 新增企业微信助手 Agent

覆盖企业微信 **14 类服务、95
个方法**：消息、群聊历史、通讯录、日程、会议、待办、邮件、在线文档、在线表格、智能表格、智能文档、文档管理、微盘、媒体文件。

**采用内联形态 + 自带私有技能**：Agent 安装对 `agents/<id>/` 整目录递归复制且 `skills/`
不在排除集合里，因此装 Agent 即带全部技能，用户无需再单独获取技能合集。

### 技能集（15 个，约 5000 行）

- 基于上游 [wecom-cli](https://github.com/WecomTeam/wecom-cli) 官方
Skill（MIT，© WecomTeam）改写，每个技能末尾保留归属声明
- **新增 `wecom-chat`**：补齐上游零覆盖的群聊历史读取
- 补齐上游未覆盖的 `message.send`、`doc.create`，方法覆盖达 **95/95**
- 修正上游三处文档漂移：邮件能力描述与实际相反、会议室参数名已过时、`title_highlight` 字段不存在

### 相对上游的核心增量：风险治理

- 26 个对外可见或不可逆的方法逐个写明**执行前确认要求**
- 4 个条件升级方法给出**参数级判据**，而非按方法名一刀切
- 文档权限扩散两项加重处理，涉及**企业外可见**时单独再确认一次
- 内部标识禁止外露，不因用户索要而放宽
- 拒绝导出可识别到具体自然人的隐私字段

### 三条真机实测得出、上游未覆盖的硬约束

1. 机器人**只能写入/修改自己创建的数据**，真人创建的只能读
2. 每次响应携带的 `extra_identity_context` **禁止透露给用户**
3. 权限错误（`850002`/`851008`/`853006`）**不得重试**，须将 `help_message`
**逐字原样**转给用户

## 2. 修正 wecom-cli 条目 ref 漂移

`source.ref` 原钉在 2026-06-28 的 `72e14f7`，该快照只有 7
个子技能且用已废弃的旧命名（`msg`/`schedule`）。上游 v1.2.0 已扩展到 **14 个**技能。按旧 ref
安装的用户拿到的是三个月前的快照。

- `source.ref` → `78c514b2afee7c0d3d7be715628478421f37ee63`
- `children` 由 `scripts/gen-collection-children.py` 重新生成，**7 → 14**
- sidecar 同步 `provenance.content.ref`、`childCount` 与 `children`

## 验证 / Verification

**静态**
- 215 条示例命令追加 `--dry-run` 实跑，**215/215 退出码 0**
- 未知方法 0、未知参数 0、`--json` 未知字段 0、枚举违规 0
- 15 个 `SKILL.md` 的 frontmatter 经客户端 `skillFrontmatterSchema` 校验全部通过
- `validate_catalog_metadata.py --require-complete` 与
`gen-collection-children.py`：**0 error**

**真机（在真实企业微信账号上端到端）**
- **待办域 6/6 方法全通**（含 2 个 write-high），`items` 必填的隐蔽坑实测证实
- **日程域 5 个方法全通**（含 3 个 write-high）
- 消息发送、通讯录解析、微盘列表、邮件搜索、文档搜索、会议列表、智能表格创建均已实测通过
- 测试数据已全部清理，未污染真实账号

**尚未实测**：群聊历史（机器人未开通该品类）。相关文档已明确标注验证状态，未实测的能力不写「实际效果」段落。

agents/wecom-assistant/docs/07-待办.md

@@ -0,0 +1,134 @@
+# 待办
+
+把「这件事要做」记进企业微信待办：记一条、查一批、改内容、标完成、删掉或退出。
+可以只给自己记，也可以分派给同事并设截止时间与提醒。
+**这是整套能力里实测覆盖最完整的一域**——6 个方法全部在真实账号上跑通了。
+
+## 你可以怎么说
+
+> 「帮我记个待办：明天下午三点前把周报发出去」
+> 「我有哪些待办？」
+> 「已完成的待办给我看看」
+> 「把『准备周会材料』这条改一下截止时间，改到周五」
+> 「这条待办完成了」
+> 「把张三也加进这条待办」
+
+## 📋 验证状态
+
+| 项 | 状态 |
+|---|---|
+| 创建待办 | ✅ **已实测** |
+| 查待办列表 | ✅ **已实测** |
+| 查待办详情 | ✅ **已实测** |
+| 更新待办（改标题） | ✅ **已实测** |
+| 标记完成 | ✅ **已实测**（高风险写入） |
+| 删除待办 | ✅ **已实测**（高风险写入） |
+| 分派给他人（多人参与） | ⚠️ 未实测（实测账号只有一个人） |
+| 完整链路（你说一句话 → 助手自动记完） | ⚠️ 未实测 |
+
+**实测记录**（命令层，人工在真实账号上执行，6/6 全通）：
+
+| 动作 | 结果 |
+|---|---|
+| 创建 | ✅ 成功。**创建人显示的是机器人身份，不是你本人**——这一点直接决定了后面能改什么 |
+| 列表 / 详情 / 更新 | ✅ 全通，标题改名成功 |
+| 标记完成 | ✅ 企业微信反问了一句「是否标记为已全部完成」，这个选择被原样交回 |
+| 删除 | ✅ 删除后复核，待办数量归 0 |
+
+还实测证实了一个隐蔽的坑：**不传待办条目会直接失败**，返回「`items` 不合法，要求为 必填」。
+而工具的帮助文本**没有把它标成必填**——助手知道这一点，不会拿空请求去试。
+
+测试数据已全部删除，企业微信侧复核数量为 0。
+
+## 能力清单
+
+| 能做什么 | 命令 | 风险 |
+|---|---|---|
+| 查待办列表（按时间 / 状态 / 关键词筛） | `wecom-cli todo list` | 读取 |
+| 批量查待办详情 | `wecom-cli todo get` | 读取 |
+| 创建待办 | `wecom-cli todo create` | 低风险写入（**分派给他人时升为高风险**） |
+| 更新待办 | `wecom-cli todo update` | 低风险写入（**改参与人时升为高风险**） |
+| 标记完成 | `wecom-cli todo finish` | **高风险写入** |
+| 删除 / 退出待办 | `wecom-cli todo delete` | **高风险写入** |
+
+**只给自己记一条，助手直接执行，不问你。** 过度确认会让助手变得难用。
+只有下面这些情况才会先问一句：
+
+| 情况 | 为什么要问 |
+|---|---|
+| 分派给他人 | 对方待办列表里立刻出现这条，还会收到提醒 |
+| 改参与人名单 | **是「整体替换」不是「追加」**，漏掉谁就等于把谁踢出这条待办 |
+| 标记完成 | **没有「取消完成」这个操作**，标完就只能去客户端处理 |
+| 删除 | 没有恢复接口 |
+
+## 注意事项
+
+**「完成」是单向的。** 接口层根本没有「取消完成」这个方法。所以标完成前助手会先确认，
+而且会**先检查一遍这条是不是已经完成了**——已完成就直接告诉你「这条已完成」，不再重复操作。
+
+**完成范围可能有两档。** 一条待办有多个参与人、而你既是创建人又是参与人时，
+标完成会先只标你自己那份，然后企业微信会反问一句是否连别人的份一起标。
+助手会把这个选择带着待办标题和参与人姓名交回给你，让你选「仅我完成」还是「已完全完成」——
+**不会替你决定**（实测中确实触发了这个反问）。
+
+**「删除」对不同的人是两件事。**
+
+| 你的身份 | 「删除」的实际含义 |
+|---|---|
+| 你是这条待办的创建人 | **删掉整条**，其他参与人也不再看到 |
+| 你不是创建人 | **你退出这条待办**，不影响其他人 |
+
+助手会先弄清是哪一种，再用对应的话跟你确认。它**不会**用「创建人之外无权删除」这种话搪塞你——
+非创建人本来就可以退出。
+
+**改参与人是「整体替换」，这是本域最危险的一个动作。**
+说「把张三也加进去」时，助手会先把现有名单读出来，本地合并成完整名单，再整份传回去。
+它不会只传张三一个人——那样会把原来的人全部踢出去。这也是为什么改参与人要先确认。
+
+顺带一提：说「分派给我和张三」时，**你自己也要在名单里**——企业微信不会自动把创建人算成参与人。
+助手知道这一点。
+
+**查询默认只给「进行中」。** 问「我有哪些待办」返回的是进行中的；
+要看已完成的、或者全部，得说清楚（「已完成的待办」「所有待办」）。
+助手在做删除、完成这类操作前定位待办时，会主动把已完成的也查进来，免得「其实有」被误判成「找不到」。
+
+**关键词是字面匹配，不是语义搜索。** 你记的是「把周报发出去」，搜「汇报」是搜不到的。
+搜不到时助手会建议放宽关键词或改按时间范围列，**不会断言「你没有这条待办」**。
+
+**统计类问题它会翻完所有页。** 「我一共有多少条待办」这种问题，单页最多只能拿 20 条，
+只看首页会严重少算——助手会翻到底再报数。
+
+**截止时间和提醒有几条固定规则：**
+
+- 你说了具体时刻（「明天下午三点前」）→ 落成精确到分钟的截止时间。
+- 你只给了日期（「周五之前」）→ 落成日期。
+- 你完全没提时间 → 两个都不设，**它不会追问**。
+- **「不要提醒我」做不到**：接口层没有「关闭提醒」这一档。唯一的办法是把截止时间一起清掉，
+  助手会先跟你确认再动手。
+- **「提前 30 分钟提醒」也设不了**：只能设截止时间，提醒时刻由企业微信按默认规则给。
+  助手会告诉你实际的提醒时刻，并引导你去企业微信待办里手动改。
+- **它不会另建一个定时任务来模拟提醒**——那会造成重复提醒。
+
+**描述不会写成标题的复述。** 只有标题装不下的额外信息（背景、对接人、单号、链接）才会写进描述。
+一条只有标题的待办完全正常。
+
+**「帮我记一下」不一定是待办。** 只有你明确说了「待办」，或者说的是「定时提醒的待办」，
+助手才会建企业微信待办。泛泛的「提醒我一下」它不会擅自往待办里塞——那可能该用日程，
+也可能该用别的方式。
+
+### 三条通用边界在本域怎么体现
+
+1. **只能改它自己建的东西**——**实测确认：助手创建的待办，创建人是机器人身份。**
+   这意味着**你自己在企业微信里建的待办，助手改不了、也标不了完成**。
+   碰到这种请求，它会说明边界，并建议由它新建一条，或者你在客户端自己改。
+2. **能力按品类逐项开通**——待办属于基础品类，实测账号一开始就能用。
+   未开通时助手会把官方开通指引原样转给你，然后停下，不重试。
+3. **危险动作先问你**——完成、删除**总是**先问；分派给他人、改参与人名单**按参数升级**为先问；
+   只给自己记一条不问。见 [99 风险与确认](99-风险与确认.md)。
+
+## 相关
+
+- [02 通讯录](02-通讯录.md)——分派给同事前先在这里把人名解析出来
+- [05 日程](05-日程.md)——「占一段时间」而不是「记一件事」时用它
+- [06 会议](06-会议.md)——会议纪要里的行动项可以落成待办
+- [99 风险与确认](99-风险与确认.md)——哪些待办操作会先问你、判定规则是什么