.conductor/state.json before a single line of detour code is written.
Minimal vs. substantial detours
The first step of/pm:detour is always classification. Do not start fixing before deciding which kind the interruption is.
Minimal detour
Small, self-contained, no design ambiguity. Fits before the next context compaction and doesn’t reshape the current proposal.Path: Fix → test → commit →
log-detour "<what you fixed>" → resume. No stack entry. No proposal. The log call appends a timestamped line + commit SHA to .conductor/detours.log.Substantial detour
Needs its own design, changes shared behavior, or is multi-step.Path: Becomes its own epic in the appropriate lane. Run PUSH. When unsure, treat as substantial — a needless stack entry is cheap; a lost thread is the whole problem PM is solving.
What a stack frame contains
A detour stack frame records everything needed to restore context after the detour is resolved:
The stack is LIFO — the most recent push is always what
/pm:resume pops. Multiple nested detours are supported; each POP restores exactly one level.
Repeated deferral is visible
New in 0.34.0. An epic parked more than once now says so, in the stack block and in the Honcho line:A warning was considered and deliberately not built, and the reason is structural rather than a judgment about thresholds. At the time there was no
push-detour verb: the PUSH was a documented hand-edit, so the engine was not running at the moment a deferral was decided, and a gate needs the engine present at the transition it gates.0.35.0 removed that obstacle — PUSH and POP are verbs now, so a gate has somewhere to live. Whether one is warranted remains open, and limited by the same evidence problem: depth, elapsed time and repeat-count are different phenomena and not equally meaningful, so a threshold over any of them would need data this record does not yet have.Depth, elapsed time, and repeat-count are also different phenomena and not equally meaningful, so a threshold over any of them would be a number the engine cannot support.PUSH: entering a substantial detour
When/pm:detour classifies an interruption as substantial, the following steps run in order:
1
Commit all uncommitted work
Make the current epic’s progress source (e.g.
tasks.md) reflect reality, then commit so nothing is left staged or dirty. The paused epic’s state must be clean before it’s parked.2
Register the detour epic
Pausing the current epic is never a hand-edit:
push-detour below writes status: paused itself, in the same guarded write as the frame. What this step needs is the detour registered as its own epic — the appropriate lane, usually priority P0 — so the PUSH has something to name.3
Push a frame onto detourStack
.conductor/state.json directly — the one mechanism this project tells every agent never to use, at its most consequential transition. None of the engine’s guarantees applied: no validation that the paused epic existed, no conflict guard, no read-back verification, no record it happened.The verb pauses the epic, writes the frame, registers the detour with role: "detour", sets it active and emits the Honcho line — in one guarded write. It refuses an unknown or archived epic and an empty reason, and it makes --reconcile / --no-reconcile an explicit choice rather than a default you can forget.4
Create the detour epic
Register the detour as a new epic with
role: "detour", the appropriate lane, and usually priority P0. Add the cross-links: detour resolves-blocker-for parent; parent may-invalidate detour.5
Set the detour as active
Call
set-active <detour-id>. Build the detour through its lane’s normal workflow and archive it when complete.6
Write a Honcho memory
Get the ready-to-copy memory line and log it durably:This prints
paused <parent> for <reason> and appends a timestamped copy to .conductor/honcho-memories.log. Paste the printed line into your Honcho MCP memory tool call — the engine only formats and logs the string, it never calls Honcho itself.POP: leaving a detour
When the detour epic is archived and/pm:resume runs:
1
Verify the detour is archived
Confirm the detour epic’s status is
archived and its work is committed or deployed. If not, it’s not time to resume — finish the detour first.2
Pop the top frame
reconcileNeeded for any epic with no live frame — so done as two separate writes, the obligation is destroyed by the very heal meant to preserve it. The verb does the frame removal, the reconcileNeeded write and the active-pointer move in one state object and one write.3
Restore the paused epic to active
pop-detour already did this — it resumes the paused epic and moves the active pointer in the same write that removes the frame. Nothing here sets a status by hand; set-active <paused-id> is only needed if the pointer was moved elsewhere in between.4
Run the reconcile gate
If
reconcileOnResume was true, the reconcile gate fires now. A fresh-context review re-reads the paused proposal and diffs what the detour actually shipped. Do not write code until the gate clears. See The Reconcile Gate for the full flow.Honcho integration
Both/pm:detour (PUSH) and /pm:resume (POP) emit a ready-to-copy Honcho memory line via the honcho-memory subcommand:
.conductor/honcho-memories.log. This local log exists precisely because the line needs to be pasted into an actual Honcho MCP tool call — if you forget to paste it, the log is your fallback. The engine only formats and logs; it never calls Honcho itself. This keeps PM squarely on the instruction layer and never the integration layer.
Honcho is valuable here because it lets the detour relationship survive outside this repo — across context compactions, across machines, and across sessions weeks later. The detour stack in .conductor/state.json is the live working set for one project; Honcho is where the relationship goes when it needs to outlive the project’s own context window.