overflow 压缩会吞掉本轮工作提示，回合仍算成功

[ericcaiwx-star]

context-overflow 压缩用 retainTokens = 0 选区间，只留最后一个 surface node。本轮已准入的 user 消息可以被写进 checkpoint，模型却被要求「从后面的消息继续」。schedule / goal / webhook 这类单次工作回合会在提示被吞后仍走成功 retry。

对标 Hermes #100818：cron 压缩把任务提示并进摘要，模型按「只回答摘要之后的用户消息」保持沉默，调度器仍记 completed。下面写的是 DSH 树上已经存在的同类选择，不是渠道问题。

树上已经这样选

1. packages/compaction/compaction-basic/src/index.ts 在 agent/request-error 上对 CONTEXT_WINDOW_EXCEEDED 调用 compactIfNeeded(agent, 'context-overflow', signal)。

2. overflow 分支写死：

   const range = selectCompactableRange(agent.session, measurement, 0)

3. selectCompactableRange（packages/compaction/compaction-basic/src/region.ts）从尾巴往前累加，直到 accumulated >= retainTokens。retainTokens = 0 时第一次循环即满足，keepFromIdx 停在最后一个 node。除最后一格外的 surface 都进入 shadow 区间。

4. checkpoint（packages/compaction/compaction-basic/src/summarizer.ts）把压缩内容当背景，要求模型从后面的消息继续任务，不要回应这条 checkpoint。

5. 压缩成功后 overflow 返回 { kind: 'retry' }。本轮 schedule / goal / webhook 准入的 user 消息若不是最后一格，retry 时模型看不到那条工作提示，只看到「继续后面」的 checkpoint 和可能无关的最后一格（工具结果或助手碎片）。回合可以正常结束。

人工 /compact（compactNow）要求空闲、且不得有未关闭回合，不在这条里。压力压缩走 retainTokens = spec.retainTokens，也不是这条。只论 overflow。

建议怎么改

不变量只有一条：overflow 不得 shadow 本轮已准入的 user 消息；做不到就让回合失败，不得成功 retry。

修在 @deepseek-ai/dsh-compaction-basic，不要改 agent-loop，不要给 schedule / goal / webhook 各加一层 consumer 守卫，不要新增 config。

具体落点二选一（或两个一起，只要不变量成立）：

• 选区间时：overflow 调用 selectCompactableRange 时把本轮已准入的 user 消息留在尾巴里，不允许它进入 shadow 区间。retainTokens = 0 只表示「为腾窗口可以压得更狠」，不表示「可以丢掉当前工作提示」。
• 提交前：compactRegion 若发现本轮 user 消息会进 shadow 区间，拒绝这次压缩，overflow 保持原来的 request error，不返回 { kind: 'retry' }。

checkpoint 文案可以后补。先保证模型 retry 时还能看见本轮工作提示；看不见就不该当成功。

验收

• 先红测试：构造一个 overflow，本轮 user 消息不是最后一个 surface node；压完后该消息仍在 surface，或不进入成功 retry。
• 对称：schedule / goal / webhook 各一条，证明不是人工 /compact 才有的约束。
• 生产代码不新增 tunables。

Owner

• @deepseek-ai/dsh-compaction-basic
• packages/compaction/compaction-basic/src/index.ts（overflow 的 retainTokens = 0 与 retry）
• packages/compaction/compaction-basic/src/region.ts（selectCompactableRange）
• packages/compaction/compaction-basic/src/summarizer.ts（CHECKPOINT_PREAMBLE）
• 消费方：packages/schedule/schedule、packages/goal、packages/webhook/webhook（往 session 写 user-role 工作提示）

[argszero]

Verified every claim against current upstream master (4e84901 = 0.1.2-alpha.4) — your analysis is exact, and the fix seam you propose is the right one. Line-level confirmation:

