[Bug] One third-party plugin load failure aborts the entire app, with no self-repair path / 单个第三方插件加载失败导致整个应用无法启动，且无自修复路径

[Young-Spark]

说明：本帖文字由 AI 协助撰写润色，但下面的 bug 是我本人实际遇到的，期望行为也是我自己的需求；复现步骤与报错均来自真实环境。

Note: The wording of this post was drafted with AI assistance, but the bug below is one I actually hit, and the desired behavior is my own requirement; the reproduction steps and error output come from a real environment.

问题概述

profile 里装的第三方插件只要有一个加载失败，整个 dsh 就起不来——不是那个插件不能用，是整个应用直接 abort，界面都弹不出来。而且没有任何恢复入口。更尴尬的是，写 dsh 插件的人基本都拿 dsh 自己当主力 agent，dsh 挂了，连用它来修这个插件都做不到。

复现

1. 装一个按旧版 API 编译的 profile 插件（名字匿了）：
   dsh plugin --profile web add ./acme-dsh-browser-plugin
2. 升级 harness。预发布阶段 API 本来就一直在变，文档也写明不提供兼容承诺。
3. dsh web，起不来：

Error: dsh: plugin tree failed to load: failed to apply loader entry include (cordis:include): loader entries failed to apply
Error: failed to import loader entry browser-bridge (acme-dsh-browser-plugin):
  The requested module '@deepseek-ai/dsh-settings' does not provide an export named 'installSettingsSection'

插件挂在 ESM 链接阶段，代码一行都没跑到。装好的 bundle 又不会自动重编，之后每次启动都是同一个死法。目前只能手动去改 profile 的 package.json，把插件摘掉再重装。

影响

• 影响面太大。 一个可选的第三方插件能放倒整个产品。而且这不是偶发：按"不提供兼容承诺"的政策，每次 API 变动，所有没来得及更新的生态插件都会再挂一遍。
• 没法自修。 插件开发者修插件基本全靠 dsh 自己——读报错、查 API diff、改代码。启动挂了之后 agent 没了，等于把修它的工具也一起弄丢了。其实报错里该有的信息都有，就是没有会话能去用它。
• 顺带说一句，"默默跳过坏插件、只打行日志"这种做法我觉得不可取，跟仓库自己强调的 fail-loud 和「模型可见必须可记录」是冲突的。要隔离就该明着隔离，别悄悄降级。

期望的行为

一句话：第三方插件加载失败，不该拦住我进 dsh；进去之后我要能在 dsh 里直接看到哪些插件失败了、失败的原因是什么，并且能顺手把报错交给 agent 去修。

1. 第一方 @deepseek-ai/* 的包挂了照旧中止启动。这个没意见，核心的东西坏了本来就该起不来。
2. 第三方 profile 插件加载失败时只处理它自己：摘掉这一个 entry，其余照常启动，应用可用。
3. 失败要留下痕迹：启动时有明显的警告，说清哪些插件被摘了；错误详情（entry、包名、报错）落盘保存，重启也还在，直到用户主动处理。
4. 在应用内可见：打开 dsh（GUI 或插件管理面板）就能看到失败插件的列表和各自的原因，不用去翻终端里的历史输出；agent 也要被明确告知哪些插件被禁了、为什么，别让模型去调手里根本没有的工具，并且最好能一键把完整报错丢给 agent，让它自己看、自己修。
5. 给个恢复入口：修好或者重装之后，能用命令查看和清除隔离状态（比如 dsh plugin --profile <name> quarantine [--clear <row>]），下次启动自动重试。
6. （可选）安装时就做兼容性预检，坏插件根本走不到启动那步。

环境

• dsh 0.1.2-alpha.3（源码 checkout）、Windows 11、Node 22.19

---

Summary

A single third-party plugin installed into a profile can make the whole dsh application unbootable. There is no isolation, no surfaced recovery path, and — for plugin developers whose only agent is dsh — no way to use dsh itself to diagnose and fix the very plugin that bricked it.

Reproduction

1. Install a profile plugin built against an older harness API (names anonymized):
   dsh plugin --profile web add ./acme-dsh-browser-plugin
2. Update the harness. Pre-release API churn is normal and documented: no compatibility promises, old formats are rejected.
3. Launch dsh web.

Actual result — the entire application aborts before any UI comes up:

Error: dsh: plugin tree failed to load: failed to apply loader entry include (cordis:include): loader entries failed to apply
Error: failed to import loader entry browser-bridge (acme-dsh-browser-plugin):
  The requested module '@deepseek-ai/dsh-settings' does not provide an export named 'installSettingsSection'

The plugin fails at ESM link time, before any of its code runs. Because installed bundles are not rebuilt in place, every subsequent launch aborts the same way. The only workaround is to hand-edit the profile's package.json / bundle list and reinstall.

Why this hurts

• Blast radius. One optional, third-party extension takes down the whole product. The failure class is routine by policy — every documented API drift in the pre-release window re-bricks every not-yet-updated ecosystem plugin.
• Bootstrap paradox. dsh's audience includes dsh plugin developers. For a developer whose only agent is dsh, a boot aborted by a stale plugin removes the tool needed to diagnose and repair that plugin. The aggregated error already contains everything the agent would need — but there is no session, because the app never boots.
• Silent skipping is not the answer. Dropping failed plugins with only a log line would violate the project's own fail-loud and "model-visible ⟺ logged" invariants. The goal is loud isolation, not quiet degradation.

Desired behavior

In one sentence: a failed third-party plugin must not keep me out of dsh — once inside, I should see which plugins failed and why right in the application, and be able to hand the error straight to the agent to fix.

1. Product-spine failures (first-party @deepseek-ai/* plugins) keep aborting the boot exactly as today.
2. A third-party profile plugin that fails to load is isolated: the rest of the tree boots and the application is usable.
3. The isolation is loud and durable: a startup warning naming the failed plugins; the failure kept on disk with a structured diagnostic (entry, package, error); the state survives restarts until the user acts.
4. Visible in-app: opening dsh (GUI / plugin panel) shows the list of failed plugins with their individual reasons — no digging through old terminal output. The agent is also told which plugins are disabled and why, so it never offers tools that aren't there, and ideally one click hands the full diagnostic to the agent to diagnose and repair.
5. Explicit recovery: a way to inspect and clear isolated entries (e.g. dsh plugin --profile <name> quarantine [--clear <row>]), so that after updating or reinstalling the plugin, the next launch retries it.
6. Nice to have: run the same compatibility check at install time, before a broken plugin ever reaches a boot.

Environment

• dsh 0.1.2-alpha.3 (source checkout), Windows 11, Node 22.19

[airlian]

放一個 pi 在旁邊比較快。

[Young-Spark]

我差不多也这样，不过还是让别的agent给我修了dsh，我自己用本地编译的版本，不过dsh不开放pr

[liguobao]

应该有个doctor 之类的命令，能把这个事情Cover住。不过我自己打包的 dsh-desktop 是支持了修复的，毕竟这玩意还是个桌面程序。