mirror of
https://github.com/teamchong/pxpipe.git
synced 2026-07-22 02:02:51 +02:00
teamchong
8b15525cb9
The history image sits after the slab in prefix order, but the single cache breakpoint was anchored on the slab. So the largest block — the ~141k-token history image — only cached when the caller's roaming downstream marker happened to land after it. When it didn't, the whole history image re-created at the 1.25x cache_create rate every turn instead of amortizing into 0.1x reads. On a warm session that turned a real compression win into a net loss (the "411% more" the dashboard correctly surfaced). Fix is pure relocation: move pxpipe's single breakpoint from the slab onto the LAST history image (which sits after the slab), so slab + history cache as one stable prefix — created once, then read. Marker count is unchanged: pxpipe still never ADDS a marker (Task #21), it only moves the caller's existing one. When no slab imaged, the history path keeps its own relocation. - transform.ts: relocateAnchorToHistoryImage on the collapse-success branch - history.test.ts: two old "history carries no marker" invariants upgraded to assert the relocation (last history image carries it; exactly one marker total)