[Bug][Desktop rc.1 → rc.2] 官方 CUA 旧依赖残留禁用 storage-domain，导致工作区/历史全空

[ygttygtt]

Summary

After upgrading the official macOS Desktop from 0.2.2-rc.1 to 0.2.2-rc.2, an existing profile-local installation of the official CUA bundle retained rc.1 dependencies. The old profile-local dsh-storage-domain was selected and disabled by compatibility preflight, leaving workspace/session services unavailable. Updating the profile-local CUA dependency to rc.2 and restarting restored the workspace/history UI before changing any third-party plugin versions.

Related: #8166 describes the same old-transitive-dependency/core-storage failure mechanism on an earlier release. This report adds a current case where the old dependency comes from the official CUA bundle.

环境与症状

• 官方 DeepSeek Harness Desktop：0.2.2-rc.1 → 0.2.2-rc.2，macOS 27.2.1 / arm64，desktop profile。
• 2026-11-06 曾通过插件安装器安装官方 @deepseek-ai/dsh-cua-bundle@0.2.2-rc.1。
• 2026-11-12 桌面升级后，工作区/历史列表显示为空，重新选择文件夹失败：

  workspace create failed: gateway/service-unavailable:
  typert gateway: workspace/create: active Service "workspaceController" is unavailable
  

• 同时，已安装的非官方社区插件 @michengai/dsh-archive-manager 更新和回退均在 enable 阶段失败；pnpm 下载/安装本身完成。
• 磁盘上原有 63 份会话日志仍存在（约 74 MB），此处是历史不可见，未观察到日志被删除。

本机取证

升级后、修复前，profile 的直接依赖仍含：

{ "@deepseek-ai/dsh-cua-bundle": "0.2.2-rc.1" }

锁文件显示以下依赖链：

dsh-cua-bundle@0.2.2-rc.1
  → dsh-cua@0.2.2-rc.1
    → dsh-storage-domain@0.2.2-rc.1

通过自带 Inspector 只读检查运行时，确认：

• storage-domain 实际解析到 ~/.dsh/profiles/desktop/node_modules/@deepseek-ai/dsh-storage-domain/package.json，该文件版本为 rc.1。
• 该包的 peer 要求 @deepseek-ai/dsh-storage: 0.2.2-rc.1；与当前 rc.2 运行时不匹配。
• Loader 中 storage-domain 行的有效配置为 disabled: true，无对应 fiber。
• workspace、session-projection-cache、schedule 等等待 storageDomain；workspace-controller / session-controller / archive-manager 等继续等待 workspaceRegistry。
• 运行时日志包含：

  workspace (@deepseek-ai/dsh-workspace): pending (waiting for service: storageDomain)
  workspace-controller (@deepseek-ai/dsh-api-workspace-controller): pending (waiting for service: workspaceRegistry)
  

为什么用户难以通过普通更新操作解决

对本机 rc.2 随包代码的检查发现：

1. 应用内已经包含 rc.2 的 CUA bundle 和存储组件；但用户 profile 内仍保留以前安装的 rc.1 副本。
2. DesktopProjectManager.applyRelease() 不运行依赖安装；initProfile() 保留已有 manifest；removeLinkProjections() 不删除 pnpm 安装的包。因此这条路径不会同步更新上述旧安装。
3. 插件清单通过安装包优先的 resolveBundleDir() 获取官方 bundle 元数据，并将随应用提供的 CUA 归类为 installation。updateRefusal() 又将 official / 非 profile 插件排除在普通 listVersions / updateBundle 更新入口之外。
4. 因此出现不一致：bundle 元数据/官方更新归属在应用侧，底层模块实际解析却仍可命中用户目录中的旧依赖。

相关公开源码：

• 桌面 profile 准备流程
• 插件清单与更新资格
• profile 初始化、bundle 解析及依赖解析

已验证的恢复

1. 完全退出桌面。
2. 使用应用自带的 CLI/pnpm，将 profile 里的官方 CUA bundle 精确更新到 0.2.2-rc.2，同步更新其传递依赖。
3. 重启后，storageDomain、workspaceRegistry、workspaceController、sessionController 全部恢复，原有 5 个工作区与历史列表重新显示，实际打开旧会话正文成功；重新选择现有工作区文件夹不再报错。
4. 上述恢复发生时，第三方归档插件仍为原来的 1.2.8，标题插件版本与本地定制也未改变。
5. 随后在插件页重试归档插件 1.2.8 → 1.3.2，enable 成功，操作日志为 application: applied。

未清空/重建 profile、未迁移会话日志、未授予版本兼容豁免。

影响范围与建议

这是单台现有用户环境的完整取证与恢复记录，尚未在干净环境独立复现，也不声称所有安装过 CUA 的用户都会遇到。请重点核查“旧 profile-local 官方 CUA 安装仍存在，桌面升级至 rc.2”这一升级路径；第三方插件仍在该环境中，尚未通过干净环境实验排除全部交互影响。

建议官方处理：

• 桌面升级时识别并迁移/协调已安装官方 bundle 的旧 profile 副本及依赖，避免管理归属和实际解析版本不一致。
• 核心存储组件避免被插件目录内的旧传递依赖覆盖。
• 核心服务因兼容问题不可用时，提供明确诊断和恢复入口，避免界面仅显示“暂无会话”而让用户误以为历史丢失。