[TecFancy]

What and why

dsh 0.2.1-rc.2 users could not install this plugin. The macOS Desktop App rejected
dsh-deeptutor@0.1.9 with:

与 DSH 0.2.1-rc.2 不兼容 (要求 @deepseek-ai/dsh-tools ^0.1.0-rc.6)

Two layers caused it, and either one was enough on its own:

1. The published manifest was too narrow. 0.1.9 declared only
   peerDependencies["@deepseek-ai/dsh-tools"] = "^0.1.0-rc.6" and no engines.dsh.
   The host check (evaluatePluginCompatibility in dsh-app-boot) compares
   engines.dsh, or every @deepseek-ai/dsh-* peer range, against the running host
   version. 0.2.1-rc.2 does not satisfy ^0.1.0-rc.6.
2. The fix existed but was never released. Commit fc0bb67 on development
   widened the range to ^0.2.0-rc.1 but was never pushed or published, so npm kept
   serving 0.1.9.

CI had also been red since 2026-08-29: 772124e moved the shipped skills to
.agents/skills and repointed the package-root scripts/md-to-html.js, but left the
copy under .agents/skills/html-doc/scripts/ on the old template path. The release
workflow runs the same equality check, so even a tag push could not have published.

Changes

• engines.dsh now decides the compatibility check alone:
  ^0.1.0-rc.6 || ^0.2.0-rc.1. The host evaluates it with includePrerelease, so it
  covers the whole 0.2.x prerelease line (0.2.1-rc.2, 0.2.1-rc.3, future rc's).
• the @deepseek-ai/dsh-tools peer range also names ^0.2.1-rc.1, because pnpm/npm
  peer resolution uses strict SemVer, where a prerelease range only matches its own
  major.minor.patch tuple.
• devDependencies move to the cohort this release is built and verified against
  (dsh-tools 0.2.1-rc.3, cordis 4.0.5).
• new tests/manifest.test.ts pins both rules plus the exact 0.2.1-rc.2 /
  0.2.1-rc.3 versions from the report; against the v0.1.9 manifest three of its
  four assertions fail, which is the regression it exists to catch.
• README (EN/ZH) states the supported host lines.
• the two md-to-html.js copies are byte-identical again, which turns CI and the
  release gate green.

Verification

• Host evaluator (@deepseek-ai/dsh-app-boot) on the packed manifest: 0.1.0-rc.6,
  0.2.0-rc.2, 0.2.1-rc.1/rc.2/rc.3 pass; 0.3.0-rc.1 is still rejected.
• The same evaluator on the published 0.1.9 manifest reproduces the reported error
  verbatim ({"@deepseek-ai/dsh-tools":"^0.1.0-rc.6"} unmet on 0.2.1-rc.2).
• Isolated profile on a real dsh 0.2.1-rc.3 host: dsh plugin add of the packed
  tarball succeeds, the bundle auto-registers, and a cold boot through a 150 s probe
  shows no activation failure (the plugin logs [dsh-deeptutor] plugin loaded).
• Clean clone of this branch, running the CI and release gates: npm ci,
  npm run typecheck, npm run build, the two-copy equality check, npm test
  (41 pass) and npm pack --dry-run.

Risk and rollback

Manifest, tests and docs only; no runtime code changed. To roll back, revert the three
commits and untag v0.1.10 if it was published.

Related

Fixes #5