[Bug][rc.2] 中断恢复：合成闭包已落盘，续跑却按闭包前的长度编号 → seq 复用、会话历史永久不可加载（3 个实例已在盘上定位并修复）

[Hcc32]

TL;DR

中断（interrupt）后恢复会话时，rc.2 的构建先追加了合成闭包 step/end + turn/end{interrupted} 和 session/end-seed，紧接着的续跑事件却按"闭包之前"的 log 长度编号，于是 seq 整段复用（复用宽度 = 闭包条数），日志从此不可加载。

和 #10429 描述的形状不同：那里是陈旧的活写者交回一条真 tool/result；这里续跑出来的是同一 turn/step 的全新一段运行（assistant/message → tool/call → tool/result → step/end → step/start → …），而且三次落盘跨越 16.5 秒、同进程内三种长度视图。所以它不是跨写者租约能覆盖的竞态，而是恢复路径自己的 seq 基准算错了。

三个坏档都在盘上留了可判读的指纹，我按指纹修好并验证了（见末节）。

盘上指纹

设中断时刻的已提交前缀为 persisted（条数 n），闭包条数 c = 2（step/end + turn/end，无待回填的 tool call），则三个实例都满足：

• persisted 末条
• step/end → seq n
• turn/end {interrupted} → seq n+1
• session/end-seed {} → seq n+2（分离落盘，落后约 6～9 秒）
• 续跑第一条 → seq n（= 第一个闭包的 seq），而不是 n+3

实例（均为 ~/.dsh/sessions/…/session.v4.jsonl.zstd，行号含 header）：

会话	记录数	断点	冲突值	续跑内容
session-18b40e1e…	1900	line 1509	期望 1507，得 1504	turn29/step20 起重新跑
session-f6e85f0c…	2063	line 2021	期望 2019，得 2016	turn18/step8 起重新跑
session-27cc3b7a…	616	line 250 / 285 / 296	247→245、279→248、258→280	turn1 steps 30..35 整段重跑（34 条）

18b40e1e 的原始片段（相对时间）：

seq 1503  t+15504.4s  step/start   turn=29 step=20
seq 1504  t+15504.5s  step/end     turn=29 step=20      # 合成闭包
seq 1505  t+15504.5s  turn/end     turn=29  {interrupted}
seq 1506  t+15510.4s  session/end-seed {}
seq 1504  t+15521.0s  assistant/message  turn=29 step=20  # 续跑，退回 1504
seq 1505  t+15521.0s  tool/call          turn=29 step=20
seq 1506  t+15521.0s  tool/result        turn=29 step=20
seq 1507  t+15521.0s  step/end           turn=29 step=20
seq 1508  t+15521.1s  step/start         turn=29 step=21

注意 step 20 在中断时是刚 step/start 就被打断（还没有 assistant/message），续跑从这一步的模型调用重新开始——这说明续跑继承的是 persisted 这个快照，而不是 persisted + closers 那个快照。

Current behavior

打开历史时报：

历史加载失败：stored session "session-…" is corrupt: invalid committed event at line 1509:
released v2 row 1507 has seq gap (expected 1507, got 1504)

packages/session/session-persistence-jsonl/src/format.ts:510 +
packages/session/session-format-v1-to-v2/src/codec.ts:106。此后该会话永久不可加载，且会从会话列表里消失，普通用户没有任何修复入口。

Expected behavior

恢复流程写下的闭包与它随后续写的实时事件，必须共用同一个 seq 基准；即续跑的第一条事件的 seq 必须是 persisted.length + closers.length + 1（上面例子里应为 1507，而不是 1504）。

环境

• Windows 11，Node 22.x
• DSH 本地构建 0.2.1-rc.2（常驻进程 PID 49648，今天 08:05 才重启到 rc.5；这三个会话的最后写入时间分别是 10-30 17:33、10-31 01:46、10-31 23:58，全部早于升级，所以确系 rc.2 产出）
• 会话格式 v4，session.v4.jsonl.zstd（多帧 zstd）

根因指向

packages/core/agent-loop/src/index.ts 的 resume 路径：

const persisted = coldRead.events                                    // :890
const closers = interruptedTurnClosers(persisted)                     // :891
if (closers.length > 0) await handle.append(closers)                  // :892
preparation = SessionPreparation.create(...prepare(id, {
  seed: [...persisted, ...closers], ... }))                          // :893-898
stored = { handle, storedCount: persisted.length + closers.length }   // :899
await this.appendUnstoredSuffix(stored, preparation.session)          // :900

session/end-seed 是 packages/core/session/src/index.ts:696-697 在构造时补的，所以它拿到了 n+2（正确）。但从 :900 之后进入 live 的会话，第一条事件的 seq 退到了 n。

可疑点是用"条数"做游标：:899 的 storedCount 取的是 persisted.length + closers.length，而 handle 的真实长度已经被 end-seed 推进到 n+3；如果 live 会话的事件数组是按 persisted 播种、appendUnstoredSuffix 又按索引切后缀，两套编号就会在这里错开一格，再被后续 append 放大成整段复用。我倾向于认为 live 会话（用于续跑的那个）持有的日志数组里没有闭包，于是 seq = log.length 从 n 起算。

与既有报告的差别

• Session log can be corrupted when 0.1.0-rc.8 crash recovery races a still-live writer #10429：陈旧写者 + 真结果回填 → 结构修复是 SessionWriteLease。
• [bug] Duplicate seq written to session log when seed-construction and resume overlap (bionic: no write lease → whole history rejected on read) #8984：seed 构造与 resume 重叠导致重复 seq。
• #6407：interrupt + 后台任务恢复后永久不可加载。

本例的新信号是：没有第二个写者，续跑是同一进程继续跑同一 step；如果 rc.2 已带 SessionWriteLease，那它对这条路径无效——问题出在恢复流程内部的 seq 基准，而不是互斥。

已验证的修复方法（3/3 生效）

判据：找到"step/end → turn/end{interrupted} → session/end-seed"三连，且其后第一条事件的 seq 等于第一个闭包的 seq（差值为 c），则这三条闭包是多余的，续跑才是真实经过。

步骤（对 18b40e1e、f6e85f0c 两条直接适用，无需任何语义改动）：

1. 删除这三条闭包行；
2. 其余行按文件顺序重编 seq = 0..n-1；
3. 重新压成两帧 zstd（header 一帧 + body 一帧），保留原 header；
4. 用仓库自带的 scanLog() 严格校验。

结果：

• 18b40e1e：删 3 条 → 1897 事件，scanLog OK，末事件 turn/end seq 1896 turn 32；
• f6e85f0c：删 3 条 → 2060 事件，scanLog OK，末事件 turn/end seq 2059 turn 18；
• 27cc3b7a：形态更大（交错两条链），保留用户实际经历的 turn 2..5 主线，丢弃重跑的 34+4 条，577 事件，scanLog OK。

原文件全部保留了 .pre-repair / .bak-corrupt 备份。

建议加一道写前不变量

append 落盘前断言 event.seq === handle 当前长度，不匹配就拒绝写入并立刻重读日志（而不是只在读取侧靠 scanLog 事后发现）。读取侧的校验只能保证"坏档不被静默吞掉"，挡不住把好档写成坏档——这类损坏一旦提交，用户侧没有任何自愈路径。

如果需要，我可以把这套判据 + 修复脚本整理成一个最小复现器（构造 persisted + closers + 续跑 的单进程时序），方便你们加回归测试。