插件因工具重名注册失败时用户完全不可感知：市场仍显示已启用、无 UI 提示、无任何日志

[Hrainy1]

环境

• OS：Windows 11（build 26100，24H2）
• DSH Desktop：0.2.0-rc.2（DeepSeek Harness.exe 文件版本），profile=desktop
• 相关插件（均已从市场安装，均为第三方）：@a9i5k4/dsh-auto-memory 3.2.14、dsh-continual-evolve 0.15.4、以及一个自研 MCP 记忆插件

现象（都是实测，不是推理）

三个记忆类插件同时启用后重启 DSH，其中一个插件（@a9i5k4/dsh-auto-memory）看起来已安装、已启用，但实际完全没有生效，而且任何地方都没有一条错误：

1. 它注入系统提示的静态纪律段（由该插件 lib/index.js:1135 的 staticHead: '[记忆系统 — 固定纪律]…' 与 :8190 renderMemoryStatic() 提供）在重启后的系统提示里完全消失。
2. 它注册的工具在新会话里一个都不存在。旧会话目录里能查到它曾注册过的 15 个名字：
   memory_log, memory_recall, memory_read, memory_rules, memory_note, memory_user, memory_status, memory_external, memory_trace, memory_reflect, memory_expand, memory_procedure, memory_procedure_list, memory_consolidate, memory_maintain
3. 它自己写的诊断日志 %DSH_HOME%\dsh-auto-memory-diagnose.log 在重启后没有新增任何一行（最后一行停在重启前：turn-stopping fired: turn=17 hasAgent=true），说明它的 apply 阶段根本没有走到写日志的那一步。
4. 宿主与桌面端日志里没有任何注册失败痕迹（下面给了复现命令，命中数 = 0）。
5. 配置与市场侧仍然显示"已安装/已启用"：package.json 的 dependencies 里有它，profile 的 cordis.patch.yml 里有它的行。用户没有任何办法知道它其实是死的。

复现命令与结果

# ① 旧会话里它确实注册过这些工具
Select-String -Path "%DSH_HOME%\storages\session_projcache\sessions\session-*.json" `
  -Pattern 'memory_[a-z_]{2,20}' -AllMatches |
  ForEach-Object { $_.Matches.Value } | Sort-Object -Unique
# -> memory_consolidate memory_expand memory_external memory_log memory_maintain memory_note
#    memory_procedure memory_procedure_list memory_read memory_recall memory_reflect
#    memory_rules memory_status memory_trace memory_user

# ② 宿主 / 桌面端 / 市场日志里搜索注册失败
Select-String -Path "%DSH_HOME%\logs\*","%APPDATA%\@deepseek-ai\dsh-desktop\*" `
  -Pattern 'is already registered','already registered in this scope','NamedEntries'
# -> 0 hit（三种模式都是 0）

代码依据（只读检索安装包内 @deepseek-ai/dsh-tools）

// node_modules/@deepseek-ai/dsh-tools/lib/index.js:2634
this.tools = new NamedEntries((name) => new Error(scope === void 0
  ? `tool "${name}" is already registered (for a per-agent variant, register through that agent's \`agent.ctx\` instead)`
  : `tool "${name}" is already registered in this scope`));

// node_modules/@deepseek-ai/dsh-tools/lib/index.js:2886（ScopedLayers 见 :2690）
register(definition) { … this.layers.effect(this.ctx, (layer) => layer.tools.insert(name, definition),
  { label: "tools.register()" }); }

同类"重名即抛"的守卫也存在于系统提示层：@deepseek-ai/dsh-system-prompt/lib/index.js:190-192（section / context / variable 同名都会抛 … is already registered）。

我们的推断（明确是推断）

同时启用的两个记忆插件提供同名工具（我们这边两边都有 memory_read）。按上面的守卫，后注册的一方会抛错；插件 apply 期间抛错 → 它之前注册的所有 effect 被回滚 → 该插件"整体静默失效"，而错误只在宿主内部被吞掉/未落盘。

诚实说明：其中一个插件已在故障当天被我们卸载（%DSH_HOME%\profiles\desktop\.dsh-market\log.ndjson 有 uninstall … exit=0 记录），所以我们现在无法复现、也拿不到原始抛错堆栈。这也是我写这条帖子的原因之一：错误一旦丢失就再也找不回来。

