prune: isCovered misses base-id coverage when block effective ids use sub-id forms (base#suffix)

[ranxianglei]

Found while investigating billion-context-pi #336 (closed PR #225).

Bug: isCovered(id, covered) in src/prune.ts only tests exact id membership. If a compression block's recorded effective message ids use sub-id forms (base#callId, base#r0, …) while the current projection emits plain base (or vice versa after a projection change), coverage checks fail and already-compressed messages re-enter the visible view resurrected (measured: a 762K-token leak in replay after introducing thinking sub-id projections).

Fix: normalize to the base id before membership — covered.has(id) || covered.has(base) || any covered entry shares the same base prefix. Currently latent (no shipped adapter projects sub-ids), but it bites anyone who extends the projection.

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 Triage update — bug verified, fix in progress.

Verified (repro, not just code reading): added 8 regression tests; 6 fail on current master:

• prune resurrects the message in both directions: block records sub-ids + view emits plain base (your primary scenario), and block records base + view emits sub-ids.
• Sibling sub-ids of the same base (h_abc#r0 covered, view emits h_abc#call1) also leak.
• Negative case (distinct id h_abcde vs covered base h_abc) correctly stays visible — the fix must not turn into prefix matching.

Mechanism: src/prune.ts:144 does covered.has(messages[index]!.id) — exact string membership, with covered built verbatim from block.effectiveMessageIds (src/state.ts:45). Root cause is exact-string coverage in a world where one original message can appear under several id forms (base, base#r0, base#callId); the 762K leak is the symptom. Your layering is right.

Two findings beyond the issue text:

1. The isCovered from closed PR feat: reasoningReplay policy + anchor arg stubs + extraTokens accounting #225 early-returns when the id has no # (hash <= 0), so it misses your primary direction (block recorded sub-ids, view emits plain base). My fix normalizes both sides to the base, so all three combinations are covered, with an O(1) precomputed base set instead of the per-message linear scan.
2. src/sync.ts:72-74 (sync-blocks, which runs before prune in the pipeline) has the same exact-match presence check: in your primary direction it deactivates the block (summary lost) before prune can cover the message — so fixing prune alone would not stop the leak. I'm fixing that site in the same PR.

Other exact-match sites of the same class exist (recommend.ts:53, decompress.ts:21/105/169, compress.ts:1044, boundaries.ts); I'm not touching those here — will file a follow-up issue with source tag listing them.

PR incoming.

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 Done — PR: #233

Triage conclusion (per 审核先于实现):

1. Verified, real. Reproduced with 8 new regression tests; 6 failed on master before the fix, in all three ways: block-sub-id/view-base (your primary scenario), block-base/view-sub-id (reverse), and sibling sub-ids of the same base. Negative control confirms no prefix false-positives (h_abcde is not covered by base h_abc).
2. Layering confirmed. Root cause: exact-string membership between block.effectiveMessageIds and current-view ids, in a world where one original message can appear under several id forms. The 762K leak is the symptom.
3. Fix as prescribed, both directions. baseIdOf(id) (base = everything before first #) + isCovered(id, coveredBases) with a precomputed base set — O(1) per message, not the per-message scan PR feat: reasoningReplay policy + anchor arg stubs + extraTokens accounting #225's version used (which also missed your primary direction via its hash <= 0 early-return). Summary anchoring uses the earliest index of the base group, so summaries no longer jump to index 0.
4. Extra fix, same root cause: sync.ts presence check (runs before prune in the pipeline) had the same exact-match and would have deactivated the block — losing the summary — before prune could cover the message. Fixed in the same PR; without it the leak would have persisted.

Verification: 588/588 tests pass, tsc --noEmit clean, tsup build clean.

Follow-up: remaining same-class exact-match sites (recommend.ts:53, decompress.ts:21/105, compress.ts:155/1044, boundaries.ts:259, report.ts:75/93) are latent today (kernel only emits plain base ids) — filed as #234 with source tag, kept out of this PR to stay focused on the leak path.

Awaiting review (repo policy: ≥2 agents) and human merge.