[Bug] 0.2.0 peer gate 静默禁用基础层 storage 行(profile 传递依赖劫持包解析)→ 工作区/会话列表全空

[Chenfyy-mac]

环境

• DSH Desktop 0.2.0-rc.1(从 0.1.7-rc.1/rc.2 自动更新),macOS arm64
• desktop profile,装有若干三方插件(本例涉及 dsh-output-styles@0.6.16、@michengai/dsh-archive-manager@1.0.5、dsh-jev-tools@0.1.8、dsh-mcp-connector@0.2.59)

症状(用户视角 = "更新后数据全丢了")

更新到 0.2.0-rc.1 后启动应用:

• 侧边栏「工作区」分组几乎全空,会话树显示「暂无会话」
• 点「选择工作区」永远停留在「正在加载工作区…」,下拉菜单里一个已有工作区都没有(只有"添加工作区…")
• 全部历史会话不可见——磁盘上 184 个会话文件完好无损,纯粹是读不出来

渲染器 console 里唯一的线索(启动后出现一次,之后 UI 静默空白):

RemoteError: typert gateway: session/control: active Service "sessionController" is unavailable

根因链(已完整取证)

1. profile 的 node_modules(hoisted 布局)里存在 @deepseek-ai/dsh-storage-json@0.1.5-rc.2 与 @deepseek-ai/dsh-storage-domain@0.1.5-rc.2。它们是三方插件的传递依赖(pnpm why 指向 dsh-output-styles@0.6.16,该插件至今声明依赖 0.1.5-rc.2),profile 自己的 dependencies 里并没有这三个包。
2. 0.2.0 组合里 dsh-base 层的 storage-json / storage-domain 行按 Node 解析规则从 profile 树取包,拿到的是旧副本,而不是内核自带的新版副本。
3. 0.2.0 新增的 peer 版本闸门判定不兼容,自动禁用这两行(离线跑内核 CLI 才能看到):

dsh: disabling profile plugin row "storage-json": Plugin @deepseek-ai/dsh-storage-json@0.1.5-rc.2 is incompatible with dsh 0.2.0-rc.1: peerDependencies {"@deepseek-ai/dsh-storage":"^0.1.5-rc.2"}. Running it may cause crashes or data loss. ... grant the exact-version exemption ... Exact-version exemption: not active.
dsh: disabling profile plugin row "storage-domain": Plugin @deepseek-ai/dsh-storage-domain@0.1.5-rc.2 is incompatible with dsh 0.2.0-rc.1: ...

4. storage-domain 是 workspace 注册表的存储层(ctx.storage.domain)。这两行被禁后,workspaceRegistry / sessionController 等服务群全部无法激活 → 工作区列表与会话列表全空。

最小组合即可复现:把 profile 的 bundles 削到只剩 @deepseek-ai/dsh-base + @deepseek-ai/dsh-web-app,症状不变——与三方插件行无关,只要传递依赖把旧版 infra 包带进了 profile 树就会触发。

为什么用户几乎无法自查

• disabling 提示只写到宿主进程 stderr,桌面 App 不把它落盘(userData 里没有日志目录),GUI 里零报错。
• 桌面 App 的用户第一反应是"我的会话/工作区没了",而不是"有个插件被禁了"。
• 目前唯一能看到提示的途径是解包 asar 用内核 CLI 离线跑组合(CLI 对 desktop profile 名有硬编码拒绝,需要先复制为别名):

npx asar extract "/Applications/DeepSeek Harness.app/Contents/Resources/app.asar" /tmp/x
cp -R ~/.dsh-official/profiles/desktop ~/.dsh-official/profiles/diag
node /tmp/x/dsh/node_modules/@deepseek-ai/dsh/lib/bin.js --profile diag --dump-config

我们当前的 workaround(已验证有效)

在 profile 里把三件套显式钉到当前内核版本(直接依赖在 hoisted 布局下赢得顶层槽位,组合行随之解析到新版):

cd ~/.dsh-official/profiles/desktop
pnpm add @deepseek-ai/dsh-storage@0.2.0-rc.1 \
         @deepseek-ai/dsh-storage-json@0.2.0-rc.1 \
         @deepseek-ai/dsh-storage-domain@0.2.0-rc.1

重启后 8 个工作区 + 全部历史会话回归,渲染器零错误、零 disabling。

但这是"带病防守":下次内核大版本(如 0.3.0)时,这枚钉子自己会变成闸门的违规者,同样的全空症状会复发,需要再钉一次。

建议的修复方向(任一都能大幅降低伤害)

1. 基础层行从内核解析:dsh-base 组合的基础设施行(storage 系列)不应从 profile 的 node_modules 取包——三方插件的传递依赖不应该有能力劫持内核基础设施的版本。
2. 更新器自动迁移:内核更新时,插件管理器自动升级 profile 树里的官方 infra 传递依赖(或至少在 GUI 提示 + 一键修复)。
3. 闸门可见、可恢复:被 peer 闸门禁用的行应在桌面 GUI 有可见呈现(横幅/诊断页),而不是只写 stderr;禁用基础层行时提供"回退内核自带副本"的恢复路径。
4. 对 schema 稳定的 infra 包降级闸门:storage 三件套的数据格式(workspace.json v2)在 0.1.7 → 0.2.0 间并未变化,这类包的 peer 不匹配可以降级为警告而不禁用,避免"数据其实完好但整个 UI 变空"的极端体验。

感谢这个闸门本身的立意(防崩溃/防数据损坏)——问题只在它与 profile 传递依赖的解析规则叠加后产生了"静默全空"的组合效应。