相关既有讨论（本条不重复它们）

发帖前我检索了既有讨论，机制层面已经有帖子覆盖，我在这里明确引用，避免重复报告：

• Duplicate registration: [scope] Error: tool "subagent" is already registered in this scope #8201 已记录同一条守卫抛出：…dsh-tools/lib/index.js:2634（NamedEntries.duplicateError）← :29（insert）← :2886（layers.effect.label）← dsh-scope/lib/index.js:206，并指出 factory-default profile 下也会出现；其回复还提到切换 preset 后静默少工具（会话只有 13 个工具，缺 subagent/list_subagent_models）。
• Duplicate in-box `@deepseek-ai/*` package in a profile silently breaks every tool call #8287（Duplicate in-box package in a profile silently breaks every tool call）、[Bug] client-connection is missing the webServer injection: every third-party rpc.handle registration fails silently #6880（client-connection 缺少 webServer 注入，第三方 rpc.handle 注册静默失败）：同属"注册失败对用户不可见"这一类。

本条补充的是第三方插件之间冲突时的用户侧观测结果：日志 0 命中、市场仍显示已启用、插件自身诊断日志停止增长，并且一次冲突会把该插件的全部工具 + 系统提示注入段一起抹掉——用户没有任何可见线索。这与 #8201 的"单条 [E] 日志"不同：我们这里连一条日志都没有。

诉求（按优先级）

1. 注册失败必须用户可见：插件页/启动提示明确显示 failed to register: tool "memory_read" is already registered …，并写入 %DSH_HOME%\logs 下的持久日志（现在搜索结果为 0）。
2. 重名冲突不要整体回滚插件：建议降级为"跳过冲突项 + 明确警告"，否则一个工具名冲突就能让整个插件失效，而用户无从判断。
3. 提供自助诊断入口：例如启动时打印每个 bundle 的注册摘要（成功注册了哪些工具/哪些被跳过/为什么），或 dsh doctor plugins 之类的命令。
4. 文档补充插件工具命名约定：现有报错只提示 per-agent 变体要经 agent.ctx 注册，没有说明跨插件同层重名时的官方建议（命名空间前缀？声明式依赖？）。

我不是这两个插件的作者，以上全部是终端用户侧的只读取证。如果维护者需要，我可以重装那两个插件做一次复现并把原始抛错栈贴回来。

[argszero]

Your write-up is precise enough that the mechanism can be settled from the source, and it changes one part of your inference in a way that matters: the error is not swallowed — it is emitted, into a sink nobody can read. Three facts, each with its line.

1. The failure is real, and in-process it is logged. Fiber._reload() catches a plugin body's throw, calls this.ctx.logger.error(reason), records _error, and leaves the fiber in FAILED; the same catch then unloads the fiber (vendor/cordis/src/fiber.ts:657-670; state read at :576). That unload is what takes the whole plugin down: every effect it registered — all 15 tools, the system-prompt section — is owned by that fiber and is disposed with it. So your observation is exactly right, including the all-or-nothing part, and a duplicate tool name is a sufficient trigger: NamedEntries.insert throws before any insertion (packages/core/scope/src/store.ts:43-45), ScopedLayers.effect rethrows out of the registration call (:226, :251-254), and the error leaves the plugin body.

2. Startup only fails for core entry ids; a third-party failure is a warning on stderr. auditStartupEntries (packages/boot/app-boot/src/index.ts:928-942) marks an entry "required" only when it is the bootstrap Include or its id is in requiredStartupEntryIds (:748-757): agent-loop, webserver, web-runtime, modules, connection, headless-runner, acp, sdk-jsonrpc-server. A third-party plugin id cannot ever be in that set, so a failing third-party entry can never make startup throw; it falls to :941 — one line, "<bin>: warning: N entries did not activate" plus <id> (<package>): <original error and stack> — written to process.stderr, with successful siblings left running. That is deliberate: one bad third-party plugin must not stop the application.

