headless profile lacks services that session-category plugins depend on

[Ruqii]

A plugin that works in web can stop headless from booting, with no warning at install time and nothing in --dump-config to indicate it.

Reproduction

export DSH_HOME=/tmp/dsh-repro
dsh --profile headless --dump-config >/dev/null      # bootstrap
dsh plugin --profile headless add github:csyangwen/dsh-memory-evolve
dsh --profile headless --dump-config | grep memory   # present in the composed tree
dsh --profile headless "Say OK."

Result:

dsh: plugin tree failed to load: dsh: 1 entry did not activate
dsh-memory-evolve: pending (waiting for service: workspaceRegistry)

The harness will not start at all until the plugin is removed. The same install under --profile web activates and runs normally.

dsh-memory-evolve is the highest-starred memory plugin in the community directory, so this is not an obscure edge case.

Why it is hard to diagnose

• dsh plugin add exits 0 and warns about nothing.
• --dump-config lists the plugin in the composed tree, because it composes without booting.
• The real cause only appears on stderr of a crashed process, after the plugin is already installed.

A user who installs a plugin into headless gets a harness that no longer runs, and the most obvious diagnostic says everything is fine.

Not specific to one plugin or one service

Testing four memory/session plugins in headless, each failed for a different missing piece of the same kind:

plugin	outcome in headless
dsh-memory-evolve	pending (waiting for service: workspaceRegistry), boot fails
dsh-memento	boots, but its memory write is rejected — no approver exists, so it silently falls back to a file
@furongjun1999/dsh-memory	loads and activates, and the agent reports it has no cross-session memory

workspaceRegistry is owned by @deepseek-ai/dsh-workspace, which itself injects storageDomain and sessionPersistence. None of those declare dsh.bundle, so they cannot be added to a profile with dsh plugin add. Stacking the shipped bundles instead — dsh-base + dsh-web-app + dsh-headless — fails with duplicate loader entry id: code-runtime, so the two app bundles appear to be mutually exclusive by design.

The effect is that the session category (252 plugins in the community directory) is effectively web-only, and there is no supported way to run those plugins in an automated context.

What would help

Any one of these would resolve it:

1. Fail the install, not the boot. If a plugin's required services are absent from the target profile, dsh plugin add could say so instead of leaving a harness that will not start.
2. A way for a plugin to declare the services it needs, so the mismatch is visible before installation rather than after.
3. A services-complete headless mode — the web service stack without the web app — so plugins that depend on workspace/session/approval services can run non-interactively.

(3) is the one that unlocks automation, but (1) alone would turn a broken harness into a clear message.

Versions: @deepseek-ai/dsh@0.1.0-rc.6, node v24.7.0, macOS.

[weijiafu14]

这份报告的质量很高，尤其是那张四个插件四种不同失败方式的表——它证明了这不是某个插件的打包问题。补两件：一条可能今天就能给用户止血的路，和一个诊断层面的观察。

一、你的"方案 1（在安装时失败，而不是启动时）"可以更快落地——已经有人在做同类检查了

你写的这条最有价值：

dsh plugin add exits 0 and warns about nothing.
--dump-config lists the plugin in the composed tree, because it composes without booting.

问题不只是"没有警告"，是诊断工具主动认证了一个坏掉的状态。 用户去查 --dump-config，它说一切正常——于是他排除了"插件装错了"这个方向，转而怀疑别的。这比没有诊断工具更糟。

好消息是：这个前提条件在离线状态下是可判定的。cordis 在组合期就知道每个 entry 声明了哪些 inject，也知道这个组合里哪些服务有 provider。"声明的 inject 里有本组合无人提供的服务"是一个纯静态检查，不需要启动。

而且已经有人在做这一类事了。#1697 那边为另一个 profile 层缺陷（顶层 hoist 的 @deepseek-ai/* 副本遮蔽宿主）产出了两个独立的离线诊断器：

• moonquake2004/dsh-doctor（profile / session / env 离线诊断，19 项检查）
• zoahdev/dsh-plugin-doctor（发布前的插件 + profile 探针，--profile <dir>）

"未满足的 service 依赖"和它们已有的 profile 检查是同一类东西（都是"这个 profile 组合起来会不会坏"），而且两位作者已经在讨论对齐彼此的 contract（JSON schema / exit codes）。我建议把你这条带着那张四插件的表去找他们——这可能让用户在上游改之前就有一个 dsh-doctor 能报出来的检查，而你手上正好有现成的复现集。

（顺带一句：那两个工具本身也是"profile 层的问题必须能离线判定"这个思路的产物。你这条是同一思路的第二个实例，加起来对上游立"安装时校验"更有说服力。）

二、headless 与 web 的差异，可能比"缺服务"更值得说清

你查到的这条是整帖第二贵的：

workspaceRegistry 由 @deepseek-ai/dsh-workspace 拥有，而它自己又 inject storageDomain 和 sessionPersistence。这些都没声明 dsh.bundle，所以没法用 dsh plugin add 加进 profile。而堆叠现成 bundle（dsh-base + dsh-web-app + dsh-headless）会撞 duplicate loader entry id: code-runtime——两个 app bundle 看起来是设计上互斥的。

也就是说：这不是"headless 少装了一个包"，而是这批服务在当前的打包边界下对 headless 不可达。 用户没有任何拼装的余地——这一点建议在原帖里加粗，因为它决定了修法：

• 如果只是"少装了包"，那答案是文档 + 一条 dsh plugin add；
• 但按你查到的，答案只能是上游决定 headless 该不该拥有 session/workspace 这一族服务——这是产品边界问题，不是配置问题。

而"社区目录里 252 个 session 类插件事实上只能在 web 上跑"这个数字，是这个产品决策最有力的输入。建议把这句从"影响"挪到摘要第一行。

三、一个可能对读者有用的区分

你表里三个插件失败得不一样，其中 dsh-memento 那条特别值得单独说：

boots, but its memory write is rejected — no approver exists, so it silently falls back to a file

前两种（启动失败、明确报缺服务）至少是响亮的。而这一种是静默降级：插件活着、agent 也不报错，但它宣称的能力其实没在工作，用户要过很久才会发现"记忆好像没生效"。

这属于这个社区反复出现的一类——诊断信息在系统里真实存在过，只是没送到需要它的人手上（我最近数到第八次：设置写入被静默吞掉、agent-preset-invalid 被前端扔掉、deny hook 被静默跳过、缺凭据导致 MCP 工具静默不注册……）。

对你的提案的意义：即使方案 1（安装时失败）做了，也只挡住第一种。 第三种（能启动但能力静默失效）需要的是另一件事——插件在关键依赖缺失时应该 fail loud，而不是降级到一条用户不知道的路径上。这两件事值得在原帖里分开列，否则很容易被当成一个诉求一起排期，然后只修了容易的那半。

边界与利益相关

我们不修 DSH 自家组件——bundle 边界、dsh-workspace 的服务归属、dsh plugin add 的校验都在 DSH 里。上面全是建议和归类；我没有复现过你这四个插件的场景（也没在 headless 下装过它们），全部建立在你贴出的输出上。第一节提到的两个诊断器是别人的项目，我只是读过那帖。

利益相关：我维护 pi2dsh（Pi 生态兼容层），我们自己的规矩是每个场景必须在 CLI（headless）与 Web 双端都跑通才算完成——所以我对"同一个东西在两个 profile 下行为不同"这件事比较敏感。这条不推销：你要的是 headless 能跑 session 类插件，那是 DSH 的 bundle 边界问题，换任何插件都不会让 workspaceRegistry 出现在 headless 里。