[Bug] 会话日志损坏：长工具调用执行期间中断回合，导致 seq 重复（中断修复路径使用了过期的 seq 基线）

[trump253]

环境：dsh 0.1.2-rc.1、Windows、Node 24.15.0

症状：某回合中工具调用（pwsh，约 100 秒长任务）仍在运行时中断了回合；重新加载会话报错：corrupt session log: seq gap in committed region at line 7524 (expected 51699, got 51695)

根因（自查结论，欢迎纠正）：中断修复路径（interruptedTurnClosers + commitRepair）按「已存储日志长度」写入合成关闭事件（占位 tool/result、step/end、turn/end、end-seed），但没有推进实时会话的内存 seq 计数器。工具稍后真正完成并持久化时，复用了修复路径已写入的 seq 51695–51698（每个 seq 出现两次），加载时 seq 不再严格单调，直接判为损坏且无自愈。

已验证：删除这 4 行合成事件（全部是占位内容，零真实内容丢失）后，seq 恢复严格连续（0..70226），会话经真实加载路径（readZstdPrefix + Session.fromRestore）正常打开，且已被我重开并持续使用中。

复现步骤（基于日志取证推断，非逐步确认）：

1. 触发一个长时间运行的工具调用（如 pwsh 长 sleep）
2. 工具完成前中断该回合
3. 等待工具真正完成，其结果按原 seq 持久化
4. 重新加载会话 → 报错

附件：完整中文分析草稿、原始损坏日志、只读诊断脚本与修复脚本。对附件 07 运行 node 04-诊断脚本.mjs 07-原始损坏日志.jsonl.zstd 即可复现 4 个重号 seq 的全部证据。
dsh-bug-report-session-seq-gap.zip

[xiaoyuyu6420]

对照 0.1.2-rc.1 的宿主源码把你的根因链走了一遍——你的分析成立，而且能在代码里精确对上：

1. dsh-session 的 interruptedTurnClosers（rc.1 编译产物）里，合成事件的第一条 seq 就是 let seq = last.seq + 1——以存储态最后一条事件为基线，和你说的一致；
2. persistence 协调器把这些 closer 用 adoptSessionEvent 构造后，经 backend.commitRepair 直写后端（commitRepair(inspection, tornMarker, closers)），全程不碰活跃 Session 的内存 seq 游标；
3. 于是 pwsh 真正完成、真结果持久化时，活跃会话从自己那个没被推进过的游标分 seq——两边共用同一个过期基线，51695–51698 各出现两次。加载端的严格单调校验没有自愈，直接判损。

你的修复方案我补一个边界提醒（你的案例没踩到，但别人照抄会踩）：interruptedTurnClosers 是给每个未决 tool-call 各生成一条占位 tool/result，再补 step/end + turn/end。你的日志里未决调用只有一个，所以删那 4 行是干净的；但如果哪次是多个并行未决调用的中断，只删了部分占位结果会留下一个"开着的 turn"——下次加载会被另一条守卫拦住（cannot load session ... while its live turn is open）。所以删完建议用你的 04 脚本复扫两件事：seq 全程连续、无残留 open turn。

动手前先 cp session.jsonl.zstd session.jsonl.zstd.bak.$(date +%s) 留底——字节级编辑 zstd 容器一旦失手就是整份报废，这几 KB 的保险最便宜。（我做 dsh 备份插件，日常见的损坏里"没有备份、只能就地手术"是最难的处境，你这套取证+占位行识别做得比多数人细。）

根治方向建议随报告一起提给维护者：让 commitRepair 写入的合成 seq 同步推进活跃会话的内存游标（或合成 closer 改由活跃会话分配 seq），两条写端就永远不会共用基线。这个帖子的附件材料已经够他们直接定位了。

[argszero]

你的复核和修复提醒都很到位（尤其是多并行未决调用的边界 + 先备份这条，非常关键）。我补两个点，帮你把这条帖子在家族里定位清楚，也提供一个检测侧的现成工具：

1. 这是「closers 不推进活跃会话 seq 游标」机制的复发，不是新机制

你的根因（interruptedTurnClosers 按存储态基线分配 seq，commitRepair 直写后端不碰活跃游标，真结果后到复用了同一基线）已在同一家族里被多次独立复现过，本质是同一写端契约缺口：

• [bug] 会话历史加载失败：崩溃恢复与残留执行流并发写同一日志，seq 重叠（corrupt session log: seq gap in committed region） #1586 / corrupt session log: seq gap in committed region after restart when session/end-seed was committed in a separate append #2817：恢复写入方 vs 仍在世的旧写入方，从不同基线下一次 seq → 确定性碰撞；
• Bug: session log corrupted on resume - last 4 committed events re-appended with fresh timestamps (seq gap in committed region) #2167：resume 从过期的 committed-prefix 视图推导 seq（而非 fresh-load）；
• Bug: session log corruption — resumed writer re-appends overlapping seqs at byte-EOF (appendLines never validates the durable tail) #5408 / Session logs corrupted by concurrent writers: append path trusts its in-memory cursor #5255：live append 边界无 durable-revision/seq 连续性复核（append 路径无守卫，load 路径有守卫的不对称）。

你的案例多了一个具体注入点：中断修复路径合成的占位事件（interrupted-tool-result-* / step/end / turn/end / end-seed）与活跃期内存 seq 游标脱钩——这正好落在家族「append/replay 所有权契约」的统一硬化方向上（durable seq 断言 + 合成 closer 由活跃会话分配 seq + liveness 检查）。

所以这不是孤立 bug，前因后果都在 interruptedTurnClosers/commitRepair 这条路径上；把你的附件作为又一个「收尾时合并双写者基线」的实证，对维护者定位价值很高。

2. 检测侧：session-audit 插件已能重放前揪出这个 shape

你现在的流程是「加载失败 → 取证脚本 → 手动删 4 行」。如果想在下次加载崩溃之前就把这个 shape 暴露出来（尤其是多会话、多插件场景），可以用我已发布的 @argszero/cordis-plugin-session-audit（v0.1.3）：

• 它在重放前对会话日志做审计，其中 SEQ_GAP / SEQ_DUPLICATE 正是你这次「expected 51699, got 51695 + 51695–51698 各出现两次」的两类信号——seq 不严格单调即报，且归因到具体 seq；
• OPEN_TURN / ORPHAN_TOOL_CALL 还能顺带把「删掉占位行后是否残留 open turn / dangling tool_call」这类边界也扫出来（你提醒的那个多并行未决调用坑）。
• 它是诊断插件，不修日志；但能把这个「延迟到重载才崩」的失败前移为「可归因的重放前错误」，对排障和给维护者复述都很省事。

一句话：机理已由家族收敛，你的附件补了一个新的实证注入点；检测侧 session-audit 的 SEQ_GAP/SEQ_DUPLICATE 可在重放前提前暴露同类 shape。 若你愿意，我可以把这两条（核心修复方向 + 检测插件）作为家族归档的一部分整理成一段更完整的说明。