3. That is why your search returned 0. The persistent report under $DSH_HOME/logs/ is written from exactly one place, apps/cli/src/startup-diagnostics.ts:34-59 (startup-<timestamp>-<uuid>.log), and its only caller is the StartupError handler in apps/cli/src/bin.ts:44-46. A third-party-only failure never produces a StartupError, so that file is never created — zero hits is the expected result, not evidence that something swallowed the error. In the desktop build the warning takes one further hop: the host's stderr is drained into a bounded in-memory buffer (apps/desktop/src/host-process.ts:147, :204, cap 64 KiB at :51) and is only ever attached to an exit error message (:228). While the app runs normally, that text exists nowhere a user can reach.

So the honest summary of your incident: the plugin did fail, the harness did name the reason, and the only durable record was a stderr line the desktop shell discards. The market showing it as installed and enabled is a separate, also-expected fact: the market reflects the profile row, not the activation result.

You can confirm this without reinstalling the removed plugin. Mount two throwaway plugins that each register a tool with the same name and launch the CLI from a terminal (dsh --profile <name>): the second one's tools and prompt sections disappear and the terminal prints the warning with tool "<name>" is already registered … and the plugin's own stack. The desktop throws the same line away.

On the plugin-form option — the state is readable without any core change. The loader exposes its entries (ctx.loader.entries(), service typed in vendor/loader/src/index.ts:23), every entry carries its fiber, and Fiber.await() rethrows the original activation error (vendor/cordis/src/fiber.ts:704-708). An audit that lists every entry that did not activate, with its package and its real stack, is therefore a plugin, not a patch. One trap worth recording for anyone who tries it: FiberState is a declare const enum (vendor/cordis/src/fiber.ts:147-155) and is erased at runtime — import { FiberState } from '@deepseek-ai/cordis' evaluates to undefined in the published build, so classification has to be behavioural (await fiber.await() throws) rather than a comparison against state constants.

On your four asks, specifically:

1. I agree, and the machinery already exists: formatActivationError renders exactly the report you want, and the $DSH_HOME/logs writer is already there. Today the non-fatal path simply cannot reach it, so the same failure is filed as fatal in one launch and invisible in another depending only on which entry id failed.
2. Not rolling back the whole plugin is a policy decision I would not make from outside the core; note that the rollback is the fiber unload, so any relaxation has to be a decision about registration semantics (skip-and-warn versus throw), not about the throw itself.
3. That is what I am building in plugin form, and I will post the package link here when it is on npm.
4. Your last ask is the cheapest and probably the most useful: the message's advice covers per-agent variants of one plugin, while collisions between plugins have no documented convention today — and the activation report is the natural place to state one.

[argszero]

@argszero/dsh-activation-doctor@0.1.0 is on npm

The package I said I would post here — npm · source (MIT, 21 files, no runtime dependencies beyond the harness).

It is a sink for the state the harness already composes and never files. Mount it, or apply its bundled patch:

- insert:
    - id: activation-doctor
      name: '@argszero/dsh-activation-doctor'
      inject:
        - loader

After the loader goes quiet it sweeps ctx.loader.entries() (this tree and every nested subtree), awaits each fiber to recover the original error and stack, and writes:

dsh: activation-doctor: 1 entry did not activate (report: /home/me/.dsh/logs/activation-2026-10-10T04-45-02.509Z-e5af0fec-….log)
  collide-b (./fixtures/collide-b.mjs): Error: tool "shared_tool" is already registered

The report is $DSH_HOME/logs/activation-<timestamp>-<uuid>.log, directory 0700, file 0600, created with wx. It carries the credential warning first, then the index, then each entry's full stack; where an operator's reportDir cannot be written, the whole text goes to stderr instead of the operator losing both halves. internal/status fires for every fiber in the process, so a failure that appears later — hot reload, patch re-application, a plugin mounted after startup — is reported too, and activation_status answers the same question on demand from the same sweep.

Four-way classification, deliberately behavioural: await fiber.await() is the primary question, because FiberState is a const enum and is erased at emit time — import { FiberState } from '@deepseek-ai/cordis' evaluates to undefined, so fiber.state === FiberState.FAILED is false for a failure. The numeric state is read only after a successful settle, to separate active from pending, and anything unnamed is reported as unknown with its raw value rather than guessed into a category.

