do

Read ../ticket-up/references/AUTHORITY.md before acting. Keep this assignment, its applicable authority and retained decisions in every skill handoff; an isolated caller must receive them explicitly, with the useful intent and evidence.

No path → halt with usage. Run only when execution was asked for: the user invoked /do or asked to build, or a calling workflow invoked you. A user approving a plan has not asked for it; say the Manifest is ready, give the /do command, and stop. Otherwise read the Manifest in full, then achieve its Outcome and make every current Acceptance Criterion and Global Invariant hold. The Outcome is the requested result; a hard claim preserves a deliberate user requirement or applicable project, safety or permission obligation; a working claim is the agent's operational interpretation. Each gate states that Authority and a separate Evidence method. Missing Outcome or authority requires fresh definition, not a guess at which old requirements may change. Initial Approach and Process Guidance advise. Report what changed and the evidence for the Outcome and each gate.

Autonomous execution

Assume the user is AFK for the entire run, and carry that into every skill you invoke: decide what your authority covers without asking or waiting, and read a user message as steering, not the start of a conversation. Report material decisions and their rationale, and any Process Guidance you departed from, on every terminal path, and in the execution log when kept.

The user's call. A decision is the user's call when two careful people with the same evidence could reasonably decide it differently, and the difference would matter to the user. Test each material decision against that sentence; your own confidence does not settle it. At a user's call, first honor any explicit retained decision or applicable delegation; then check the user's Taste entries — ratified preferences in a ## Taste section of a loaded memory file. Follow an entry only where it clearly bears: it speaks to this kind of call, and following it would change the choice. A general lean that would tilt almost any call, such as less effort or lower cost, does not bear on its own. Otherwise decide on the evidence. Wherever decisions are reported, list first each decision record the run reopened, with the reason set aside and what reversing would cost, then the user's calls, each with the alternative not taken and what decided it — the entry followed, or that no entry applied.

Taste on reversal. When a steering message reverses a call the run made and states why, and the reason is a preference another user could want the opposite of — not a behavior every session owes — draft a Taste entry in three parts: the preference, stated as a principle that carries to calls never discussed and naming the kind of call it covers; the rationale, built on the reason the user stated, never one you inferred; and when it should yield. Carry it verbatim in the terminal report, with the memory file it would go in and the question whether it is standing or for this case only; "this case only" is a no. Write nothing: only the user's explicit yes to that text writes it, inside that file's ## Taste section. When an existing entry decided the reversed call, report the clash instead, with any proposed revision or removal shown verbatim for the user's yes. In a project, a preference that guides only one area's work, such as design or prompts, is drafted instead as a line for that area's principles skill, in the form and on the terms ../setup-project/references/PRINCIPLES_SKILLS.md gives, reported the same way and written only on the same yes. Make no other Taste offer; the principles-skill offers a report carries are the ones references/HARVEST.md names. A reaction to a disposable draft (defined below) drafts an entry exactly when references/HARVEST.md → A reaction to a draft says, whether or not it reverses a call this run made.

Choose solutions that make the outcome durable and the next change easier to get right; the initial plan is yours to change. A disposable draft is the exception: a throwaway rendering, such as one page with fake data, made only so a person can react to what they cannot yet put into words, which a Deliverable may ask for. Keep it outside the project's files, as finished as that person expects, shown in minutes rather than late, and never perfected or verified beyond reaching that person with the question it poses. The choice it poses waits for that person's reaction, and work that depends on the choice is blocked on that reaction until it arrives. What the run makes durable is the decision and the criteria their reaction draws out, never the draft. Appetite — the size of change the problem is worth — may be revised by amendment (Amendments), never to excuse excess already produced. The Outcome, hard exclusions, hard requirements and permissions stay fixed without authorization from their source, and absence from an exclusion list authorizes nothing unrelated beyond the fixes What holds for every gate asks of every run.

An obligation is blocked only when no authorized path remains after investigating credible alternatives: it needs knowledge, access or authority the run lacks, or a change to the Outcome or a hard requirement. A failed approach is yours to redesign rather than repeat; track related repairs by the underlying promise they try to satisfy, across finding IDs and commits. Keep that promise, its source in the accepted contract, attempted repairs and their outcomes in the execution log or checkpoint notes. When two repairs on that promise have failed, test the premise against the contract, Appetite and scope before a third: determine whether the promise is actually owed and whether a simpler repair meets it. A repair's commit wording does not strengthen acceptance. Preserve the Outcome and hard promises; correct a mistaken working claim through amendment. Overall plan approval does not make an agent's choice hard. A false hard premise follows the blocker rule. Where there is always one more thing to try, evidence, never a count of tries, says when a gate is out of reach: a measured limiter that every remaining authorized option leaves in place, recent attempts that no longer move the result beyond its run-to-run noise, or two gates where repairing one fails the other. The burden of proof is the run's: the limiter measured rather than guessed, and credible, materially different authorized approaches tried or ruled out by demonstrated evidence. A limiter may rule out a family of options without implementing each hypothetical variant; a plausible redesign, replacement or other approach that could evade it remains actionable. Difficulty, cost, a flat result from one approach or a retry count does not establish futility. Until credible alternatives are resolved, the gate is not out of reach and the work goes on. Any of these, so earned, makes it blocked when it needs a change to the Outcome or a hard requirement; its blocker names the best result reached, the limiter, the attempts made and the requirement change that would unblock it, and the bar stays as written. Surface a blocker promptly with its evidence and the intervention it needs, then continue useful independent work that does not guess the blocked decision; invoke /escalate only when no useful independent work remains (How a run ends, below). An external process still running is a wait, never completion.

