`rewriteCompressInput` full-consumption leak: compress part left intact when all blocks consumed

[ranxianglei]

来源: #368 (#368) 分析 "compress-call reasoning inflates the incompressible floor" 时发现

问题

rewriteCompressInput 在 compress 调用的所有 block 都被消费（kept 为空）时直接 return null，导致 compress part 原样保留，其内容（含 reasoning）泄漏到上下文中。

证据

• lib/compress/hide-consumed.ts:42 rewriteCompressInput：

  if (kept.length === content.length || kept.length === 0) return null;

  kept.length === 0 = 所有 block 都被消费 → 返回 null → 不重写 → compress part 保留。

影响

• 完全消费的 compress 调用本应被 hideConsumedCompressCalls 隐藏，但此处泄漏，残留 ~3.7 KB/block。

建议修复

当 kept.length === 0 时应返回一个"空 / 已消费"标记（或让调用方隐藏该 part），而不是 return null（表示"不修改"）。需区分"无需修改"与"应隐藏"两种语义。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 已接手，先给 triage 结论（已逐条在源码核实 + 写了复现脚本验证）：

1. 复现/查证：泄漏真实存在，但触发路径与描述不同

• 描述里的"所有 block 都被消费"并不会泄漏。该路径由外层 keepCallIds 检查正确处理：全消费时 callID 既不在 activeCallIds（无 live block）也不是 orphan（有 block 记录）→ part 被隐藏。现有测试 tests/hide-consumed.test.ts:606（"fully removed when all sibling blocks consumed"）已覆盖并通过。
• 真正能走到 kept.length === 0 的路径是：liveKeys.size > 0（该 call 还有 live block）但没有任何 content entry 匹配上 live block 的 rangeKey —— 即 Protected-message exemption inflates the incompressible context floor: per-compression reasoning is never reclaimable (~83.5% of measured residual) #368 原文说的 "block ranges don't match entries"。

2. 层次定位：根因是 rangeKey 匹配不一致（trim 分歧）

• resolveRanges（lib/compress/range-utils.ts:59-60）对 startId/endId 做了 .trim()，block 记录的是修剪后的值（lib/compress/state.ts:158-159）。
• 但 compress part 的 state.input.content[] 保留的是模型发出的原始未修剪 ID。
• 于是 rewriteCompressInput（lib/compress/hide-consumed.ts:37-39）用原始 ID 算 rangeKey 去匹配 block 的修剪后 ID → 一旦模型 ID 带首尾空白就匹配失败 → kept.length === 0 → return null → part 原样保留（泄漏）。
• 复现脚本确认：live block startId="m5" + content entry startId="m5 " → hidden=0、content.length=2、live summary 仍在 = 泄漏成立。

3. 方案评估：不建议按原提议"kept 为空就隐藏 part"

kept.length === 0 且 liveKeys.size > 0 时存在 live block，其 summary 只通过该 part 送达模型（见 #368 机制点 4）。此时隐藏 part 会丢掉 live summary = 数据丢失，比泄漏更糟。当前 return null（保留）是刻意的保守兜底（代码注释明确写了 "matching missed → left intact rather than risk dropping a live summary"）。

4. 我的修法（更安全，打到根因）

让匹配两侧口径一致：在 rewriteCompressInput 里对 content entry 的 startId/endId 也 .trim() 后再算 rangeKey。这样消除 trim 分歧导致的误判，kept.length === 0 退化为真正的"数据不一致兜底"（保留原保守行为，不隐藏）。改动只读、不写 state、不动持久化格式。

正在建分支 + devlog + 实现 + 测试，完成后回 PR 链接。