[Bug]+小优化点请求：插件热重载后所有历史会话从侧边栏消失，无任何提示+优化 Windows 托盘缺重启入口

[alexzeng666]

环境：DSH Desktop 0.2.1-rc.2（nightly / win-x64，Electron 44.7.0），Windows 10/11 x64

---

一、Bug：插件热重载后，所有非内存会话从侧边栏消失（数据完好、静默失败）

摘要

在插件页关闭任意插件再重新打开（触发 profile 热重载）后，侧边栏只剩当前处于内存中的会话；所有对话已结束、不在内存里的会话全部从列表消失，搜索框按标题搜、按内容搜都返回空。重启应用后全部恢复。磁盘数据全程完好，无任何报错或日志。

复现步骤

1. 新建若干个会话并正常结束对话，使其不在内存中（cold）
2. 保留至少一个会话处于运行中（live）
3. 在插件页关闭任意插件，再重新打开（profiles/desktop/package.json 被重写，触发 profile 热重载）
4. 观察侧边栏

最小复现路径：跑一个会话 → 结束它 → 关开任意插件 → 看侧边栏。约三分钟。

实际结果

• 侧边栏只剩 live 会话（当前会话 + 运行中的那个）
• 所有 cold 会话从列表消失，且搜索无结果
• 无报错弹窗、无日志、无任何提示
• 重启应用后全部恢复

期望结果

会话列表不应受插件热重载影响。若持久化服务确实不可用，应当报错或给出明确提示，而不是静默返回空语料。

根因分析

@deepseek-ai/dsh-session-query 的 SessionCorpus（lib/index.js:78-85）：

this._optionalPersistenceFiber = _ctx.inject(["sessionPersistence"], (childCtx) => {
  const service = childCtx.sessionPersistence;
  this._persistence = service;
  childCtx.effect(() => () => {
    if (this._persistence === service) this._persistence = void 0;   // 服务 dispose 时清空
  }, "sessionQuery.persistenceBinding");
});

listSessions()（lib/index.js:95-98）：

async listSessions(signal) {
  const persistence = this._persistence;
  const persisted = persistence === void 0 ? [] : await listPersisted(persistence, signal);
  //                              ↑ 静默返回空数组，不抛错、不打日志

热重载使 sessionPersistence 被 dispose，_persistence 变为 undefined 且未被重新注入。listSessions 于是把「持久化服务丢失」当作「无持久化部署」的正常降级，返回空语料，最终只剩 this._ctx.sessions.list() 提供的 live 会话。

问题本质：undefined 同时承载了两种语义——「从未注入」（无持久化部署，正常降级）与「曾注入后被 dispose」（异常状态）。后者被静默当作正常处理。

修复建议

1. 区分两种状态（例如增加 bound 标记），服务丢失时抛错或强制重建绑定
2. 或确认 cordis inject 在服务重新提供后是否会重新执行绑定回调；若不会，需要显式重建
3. 同类风险可能存在于其他通过 inject 持有 optional service 的消费者，建议一并审计

数据影响

无数据损失。实测消失会话的文件：

• session.v4.jsonl.zstd = 2,267,167 字节
• 1076 个 zstd 帧逐个解压全部成功，解码 6.96 MB，尾部无残留
• 第一帧 header 合法（末尾 0x0a、JSON 可解析、字段与正常会话同构、无 retired 字段）
• projcache 完整：title 存在、sessionListMetadata.blank = false、seq 与文件一致
• 该会话仍在 workspace.json 的 sessionIds 中，不在 archivedSessionIds

即：磁盘上一切正常，仅列表索引层缺失。通过 @会话标题 引用仍能读出全部事件内容。

附带问题：排障困难

%APPDATA%@deepseek-ai\dsh-desktop\logs 在整个过程中为空。该故障全程无任何日志输出，只能靠逆向 asar 内的代码定位。建议此类降级路径至少写一条 warn。

---

二、功能请求：托盘右键菜单增加「重启 DeepSeek Harness」

现状

托盘的上下文菜单是写死的两项（lib/main.js 的 DesktopTray.relabel()）：

tray.setContextMenu(Menu.buildFromTemplate([
  { label: messages.openApplication, click: () => this.options.open() },
  { type: "separator" },
  { label: messages.quitApplication, click: () => this.options.quit() }
]));

DesktopTray 的 options 只接收 open 与 quit，没有 restart 动作。

而「重启应用」菜单项已经存在：

{
  label: currentDesktopLocale().messages.restartAppHostMenu,
  click: () => {
    if (quitting) return;
    app.relaunch();
    quitWithoutConfirmation();
  }
}

但它挂在 applicationItems() 中，而 Windows 的应用菜单被替换成了 devToolsItems：

Menu.setApplicationMenu(Menu.buildFromTemplate(
  process.platform === "win32" ? devToolsItems : [
    { label: app.name, submenu: [...applicationItems(), ...devToolsItems] },
    ...platformMenus()
  ]
));

devToolsItems 仅包含两个 visible: false 的 toggleDevTools（F12 加速键）。因此该重启项在 Windows 上永远不会被渲染——macOS 有，Windows 没有。

期望

托盘右键菜单增加一项「重启 DeepSeek Harness」，点击后走 app.relaunch() + 退出流程。

理由

1. 这是 macOS 与 Windows 的现有能力差异，不是新增功能，只是补一个平台遗漏
2. 插件热重载、profile 变更等场景下重启是常规操作，入口越短越好；当前 Windows 用户只能「退出 → 再双击图标」两步
3. 与问题一互补：该 bug 目前的唯一恢复手段就是重启，降低重启成本能显著缓解用户感知

实现参考

• DesktopTray 的 options 增加 restart
• relabel() 的模板在 open 与 quit 之间插入一项：{ label: messages.restartApplication, click: () => this.options.restart() }
• 接线复用现有实现：restart: () => { app.relaunch(); quitWithoutConfirmation(); }
• 新增 locale 文案 restartApplication: "重启 DeepSeek Harness"
• 注意：直接 quitWithoutConfirmation() 会中断正在运行的任务。建议重启复用与退出相同的确认流程（现有 locale 已有 quitActiveTasks: "当前正在运行的任务将会中断"），有运行中任务时弹确认，否则直接重启