No built-in way to tell whether a plugin loaded and activated

[Dogwind221]

Problem

After adding a plugin to a profile patch, there is no built-in way to answer the most basic question: did it actually load?

I've assumed "it didn't work" three times when the real cause was something else — a stale module, a bad path, or the wrong profile. Each time, finding out took a restart cycle or a look at host logs.

What I built to work around it

The plugin appends a line to a local file whenever it activates, so any script can confirm it:

2026-10-23T07:03:32.108Z apply() basePath=/live-workbench
2026-10-23T07:03:32.141Z activated basePath=/live-workbench

That's a plugin-side workaround every author has to invent separately. On the consumer side (someone who just installed a plugin from the market), there's nothing comparable.

What I'd find useful

1. A startup line listing the plugin entries the loader actually mounted, e.g.
   loaded 12 plugins, 1 failed (id: live-workbench, error: cannot resolve package)
2. A status command (or a Settings → Plugins list) showing per entry: id, resolved package name, file path, load result, and the routes/slots it registered
3. Fail loudly when a patch entry points at a package that can't be resolved, instead of continuing silently

Why it matters for DX

"My plugin doesn't work" is the most common question in any plugin ecosystem, and right now the answer is usually invisible unless the author already added their own logging. A minimal activation report would turn a debugging session into a single glance.

Environment

• DSH desktop, two profiles (desktop, web) with local file:// plugins
• The plugin itself works; this is purely about observability

[xiaoshenming]

同意这个需求，并且补一个你那张清单里没有的第三种状态 —— 我今天刚在自己的插件上踩到。

「加载失败」不等于「没加载」

dsh-session-surgeon 装在桌面端 profile 里、在插件列表里、路径也对，但从来没有 apply() 过。原因不是解析失败，也不是 apply() 抛错，而是桌面端在加载之前就做了静态判定：

dsh-session-surgeon@0.2.6 与 DSH 0.2.1-rc.2 不兼容
（要求 @deepseek-ai/dsh-tools >=0.1.0-rc.6 <0.2.0）

它读的是 package.json 的 peerDependencies，跟当前 harness 的 dsh-tools 版本比了一遍，越界就拒绝加载。于是：

• 模块能解析（cannot resolve package 那类报错不会出现）；
• apply() 不会执行（你在 apply() 里写日志那招在这里一行都不会出现）；
• 宿主侧也没有 error，因为它压根没进到 import 那一步。

用户能看到的只有一条提示，而那条提示恰恰是另一个插件（管理器自己）弹出来的。也就是说：插件越是有问题，越不可能自己报告问题。

所以清单要这么列

1. 启动行分三档，而不是两档：loaded 12, failed 1 (id, cannot resolve package), refused 1 (id, peer @deepseek-ai/dsh-tools needs >=0.1.0-rc.6 <0.2.0, harness has 0.2.1-rc.2)；
2. 设置 → 插件里每个条目显示判定依据：解析到的包名、版本、命中的规则（peer 范围 / client 模块缺失 / 路径不存在），而不只是「未加载」；
3. 「被拒绝」要黏住（条目上常驻一个角标），不能是过一会儿消失的 toast —— 我这个案例里，用户是隔了三天才发现插件一直没跑。

给插件作者的一条反向经验

同一件事的另一半在我这边：那个上限是猜的，不是量出来的。我们从这个包里只 import 一个 defineTool，0.2.1-rc.2 里它还在，而且拿不到时本来就是「跳过注册、不崩」。写个上限什么也没保护到，只保护到了「所有更新的 harness 一律装不上」。已经改成 >=0.1.0-rc.6 并在测试里钉住「peer 范围不许出现 <」—— 用测试盯住声明，比用注释提醒自己靠谱。

如果这个帖最后变成一个提案，第 1 条的三档计数是最小可用版本：它不需要宿主暴露新 API，只需要在现有加载流程的每个早退点上报一次。

[Dogwind221]

This is the missing third state, and the framing "failed" vs "refused" is the part I got wrong — I assumed everything that does not show up in apply() is either a resolution failure or an exception.

Worse: my own plugin had the same trap waiting for it. After reading this I checked my package.json:

"peerDependencies": {
  "@deepseek-ai/cordis": ">=4.0.0-rc <5",
  "@deepseek-ai/dsh-client-ui-slots": ">=0.0.1-rc <2"
}

Both upper bounds are guesses, exactly like the one you describe. If the harness ever ships cordis@5 or ui-slots@2, my plugin gets refused before load — and since refusal never reaches apply(), the activation breadcrumb I added for issue #10776 writes nothing. So the observability feature I asked for would have reported "nothing happened" for a plugin that was silently refused. Your reverse lesson is the sharper half of this thread.

What I changed in response (already pushed to Dogwind221/img2img-studio):

• Dropped both upper bounds (>=4.0.0-rc, >=0.0.1-rc), matching your reasoning: I only use one symbol from each, and a missing symbol already fails inside apply() where it is visible.
• Added a check that fails if a peer range contains <, and wired it into the publish workflow — same idea as yours: pin the declaration with a test instead of a comment.

On the proposal, I agree the three-bucket startup line is the minimum viable version, and I like that it needs no new host API — one report at each early exit. Two additions from my side:

1. The refusal reason should carry the compared values, not just the range: refused 1 (id, peer @deepseek-ai/dsh-tools needs >=0.1.0-rc.6, harness has 0.2.1-rc.2). The "harness has X" part is what turns it into a bug report the user can act on.
2. The persistent badge matters more than the startup line for the case you hit: a startup line scrolls away, and three days later the user has no trace. A badge on the plugin entry (plus the same reason text) survives sessions.

Happy to help write this up as a concrete proposal if it heads that way — the three exit points (resolve failure / refusal / activation failure) map cleanly onto what the loader already knows.

Context for whoever else reads this: dsh-img2img-config@0.1.0 is now on npm, and I am fixing the same class of bug in it — so this is not hypothetical for plugin authors.