# Execution

Execution mode: one session runs a long series of plans (a program of waves, or several plans in parallel) through to merge without waiting on a person between them. This rule sets the practices that keep that run from going brittle. A single plan's own lifecycle (its gate, its ledgers, its freeze) stays with the plan, the `testing` skill and the `boundary` skill. This rule governs only what a run of many plans adds on top of that.

## The execution log

**Every run keeps one execution log at `docs/history/executions/YYYY-MM-DD-{slug}.md`.** It is the run's whole memory. A session that has lost the conversation (to a compaction, a new sitting or a crash) re-anchors by reading it first, so nothing the run still needs may live only in context.

- **It holds:**
  - the plans and waves, each with its status;
  - what is in flight (each dispatch's goal, budget and progress-file path);
  - decisions taken mid-run, with their reasons;
  - the standing constraints of the run;
  - the owner's pending steps;
  - the close: what remains, in order, until the run ends.
- **It is written at every milestone:** before each dispatch, at each plan freeze and merge, and at each owner step discovered. It is never written after the fact from memory.
- **It is a record.** It stays amendable while the run is open and is frozen when the run closes.

## Sub-agents

- **Every brief carries a contract:**
  - the result that ends it;
  - its milestones, in order;
  - a wall-clock budget derived from the work: n browser tests take about n × 10 s, and a build step gets its last run's time plus 50%.

  A sub-agent past its budget stops and reports what it has, with the blocker named. The budget limits itself; nothing outside the sub-agent has to enforce it.
- **Progress goes to a file:** one line per milestone in `/tmp/<task>-progress.log`, in the form `<UTC time> <milestone> started|done|stuck — <result>`. A line is written before and after anything expected to run past two minutes.
- **No alarms, monitors or watchers.** The main session learns a sub-agent's state from its completion notification and from its progress file, read at the main session's own turn breaks. A standing monitor, a polling loop or a scheduled alarm is machinery the run then has to watch too.
- **An overrun is acted on, never waited out.** When a progress file shows a milestone past its budget, the main session checks the transcript, the processes and the logs. It then unblocks the sub-agent, stops it, or takes the step over, and says which. It never silently redoes a sub-agent's work inline.
- **A workflow's sub-agent is never messaged directly.** A message starts a duplicate copy that edits the same files. Fix the shared state instead, or stop the workflow and re-run it.

## Context

- **Plan for the compaction boundary.** Earlier tool results are gone after a compaction, so whatever must survive one goes into a file: the execution log, the plan, a progress log, a changelog draft or memory.
- **Bulky reads go to sub-agents,** so the main context compacts later.
- **Tokens are not the constraint.** A read, check or verification is never trimmed to save tokens. Context capacity is what delegation protects.

## Parallel plans

- **Plans cascade into each other.**
  - Every merge into `dev` moves the base under every open branch, so `dev` is re-merged before CI on an open pull request is trusted.
  - Append-only files (the backlog, changelog entries, memory) conflict on every merge and resolve as a union.
  - The typecheck and the touched suites re-run after every re-merge.
- **Parallel load causes false failures.**
  - A timing-sensitive test or latency measure run while other builds or apps are busy can go red falsely. It is re-run before the result is treated as real.
  - Parallel test runs never rebuild a shared `dist/`; each gets a no-build config.
- **A committed fix is revert-checked in place.** `git stash` cannot revert a fix already committed, so the bite check reverts it with a targeted edit, rebuilds, runs the pin, then restores the fix.