[Bug] 升级后可选插件遮蔽核心包，导致 workspace/session 服务全部不可用，界面表现为"会话全部丢失"（数据实际完好）

[workerwannafree]

一、环境

• DSH Desktop 0.2.2-rc.3
• macOS arm64
• 升级方式：通过应用内更新提示，手动点击升级
• 升级前：0.2.2-rc.1，一切正常
• 升级后首次启动即复现，无需任何额外操作

二、现象

1. 启动后左侧没有任何 workspace，主区域显示"暂无会话"，看起来像历史全部清空。
2. 点击"添加文件夹"弹窗报错：
   workspace create failed: gateway/service-unavailable:
   typert gateway: workspace/create:
   active Service "workspaceController" is unavailable
3. 检查磁盘：sessions/ 下所有 session.v4.jsonl.zstd 均完好、可正常解压，
   storages/workspace.json 也完好。数据从未丢失。

三、复现步骤

1. 旧版本下通过插件页安装某个可选插件 bundle，其依赖树里带有
   @deepseek-ai/dsh-storage-domain@<旧版本>。
   pnpm 会把它提升到 profile 的：
   profiles//node_modules/@deepseek-ai/
2. 通过应用内更新提示手动升级到新版本。
3. 启动即复现，无需额外操作。

四、启动日志（关键部分）
dsh: disabling profile plugin row "storage-domain":
Plugin @deepseek-ai/dsh-storage-domain@0.2.2-rc.1 is incompatible
with dsh 0.2.2-rc.3: requirements {"@deepseek-ai/dsh-storage":"0.2.2-rc.1"}.
Running it may cause crashes or data loss.

dsh: warning: 6 entries did not activate
session-projection-cache: pending (waiting for service: storageDomain)
workspace: pending (waiting for service: storageDomain)
session-controller: pending (waiting for service: workspaceRegistry)
schedule: pending (waiting for service: storageDomain)
workspace-controller: pending (waiting for service: workspaceRegistry)
ui-deliverables: pending (waiting for service: sessionController)

注：应用从 Finder 启动，以上 stderr 用户完全看不到，只有把 profile 改名
用 CLI 引导才能复现出来。

五、根因分析

1. 可选插件的依赖树把核心包 @deepseek-ai/dsh-storage-domain 带进了 profile，
   并被 pnpm 提升到 profile 顶层 node_modules。
2. 插件按包名解析时会优先命中 profile 内的副本，于是 base bundle 里名为
   @deepseek-ai/dsh-storage-domain 的那一行实际加载的是旧版本。
3. 启动兼容性预检判定该行与当前运行时版本不兼容，将其禁用（disabled）。
4. dsh-workspace 的 static inject 是 ["storageDomain","sessionPersistence"]，
   storageDomain 缺失 → workspace 永久 pending。
5. workspaceRegistry 缺失 → workspace-controller / session-controller 永久 pending。
6. 最终 UI 上 workspace 列表为空、会话列表为空、workspace/create 报
   service-unavailable。用户看到的现象与"数据丢失"无法区分。

六、期望修复

1. 解析隔离：核心包（@deepseek-ai/dsh-*）应优先使用 App 自带版本，
   或禁止 bundle 将核心包作为普通依赖装入 profile；
   至少应在安装时拒绝把核心包 hoist 到 profile 顶层。
2. 升级前置校验：升级完成、重启之前，校验 profile 内插件与目标版本是否兼容；
   不兼容时明确提示并提供"以安全模式启动（停用插件）"选项，
   而不是升级完直接进入不可用状态。
3. 失败隔离与降级：单个插件被禁用不应导致核心服务级联 pending。
   建议 core 服务在依赖缺失时报明确错误，
   UI 提示"插件 X 不兼容"，而不是显示"暂无会话"。
4. 至少把 CI 里加一条回归：已安装插件的旧 profile + 新版本启动，
   断言 0 pending、会话列表可用。

七、影响评估

• 用户完全无法使用（无法新建/打开任何会话）。
• 界面表现与"数据丢失"无法区分，会造成严重信任损失与实际恐慌。
• 用户无法自救：报错是 service-unavailable，
  没有任何指向"插件版本"的信息；应用内也没有安全模式入口。
• 本次事故中用户尝试过移动 sessions 目录、移动 workspace.json、
  安装第三方恢复工具，均无效且增加了误操作风险。

八、临时绕过（已验证）
删除 profile 内被 hoist 的旧核心包，使其回落到 App 自带版本，即可恢复：
rm -rf profiles//node_modules/@deepseek-ai/dsh-storage-domain
删除后重新引导：0 条目被禁用、0 pending，全部会话与 workspace 正常加载。
若要长期避免，需同时把 profile 里依赖该核心包的 bundle 升级到与 App 相同版本，
或直接卸载该可选插件。

[dongsheng123132]

同症状，macOS / Desktop 0.2.2-rc.3（rc.2 → rc.3），补充几点实测结论，尤其是「临时绕过」那段：

1. 只移走 dsh-storage-domain 一个包会留下半死状态。 我照这个思路只隔离该包后，左侧工作区列表确实回来了，但点「新建会话」仍报 active Service "sessionController" is unavailable。host 日志里还剩下 7 行 0.2.2-rc.2 的官方包被判 incompatible with dsh 0.2.2-rc.3 并 did not activate，session-controller 继续卡在 waiting for service: workspaceRegistry。把 8 个 rc.2 官方包（dsh-cua-bundle、dsh-storage-domain、dsh-typert-protocol、dsh-computer-use、dsh-cua、dsh-brand、dsh-atomic-write、dsh-experimental-cua-macos）整体隔离、并把 package.json 里三个显式 @deepseek-ai/* 依赖对齐到 rc.3 之后，才恢复成 0 disabled / 0 pending。所以建议把「删除单个核心包」改成「按版本线整体对齐 / 整体隔离」。

2. 建议把 rm -rf 换成 mv 到备份目录。 这次全程没有删任何数据文件，workspace.json 自始至终未改动，回滚只要把目录移回去。帖子里的做法对用户来说不可回滚，而界面表现又和「数据全丢」无法区分，一旦误判很容易继续误操作。

3. 还有一层独立的坑，容易让人以为没修好： Electron 的 dsh.workspace.view.v5 旧快照含 null 字段会让侧栏组件整块崩溃（见 #7637 / #6942 / #7256）。我把前端状态目录封存重建后，「工作区」标题、搜索/排序按钮都回来了，但列表仍然是空的——那其实是依赖层还没修。两层叠加时特别难定位。

4. 验证清单里建议加一条「亲手点一次新建会话」。 只看列表回来会漏掉上面那个半死状态；另外重启后 workspace.json 的 mtime 被正常写入，也能佐证 storageDomain + workspaceRegistry 真的挂上了。

完整可回滚步骤（含只读体检命令、备份、验证、回滚）我整理在 #13389，可以直接照做。