Skip to content

Stop tying the plugin to one dsh line, and ask for Evolver 2.0.39 - #28

Merged
forrestlinfeng merged 1 commit into
mainfrom
claude/plugin-dsh-version-decoupling-60a70c
Sep 26, 2026
Merged

forrestlinfeng merged 1 commit into
mainfrom
claude/plugin-dsh-version-decoupling-60a70c

Conversation

@forrestlinfeng

Copy link
Copy Markdown
Contributor

The problem

dsh upgrades often. The peer ranges said <0.1.7, and 0.1.7-rc.2 is already published — so on paper the plugin no longer supports the dsh users are upgrading to.

What the range was actually protecting

Nothing. Checked in dsh-app-boot:

  • the loader does no version check on plugin peers;
  • profiles install with autoInstallPeers: false;
  • the host hands the plugin its own dsh-llm / dsh-tools / dsh-skill at runtime (module fallback).

What can really break is the API surface the plugin imports — four symbols:

symbol package in 0.1.7?
createUserMessage dsh-llm ✅
boundContextSummary dsh-llm ✅
defineTool dsh-tools ✅
BUNDLED_SKILL_RANK dsh-skill ✅

What changes

  • Peers → >=0.1.5-0, no upper bound.
  • CI tests against 0.1.5-rc.3 plus the next and alpha dist-tags, and runs daily — an incompatible dsh release turns CI red before users upgrade into it, instead of the range going stale again.
  • Evolver < 2.0.39 is the one dependency that does gate behaviour: an older Proxy answers every text recall empty, so priming silently injects nothing. /proxy/status doesn't carry a version, so the plugin reads evolver --version once at boot; below 2.0.39 the first step of a session carries an upgrade notice (npm install -g @evomap/evolver@latest), at most once a day per installed version. No evolver on PATH → no notice. /evolver-status names the minimum too.

Verification

95/95 on each of:

  • 0.1.5-rc.3
  • 0.1.7-alpha.2
  • 0.1.7-rc.2

New tests put a fake evolver on PATH, so the suite never depends on what the machine has installed.

Caveats

  • Not yet booted inside a real dsh 0.1.7 host (local dsh is 0.1.5-rc.1).
  • Under strict npm semver >=0.1.5-0 doesn't match 0.1.7-rc.x. pnpm likely treats prereleases as matching for peer checks, but that is unconfirmed. Either way the worst case is an install-time warning — peers are host-provided. No strict-semver range covers future prereleases.
  • The version probe isn't exercised on Windows. It fails closed there: no notice.

🤖 Generated with Claude Code

dsh upgrades often, and the peer ranges said `<0.1.7` while 0.1.7-rc.2 is
already published. The range never protected anything: dsh's loader does no
version check, the profile installs with autoInstallPeers off, and the host
hands the plugin its own dsh-llm / dsh-tools / dsh-skill at runtime. What can
actually break is the four symbols the plugin imports -- createUserMessage,
boundContextSummary, defineTool, BUNDLED_SKILL_RANK -- and all four are still
exported in 0.1.7.

So the ranges become `>=0.1.5-0`, and the guard moves to where breakage shows
up: CI runs the suite against the `next` and `alpha` dist-tags as well as
0.1.5-rc.3, and runs daily, so an incompatible dsh release turns CI red before
users upgrade into it. 95/95 pass on 0.1.5-rc.3, 0.1.7-alpha.2 and 0.1.7-rc.2.

Evolver is the one dependency that does gate behaviour: a Proxy older than
2.0.39 answers every text recall empty, so priming silently injects nothing.
The Proxy status does not carry its version, so the plugin reads
`evolver --version` once at boot and, below 2.0.39, the first step of a
session carries a notice with the upgrade command -- at most once a day per
installed version. No evolver on PATH means no notice; /evolver-status covers
that case and now names the minimum too.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@forrestlinfeng
forrestlinfeng merged commit b8f1827 into main Sep 26, 2026
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant