dsh-instruction-memory 1.0.7 → 1.0.9

package/README.md

@@ -36,6 +36,7 @@ dsh plugin --profile web remove dsh-instruction-memory
 | `contract-test.mjs` | 契约测试：驱动真实路由，验证两半之间的响应格式 |
 | `verify.mjs` | 装载验证：按 DSH 的方式加载两半 |
 | `smoke-test.mjs` | 注入渲染逻辑的单元测试 |
+| `host-range-test.mjs` | 宿主版本范围契约测试：固定矩阵 × 两种 semver 判定模式，锁死兼容性声明 |
 | `docs/demo.html` | 离线演示页：桩掉 DSH 外壳、加载真实 Client 半渲染设置页（不随 npm 包发布） |
 
 ## 生效方式
@@ -73,10 +74,10 @@ DSH 就会得到第二份空记忆，看起来像"记忆消失"。
 
 ## 兼容性
 
-`dsh.compatibility.dsh` 声明为：
+`dsh.compatibility.dsh` 与 `dsh.engines.dsh` 声明为同一串：
 
 ```
->=0.1.3-alpha.2 <0.1.4 || >=0.1.4-0 <0.1.5-0 || >=0.1.5-alpha.1
+>=0.1.3-alpha.2 <0.1.4 || >=0.1.4-0 <0.1.5-0 || >=0.1.5-alpha.1 <0.1.6-0 || >=0.1.6-alpha.0 <0.1.7-0 || >=0.1.7-alpha.0 <0.2.0-0 || >=0.2.0-0
 ```
 
 **实测范围**：以下 5 个宿主版本已在 **Windows / Node 22** 上逐个真实启动验证（每个版本都确认了
@@ -84,14 +85,34 @@ DSH 就会得到第二份空记忆，看起来像"记忆消失"。
 
 `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`
 
+此外 `0.1.6-alpha.2` 与 `0.1.7-rc.2` 完成了完整的装载与兼容性判定核验（`host-range-test.mjs`
+的固定矩阵覆盖它们，且该脚本会**读取本机实际安装的宿主版本**做实时断言）。
+
 **为什么写成分段形式**：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 个版本。
+major.minor.patch 且自身带预发布标签的比较符"。这条规则是**集合级**的——一个 `||` 分支最多
+覆盖**一个** minor 的预发布版本。由此产生两个必须遵守的约束：
+
+- **宽写法接不住预发布**：`>=0.1.3-alpha.2`、`>=0.1.3-alpha.2 <0.2.0-0` 都**匹配不到**
+  `0.1.4-0` / `0.1.5-rc.1` / `0.1.6-alpha.2`——因为 `0.1.3` 与 `0.2.0` 的 tuple 都不等于
+  它们各自的 tuple（已用 node-semver 7.8.5 实测确认）。
+- **每段的上界不能省**：省略会被上一段的比较符"续接"。例如单写 `>=0.1.5-alpha.1`（不封顶），
+  在把 `0.1.3` 当 token 时会放行 `0.1.3-alpha.0/1`。
+
+⚠️ **一个必须知道的上限**：**未声明的未来 minor 的预发布版本，无法被任何范围覆盖。**
+`0.1.8-rc.1` 这类版本 tuple 与所有比较符都不同，在 npm 语义下**永远匹配不到**——与
+`^0.1.0` 无法匹配 `0.1.8-rc.1` 是同一个限制。正式版（`0.1.8`、`0.2.0`、`1.0.0` 等）不受影响。
+DSH 发布新的预发布 minor 时需追加一段，例如 `|| >=0.1.8-alpha.0 <0.2.0-0`；
+`host-range-test.mjs` 的**实时守卫**会把这类缺口暴露出来（它直接读本机安装的宿主版本）。
+
+**历史修复说明**（同一个 bug 出现过两次，值得记下来）：
+
+- 1.0.7 及以前，范围末段是 `>=0.1.5-alpha.1`，使宿主 `0.1.6-alpha.2` 在 npm **默认**语义下
+  被判为**不兼容**（预发布门禁要求 tuple 相同：`0.1.5 ≠ 0.1.6`，`>=` 的大小比较根本走不到）。
+- 1.0.8 改为逐段枚举，但只枚举到 `0.1.6`。DSH 随后发布 `0.1.7-rc.2`，**同一个假阴性再次出现**：
+  范围里最后一个预发布 tuple 是 `0.1.6`，而 `0.1.7 ≠ 0.1.6`。1.0.9 补上 `0.1.7` 段。
 
-**为什么没有上限**：不设上限，未来 DSH 发布新的预发布版本时不会被判为"超出上限"而拒绝升级。
-代价是 `0.2.0` / `1.0.0` 这类未来版本在 node-semver 下也会被判为满足；若你希望严格封顶，
-在末尾追加 `<0.2.0-0` 即可（注意那会让下一版 0.1.6+ 被市场判为超限）。
+两次都因为插件市场传入 `includePrerelease: true` 而侥幸放行，但任何标准 semver 判定
+（`npm` / `pnpm` 的依赖解析）都会拒绝。现在 `host-range-test.mjs` 同时具备固定矩阵与实时守卫。
 
 **未验证范围**：macOS / Linux、`headless` 与 `tui` profile、以及上表之外的其他 DSH 版本均未实测。
 
