会话从工作区列表消失（孤儿会话）：新建/继续的会话未 attach 到工作区，且 bootstrap 只在首次初始化时收编

[yu633]

环境

• DSH 0.2.0-rc.2（dsh web 与桌面版共用同一个 DSH_HOME=D:\Data\dsh）
• Windows 11 / Node v24.18.0 / win32 x64

现象

某个会话在创建它的客户端里可见，但在另一个客户端的工作区列表中完全不存在；重启创建方之后，它也会从侧栏消失。会话文件、标题、投影缓存都完好，全程没有任何报错或警告。

实测（工作区 E:\wk-aidu）：

• 磁盘上有 15 个会话目录，但 storages/workspace.json 中该工作区只登记 4 个；其中 1 个 blank=true 会被列表过滤 → 列表只显示 3 条。
• 缺失的会话 session-d901ebef-…（标题「项目汇报评估2」）：日志正常、投影缓存 rows.title.val 正常、sessionListMetadata.blank=false、identity.cwd="E:\wk-aidu"，但它不在任何工作区的 sessionIds 里（8 个工作区全部查过）。
• 把它补登回工作区并重启两个客户端后，列表恢复一致（4 条）。

根因

会话列表的数据源是工作区注册表 storages/workspace.json 的 workspace.sessionIds（dsh-workspace 的 sessionIds getter 还要求 host.sessionPath(id) === record.path）。它有三个环节共同导致孤儿会话：

1) 创建会话时，只有带 workspaceId 才 attach

@deepseek-ai/dsh-api-session-controller/lib/index.js：

async create(request) {
  ...
  let workspace;
  if (request.workspaceId !== void 0) {
    workspace = this.ctx.workspaceRegistry.get(request.workspaceId);
    ...
  }
  const cwd = workspace?.path ?? request.cwd ?? this.defaultCwd;
  ...
  if (workspace !== void 0) try {
    await workspace.attachSession(sessionId);
  } catch (error) { ... }
}

也就是说：调用方若只提供 cwd（例如“在新窗口继续 / fork 一个新会话”这类流程），新会话不会被登记进任何工作区。

2) 孤儿会话永不自愈

@deepseek-ai/dsh-workspace/lib/index.js 的 Service.init()：

if (!this.state.initialized) {
  const headers = await this.listStoredHeaders();
  await this.replaceHeaderIndex(headers);
  await this.bootstrap(headers);        // ← 唯一按 header.cwd 收编孤儿的逻辑
} else if (this.table.size > 0) await this.replaceHeaderIndex(await this.listStoredHeaders());

bootstrap() 会把未归属的会话按 header.cwd 并入对应工作区，但它只在注册表首次初始化时运行一次。注册表一旦 initialized: true，之后启动都只重建路径索引，孤儿永远是孤儿。

3) 只在“别的客户端”暴露

创建方进程内该会话仍然活跃，因此照常出现在自己的侧栏；读取注册表的其他客户端则完全看不到。所以从用户视角看是“升级/重启后会话丢了”，很容易误判为数据损坏。

期望行为

1. 创建会话时，如果只给了 cwd，应把解析出的工作区一并用于 attachSession；至少“继续/fork”流程应当沿用源会话的 workspaceId。
2. bootstrap() 的收编逻辑建议在每次启动幂等执行一次（或提供显式的“收编孤儿 / 修复注册表”入口）。
3. 收编失败或存在未归属会话时，应给出可见提示。目前 reportFilteredCandidates() 只写 logger.warn，UI 里看不到。

临时绕过（供遇到同样问题的用户）

停掉客户端后备份 storages/workspace.json，把该 session id 前插到对应工作区记录的 sessionIds（attachSession 也是前插），然后重启客户端。
注意：正在运行的客户端内存里持有旧副本，回写时会覆盖该修改，所以创建方与读取方都要重启。

我是用一个小脚本做的：遍历 storages/session_projcache/*.json，用 identity.cwd 匹配工作区路径，并且只处理 sessionListMetadata.blank === false 且 rows.subagent.val.identity 为空的会话（子代理会话同样不在工作区里，但不能并进去——我第一次干跑就误抓了 28 个子会话）。

数据佐证

• 会话日志 / 投影缓存 / 标题齐全，formatVersion 与日志代际一致；
• workspace.json：8 个工作区、global.initialized=true、archivedSessionIds=[]；
• 补登前后对比：wk-aidu.sessionIds 4 → 5，列表 3 → 4。