[dsh-compaction] A compaction/prune span stored by 0.1.1-rc.2 is unaddressable under 0.1.5 — the v0 migration refuses the whole session

[yamingmou]

Environment / 环境

Item	Value
Product	@deepseek-ai/dsh (DeepSeek Harness)
Version observed	0.1.5-rc.1 / 0.1.5-rc.2 (migration packages); source log written by 0.1.1-rc.2
Where observed	a real session log migrated through the official v0 → v1 → v2 → v3 chain
Source of the log	written by 0.1.1-rc.2, 20,179,981 B / 64,085 lines, unmodified (read-only)
Gates referenced	dsh-compaction/lib/invariant.js (validateShadowedSeqs) · dsh-session-format-v0-to-v1/lib/index.js:2576 · dsh-compaction-tool-result-pruner/lib/index.js:137-169

Summary

A session log written by 0.1.1-rc.2 contains 17 compaction/prune entries whose declared span does not resolve on the surface model that 0.1.5 validates against. The migration refuses the whole session at the first such entry:

compaction/prune 151836 shadowedRange start targets consumed assistant/chunk 1299

The point of this report is not "a log has bad data". It is that the meaning of a stored prune span is not versioned: a span is a pair of coordinates that is only interpretable relative to some surface model, and nothing on disk records which one. When the surface model changes, previously-stored spans become unaddressable, and the failure mode is "the entire session will not open" rather than "this one log-only entry is ignored".

What the 17 entries look like

• 0 of 17 have shadowedRange.start on the surface that the invariant is checked against. All 17 land inside a packed assistant/chunk run.
• v1 → v2 folds chunk runs, so chunk coordinates are not addressable in the v2/v3 coordinate space — there is no mapping entry that produces them.
• Each of the 17 has no paired surfaceOp: replace tool/result. The 7 compliant compaction/prune entries in the same log all have one.
• Recomputing the official per-message price (dsh-token-meter, ceil(len/4)+4-class estimator) reproduces the stored shadowedTokenCount for the compliant entries in 7/7 cases; for the 17 entries, the stored value matches no node in the log (0/17).

Together these say the span was not written against the same surface model that 0.1.5 checks. We could not find any derivable repair: the coordinates are not a spelling of a current node, the price is not a price of any current node, and there is no replacement to resolve against. Guessing a span would be inventing history, so none was synthesised — these entries are simply outside what can be reconstructed from the artifact.

The part that seems worth fixing

We cannot tell from the artifact whether the span was legal when it was written and became unaddressable later, or was already illegal at write time. That is exactly the problem:

1. A stored span carries no version of the surface model it was computed against. Two builds can read the same bytes and disagree about whether the entry is well-formed.
2. ToolResultPruner only ever prunes tool/result nodes that are on the surface at that moment (dsh-compaction-tool-result-pruner/lib/index.js:137-169). So a span pointing into a chunk run should not be producible by the current write path — which makes it ambiguous whether this is (a) an old write path that skipped the check, or (b) a surface model that changed underneath data that was legal when written.
3. The failure is hard, not soft. An unsatisfiable log-only entry takes down the entire session. Prunes are not part of the visible conversation; users get "your session is gone" for data that was never shown to them.

Suggested direction (any one would help)

1. Validate at write time — reject a span that does not resolve against the current surface when the prune is appended, so illegal data never reaches disk.
2. Make the span self-describing — record the surface model / a generation marker alongside the span, so a later reader can migrate it instead of rejecting it.
3. Fail soft on log-only entries — if a prune's span is unsatisfiable but the entry is not on the surface and is not referenced by anything, skip it with a warning rather than refusing the whole session. (We understand this trades strictness for availability; it may be acceptable for entries that can never be shown.)

What we did not claim

• We did not claim a specific write path produced this; we only established that the stored span does not resolve under the checked model, and that no mapping to the current space exists.
• We are not asking for the 17 entries to be "fixed" — we are asking that the ambiguity be removed so that the next occurrence is decidable.
• Our ask is about the gate itself, not about our data — how one chooses to handle unsatisfiable log-only entries is the reader's call.

---

Reported by the OfferKuai Team — Founder: Zhaofeng (Yaming). Website: https://www.offerkuai.com/ | Contact: contact@offerkuai.com

Authorship note: measured and documented by me against my own session store; root-cause tracing and drafting assisted by AI; verification and publication by me. I have no engineering background — if any technical claim reads wrong, please call it out; I will re-verify against the toolchain and correct.

---

中文版

环境

