dsh-instruction-memory 1.0.2 → 1.0.4

package/README.md

@@ -61,10 +61,32 @@ DSH 就会得到第二份空记忆，看起来像"记忆消失"。
 
 ## 兼容性
 
-`dsh.compatibility.dsh` 声明为 `>=0.1.5-rc.1`。
+`dsh.compatibility.dsh` 声明为：
 
-**准确说明**：本插件仅在 **dsh 0.1.5-rc.1（Windows / Node 22）** 上实测通过。
-该版本下限是"已实测"的记录，不是对更高版本兼容性的验证结论。
+```
+>=0.1.3-alpha.2 <0.1.4 || >=0.1.4-0 <0.1.5-0 || >=0.1.5-alpha.1
+```
+
+**实测范围**：以下 5 个宿主版本已在 **Windows / Node 22** 上逐个真实启动验证（每个版本都确认了
+插件装载、系统提示注入真的进入组装后的提示、插件 HTTP 路由可应答、客户端设置页模块被下发）：
+
+`0.1.3-alpha.2` · `0.1.5-alpha.1` · `0.1.5-alpha.2` · `0.1.5-rc.1` · `0.1.5-rc.2`
+
+**为什么写成分段形式**：node-semver 规定"候选版本带预发布标签时，区间里必须存在同一个
+major.minor.patch 且自身带预发布标签的比较符"。因此看起来很宽的写法——例如 `>=0.1.3-alpha.2`
+甚至 `>=0.1.3-alpha.2 <0.2.0-0`——**反而匹配不到** `0.1.5-rc.1` / `0.1.5-rc.2` 这些预发布版本
+（已用 node-semver 7.8.5 与插件市场自带的版本判定实现逐一实测确认）。分段写法在两者下都能覆盖上面 5 个版本。
+
+**为什么没有上限**：不设上限，未来 DSH 发布新的预发布版本时不会被判为"超出上限"而拒绝升级。
+代价是 `0.2.0` / `1.0.0` 这类未来版本在 node-semver 下也会被判为满足；若你希望严格封顶，
+在末尾追加 `<0.2.0-0` 即可（注意那会让下一版 0.1.6+ 被市场判为超限）。
+
+**未验证范围**：macOS / Linux、`headless` 与 `tui` profile、以及上表之外的其他 DSH 版本均未实测。
+
+**同一串范围写在两处**：`dsh.compatibility.dsh`（插件自己的字段）与 `dsh.engines.dsh`（插件市场**实际读取**的位置）。
+市场只读 `engines.dsh` / `dsh.engines.dsh` 以及 `@deepseek-ai/dsh*` 的 `peerDependencies`，并不读 `dsh.compatibility.dsh`。
+从 1.0.4 起宿主要求会真实出现在市场卡片上，并生效于安装前的校验：**范围之外的宿主上，市场会把本插件从列表中隐藏并拒绝安装/更新**
+（市场只隐藏"确认不兼容"的条目；"未声明"或"无法确认"的条目照常显示）。范围之外的宿主仍可自行用 `dsh plugin add` 安装，只是不再被市场担保。
 
 ## 发布（维护者）
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-instruction-memory",
-  "version": "1.0.2",
+  "version": "1.0.4",
   "description": "DSH 指令记忆：在设置界面中维护可增删改的长期指令，并自动注入此后每一轮对话的系统提示词。",
   "license": "MIT",
   "type": "module",
@@ -60,8 +60,11 @@
       ],
       "platform": "web"
     },
+    "engines": {
+      "dsh": ">=0.1.3-alpha.2 <0.1.4 || >=0.1.4-0 <0.1.5-0 || >=0.1.5-alpha.1"
+    },
     "compatibility": {
-      "dsh": ">=0.1.5-rc.1"
+      "dsh": ">=0.1.3-alpha.2 <0.1.4 || >=0.1.4-0 <0.1.5-0 || >=0.1.5-alpha.1"
     }
   }
 }