Historian never compresses a single-prompt session: stale-snapshot refresh drops liftLivePromptFloor #795

Short description

In a session with a single user prompt, the historian fires from the execute threshold and then no-ops every time. It never compresses until the 85% force band, because the stale-snapshot refresh drops liftLivePromptFloor.

What happened?

Setup: OpenCode 2.1.4 TUI with a local llama.cpp model (262K context, contextLimit=245760). The historian runs on a separate no-thinking alias, with execute_threshold_percentage at the default 65%. The session is a long autonomous run: one user prompt, then about 130 agent steps (37K → 201K tokens).

Observed: below the threshold, the trigger refuses (no eligible head (live-prompt floor at 1)), which is expected. From 65.6% it alternates on every other step: the floor mark is set, then consumed, the trigger fires, and the historian no-ops:

compartment trigger: not firing at 64.9% — no eligible head (live-prompt floor at 1); offset=1 protectedStart=1 eligibleEnd=1 rawTokens=0 chunkTokens=0
compartment trigger: live-prompt floor mark consumed at 1
compartment trigger: proactive fire at 65.6% (floor=63% projected post-drop=none target=48.8%)
compartment trigger: firing (reason=projected_headroom)
transform: compartmentInProgress flag set, starting agent
historian no-op: stale protected-tail snapshot (raw range fingerprint changed)
compartment trigger: live-prompt floor mark set at 1
compartment trigger: not firing at 65.7% — no eligible head (live-prompt floor at 1); offset=1 protectedStart=1 eligibleEnd=1 rawTokens=0 chunkTokens=0
compartment trigger: live-prompt floor mark consumed at 1
compartment trigger: proactive fire at 65.9% (...)
historian no-op: stale protected-tail snapshot (raw range fingerprint changed)

• No compaction: there were 17 no-ops between 65.6% and 81.8%. No historian request ever reached the model, and no compartment was written.
• No other reclaim either: heuristics logged transform: skipping heuristics (already ran for turn …) on every execute pass, because the turn never changes. So nothing reclaimed context between 65% and 85%.
• Only a manual /compact helped. At 81.8% it rode a hard fold and cleared reasoning (201K → 151K), but the compaction summary was an empty <session-history></session-history>.

Root cause (master a5c0299)

1. The trigger lifts the floor. compartment-trigger.ts consumes the live-prompt floor mark and recomputes the tail with liftLivePromptFloor: true, so the trigger's snapshot does have an eligible head.
2. The stale-snapshot refresh drops the lift. In compartment-runner-incremental.ts (~L528-552), when that snapshot fails validation as stale_snapshot, the runner rebuilds it with resolveOpenCodeProtectedTailBoundary({ mode: "incremental-runner", … }), without liftLivePromptFloor.
   • Below the force band, resolveProtectedTailBoundary in protected-tail-boundary.ts (~L730-744) then clamps protectedTailStart to the last meaningful user ordinal.
   • In a one-prompt session that ordinal is 1, so hasRunnableCompartmentWindow(refreshed) is false and the run no-ops.
3. The snapshot can't carry the lift. ProtectedTailBoundarySnapshot doesn't record whether the floor was lifted, so the runner has no way to lift it again.

I didn't pin down why the snapshot is stale on every attempt, possibly the in-memory-primed tail at trigger time against the DB read during validation. The refresh is the path that's meant to recover from that.

packages/pi-plugin/src/pi-historian-runner.ts has the same refresh shape and probably needs the same change.

Fix

--- a/packages/plugin/src/hooks/magic-context/protected-tail-boundary.ts
+++ b/packages/plugin/src/hooks/magic-context/protected-tail-boundary.ts
@@ export interface ProtectedTailBoundarySnapshot {
     emergencyTailScale?: 0.5 | 0.25;
+    /** The trigger lifted the live-prompt floor (execute-threshold reclaim); a run-time refresh must lift it too. */
+    liftLivePromptFloor?: boolean;
@@ resolveProtectedTailBoundary: returned snapshot (~L811)
         emergencyTailScale: ctx.emergencyTailScale,
+        liftLivePromptFloor: ctx.liftLivePromptFloor === true,
--- a/packages/plugin/src/hooks/magic-context/compartment-runner-incremental.ts
+++ b/packages/plugin/src/hooks/magic-context/compartment-runner-incremental.ts
@@ stale_snapshot refresh (~L541)
                       usageSource: boundarySnapshot.usageSource,
                       emergencyTailScale: boundarySnapshot.emergencyTailScale,
+                      liftLivePromptFloor: boundarySnapshot.liftLivePromptFloor === true,
                   });

Verified with this patch applied to the 0.49.23 dist, in the same session after a restart at 64.4%:

compartment trigger: proactive fire at 64.4% (floor=63% projected post-drop=none target=48.8%)
historian: refreshed stale protected-tail snapshot at run time (was: raw range fingerprint changed) — eligible head 1-10
historian publish completed: compartments=1 range=1-10
compartment agent: queued 27 drops for messages 1-10
historian: refreshed stale protected-tail snapshot at run time (was: raw range fingerprint changed) — eligible head 11-46

The historian now runs incrementally inside the single prompt instead of no-opping.

A test that would catch this: a one-user-message session above the execute threshold, where the trigger's snapshot is made stale (for example, by appending a message before the runner validates). The runner should refresh to a runnable window and write a compartment, instead of logging historian no-op: stale protected-tail snapshot.

Plugin version

0.49.23 (the bug is also present on master a5c0299)

OpenCode version

2.1.4

Platform

linux x64

Client

OpenCode TUI (CLI)