项	值
产品	@deepseek-ai/dsh（DeepSeek Harness）
观察版本	迁移包 0.1.5-rc.1 / 0.1.5-rc.2；被迁移的源日志由 0.1.1-rc.2 写入
观察位置	一份真实会话日志，走官方 v0 → v1 → v2 → v3 链迁移
源日志	由 0.1.1-rc.2 写入，20,179,981 字节 / 64,085 行，未改动（只读）
涉及判据	dsh-compaction/lib/invariant.js（validateShadowedSeqs）· dsh-session-format-v0-to-v1/lib/index.js:2576 · dsh-compaction-tool-result-pruner/lib/index.js:137-169

摘要

一份由 0.1.1-rc.2 写入的会话日志里，有 17 条 compaction/prune 的声明区间在 0.1.5 校验所用的 surface 模型上不成立。迁移在第一条处就拒收整条会话：

compaction/prune 151836 shadowedRange start targets consumed assistant/chunk 1299

这份报告想说的不是"某份日志里有坏数据"，而是：一个被存在磁盘上的 prune 区间，其含义是没有版本标记的。区间是一对坐标，只有相对于某个 surface 模型才可解释，而磁盘上没有任何东西记录它是按哪一个算出来的。当 surface 模型变了，先前存下的区间就变得不可寻址，而失败方式是"整条会话打不开"，而不是"这一条纯日志条目被忽略"。

这 17 条长什么样

• 0/17 的 shadowedRange.start 落在校验所用的 surface 上；17 条全部落在一段被打包的 assistant/chunk 运行内部。
• v1 → v2 会把 chunk 运行折叠掉，所以 chunk 坐标在 v2/v3 坐标空间里不可寻址——不存在能产生它们的映射项。
• 这 17 条都没有配对的 surfaceOp: replace 的 tool/result；而同一份日志里 7 条合规的 compaction/prune 都有。
• 复刻官方逐消息计价（dsh-token-meter，ceil(len/4)+4 一类）后：合规条目的 shadowedTokenCount 能被复算出来 7/7；而这 17 条存下的值，在整份日志的任何节点上都对不上（0/17）。

三条合起来说明：这些区间不是按 0.1.5 校验所用的那个 surface 模型写下的。我们找不到任何可推导的修复——坐标不是某个当前节点的另一种拼法，价也不是任何当前节点的价，而且没有配对的替换可供解析。猜一个区间等于伪造历史，所以那 17 条我们按"无法从产物重建"处理，没有去合成。

我们认为值得修的部分

从这份产物上，我们无法判断该区间是"写入时合法、后来变得不可寻址"，还是"写入时就已经非法"。而这正是问题所在：

1. 存下的区间不带它当时所依据的 surface 模型的版本。 两个 build 读同一段字节，对"这条是否良构"可以给出不同答案。
2. ToolResultPruner 只会裁剪当刻在 surface 上的 tool/result 节点（dsh-compaction-tool-result-pruner/lib/index.js:137-169）。所以指向 chunk 运行的区间不该由当前写路径产生——这让"这是旧写路径漏了检查"还是"下面那层 surface 模型变了"变得无法区分。
3. 失败是硬的，不是软的。 一条无法满足的纯日志条目，拖垮的是整条会话。prune 不属于可见对话；用户得到的是"你的会话没了"，而那些数据从来没给他看过。

建议方向（任一条都有帮助）

1. 写入时校验：prune 落盘前就拒绝无法在当前 surface 上解析的区间，让非法数据到不了磁盘。
2. 让区间自描述：把 surface 模型 / 世代标记与区间一起记录，后来的读者可以迁移它，而不是拒收。
3. 纯日志条目软失败：若某条 prune 的区间无法满足、但它不在 surface 上、也没有被任何东西引用，则跳过并告警，而不是拒收整条会话。（我们理解这是拿严格性换可用性；对于永远不会被展示的条目，这或许可以接受。）

我们没有主张的

• 我们没有主张是某条具体写路径产生了它；我们只确认了"存下的区间在被校验的模型上不成立，且不存在到当前坐标空间的映射"。
• 我们不是要求把那 17 条"修好"，而是要求消除这种歧义，让下一次出现时可判定。
• 我们的诉求是这道门本身，而不是我们的数据——无法满足的纯日志条目怎么处置，由读者自行决定。

---

本报告由 OfferKuai（Offer快）团队提交 —— 创始人：Zhaofeng（Yaming）。官网：https://www.offerkuai.com/ ｜ 联系：contact@offerkuai.com

署名说明：本文由我对自己的会话库实测并整理；根因追溯与成稿有 AI 协助；核验与发布由我完成。我并非工程背景——若任何技术表述有误，请直接指出，我会对照工具链复核并更正。