来源: #376 (#376) 实现 compress 结果面板块跨度回报时发现
现象
tests/compress-tool.test.ts:87 "compress afterTokens is measured on the same sent-view scale as beforeTokens (multi-block)" 声称验证多块 summary-anchor 尺度,但其中两条压缩调用实际都被 kernel 拒绝,测试仍然通过——守卫空转(vacuous)。
证据(用与该测试完全相同的 entries/config 实测)
- tc1(m00001–m00001,"hello world"):
▣ ACP | 646 → 646 tokens (~0 reclaimed, 0 blocks) + Errors: Total compressible content too small (52 chars across 1 range(s), min 5000)
- tc2(m00003–m00003,ZH2=150 CJK chars):同型拒绝,
193 chars ... min 5000
minCompressRange 默认门槛 5000 chars;该测试的 payload(ZH=300 / ZH2=150 CJK chars)远低于门槛。而它的断言(after >= 480、reclaimed <= 180、before - after === reclaimed)在 no-op 面板(646→646,reclaimed=0)上全部成立——压缩发生与否都通过。
影响
#289 的多块尺度回归(afterTokens 必须计入每个活跃块的 summary anchor + ref-tag overhead)目前没有有效守卫;若该投影逻辑回归,CI 不会失败。
建议修复
按 #309/#322 测试的模式改造:entries 改用 ≥5000 chars 的 CJK payload(如 "中".repeat(6000))并传 preserveRecentMessages: 1;先断言面板含 blocks: bN=(#376 新格式)确认压缩真实发生,再保留原有尺度断言。
来源: #376 (#376) 实现 compress 结果面板块跨度回报时发现
现象
tests/compress-tool.test.ts:87"compress afterTokens is measured on the same sent-view scale as beforeTokens (multi-block)" 声称验证多块 summary-anchor 尺度,但其中两条压缩调用实际都被 kernel 拒绝,测试仍然通过——守卫空转(vacuous)。证据(用与该测试完全相同的 entries/config 实测)
▣ ACP | 646 → 646 tokens (~0 reclaimed, 0 blocks)+Errors: Total compressible content too small (52 chars across 1 range(s), min 5000)193 chars ... min 5000minCompressRange 默认门槛 5000 chars;该测试的 payload(ZH=300 / ZH2=150 CJK chars)远低于门槛。而它的断言(
after >= 480、reclaimed <= 180、before - after === reclaimed)在 no-op 面板(646→646,reclaimed=0)上全部成立——压缩发生与否都通过。影响
#289 的多块尺度回归(afterTokens 必须计入每个活跃块的 summary anchor + ref-tag overhead)目前没有有效守卫;若该投影逻辑回归,CI 不会失败。
建议修复
按 #309/#322 测试的模式改造:entries 改用 ≥5000 chars 的 CJK payload(如
"中".repeat(6000))并传preserveRecentMessages: 1;先断言面板含blocks: bN=(#376 新格式)确认压缩真实发生,再保留原有尺度断言。