.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.
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
Pause the current epic
Set the current epic’s
status to paused in .conductor/state.json.3
Push a frame onto detourStack
Write the stack frame with
pausedEpic, pausedAt, reason, spawnedDetour, and reconcileOnResume: true (default) onto .conductor/state.json’s detourStack[].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
Remove the top frame from
detourStack[] in .conductor/state.json. If reconcileOnResume was true, set reconcileNeeded: true on the paused epic before popping — this is the only place that obligation survives once the frame is gone.3
Restore the paused epic to active
Set the paused epic’s
status back to active and call set-active <paused-id>.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.