seq 序号重复导致对话加载失败

[Firefly1007]

seq 序号重复问题

异常点只有一个：第 6708 条记录 seq 从 147517 回退到 147513，导致 147513–147516 出现两次。这种"序号回退 + 重复"是事件溯源系统典型的计数器与持久化状态不一致，只能由程序在分配/恢复 seq 时出错产生，不可能由磁盘或用户操作造成。

seq 的分配规则是硬编码的：append() 里 seq: this.log.length（源码 lib/index.js:1455），注释明确写着"seq = log.length 连续性契约"。
resume/fork 时，seed 边界决定 log.length 的起点：构造函数里 firstLiveSeq = this.log.length，若 seed 末尾不是 session/end-seed 就追加一条（index.js:1385-1387）。
崩溃恢复还有一条 interruptedTurnClosers() 逻辑：若日志末尾是未闭合的 turn，会重新生成合成 closer（tool/result + step/end + turn/end），seq 从 last.seq + 1 开始（index.js:664）。

[argszero]

非常好的定位——我把你引用的 built lib 路径对应到当前 master 的源码，逐条核对后基本都成立，但有一个关键点想补充：interruptedTurnClosers 不可能是"序号回退"的来源，真正的候选是并发写入。

源码对应（built lib → src）

• seq: this.log.length → packages/core/session/src/index.ts:629。注意这行在 append() 里：seq 是当次 in-memory 日志长度的索引，不是持久化的计数器。每条 Session 实例从自己的 log.length 派生 seq。
• resume/fork 的 seed 边界 → index.ts:525-528：seed 校验要求 snapshot.seq === index（从 0 连续）。连续性校验只能挡住"断档"，挡不住"截断"——一个被截短但依然从 0 连续的 prefix 会静默通过。
• interruptedTurnClosers → packages/core/session/src/repair.ts:85：合成 closer 从 last.seq + 1 开始，只向后延伸、从不回退。所以它不会产生 147517→147513 这种回退。

真正可疑的机制：跨进程并发写入

seq = log.length 是每进程实例内的契约。进程内是安全的（coordinator.ts:231 "reject a second, unrelated session"、:724 "cannot prepare session while it is live"、:581 per-id promise chain 串行化），但跨进程没有锁：

• session-persistence-jsonl/src/index.ts:649 的 appendLines 就是 open(path, 'a') + write + fsync——O_APPEND 只保证单次 write 不撕裂，不保证 seq 不重叠；
• link()（:546）只保护首次物化（防止两个进程同时创建同名文件互相覆盖），append 阶段没有任何互斥；
• 两个进程各自持有同一 id 的 live Session（seed 相同 → log.length 相同）→ 各自算出相同的 seq 区间 → 都往文件尾部 append。

文件里出现 …147512, 147513…147517, 147513…147516（你看到的"第 N 条 seq 从 147517 回退到 147513"）正是"writer B 在 writer A 的 batch 之后又追加了自己的 batch"的形态：B 的 seed 停在 147512，于是从 147513 重新开始。两个 batch 的 seq 区间重叠但各自内部连续。

需要你确认的几点

1. 用的是 JSONL 还是 SQLite 后端？
2. 出事时是否有两个进程/两个入口同时开着这个会话？比如：dsh web + 另一个 CLI/窗口、两个浏览器标签页、或者一个常驻进程 + 一次重启竞速。跨进程场景下 coordinator 的"单 live session"约束管不到。
3. 如果只有单进程：那更可能是 torn-tail 修复路径（commitRepair 把文件 truncate 到 committedBytes）把已写完整但未被 scanLog 计入的尾部裁掉了，然后恢复的 Session 从更短的 seed 重新 append。这种情况你可以在文件里看到 repair 后新 batch 的 time 与旧 batch 不同但 seq 重叠——也是"回退"的另一种形态。

给维护者的修复方向（feature request 素材）

• 持久化层加每 id 的 append 水位 + 跨进程互斥（如锁文件/原子 CAS last-seq），或
• 至少在加载时检测 seq 非单调/重复并 loud fail（SESSION_FORMAT_VERSION = 0，pre-release，改格式无兼容负担），而不是让损坏静默进入会话。

如果你能提供后端类型 + 复现时进程拓扑，我可以继续往对应后端（JSONL append 路径或 SQLite 事务）里挖。