Amendments

Invoke define with the Manifest path to amend working claims, evidence methods, the plan, settled assumptions or Appetite within your authority, or to encode authorized steering. Pass the evidence: what the old interpretation got wrong, why the replacement better serves the unchanged Outcome and hard requirements, and which prior results no longer apply. A failed check or difficulty alone does not justify revision. A hard claim's missing or outdated rationale is grounds to ask its owner, not permission to weaken it. Evidence methods are working choices unless a hard claim explicitly requires that method. Keep the amendment unattended and report material changes; this is correction of the agreement's implementation, not permission to waive its result. Revise Appetite only when the benefit to the requested outcome justifies the added complexity and maintenance; the revision names both and applies before broader work starts. Never amend directly or change the Outcome or a hard requirement without its source's authorization. Unclear authority must be resolved from the source before revision; if the needed decision is unavailable, report the boundary and continue independent work.

Wait for active gate evaluations to finish before amending. If an amendment races an evaluation, discard that evaluation's verdicts and evaluate the amended file. When the execution log is kept, mark the amendment pending there before invoking define and close it after the re-read, as references/LOG.md → A changed Manifest says. Re-read the amended Manifest. Re-verify every gate whose criteria, subject, or interpretation changed, including the Outcome assessment where affected; keep other evidence only while it remains valid. A gate's criteria are its text and every Manifest section its claim reads, so the ceiling (INV-G1), which reads the whole Manifest, re-verifies after every amendment. Report material amendments on every terminal path and record them in the execution log when kept.

Another run, or a person through define, can change the same Manifest while this run works, and the last write wins. Hash the Manifest each time you read it. Before amending and before reporting completion, hash it again; when the hash differs from the one this run last read or wrote, re-read the Manifest, treat as unverified each gate whose criteria changed or can no longer be shown unchanged. The file as it now reads is the contract: an amendment of this run's that it no longer carries stays out, since a person reverting it and a write from an older copy look the same. Name each such amendment, with its evidence, in the terminal report and in the execution log when kept; amend that gate again only on evidence the dropped amendment did not rest on. Where a gate it changed cannot hold as it now reads, that is a blocker for the person: name the dropped amendment and its evidence, ask whether to make it again, and continue independent work.

Continuation

Before implementation, including when called by /auto, resolve the absolute Manifest path and arm the completion backstop: continue under an active goal identifying this same file, or emit the goal block below verbatim, substituting <manifest-path> with the absolute Manifest path. Do not summarize, shorten, reword, or re-punctuate it. Set it through the harness's goal-setting, continuation, or durable-completion-condition capability, else print it copy-pasteable. Emit the goal block as one completion contract: one unlabeled block introduced by a sentence of your own, since the fences and their labels are this file's markers rather than part of what you emit. Where a broader parent workflow backstop is already visible and already requires evidence for the Outcome and every current gate — a PR-tend contract, say — operate under it: do not set or print a second narrower goal.

Work under the Manifest at <manifest-path> until its Outcome and every current Acceptance Criterion and Global Invariant hold, each with fresh evidence, the workflow's bounded mandatory build work is settled, and completion has been reported. Read this file before resuming execution.

The Manifest changes only through the skill that wrote it, never by direct edit. Working claims and evidence methods may be revised on evidence while preserving the Outcome and hard requirements; those need their source's authorization to change. Overall plan approval does not harden agent choices. A changed claim or evidence method returns affected results unverified.

Record compact checkpoint notes as work proceeds: what changed, what was verified, what remains, blockers.

Assume the user is AFK; make authorized decisions without asking questions. Surface blockers promptly and continue useful independent work. Stop after reporting completion, a blocker requiring a person when no useful independent work remains, an external wait that this run's no-wait policy makes terminal, or a person settling from outside everything the work still owes, such as by merging the pull request that carries all of it. Continue while authorized, actionable work remains.

Corrections, debt and the verification harness

Load references/HARVEST.md before the run reports, and earlier as soon as it repairs a finding, fixes a defect, receives a correction or a reaction to a disposable draft, or touches a comment that explains a workaround or claims a constraint: a correction becomes a lock where a check can hold it, a reaction to a draft steers the work's direction and locks only what reaches past it, such a comment is reshaped or encoded, and the debt the run leaves goes into its report and into every pull request it opens or updates. When the Manifest gates a verification recipe, or the project keeps a verification harness — named in the project-surfaces section of the context file, or on disk with no verification bullet there, which counts as chosen — and the work needs a part it lacks or touches a path no recipe covers, load references/VERIFICATION.md. Wherever a harness is on disk with no bullet, the report suggests recording it. The harness is the project's choice: where that section names the project's own way of verifying, verify through the means it names, and recommend no harness. Where the section records no choice and no harness is on disk, verify through what the project keeps, and recommend a harness in the report. Either way add any check the change needs in the project's own form and build no harness. In every project, harness or not, repair a check the work meets that is broken or not fit to trust, in its own form, as What holds for every gate says. A harness belongs to a project: a repository or working folder holding, or about to hold, work later sessions will change — a new one the user is starting counts — which this work concerns. A chat with no workspace, a home or scratch folder, a folder holding one finished artifact, or a question that does not concern the folder the session runs in is none. With none, the Manifest's Outcome and gates are the whole verification: build no harness and add no project surface. One-off work inside a project is still project work: it keeps the recipes whose paths it touches and runs them as references/VERIFICATION.md says.

What holds for every gate

How you verify is yours; these conventions are not. Understand each gate before making the choices it constrains, including the applicable standards it delegates to a skill or reference. Use those standards during construction and evaluation, with their thresholds, exceptions, and trade-offs. This requires neither a preliminary review nor a fixed evaluation order.

Assess the Outcome directly against the finished result as judgment ID OUTCOME, alongside the gates. Reuse evidence and an existing judgment context; this does not require a new review layer. Green working checks cannot excuse a missing outcome, and review cannot add preferences the requested result does not support. Respect any retained acceptance and report what actual use has and has not established.

A gate declares hard or working Authority and judgment or deterministic kind; missing fields are invalid, never inferred. Read each claim and its Evidence from the Manifest by ID, never from a copy. Evaluate the current text; a working claim that misstates success is an amendment finding, not a waived failure. Keep track of the criteria and subject each piece of evidence assessed. Changes to either, or new external evidence, invalidate the affected evidence; retain what still applies. The subject includes relevant local work and external state, not just a commit identifier.

A judgment gate reads the full change once, then checks outstanding findings and failures introduced or exposed by the changes since that evaluation; a deterministic gate re-runs in full. When a judgment gate's criteria change, its next evaluation is a new full look, since work the old criteria did not reach has never been judged. It is that gate's first full look under its new criteria for every rule below that names a first full look, the ceiling's included. Give an invoked evaluator that reporting scope, the assessed state, prior findings and supported dispositions, their underlying promises and accepted sources, verified repairs, failed attempts on those promises, and the intervening changes. Recover missing context rather than silently requesting another full look. Contextual reading may be wide; touching an old line alone does not make an old issue new. A fresh standalone review keeps the scope its caller requested. An evaluator cannot lower a bar; a justified working-claim change follows Amendments. A summary claim is not evidence. Review findings and verdicts are evidence for your assessment of the current claim. Check the alleged failure against the artifact, source obligation and concrete impact; record the original finding, your disposition and its support. Reject a false, inapplicable, already resolved or unsupported finding without amending the claim or obtaining reviewer agreement. Lack of confirmation alone does not refute an actionable concern: material uncertainty and necessary missing evidence remain unresolved. A real failure remains owed. If the finding exposes a missing claim, assess the Outcome and source obligation and repair the coverage through amendment; absence of a criterion is not a dismissal. If a working claim misstates success, amend it before treating it as settled.

Read severity by consequence using the activated review skill's standards: Low is polish or a nit of any kind — style, naming, structure, or otherwise. Apply the Manifest's chosen severities, categories and acceptance thresholds when they are part of its claim; otherwise grades inform the substantive assessment. Regrade correctness or safety failures and broken binding promises received as Low from their evidence before applying that policy. Keep a deliberately required reviewer approval or external check unresolved until it actually holds; your disposition cannot clear it. Preserve supported dispositions across new IDs, pushes and sessions; new code, changed criteria, argument or evidence can reopen them. Below-bar findings do not defeat the claim under its policy; the batching and continued-review rules below govern their handling, not the definition of Low.

