[Bug] /compact says a compaction is active when the agent is simply mid-turn

[Kunstderfug]

Summary. A manual /compact that arrives while the agent is still finishing a turn is refused with a message that names the wrong cause — and the error classification makes the two cases indistinguishable for every consumer, not just /compact.

Found on DSH Desktop (harness 0.1.2-rc.1). The same code path is still present on master, so I'm reporting it rather than assuming it is known.

What the user sees

Compaction is unavailable because this process has an active compaction, or the agent is not idle.

That is the single busy arm of expectedFailure in packages/compaction/command-compact/src/index.ts:29.

Why the message is wrong for this case. The refusal users actually hit is the agent loop rejecting the maintenance claim:

// packages/core/agent-loop/src/agent.ts:158
if (this.phase.kind !== 'idle') throw new Error(`agent "${this.id}" already has active work`)

compactNow catches everything and reports one code for all of it:

// packages/compaction/compaction-basic/src/index.ts:414
} catch (error: unknown) {
  throw new ManualCompactionError(
    'busy',
    'manual compaction requires an idle agent with no waking queued work',
    { cause: error },
  )
}

So "another compaction is in progress" (what the copy leads with), "the agent is not idle" (vague, but the real cause), a live unmatched bracket, and an unavailable admission all arrive as busy. The message leads with the case a user is least likely to have hit.

Evidence from a real session log (session.jsonl.zstd, ts in epoch ms):

event	ts	delta
last step/end of the answered turn	1789070593953	—
command/run compact	1789070596493	+2.5 s
command/done kind=error	1789070596498	+5 ms
next turn/start	1789070640640	+45 s

The refusal landed 2.5 s after the turn's final step and 45 s before the next turn began: phase.kind was still running. Worth adding why the user thought the agent was idle — agent/turn-stopping hooks (title generation) run before turn/end, so the response visibly ends tens of seconds before the phase does. That window is exactly when someone reaches for /compact, and exactly when the message is wrong.

Suggested change. Classify at the boundary, then let each consumer name its own cause:

function isAgentWorkingError(error: unknown): boolean {
  return /already has active work$/u.test(errorMessage(error))
}

// in compactNow's catch
if (isAgentWorkingError(error)) {
  throw new ManualCompactionError(
    'agent-busy',
    'manual compaction did not start: the agent was still working',
    { cause: error },
  )
}
throw new ManualCompactionError(/* existing busy */)

command-compact gains an agent-busy arm — "the agent is still working on this session. Wait for the turn to finish, then run /compact again." — and busy narrows to the claim conflicts it already describes.

Tests that currently encode the conflation (these need updating, not just adding alongside):

• packages/compaction/compaction-basic/tests/manual-compaction.spec.ts:213 — the fake agent throws the agent-loop string verbatim: if (release === undefined) throw new Error('agent already has active work'). The testkit comment calls it "a fake idle agent whose maintenance claim is scripted per test", so the string is effectively a contract.
• …/manual-compaction.spec.ts:345 — reports busy without summarizing when a prompt already owns the next turn, asserting code === 'busy' at :354; also the cases at :710 ({ name: 'busy', …, release: undefined }) and :884.
• packages/compaction/command-compact/tests/command-compact.spec.ts:209 — pins the current user-facing string in a table.

Working implementation, if useful. I implemented this against the 0.1.2-rc.1 published artifacts, shipped it in our desktop shell, and added a test pinning the classifier, both refusal messages, and the patch: dataelement/dsh-desktop#381

Out of scope / open question. This fixes only the diagnosis — /compact still will not start mid-turn. Making it wait for idle changes runMaintenance semantics for every maintenance caller (the scheduler currently defers when the claim is busy), so it reads like a separate product decision. Which direction would you prefer?

[PerryLink]

Confirmed against master (c291e79) — every claim checks out and nothing has changed:

• The agent loop refuses the maintenance claim while any phase is active: packages/core/agent-loop/src/agent.ts:157-158 (agent "${id}" already has active work).
• compactNow catches everything and relabels it: packages/compaction/compaction-basic/src/index.ts:414-419 → ManualCompactionError('busy', 'manual compaction requires an idle agent with no waking queued work', { cause }).
• The command maps that one code to the one message: packages/compaction/command-compact/src/index.ts:24-30 — "Compaction is unavailable because this process has an active compaction, or the agent is not idle."

So an active compaction, a mid-turn agent (including the post-response window while turn-stopping hooks such as title generation still run — your log's 2.5 s / 45 s split is consistent with that), an unmatched bracket, and admission failures all collapse into busy, and the message leads with the least likely cause. It is a diagnosis conflation, not user error, and it is still live on master.

Practical answer: the refusal itself is correct — compaction genuinely requires an idle agent, the claim is a real exclusion (agent.ts:158) — only the diagnosis is wrong. Workaround: wait until the turn has fully ended (the run indicator clears and title generation finishes) before /compact. If it still says busy, inspect the session log for the actual cause.

Your boundary-classifier direction is sound and cheap to land: the agent.ts:158 string is stable enough that the existing suite already scripts it verbatim (packages/compaction/compaction-basic/tests/manual-compaction.spec.ts:213), so matching it in compactNow's catch and adding an agent-busy arm (with the narrowed copy you proposed) is a minimal, testable change. The open question — whether /compact should queue for idle instead of refusing — changes runMaintenance semantics for every maintenance caller and is a maintainer product decision; it deserves a separate issue from the diagnosis fix.