[Bug] Upgrading only @deepseek-ai/dsh* to 0.2.2-rc.1 leaves the cordis family at 4.0.x — pnpm exits 0, boot fails with version-unrelated errors

[LUgABeEEE]

Environment: Linux x86_64, Node v22.23.4 (see related note below), pnpm 12.10.1, DSH profile upgrading from 0.2.1-rc.5 to 0.2.2-rc.1 (web profile, ~325 deps, 44 bundles, a few local plugins).

Summary

When upgrading a profile to 0.2.2-rc.1, bumping only the @deepseek-ai/dsh* packages and forgetting the cordis family (@deepseek-ai/cordis, -plugin-group, -plugin-include, -plugin-loader, -plugin-timer, cosmokit, schemastery) produces a successful-looking install that only fails at boot, with errors that never mention a version. It would be very helpful if the upgrade guide called this out explicitly, and/or if the runtime asserted it.

What I did

# in a copy of the profile (production untouched)
sed -i 's/0\.2\.1-rc\.5/0.2.2-rc.1/g' package.json   # 282 @deepseek-ai/dsh* packages only
pnpm install --lockfile-only

Observed

check	result
pnpm install --lockfile-only	exit code 0, no error printed
cordis@4.1.0 occurrences in the lockfile	0
cordis@4.0.5 occurrences in the lockfile	1676
pnpm peers check	23 unmet peers, 6 of them are the cordis family itself

strict-peer-dependencies is off by default, so pnpm only warns. The installed tree then looks fine (pnpm list succeeds) and the profile boots into failures such as "a service is missing" / "configuration cannot be read" / "fiber config has an unexpected shape" — none of which point at @deepseek-ai/cordis.

Root cause

Every @deepseek-ai/dsh*@0.2.2-rc.1 package declares the cordis family as a peer, e.g.

$ tar -xOf dsh-agent-0.2.2-rc.1.tgz package/package.json | jq .peerDependencies
{ "@deepseek-ai/cordis": "~4.1.0", ... }

and the 0.2.2 release notes do mention "Update to Cordis Core 4.1.0, Loader 1.1.0, Include 1.1.0", but nothing in the upgrade path turns that into a hard failure: the dsh packages are upgraded by name (@deepseek-ai/dsh*), while the cordis packages are a different name pattern, so a scripted "bump all dsh packages" upgrade misses them by construction.

Suggested fixes (any one would help)

1. A startup assertion in app-boot: read the resolved @deepseek-ai/cordis version and fail loudly ("expected ~4.1.0, found 4.0.5 — upgrade the cordis family together with the engine") before mounting anything.
2. Upgrade guide: an explicit "these 7 packages must be upgraded in the same batch" list, next to the existing engines/plugin-API migration steps.
3. dsh doctor (or --dump-config) check: report unmet cordis-family peers, since pnpm's own warning is easy to lose in install output.

Workaround we use

Bump the cordis family in the same loop as the @deepseek-ai/dsh* packages, then verify:

grep -c 'cordis@4.1.0' pnpm-lock.yaml     # must be > 0
pnpm peers check                          # cordis-family entries must be gone

Why I'm reporting this

It cost us one "successful" dry run to notice, and the failure mode (install OK, boot broken, message unrelated to versions) is the kind of thing that is expensive to reproduce remotely. If the intended behavior is "users must bump both groups", a one-line assertion would save that.

[Muguett-DBY]

One separate variable in the reproduction: the 0.2.2-rc.1 CLI manifest declares Node >=24.9.0; the release notes also call out that minimum. If 22.23.4 is the Node executing the profile, rather than a system Node while another runtime launches it, that is below the supported floor. pnpm 12 itself is a native executable, so a successful lockfile-only run does not establish which Node will execute DSH.

Could you compare the mismatched and aligned Cordis dependencies under Node 24.9+ in the same copied profile? That would help separate the peer mismatch from a runtime-version effect; it doesn't rule out the peer-dependency problem. I checked the package metadata and documentation, but haven't reproduced your profile's boot failure.

[LUgABeEEE]

Thanks — you're right that Node is a separate variable, and we've now run the comparison you asked for. One of our original claims does not survive it, so let me correct it explicitly.

What we re-ran (Node 24.22.2, same copied profile)