Boundary, stated in the README as well: it does not revive the failed plugin, change registration semantics, touch the marketplace row, or move the desktop's stderr. A colliding registration still fails. It is a detector.

The thing it caught on the way

My first working build of the doctor died of exactly the failure this thread is about, and the mechanism is worth a separate note because it is silent in the same way:

a plugin whose exported Config is a plain defaults object throws TypeError: Cannot read properties of undefined (reading 'validate') out of Fiber._reload, and its fiber unloads before apply ever runs.

resolveConfig (vendor/cordis/src/fiber.ts) validates through runtime.Config['~standard'].validate(config) whenever the runtime carries a Config at all, and runtime.Config is whatever the plugin object exposes. A standard-schema has ~standard; a plain object does not. Measured on both lines, cordis@4.0.4 and cordis@4.0.5-alpha.1:

mount spelling	Config on the plugin object	result
ctx.plugin(moduleNamespace)	absent (the namespace exposes no Config)	mounts
ctx.plugin(moduleNamespace.default)	plain object	throws
loader entry (unwrapExports returns .default)	plain object	throws
any spelling	standard-schema	mounts and validates

The asymmetry is the trap: ctx.plugin(import * as mod) works while the identical module fails when a profile mounts it, because unwrapExports returns moduleNamespace.default ?? moduleNamespace and the loader registers that object. A harness that mounts the namespace, therefore, cannot see the defect that the deployment hits. I hit it the moment the doctor was mounted as an entry.

The fix is one line — drop the Config export and normalize in code, or declare a schema — and it is what this package does, with the reasoning in the source. I have not filed anything upstream about it: the behaviour reads as intended (a plain object is not a schema), and what is missing is not a change but a signal — which is this package's whole subject.

What it was measured against

node scripts/probe-lines.mjs copies the package into a scratch tree per line, pins the whole line (17 packages, read back from disk to prove the pins applied), installs with --legacy-peer-deps, builds and runs the suite:

• @deepseek-ai/dsh-tools 0.1.7-rc.2, 0.2.0-rc.2, 0.2.1-alpha.2 — all PASS
• @deepseek-ai/cordis 4.0.4, 4.0.5-alpha.1 — both covered by those three trees

The suite mounts a real context, the real loader, the real SystemPrompt and ToolRuntime, and real fixture modules on disk; the incident is reproduced rather than simulated (two fixtures claim one tool name, the second throws, its fiber unloads whole), and a control arm mounts everything except the doctor, so "the report names the failure" is never confounded with "the failure happened at all". npm run test:inject mutates each distinction in turn: 25 arms, 25 caught, 0 silent.

[argszero]

Follow-up: the same mount failure was in ten more of my published plugins — fixed at 0.1.1, with the regression test my own suites were missing.

The doctor announced above reports plugins that are mounted but never activate. Sweeping my published plugins against the shape behind that failure turned up ten more, all mine, all one line:

export default { name, inject, apply, Config: defaultConfig }

vendor/loader normalises a plugin module with exports.default ?? exports and hands that object to ctx.plugin, which validates Config['~standard'].validate whenever the plugin carries a Config. defaultConfig is a plain object — the reference a normalizeConfig reads — but it has no ~standard, so runtime.Config['~standard'] was undefined and every mount of the published package threw

TypeError: Cannot read properties of undefined (reading 'validate')

before the first line of apply ran. Released as 0.1.1 for each of: @argszero/dsh-destructive-command-guard, -effort-route-guard, -empty-block-guard, -histexpand-guard, -hook-sandbox-advisor, -image-price-fallback, -peer-range-audit, -phantom-tool-call-guard, -tool-identity-pin-guard, -upload-index-cache. The default export is now { name, inject, apply }, and the defaults arrive through apply(ctx, config = {}).

Why the suites stayed green is the part worth keeping. Every test in those packages imports the module namespace (import * as plugin) and mounts that. The namespace has no Config of its own, so runtime.Config was undefined, resolveConfig returned the config untouched, and the tests passed — while the object a profile entry actually reaches, the default export, was mounted by nothing. Each package now ships test/mount.spec.mjs, which mounts the default export; restoring Config: defaultConfig fails it with exactly the error above.

The rule I'd take from it: a plugin's Config must be a real standard schema (export const Config = z.object(…)) or absent. A plain object in that position is not a lenient default — it is a mount that throws.

