pipeline-auto: controller rules

Machines may unblock work. They may not decide past the budget, override a human, choose between equally grounded answers, or enlarge scope. When a rule says escalate, escalating is the decisive action. Deadline, billing and "too cautious" pressure change none of these rules.

The rule this skill reverses

superb:pipeline forbids "a Brain Agent that decides user requirements" (skills/pipeline/references/planning.md:177-181), and its zero-assumption law (skills/pipeline/SKILL.md:40-71) lets another agent explain options but never decide an unresolved requirement. This skill is that Brain Agent, built on purpose. The guardrails below are the answer to that objection; changing a threshold, budget or escalation route loosens the answer.

The objection	The answer
A machine decides what it prefers	It adopts only what the spec or code entails. convention-cited is below the floor
Three agents agreeing proves nothing	Agreed. The bar is grounding rung, not votes; reading assignments decorrelate the three
It will decide more and more	3 adoptions per phase, 10 per run, checked before dispatch; only a human extends, at most twice
It will overrule the user	A candidate contradicting Provenance: human is rejected at any rung
It will build what nobody asked for	Stage 06 seals the phase set; the tracker creates phases only at stage 07 and only for sealed ids (the ids themselves are not checked against the master plan); MISSING-FROM-SPEC is frozen
It will drift from the request	Depth cap 2 from the last human answer
It grades its own homework	Every adoption is labelled Provenance: quorum; the terminal report leads with them, weakest first

Want the user consulted at each decision? Use superb:pipeline. This is a different trade, not a better version.

Invocation

Trim $ARGUMENTS and select exactly one mode:

Argument	Mode
empty	Full run from stage 01
resume	Resume one compatible pipeline-auto/v1 run from its files and Git. Never create or replace a run
status	Strictly read-only: no lock, write, reconcile, dispatch, test, fix or initialize
anything else	Ask what the user meant. Do not guess a verb

For resume and status, use references/persistence.md. No identifiable run: say so. Several: ask which. Recency is not selection authority.

Harness

First action on every harness, before any other step: read references/planning.md. This file is the rules; the stage files are the procedure. A harness that read only this file and started implementing did not run the skill.

No Agent tool with named agent types (Codex, whose spawn_agent takes a free-text brief): a named agent type in the dispatch table is the file agents/<name>.md in this plugin, ../../agents/<name>.md relative to this file — pipeline-auto-intent-reader is ../../agents/pipeline-auto-intent-reader.md, pipeline-auto-brain is ../../agents/pipeline-auto-brain.md. Dispatch it with spawn_agent, fork_turns: "none", the message being that file's body after its frontmatter followed by the brief the stage specifies (prompts/brain.md, prompts/brain-proposal.md, or the stage-01 intent read). A quorum or the intent read is three separate spawns, one per index, then wait_agent for all three; never one spawn asked for three answers. The tool allowlist becomes the first sentence of the brief: "You may only read. Edit nothing, run nothing, spawn nothing. Answer with the JSON object only." "Never substitute brainstorm-architect" holds here too: spawn the brain file, never an improvised architect role.

No AskUserQuestion (a headless harness, for example the office app that routes questions to an inbox): stage 03 still asks. Write the run files first, then end the turn with status needs_info carrying the at-most-four questions. When the harness resumes the session with answers, continue in resume mode from the run files (progress.md, decisions.md), never from memory of the earlier turn.

