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 consolidated; 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, verifier-model validation and inheritance, evaluator provenance, and mode-specific evidence wording for completion and unattended backstops. Apply its option validation before work. 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. Its verify block contains required instructions, required kind (judgment or deterministic), and optional integer phase (default 1). Reject prompt, model, a missing or unrecognised kind, a missing instructions, or any other verify field with a clear instruction to create a fresh Manifest by running /define without the incompatible Manifest as an amendment input; do not translate, ignore, or amend an old schema. 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.

Before calling /done, evaluate every Acceptance Criterion and Global Invariant under the selected mode. Gate instructions carry the goal, evidence, threshold, verdict contract, non-obvious context, and any skill activation. Preserve each gate's instructions verbatim inside the selected execution envelope. Multi-repo manifests declaring Repos: add the path map per define/references/MULTI_REPO.md; otherwise add no gate context.

Evaluate gates through the selected reference's execution envelope. Respect phase ordering under every mode: only the lowest phase containing any gate without a fresh PASS is eligible. Within it, evaluate every gate that is unverified, stale, FAIL, or retryable BLOCKED; keep fresh PASS gates settled. A FAIL remains eligible after repair, and a retryable BLOCKED remains eligible at its next check. Every gate in that phase needs fresh PASS before a later phase becomes eligible, and any non-PASS leaves later phases unverified. Within the eligible phase, run 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 in verify.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, instructions naming explicit commands always run those commands in full, since a command's cost is small and its answer is the evidence.

A Deterministic Gate re-runs freely and fully whenever it is eligible. Narrowing what it reads buys nothing: the same state returns the same verdict.

A Judgment Gate runs under the Ratchet. Its first evaluation reads the full change. Every later evaluation judges two things only — whether the findings it last reported were repaired, and whether the delta since that evaluation introduced anything its criterion catches. The evaluator still reads as widely as it needs to understand what it is looking at, and reports only within that scope. Re-sampling the whole change every round is what makes a Judgment Gate terminate on a sample that happens to come up empty rather than on the work being done; closing the finding space after the first full look is what lets the run end on repaired findings instead of on a lucky draw. The forgone recall — what a later full look might have turned up on ground already judged once — is the deliberate cost, and --exhaustive-verification is where a run buys it back.

The whole-change quality sweep — the advisory review dimensions, which range over everything the run touched — takes its one full look late, after every Deterministic Gate and defect-finder gate holds a fresh PASS; /define encodes that ordering as a later phase. Its 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 — in full for Deterministic Gates, ratcheted for Judgment Gates, including the sweep itself when it comes round again. It never takes a second full look. A Judgment Gate scoped to a single Deliverable takes its one full look when that Deliverable is complete, and ratchets from there.

The Ratchet can be suspended deliberately, at two widths. --exhaustive-verification suspends it for every Judgment Gate in the run, at the round cost the Ratchet exists to bound; when it is passed, load references/exhaustive-verification.md and apply it, and otherwise do not load it. A single gate can buy the same thing for itself: instructions asking for the whole change to be re-read on every evaluation suspend the Ratchet for that gate alone, and its re-rounds receive the full change in place of the delta scope — /define authors that where a user wants one criterion held to exhaustive re-review. The two widths live in different places, and it matters for the ledger. Like the verification mode, the flag is run-level policy fixed at launch and never written into the Manifest. The per-gate width is the opposite: it lives in that criterion's own verify.instructions, so it travels with the Manifest, and adding or removing it changes that gate's verification identity like any other instruction edit — that gate returns to the ledger unverified while every other verdict stands. Neither width is something the run chooses for itself.

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 the gate instructions; 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. Do not keep refining past the gates: 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.

Reconciling the ledger. A gate's verification identity is its complete effective evaluation input: ID, criterion/invariant text, verify.instructions, verify.kind, verify.phase (default: 1), 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 in normal phase order.

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, phase, verify.instructions 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.