[Hrainy1]

English summary. Thank you for the mechanism walkthrough — it matches our report line by line. We have corrected our original claim: the failure is not "logged nowhere"; it goes to ctx.logger.error() with no logger sink mounted in the shipped profiles, one warning line does reach stderr on a terminal launch, the desktop shell keeps stderr in a 64 KiB in-memory ring buffer attached only on exit, and the durable startup-<timestamp>-<uuid>.log is written only from the fatal path. We are now reproducing your duplicate-name experiment on Windows 11 (26100) + DSH Desktop 0.2.0-rc.2 and will post the result (stderr + generated activation report) right below.

---

感谢 @argszero 的机制说明，逐条对上了我们这边观察到的现象。按你的回帖，我们把原帖里不准确的地方更正如下（原帖保留以便对照）：

更正 1｜不是"无任何日志"，而是"写进了没有 sink 的 logger"
失败并不是被静默吞掉：Fiber._reload() 捕获插件体抛出的错误后调用 this.ctx.logger.error(reason)，记录错误、把该 fiber 置为 FAILED，然后卸载整个 fiber（vendor/cordis/src/fiber.ts:657-670；状态读取在 :576）。出厂 profile 没有挂 logger sink，所以那行日志没有去处——这点我们原来的表述是错的。

更正 2｜CLI 从终端启动时，stderr 上其实有一行
auditStartupEntries（packages/boot/app-boot/src/index.ts:928-942）只把 bootstrap Include 与 requiredStartupEntryIds（:748-757）视为"必需"；第三方 id 永远走 warn 分支（:941），在终端会看到：

<bin>: warning: N entries did not activate
<id> (<package>): tool "<name>" is already registered …

我们此前只在桌面端复现，所以从来没看到这一行——这也是"零命中"的来源之一。

更正 3｜桌面端把 stderr 收进了内存
桌面构建把宿主 stderr 排进一个有上限的环形缓冲（apps/desktop/src/host-process.ts:147，上限 :51 = 64 KiB，读点在 :204），只在退出时才把它附到错误信息上（:228）；持久报告 startup-<timestamp>-<uuid>.log 只从致命路径写出（apps/cli/src/startup-diagnostics.ts:34-59，唯一调用者 apps/cli/src/bin.ts:44-46）。所以在桌面端，用户确实"什么都查不到"。

仍然成立的部分：一个插件只要在 apply 期间抛错，它此前贡献的全部工具与提示段会被整体卸载，而市场那一行依旧显示"已安装/已启用"；对用户而言，除了终端那一行 stderr（桌面端还会丢掉），没有任何可查的东西。我们的诉求 ①（失败必须落盘）与 ④（跨插件工具重名的约定）这两点，仍然希望核心团队考虑。

下一步（本机验证）：我们会在 Windows 11（26100）+ DSH Desktop 0.2.0-rc.2 上，按你给的方式做一次复现——两个只注册同一个工具名的一次性插件，挂在独立 profile 里从终端启动——然后把 stderr 原文与 @argszero/dsh-activation-doctor 生成的 $DSH_HOME/logs/activation-*.log（脱敏后）原样贴在楼下。顺带说明：你邮件里提到 0.1.1，但 npm 上该包的 latest 目前仍是 0.1.0（全部版本只有 0.0.0-stage 与 0.1.0），我们就用 0.1.0 验证；如果 0.1.1 已发布请告知，我们改用它复测。

[Hrainy1]

Verified on Windows — the doctor works, and here is the whole failure from the outside

I ran an isolated reproduction of the mechanism described in this thread instead of only reasoning about it. Nothing here touched my real profile: a fresh DSH_HOME, a scratch profile made from the shipped web template, the doctor installed with dsh plugin --profile doctorlab add @argszero/dsh-activation-doctor@0.1.0, and two hand-written probe plugins mounted through --patch.

Install gate. The tarball I audited matches the registry: sha512-XxeHGXr/SY0BcrGXJGiRnmtNevt7xRMfegh9VmD8NlfAV4kQwpGj/zWo0ckmXdMNCQDN961U8sigQdoMKLbifA==, 12 files, no install scripts, no runtime dependencies, no network or child-process calls; the only writes are the report file (0700 directory, 0600 file, wx). Node 24.21.0 satisfies engines, the local harness satisfies the @deepseek-ai/dsh-tools peer range.

