dsh-compaction-sticky-window

LIMITATIONS

Known limitations

- The model can still under-write. When it does, the note carries only the recorded facts and says no handoff was written; it never fabricates one. - If the model never writes a note, the window holds out until a provider-confirmed overflow forces it. That is deliberate — an unprepared rollover loses state — but it means a model that ignores every notice reaches the hard failure instead of a quiet one. - The note's handoff is read from the whole session, so a note written in the turn that triggers a rollover is still carried. - A single indivisible message larger than the window cannot be repaired by a rollover; the optional tool-result pruner still runs before selection. - The override is a snapshot of `standard` at the targeted DSH release. A DSH upgrade can change that preset without this package noticing; run `sync-preset` and publish a new version. Verified at the targeted release: the restated list has the same 19 top-level plugin ids as the installation. - The override applies to sessions **started after** the bundle is enabled. A session already running keeps the preset it mounted at start, so restart (or open a new session) to pick up the new backend; the tools it already has do not change either way. - Push notices are appended as ordinary `user/message` events with the `sticky-window-notice` source kind. The session format admits extension source kinds, so a log stays readable after the plugin is removed, but an older reader will not know that kind by name. - On a DSH release whose base backend compacts on a **model switch** through a path that bypasses `compactIfNeeded`, that switch can still roll over without the note gate. The targeted 0.2.0 line has no such path; a later line would need this backend to gate it too.