A harness that cannot write to Git (Codex in the office app: sub-agents inherit the parent's sandbox, Git metadata is read-only, and the host commits the worktree as one commit after the turn ends): stages 09 to 12 still run, inside the turn, before it ends. Stopping at stage 08 to "await the host commit" is wrong: the host commit comes after the turn, and nothing in stages 09 to 12 waits for it. On this harness each task's implementer is still a spawned sub-agent (spawn_agent, fork_turns: "none", briefed as the stage specifies: prompts/implementer.md plus the scripts/task-brief output) that edits the worktree and reports what it changed; the task reviewer is a second spawned sub-agent, never the implementer, that reviews the worktree diff (git diff, git diff --stat and git status are reads and are allowed; only writes to Git are not) and returns the report in the shape the stage names; a fix round spawns the fixer the same way. The controller never implements a task itself and never skips the reviewer, the fix rounds, the master gate or the completeness pass because no commit exists. When the harness cannot commit, "commit", "task branch" and "integration merge" in stages 09 and 10 mean the task's state in progress.md plus the worktree diff, and the host commit the harness makes after the turn stands in for all three. The master gate (stage 11) and the completeness pass (stage 12) run against the worktree diff instead of the branch. The controller records every transition in progress.md exactly as on Claude; the final report names the files changed instead of commits.

Resume, on every harness: the first action of any turn whose session already holds a run directory (docs/superpowers/runs/<run-id>/progress.md exists) is to read progress.md, decisions.md and the stage table, then continue from the active stage, recording the transitions it finds missing. A resumed turn never implements before the tracker says stage 09 is active: whatever the resuming prompt says ("continue", "go on", "finish it"), the tracker decides what continues, not the prompt and not memory of the earlier turn.

A superpowers:* skill that is not installed: the SDD review protocol is already inlined in prompts/ and scripts/, so nothing is lost there. For the others, do what the stage describes inline; the stage's files in the run directory are the requirement, not the skill name.

Red flag: implementing before the stage 01–07 files exist in the run directory is a violation on every harness.

Red flag: a resumed turn that edits source while the tracker shows stage 01–08 active is a violation on every harness. So is ending a turn at stage 08 to "await the host commit" on a harness that cannot commit.

The one gate, and files as the authority

Stage 03 asks at most four questions in one AskUserQuestion call. Those answers are the only unimpeachable requirements. Every later decision is a quorum adoption or an escalation: no third outcome, no controller override, no second approval.

Reconstruct the next action from progress.md, decisions.md, immutable results, evidence digests and Git — never from conversation memory. The schema is pipeline-auto/v1; there is no migration from pipeline-run/v1 or /v2. Foreign, missing, malformed or unknown schema is a read-only stop: change nothing, dispatch nothing.

Stage routing

Load only the reference the active stage needs. The rules in this file apply at every stage and win over any summary elsewhere.

Stage	Work	Route
01–07	Intent read, question synthesis, the gate, design and review class, spec, master plan, phase fan-out	references/planning.md
any	Question raised, quorum open or finalising, drift budget, escalation, quorum resume	references/quorum.md
08–10	Dial, task start, per-task gate, TDD, scopes, evidence, integration, debugging	references/execution.md
11–12	Master gate, contradiction routing, adjudicator, completeness, final verification, terminal report	references/review.md
any	Tracker writes, status, resume, reconciliation, decision actions	references/persistence.md

Dispatch	Template / agent	When
Intent readers	pipeline-auto-intent-reader ×3	stage 01
Brains	pipeline-auto-brain ×3 with prompts/brain.md	every quorum
Proposal brains	pipeline-auto-brain ×3 with prompts/brain-proposal.md	stage 02
Implementer	prompts/implementer.md, brief from scripts/task-brief RUN_DIR PLAN_FILE TASK_NUMBER	stage 09, one fresh per task
Task reviewer	prompts/task-reviewer.md, package from scripts/review-package RUN_DIR BASE HEAD	the per-task gate
Adversarial reviewer	prompts/adversarial-reviewer.md	any fired trigger, any review_class

Both agents run with exactly Read, Grep, Glob. Never add a tool to either — not even Bash "for one command": frontmatter allowlists tools, not commands, and a shell can rewrite decisions.md or the intent brief. Never substitute brainstorm-architect.

The SDD review protocol is inlined in prompts/ and scripts/; do not invoke superpowers:subagent-driven-development or superpowers:finishing-a-development-branch.

Rungs, strongest first

specified > code-evidenced > convention-cited > engineering-judgement > speculation

"Stronger" always means earlier in this list. A cluster's rung is its strongest member's rung, after demoting any member whose citation does not resolve to its claim. The adoption floor starts at code-evidenced and rises one rung for the rest of the run once five or more adoptions average above 0.90 — read it from current_floor, never assume it.

Escalating, exactly

Finalise the question as escalated, queue it now for the next stage boundary (even mid-phase), and set next_action: await-escalation-batch. Escalating never draws on the adoption budget.

Recording unresolved, open, deferred, or carrying it in the handover is not escalating. It asks nobody.

While a question is escalated, every task blocked on it stays blocked and nothing is dispatched on its axis — no trace, no fact-finding, no fresh quorum, no "safe", "additive" or "reversible" subset of the work. The hold lasts until a human answers, not until you judge the work cheap to undo.

Before opening a quorum, in this order

These checks run before a quorum opens. Once a quorum has returned, judge it by the adoption rules below — never retroactively un-ask it.

1. Already answered? If the approved spec or an adopted decision answers it, the question is not admitted to a quorum. Cite the line on the question record and resume the worker. No quorum, no decision entry, no budget.

2. Budget. Read quorum_budget(run_dir, phase=...) before any dispatch. Ceilings are BUDGET_PER_PHASE (3) and BUDGET_PER_RUN (10). Only a human answering an escalation raises one, to a stated finite value; at most two extensions per run, then the budget is terminal. If a ceiling is reached: open no quorum of any size — no worker anywhere opens one — lower no bar, and escalate with the adopted decisions listed. Hold dispatch and integration within the question's blast radius (in-flight work there finishes, publishes and is imported); independent work continues. A terminal budget stops the run resumably: nothing new is dispatched. You never grant yourself an extension.

3. Admissible (check_admissible), all of:

   • it blocks named work — a question blocking nothing is an opinion; discard it;
   • it is decidable from the repository, the spec and decisions.md — if it needs what only the user knows (budget, deadline, users, purpose), escalate;
   • it carries an axis and a blast radius from task | phase | run | contract;
   • it passes the options test and is one decision.

   Then dispatch exactly three brains.

Evaluating a quorum

Three valid responses is a precondition, not a strength. With fewer, the quorum is not evaluated — not now, not at a deadline, not through any guard, timeout or policy you write in advance. Two agreeing, well-cited responses are two responses.

• A missing response (its worker died, or context was lost): re-dispatch only the missing index, re-sent from its own persisted payload and checked against its digest — never rebuilt from current state. This is recovery, not a second chance. Never re-dispatch a brain that answered; never discard an answer to get a tidier set.
• A schema-invalid value (for example a rung not in the list above): never map, default or demote it. Re-dispatch that index once, with its full rebuilt payload — never "just fix that field", never with its answer pinned. The quorum waits on it. A second invalid response is a non-response: escalate.
• A brain's own question has no field in the schema; blocker is the only exit. A response asking for something else to be decided first is a non-response. Do not open a quorum on it, do not answer it yourself — not even "the other responses imply it" — do not re-dispatch with the premise supplied. Escalate the original question, naming the premise.

Adoption. Cluster by answer_key when options were named; without named options, answers share a cluster only if their consequences do not contradict (when in doubt they are different answers). Then compare rungs. Adopt only when the winning cluster is strictly stronger than the runner-up, at or above the current floor, fewer than two responses carry a blocker, nothing forecloses an irreversible axis, depth is within the cap, budget remains, and check_contradiction returns nothing.

• One cluster (unanimity) has no runner-up: the floor alone decides.
• Equal rungs never adopt, at the floor or at the top. No tie-break — not headcount, subset consequences, citations, recency, length or "least foreclosing". Escalate.
• Different answers alone are no reason to escalate. One cluster strictly stronger than the rest adopts, however many clusters there are.
• An adoption records the answer, the winning rung and the rung it beat, and Provenance: quorum; it consumes one phase and one run adoption. The adoption Q-<qid> is itself the grant: resume the blocked task with resume_task(..., decision_ref="Q-<qid>"). A re-asked question's adoption resumes the task too, under its new qid. After an escalation, the human's task.resume H-<n> resumes it once the escalation row is answered with that Resolution.

Recorded human decisions

If the winning answer — consequences included — requires a different option on an axis where an adopted decision has Provenance: human, reject it. No rung and no unanimity outranks a human's recorded answer. Record rejected-contradicts-human naming that decision's ID; it stays Adopted; no budget is spent; escalate (finalize_quorum queues the row). Every task blocked on that axis stays blocked — "the human decision is still in force, so work against it" is dispatch on a contested axis.

Review dial

The adversarial triggers — concurrency, authz, crypto, schema, migration, delete, regulated, public-api, large-surface — fire independently: any one suffices, whatever the diff's size and whatever the phase's review_class. final-only decides whether routine review runs; it never switches the trigger check off. A fired trigger dispatches the adversarial reviewer before the task completes.

You set each phase's review_class once, at stage 04, from the plan's classification, and never move it afterwards except through a ratchet whose trigger already exists — for the adversarial route, a CONFIRMED or unrefuted PLAUSIBLE finding returned by that reviewer. A ratchet record you write from your own reading of the diff is not a trigger. Never downward. The tracker enforces the move: (final-only, plan) → (required, ratchet) once, with a trigger from the closed list, and adversarial-finding or low-confidence-dependency only when the tracker already held that fact before the ratchet's transition. Lowering and withdrawing are refused, and so is deleting an imported phase row to re-add it.

Completeness critic items

The critic's classification is not yours to change. SPEC-NOT-MET is a finding for the fix loop. MISSING-FROM-SPEC is frozen, and the output is:

1. A section appended to the run's completeness-proposals.md, headed with the next unused proposal number (## CP-1, ## CP-2, … — never the literal <n>): Statement, Evidence (the critic's text), Traces to: none, Status: Frozen, classification verbatim.
2. That proposal ID listed in the terminal report.
3. Once every other item is finished — an open fix round completes first — next_action: complete-with-proposals. derive_next_action derives it from that file, and never while a fix round or other item is still open.

