v0.5.4 — 适配 dsh 0.1.7-alpha.1（补丁数组 / 锚定 / 解析顺序）+ 测试版原生热装卸说明

0.5.2 → 0.5.4 — 适配 dsh 0.1.7-alpha.1（并说明测试版的原生能力现状）

从 v0.5.1 直接升级即可，无需改任何配置。
dsh plugin --profile <你的 profile> add dsh-hot-installer@latest，装完重启一次（或让它自更新）。

修复

0.5.2 — 兼容 dsh 0.1.7-alpha.1 的「有序补丁文件数组」

• dsh.bundle.patch 从单个文件路径扩展为有序文件数组（@deepseek-ai/dsh-web-app 已改成 5 个文件：主补丁 + 4 个 agent preset）。此前插件把声明直接当字符串交给 path.join，凡是数组声明的 bundle，每次启动都抛 ERR_INVALID_ARG_TYPE，只在日志里留一条 cannot index … for hot removal。现在按声明顺序逐个解析并拼接（顺序与平台一致，顺序错了就摘不掉行）、空数组返回 []、非法声明给出与平台同义的清晰错误。
• 顺带堵掉一个静默降级：没有 dependencies 条目的 bundle（dsh-base / dsh-web-app）此前会被纳入版本热更新；一旦失败，"回滚到空 spec"执行的是 pnpm add <pkg>@ —— 这不是报错，而是装该包的 latest（dsh-web-app@ → 0.0.1-rc.1），回滚后的校验还会通过，于是 profile 被悄悄写坏、重启后 UI 变旧。现在这类 bundle 只索引记账、不纳入 update 管理。

0.5.3 — insert 行的插件名按平台规则锚定

• 平台解析任何补丁文件时（bundle 补丁 / --patch overlay / profile 补丁层），都会把 insert 行里绝对路径或 ./ / ../ 开头的 name 改写成"紧邻该补丁文件"的 file:// URL。插件此前不做这个改写，于是记录的行与活配置里的行匹配不上：热卸摘不掉（日志退化成 rows already gone … nothing to unload）、重挂被去重成空（all rows already present）、既不打印 hot-reloaded，行还继续跑旧代码 —— 又是一次"假成功"。现在做与平台逐字一致的改写（含 group.config 递归）。

0.5.4 — 按平台的顺序解析 bundle 目录（dsh 安装树优先）

• 随 dsh 安装自带的 bundle（dsh-base、dsh-web-app、dsh-experimental-agent-team-profile 等）既不在 profile 的 node_modules、也不在 dependencies 里。平台先查 dsh 安装树、失败才回落 profile；插件此前只查 profile，于是把已被平台正常挂载的 bundle 误报成"未安装"，每次启动留一条 warn（实测触发：在 Web UI 里启用 agent-team 后）。现在复刻平台的锚点顺序，锚点取自平台自己的 profileContext.installAnchor。

关于「测试版 / 实验版」：已自带插件热装 + 热卸

dsh 0.1.6-alpha.2 起（含最新的 0.1.7-alpha.1）自带插件热装与热卸：平台自己的 dsh-hmr 监听 <profile>/package.json，dsh.profile.bundles 变化时原生重组树，因此 dsh plugin add / dsh plugin remove 本来就免重启。

本插件在这条线上会自动进入 specOnly 模式（不抢已被占用的监听路径，改为每秒轮询清单），只补平台跳过的那一段：

• 依赖版本变化（dsh plugin add pkg@新版本）—— 平台在 bundles 列表没变时直接返回，不处理；
• 升级失败的预检 / 回滚 / 紧急卸载防护链。

2026-09-22 用可观测探针（apply() 写 active、被 dispose 时写 disposed）在真实 0.1.7-alpha.1 上实测：

操作	探针自己的日志	本插件日志
dsh plugin add	active	零新增（是平台挂的）
dsh plugin remove	disposed（行被真正卸载）	零新增

稳定线（0.1.5-rc.2 / 0.1.5-rc.3）没有这个能力，装 / 卸 / 升级全靠本插件（已在隔离环境用旧版自己的 CLI 实测：完整能力模式、hot-applied / hot-removed 均成功）。

你的 dsh	平台自身能力	这个插件提供什么
0.1.5-rc.2（npm latest）/ 0.1.5-rc.3	无：HMR 只监听补丁文件，从不看 profile 清单	全部：装 / 卸 / 升级都免重启
0.1.6-alpha.2 及以后（含 0.1.7-alpha.1）	装 + 卸原生免重启	版本升级免重启 + 预检 / 回滚 / 紧急卸载

验证

• 单测 18/18（npm test）：数组解析、name 锚定、平台自有 bundle 分流、解析顺序。
• 与平台逐条对照（用平台自己导出的 resolveBundleDir / bundlePatchPaths / loadOverlayPatches）：真实 profile 全部 6 个 bundle，在"解析到的目录"与"解析出的补丁条目"上 0 处不一致。
• scratch 活测：数组声明不再产出 warn；含相对 name 的 bundle 热重载真的换了代码（A/B 对照：关掉锚定时日志为 rows already gone + all rows already present，行从未重载）。
• 旧版隔离实测：dsh@0.1.5-rc.2 + 0.5.4 → 完整能力模式，hot-applied / hot-removed 均成功。
• 发布物与仓库、与已安装副本的 index.mjs sha256 一致。

安装 / 升级

dsh plugin --profile <你的 profile> add dsh-hot-installer@latest

装完重启一次，之后装 / 卸 / 升级都不再需要重启。

完整逐版本历史见 CHANGELOG.md。

v0.5.1 — 兼容 dsh 0.1.6-alpha.2 + 版本矩阵

0.5.1 — 兼容 dsh 0.1.6-alpha.2 + 版本矩阵

修复

• 兼容 watchConfig / registerConfig 两种方法名：dsh 0.1.6-alpha.2 把 HMR 实现换成 dsh-hmr 并改名了服务方法，0.4.x 在该版本上会抛 TypeError 让热装静默失效（只有日志里一行 error，UI 无提示）。现在特性探测，两代 dsh 用同一份代码。
• 升级假成功：新版 loader 下 entry.update() 会早于树应用返回（实测配置 4→3 时行仍挂载），导致去重误判行还在、跳过重挂，只打印 all rows already present 而模块从未重载。现在删除后有界等待行真正离开树。
• 缓存驱逐覆盖 realpath：Windows 上 link: junction 装的包缓存键是真实路径，只按 node_modules 路径匹配会漏掉。

新增

• 模式自适应：平台（dsh-hmr）已自行监听 profile 清单并原生重组装/卸 bundle，插件检测到路径被占用时自动改为轮询模式，只接管平台跳过的依赖版本变化（add pkg@新版本），并保留缓存驱逐、预检、失败回滚、紧急卸载整条链。

我需要装这个插件吗？

你的 dsh	平台自身能力	这个插件提供什么
0.1.5-rc.2（npm latest）	无：HMR 只监听补丁文件，从不看 profile 清单	全部：装 / 卸 / 升级都免重启
0.1.6-alpha.2 及以后	装 + 卸原生免重启	版本升级免重启 + 预检 / 回滚 / 紧急卸载

安装

dsh plugin --profile <你的 profile> add dsh-hot-installer

装完重启一次，之后装/卸/升级都不再需要重启。

完整历史见 CHANGELOG.md。