[Bug][0.1.2-rc.1] 冷态 seeded 会话重启后丢失全部列表投影：cachedSnapshot 以 inheritedEventCount = 0 校验身份，弃用有效检查点

[xmzhu13]

概要

应用重启后，带 fork 血统的冷会话（isSeeded: true、inheritedEventCount > 0）在会话列表中完全丢失投影：无标题（UI 回退显示工作区名）、turns 为 0、无统计、无权限信息。打开该会话后标题与统计恢复正常（live 路径正确），但下次重启后再次丢失。

该会话的持久投影检查点是健康的，observation 路径读写均正常——只有冷列表路径失败，原因是它在校验检查点身份时把 expected inheritedEventCount 硬编码为 0。

版本

在 v0.1.2-rc.1 上实测；dsh-v0.1.3-alpha.1 源码中同样存在。

根因

packages/api/session-controller/src/list.ts 的 summarizeCold 用投影缓存服务冷会话：

// rc.1 第 335 行（0.1.3-alpha.1 第 277 行）
this.ctx.get('sessionProjectionCache')?.cachedSnapshot(header, SessionLogOffset(0))

cachedSnapshot(meta, inheritedEventCount) 用该值构造 expected 检查点身份，而 identityMatches（packages/session/session-projection-cache/src/index.ts:377）要求精确匹配：

(stored.inheritedEventCount ?? 0) === expected.inheritedEventCount

observation 路径写入的检查点存的是真实的 fork 继承前缀长度（例如 270223），因此对每个 seeded 会话，冷列表读取的身份校验必失败，记录被当作无关日志丢弃。随后 probeSmallCold 对任何超过 coldBlankProbeMaxBytes（默认 1024 字节——实际覆盖几乎所有真实会话）的日志返回 undefined，列表 summary 便不带任何投影。

live/attached 路径不受影响，因为它调用的是 sessionProjections.cachedSnapshot(session)，传入的是 Session 的真实 inheritedEventCount。

复现步骤

1. 新建会话并跑几个 turn，使日志超过 1 KB。
2. fork 该会话（副本即 seeded：inheritedEventCount > 0）。
3. 打开一次该副本，使投影检查点落盘。此时侧栏显示正常。
4. 重启应用。
5. session.list 返回的该副本没有 projections 字段：侧栏显示工作区名作为标题、0 turns、排序位置异常。
6. 打开该会话：标题/统计恢复。再次重启：复现。

期望行为

身份与会话真实血统匹配的持久检查点应当服务冷列表 summary——与 unseeded 会话的行为一致。

修复建议

把真实的 inheritedEventCount 传入冷列表路径——例如持久化到存储 header 或由 listSessions 返回——替代 SessionLogOffset(0) 传给 cachedSnapshot。

另注：packages/subagent/subagent/src/list-children.ts:312 以同样方式传 SessionLogOffset(0)，对 seeded 会话是同款潜在问题。

临时规避

每次应用重启后打开一次受影响会话（live 路径行为正确）。

[argszero]

确认：这是真 bug，而且你在 master d347e70390 上的定位基本准确。我在当前源码里核了一遍，机制可以再精确一层，并有一个影响修复方向的设计事实需要补充。

机制修正：冷路径对 seeded 会话是在调用 cachedSnapshot 之前就短路了，不只是 identity 不匹配

api/session-controller/src/list.ts:274-279（projectionsFor）当前结构：

const block = session === undefined
  ? header.isSeeded
    ? undefined            // ← seeded 冷会话：无条件跳过，连缓存都不读
    : cache?.cachedSnapshot(header, SessionLogOffset(0))
      ?? cache?.cachedPredecessorTitle(header, SessionLogOffset(0))
  : this.ctx.sessionProjections.cachedSnapshot(session)

所以现状比"传 0 → identity 不匹配 → 丢弃"更直接：seeded 冷会话根本不进缓存读路径（cachedPredecessorTitle 零 I/O 标题提示也不尝试）。你描述的 identity 不匹配正是"如果传 0 会发生什么"——lifecycleIdentityMatches（session/session-projection-cache/src/index.ts:419-443）要求 (stored.inheritedEventCount ?? 0) === expected.inheritedEventCount，seeded 存的是真实前缀长度（如 270223）≠ 0 → 必不匹配。该 guard 大概率就是因此存在：作者知道传 0 必 mismatch，选择了跳过而不是去取真实 count（git log -S 显示 guard 引入于 seq/log-offset 重构 27bf1039db）。