@@ -99,6 +120,7 @@ major.minor.patch 且自身带预发布标签的比较符"。因此看起来很
 市场只读 `engines.dsh` / `dsh.engines.dsh` 以及 `@deepseek-ai/dsh*` 的 `peerDependencies`，并不读 `dsh.compatibility.dsh`。
 从 1.0.4 起宿主要求会真实出现在市场卡片上，并生效于安装前的校验：**范围之外的宿主上，市场会把本插件从列表中隐藏并拒绝安装/更新**
 （市场只隐藏"确认不兼容"的条目；"未声明"或"无法确认"的条目照常显示）。范围之外的宿主仍可自行用 `dsh plugin add` 安装，只是不再被市场担保。
+`host-range-test.mjs` 会断言这两处字段逐字节一致。
 
 ## 发布（维护者）
 

package/lib/client.js

@@ -541,7 +541,15 @@ window.__ModuleLoader__.load({
       })
 
       ctx.effect(() => slots.inject('settings.section', () => slots.register(
-        { name: 'settings.section', id: 'instruction-memory', order: 26, label: '指令记忆' },
+        // `order` 1200 deliberately sits far above every official section
+        // (general 0, models 10, plugins 15, agent-presets 20, archived-
+        // sessions 25) and above the third-party ones in the wild (mnemon 20,
+        // pet 30, market 40, prompt-optimizer 90, better-sidebar 100,
+        // version-update 140). `settings.section` is a `list` slot, so a
+        // duplicate order does not throw — it silently makes the render order
+        // depend on registration timing. The previous value was 26, one above
+        // the official tail: a single new official section would have collided.
+        { name: 'settings.section', id: 'instruction-memory', order: 1200, label: '指令记忆' },
         () => h(InstructionPanel, null),
       )))
     }

package/lib/index.js

@@ -36,7 +36,28 @@ const STORE_FILE_NAME = 'memory.json'
 /** Pre-release location, kept only so existing installs can migrate off it. */
 const LEGACY_FILE_NAME = '.dsh-instruction-memory.json'
 const SECTION_NAME = 'instruction-memory'
-const SECTION_ORDER = 900
+/**
+ * Placement of the injected instruction block among the system prompt's
+ * ordered sections. Sections are concatenated ascending; equal orders fall
+ * back to code-unit name order, which is not something a plugin can reason
+ * about — so this value must not collide with a reserved slot.
+ *
+ * `@deepseek-ai/dsh-system-prompt` owns a central `SECTION_ORDERS` table
+ * (0.1.7-rc.2): HARNESS_IDENTITY -1000, DEPLOYMENT_PERSONA_PREFIX 0,
+ * PLAN_POLICY 500, TEAM_POLICY 600, PTC_ONLY 800, FILE_REFERENCE **900**,
+ * TOOL_BASH 1000, … STRUCTURED_OUTPUT 9900, HARNESS_SOURCE 10000,
+ * WEB_SURFACE 10100, DEPLOYMENT_PERSONA_SUFFIX 10200.
+ *
+ * This was 900 through 1.0.8 — an exact tie with FILE_REFERENCE. It never
+ * threw (a tie only degrades to dictionary order), and it happened to sort
+ * the way we wanted: `instruction-memory` > `file-reference` on code units
+ * ('i' 105 > 'f' 102), so the block landed just after the file references.
+ * That is an accident of the name, not a decision, and renaming the section
+ * would silently move it. 950 states the intent outright: in the gap between
+ * FILE_REFERENCE (900) and TOOL_BASH (1000) — after the file-reference block,
+ * before the tool descriptions, clear of every reserved value.
+ */
+const SECTION_ORDER = 950
 const API_PREFIX = '/instruction-memory/api'
 /** Request body ceiling for the settings-page route; anything larger is rejected. */
 const MAX_BODY_CHARS = 1_000_000

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-instruction-memory",
-  "version": "1.0.7",
+  "version": "1.0.9",
   "description": "User-only instruction memory for DSH: long-term instructions maintained in the settings UI and auto-injected into every conversation — the model has no write access. 指令记忆：只由用户在设置页维护的长期指令，自动注入此后每轮对话；模型没有任何写入口。",
   "license": "MIT",
   "type": "module",
@@ -52,7 +52,7 @@
   },
   "author": "huangpeiyan",
   "scripts": {
-    "test": "node smoke-test.mjs && node contract-test.mjs && node verify.mjs",
+    "test": "node host-range-test.mjs && node smoke-test.mjs && node contract-test.mjs && node verify.mjs",
     "prepublishOnly": "node check-metadata.mjs"
   },
   "dsh": {
@@ -61,16 +61,16 @@
     },
     "client": {
       "inject": [
-        "@deepseek-ai/dsh-client-runtime",
-        "@deepseek-ai/dsh-client-ui-slots"
+        "@deepseek-ai/dsh-client-ui-renderer",
+        "@deepseek-ai/dsh-client-ui-settings"
       ],
       "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"
+      "dsh": ">=0.1.3-alpha.2 <0.1.4 || >=0.1.4-0 <0.1.5-0 || >=0.1.5-alpha.1 <0.1.6-0 || >=0.1.6-alpha.0 <0.1.7-0 || >=0.1.7-alpha.0 <0.2.0-0 || >=0.2.0-0"
     },
     "compatibility": {
-      "dsh": ">=0.1.3-alpha.2 <0.1.4 || >=0.1.4-0 <0.1.5-0 || >=0.1.5-alpha.1"
+      "dsh": ">=0.1.3-alpha.2 <0.1.4 || >=0.1.4-0 <0.1.5-0 || >=0.1.5-alpha.1 <0.1.6-0 || >=0.1.6-alpha.0 <0.1.7-0 || >=0.1.7-alpha.0 <0.2.0-0 || >=0.2.0-0"
     }
   }
 }