do

name	do
description	Manifest executor. Works through Deliverables verifying every Acceptance Criterion and Global Invariant. Use when executing a manifest, running a plan, implementing a defined task, or when the user asks to run, execute, implement, or ship a manifest-backed plan.
argument-hint	<manifest-path> [--verification per-gate|consolidated|self] [--verifier-model <model>] [--exhaustive-verification] [--no-log]
user-invocable	true

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.

What /do supplies once, so no gate restates it

Two things hold for every evaluation in the run, so they live here rather than being copied into every gate body:

• The comparison. For repository work, read the change as origin/main...HEAD — origin/main rather than main, since a local ref can sit stale in a fresh or shallow clone and fail a gate on the wrong evidence. Substitute the repository's actual default branch where it differs. A gate needing a different subject — every commit on the branch rather than the net diff, because a gate reading only the net diff cannot see what appeared and was removed inside it — says so in its own body, as an exception to this default.
• The verdict contract. Every evaluation returns PASS, FAIL, or BLOCKED with concrete evidence. A gate does not restate it.

Gate bodies that activate a skill name the skill and its dimension and stop there: review-code owns each dimension's threshold in its own table, so a threshold copied into a gate is a second statement that can contradict the first. Under every mode, an evaluator meeting such a body activates that skill in its own context — never spawns a further agent to run it, which would bypass the gate's PASS/FAIL/BLOCKED contract.

Evaluate gates through the selected reference's execution envelope. Every gate that is unverified, stale, FAIL, or retryable BLOCKED is eligible; a fresh PASS is settled and does not re-run. A FAIL remains eligible after repair, and a retryable BLOCKED remains eligible at its next check. Run eligible gates in parallel only where the selected reference provides parallel evaluator executions.

What each gate's kind decides

Every Acceptance Criterion and Global Invariant declares its kind. A Deterministic Gate (deterministic) takes its verdict from a command or check returning the same outcome for the same artifact state. A Judgment Gate (judgment) takes its verdict from a model's judgment over an open finding space, where a fresh evaluation surfaces findings the previous one did not even on an unchanged subject. A gate that mixes the two — a command whose result is one input to a judgment — is a Judgment Gate; whatever a gate's kind, a body naming explicit commands always runs those commands in full, since a command's cost is small and its answer is the evidence.

How much checking to buy

Two settings trade cost and time for verification quality; Running gate evaluations above resolves both and fixes them for the run.

Who checks — --verification:

• per-gate (default) — a fresh independent verifier execution per gate, run concurrently. Each gate gets a whole context and a whole reader to itself, so a round costs about one gate's wall clock rather than the set's, and nothing one gate read weighs on another's judgment.
• consolidated — one independent verifier execution works through the outstanding gates in sequence, in a single shared context. It pays the orientation once rather than per gate, but every gate it finishes stays in that context for the gates after it, so both elapsed time and tokens grow with the size of the set. Choose it where the gates are many and each is slight — mostly commands and quick checks — or where launching many executions at once is capped or costly.
• self — the executor evaluates its own work. Cheapest and fastest, and it is marking its own homework.

How much a Judgment Gate re-reads — --exhaustive-verification:

• off (default) — the Ratchet. A Judgment Gate reads the full change on its first evaluation; every later one judges two things only — whether the findings it last reported were repaired, and whether the delta since introduced anything its criterion catches. It still reads as widely as it needs to understand what it is looking at, and reports only within that scope. Fewer rounds, and the run ends on repaired findings rather than on a re-read that happened to come up empty. The cost is real and deliberate: a defect sitting in ground already judged once stays missed.
• on — every Judgment Gate re-reads the full change whenever it is eligible. More rounds, and a better chance of catching what the first read walked past. Load references/exhaustive-verification.md when this is passed, and otherwise leave it unloaded.

A Deterministic Gate is outside the second setting: the same state returns the same verdict, so it re-runs freely and in full whenever it is eligible. Narrowing what it reads buys nothing.

