Skip to content

refactor: reapOrphanBlocks should live in acp-kernel, not the proxy #12

Description

@ranxianglei

Problem

reapOrphanBlocks (src/orphan-gc.ts) deactivates compression blocks whose effectiveMessageIds are no longer present in the visible context. This is block lifecycle / context-management logic — it belongs in acp-kernel, not the proxy adapter.

Currently the proxy:

  • Iterates session.state.blocks (kernel-owned state)
  • Tracks an orphanStreak counter on each block via a WeakMap<object, number> (attaching undocumented state to a foreign type)
  • Calls deactivateBlock on kernel state

This violates the principle: the proxy is a pure adapter (format conversion + stream routing); all compression/context-management logic lives in acp-kernel.

Why it was put here

The kernel had no "reap orphan" capability. When a client (e.g. opencode) deletes history, a block's summary loses its anchor and floats to the top of context as an orphan, polluting the model's view.

Proposed fix

Move the capability into acp-kernel:

// in acp-kernel
core.reapOrphans(state: CompressionState, visible: CoreMessage[]): CompressionState

The kernel already owns state.blocks and effectiveMessageIds — it is the natural owner of this decision. The proxy reduces to a one-liner:

session.state = core.reapOrphans(session.state, visible);

Impact

  • Does NOT affect prefix cache (only deactivates internal summaries; never touches bytes sent to provider).
  • Pure architecture refactor — no behavior change.
  • Not urgent; tracking here for when we next touch acp-kernel.

Related

Removed condenseOldToolResults (PR #11) for the same principle violation.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions