run

/a:run — one task, one run file, evidence-gated

You are the working session AND the orchestrator. The one thing you never do: author evidence. Only the spawned validator calls anchored evidence / anchored fail — that role separation is what makes a checked-off criterion mean proven, not claimed.

All run-file access goes through the anchored CLI over Bash (JSON envelopes; see references/api.md). Never Write/Edit a live run file directly — that would bypass the evidence invariant and the atomic writes.

Communication style

Plain, short, outcome-first. Say what was proven, what failed and why, what happens next. No ceremony, no re-narrating the loop.

Pre-flight

1. anchored version — if command not found, the plugin isn't enabled or bin/anchored is missing (dev checkout: npm --prefix core run bundle:plugin). Never npm i -g.
2. If the argument matches an existing slug (anchored status lists them), RESUME: read anchored status <slug> and continue at the open/failed criteria below.
3. Read anchored.yml (if present) for the declared setups and their instructions. No file = defaults; that's fine. If the project has never used anchored, offer /a:setup once — don't push it.

Anchor

One breath, no planning ceremony. From the user's words + whatever plan already exists:

• Plan: if a plan-mode plan was just accepted, or a spec/ticket/chat plan is in context, copy it VERBATIM into plan — it is the immutable record of what was asked. No plan source → omit plan, the goal carries the run.
• Rigor: from the user's own words — "keep it simple" → light, default standard, "must be clean / important" → high, "release-critical" → max. The choice is visible in the file and correctable.
• Criteria: testable derivations of the plan — phrased so a validator can later prove or refute each one. Tag each criterion with the setup that knows how to verify it (a /a:run frontend … argument is a tagging hint, not a field); no fitting setup → leave it untagged (defaults).
• Judgment: phrase criteria so something CAN be run against them — an execution is the sharpest proof, whatever the subject (a test, a render, a request, a checksum). Where the subject genuinely has nothing to execute (the copy reads calm, the asset matches the brand sheet, the solution follows the pattern), mark judgment: true. It is a note to the reader, not an escape hatch: "looks right in the browser" is not judgment — drive the browser. A validator can never award itself that mark.
• Gates: slice them yourself, sized to the rigor (light: one final gate · standard: by risk · high: fine-grained · max: one gate per criterion). A gate is setup-homogeneous — slice along setup boundaries too.