/long-run

name: long-run
description: Orchestrates multi-day execution of complex tasks through milestones. Each milestone goes through plan-crafting, run-plan (worker-validator), and review-work phases with checkpoint/recovery. Runs autonomously end-to-end — no per-milestone approval gates; escalates to the user only on failures. Triggers when the user says "long run", "start long run", "execute milestones", or "run all milestones".

Long Run Harness

Orchestrates multi-day execution of complex tasks through a milestone pipeline. Each milestone passes through plan-crafting → run-plan → review-work with checkpoints between milestones for recovery from interruptions.

Core Principle

Long-running execution must be **resumable, auditable, and fail-safe.** Every state transition is persisted to disk before the next action begins. If execution stops for any reason — rate limit, crash, user pause, context loss — it can resume from the last checkpoint without repeating completed work.

Hard Gates

1. **Milestones must exist before execution.** Either from `milestone-planning` skill or user-provided. Never generate milestones inline during execution. 2. **State file must be updated before and after every milestone.** No in-memory-only state. If it's not on disk, it didn't happen. 3. **Each milestone must complete the full pipeline.** plan-crafting → run-plan → review-work. No shortcuts. No skipping review-work "because it looked fine." 4. **Failed milestones block dependents.** If M2 depends on M1 and M1 fails review, M2 does not start. Period. 5. **Autonomous by default — no approval gates between milestones.** The user approved the milestone plan once, at milestone-planning's lock. From then on, milestones proceed plan → run → review → checkpoint without pausing for confirmation. Stop and ask ONLY when: a milestone exhausts its retry budget (`failed`), Mid-Execution Correction requires a scope decision, integration escalation triggers, or loaded state is inconsistent. Post a brief status report at each phase transition so the user can interrupt anytime — state files make every pause resumable. 6. **Never modify completed milestones.** Once a milestone passes review-work, its files are locked. If a later milestone needs changes to earlier work, that is a new milestone. 7. **Checkpoint after every milestone completion.** Write a checkpoint file recording what was done, test results, and review verdict before proceeding.

When To Use

• After `milestone-planning` has produced a milestone DAG
• When the user says "long run", "start long run", "execute milestones", or "run all milestones"
• When resuming a previously paused long run session

When NOT To Use

• When milestones don't exist yet (use `milestone-planning` first)
• When there's only one milestone (use plan-crafting + run-plan directly)
• For quick tasks that don't warrant multi-phase execution

Input

1. **Harness state directory path** — e.g., `docs/engineering-discipline/harness/<session-slug>/` 2. The directory must contain `state.md` and `milestones/*.md` files

If no state directory exists, ask the user if they want to run `milestone-planning` first.

Process

Phase 1: Load and Validate State

1. Read `state.md` from the harness directory 2. Read all milestone files from `milestones/` 3. Validate:

• All milestones referenced in state.md have corresponding files
• Dependency DAG is valid (no cycles, topological sort possible)
• No milestone is in an invalid state (e.g., "executing" without a plan file)

4. Determine current position:

• Which milestones are completed?
• Which milestones are ready to start (all dependencies met)?
• Is this a fresh start or a resume?

5. Present status to the user:

## Long Run Status: [Session Name]

**Progress:** N/M milestones completed
**Current phase:** [planning M3 | executing M3 | reviewing M3 | ready to start M3]
**Next up:** [M3, M4 (parallel)]

Completed: M1 ✓, M2 ✓
In progress: M3 (executing)
Pending: M4, M5

6. If the loaded state is consistent, proceed immediately — the status display is a report, not a gate. Ask the user only if validation in step 3 found inconsistencies or a `failed` milestone blocks the path forward.

Phase 2: Milestone Execution Loop

For each milestone in topological order:

┌─────────────────────────────────────┐
│         Milestone Pipeline          │
│                                     │
│  ┌──────────┐    ┌─────────┐        │
│  │  Plan    │───→│  Run    │        │
│  │ Crafting │    │  Plan   │        │
│  └──────────┘    └────┬────┘        │
│                       │             │
│                  ┌────▼────┐        │
│                  │ Review  │        │
│                  │  Work   │        │
│                  └────┬────┘        │
│                       │             │
│              ┌────────▼────────┐    │
│              │   PASS?         │    │
│              │  Yes → checkpoint│    │
│              │  No  → retry    │    │
│              └─────────────────┘    │
└─────────────────────────────────────┘

Step 2-1: Gate Check

Before starting a milestone:

1. Verify all dependency milestones have status `completed` 2. Verify no file conflicts with in-progress parallel milestones 3. Update state.md: set milestone status to `planning` 4. Update execution log with timestamp

Step 2-2: Plan Crafting Phase

1. Compose a Context Brief from the milestone definition:

• Goal → from milestone file
• Scope → files affected from milestone file
• Success Criteria → from milestone file
• Constraints → inherited from the parent problem + completed milestone context
• **Completed milestone context contract:** From each completed predecessor, include ONLY:
• Files created/modified (from checkpoint's "Files Changed" list)
• Interface contracts established (function signatures, API shapes, type definitions)
• Success criteria that were verified as met
• Do NOT include: e