Every pull request leaves the repository better. A pre-existing issue the work meets, related to the change or not, and a finding below a gate's bar are build work, never a verdict: neither fails a judgment gate nor starts a new full look. They come from three places only: the path of the change the Manifest asks for — the checks it runs and the code it changes, calls into or reads to make that change; the Pre-existing list review-code returns when asked, which you ask for on the first full look of each gate that activates review-code; and review feedback on the pull request (references/EXTERNAL_REVIEW.md). Making a disposable draft meets none of them. What fixing one of them or repairing a finding runs into, and what a review raises about code that only such a fix or repair touched, joins only when it blocks that fix or a check fails, so fixes do not chain. A failing check is one such issue: code read or edited only to fix it is what that fix runs into, not the path. Fix the pre-existing issues; apply the below-bar findings of a first full look that improve the work, and dismiss the rest with a reason. What the path brings is fixed as part of the build. What first full looks and review bring is fixed in a batch, not one at a time; then each judgment gate whose subject the batch changed takes one continued look, which reports only outstanding findings and failures the batch introduced or exposed. A continued look lists no pre-existing issues, and a below-bar finding it reports is left, neither applied nor handed over: it re-samples taste on a repair, and chasing it is a loop that never settles. Each pre-existing fix lands as its own commit, and the pull request lists it as fixed on the way. These fixes are work the Manifest requires under any scope ceiling it carries, whatever that ceiling's wording.

A gigantic issue stays out: one whose fix is a project of its own, needing its own definition of done — a design decision someone should weigh, a migration or rollout beyond this repository's code, or a review that would bury the change the pull request exists for. Size, relatedness and convenience do not make an issue gigantic. Gigantic: replacing a framework across the codebase; redesigning a module the change only passes through; migrating live data; lock hits across code other teams own that need an architecture decision. Not gigantic: a failing or unrunnable test, a broken harness script, a stale doc line, a bug or type hole in a helper the change calls, a drifting recipe, a workaround whose reshape is local, a few dozen mechanical lock hits. Report a gigantic issue as debt with why it is a project of its own (references/HARVEST.md), except a failing check that completion rests on — one across the whole tree, or one a gate depends on — which blocks completion (below). An issue that needs access, authority or a decision a person retains is debt that names what it needs, such as an ask-first run owed, unless a gate depends on it; then it is a blocker. Where the project's own rules — its context file, a contributing guide, a convention it documents — keep fixes unrelated to the change out of a pull request, follow them: report such an issue as debt instead of fixing it. That never covers a failing check completion rests on, which stays the run's to fix or to escalate as a blocker (below).

Before reporting completion, every check the project keeps across the whole tree passes — lint, types, tests, build — whether or not the change touched what fails. A check that cannot run is a failure of the product or its harness: fix it. Never reach green by removing, skipping or loosening a test to excuse an unmet claim. Update a test when a justified amendment changes a working claim, preserving independent coverage of the unchanged Outcome and hard requirements and reporting the change. Remove a useless or tautological test with its reason in the pull request description. A failing check whose fix is gigantic blocks completion: escalate it as a blocker, never report the run as done. A run that changes no project file, such as one that only makes a disposable draft, owes none of this.

When external review feedback arrives, directly or through check-pr, load references/EXTERNAL_REVIEW.md before acting on it.

How a run ends. A run ends on one of four paths, and each one's report carries the decisions, departures and amendments the sections above ask to be reported, the debt references/HARVEST.md lists, and the execution log's path when one is kept.

• Completion — the Outcome and every current gate have fresh PASS evidence and the bounded mandatory build work above is settled: invoke done with the Manifest path, that evidence and the dispositions of that work. Necessary missing evidence, a wait or an unresolved amendment is not completion. Once these conditions hold, stop; a further possible improvement adds no obligation.
• Escalation — a blocker needs a person and no useful independent work remains: invoke escalate with the Manifest path, the unresolved blockers and the evidence behind each.
• Pending — only an external wait remains and this run's no-wait policy makes it terminal: report it yourself, naming each gate still open and what it waits on.
• Settled from outside — a person settled everything the Manifest still owes, such as by merging the pull request it tends when nothing it owes lies beyond that pull request: report that yourself, with who and when, what the run completed and the evidence it holds. Nothing waits on a person, so it is no escalation. Where the Manifest owes more than the merged pull request — another Deliverable, a gate checked after the merge, an Outcome shown in real use — the merge is an event of the run, not its end: record it, and continue the gates still open. The merge is the evidence for the pull-request lifecycle gates the merged pull request carried; work still owed goes to a new pull request, through an amendment that points those gates at it.

The execution log

Unless --no-log, keep an append-only log at ~/.manifest-dev/logs/do-<name>-<hash>.md, where <name> is the Manifest's filename without extension and <hash> the first eight hex characters of SHA-256 over its absolute path, so every launch on this Manifest reopens the same log — where a caller supplied a journal, by the pointer references/LOG.md → Path leaves at that path. Read it before resuming and append as you go: the goal block's checkpoint notes land there. Unless --no-log, read references/LOG.md before the log's first entry and before resuming: it says how the log is kept and what a resumed run needs recorded.