dsh-wsl-tool 1.10.11 → 1.10.12

package/PUBLISHING.md

@@ -117,6 +117,22 @@ both that the entry stays relative and that it resolves.
    artifact, not just the metadata. Scripted requests to `npmjs.com`'s HTML hit a
    Cloudflare challenge; the registry API is the source of truth.
 
+   Two things make a published release look unpublished, so rule them out before
+   believing a negative:
+
+   - **A green run is not proof that npm was published.** The `Publish to npm`
+     step exits 0 with a warning when `NPM_TOKEN` is absent, so the run stays
+     green while npm is skipped. Ask the jobs API whether the step really ran —
+     a real run has `started_at`; a skipped one has `conclusion: skipped` and no
+     timestamp — and ask the registry what actually handles the version
+     (`time[<version>]` on the packument).
+
+   - **A failing `npm whoami` says nothing about the release.** A stale token in
+     `~/.npmrc` only means that machine cannot publish by hand; CI has its own
+     credential. Release state lives in the three artifacts — the tag's commit,
+     the release asset, and the registry tarball — so compare their bytes rather
+     than your credentials.
+
    Expect the registry's caches to lag a publish by minutes, and to lag
    *inconsistently*: the full packument, the abbreviated (install) packument,
    `/-/package/<name>/dist-tags` and the tarball URL each cache separately, so one

package/README.md

@@ -128,7 +128,17 @@ forever.
 
 ## Compatibility
 
-Verified against DSH **0.1.7-rc.2** (and 0.1.5-rc.2 before it): the tool schemas
+The manifest declares the DSH it needs — `"engines": { "dsh": ">=0.1.7-rc.2" }` —
+which is the floor this section documents. The plugin market reads that
+declaration from the published manifest and shows it as a requirement on the
+entry (`DSH >=0.1.7-rc.2`), warning before an install or update onto an older
+host; DSH itself ignores `engines`, so the declaration is advice, not a gate.
+The `-rc.2` is load-bearing: `>=0.1.7` alone excludes the `0.1.7-rc.2` release
+this line was verified on, and the market would then report the plugin as
+incompatible with its own verified host.
+
+Verified against DSH **0.1.7-rc.2** (earlier releases of this plugin were verified
+on 0.1.5-rc.2): the tool schemas
 pass DSH's own `assertSupportedJsonSchema`, the subprocess seam is exercised
 against the real provider rather than a shim, and the background-job path is
 checked against the real job registry, including the session-id ownership fence

package/README.zh-CN.md

@@ -109,7 +109,13 @@ launcher: WSL 版本: 2.6.3.0 · 内核版本: 6.6.87.2-1 · WSLg 版本: 1.0.71
 
 ## 兼容性
 
-已在 DSH **0.1.7-rc.2** 上验证（此前为 0.1.5-rc.2）：工具 schema 通过 DSH 自己的
+清单里声明了它需要的 DSH —— `"engines": { "dsh": ">=0.1.7-rc.2" }`，也就是本节记录的
+下限。插件市场会从已发布的清单读取这条声明，在条目上标成要求（`DSH >=0.1.7-rc.2`），并在
+装到更老的宿主上之前给出提醒；DSH 自身不读 `engines`，所以它是提示而不是门禁。那个
+`-rc.2` 不能省：只写 `>=0.1.7` 会把本条验证过的 `0.1.7-rc.2` 排除掉，市场于是会把插件
+判成与它自己验证过的宿主不兼容。
+
+已在 DSH **0.1.7-rc.2** 上验证（本插件的更早版本曾在 0.1.5-rc.2 上验证）：工具 schema 通过 DSH 自己的
 `assertSupportedJsonSchema`；subprocess 接缝是跑在**真实 provider** 上而非替身；后台任务
 路径跑在**真实 job 注册表**上，包含 0.1.7 收紧的「会话 id 属主围栏」。这套检查就是
 `test/real-seam.mjs`，约一分钟即可重验一个新宿主——升级后把它指向新的 DSH 安装即可：

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-wsl-tool",
-  "version": "1.10.11",
+  "version": "1.10.12",
   "description": "WSL tools for DSH: run Linux commands (fresh shell per call, exit codes and signals, timeouts, truncated output spilled to a file, optional stdin), convert Windows↔WSL paths, report the WSL environment (kernel, systemd, docker, drives), send long builds to background jobs, and guard destructive commands. A left-sidebar panel switches each capability; an opt-in patch points the sidebar terminal at WSL. WSL calls run below the DSH sandbox.",
   "type": "module",
   "main": "index.js",
@@ -18,6 +18,9 @@
       "optional": true
     }
   },
+  "engines": {
+    "dsh": ">=0.1.7-rc.2"
+  },
   "license": "MIT",
   "repository": {
     "type": "git",