1. Overflow trigger — index.ts:180-195: agent/request-error handler, gates on failure.code !== CONTEXT_WINDOW_EXCEEDED_CODE, calls compactIfNeeded(agent, 'context-overflow', signal).
2. retainTokens = 0 hardcoded — index.ts:284-289: the context-overflow branch calls selectCompactableRange(agent.session, measurement, 0) (after an optional model-free prune), then compactRegion(start, end, ...).
3. retainTokens = 0 keeps only the tail node — region.ts:114-122: the accumulation loop breaks on its first iteration (accumulated = pricedNodes[last].tokens >= 0), so keepFromIdx = the last surface node; the only walk-back is toolPairingBalancedBefore (:124-127), which protects tool-call/result pairs — nothing protects user messages. Range = {start: nodes[0], end: nodes[keepFromIdx - 1]} → everything except the tail is shadowed.
4. Checkpoint framing — summarizer.ts:69-74 CHECKPOINT_PREAMBLE: "Treat the captured context as established background… Continue the task directly from the messages that follow, without acknowledging this checkpoint." Exactly the "continue from later messages" instruction.
5. False-success retry — index.ts:218-229: whenever compaction advanced surface.replaceGeneration (i.e. the region was replaced), the handler returns { kind: 'retry' } — regardless of what got shadowed. The conservative path exists too (:221-222: no replaceGeneration advance → return next(), preserving the original request error).

The one nuance worth adding to the red test: the bug bites only when the admitted user message is not the tail node. If overflow fires on the first model request after a user message (no tool calls yet), the tail node is that message and it survives — the retry is safe. The shadowing happens in tool-loop turns: user message → assistant tool_calls → tool results → overflow on the next model request — now the user message is mid-surface, gets checkpointed into "established background", and the retry rebuilds from a surface whose only tail content is tool results/assistant fragments. Schedule/goal/webhook single-shot turns hit exactly this shape because their work instruction is followed by tool activity before the later request blows the window. So the fixture must place the user message before a tool result, not at the tail, or it will pass vacuously.

On the two fix options: both preserve your invariant, and the code already has both exit paths — option B (refuse compaction) flows through the existing return next() at :221-222 and keeps the original error fail-loud, while option A (exclude the current turn's admitted user message from the shadow range in selectCompactableRange) keeps overflow recoverable. Since pressure-path compaction (spec.retainTokens) has the same selectCompactableRange walk, option A's guard belongs in the shared selection logic — a "never shadow the last admitted user-role message of the current turn" floor under keepFromIdx — not in the overflow branch alone. Option B can be a cheap belt-and-braces at compactIfNeeded returning null when that floor would be violated, which then makes :221-222 preserve the original error instead of a false-success retry.

Also worth noting this is adjacent to the earlier compaction report about summary-not-smaller hard-throw (#4454) — different mechanism (selection swallowing live context vs. shrink refusing), same owner seam, so a single fixture family under @deepseek-ai/dsh-compaction-basic would serve both.

[ericcaiwx-star]

对，分析对上了，谢谢按 master 逐行核。

先红测试按你说的来：user 必须在工具结果前面。overflow 打在 user 之后第一次请求时，尾巴就是那条 user，会空绿。schedule / goal / webhook 出事的就是工具环这一种。

改法也按你的落点：A 的 floor 进共享的 selectCompactableRange（「本轮最后一条已准入的 user 消息不得进 shadow」），不要只改 overflow；B 当保险，选区间会违反这条就让 compactIfNeeded 返回 null，走现成的 replaceGeneration 未前进 → return next()，保住原来的 request error。

#4454 同 owner、不同机制，测试可以放同一家族，PR 不绑。

[VillagerUncle02]

补一组量级数据，另外有个调用点可能值得一起写进原帖。

环境：dsh 0.1.5-rc.1 / deepseek-flash / contextWindow 1048576 / Windows。

本机 8 次完整压缩里 7 次走 overflow。overflow 的 post/pre 分别是
1.72% / 1.75% / 2.02% / 2.10% / 2.25% / 2.38% / 2.60%，也就是一次从约 79 万 token 掉到一万多。
作为对照，唯一那次 pressure 保留了 161146 / 167772 = 96.1%，所以问题确实只在 overflow
这一条分支，不在 retainRatio。

调用点这边，除了 agent/request-error 上那条，还有一处也传 0：

dsh-compaction-basic/lib/index.js:891   selectCompactableRange(..., 0)                // context-overflow
dsh-compaction-basic/lib/index.js:908   selectCompactableRange(..., spec.retainTokens) // pressure
dsh-compaction-basic/lib/index.js:951   selectCompactableRange(..., 0)                // compactNow

compactNow() 是手动 /compact 走的路径。也就是说用户主动整理上下文，拿到的是和 overflow
一模一样的激进结果，同样只留最后一个 surface node。这个和你在 #6223 里观察到的
"/compact 在 mid-turn 报 compaction active"是两条不同的路径，但后果同源，可能值得一并写进去。