dsh: 大范围 compress 后 contextBreakdown.messageTokens 为负，zod 拒绝导致本轮运行失败（会话卡死）

[S-AN-Shu]

一句话：大范围 compress 后 dsh-token-meter 的 contextBreakdown.messageTokens 被投影成负数，zod 校验拒绝，压缩后的每一轮运行都失败，会话无法继续。

复现、预期与验收

症状

1. 会话积累大量历史（1200+ 条事件）。
2. 执行一次大范围 compress，例如工具调用：

{"content":[{"startSeq":7,"endSeq":1221,"summary":"..."}]}

一次覆盖 1214 条 seq。压缩本身成功（日志显示"已压缩 N 条历史记录"）。
3. 压缩后模型尝试继续运行，立刻失败：

{"origin":"number","code":"too_small","minimum":0,"inclusive":true,"path":["messageTokens"],"message":"Too small: expected number to be >=0"}

Web UI 显示"本轮运行失败"；再次重试仍然失败（连续多轮），会话卡死。

实际结果

• 压缩成功后 contextBreakdown.messageTokens 等于负数，请求组装被 zod 校验拒绝。
• 后续每一轮都失败，只能放弃该会话。

预期结果

• 压缩后 contextBreakdown.messageTokens 保持 >= 0（或退化到 0），会话继续运行。

环境

• @deepseek-ai/dsh 0.1.1-rc.2（DSH Desktop 0.5.2 内嵌运行，Windows）

根因分析

版本 0.1.1-rc.2 中 dsh-token-meter 的 contextBreakdown 投影（打包路径 lib/types/breakdown-projection.js）：

• const tokenCount = z.number().int().nonnegative() —— messageTokens 必须 >= 0。
• apply 中：messageTokens: state.messageTokens + fold.deltaTokens —— 无下限保护（clamp）。

共享的 surface fold（lib/types/surface-projection.js）走"阴影价协议"：

• compaction/summary 或 compaction/prune 事件 → 武装一个 claim（delta=0，记录被替换范围的影子价 shadowedTokenCount）。
• 紧邻的 surface replace 事件消费 claim：deltaTokens = estimateMessage(新内容) - claim.tokens（负值），累加进 messageTokens。

纯数学上该值不会为负（旧累计 − 被替换范围价 + 新摘要价 = 保留部分 + 摘要 ≥ 0）。但协议存在交错窗口：claim 是单槽位状态，若被相邻事件覆盖/失效后 replace 仍消费（连续两次压缩事件、tool-result-pruner 与 compaction-basic 连续、或投影从 checkpoint 恢复后 stale claim 与新 replace 配对），delta 与累计的吸收会错位；一旦 state.messageTokens + deltaTokens < 0，zod 直接拒绝，且因为投影状态已经写入缓存，后续每轮请求都失败。

大范围压缩（一次覆盖 1000+ seq）显著提高交错概率，与观察到的情况吻合。

建议修复（一处即可）

// breakdown-projection.js apply
messageTokens: Math.max(0, state.messageTokens + fold.deltaTokens),

或在 tokenCount 约束处允许 0 并兜底（投影缓存可重建，应 fail-soft 而不是让整轮运行失败）。

验收条件

• 连续执行多次 compress（含一次覆盖 1000+ seq 的大范围压缩）后压缩成功；
• contextBreakdown.messageTokens 始终 >= 0；
• 压缩后会话可继续运行，不再出现 "Too small: expected number to be >=0"。

[nokkies]

Reproduced, and your expected behaviour is the right one.

Driving the reported shape through the projection directly — one folded append, then a wide shadow claim, then the replacement — gives messageTokens of -499982. Both the state schema and the wire view declare nonnegative, so it is not merely a wrong number on screen: validation fails on every subsequent turn and the session can never continue.

Why it can go negative at all

The subtrahend and the running total do not come from the same set.

A replacement's delta is tokens - claim.tokens, where the claim prices everything the compaction shadowed. The running total, meanwhile, holds only the appends that projection folded. Those differ whenever the projection did not personally observe the whole shadowed range — a checkpoint resumed mid-session, or a compress reaching back over history the fold never saw. Your 1214-seq compress is the clearest possible instance.

So the invariant messageTokens >= 0 was assumed rather than enforced, and the accumulator has no way to guarantee it.

Fix

messageTokens: Math.max(0, state.messageTokens + fold.deltaTokens),

Under-reporting until the total recovers is the strictly better failure mode for an estimate — and it is what you asked for in the expected-result section.

Worth noting the clamp belongs on messageTokens alone: systemTokens and toolsTokens are assigned from estimates on each request/header rather than accumulated, so they cannot drift negative.

A test asserting the wire view parses — rather than just reading as zero — is worth having, since the schema is the thing that was rejecting it:

expect(() => definition.wire.viewSchema.parse(definition.wire.view(state))).not.toThrow()

[Jstn-1g]

I built a bounded reference implementation against official master at b150a551b8d465e31e418e1b2eaf5e79bbb7d28e.

Thank you @S-AN-Shu for the exact failure and acceptance criteria, and @nokkies for independently reproducing the negative accumulator and identifying the fail-soft clamp direction.

The patch covers two consumers of the shared signed surface fold, not only the reported field:

• clamp contextBreakdown.messageTokens at zero;
• clamp the sibling contextPressure.surfaceTokens at zero before its state schema can reject it;
• advance their checkpoint versions from 2→3 and 4→5 so older cached rows are discarded and the authoritative log is refolded from seq 0.

The regression uses a contract-valid historical compatibility sequence rather than an arbitrary shadow price: a legacy unpriced replacement expands the surface without increasing the bounded accumulator, then an adjacent built-in claim subtracts the exact estimator-priced expanded surface before a smaller replacement lands. The old reducers reach -51; the guarded reducers publish schema-valid 0. This demonstrates one valid path to the invariant break; it is not a claim that it reconstructs the reporter's exact stored history.

Evidence:

• focused projection regressions fail before the clamps and pass 30/30 after them;
• full token-meter package: 56/56;
• a keyless real Loader/headless snapshot restores the historical sequence and continues the session after both projections recover;
• state-migration tests pin versions 3/5 and the full seq-0 refold behavior;
• documentation gates: 28/28; typecheck, lint, staged hooks, and pre-push build/contracts checks pass.

Reference branch: https://github.com/Jstn-1g/deepseek-harness/tree/reference/discussion-4674-nonnegative-token-projections

Exact commit: Jstn-1g@fd88e82

This is a verified reference implementation, not a claim of upstream adoption.

[nokkies]

A branch carrying a fix for this is available, based directly on cd5ef8148 (0.1.2-alpha.1) so it applies with git am -3:

https://github.com/nokkies/dsh-upstream-patches/tree/fix/token-meter-shadow-pricing

It stops a shadow entry pricing more than the fold it shadows.

Offered as-is, no attribution wanted. Take, adapt, or ignore it freely.