3.5 KiB
RFC: Fold the single compaction backend into its service package
Status: rejected — More compaction backends are planned, so the interface and basic implementation packages remain separate.
English | 中文
Problem
Compaction is split between @deepseek-ai/dsh-compact, which owns an abstract two-method service and shared types, and @deepseek-ai/dsh-compact-basic, which owns the only complete implementation. Shipped configurations load only the basic package, and no production package independently consumes the interface package except that implementation.
The split adds a package manifest, README, project boundary, dependency edge, abstract forwarding class, generated catalog entries, and composition wiring without demonstrating backend substitution. The capability-seam decision requires a real interface, implementation, and consumer rather than a preemptive split; the compaction decision records that its independent consumer was deferred.
Proposal
Move the basic implementation into @deepseek-ai/dsh-compact and remove @deepseek-ai/dsh-compact-basic. Keep ctx.compact, CompactionResult, the shared transcript and tool-pairing helpers, the existing configuration, and the concrete compaction algorithm in one package.
Preserve summarize() as a protected customization hook. A deployment-specific summarizer can subclass or intercept the existing LLM call without requiring a second capability package. Reintroduce an interface package only when a second complete backend and an independent consumer need substitution.
Amend the implemented compaction decision and the recallable-compaction proposal if this proposal is accepted so package ownership has one durable description.
Alternatives considered
Keep the split because a remote or recall backend may arrive. A possible future implementation does not justify the current package boundary. Recall adds a consumer of compaction results, not necessarily another implementation, and a remote summarizer can use the protected hook.
Move the implementation package name onto the interface package. Keeping compact-basic as the surviving name would make the product service appear to be one optional backend. compact is the stable service identity already used by ctx.compact and is the clearer single-package owner.
Acceptance criteria
@deepseek-ai/dsh-compact-basicand its workspace/package metadata are removed.@deepseek-ai/dsh-compactowns the current configuration, plugin class, algorithm, types, events, and shared helpers.- Existing deployments can load the surviving package with equivalent configuration and model-visible behavior.
- Automatic and manual compaction preserve cancellation, locking, token accounting, tool pairing, durable events, provenance, retry convergence, and transcript rendering.
- Loader composition, unit, runaway-turn, cancellation, snapshot, and real-model compaction tests pass; generated catalogs and module graphs are current.
Risks
This is an intentional pre-release package-name contraction. Embedders loading @deepseek-ai/dsh-compact-basic must switch packages, and future backend substitution would require extracting a boundary again. The cost is acceptable only while one complete implementation exists; acceptance should be revisited if a second backend lands first.