run	what	result
A. lockfile-only	282 × @deepseek-ai/dsh* at 0.2.2-rc.1, cordis family pinned back to 4.0.5 / 1.0.6 / 1.0.10 / 1.0.5 / 1.1.7 / 1.8.6 / 3.18.5	exit 0; lockfile contains cordis@4.0.5 ×5580, cordis@4.1.0 ×0 — same as under Node 22, so the silence is not a Node artifact (as you suspected, pnpm is a native binary; it doesn't care which Node will execute DSH)
B. real install + boot	same profile, Node 24.22.2, real pnpm install, then boot the web app	starts and serves: HTTP 200, 333 client plugin entries in the page, 0 errors/warnings in the log, process stays up

So: we withdraw the "boot fails with version-unrelated errors" wording. With cordis 4.0.5 + dsh 0.2.2 packages the app comes up and serves the UI. That part of my report was inference, not an observed failure — your push to separate the variables is what surfaced it.

What does remain (and why I still think a diagnostic is worth it)

The mismatch is not fatal at boot, but it is silently wrong in specific code paths, and the evidence is in the trees:

• @deepseek-ai/dsh-hmr@0.2.2-rc.1 lib/index.js:1071 reads fiber.rawConfig;
• dsh-settings / dsh-experimental-translator reference rawConfig / effectiveConfig as well;
• @deepseek-ai/cordis@4.0.5 lib/index.js contains 0 occurrences of rawConfig (4.1.0 contains 2).

So those reads yield undefined instead of throwing — config/HMR/translator paths degrade quietly. We have not exercised them (no settings save, no hot reload in this probe), so I state it as a code-level expectation, not a measured failure.

Revised ask

Not "make install fail", but "make the mismatch visible":

1. an engines-style check that reports the resolved cordis-family versions next to the engine version (in dsh doctor, --dump-config, or a single startup warning line);
2. the upgrade guide saying the cordis family must be bumped in the same batch (which is what we now do, but only after learning it the hard way).

Is cordis 4.0.5 + dsh 0.2.2-rc.1 explicitly unsupported, i.e. should we treat any such tree as broken by definition? If you want, we can also test the settings-save and hot-reload paths on the mismatched tree and report what actually breaks — that would turn the remaining claim into measured behavior.

[Muguett-DBY]

Thanks for rerunning this on Node 24 and correcting the boot result.

For the three packages you named, the published 0.2.2-rc.1 manifests—hmr, settings, and experimental-translator—each declare @deepseek-ai/cordis: ~4.1.0 as a peer. So, if those plugins resolve to 4.0.5, that pairing is outside their declared peer range. I can't speak for the maintainers' broader support policy, and the metadata alone doesn't establish a runtime failure.

The settings-save and hot-reload comparison you offered would be useful for separating a declared mismatch from an observed problem. I haven't inspected the dependency graph or exercised those paths in your profile.

[XuZhangxing]

你用的是客户端吧，昨天web版的 dsh 上master似乎已经更新到@deepseek-ai/cordis: ~4.1.0了

[jjjjjjjjnnjnn]

One data point supporting your proposed startup assertion: the boot-time declaration gate cannot detect a @deepseek-ai/cordis family mismatch because none of the involved packages declare a DSH constraint.

Declaration-layer admission readings at target runtime 0.2.2-rc.1:

• @deepseek-ai/dsh@0.2.2-rc.1 -> unconstrained (declares no DSH range)
• @deepseek-ai/cordis@4.1.0 -> unconstrained
• @deepseek-ai/cordis@4.0.5 -> unconstrained

The declaration gate only inspects engines.dsh and @deepseek-ai/dsh* peer declarations. Because all three manifests evaluate to unconstrained, the declaration layer is blind to whether @deepseek-ai/cordis@4.1.0 or @deepseek-ai/cordis@4.0.5 is loaded alongside @deepseek-ai/dsh@0.2.2-rc.1. An unconstrained verdict only means no range was declared; it is not compatible.

What you can do:

• Treat unconstrained packages as unverified by the manifest gate when diagnosing cross-family version drift.
• Keep the explicit runtime assertion in app-boot, since declaration-layer checks cannot catch a @deepseek-ai/cordis mismatch.

Boundary: Our tool does not detect this failure; it only evaluates declaration-layer admission and cannot see cross-family runtime mismatches. This reads published manifests from npm, not your machine. Declaration-layer admission does not prove runtime health.

Recompute artifact:

• https://github.com/jjjjjjjjnnjnn/dsh-triage/blob/main/data/results/remedy-probe-2026-11-05T08-06-24-136Z.json (sha256 50455dfb5db76bc75985bf4284eb74125869fbeb65e1ca5f7b4e699cf78e989c)