[Bug Report] dsh plugin remove 失败后残留 dsh.profile.bundles 条目，profile 永久无法启动且官方提示的修复命令无效

[DRAG0NM]

摘要

dsh plugin remove 在 pnpm 非零退出（如 git-hosted 源瞬时网络错误）时，manifest 已被写入"依赖已删"状态，但 reconcile 因 exitCode === 0 门控被跳过，dsh.profile.bundles 残留条目；此后该条目 wasDependency 恒为 false，删除分支永不触发，install/ls 均无法修复，profile 永久无法启动，只能手改 package.json。原帖假设经 rc.6 源码逐条证实，另发现启动错误信息中建议的 install 修复路径实际无效。

复现步骤

1. 全新 profile：dsh plugin --profile X add github:owner/repo，bundle 注册并可用。
2. dsh plugin --profile X remove <bundle>，且在 pnpm 执行中出现瞬时错误（如 git-hosted 操作的 ETIMEDOUT，本机实测 4/4 对照重跑通过，属非确定性触发）。
3. pnpm 已将 bundle 从 dependencies 移除（manifest 已写入），但以非零码退出。
4. 启动 profile：报 cannot resolve profile bundle "<bundle>"，无法 boot。
5. dsh plugin --profile X install、dsh plugin --profile X ls 均不清理残留条目（已实测验证）。
6. 手改 package.json 删除 dsh.profile.bundles 中残留条目后 profile 恢复。

根因（源码定位，rc.6）

1. reconcile 被 pnpm exit code 门控 — @deepseek-ai/dsh/lib/plugin-9h8shc4d.js：

   • L107：pnpm 运行前读取 before manifest 快照；
   • L121：if (exitCode === 0) reconcilePlugins(before, dir); —— pnpm 非零退出时 reconcile 整体跳过。而 pnpm remove 会先写 manifest 再执行网络/清理操作，失败时 manifest 已处于"依赖已删"状态 → dsh.profile.bundles 残留。

2. 残留条目一旦形成便永久存在 — 同文件 reconcilePlugins：

   • L48-49：beforeDeps（运行前）与 dependencies（运行后）两个集合；
   • L61-67 删除分支：wasDependency = beforeDeps.has(packageName) || dependencySet.has(packageName)，仅 wasDependency && !stillBundle 才 splice；
   • 残留条目在后续任何调用中（install/ls 走同一函数）均不在两个集合内 → wasDependency = false → 删除分支永不触发，条目被当作 in-box/用户自有条目永久保留。原帖对 wasDependency 的分析与 L62 完全一致。

3. 启动错误信息给出的修复路径无效（增量发现） — @deepseek-ai/dsh-app-boot/lib/index.js：

   • L518-524 resolveBundleDir 抛错文案：...run 'dsh plugin --profile X install' if its dependency is not installed；
   • 但 install 成功后走的是同一个 reconcilePlugins，同样的 wasDependency 判定，同样无法移除残留条目 —— 用户按提示操作必然失败。

4. 首次 add 偶发缺行是同族问题 — 原帖观察"全新 profile 首次 add 不填充 bundles 行"：add 的 pnpm 非零退出 → reconcile 跳过 → 拼接分支（L52-56）未执行，第二次 add 成功才补上。

建议修复

方案 A（推荐）· reconcile 脱离 exit code 门控 + 残留条目独立判定：

• L121 改为无论 pnpm 成败都调用 reconcile（manifest 可能已被写入，reconcile 本身幂等）；
• 删除分支不再依赖 beforeDeps：条目既不在 dependencies 中、又不在模板 bundle 集合（该文件已 import PROFILE_TEMPLATES/DEFAULT_PROFILE_BUNDLES，可区分 in-box 模板条目）时，直接移除或告警。
• 同步修正 dsh-app-boot L523 的错误提示文案（install 无法修复该场景）。

方案 B · manifest 写入原子化：pnpm 成功提交后才更新 manifest，失败回滚。pnpm 自行写 manifest，dsh 难以原子控制，工程量大、收益低。

方案 C · 启动期自愈：boot 时对无法解析的 bundles 条目降级为告警并自动清理（保留 --dump-default-config 等只读路径不受影响）。可兜底历史遗留坏 profile，但与 A 配合最佳。

影响

