ANATOMY OF A RUN

One run, one directory

Everything a run produces lives in one directory, created at the moment the commission is accepted and named for the day and the task. The spec, the plan, the vetted prompts, the design folder, the state file, the log — all of it, in one place, under the project it serves:

.bureau/runs/20260612-task-slug/
  spec.md        what must be true when this is done
  plan.md        how the Architect intends to get there
  prompts.md     the plan, decomposed into vetted work orders
  design/        briefs and manifests, when the work has a face
  state.json     where things stand — state, not prose
  log.md         everything that happened, in order

The directory is the concurrency mechanism. Two runs on the same repository get two directories and never touch each other's artifacts; the code itself is isolated per-run in its own worktree branch, merged only at close-out. An existing run directory is sticky — a resumed run uses it verbatim, never relocates it. The one rule with no exceptions: an agent writes inside its own run's walls and nowhere else.

The state file — state, not prose

After every phase, the Conductor updates state.json: which phase is active, which are complete, how many critique loops each agent has burned, what decisions were made, what questions remain open. The discipline is in what the file refuses to hold. Values are short labels, lists, and decisions. Anything that needs a paragraph — a migration pattern, a design rationale — goes in the log, and the state file may hold a one-line pointer to it.

Carried items get their own key: the open questions, caveats, and confirm-before-build notes each agent passes forward are copied 1:1 into carried_items — copied, not paraphrased, because a paraphrase is an opportunity to lose the caveat. And the file is validated after every write, because a duplicate key that silently shadows a stale value has bitten real runs before. The rule earned its place.

The log — append-only, after every decision

The log is the run's narrative memory. After every spawn and every adjudication, an entry lands — what came back, what the Conductor decided, and why:

## [14:02] — Spawned Analyst → complete
Handoff: <the agent's returned block, verbatim>

## [14:41] — The Challenger round 1 → 2 blockers, 1 warning
The Conductor's call: blocker 1 (architecture) → fix;
blocker 2 → fix; warning → noted, proceed.
Re-spawning The Architect (loop 1/2) with the two blockers.

Handoffs are pasted verbatim, not summarized. Entries are appended, never edited. The log is where overridden blockers keep their reasons and escalated tiers keep their evidence — the place a later reader goes to learn not just what the run did, but what it almost did.

The index card

Every time the state file changes, the run projects a small card into the studio's index — slug, repository, status, phase, last touched. Seven fields, written atomically, one file per run so concurrent runs never contend. The card is how the studio sees its whole desk at a glance: which runs are moving, which are blocked on a human, and which have gone stale — untouched for four hours, the threshold where the Ministry of Flow starts asking questions.

Status is derived, not declared: a run with no finished phases is not_started; a blocked phase blocks the run; finished phases with more to come is in_progress; close-out makes it complete, and the archive takes it from there. The tokens themselves are defined in Record No. I — The Lexicon.

Why the trail exists

The doctrine on the main floor says knowledge moves through artifacts, never conversation — this record is what that means in practice. A run that crashes mid-phase is resumed by reading its directory, not by reconstructing a chat. A Conductor who was never present can pick up the work, because everything that mattered was written down where the next reader expects it. The paper trail is not overhead on the work. In a bureau of many minds and no shared memory, the paper trail is the work.