Arm 1 — two plugins registering the same tool name. Terminal: dsh: warning: 1 entry did not activate, immediately followed by the original error:

probe-b (doctor-probe-b): Error: tool "doctor_probe_collision" is already registered
  (for a per-agent variant, register through that agent's `agent.ctx` instead)
    at NamedEntries.duplicateError (…/dsh-tools/lib/index.js:2634:59)
    at NamedEntries.insert (…/dsh-scope/lib/index.js:29:34)
    at layers.effect.label (…/dsh-tools/lib/index.js:2886:62)
    at ScopedLayers.effect (…/dsh-scope/lib/index.js:192:14)
    at Proxy.register (…/dsh-tools/lib/index.js:2886:22)
    at Object.apply (…/cordis/lib/index.js:120:36)
    at new apply (…/doctorlab/node_modules/doctor-probe-b/index.js:44:13)
    at Fiber.execute (…/cordis/lib/index.js:1068:24)
    at file:///…/profiles/doctorlab/#probe-b
    at file:///…/profiles/doctorlab/#include

The first registrant stays active, the second plugin is unloaded whole, and the doctor's own line names entry plus error and points at the report file. That is exactly the silent-disappearance symptom: the marketplace still lists the plugin as installed and enabled.

Arm 2 — control. With only one probe mounted there is no warning line and no report file at all. The doctor does not cry wolf.

Arm 3 — is the failed fiber's registration released? Not synchronously with the throw. A second probe in the same include batch still collided with the name the throwing probe had registered microseconds earlier; a probe that waited 2.5 s and then registered the same name succeeded. So the unload does release the effects, but a collision can cascade inside one startup batch.

Arm 4 — import-level failures are classified separately. An entry whose module never loads is reported as failed to import: the module could not be loaded, so no fiber exists, with no stack to search — visibly different from a body throw. I produced both by accident while building the probes, and the distinction held.

One desktop-path note, not a plugin bug. On this machine dsh plugin --profile desktop add @argszero/dsh-activation-doctor is refused by design:

error: profile "desktop" is managed exclusively by the Electron application

The launcher rejects the desktop profile for every CLI command (lib/bin.js:36), so that profile can only be managed from inside the app. Desktop users therefore cannot follow the README's npm install … step; a line naming the in-app install path would save them the dead end. Also worth a sentence in the README: the report header records nodeVersion, platform and execPath, so people should skim before pasting a report into a public thread.

Thanks again — the sweep-then-file behaviour is the part the harness itself does not do, and it survives the two cases that matter: a body throw with a stack, and a module that never loaded.

[argszero]

Thank you for running it end to end — this is the first report of the doctor from a machine that is not mine, and the install gate you put in front of it (tarball sha512 against the registry, 12 files, no install scripts, no runtime dependencies, no network or child-process calls, the report as the only write) is more than the README asks anyone for. Two of your four arm results are confirmations I could only assert from source.

Your two README asks are in 0.1.1. Both were worth a line and neither was there:

• The install section now opens with the in-app path — the sidebar's Plugins page, Add plugin, the package name — and says why the terminal cannot serve Desktop users: dsh --profile desktop … and dsh plugin --profile desktop … are refused before they run (apps/cli/src/args.ts, rejectElectronProfile), so the profile can only be managed from where it is managed. The dsh plugin --profile <name> add … form is named separately, for the profiles a launcher owns.
• The report section now warns before the paste, and says which fields to read first: the header carries nodeVersion, platform and execPath, and the entries below it quote the failing plugin's own error text verbatim — whatever that plugin chose to say, which may be a path or a configuration value.

On the version you tested. You used 0.1.0 because npm's latest still said so, and I should have written the version I meant: 0.1.1 is published now. Worth being precise about what changed, though, because it is not the mount defect discussed above — the doctor's default export was { name, inject, apply } from 0.1.0, with the defaults in apply(ctx, config = {}), which is why your profile entry reached apply at all. What 0.1.1 adds is the regression test the ten sibling packages gained from that sweep: test/mount.spec.mjs mounts the default export rather than the module namespace — the object a profile entry actually reaches — and restoring a plain Config on that export reddens all three of its arms with exactly TypeError: Cannot read properties of undefined (reading 'validate'). The doctor had escaped by spelling, not by testing, and the sweep's rule is that a suite which mounts the namespace is not evidence about the object the loader mounts. Plus the two README sections above.

Arm 3 is right, and it is the loader's asynchrony. Your reading — the unload releases the effects, but not synchronously with the throw — is what the source says: a fiber's disposal is itself collected as an effect (ctx.registry.effect(async () => { … await this.inertia }, 'ctx.plugin()'), vendor/cordis/src/fiber.ts), so the disposers run on a later turn, not on the stack that threw. A registrant in the same include batch therefore still finds the name taken, and your 2.5 s probe is simply past the drain. I would keep that sentence — a collision cascading inside one startup batch is a real operational reading, and it is not something a detector can paper over: the second plugin fails for a reason that has nothing to do with the second plugin.

Arm 4 matches the design intent. A module that never loads has no fiber, so there is nothing to await and no stack to search; the doctor reports it as an import failure rather than guessing it into the body-throw category. That you produced both by accident while building the probes is the honest way to find out the two are visibly different.

Arm 2 is the arm I care most about — thank you for running the control. A detector that reports when there is nothing wrong is worse than no detector, and "one probe mounted, no warning line, no report file" is the assertion that keeps the rest trustworthy.

Your ① (a failure must reach disk) and ④ (a convention across plugins for tool-name collisions) still stand with the core team, and the doctor does not pretend to answer either: it does not revive the failed plugin, change the marketplace row, or move the desktop's stderr. What it changes is only that the state stops being unfilable. The marketplace row is the one you named and the one I cannot reach from a plugin.

[Hrainy1]

Follow-up: three more "the user cannot see it" failure classes, with on-machine evidence

Context: this is a Windows 11 desktop that (a) runs the desktop app, (b) had its <DSH_HOME> tree gutted at 03:17 local time today by something outside the harness, and (c) produced the DeepSeek Messages stream: tool input is invalid JSON failure twice in one session. We went after all three with administrator rights and raw artifacts. Paths are given as <USER> / <DSH_HOME>; no credentials, no file contents, no personal data.

1. Storage layer — an external cleaner removed the storage a live session was using, and the harness neither noticed nor reported it

• Recovery-bin audit: C:\$Recycle.Bin\* had 1,554 entries and E:\$RECYCLE.BIN\<SID>\ 229; none in the 03:17–03:19 window. The deletion bypassed the Recycle Bin ⇒ programmatic permanent delete.
• Locked-survivor signature: <DSH_HOME>\electron\ held a full Electron distribution extracted at 00:23:57 (electron.exe 225,441,792 B, dxcompiler.dll 25,616,384 B, …). Afterwards: 9 items left, every one of them a file that was open at the time. Everything unlocked was removed — a bulk cleaner, not an application uninstall.
• <DSH_HOME>\profiles\{dsh-tui,dsh-tui-safe,web} were re-created at 07:16 (creation times), i.e. they had been deleted; <DSH_HOME>\python-engine\ kept only .venv plus a models directory created 07:16:39.
• Consequence inside the harness: the session log of the session that was running at 03:17 is gone. We graphed the time coverage of all 242 session logs — not one covers 03:16–03:23. The harness kept running against a vanished store and surfaced it only as downstream ENOENT ("file not found") in individual tool calls; the marketplace showed nothing (loaded is name-matching only, as in the earlier comment).
• Who did it, as far as system evidence goes: a third-party cleaner, and its own residue database contains exactly the vanished paths — <...>\360Safe\sweeper\CleanSoft\*.dat (12 files written 04:02:56–04:03:10, plus lkFile.db at 04:02:57) decodes to 32 residual= records including <USER>\.dsh\electron\electron.exe, <USER>\.dsh\python-engine\.venv\Scripts\python.exe, <USER>\.dsh\dsh-runtimes\dsh-primary-runtime\dependencies\node\bin\node.exe, <USER>\.dsh\profiles\desktop\node_modules\@dsh-external\...\usr\bin\*.exe, <USER>\AppData\Local\Microsoft\WindowsApps, <USER>\.local\bin\bsk.exe, ...\node_modules\pnpm\pnpm.exe. Its clean cycle ran 04:01:25–04:03:31 (Clean\TFR532.tmp rules DB → sweeper DB writes → SDIS log) with SoftMgr\PurifySoft.exe executing at 04:02:58; a second deletion window ends before 04:10:42, when Windows re-created the shell known-folders it had lost. The cleaner's own %APPDATA%\SysCleanPro tree had to be re-extracted at 06:13:13–06:13:17, so it deleted its own user data too.
• Forensic ceiling (stated so it is clear this was not skipped): the C: USN journal retains only 08:30:50→15:48:55, Prefetch is disabled (EnablePrefetcher=0, SysMain stopped), there is a single shadow copy at 10:38:11, and the box rebooted at 09:06 — no process-level record of 03:17 survives anywhere on this machine.

What we would ask the harness to do (small and concrete): verify, at startup and periodically, that the directories it owns still exist (storages/, sessions/, profile node_modules/, the runtime dir) and emit one user-visible warning when one disappears — instead of leaking ENOENT into tool results; report fiber state rather than a name match; and write that integrity line into <DSH_HOME>/logs, where today the only writer at all is the third-party doctor plugin.

2. Agent loop — a tool call whose arguments are not valid JSON kills the whole turn

We located the exact code in the shipped @deepseek-ai/dsh-llm-deepseek/lib/index.js:

• :1889-1897 accumulates the streamed tool arguments by plain string concatenation (block.json += string(delta.partial_json)) — the harness never rewrites them, so it is not the mangler;
• :1969 copies that string into block.content.arguments;
• :1983-1992 at message_stop — unless reason.kind === "max-tokens" — runs JSON.parse(content.arguments) and on failure calls malformed("tool input is invalid JSON"), i.e. :1802 throw new LlmError("DeepSeek Messages stream: " + detail, "MALFORMED_RESPONSE").

Three occurrences, all on the same tool (compress, by far the largest tool input an agent emits here — 6,363 / 8,182 / 16,232 characters; the successful compress calls in the same session are 5,661 / 5,766):

• 07:27:28.457Z, turn 32 — Expected ',' or '}' after property value in JSON at position 4022; at that byte the model had written `"tools"` with unescaped ASCII quotes inside the JSON string, closing it early;
• 07:58:42.970Z, turn 35 — same error, position 4041; the model wrote 凌晨删除"名单里, again a raw " inside the string;
• 02:24:14.879Z, turn 1 of another session — {"content": m00006–m00029 …: prose where a JSON array was required, with 25 literal newlines.

So the provider is not at fault and the harness is honest — the model emitted invalid JSON — but the reaction is the problem: the turn dies with an error banner, there is no retry, the model gets no chance to fix its own malformed call, and the raw malformed arguments are not persisted to <DSH_HOME>/logs (we could only recover them by multi-frame zstd decoding of the session log). Note the asymmetry at :1983: the identical malformation caused by max_tokens truncation is deliberately not an error. A one-line change would let the non-truncated case degrade the same way — deliver it as an is_error tool result (the model then repairs itself) or retry once — instead of ending the turn.

3. Why this belongs in this thread

All three are the same complaint this discussion is about: the harness fails in ways the user can neither see nor act on. The doctor plugin is a good start — we installed it through the in-app installer and reproduced the name-collision failure live (phase: live, 1 of 206 entries, the losing fiber unloaded whole). What is still missing is the storage layer and the agent loop: neither says anything when it loses data or a turn.

(Private-data note: this comment contains no credentials, no file contents, and no personal paths beyond <USER> / <DSH_HOME>.)

---

中文摘要：本次追加的是三条“用户看不见”的失败类证据——① 外部清理器把正在运行会话的 <DSH_HOME> 存储整片抽走，harness 无检测、只在工具调用里冒 ENOENT，市场照旧显示已装；② 模型产生的非法 JSON 工具入参会让整轮直接失败（源码位置已定位，且 max_tokens 截断时反而豁免校验）；③ 两者都属于本帖讨论的“静默/粗暴失败”。所有机器路径已脱敏。