identity 精确匹配是有意的安全设计，不能简单放宽

• index.ts:395-405 identityOf：!header.isSeeded && cut !== 0 时抛错（"unseeded projection-cache identity inherited event count must be 0"）——非 seeded 必须 0。
• recordFor docblock：防"recreated id / persistence store swapped under a surviving cache 把无关日志的记录当自己的种"。
• cachedSnapshot docblock："never from an unrelated log (the caller's header is the identity witness)"。

所以"放宽匹配/把 count 当可选"会直接削弱这条防串线安全属性，不是可取的修复面。

影响修复方向的关键设计事实：真实 count 刻意不在持久化 header 里

core/session/src/types.ts:99-102（SessionHeader.isSeeded 的 docblock）原文："Whether this Session contains a fork-inherited event prefix. The exact prefix length is Session state rather than ordinary header metadata."

也就是说 count 是 Session 态（fork 时父会话长度），不是普通 header 元数据——你建议的"持久化到 storage header"与这条文档化意图冲突，需要 storage 格式变更 + 相邻迁移；而当前存储描述符也不落 firstLiveSeq（我 grep 过 session 存储层，无持久化点），冷列表没有便宜的渠道拿真实 count。这是修复的真正难点：live 路径传 session.inheritedEventCount 容易，冷路径手里只有 header（只有 isSeeded 布尔）。

修复方向（在尊重 identity 安全模型的前提下）

1. 让冷列表能拿到真实 count：把继承边界作为日志描述符字段落盘（描述符已存 version/createdAt/cwd/isSeeded，再加 inheritedEventCount 或 firstLiveSeq；格式 bump + adjacent migration，旧描述符缺字段 → 该会话退回无投影，不炸不串）。
2. projectionsFor 的 seeded 分支改为 cache?.cachedSnapshot(header, header.inheritedEventCount ?? SessionLogOffset(0))（有 count 才读，无则退回现状 undefined）——去掉 ? undefined 硬短路。
3. 同款修复覆盖 subagent/subagent/src/list-children.ts:312（你已发现，同一模式）。
4. 测试：seeded 会话写 checkpoint → 冷列表（无 live session）能读到投影；非 seeded 传非 0 仍抛错；无描述符字段的旧记录安静退回。

家族关联：#5576（cold-list 标题陈旧，异步 commit 滞后）同处冷列表路径但机制不同（那是缓存滞后、这是身份门）；本 bug 与 #5818/迁移族相邻（已发布会话格式约束）。这属于 core 面（session-controller + projection-cache + 存储描述符），插件旁观——值得作为 upstream-fix 候选归档，修复面清晰、调用点就两处。

附带一个观察供复现参考：你的复现步骤第 3 步"打开一次副本使检查点落盘"是关键——冷列表 bug 只在 checkpoint 已存在但冷读不到时可见；若从未打开过，seeded 会话本来就没投影可丢，侧栏行为一致（都无标题提示），不会暴露此路径。

[xmzhu13]

感谢确认与详尽的机制补充——「guard 是因为知道传 0 必 mismatch 才选择跳过」和「真实 count 刻意不在持久化 header（docblock 明示是 Session 态而非 header
元数据）」这两点补全了我们对现状的理解。也认同修复方向应走存储描述符落 inheritedEventCount + 相邻迁移，而不是放宽 identity 匹配——防串线属性确实不该为这个 bug 让路。

补充一个实测 workaround，供其他撞上的用户参考：打开受影响的会话即可恢复显示——live 路径（sessionProjections.cachedSnapshot(session)）传的是 Session 真实的 inheritedEventCount，标题
/ turns / 统计立即恢复；下次重启后复发，再打开一次即可。数据无损（投影检查点与会话日志都完好），纯显示层问题。

两个排障时的观感提示，帮助快速识别此 bug：

• 受影响会话在侧栏的标题会兜底显示为工作区名——我们最初误以为标题被重写成了工作区名，实际是空投影的 UI 兜底；
• 排序同时异常（updatedAt 回落到 header 时间）——两者叠加很容易被误判为数据丢失，实际打开会话一切正常。