Spend an expensive evaluation on a state you expect to hold. Where re-running a gate costs far more than a round of repairs — a long end-to-end suite, a deploy-dependent check — evaluate it once the gates whose failures would move its subject are settled, rather than on a state a repair is about to change. A gate whose cost is not obvious from reading it says so in its own body, which is what lets this be judged rather than guessed. The whole-change quality sweep is the standing case: the advisory review dimensions range over everything the run touched, so their one full look is worth spending after the run's mechanical and defect-finding gates hold a fresh PASS. Sweep findings bind like any gate's — repair them in the run rather than handing them to the user, and let the repairs re-verify through the gates whose subjects they touched.

The gate ledger

Each evaluated gate returns PASS, FAIL, or BLOCKED; track its latest verdict, evidence, freshness, verification mode, evaluator provenance, and explicit or inherited verifier model in the gate ledger. A Judgment Gate carries two more entries, since they are what its next evaluation is scoped against: the artifact state its last evaluation read — for repository work, the head SHA — and the findings it reported there. A substantive change to a gate's subject after a PASS marks that gate stale; re-reading, re-examining, and cosmetic or no-op edits do not. Manifest amendments invalidate evidence for new or definition-changed gates as described under Steering & amendment. Unverified, stale, FAIL, and retryable BLOCKED gates re-evaluate when eligible; a settled fresh PASS does not re-run.

When the run is done

A fresh evidenced PASS on every Acceptance Criterion and Global Invariant under the selected mode is both necessary and sufficient for done: necessary — never declare done on an unevidenced self-attestation or a "looks done" judgment in place of executing what the gate asks for; sufficient — once every gate holds a fresh PASS the run is complete, so invoke /done with the manifest path, selected mode, verifier-model provenance, gate ledger, and the selected reference's evidence/provenance wording, then stop. A passing gate is settled, not provisional, and its PASS evidence ends the loop.

Sufficiency runs over gates whose premises stand. A PASS whose criterion misdescribes what it judges is not a settled PASS: do not complete on it — it routes to /escalate per Gate text is the exception below, which owns that route. The user's ruling settles the premise question, not the ledger: affirming the text as written leaves the existing PASS standing, while amending it changes the gate's identity, so it returns to the ledger unverified and re-verifies like any other changed gate. That is the only thing a passing gate owes on its own premise.

Acting on verdicts

Any actionable BLOCKED routes via /escalate — one whose note names something a person can do now. A BLOCKED that leaves only waiting is the retryable kind: it reports as pending under a no-wait overlay; see Caller overlays. Without that overlay it waits and re-verifies on an interval proportionate to what is being waited on — the evaluator's own note usually implies one — and escalates once the wait has no visible end, bounded by Runaway protection. FAIL bodies carry findings or a natural-language hint — read them and act on what they say. When two evaluations of the same subject disagree about whether a rule holds, the disagreement is the finding: a subject two careful reads judge oppositely is under-specified, whichever verdict is technically right. Sharpen the subject under test — the artifact both evaluations read, and only within what this run is changing — rather than adopting the more convincing verdict; unless what they read oppositely is a gate's own criterion, which routes to /escalate per Gate text is the exception rather than being rewritten here.

Loop discipline

Verify per head, not per fix. A round's findings were all true of the same commit, so decide everything you will change from that round, change it, then re-verify once. Fixing and re-running evaluations one at a time re-stales every gate whose subject moved and learns nothing the round had not already told you — and it strands evaluations still running against a head that no longer exists.

A gate's threshold is the bar, not a starting point. A PASS settles that gate's subject: the default on a passing gate is to do nothing further there, and findings it reported beneath its bar are handed over rather than worked. That threshold was chosen deliberately — treating a lower severity as free to fix while already in the file overrides someone's decision and re-stales every gate whose subject that file touches. Findings below the bar are real and worth recording for the user, but they are not owed. Repairing them in-loop costs a full re-verification of everything the change touches, and a branch that keeps growing to chase advisory findings pays that cost repeatedly for work no gate asked for. Hand them over on whichever terminal path the run takes — completion summary, escalation payload, or pending summary — the same way a Process Guidance departure is named, and move on. Where the manifest carries a ceiling invariant, that cost has a second edge: the invariant can fail work no criterion required, so a round that reaches past the artifacts already in scope to chase advisory findings risks failing it as well.

