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