From coordinator
Autonomous backlog execution — gathers all ready work items, builds a compaction-proof flight recorder, executes sequentially without stopping for input, then tails with /update-docs (or /update-docs + hibernate in overnight mode)
npx claudepluginhub oduffy-delphi/coordinator-claude[--hibernate]# Mise-en-Place — Autonomous Backlog Execution Everything in its place before the fire gets lit. This command front-loads all context gathering and sequencing into a compaction-proof flight recorder, then executes the full backlog in a straight shot without stopping for input. The PM authorized the run when they invoked this command. **Core principle:** Prep all context, sequence all items, build the flight recorder — then execute without interruption. Once Phase 5 begins, the EM never pauses to ask a question, offer a choice, or wait for a response. The anti-stall rule is not optional: i...
Everything in its place before the fire gets lit. This command front-loads all context gathering and sequencing into a compaction-proof flight recorder, then executes the full backlog in a straight shot without stopping for input. The PM authorized the run when they invoked this command.
Core principle: Prep all context, sequence all items, build the flight recorder — then execute without interruption. Once Phase 5 begins, the EM never pauses to ask a question, offer a choice, or wait for a response. The anti-stall rule is not optional: if execution stalls mid-run, the tail phase (hibernate) never triggers, leaving the machine running indefinitely.
Announce at start: "Running /mise-en-place — prepping flight recorder, then straight shot through the backlog."
Parse $ARGUMENTS for the tail mode:
| Trigger | Mode | Tail action |
|---|---|---|
| No arguments, or no hibernate keyword | Standard (default) | /update-docs — sync docs, commit, push to branch |
--hibernate, or keywords: "overnight", "hibernate", "shutdown", "go to bed" | Hibernate | /update-docs + push + hibernate PC |
Default to standard. If the PM didn't specify hibernate, run standard and move on. Do not ask — the PM can invoke /workday-complete separately afterward.
Follow all six phases in order. The pipeline definition at pipelines/mise-en-place/PIPELINE.md is the authoritative source. This command codifies its orchestration.
Gather every ready-to-execute work item. Sources to check:
tasks/*/todo.md — items marked ready/pending execution$ARGUMENTS names specific items (e.g., "PX4-6B through Cesium-D"), use that as the canonical listtasks/*/ directories with incomplete workFor each item, capture:
The goal is maximum throughput: run as many items concurrently as possible while guaranteeing no two concurrent executors touch the same files.
Step 2a — Dependency sort: Order items by dependency (item B needs item A's output → A before B), then by complexity (smaller first to build momentum, unless dependencies dictate otherwise).
Step 2b — File-overlap analysis: For each item, read its spec and identify the file footprint — the set of files it will create, modify, or read-then-write. Focus on write targets. Items whose specs name the same files (or the same directories in a "touch everything in this dir" pattern) have overlapping footprints.
Step 2c — Build parallel batches (waves): Group items into execution waves:
If every item overlaps (e.g., they all touch the same config file), the result is N sequential waves of 1. That's fine.
Step 2d — Identify risks:
No worktrees. Ever. Worktree creation, branch management, and merge conflict resolution cost more than they save at agent execution speed. The file-disjoint constraint is the coordination mechanism. If an item can't be made file-disjoint, it runs in a later wave.
This is the critical step. Build a task list (TaskCreate) that persists through context compaction and allows the run to continue without re-reading everything.
Create tasks with this structure:
Goal task — titled with the full scope of the run, including:
/update-docs) or hibernate (/update-docs + hibernate)Per-item tasks — one for each work item, with:
TaskUpdate metadata field tried_and_abandoned. Format: "Tried: [approach] — Failed: [reason]". One line per attempt. Persists through compaction; prevents post-compaction repetition.)pendingTail tasks (based on mode):
pendingpending, then "Hibernate PC" — pendingThe flight recorder must contain enough context to resume cold. After compaction, you may have lost the conversation but the task list survives. Write it like a handoff to a stranger.
Anti-amnesia rule: If you abandon an approach during execution, update the task's metadata.tried_and_abandoned field via TaskUpdate to include what you tried and why it failed BEFORE trying something new. After compaction, always read task metadata and descriptions (TaskGet) for "Tried and abandoned" notes before starting work — never retry a recorded-failed approach.
Output this plan to the PM, then IMMEDIATELY begin Phase 5. Do NOT wait for a response.
## Mise-en-Place — Ready to Fire
**Items queued:** [N items] across [M waves]
**Wave 1** (parallel): [items] — file-disjoint ✓
**Wave 2** (parallel): [items] — depends on Wave 1
[... or "Wave 1 (sequential): [items] — all items overlap on [file]"]
**Risks:** [any dependency or risk notes]
**Tail:** /update-docs — straight shot, work stays on branch.
[or: /update-docs + hibernate — overnight run, work stays on branch.]
**Estimated scope:** [rough sense of the run — "3 small items + 1 medium" etc.]
Proceeding.
The tail line is the EM's confirmation of mode — stated declaratively, not as a question. This is a launch announcement, not a proposal. The PM may already be away from the terminal. Do not frame it as "Ready to execute — shall I proceed?" Just output the announcement and start Phase 5.
Signal autonomous mode: Before executing the first item, write the autonomous-run sentinel so the context pressure hook knows not to nudge /handoff:
echo "mise-en-place" > /tmp/autonomous-run-${SESSION_ID}
This tells the hook to emit informational-only context pressure messages (no handoff recommendation). The sentinel is cleaned up in Phase 6.
Execute wave by wave. Each wave from Phase 2 is a batch of file-disjoint items.
For each wave:
Dispatch all items in the wave concurrently. For each item:
in_progress via TaskUpdate. Update the plan document status if applicable. Run the canonical tracker sweep — grep for the item's codename across docs/project-tracker.md, tasks/*/todo.md, and roadmap files. Mark every match as "in progress."run_in_background: true. The prompt must include: the full spec (or path to it), the item's file footprint from Phase 2, and an explicit constraint: "You MUST NOT create or modify any file outside this footprint: [list]. If you discover you need to, STOP and report back."Process completions as they arrive. As each background agent completes:
coordinator:verification-before-completion — evidence before claims.## Acceptance Criteria, read the criteria and confirm each was implemented.git diff --name-only against the declared footprint. File footprint violations are bugs in the parallelism plan, not just agent misbehavior — if an agent needed a file outside its footprint, the Phase 2 analysis missed a dependency.Wave gate: ALL items in a wave must complete before the next wave begins. This is the serialization point that guarantees later-wave items see earlier-wave changes.
Brief status update between waves: "Wave N complete ([items]). Firing wave N+1 ([items])." Output-only — never frame as a question, never wait for a response. Never output:
Single-item waves (forced sequential due to file overlap or dependencies) execute inline — dispatch overhead isn't worth it for one item. Follow the same write-ahead → execute → verify → commit → mark-complete cycle.
Dispatch model: Enriched specs with code sketches are blueprints — Sonnet follows them; Opus judgment was already spent during enrichment+review. See /delegate-execution Phase 2 for the full model selection rubric. The coordinator's job during execution is verification and wave gating, not typing code.
No worktrees. All executors operate on the same worktree. The file-disjoint constraint from Phase 2 is the coordination mechanism. Do not use isolation: "worktree" on any executor dispatch.
After all waves are executed and verified, mark all item tasks completed via TaskUpdate, clean up the autonomous-run sentinel, then run the final tracker sweep before the tail action:
rm -f /tmp/autonomous-run-${SESSION_ID}
Final tracker sweep (mandatory before tail):
Before invoking /update-docs, verify that ALL canonical trackers reflect the run's outcomes. This is the EM's backstop — especially critical because nobody is watching during autonomous runs:
docs/project-tracker.md, tasks/*/todo.md, ROADMAP.md, and any dispatch trackers/update-docsThis sweep is the difference between "work got done" and "the project knows work got done." /update-docs will cascade tactical completions upward via tracker-maintenance, but only if the tactical trackers are accurate.
Standard (default):
/update-docs — sync documentation, commit, push to branch/workday-complete separately when ready to merge.Hibernate:
/update-docs --no-distill — sync documentation, commit, push to branch. Skip distillation in overnight mode — it requires PM approval and nobody is home.# Windows
shutdown /h
# Linux/Mac
systemctl hibernate
Hibernate over shutdown: same zero power draw, but the machine resumes to its prior state instead of cold-booting.
If /update-docs fails in hibernate mode: Hibernate anyway. Item-level commits from Phase 5 already preserved the work. Doc sync is nice-to-have; power conservation is the priority. The PM can run /update-docs after wake.
/merge-to-main or /workday-complete.$ARGUMENTS, never escalated unilaterally.Stop and report when:
Do NOT stop for:
If you must stop early:
| Situation | Action |
|---|---|
| Item spec ambiguous at multiple decision points | Stop early (see above) |
| Verification fails with a fixable error | Fix and continue — do not escalate |
| Verification fails structurally | Stop early, commit progress |
| Dispatched executor returns BLOCKED | Diagnose — if spec-fixable, update stub and re-dispatch; if architectural, stop early and report |
| Executor writes outside its file footprint | Bug in Phase 2 analysis — revert the out-of-bounds changes, re-analyze the overlap, adjust wave assignments, and re-execute |
/update-docs fails in standard mode | Report the failure, leave work on branch |
/update-docs fails in hibernate mode | Hibernate anyway — item commits already pushed |
| Push fails before hibernate | Do NOT hibernate — work must be on remote first. Stop and report. |
| Context compacted mid-run | Read goal task and per-item tasks via TaskList/TaskGet to re-orient; check metadata.tried_and_abandoned; continue from in_progress item |
/delegate-execution — used within Phase 5 for dispatching executor agents; its Phase 2 model selection rubric governs dispatch decisions/update-docs — the tail action in both modes; invoked at Phase 6/workday-complete — what the PM runs afterward (interactively) if they want end-of-day consolidation and health survey/merge-to-main — what the PM runs when ready to merge the branch; never invoked from this commandpipelines/mise-en-place/PIPELINE.md — the pipeline definition this command executes; consult it for full nuance on any phase