The exception is a finding that shows the change unfinished rather than imperfect — an obligation introduced with no recipient, a rule written that contradicts one kept. Repair those in the round that found them instead of handing them over: severity ranks impact, not completeness, and shipping a half-wired change is not restraint. A ceiling invariant does not reach them either, since completing what a criterion started is work that criterion required. This bounds what a repair round covers, not when the run may stop — gates alone decide that.

A rule lives in more places than the one you are editing. Search its distinctive wording before changing it, rather than after the next verifier points at another copy — the first pass is where the sweep is cheapest, and the site a finding named is where it was noticed, not where it lives. It is not done until every statement agrees in scope as well as in wording: other files carrying the rule, a caller's copy of a contract, generated or distributed copies, and the surfaces that discharge it, since an obligation with no recipient is announced rather than stated. Where one statement is already right, adopt its wording instead of composing a fresh one — solving a solved problem twice yields two answers, and the second is rarely the better one.

Failure routing

Code-change fix attempts iterate until they pass or /do judges them genuinely unrecoverable → /escalate. Other retry shapes (waiting, retriggering, replying with or without resolving, mechanical syncs) aren't fix attempts — they follow the verifier's findings directly.

Whenever /do invokes /escalate, pass the manifest path, selected verification mode, explicit or inherited verifier-model provenance, and affected gate ledger entries including evaluator provenance; /escalate reports them with the blocker.

Bound repairs by subject, not by count. Substantive findings that keep landing in one subject — the same code path, document section, or design decision an earlier finding named — mean the design is wrong rather than the wording. The test is convergence, not recurrence: findings in one subject getting smaller and fewer is the loop working, while each fix spawning a comparable one is the design telling you the wording was never the problem. When that is what you are looking at, stop and route to /escalate instead of patching again. Read it from the findings rather than from a tally or a severity label: some verifiers grade and many emit no severities at all, and a second finding genuinely unrelated to the first is the loop working normally, not the pattern. Keep this separate from runaway protection below — that bounds the same fix retried; this bounds different fixes converging on one subject — and separate from the threshold question that follows, which fires while the loop is working rather than when it has stalled.

A threshold can be wrong while the criterion is right. A gate can describe its subject correctly and still sit at a bar costing more than it returns: the verifier keeps failing it on findings that are real and each smaller than the last, while every round re-verifies everything their subject touches. These are findings a gate is being failed on — not the ones a passing gate reports beneath its bar, which are handed over per A gate's threshold is the bar. Convergence is not the test either; the repair loop is working, which is what makes this hard to see from inside it. Read the bar as suspect once what the rounds turn up sits below the severity the gate was written to catch, or once re-verifying costs more than the remaining findings would change. That is a question about the gate rather than the work, so it routes to /escalate carrying what recent rounds found and what another round would re-verify. The user amends the bar or affirms it: an amendment changes the gate's identity, so the gate returns to the ledger unverified and re-verifies like any other changed gate; an affirmation settles the threshold question for this run — record it, don't raise it again, and resume repairing toward the bar as it stands. Never lower it on the run's own reading — a bar the executor can move is not a bar. With no user to ask, do not stall for one: this question is discretionary, and the run is still converging. Record it, keep repairing toward the bar as it stands, and surface it on whichever terminal path the run reaches, beside the sub-threshold findings and Process Guidance departures already named there.

The run never widens scope on its own reading to absorb work it already did. Any manifest edit that stops already-completed work from being judged — narrowing Out of bounds or widening Appetite to cover it, folding it into a ceiling's inherited-work list, or refreshing a ceiling's authorized list from an Initial Approach the run amended to match work it had already done — is the executor deciding after the fact what it owed — the thing a ceiling invariant exists to prevent — and it hides itself, since the widened manifest passes on the next round and the loop reports success over exactly what it was meant to catch. That holds whenever the question arises on the run's own reading, not only once a ceiling has failed. So a ceiling FAIL is repaired by removing the excess; where removing it is genuinely the wrong answer, that scope question goes to /escalate rather than being settled by the run, the way a disputed gate text does.

