dsh-plugin-t-expert 0.4.38 → 0.4.51

package/CHANGELOG.md

@@ -16,6 +16,349 @@
 > 发布时**不要再跑 `npm version`**（那会把已提交好的版本又升一级，发出去的号与 CHANGELOG、tag 就对不上），
 > 只补一个 annotated tag（`git tag -a`，因为 `git push --follow-tags` 只推带注释的 tag）。
 
+## [0.4.51] — 未发布
+
+**`upload-obs.mjs` 新增 `--delete-orphans`：清理删过专家后留在桶里的孤儿对象。**
+
+### 新增
+
+    node tools/upload-obs.mjs --delete-orphans        # 只列不删
+    node tools/upload-obs.mjs --delete-orphans --yes  # 真删
+
+- 用 ListObjects（自动翻页）扫 `<prefix>/packs/`，与 `roster.json` 引用的 path 集合比对，
+  列出没被引用的对象；**只扫 `packs/` 前缀**，不碰桶里其它东西，免得误删手工放进去的。
+- **默认只列不删**，要 `--yes` 才真删（破坏性操作两道闸）。
+- 实现细节：OBS v2 签名里 `prefix` / `marker` / `max-keys` **不属于**要签的子资源，
+  桶级 LIST 的 CanonicalizedResource 只有 `/<bucket>/` —— 所以直接复用 `authorize({ key: "" })`。
+
+### 实测（这就是加它的原因）
+
+```
+桶里 244 个对象 / 清单引用 181 个 / 孤儿 63 个 / 合计 529.0 MB
+```
+
+其中 `vietnam-finance-tax-expert.tar.gz` 一个就 495.6 MB（占 93.7%），其余 62 个来自更早的几次删除：
+内部依赖专家（`omics-*`、`fundus-disease-analysis`…）与「去分区前缀重名」那批
+（`ui-designer`、`backend-architect`、`frontend-developer`… —— 判重修复之前导入的）。
+
+## [0.4.50] — 未发布
+
+**移除 `finance/vietnam-finance-tax-expert`（495.6 MB）** —— roster 里最大的包，是第二名的 12.5 倍。
+
+### 为什么
+
+它是个「**离线 RAG 型**」专家：自带 723 篇越南财税法规语料，外加
+
+| 文件 | 大小 |
+|---|---|
+| `tfidf_matrix.npz`（预计算检索索引）| **382.9 MB** |
+| `chunks_metadata.json`（分块元数据）| 41.7 MB |
+| 法规原文（PDF/HTML/TXT）| 约 70 MB |
+
+功能上很完整（不联网就能查越南税法，还配了企业所得税／工资／关税／选址四个计算器），
+但**单个专家 495.6 MB 太重**（第二名 `legal/malaysia-hr-admin` 才 39.6 MB），
+按需下载的设计不值得为它付这个代价。
+
+名册 **624 → 623**；roster **182 → 181**；README / npm description / THIRD-PARTY-NOTICES /
+许可说明 / source.json / verify 数字同步校准。
+
+### 遗留
+
+OBS 上的 `packs/finance/vietnam-finance-tax-expert.tar.gz`（495.6 MB）现在是**孤儿对象** ——
+`roster.json` 里没有它，不会有任何客户端去下载，但占着云端空间。清理方式见技能
+`t-expert-roster-sync` 的说明（`tools/upload-obs.mjs` 目前只有上传与校验，没有删除）。
+
+## [0.4.49] — 未发布
+
+**远端清单的两个缺陷：一个是功能性的（495 MB 附件拿不到），一个是我自己设错的上限。**
+
+### 背景
+
+按用户要求实测「召唤专家能否下载附件」：两位专家（`seo-content-team`、`fin-research-expert`）
+都下载成功，sha256 与清单**逐字节一致**，解包后文件齐备。但顺带查出远端清单的两个问题。
+
+### 修复
+
+1. **远端清单改成「并集合并」而非替换**。远端可能比包内**旧**（改了专家但还没重传 roster），
+   直接替换会让包内独有的条目查不到 —— 表现是那位专家被判成「没有云端附件」，附件**永远下载不下来**。
+   实测踩到：`finance/vietnam-finance-tax-expert`（**495.6 MB**）在包内清单里有、远端那份是旧的因而没有，
+   它的 `agents/` 与 `references/` 一直缺失。
+   现在 `mergeRosters(bundled, remote)`：远端同名条目优先（那是新版本），包内独有条目保留（兜底）。
+   **所有返回路径都过合并**（含缓存命中 —— 否则插件升级后、缓存 TTL 内，包内新增条目会因
+   「缓存还新鲜」而丢失）。
+2. **单包体积上限 200 MB → 2 GB**。这是我上一版设错的：roster 里真实存在 495.6 MB 的包，
+   200 MB 上限会把它当异常条目**整条拒掉**，同样导致附件拿不到。
+
+### 自检
+
+新增 5 条断言（并集的覆盖/保留/undefined 回退 + 「495 MB 大包必须放行」），541 → **546**。
+端到端验证：包内 182 条 ∪ 远端 203 条 = **204 条**，那条 495.6 MB 的条目现在查得到。
+
+### 运维提醒
+
+远端 `agetn/roster.json` 目前比包内**旧**（它是删掉那批内部依赖专家之前上传的：多 22 条孤儿条目、
+少 1 条）。并集逻辑已保证不影响使用，要让它干净就重跑一次 `node tools/upload-obs.mjs`。
+
+## [0.4.48] — 未发布
+
+**逐行审查 0.4.47 的远端清单代码，修掉一个会导致「远端故障时频繁打远端」的 bug。**
+
+### 修复
+
+- `refreshRoster` 失败时不更新 `rosterFetchedAt`：首次 `resolveRoster` 失败会标记时间（TTL 内不再试），
+  但后台刷新 `refreshRoster` 失败时直接 return、没标记 —— 于是远端故障期间，每次召唤专家都会
+  重新触发一次 8 秒超时的远端拉取，一路打到远端。现在无论成败都标记。
+- `readCachedRoster` 对齐 `loadRoster`：补上 `packs` 必须是对象的校验（缺 packs 的坏缓存现在返回
+  undefined，而不是一份查不到任何附件的空清单）。
+
+### 自检
+
+- 新增 4 条清单缓存断言（往返一致 / 缺 packs / 坏 JSON / 缺 fetchedAt），537 → 541。
+
+## [0.4.47] — 未发布
+
+**远端清单：只更新专家、不动插件，用户也能拿到新版附件。**
+
+### 背景
+
+之前 `roster.json` 只随插件包发布，于是「改专家 → 必须发版 → 用户必须升级」，否则老用户
+手上的清单停在旧 sha256、判定 READY、永不刷新。现在清单也放云端 —— `upload-obs.mjs` 早就在传
+`agetn/roster.json`，这里补上「运行时优先读远端」这半边。
+
+### 实现
+
+- `lib/fetch-assets.js` 新增 `sanitizeRemoteRoster` / `fetchRemoteRoster` / `readCachedRoster` /
+  `writeCachedRoster`。清单来源三级：**磁盘缓存（TTL 12h）→ 远端 → 包内快照**。
+- `lib/index.js` 的 `rosterOnce` 改成三级回退 + **TTL 过期后台刷新**（不阻塞召唤）：
+  远端拉到新清单就替换，拉不到静默用旧值。
+- **安全校验**（远端清单会指挥客户端下载任意 URL，必须过白名单）：
+  - `baseUrl` 只能等于包内清单的 `baseUrl`（随 npm 签名包走、可信），包内缺失时退回写死常量；
+  - `path` 严格等于 `packs/<分区>/<slug>.tar.gz`（拒 `../`、绝对路径、其它形态）；
+  - `sha256` 必须 64 位十六进制；`bytes` 非负整数且 ≤ 200MB；`dirs` 必须是纯目录名（拒斜杠、`..`）；
+  - 条目数 ≤ 包内 + 200；roster 本体 ≤ 2MB。
+  - 任何一条非法 → 该条跳过 / 整份拒绝 → 回退缓存或包内。
+
+### 效果
+
+| 场景 | 行为 |
+|---|---|
+| 只更新专家（OBS roster 变了） | 用户下次用（TTL 内缓存、之后后台刷新）自动拿到新版，**不用升级插件** |
+| 插件也升级 | 照常 |
+| 离线 / OBS 挂了 | 回退缓存 → 包内，不影响使用 |
+
+### 自检
+
+新增 12 条断言（sanitize 各条白名单 + fetchRemoteRoster 合法/非法/异常路径），525 → 537。
+实测：真实远端 226ms 拉到 203 条、样本 sha256 与包内一致；缓存往返一致；坏缓存/缺字段均返回 undefined。
+
+## [0.4.46] — 未发布
+
+**修掉「把关」完全失效的 bug，并清掉因此回流名册的 24 个内部依赖专家**（648 → 624）。
+
+### 修复
+
+`scan-internal-deps.py` 的布局判断把「是不是分区目录」放在前面，而它的判据是
+`persona.md` —— **那是 T专家导入时生成的，上游 WorkBuddy 包里根本没有**；上游的标志是
+`.codebuddy-plugin/plugin.json`。
+
+后果：扫 WorkBuddy 导出目录时**每一层包都被当成「分区」**，产出的 key 变成 `<slug>/skills`
+这种形式，而编排脚本按 key 的**末段**取专家名 —— 拿到的是 `skills`、`agents`。
+于是 `blocked` 集合里**一个专家都没有，把关形同虚设**。
+
+**实际后果**：0.4.45 那次「完整跑通」的同步，把之前删掉的 24 个内部依赖专家
+**原样导回**了名册（`cpq`、`txzhaopin`、`omics-*`、`mi-zhen-expert`、`migraq`…）。
+
+现在判据补上 `.codebuddy-plugin`：扫 447 个包**命中 24 个**，与人工核对过的清单完全一致。
+
+### 清理
+
+名册 **648 → 624**；`source.json` / README（两处）/ npm description / THIRD-PARTY-NOTICES /
+许可说明同步校准。
+
+### 教训
+
+**「跑通了」不等于「跑对了」。** 0.4.45 那轮六阶段全绿、同源校验通过、名册数字也合理 ——
+但**把关那一环悄无声息地什么都没做**，而且没有任何迹象。
+
+守卫必须能在**失效时自己报警**：这里只要在 `blocked` 为空时打印一句
+「⚠️ 本轮没有拦下任何专家 —— 扫描器可能没生效」，这类问题就不会带着满屏绿灯过关。
+下次改编排脚本时补上。
+
+## [0.4.44] — 未发布
+
+**加一条守卫：打包产物必须与 `roster.json` 同源** —— 在上传之前就拦下，而不是等远端校验。
+
+### 为什么
+
+排查过程中我手动恢复过一次 `roster.json` 备份（来自那次 722 位的同步），而 `dist/assets/`
+是另一轮的产物，**两者对不上**。这个错位一路蒙混到**上传校验阶段**才暴露 —— 那时 tgz
+已经传上去了、清单却是旧的，还得再绕一圈（`brand-guardian` 就是这个状态）。
+
+现在编排脚本在**阶段 4 之后、阶段 5 之前**逐个重算 `dist/assets/**/*.tar.gz` 的 sha256，
+与 `roster.json` 的记录比对，不一致就**直接退出并给出是哪几个**。实测它拦下了
+`marketing/brand-guardian`（`7878732f… ≠ d072a301…`），流程没有继续往下走。
+
+### 教训
+
+**手工修数据要留痕**。我恢复 roster 备份时只想着"把清单救回来"，没意识到它和 `dist/`
+已经不同源 —— 而这类不一致不会自曝，只会在最下游以"校验失败"的形式出现，让人误以为是
+上传工具的问题。守卫的价值就在这里：**把不变式写成代码，别指望人记住。**
+
+## [0.4.43] — 未发布
+
+**修掉三个让「增量同步」实际不可用的 bug** —— 全量真跑时逐个暴露。
+
+### 修复
+
+1. **`import-workbuddy.py` 的 `--only` 会丢弃判重结果**（最严重）：
+   `wanted = [p for p in idx if p in want]` 从**全部候选**重新取，把刚算好的 `dups` 整个覆盖。
+   于是**只有走 `--only` 的路径**（正是编排脚本用的那条）判重形同虚设。实测全量同步因此产生
+   50+ 组 slug 冲突（`ai-engineer` vs `engineering-ai-engineer`、`ui-designer` vs
+   `design-ui-designer`…），两两都变成不可召唤；而不带 `--only` 的干跑却显示「跳过 300 个」——
+   这个差异是排查的关键线索。
+2. **判重规则漏了「去分区前缀」这一整类**：T专家存量里有一批 slug 带分区前缀
+   （`engineering-`、`design-`、`marketing-`…），而 WorkBuddy 收录同一位专家时用的是**不带前缀**
+   的名字。现在把存量 slug 归一化后再比。同时**补上目录形态**（原先只收 `.md` 单文件，
+   目录形态的专家根本不在比对范围里）。
+3. **`upload-obs.mjs` 缺 `--force`**：上传中断过的对象会出现「meta 已写新、内容体还是旧的」，
+   而跳过逻辑只比 meta，会把它误判成"已同步"，永远修不好。加了 `--force` 忽略跳过判断。
+
+### 实测数据（判重修复前后，同一批 447 个候选）
+
+| | 修复前 | 修复后 |
+|---|---|---|
+| 被拦下 | **0** | **404** |
+| 实际导入 | 447 | **27** |
+| 名册 | 621 → 722（50+ 组冲突）| 621 → **648**（无冲突）|
+
+### 编排脚本 `sync-from-workbuddy.mjs`
+
+- **去掉 `--include-dups`**：那会关掉判重。上一步已把「要更新的」旧包删掉，它们不再同名、
+  会正常导入；真正重复的（去前缀后同名 / 同职业名 / 同正文）则被拦下。
+- **`--prune` 移到上传成功之后**（反过来就没东西可传），且它重写 `roster.json`，要先护住再恢复。
+- 「名册里有没有」**收全两种形态**（单文件 + 目录），只收目录会把几百个单文件专家误报成「新增」。
+
+> **本轮未完成**：完整跑完六阶段还差两处 —— ① 上传中断遗留的坏对象（`brand-guardian`，
+> 远端 meta 与内容不一致）；② `dist/assets/` 与 `roster.json` 的**同源性**校验：
+> 排查过程中我手动恢复过一次 roster 备份，造成两者不同源，已回滚。
+> 下一步先加一条「打包产物与清单必须同源」的守卫，再重跑全量。
+
+## [0.4.42] — 未发布
+
+**用真包把六阶段全跑通了一遍，并修掉途中暴露的四处问题。**
+
+### 修复
+
+- **新增 `--only` / `--limit`**（安全试点开关）：打通流程不可能一上来就动 447 个包。
+- **拉取脚本的路径拼错了**：原来用 `join(TOOLS, "..", "..", "..", ".dsh", ...)` 拼出来是
+  `~/web/.dsh/...`（错），改用 `$HOME` 常量，并加了「脚本不存在就明确报错」的检查。
+- **文档里的 OBS 环境变量名是错的**：写的是 `OBS_AK` / `OBS_SK`，实际要 `OBS_ACCESS_KEY_ID` /
+  `OBS_SECRET_ACCESS_KEY`（`upload-obs.mjs` 只认后者，用错会在上传时报「缺少环境变量」）。
+- ETag 快照（`tools/.workbuddy-etags.json`）与打包备份（`data/roster.json.bak-before-pack`）不入库 ——
+  都是机器相关或用完即弃的状态。
+
+### 实测（拿 `book-co-creator` 真跑一遍）
+
+| 阶段 | 结果 |
+|---|---|
+| ① 检测 | 447 个包全部可探测，其中 149 个名册里没有、298 个内容变了 |
+| ② 拉取 | 495 个文件落到 `~/web/t-team/workbuddy-experts/experts/book-co-creator/` |
+| ③ 把关 | 无内部依赖，放行 |
+| ④ 导入 | 先删旧包再导；**名册仍 621（无重复）**，包内 6 → **497 个文件** |
+| ⑤ 打包 | roster 备份 + 合并（178 → 178），tgz **1.1 MB / 491 文件**，落 `dist/assets/marketing/` |
+| ⑥ 上传 | OBS 元数据 sha256 与 roster 一致；**下载回来逐字节校验 491/491 一致** |
+
+> 关键验证点：④ 走的是「删旧包 → 重新导入」——因为 `import-workbuddy.py` 的判重**不认目录形态**。
+> 实测名册总数没有变化，证明这条路没有产生重复。
+
+## [0.4.41] — 未发布
+
+**新增增量同步入口 `tools/sync-from-workbuddy.mjs`** —— 配套 `t-expert-roster-sync` 技能（在 `~/aitools/skills/engineering/`）。
+
+### 新增
+
+- `tools/sync-from-workbuddy.mjs`：六阶段编排（检测 / 拉取 / 把关 / 导入 / 打包 / 上传），
+  面向**日常维护**（腾讯更新了，同步一次），首次导入仍用 `import-workbuddy.py`。
+  - **检测**用 HTTP HEAD 拿 ETag（COS 的 ETag 即内容 MD5）—— 几百个包几秒探完，**不下载**就知道谁变了；
+    快照存 `tools/.workbuddy-etags.json`。实测：447 个包全部可探测，其中 **149 个名册里还没有**、
+    298 个已有但内容变了。
+  - **把关**接 `scan-internal-deps.py`，拦掉绑定腾讯内部系统的专家。这是硬约束 —— 否则下次同步会把
+    已清理的同类原样灌回来。
+  - **导入**用「更新 = 先删旧包目录，再 `--only` 导入」：`import-workbuddy.py` 的判重只认单文件形态
+    （`<分区>/<slug>.md`）、**不认目录形态**，它是给「往空名册里灌」写的，所以不去改那个脚本。
+  - **打包**在 `pack-assets.mjs` 前后对 `roster.json` 做**备份与合并** —— 它写的是全量清单，而它按
+    「本地还能打包的包」重算，附件早在云端时算出来是空的（0.4.39 那条坑的自动化处理）。
+- 支持 `--check`（只报告，不落盘）/ `--dry-run` / `--stage fetch|scan|import|pack|upload`。
+
+## [0.4.40] — 未发布
+
+**新增内部依赖扫描器 `tools/scan-internal-deps.py`** —— 把手工清理时的一次性判定固化成规则。
+
+### 新增
+
+- 判定「这位专家是不是绑定腾讯内部系统」：**算**代码层 API base / MCP URL / 鉴权端点里的
+  `*.woa.com` 与内部服务域名；**不算**遥测（`otlp`/`gocp`/`galileo`）、公开服务
+  （企业微信 / 腾讯文档 / 问卷 / 埋点 / `cloud.tencent.com`）、注释行。
+  支持 `--src` / `--json` / `--exit-code`。
+
+### 修复
+
+- 一个会**静默漏检**的正则 bug：内部服务域名的前缀写成 `+`，而锚定串**自带子域**
+  （`omics.qq.com`），`(?:x\.)+` 贪婪吃掉 `omics.` 后剩 `qq.com` 去匹配 → **必然失败**。
+  实测 `omics` / `andon` 系列**一个都没抓到**（`woa.com` 侥幸正常，因为前缀与锚定串不重叠）。
+- 借此揪出并清掉 2 个更早的漏网专家：`healthcare/mi-zhen-expert`（小于 50 KB 的**本地目录包**，
+  上一轮的取样方式没覆盖到）、`engineering/omics-diagnosis-expert`（被上述正则遮蔽）。
+  名册 **623 → 621**。
+- 教训写进脚本注释：**扫描器必须在已知样本上验证召回率**，否则规则写错会安静地放过该拦的包。
+
+## [0.4.39] — 未发布
+
+**移除 22 位绑定腾讯内部系统的专家** —— 名册 645 → **623**。
+
+### 为什么
+
+从 WorkBuddy 专家市场导入的这批专家里，有一部分**本质上是内部系统的客户端**：脚本把
+API 端点指向腾讯内网域名（`*.woa.com`）或内部服务（`pacs.qq.com`、`andon.qq.com`…）。
+在腾讯内网之外这些专家**核心功能不可用** —— 用户照着正文操作，只会拿到连接失败。
+
+实测例：`sales/cpq` 的 `bin/cpq --help` 报 `status=-401 code=UNAUTHORIZED`，域名指向
+`knot.woa.com` / `cpq.woa.com` / `agent-dashboard.huijin.woa.com`。
+
+### 判定方式（全量扫描 322 个包的代码文件）
+
+- ✅ **算**：代码层作为 API base / MCP URL / 鉴权端点出现的腾讯内网域名
+- ❌ **不算**：**遥测** —— `otlp.j.woa.com`、`gocp.woa.com` 是 OpenTelemetry / GalileoTrace
+  上报（多份 SDK 内嵌了它），失败不影响功能，曾据此误判过一批
+- ❌ **不算**：**公开服务** —— `qyapi.weixin.qq.com`（企业微信）、`doc.weixin.qq.com`（腾讯文档）、
+  `wj.qq.com`（问卷）、`beacon.qq.com`（埋点）、`cloud.tencent.com`（文档链接）
+- ❌ **不算**：`.md` 里的说明性链接（如安全专家正文里的 `10.0.0.4` 示例数据）
+
+### 移除清单（22）
+
+`hr/txzhaopin` `hr/hr-digital-expert` `hr/career-broker`
+`engineering/tiderider-sentiment` `engineering/databrain-opinion-expert` `engineering/wentu`
+`engineering/pneumonia-ai-analyst` `engineering/fundus-disease-analysis`
+`engineering/omics-{bioinfo,iggm,ori,tfold}-expert`
+`research/ab-experiment-analyst` `game-development/databrain-agent-v2` `sales/cpq`
+`supply-chain/tencent-cloud-quote-assistant` `support/tencent-cloud-price-expert`
+`support/migraq` `support/andon-q-expert` `support/cloud-ops-team`
+`design/cloud-requirement-expert` `finance/stock-partner-team`
+
+### 配套
+
+- 新增 **`tools/remove-experts.py`**：按 `<分区>/<slug>` 移除，一次照顾四处（专家包目录、
+  中文侧车、`zh/descriptions.json`、云端清单 `roster.json`），支持 `--dry-run` / `--from`。
+  文件头写明了一个坑：**别再跑 `pack-assets.mjs`** —— 它按「本地还能打包的包」重算
+  `roster.json`，而附件早在云端，会把清单清成空的（本次踩过，已从 git 恢复）。
+- 云端清单 200 → **178**；`data/source.json` 计数 645 → 623；README（两处）/ npm description /
+  许可说明 / 合规声明（`THIRD-PARTY-NOTICES`，无后缀）同步更新 —— 自检盯着这五处数字必须
+  与包内快照一致。
+- `sales/cpq` 的附件仍留在 OBS（约 2.8 MB 孤儿对象）。**故意不删**：无害，且万一要恢复还在。
+
+> **已安装的机器**：升级后名册变 623，但**旧的那 22 个专家目录仍会留在
+> `~/.t-team/experts/`** —— 播种是「增量补新」，不删旧。清掉的办法：删对应目录，
+> 或整体删掉 `~/.t-team` 让宿主重新播种。
+
 ## [0.4.38] — 未发布
 
 **带 CLI 的专家：补上「脚本不在 PATH 里」那段说明** —— 实测 `bin/` 脚本时踩到的真实缺口。

