do
Execution
What binds the run
Work toward the manifest's Deliverables in the order listed. Acceptance Criteria and Global Invariants are the binding layer — they are what the run owes, and gates are the only thing that can hold it open. Process Guidance is advisory: recommendations on how to work, weighed rather than enforced, and set aside when the work is better for it — name every departure on whichever terminal path the run takes — completion summary, escalation payload, or pending summary — and in the execution log too when a log is being kept, since advisory only stays safe while departing stays visible. The Initial Approach and the Deliverable order are likewise plan, not contract: pivot either when reality diverges, and name the deviation the same way a departure is named. Resequence when execution changes what the order was built on — a real dependency the order missed, or a shift in which Deliverable is now least proven, since proving the leading approach is exactly what ordering by uncertainty is for. Every judgment the run weighs rather than obeys — departing from Process Guidance, pivoting the Initial Approach, resequencing, choosing what stays below a bar on a terminal path — steers by the manifest's Intent: better than the Problem's baseline story, within the size the Appetite says the problem is worth, comparing down to that baseline rather than up to an ideal.
Running gate evaluations
Resolve execution policy before implementation starts. --verification accepts per-gate, consolidated, or self and defaults to per-gate; after resolving that default, load exactly one matching reference: references/per-gate-verification.md, references/consolidated-verification.md, or references/self-verification.md. The selected reference owns evaluator topology, evaluator provenance, and mode-specific evidence wording for completion and unattended backstops. --verifier-model <model> is optional and applies to the independent modes: when supplied, use it for every verifier execution and reject the policy before work if the active host cannot honor that selector; when omitted, verifier executions inherit the invoking context's model choice. The selected mode, the verifier-model provenance, and whether --exhaustive-verification is in force are fixed for the run and never change in response to cost, elapsed rounds, findings, or model preference. A later invocation changing any of them — including adding or dropping the flag — starts a new run with a fresh gate ledger rather than mixing evidence provenance. None of them is written into the Manifest.
Read and validate every gate before work. A gate is a title, a body, an optional why, and a required kind (judgment or deterministic). There is no default kind and none is inferred — a gate that does not declare its kind makes the Manifest invalid, because the declaration is what decides how that gate re-verifies. Two shapes are the superseded schema and reject the same way: a gate carrying a verify block of any shape — instructions, prompt, model, or a description paired with a separate evaluator text — and a gate stating a phase, a field this workflow no longer has. Reject the Manifest with a clear instruction to create a fresh one by running /define, without passing the incompatible Manifest as an amendment input. Do not translate, ignore, migrate, or amend an old schema — silently dropping a stated phase would discard an ordering its author chose deliberately.
Pointing evaluators at the gate
Before calling /done, evaluate every Acceptance Criterion and Global Invariant under the selected mode. Point evaluators at the gate; never copy its text into the envelope. A per-gate execution receives the Manifest's absolute path and the ID of the gate it evaluates; a consolidated execution receives that path and the set of eligible gate IDs. The canonical text is read from the file, so nothing can paraphrase, truncate, or reframe a gate between authoring and evaluation — and the party that would otherwise be assembling that copy is the executor, whose interest in how a gate reads is exactly what verification exists to neutralize.
Run state travels in the envelope, because it deliberately is not Manifest content: which gates are eligible, and each Judgment Gate's Ratchet scope. So does one framing line — evaluate the named gate as written, and treat nothing else in the Manifest as binding on your verdict. A gate's body states what done means on its own, so it depends on nothing else in the file; the line is what stops Process Guidance and the Initial Approach, now visible, from being read as though they bound. Multi-repo manifests declaring Repos: add the path map per define/references/MULTI_REPO.md; otherwise add no gate context.
An evaluator evaluates and never repairs the artifact. A Manifest path it cannot read is BLOCKED, not FAIL — the gate was never evaluated, and a FAIL would report a verdict nobody reached; where one execution covers a set of gates, that is BLOCKED for every gate in the set.