• profile 一旦触发即永久不可启动，且官方错误提示给出的修复命令无效，用户只能手改 manifest —— 对 dsh plugin 新用户是极差的首次体验（原帖）。
• 任意 bundle 类型都可能触发（git-hosted 实测触发；link: 安装的 bundle 因无网络操作而正常移除）。
• 与 Bug: dsh plugin add with a github: spec links the dependency but does not append it to dsh.profile.bundles #656（add 不追加 bundles）、[Bug Report] `dsh plugin add` 对 git 源安装失败的诊断不分类：仓库不存在时误报 allowBuilds 提示，且提示引用的"pnpm 打印的 key"根本不存在 #874（install 失败诊断分类）同属 plugin 管理一致性缺陷族，但根因不同。

环境

• 源码定位：0.1.0-rc.6（npx 缓存安装包，Node v24.16.0，Windows 11）
• 原报告：Bug: dsh plugin remove can leave a stale dsh.profile.bundles entry that permanently breaks the profile #913（Windows 11, Node 24, pnpm 11.21.0，npm 全局安装）

验证材料

• 原帖实测序列（步骤 2-6）+ 4/4 对照重跑（非确定性确认）；
• rc.6 源码逐条核对：plugin-9h8shc4d.js L107/L121/L46-78 与 dsh-app-boot/lib/index.js L518-524；
• 代码路径推演：install/ls 与 remove 共用 runPlugin → 同一 reconcilePlugins → 同一 wasDependency 判定，故无法自愈。

---

First analysis of discussion #913. Happy to open a PR with fix option A.

[ICCuse]

评论 A 草稿 → #917（触发面：插件产物缺失 → profile 无法启动）

补充一个同类的触发模式 + 一条与你们不同的恢复路径，供团队排期参考。

新触发模式：插件入口产物缺失/不完整（不依赖 dsh plugin remove）

只要 profile 引用的插件包存在、但入口产物（lib/index.js）缺失或不完整——部分安装、更新被中断、包损坏、本地构建被打断都算——boot 同样硬失败，且报错没有任何恢复指引。干净复现（临时把某插件的 lib/index.js 改走，dsh --profile web --port 3099）：

dsh: plugin tree failed to load: failed to apply loader entry include (cordis:include):
failed to import loader entry file-memory (@deepseek-ai/dsh-file-memory):
Cannot find module '...\profiles\node_modules\@deepseek-ai\dsh-file-memory\lib\index.js'
imported from ...\profiles\web\

两点观察

1. 终端诊断其实够好（点名插件 + 具体缺失文件），但没有任何"怎么恢复"的提示，且 Web UI 侧完全无感知（见 [Bug Report] Web UI 在后端进程退出后无任何可见提醒（ConnectionBanner 组件存在但从未挂载） #916 的补充评论）。
2. 恢复路径比 [Bug Report] `dsh plugin remove` 失败后残留 `dsh.profile.bundles` 条目，profile 永久无法启动且官方提示的修复命令无效 #917 的"只能手改 manifest"更简单：恢复/重建缺失产物（重装该插件或重新构建）即可恢复，不需要改 manifest。如果 loader 能对单个失败行降级而不是整机失败，普通用户就不会被困住。

建议

• 失败行隔离 + 红卡提示原因（broken preset 已有同样的降级先例），而不是整棵 plugin tree 失败；
• 或至少：报错中给出恢复命令提示（如 dsh plugin install <name> / 重装该包）。

事件背景（真实事故）：本地构建被打断 → 两个插件产物缺 lib/index.js → 服务起不来 → UI 显示空白新会话 → 用户一度以为全部对话丢失（数据实际完好，JSONL 持久化）。

社区止损工具（预检+恢复指引+数据安全说明，零依赖）：https://github.com/ICCuse/dsh-web-safe
给团队的核心修复草图：https://github.com/ICCuse/dsh-web-safe/blob/main/docs/core-fix-sketch.md

[DRAG0NM]

感谢 @ICCuse 补充"插件入口产物缺失/不完整"这一不依赖 remove 命令的触发模式，以及不同的恢复路径。它把问题的边界从"remove 的 exit-code 门控"扩展到"profile 引用的插件包半损坏"——与我们定位的 reconcile 跳过是同族不同触发的两面，对排期很有参考价值。