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.
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.