Three neighbouring cases are not this one. Scope too narrow for work still ahead is the plan deviating from reality, and amends per When the manifest itself is what's wrong. A user's steering message that widens scope over work already done is theirs to give — encode it by amendment on the normal steering path, without asking back. And /define naming completed work when it backfills a ceiling or replaces a criterion is the opposite move, not this one: that list is bounded to what the criteria then in force required, where this rule targets relabelling work nothing required.

When a hint or finding indicates terminal / unrecoverable / human-decision-needed, route to /escalate — autonomously amending the manifest to suppress the block is forbidden.

External review input

When a finding carries external review input — a PR review comment or bot suggestion, as opposed to the manifest's own Acceptance Criteria and Global Invariants, which stay authority and must be satisfied — judge it before acting instead of implementing it to make the thread go away.

Weigh whether it's correct, whether it serves this PR's intent, and whether addressing it is proportionate to that intent — a valid point that needs work beyond the PR's intent belongs in separate work, not this PR. Adopt the comments that clear that bar; on the ones that don't — a false positive, or a valid-but-separate-scope ask — reply with your reasoning rather than changing code.

Push back even on a human reviewer when you are confident, with a respectful reply that leaves the thread open for them to resolve; when you are not — a borderline-valid point, or a substantive design objection — surface it to the user, or in an autonomous run reply non-committally and leave it for a human rather than bulldozing. Making this call autonomously is safe because /do drives to mergeable, never merged — a human still reviews the diff before the button.

When the user does want a beyond-intent ask incorporated, that is an amendment: invoke manifest-dev:define again with the manifest path and the amendment context — /define reads "manifest path in args = amend" and applies targeted changes.

Caller overlays

Caller overlays may narrow retry cadence without changing the manifest. In CI one-shot / no-wait contexts, execute immediately actionable findings (fix, test, commit/push when authorized, retrigger, reply, resolve, sync), then stop instead of executing long wait directives such as bash sleep <N>; reinvoke.

If only wait-shaped findings remain, report the waiting state as pending; do not call /done, do not call /escalate, and do not keep the runner alive. That summary reports the selected verification mode, evaluator provenance for every reported gate, and explicit or inherited verifier-model provenance. It also carries what the other two exits carry — Process Guidance departed from, deviation from the Initial Approach or the Deliverable order, findings a gate reported below its threshold, and any gate whose bar the run read as suspect without a user to ask — since it is the only thing the user sees on this exit.

Execution log

Execution history never lives in the manifest — logged or not, the manifest stays the acceptance contract. Unless parsed options include --no-log, load references/LOG.md and keep an append-only execution log — deviations from the Initial Approach or Deliverable order, Process Guidance departures, dead-end memory, and operational notes; a caller-supplied journal path is that log. Under --no-log, run without one — the log is an aid, not a precondition.

Runaway protection. Holds regardless of logging; the log is where its memory lives. Lifecycle verifiers like check-pr are stateless and report current state without counting cycles, so you own the stop condition — when the log (when kept) plus your run memory show a fix or wait has been retried well past the point of progress, route to /escalate (or, in no-wait mode, a pending summary) rather than looping.

Steering & amendment

Mid-/do user messages default to invoking manifest-dev:define for amendment — the manifest is the source of truth, silent scope drift is worse than an extra amendment cycle. A message that reverses or redefines a rule rather than adding work amends too: it widens no scope, so the drift rationale never reaches it, yet it is the class most likely to leave the manifest describing a system that no longer exists. After the amendment returns, re-read the full Manifest and reconcile the active gate ledger before resuming.