package/README.md

@@ -1,6 +1,6 @@
 # T专家（dsh-plugin-t-expert）
 
-dsh-plugin-t-expert 插件：包含 **22 个分类 / 645 位专家**的名册（中文名、简介全量覆盖）。
+dsh-plugin-t-expert 插件：包含 **22 个分类 / 623 位专家**的名册（中文名、简介全量覆盖）。
 
 装上以后你能做两件事：
 
@@ -89,7 +89,7 @@ remote 入口 `lib/skill-gate-remote.js`（wire 名仍是 `skillGate`，客户
 
 ```
 ~/.t-team/
-├── experts/              名册：<分类>/<slug>.md 或 <分类>/<slug>/（包内快照 22 个分类、645 位；你自建的另计）
+├── experts/              名册：<分类>/<slug>.md 或 <分类>/<slug>/（包内快照 22 个分类、623 位；你自建的另计）
 ├── zh/                   中文侧车：names.json、descriptions.json、<分类>/<slug>.md
 ├── custom/               你在面板里自建的专家
 ├── source.json           名册清单（专家数 / 分类 / 更新时间）

package/THIRD-PARTY-NOTICES

@@ -11,10 +11,10 @@
 | 英文名册 | The Agency / AgentLand（`msitarzewski/agency-agents`）— MIT，Copyright (c) 2025 AgentLand Contributors。完整文本随包：`vendor/third-party-licenses/agency-agents.LICENSE` |
 | 中文译文 | `jnMetaCode/agency-agents-zh`（中文翻译与本地化）— MIT，Copyright (c) 2025 Michael Sitarzewski（英文原版）、Copyright (c) 2026 jnMetaCode（中文翻译与本地化）。完整文本随包：`vendor/third-party-licenses/agency-agents-zh.LICENSE` |
 | 分发形态 | 上述两部分内容随 `@michengai/dsh-agency-agents` 一同分发（该包自身的 TypeScript 源码与构建脚本为 Apache-2.0，**本插件不打包其任何代码**） |
-| 位置 | `data/experts/`（22 个分类 / 645 位）、`data/zh/`（中文名字 / 简介 / 人格正文 / 分类标签） |
+| 位置 | `data/experts/`（22 个分类 / 623 位）、`data/zh/`（中文名字 / 简介 / 人格正文 / 分类标签） |
 | 维护方式 | 上述内容随本插件分发（`data/` 是发布源，不再从上游重新镜像）；`data/source.json` 是该名册的清单（专家数 / 分类 / 更新时间） |
 
-名册的构成分五部分（总计 645 位）：
+名册的构成分五部分（总计 623 位）：
 
 - **279 位来自 `msitarzewski/agency-agents`**（上表英文名册一行）。
 - **35 位来自 `@michengai/dsh-agency-agents` 的包内快照**（company / hr / legal / supply-chain
@@ -34,7 +34,7 @@
 
   它们没有中文译文正文（`data/zh/` 已冻结）；作为例外，中文名与中文简介手写在
   `data/zh/names.json` 与 `data/zh/descriptions.json` 里，人格正文回退英文。
-- **322 位来自 WorkBuddy 专家市场**（腾讯 CodeBuddy 的公开专家市场，2026-09-29 导入）。
+- **300 位来自 WorkBuddy 专家市场**（腾讯 CodeBuddy 的公开专家市场，2026-09-29 导入）。
   它们以「目录形态专家包」随包分发：`<分类>/<slug>/persona.md` 是名册入口，原始 `agents/`、
   `skills/` 与全部附件（references、Databases 等）一并保留在包内。
   **其版权与许可归腾讯及其各自的专家作者所有**，本插件只做本地聚合与形态转换，不声称对其拥有

package/data/experts/academic/family-education-ma/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "family-education-ma",
   "division": "academic",
   "categoryId": "12-IndustryConsultant",
-  "importedAt": "2026-09-29T12:42:05",
+  "importedAt": "2026-09-29T16:33:07",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/academic/ket-prep-team/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "ket-prep-team",
   "division": "academic",
   "categoryId": "12-IndustryConsultant",
-  "importedAt": "2026-09-29T12:42:06",
+  "importedAt": "2026-09-29T16:33:08",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/academic/liuxue-yanxue-expert/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "liuxue-yanxue-expert",
   "division": "academic",
   "categoryId": "12-IndustryConsultant",
-  "importedAt": "2026-09-29T12:42:06",
+  "importedAt": "2026-09-29T16:33:08",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/academic/study-fortune-compass/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "study-fortune-compass",
   "division": "academic",
   "categoryId": "15-BackToSchool",
-  "importedAt": "2026-09-29T12:42:07",
+  "importedAt": "2026-09-29T16:33:09",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/company/campus-event-navigator/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "campus-event-navigator",
   "division": "company",
   "categoryId": "15-BackToSchool",
-  "importedAt": "2026-09-29T12:42:04",
+  "importedAt": "2026-09-29T16:33:06",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/company/fortune-master/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "fortune-master",
   "division": "company",
   "categoryId": "12-IndustryConsultant",
-  "importedAt": "2026-09-29T12:42:05",
+  "importedAt": "2026-09-29T16:33:07",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/company/gaokao-advisor/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "gaokao-advisor",
   "division": "company",
   "categoryId": "12-IndustryConsultant",
-  "importedAt": "2026-09-29T12:42:05",
+  "importedAt": "2026-09-29T16:33:07",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/company/multi-cloud-expert/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "multi-cloud-expert",
   "division": "company",
   "categoryId": "13-TencentZone",
-  "importedAt": "2026-09-29T12:42:07",
+  "importedAt": "2026-09-29T16:33:08",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/company/multi-cloud-management-expert/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "multi-cloud-management-expert",
   "division": "company",
   "categoryId": "13-TencentZone",
-  "importedAt": "2026-09-29T12:42:07",
+  "importedAt": "2026-09-29T16:33:08",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/company/opc-team/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "opc-team",
   "division": "company",
   "categoryId": "12-IndustryConsultant",
-  "importedAt": "2026-09-29T12:42:07",
+  "importedAt": "2026-09-29T16:33:09",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/company/paper-topic-selection/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "paper-topic-selection",
   "division": "company",
   "categoryId": "12-IndustryConsultant",
-  "importedAt": "2026-09-29T12:42:07",
+  "importedAt": "2026-09-29T16:33:09",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/company/tanyuan-cultural-heritage-expert/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "tanyuan-cultural-heritage-expert",
   "division": "company",
   "categoryId": "12-IndustryConsultant",
-  "importedAt": "2026-09-29T12:42:07",
+  "importedAt": "2026-09-29T16:33:09",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/design/adort-design-expert/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "adort-design-expert",
   "division": "design",
   "categoryId": "01-ProductDesign",
-  "importedAt": "2026-09-29T12:42:03",
+  "importedAt": "2026-09-29T16:33:06",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/design/ai-image-prompt-engineer/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "ai-image-prompt-engineer",
   "division": "design",
   "categoryId": "01-ProductDesign",
-  "importedAt": "2026-09-29T12:42:03",
+  "importedAt": "2026-09-29T16:33:06",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/design/ask-liuxiaopai/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "ask-liuxiaopai",
   "division": "design",
   "categoryId": "12-IndustryConsultant",
-  "importedAt": "2026-09-29T12:42:04",
+  "importedAt": "2026-09-29T16:33:06",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/design/delightful-experience-designer/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "delightful-experience-designer",
   "division": "design",
   "categoryId": "01-ProductDesign",
-  "importedAt": "2026-09-29T12:42:04",
+  "importedAt": "2026-09-29T16:33:07",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/design/design-engine/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "design-engine",
   "division": "design",
   "categoryId": "01-ProductDesign",
-  "importedAt": "2026-09-29T12:42:04",
+  "importedAt": "2026-09-29T16:33:07",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/design/design-md-architect/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "design-md-architect",
   "division": "design",
   "categoryId": "01-ProductDesign",
-  "importedAt": "2026-09-29T12:42:04",
+  "importedAt": "2026-09-29T16:33:07",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/design/design-prototype-expert/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "design-prototype-expert",
   "division": "design",
   "categoryId": "01-ProductDesign",
-  "importedAt": "2026-09-29T12:42:04",
+  "importedAt": "2026-09-29T16:33:07",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/design/design-to-code/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "design-to-code",
   "division": "design",
   "categoryId": "01-ProductDesign",
-  "importedAt": "2026-09-29T12:42:04",
+  "importedAt": "2026-09-29T16:33:07",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/design/diversity-visual-expert/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "diversity-visual-expert",
   "division": "design",
   "categoryId": "01-ProductDesign",
-  "importedAt": "2026-09-29T12:42:04",
+  "importedAt": "2026-09-29T16:33:07",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/design/feedback-synthesis-analyst/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "feedback-synthesis-analyst",
   "division": "design",
   "categoryId": "01-ProductDesign",
-  "importedAt": "2026-09-29T12:42:05",
+  "importedAt": "2026-09-29T16:33:07",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/design/mermaid-diagram-expert/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "mermaid-diagram-expert",
   "division": "design",
   "categoryId": "01-ProductDesign",
-  "importedAt": "2026-09-29T12:42:06",
+  "importedAt": "2026-09-29T16:33:08",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/design/migraq-team/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "migraq-team",
   "division": "design",
   "categoryId": "13-TencentZone",
-  "importedAt": "2026-09-29T12:42:06",
+  "importedAt": "2026-09-29T16:33:08",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/design/ngo-challenge-advisor/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "ngo-challenge-advisor",
   "division": "design",
   "categoryId": "01-ProductDesign",
-  "importedAt": "2026-09-29T12:42:07",
+  "importedAt": "2026-09-29T16:33:08",
   "source": "workbuddy expert marketplace (COS)"
 }

package/data/experts/design/product-management/.imported-from-workbuddy

@@ -2,6 +2,6 @@
   "plugin": "product-management",
   "division": "design",
   "categoryId": "01-ProductDesign",
-  "importedAt": "2026-09-29T12:42:07",
+  "importedAt": "2026-09-29T16:33:09",
   "source": "workbuddy expert marketplace (COS)"
 }