# 兼容范围由 peer 区间声明，插件版本号不跟 dsh 版本走

dsh 的兼容闸门会把插件每条 `@deepseek-ai/dsh` / `@deepseek-ai/dsh-*` peer 区间与**单一** runtimeVersion
比对（`includePrerelease: true`）；不在区间里的插件，用 registry 规格安装会被直接拒绝，按路径安装则留在盘上、
但在 profile 启动时被禁用。`@deepseek-ai/cordis` 与 `react` 不在检查范围内。所以"能装在哪些 dsh 上"
这件事只有一个开关：peer 区间。我们把它写成 `>=0.1.5-rc.2 <0.3.0-0`，一份 bundle 覆盖 0.1.5-rc.2 直到 0.2.x；
插件版本号继续按自己的 semver 走（本次 0.19.0），不与 dsh 版本对齐。

## Considered Options

- **收窄到 `>=0.2.0-rc.2 <0.3.0-0`**（放弃 0.1.x）：承诺范围等于验证范围，最保守。没选它是因为 npm 上唯一
  可用的旧版本 0.17.0 在 0.1.7+ 上白屏、0.18.0 从未发布——收窄会让 0.1.x 用户手里彻底没有可用版本。
- **维护两条区间 / 两个发布轨**：被"单轨维护"约定否掉，而且代码层面没有需要分叉之处：0.1.7-rc.2 → 0.2.0-rc.2
  之间插件用到的 API 逐字节未变，唯一断点就是区间上界（见 issue #1）。

## Consequences

- **声明范围宽于真机验证范围**：`devDependencies` 只能钉一代（现为 0.2.0-rc.2），所以 0.1.x 一侧靠
  "代码与 0.18.0 完全相同"这一事实背书，而不是每次升级都真机回归。README 要如实写明这个区别。
- **升级的第一步是查闸门，不是查 API**：下次 dsh 换线时，先用 `dev-isolate.sh`（必要时 `STRICT_VERSION=1`）
  确认目标宿主落在区间内，再去读 API 差异——本次两者查完的结论是"区间是唯一断点"。
- **区间上界要主动跟**：`<0.3.0-0` 把整条 0.2 线一次收进来，下一次风险点是 0.3 发布（巡检思路见 issue #2）。