When the manifest itself is what's wrong. Verifiers and execution both surface evidence that a manifest statement has gone false — an Architecture that no longer describes the work still ahead, a scope boundary too narrow for that work, a Known Assumption the run has settled. That is not execution history and does not belong in the log: the log records the run deviating from the plan, and this is the plan deviating from reality. Amend, and say so — noting it in a completion summary is not repairing it. A boundary this run already exceeded is the other case, and routes per The run never widens scope on its own reading to absorb work it already did.

Gate text is the exception. Never amend an Acceptance Criterion or Global Invariant on the run's own reading that it misdescribes what it judges. That is the binding layer, and a run that rewrites what binds it has none — which is the one thing gates exist to prevent. Route it to /escalate with what the verifier reported or what execution surfaced, whether the gate passed or failed, and let a human decide; a gate changes on a user's say-so, not the executor's.

Amendments do not land mid-evaluation. Evaluators read the Manifest rather than a copy of it, so an amendment written while evaluations are in flight changes the contract under them. Wait for the round to return before amending; if one lands anyway, discard that round's verdicts and re-evaluate against the amended Manifest rather than crediting evidence gathered against text that no longer exists.

Reconciling the ledger. A gate's verification identity is its complete effective evaluation input: ID, title, body, why, kind, and any caller-injected wrapper context such as a multi-repo path map. New gates and gates whose identity changed become unverified, with prior verdicts retained only as history; removed gates retire from the active ledger; unchanged gates retain their verdict and freshness subject to relevant changes in their subject. A run-level mode or verifier-model-provenance change invalidates the whole active ledger rather than changing individual gate identities. Run outstanding verification as usual.

Which gates an amendment actually reaches is a judgment, not a byte comparison — an edit to one gate's body leaves the others' identities untouched, and an Intent edit reaches the ceiling and little else. Record that call per gate: which gates the amendment left settled and why. The run benefits from deciding it re-verifies less, so an unrecorded judgment is a lever on the run's own rigor; a recorded one is auditable. When it is genuinely unclear whether a gate was reached, treat it as reached and re-verify.

Then surface a one-line digest of what the amendment assumed (the new or changed (auto)/ASM entries) so a user who steered and left can audit on return. Pure questions about the manifest or process are answered inline.

Unattended launch

When /do is the top-level execution entrypoint, establish a durable goal-setting backstop whose completion contract is auditable from the transcript after /do reads the manifest.

What the contract must require. A gate ledger covering every Acceptance Criterion and Global Invariant: gate id, gate-text source, selected verification mode, evaluator provenance, explicit or inherited verifier model, latest verdict, evidence, and freshness relative to the last relevant change to its subject. Completion requires every listed gate to have fresh PASS evidence under that mode and /done reported. Unverified, FAIL, stale, BLOCKED/actionable, or escalation-pending gates are non-terminal. A substantive change to a gate's subject after a PASS marks that gate stale; re-reading, re-examining, and cosmetic or no-op edits do not. Stale gates re-evaluate before /done. Use the selected reference's evidence/provenance wording in the contract; never accept "looks done" or a summary claim in place of that mode's required evidence.

Where the contract lives. If a broader parent workflow backstop is already visible (for example /auto's full-chain contract or /babysit-pr's PR-tend contract) and it carries this manifest gate-ledger condition, do not set or print a second narrower goal; operate under the parent contract. If the visible parent lacks that condition, supplement it by setting or printing the manifest-completion contract before continuing. Otherwise, if the active harness exposes a goal-setting or continuation capability, set the manifest-completion contract directly; if not, print the copy-pasteable contract for the user to apply manually.

The contract should also carry the objective, constraints, stop/block condition, and compact progress expectations when useful, so continuation keeps running until all gates pass rather than stopping at the first turn's end.

Input

<manifest-path> — required; no args → halt with usage. Parse only top-level --verification, --verifier-model, --exhaustive-verification, and --no-log options as flags; quoted or topic mentions are text. Read the manifest fully before any execution. Multi-repo manifests (declare Repos: [name: path, ...] in Intent) — use absolute paths in tool calls when working in a non-cwd repo.