User-facing repro:
* In YOLO mode at low context utilisation (~5%), the engine briefly
showed `resetting plan` in the footer and the transcript area went
mostly black. Tools kept running (Plan panel + sidebar still
rendered), but the chat history above the latest turn was gone.
Root cause: the capacity controller's `VerifyAndReplan` action
(`crates/tui/src/core/engine/capacity_flow.rs::apply_verify_and_replan`)
runs `self.session.messages.clear()` and rebuilds from the canonical
state. The capacity controller fires this when its slack-based
`p_fail` calculation crosses the high-severe band — independently of
the `auto_compact` setting, independently of token utilisation.
The user opted out of auto-compaction in v0.8.11 (default
`auto_compact = false`, #665), explicitly trusting the model with
the full 1M-token V4 window. Auto-managing the prefix on their
behalf via the capacity controller contradicts that posture and
silently destroys both the user-visible transcript and V4's prefix
cache.
The fix
=======
Flip `CapacityControllerConfig::default().enabled` from `true` to
`false`. The controller's `observe_*` and `decide` methods already
short-circuit when `enabled` is false (`capacity.rs:255`,
`capacity.rs:396`), so the existing wiring becomes a no-op for the
default config — no need for defensive gating in
`capacity_flow.rs`.
Power users who want the controller can opt in via
`capacity.enabled = true` in `~/.deepseek/config.toml`. The slack
heuristics, model priors, cooldowns, and intervention paths all
remain in the codebase, ready to re-engage on opt-in. Nothing
deleted.
Tests
=====
* `default_controller_is_disabled_and_skips_observations` — pins
the new default; `observe_pre_turn` returns `None`.
* `opt_in_controller_observes_and_decides` — confirms `enabled =
true` rearms the controller end-to-end.
* `app_config_without_capacity_uses_default_disabled` — pins that
loading a config with no `[capacity]` section produces
`enabled = false`.
* `capacity_disabled_by_default_keeps_messages_intact` — direct
regression for the user-reported symptom: with default config,
even a forced error-escalation checkpoint cannot trigger
`messages.clear()`. Asserts the transcript length is preserved.
Verified locally:
* `cargo fmt --all -- --check` clean.
* `cargo clippy --workspace --all-targets --all-features --locked
-- -D warnings` clean.
* `cargo test --workspace --all-features --locked` — 2039 passed,
2 ignored, 0 failed (one flake on `snapshot::repo::tests::
restore_removes_files_added_after_target_snapshot` was filesystem-
timing-dependent, passes on isolation re-run; unrelated to this
change).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Hunter Bown
1131e7a7b0