[Bug]: finalizeSession() converts "compress-pending" to "active" via truthy check, permanently blocking auto compression

[TachikomaGundam]

Bug Description

Description
After a user manually triggers /dcp-compress, the session's manualMode is permanently set to "active" and persisted to disk. All subsequent automatic compressions are blocked with:
Manual mode: compress blocked. Do not retry until appears in user context.
This only recovers if the user manually runs /dcp manual off — automatic recovery never happens.
Root Cause
lib/compress/pipeline.ts line 88, inside finalizeSession():
ctx.state.manualMode = ctx.state.manualMode ? "active" : false
This truthy check cannot distinguish between "active" (user explicitly enabled manual mode) and "compress-pending" (temporary state from /dcp-compress). Since "compress-pending" is truthy, it is converted to "active".
The chain:

1. User runs /dcp-compress → hooks.ts:242 sets state.manualMode = "compress-pending" (memory only)
2. Model calls compress → pipeline.ts:44-48 allows it (manualMode !== "compress-pending" check passes)
3. Compression succeeds → finalizeSession() runs:

• Line 88: "compress-pending" is truthy → becomes "active" ← bug
• Line 90: saveSessionState() → persistence.ts:92: !!"active" = true → written to disk

4. Every subsequent refreshManualMode() (state.ts:195-208): loads persisted true → "active" → blocks all auto compression
   Proposed Fix

• ctx.state.manualMode = ctx.state.manualMode ? "active" : false

• ctx.state.manualMode = ctx.state.manualMode === "active" ? "active" : false
  This preserves explicit manual mode ("active") while correctly resetting the temporary "compress-pending" state back to false (auto mode) after a manual compression completes.
  Reproduction

1. Start a long session (context growth from team-mode or extended tool use)
2. Run /dcp-compress once
3. Let the model call compress normally on the next nudge
4. Observe: all future automatic compressions are blocked
5. Verify: /plugin/dcp/.json now has "manualMode": true
   Impact
   Any session that uses /dcp-compress at least once gets permanently locked out of automatic compression. In long-running sessions (1000+ messages), this causes context window exhaustion and MAX CONTEXT LIMIT failures.
   Observed in production: two team-mode sessions (1058 and 2259 messages) both hit MAX CONTEXT LIMIT despite the model repeatedly attempting to compress. The user had to manually send /dcp-compress 4 times in one session.
   Environment

• Plugin version: 3.1.14
• OpenCode: latest
• OS: Windows 11 + Ubuntu 26.04 (both affected)
• Models used: Qwen 3.7 Max, Qwen 3.8 Max Preview, Kimi K3, Kimi K2.7 Code

Expected Behavior

DCP remains auto compressing after manually /dcp-compress

Debug Context Logs

N/A — debug: false in config; affected sessions are 2-3 weeks old. Root cause was traced through source code analysis of v3.1.14 (lib/compress/pipeline.ts, lib/state/state.ts, lib/state/persistence.ts). Forensic evidence: DCP persisted state files for both sessions show "manualMode": true despite manualMode.enabled: false in config.

Tool Call Details

No response

DCP Version

3.1.14

Opencode Version

1.18.8

Model

Other (specify in description)

Additional Context

No response