模型炼丹失败，工具每次更新直接挂能不能加一个过滤机制 不兼容的 插件启动的时候会直接过滤掉

[springsky1]

过滤不兼容的插件，现在每次排查那个插件不兼容要好长时间⌛️ 都是直接删除.dsh 后一个个试 然后再还原备份

[pisce188]

其实不用删除的，dsh是根据profile来的，你的插件是注册到profile里进行使用的，比如说你默认的profile是web，那你的所有插件可以都注册到这个profile里。
同时，你可以启动另外一个用于纠错的profile，比方说叫dev，上面不注册任何的插件，当你web的插件不兼容挂了的情况下，你打开这个dev的页面，它因为没有注册过插件，是纯净的。然后它也能访问你的~/.dsh目录，可以帮你修复另一个profile里插件不兼容的问题。

[z14git]

dsh跟炼丹有半毛钱关系？

[argszero]

Your request is reasonable, and part of it already exists — but not the part you need. Here is what I can contribute, with measurements.

The filter that already exists (and why it doesn't help here)

dsh plugins declare compatibility through peerDependencies on @deepseek-ai/dsh-*. npm enforces that at install time, so a correct range makes the install fail loudly — which is exactly the "filter incompatible plugins" behaviour you want, just moved one step earlier.

It fails to filter for two reasons.

1. Declared ranges are routinely wrong — too narrow. I maintain community plugins and measured this on my own set. A real example from one of my packages:

>=0.1.2-rc.1 <0.2.0 || >=0.1.5-alpha.1 <0.2.0

A semver comparator admits a prerelease only when some comparator in the same group shares that prerelease's major.minor.patch tuple, so <0.2.0 is inert for prereleases. That range admits 5 of the 12 released versions and refuses the entire 0.1.6 line — so a user on the newest dsh could not install the plugin at all, while the plugin's own suite passed on that line. I found this shape in 4 of my packages across two rounds. It is a common authoring bug, not an exotic one.

2. Declared ranges are also wrong in the other direction — too broad. Then the install succeeds and it breaks at runtime, which no install-time filter can catch.

And a third case worth separating out: sometimes it isn't incompatibility at all. Discussion #7031 is a harness regression in CJS resolution routing (resolve.paths() returns null for core module names) that takes down any profile pulling in jsdom. The plugins there are victims, not causes. A compatibility filter would not have helped and would have mislabelled them.

An audit you can run today, against your installed plugin set:

npm view <plugin> peerDependencies

Compare each declared line against the dsh you are actually running (dsh --version). A plugin declaring a line that cannot include your version is a candidate before you install it.

The structural gap: boot is all-or-nothing

packages/boot/app-boot/src/index.ts mounts the whole config tree and any single entry failure propagates: boot() sets stage = 'plugin tree failed to load', disposes the partially-built context, and the host exits. There is no per-entry isolation, which is why you end up bisecting by hand.

What does exist nearby: auditStartupEntries() already reports inactive required entries, including all of them in one message. That machinery reports entries that resolved but did not activate — not entries that failed to import.

What I'd suggest instead of a silent filter

Isolate per-entry import failure at boot:

• catch the failure for that entry, write it as disabled (the reconciliation path already writes that flag), and continue booting the rest
• surface it — a startup banner and a CLI/UI listing, naming the entry and the package

The trade-off has to be stated explicitly, because the obvious cheap version is worse than the status quo: silently dropping a plugin is more dangerous than refusing to start. A skipped plugin looks like a working one; its tool simply never appears, and you lose the feature without any signal. Whatever isolation ships must make the skip visible.

That would turn your workflow from "delete .dsh, re-add plugins one at a time, restore from backup" into "boot succeeds, banner names the one plugin that didn't load".

Immediate unblock for today

The boot error already names the offender, so you don't need to delete .dsh at all — look for this line in the startup output:

failed to import loader entry <name> (<package>)

and remove just that package (dsh plugin --profile web remove <package>). The second-clean-profile trick described above works well too: keep a dev profile with no plugins registered, so you always have a bootable environment to repair the other one from.

I maintain several community plugins of my own; if a range on any of them refuses your dsh line, that is a bug on my side and I would want it reported — it is exactly the defect I have been fixing in my own set.

[argszero]

Follow-up: I ran that audit across my whole published set. It was worse than the four I quoted above, and the worst case is not a refusal at all.

Above I said I had found the too-narrow range in four of my packages. I then swept all 22 and computed each declared range's real admitted set with semver, instead of reading the string.

The audit, runnable now

# What does this plugin's declared range ACTUALLY admit, out of everything published?
node -e '
const {satisfies}=require("semver"),{execFileSync}=require("child_process");
const p=require(process.argv[1]+"/package.json");
const v=JSON.parse(execFileSync("npm",["view","@deepseek-ai/dsh-llm","versions","--json"],{encoding:"utf8"}));
for (const [d,r] of Object.entries(p.peerDependencies ?? {}))
  if (d.startsWith("@deepseek-ai/dsh-")) {
    const a=v.filter(x=>satisfies(x,r));
    console.log(d, a.length+"/"+v.length,
      a.includes(v[v.length-1]) ? "(covers newest)" : "(NEWEST LINE REFUSED)", r);
  }
' node_modules/<plugin>

The decisive output is the tail of each line: does the admitted set reach the newest published dsh, or stop short of it.

What it found (22 packages, 2026-09-18; newest dsh = 0.1.6-alpha.2)

Five packages refused the newest line outright. Every user on 0.1.6-alpha.2 got ERESOLVE and could not install them at all — while each plugin's own test suite passed on that line. Three carried the same range:

>=0.1.2-rc.1 <0.2.0 || >=0.1.5-alpha.1 <0.2.0

and two carried a three-clause variant that also named 0.1.3-alpha.1. In both forms the defect is identical: <0.2.0 is inert against prereleases, so it excludes no later line, and no comparator named the 0.1.6 tuple. They admitted 5 and 6 of the 23 published versions respectively. Fixed and published:

package	fixed in	admits now
@argszero/cordis-plugin-llm-tool-call-guard	0.1.5	8/23
@argszero/cordis-plugin-schedule-cron	0.1.2	8/23
@argszero/cordis-plugin-turn-budget-guard	0.1.1	8/23
@argszero/cordis-plugin-prompt-audit	0.1.1	8/23
@argszero/cordis-plugin-job-id-guidance	0.1.1	8/23

Three packages refuse exactly one version on purpose — they read the assistant-stream area, which does not exist before 0.1.3-alpha.2. That is a correct narrow range, not a bug. Worth stating because a narrow range is not automatically the defect, and mislabelling those three would send their authors chasing nothing.

The case a startup filter can never catch

subagent-effort@0.1.0 declared five harness packages as dependencies at ^0.1.1-rc.2 instead of as peers. A caret on a prerelease admits only its own tuple, so no newer tree can satisfy it — and npm resolves an unsatisfiable dependency by nesting its own copy. Measured, installing the published 0.1.0 into a project running 0.1.6-alpha.2:

node_modules/@argszero/cordis-plugin-subagent-effort/node_modules/@deepseek-ai/dsh-tools   (=0.1.1-rc.2)
node_modules/@deepseek-ai/dsh-tools                                                        (=0.1.6-alpha.2)

Install succeeds. No warning, no error, and the plugin still loads — so nothing at boot reports a problem. Two copies of the harness runtime in one process. This is precisely the failure mode a compatibility filter cannot reach: by the time a filter runs, the install has already succeeded, and at runtime the symptom is a symptom, not a mismatch report. Fixed in subagent-effort@0.1.1 by declaring them as peers; the same narrow scope now yields ERESOLVE, which is the correct answer for a user on a line that plugin does not target.

Why the wrong ranges shipped with green CI

This is the part I would underline for plugin authors, because the obvious guard does not work.

• Two of the five shipped a guard that only pattern-matched the range string — it asserted the range mentioned 0.1.2-rc.N and 0.1.5-alpha.N. That cannot distinguish a correct range from an incorrect one; it fails only on a different-looking string. So it certified the broken range.
• Two had no tests and no test script at all.
• One had a genuinely good semver-based guard, with a claimed-lines list and an "admits nothing it was not tested against" assertion — and it still missed this. Its claimed list was written before 0.1.6 existed, and a closed list can never notice that a newly published line is being refused. It guarded the over-admission direction only.

The invariant that actually covers it is asserting set equality in both directions — every claimed version admitted, and nothing but claimed versions admitted — plus an explicit assertion that the newest published release is admitted, or is refused with a stated reason. That last one is what turns a range from a claim into a checked claim. The same files now also assert that the README quotes the manifest range verbatim, since a README that quotes part of a union teaches readers to copy the broken form.

What generalises

A declared range is a prediction about future releases, and nothing re-measures it when upstream cuts one. 0.1.6-alpha.2 was published after I wrote those ranges; the predictions silently expired, and the packages kept passing their own CI the whole time.

So the request in this thread is half-reachable. A startup filter would catch plugins that fail to load. It cannot catch a plugin that installs cleanly and then misbehaves — and in my set, that was the more dangerous of the two defects. The upstream-side change with the best ratio would be author-facing rather than user-facing: publish the released dsh lines in a machine-readable place, so "does my declared range include the newest line?" is a CI check rather than something every author has to remember. That would have caught all six of these before release, and it costs nothing at boot.