[Bug] 会话从桌面端永久消失、手机端却能看到：workspace 归属只在首次初始化 bootstrap，且 mutate() 会把校验失败的候选静默剪掉（0.2.2-rc.1）

[x-dc-coder]

环境

项	值
DSH 桌面端	0.2.2-rc.1（app.asar 内打包的 harness）
同时存在的另一套 harness	全局 npm @deepseek-ai/dsh 0.2.1-rc.5，共用同一个 ~/.dsh
会话规模	单工作区 81 条会话，磁盘上共 109 条（含 subagent 子会话）
附加负载	桌面端 profile 装了 5 个第三方插件 + 每天多轮的定时任务（this_session / new）
远程访问	手机端通过 remote-access 插件连同一台 Host（所以两端打的是同一份数据）

现象

桌面端空闲挂机、只有定时任务在后台跑。回到桌面端时：

• 侧栏少了一部分会话 / 点开会话报 历史加载失败：…（code）；
• 同一时刻手机端能看到这些会话的历史；
• 重启桌面端不会恢复；只有手工改 workspace.json 才能把会话弄回来（我已经这样修过 3 次，见下"取证"）。
• 频率：几乎每天一次，与"桌面端空闲 + 定时任务触发"强相关。

取证：磁盘上的历史是好的，坏的是"归属索引"

我用自带 zstd 解码器把 109 条 session.v4.jsonl.zstd 逐条解压校验：

• 全部 version: 4，zstd 完整可解，seq 从 0 连续无缺口，坏行 0；
• 事件类型与 0.2.2-rc.1 的 KNOWN_SESSION_EVENT_TYPES 白名单完全命中（没有未知事件、没有"拒绝解析日志"）；
• 索引侧：workspace.json 记账 81 条，磁盘上 27 条是 origin: subagent 子会话（设计上不入工作区），剩下 1 条真正的孤儿：会话 cwd = C:\Users\<me>，没有任何工作区记录指向这个目录，于是它在桌面端永远不可见，而它的日志完好、任何重新列举磁盘的客户端都能看到。

历史上已经被迫手工修过 3 次（~/.dsh/session-repair-backup/ 里留着 11-04 / 11-07 / 11-08 的 workspace.json.bak、projcache.bak、repaired*.zstd）——说明这不是我第一次踩，而是可重复、不可自愈的坑。

代码定位（master 仍在）

1. 归属只在第一次初始化时全量建立：packages/workspace/workspace/src/index.ts Service.init

if (!this.state.initialized) {
  const headers = await this.listStoredHeaders()
  await this.replaceHeaderIndex(headers)
  await this.bootstrap(headers)              // 只有这一次会"建立归属"
} else if (this.table.size > 0) {
  await this.replaceHeaderIndex(await this.listStoredHeaders())   // 之后只对账，不回补
}

2. 任何一次写都会把"当下校验不过"的候选永久剪掉：packages/workspace/workspace/src/entity.ts mutate()

const sessionIds = changed.sessionIds.filter(
  id => this.host.candidateMatches(id, changed.path),
)
return { ...changed, sessionIds, updatedAt: new Date().toISOString() }

candidateMatches = sessionPaths.get(id) === path || missingSessionPaths.has(id)，而 sessionPaths 完全来自启动那一刻的 sessionPersistence.list() 快照。

3. 快照会静默漏掉正在被改名的会话：packages/session/session-persistence-jsonl/src/index.ts list() 里对 stat 抛 ENOENT 的 artifact 直接 continue（注释也写明了这是给"扫描中间刚好落地"的场景兜底）。而 compaction/迁移正是"写临时文件 → rename"的形态。于是定时任务在后台改日志的那一瞬间被 list() 扫到，这条会话就不会进 sessionPaths。

4. 漏掉之后没有任何补救：

• bootstrap 不再跑，initialized: true 之后就永久没有"建立归属"的路径；
• attachSession() 要求 realpath(header.cwd) === workspace.path，cwd 属于未登记目录的会话根本无法被任何代码路径 attach（我那条孤儿就是这样）；
• 剪链只写一条 ctx.logger.warn("workspace '<id>' filtered session '<sid>' from membership: ...")，而桌面端 harness 的日志并不落盘（~/.dsh/logs 只有启动快照），用户零感知。

结果就是：日志在、手机端能看、桌面端打不开，且永不恢复。

最小复现

1. 建工作区 A + 一条会话 S，记下 workspace.json 里 A 的 sessionIds；
2. 完全退出 DSH，把 S 的日志文件临时改名（模拟 compaction 的 rename 窗口，让 list() 扫不到它）；
3. 启动 DSH，在 UI 里做任意一次会写工作区的操作（新建会话 / 改标题 / 置顶 / 拖拽排序）；
4. 退出后看 workspace.json：S 已被永久删除；把日志文件改回来，S 也不会再回来 —— 但 sessionPersistence.list() 依然能列出 S，任何"重新列举"的客户端（手机端）照旧看得到。

变体：启动时 realpath(cwd) 暂时不可用（外接盘没就绪 / 目录被临时改名）会走 invalidSessionPaths，剪链效果相同。

建议

1. 启动增量对账：initialized 分支也做一次"headers 中 cwd 命中已有工作区、但未被任何工作区记账"的自动 attach（跳过 origin: subagent / 有 parentSession 的子会话）。这一步就能把绝大多数线上"会话消失"自愈掉。
2. 剪链要留痕、要收敛：mutate() 的 filter 改成"先标记 + 连续 N 次启动校验失败才真删"，或至少把被剪的 id/cwd/reason 写进 global 或一份可检索的诊断文件，让用户能看见、能上报。
3. list() 对 rename 窗口容忍：artifact 瞬时 ENOENT 时回退到上一次已知 header（或直接读 sessions/<encoded>/<id>/ 目录名），不要让一条会话因为"刚好在改名"而从快照里消失。
4. 给"未归属会话"一个可见去处：cwd 没有对应工作区时，至少让它们在"全部会话 / 搜索"里可打开，或提供"纳入当前工作区"的动作，而不是永久不可见。
5. 多实例保护：~/.dsh 被两套 harness（0.2.1-rc.5 与 0.2.2-rc.1）同时打开时，storage 域是整份 JSON 覆盖写、没有跨进程互斥；建议加锁或至少在启动时检测版本/实例不一致并提示。我这边 ~/.dsh/logs 里就有 web profile 抢 127.0.0.1:3080 失败的记录，说明确实同时跑过两个实例。

附带

如果你需要，我可以把这次的只读取证脚本（zstd 解码 + 索引对账 + 孤儿/幽灵/重复记账体检 + 可选择修复）整理成一个 Discussions 附件或 PR，方便其他人自查 workspace.json 是否也断链了。