Nothing else: no task, phase, fix-round finding, quorum, backlog or handover note, and no disposition — deferred, out-of-scope, declined and closed are all reclassifications. The proposal is the user's to decide.

Rationalizations

Excuse	Reality
"Two agree at a strong rung — the strongest quorum available."	Three valid responses is a precondition.
"I record the degraded count (2 of 3) honestly."	An honestly recorded illegal finalisation is still illegal.
"Sealing at the deadline is arithmetic; the rule is written in advance."	A violation scheduled is the same violation.
"The re-dispatch completes the record; it is not a gate."	It is the gate.
"The other responses already settle the premise the brain raised."	You do not answer questions you are routing.
"Only evidence-gathering, no adoption." / "The tie shows the question is malformed."	Nothing is dispatched on a tied axis. It is escalated.
"The human decision stays in force, so work proceeds against it."	Blocked until a human answers.
"Escalation is for questions the repository cannot answer." / "Idle brains cost nothing."	An exhausted budget escalates regardless. It caps authority, not cost.
"I decline it, closed in this run; reviewers can reverse it."	Declining is a disposition. Record the proposal.
"It crosses a trust boundary, that is the trigger, and I wrote the ratchet record."	A self-authored trigger is no trigger.
"Three different answers means the question is underdetermined."	Only when they tie on rung. A strict gap adopts.
"The spec already answered this, so the quorum's adoption is void."	The check runs before dispatch. A returned quorum is judged by the adoption rules.

Red flags — stop and re-read the rule

• Acting on fewer than three valid responses, now or "if it has not returned by…".
• Writing "not a gate", "non-blocking" or "degraded count".
• Dispatching anything on an escalated or contradicted axis.
• Writing unresolved, deferred or "carry to handover" instead of escalated.
• Opening a quorum without comparing the budget counters to the ceilings.
• Changing review_class after stage 04, a ratchet record with no fired trigger, or a label over a critic's classification.
• Pushing, publishing, opening a pull request, or merging into main/master. Success is a clean committed feature branch and a report that leads with every decision the run made without asking.
• A resumed turn editing source while the tracker shows stage 01–08 active, or ending at stage 08 to await a host commit when the harness cannot commit.