# Release 0.3.9 — Bounded compaction request and operation input

**Version analyzed:** DS4 Context Engine `0.3.9`
**Commit:** (recorded after pack and registry verification)
**Coordinated packages:** `ds4-context-core` 0.3.9, `ds4-context-reference-adapter` 0.3.9, `ds4-context-engine` 0.3.9

## Summary

Hardens custom compaction against request-size and total-operation token spikes.
Every direct-update, segment, aggregate and retry attempt is now bounded by an
effective estimated-input limit. A second cumulative budget covers the complete
compaction operation, including concurrent work and transport retries.

The default compaction input budget changes from the summary hard limit to the
ordinary context-fill budget. The former behavior remains available explicitly
for users who accept larger provider requests in exchange for fewer hierarchy
levels.

## Changes

- Added `compaction.maxRequestInputTokens`, default 64,000, as a hard ceiling on
  estimated input for each compaction provider request. The effective ceiling is
  the minimum of this setting and the selected model-aware compaction budget.
- Added `compaction.maxOperationInputTokens`, default 2,000,000, for cumulative
  estimated input across the complete operation. Every accepted attempt reserves
  its input before provider dispatch, so retries and concurrent segments count.
- Configuration validation requires both limits to be positive integers and the
  operation limit to be at least the configured request limit.
- Changed the default `compaction.inputBudget` from `summary` to `context`.
  Explicit `summary` configurations retain the previous calibrated-hard-limit
  behavior.
- Changed the default `compaction.transport.maxAttempts` from 3 to 4. Attempts
  remain covered by the cumulative operation budget.
- Segment partitioning now uses the minimum of `segmentTargetTokens` and the
  effective request limit. An indivisible message or complete tool exchange that
  cannot fit fails closed to Pi's native compaction.
- `/context compaction` reports the effective request limit and cumulative
  operation input consumed.
- Direct update, segment and aggregate paths continue to use strict validation,
  privacy filtering, immutable provenance and all-or-nothing graph installation.

## Validation

Before publication, the coordinated release passed:

- TypeScript builds and typecheck for the root, core and reference adapter;
- 85 Vitest files with 561 tests;
- deterministic context-quality comparison;
- context-persistence schema measurement;
- clean-consumer package verification for all three tarballs;
- whitespace/error-marker checks and coordinated manifest inspection.

The package verifier also checks the new defaults and both input-budget modes
from the packed `ds4-context-core` artifact.

## Compatibility and migration

- No SQLite migration: schema 16 remains current.
- No Pi, runtime-adapter, history, persistence-tool or summary-contract version
  changes.
- Existing configurations that explicitly set `inputBudget` or transport retry
  attempts retain those values.
- New limit fields are additive. Configurations that omit them receive the
  documented defaults.
- Pi JSONL remains canonical and custom-compaction failure still delegates to
  Pi's native fallback without installing a partial Summary Graph.
- A full Pi restart is required after upgrading so compiled core modules and
  session configuration are reloaded.

## Known limits

- If the current request, fixed overhead or another mandatory atomic group is
  itself above the planner hard limit, fail-open context planning preserves the
  native context; DS4 cannot transparently split an in-flight Pi tool loop.
- Provider work accepted before a concurrent sibling fails may still be billed,
  even though DS4 aborts and awaits all started workers before fallback.
- Limits use DS4's calibrated token estimator. Provider-side tokenization and
  billing remain authoritative.
- Mock-provider tests establish bounded scheduling and request accounting, not
  real-provider latency or semantic-equivalence guarantees.