[ranxianglei]

Reverts merge commit 4d0b61f (PR #176, released in 0.0.48/0.0.49).

Why revert

PR #176 introduced ref slot recycling: prune byRaw/byRef to view ∪ active-block effectiveMessageIds each turn, plus two reuse paths (wrap-around scan from MIN_INDEX after forward exhaustion; cursor drop via highestUsedIndex(pruned)+1). Maintenance review judged this design unsafe and it contradicts the architecture's own "GC-free" key design principle:

1. Silent decompress misattribution. effectiveMessageIds keeps only anchor ids (observed: a 7-message folded range retained 2). Summary text cites tags (mNNNNN) whose raw ids are NOT anchors and NOT in view → their mappings get pruned → slot freed → a later message reuses the slot → the model decompresses the old tag and receives the WRONG message's content, silently. Wrong content is strictly worse than an error.
2. Reuse is a new risk class. Pre-fix: reclaim dead message refs, reuse exhausted capacity, classify boundary failures (billion-context#386) #176 the map never shrank, so highestUsedIndex+1 was monotonic and slots were never reused; the model could trust any tag it has ever seen. fix: reclaim dead message refs, reuse exhausted capacity, classify boundary failures (billion-context#386) #176 breaks that trust contract for every host.
3. The architectural invariant going forward (recorded in hosts' AGENTS.md): message ids / ref numbers are never reused or duplicated within a session — ever. Capacity is addressed by widening the ref space if ever needed, not by recycling.

Accepted trade-off

The original #386 leak (monotonic growth toward the 99999 cap → allocateFreeRef throw → host-side silent stall) is REOPENED by this revert. That is accepted for now; the proper fix is widening REF_WIDTH (5→7 digits) so monotonic growth can never reach the cap — proposed separately.

Impact

• billion-context pins acp-kernel@0.0.47 (predates fix: reclaim dead message refs, reuse exhausted capacity, classify boundary failures (billion-context#386) #176) — unaffected today; this revert protects the next bump.
• Downstream audit: no consumer depends on pruneDeadRefs or reuse semantics (checked billion-context, billion-context-pi).

Verification

• npm run typecheck ✓
• npm test 558/558 ✓
• grep -rn pruneDeadRefs src/ tests/ → empty; refs.ts wrap-around removed

Merge needs 2-agent review per AGENTS.md; human merges.

[github-actions]

📦 Built Package Artifact

Branch: 2026-09-03_revert-ref-reclamation (e8081c8)

Option A — Install from npm PR tag (recommended)

In your adapter project:

npm install acp-kernel@pr-191

Each push to this PR publishes a new version under the pr-191 npm tag.

Option B — Download artifact

1. Download the artifact from the Actions run
2. Extract the tarball and install:

tar xzf acp-kernel-pr191.tgz
npm install ./package

---

This comment is automatically updated on each push.

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 Agent review 1/2 — VERIFIED ✅ (LGTM to merge)

I checked out the PR commit (e8081c8) and independently re-ran every check rather than trusting the summary. Details below. Not merging — human-only per AGENTS.md.

Revert correctness (this is the load-bearing question for a revert)

• Exact mirror. Original fix: reclaim dead message refs, reuse exhausted capacity, classify boundary failures (billion-context#386) #176 (54d45b7) was 8 files, 614+/47−; this revert is the precise inverse 8 files, 47+/614−, same files.
• Byte-level restoration. Compared each reverted file against the pre-fix: reclaim dead message refs, reuse exhausted capacity, classify boundary failures (billion-context#386) #176 state (fa38292, parent of fix: reclaim dead message refs, reuse exhausted capacity, classify boundary failures (billion-context#386) #176's code commit): boundaries.ts, compress.ts, rebuild.ts, refs.ts, sync.ts, compress.test.ts are all byte-identical to pre-fix: reclaim dead message refs, reuse exhausted capacity, classify boundary failures (billion-context#386) #176. Only index.ts differs — and solely because the later, unrelated handoff renderer (feat: add session handoff renderer (renderHandoff/renderMessage/matchSession) #183) added its exports there; those are correctly preserved, no reclamation export leaked through or was dropped.
• No dangling references. grep pruneDeadRefs|PruneDeadRefsResult|BoundaryFailureReason across src/+tests/ → empty. The 476-line tests/ref-reclamation.test.ts added by fix: reclaim dead message refs, reuse exhausted capacity, classify boundary failures (billion-context#386) #176 is deleted. The coupled "classify boundary failures" work in boundaries.ts (the reason field + "ref released when content id changed" wording) is correctly removed too — that classification only made sense with reclamation.
• No accidental behavior beyond the inverse: applyCompression goes back from syncBlocks(...).state to a plain cloneState(...), and cloneState is restored as a used helper (not dead code).

CI gates (all green on the PR commit, real Node v22)

• npm run typecheck → exit 0
• npm test → 558/558 pass, exit 0 (matches your claim exactly)
• npm run build (tsup + tsc emitDeclarationOnly) → exit 0
• Formatting: for every file this PR touches, master and the PR have identical prettier state → this PR introduces zero formatting regressions. (The repo-wide format:check failure is pre-existing and not a release-CI gate.)

Safety argument — I agree, and here's why there's no cheaper fix

Confirmed the mechanism in code: sync.ts pruned byRaw/byRef down to view ∪ active-block effectiveMessageIds, and allocateFreeRef gained a wrap-around second scan (MIN_INDEX→from) after forward exhaustion. Since effectiveMessageIds retains only anchor ids, a summary citing a non-anchor tag has its mapping pruned → slot freed → reused by a later message → the model decompresses an old tag and silently gets the wrong message. Because tags are opaque strings the model copies verbatim, there is no session registry tying a cited tag to its generation — so any reuse path is inherently misattributable. The only correct fix is making tags unique-for-the-session (never reuse), which is exactly this invariant. Reverting is right; recycling was a new risk class with no safe mitigation short of global uniqueness.

Accepted trade-off — accurately characterized

Confirmed REF_WIDTH = 5, MAX_INDEX = 99999, with the allocateFreeRef throw at src/refs.ts:99. So reopening the monotonic-growth-toward-cap leak (#386) is real but bounded (hosts currently pin 0.0.47, which predates #176 — verified in history). Widening REF_WIDTH 5→7 (~10M slots) is the correct forward capacity fix.

One heads-up for the follow-up REF_WIDTH PR (non-blocking here)

Widening 5→7 digits changes the tag format width. Any host-side parsing that assumes a fixed m\d{5} (regexes, length checks) must be updated in the same change as the constant, or hosts will fail to parse 7-digit tags. Worth calling out explicitly in that PR's scope.

Verdict: clean, complete, well-scoped revert; all CI gates green; no regressions. Approving as agent review 1/2.