Repository navigation
0.3.1 声明修正版
本版只改兼容性声明，不改插件行为：engines.dsh 从没有上界的 >=0.2.0-rc.2 改成 ^0.2.0-rc.2 || ^0.2.1-0，5 个 @deepseek-ai/dsh-* peer 与 2 个 @deepseek-ai/dsh-* dependency 同步到同一区间。源码与界面没有变化。
修正一：补上上界
旧区间 >=0.2.0-rc.2 没有上界，DSH 连 1.0.0 都判为兼容。本插件的职责是限制工具：若未来的大版本改了 tools.restrict 的语义，插件会「照常加载但限制没生效」——这比直接被禁用更危险。新区间盘掉 0.3.0、0.3.0-alpha.* 与 1.0.0。
修正二：0.2.0-rc.2 上的放宽从来没有生效
engines.dsh 这个判定机制是 DSH 0.2.1-alpha.4 才引入的。更早的宿主（包括 0.2.0-rc.2）根本不读 engines.dsh，只看 peerDependencies；而之前的 peer 区间是 ^0.2.1-alpha.2，在 0.2.0-rc.2 上不满足 —— 插件会被判为不兼容并被禁用。
所以「支持 0.2.0-rc.2」这条放宽，在真正能用到它的宿主上其实一次都没生效。现在 engines.dsh 与 peer 使用同一区间，两条判定路径结论一致。
为什么区间写成这样
^0.2.0-rc.2 || ^0.2.1-0 不够直观，但它是唯一能同时满足两个消费者的写法：
| 消费者 | 判定语义 |
|---|---|
DSH（evaluatePluginCompatibility） |
semver.satisfies(range, { includePrerelease: true }) |
| npm / pnpm | 默认模式：预发布版本只有在同一 主.次.修 三元组也带预发布号时才匹配 |
更直观的 >=0.2.0-rc.2 <0.3.0-0 在 npm 模式下会拒掉 0.2.1-alpha.* 与 0.2.1-rc.*（实测：pnpm install --frozen-lockfile 直接报错），在 DSH 模式下却放行。^0.2.1-0 里的 -0 把 0.2.1 三元组的预发布纳入匹配，两个模式的结论由此一致。
验证
- 用 DSH
0.2.1-rc.2的官方evaluatePluginCompatibility跑本 manifest：0.2.0-rc.1、0.3.0-alpha.1、0.3.0、1.0.0均不兼容；0.2.0-rc.2起至0.2.2全部兼容。 pnpm install --frozen-lockfile通过，pnpm peers check无问题。pnpm run typecheck/build/test（19 个文件、300 个测试）全过。
升级提示
- 已在 DSH
0.2.1.x上的用户：无感知，照常安装即可。 - 想留在
0.2.0-rc.2的用户：现在会被判为兼容，但本插件没有在0.2.0-rc.2实机上跑过（只在0.2.1-alpha.2与0.2.1-rc.2上验证过 API 与装配）。若装配后界面异常，请提 issue，并可用dsh plugin add @dotdance/dsh-skill-scope@0.3.0回退。