The agent pipeline that turns an idea into merged code, and the rules that decide what a machine may do without a human reading. This page explains the ten loops, who runs each one, how far each is automated today, and where a human still stands.
68ae8bf8 (2026-09-11) — not maintained. Live data: docs/registry/LOOPS.md (the registry wins when they disagree), docs/registry/hard-stop-globs.md (INT-0006), and the ruling record under docs/brainstorm/.A loop is an agent that runs the same kind of task repeatedly and can tell whether it made progress. The test is the verifier: every loop declares a machine-checkable Done = that can come back false because the work was not done. No verifier, no loop — it is a command.
N seen · N admitted · N skipped ….qiiub-work (the engine that builds), qiiub-pr-open, qiiub-pr-merge, qiiub-pr-review (the gate).qiiub-doctor, qiiub-qa-sweep, qiiub-module-scorecard (consistency is not progress).Idea to merged code, left to right. Solid boxes are loops or drivers; dashed boxes are the steps a human takes today. Select any box to read what it does, who runs it and what gates it.
Select a box above.
Two side paths are not drawn. The Assembler (LOOP-07) carries an admission straight to PRs without issues, when a piece of work should not be split. The loop-design coach (LOOP-02) designs new loops and reads this registry to avoid building one that exists.
Canonical names follow qiiub-<object>-<action>; friendly names are for prose. Automation is what runs on main today, not what is designed.
| # | Canonical | Friendly | Does | Runs as | Automation today | Human gates |
|---|---|---|---|---|---|---|
| 01 | qiiub-intent-newqiiub-intent-new --import | Workshop | Turns a raw idea, or an existing document, into a filed intent under docs/brainstorm/. Research fan-out with a contrarian, decision batches, then two fresh-agent verifiers: grounding (every claim is true) and buildability (a reader of the intent alone can plan a build). | a person, on demand | on demand | decision batches · design pick · the publish PR |
| 08 | qiiub-intent-promote | promote | Copies a filed intent into docs/admission/NNNN-slug/. Refuses unless the filing PR carries both verifier verdicts. A zero-information-loss verifier checks the copy. | a person | on demand | the Greenlight PR — its human merge is the admission (R-0002) |
| 10 | qiiub-admission-compile | Drafter | Compiles an admitted pitch into its Build Sheet: requirements, acceptance-criteria, golden-assertions, guardrails. A second pass emits seed bodies — only after a human writes seed-plan.yml. Writes files in a working tree and nothing else. | a person, pointed at one admission | on demand | every emission is reviewed before it is stamped or merged |
| 06 | qiiub-intent-decompose | Seeder | Files the Drafter's seeds as GHES issues after an adversarial coverage check and one human yes for the whole set. Does not decompose — that is the human's seed-plan.yml. --release reports which Blocked by #N tickets could be released. | a person | seeding on demand release report-only | the filing yes · the ledger PR |
| 07 | qiiub-intent-assemble | Assembler | Carries an admission straight to PRs without issues. Batched interview, one plan approval, then parallel builders in isolated worktrees (cap 3) and an adversarial reviewer that diffs the tests. Coverage lives in qiiub-work and is cited, not copied. | a person | on demand | interview · plan · PR-open |
| 05 | qiiub-issue-classify | Router | Sweeps the open backlog and classifies each issue: VALID, ALREADY RESOLVED, NEEDS RE-SCOPE, DISPUTED, INCONCLUSIVE, with a refuter. Every VALID row names its engine. Emits a ledger and an apply script by PR; writes to no ticket. | a person; --sweep exists | classify on demand dispatch report-only | one yes per verdict class · the ledger PR |
| 03 | pr-inspect (workflow) | Inspector | Reviews a PR at its head: cheap gates, then a two-pass FINDER → VERIFIER over a checkout, then one stamped comment (INT-0001) with a four-value verdict. Advisory: cannot approve or merge. | GitHub Actions | automatic on open, ready, and push when labelled inspect:failed | the merge |
| 09 | qiiub-pr-sweep | — | A tick that puts every open PR in exactly one bucket and dispatches the Inspector on the five kinds of head no automatic trigger reaches (green then pushed, never stamped, …). Its only outward act is workflow_dispatch. | vmiller's session on vm-qiiub-dev-lnx-001 | running session-scoped; stops when the session ends | Gate A (self-test per classifier version) · Gate B (R-0019) |
| 04 | qiiub-pr-fix | Fixer | Reads the Inspector's stamp, prepares a fix for every current blocker on a local branch, self-reviews with a second adversarial agent. --all walks the queue serially. A 2-bounce stop rule caps the fix loop. | a person | propose-only — never pushes | every outward act |
| 02 | qiiub-loop-design | the coach | Designs other loops. Socratic, verifier before architecture; files a one-page spec and scaffolds the skill only after approval. Reads this registry so it does not rebuild an existing loop. | a person | on demand | the spec approval · the PR |
Two rulings signed in September 2026 fix the authority model. The short form: every act up to the merge is delegable to a machine; the merge is human; and whether a machine may be the reviewer of record depends on which paths a PR touches.
Product code — apps/, packages/, most of src/. The verification stack's verdict is the review: an Inspector pass at the PR head plus the gate at APPROVE-READY on the same SHA, with every required check green. The machine may post that approval as a machine. The human act is the merge, and the merger reads the verdict, not the diff.
Not mechanical yet. Branch protection requires a CODEOWNER approval and no bot is a CODEOWNER, so today this tier works only through the interim carrier below.
47 path entries: money math, tenancy, security, migrations, tests, workflows, CODEOWNERS, the skills, the registries, the signed rulings, the gates' own controls. A human CODEOWNER reads the diff and approves in their own hand. The gate posts a comment, never an approval — its Guard 3 refuses. A mixed PR is hard-stop.
The membership test: a path belongs when a wrong merge on it would change what decides the machine's authority.
| Guard | Reads | Approves only if | Otherwise |
|---|---|---|---|
| 1 · Carrier expiry | today's date (UTC) against 2026-09-30 | the date has not passed | comment only, on every path |
| 2 · Required checks | the required contexts from branch protection, every row for each | all are SUCCESS — none pending, none failing | comment naming the pending or failing checks |
| 3 · Hard-stop | hard-stop-globs.md from origin/main, via the shared matcher | no changed file matches; the list was readable | comment naming the hard-stop paths; a human CODEOWNER approves |
All three are re-evaluated immediately before the approval fires, because a push during the wait can change what the review saw. Each guard has a control shown red against a mutant; an approval is possible only when all three clear.
F5 is a ledger of blind human reads against Inspector stamps on PRs outside the hard-stop list. It is not the entry gate to the machine tier — it is the demotion instrument. One false pass (Inspector pass, human fail) or one merge that has to be reverted returns the tier to human review the same day; coming back needs thirty clean rows. The bet is bounded because it can be taken back by one row.
The adoption ladder, as the registry measures it. Nothing here is a task list — the items that move a stage are GHES issues.
docs/admission/ exists and both signers cite it.status-board-drift.yml is advisory and never runs per-PR. The registry's Stage-4 re-grade to that reading is still owed.--all, --release, the sweep). What is missing is authority: the release leg writes to no ticket, the Fixer waits on the R-0005 cage, and a quiet tick that acts on nothing is not success.What actually happens when a product spec goes through the pipeline right now — with the four places a person steps in. The example is POS-SALE-024, a small v1 spec with no open questions; any spec follows the same shape.
qiiub-intent-new --import docs/design/pos/sale/POS-SALE-024-item-not-found-sound.md. The Workshop runs grounding and buildability; both must pass. It opens the filing PR only on an explicit yes.qiiub-intent-promote reads the filing PR's verdicts and emits docs/admission/0005-…/. It opens the Greenlight PR.docs/admission/ is hard-stop, so a human CODEOWNER approves and the merge is a principal's.qiiub-admission-compile 0005-… emits requirements, acceptance criteria, golden assertions and guardrails from the pitch alone. A human reviews the emission before it is stamped.seed-plan.yml. How the work splits into issues is a human judgment and appears in no compiled surface. This is the one creative step in the middle.qiiub-intent-decompose refutes coverage, asks one yes for the set, files the issues and reads each one back.qiiub-issue-classify classifies the new issues VALID and names qiiub-work as the engine. It reports what it would dispatch./qiiub-work <issue> for each issue. The engine plans, builds in a worktree, tests, and opens the PR.POS-SALE-024 touches src/QIIUB.Api/Features/, which is hard-stop — so the gate comments and a human CODEOWNER approves in their own hand. A frontend-only PR would go through the machine tier instead.qiiub-pr-fix prepares the fix on a local branch and self-reviews it. It does not push; a person applies it.Each step leaves an artifact the next one reads — the filed intent, the admission folder, the Build Sheet, the issues, the stamp, the proposal. Nothing passes between steps by memory.
The eleven steps above, as they actually read in a session. Purple turns are you typing; dashed turns are something happening without anyone asking; the four bordered turns are the places the pipeline stops and waits for a person.
Read the spec. Fanned out research with a contrarian. Two decisions are yours before I draft:
1 · Does the sound play on every failed scan, or only on an unknown barcode?
2 · Does it respect the terminal's mute setting?
Unknown barcode only. And yes — mute wins.
Drafted. Two fresh agents checked it, each shown red against a mutant first:
GROUNDING pass every factual claim re-verified.
BUILDABILITY pass a reader of the intent alone produced a build plan.
Publish?
yes
Filing PR open. Both verdicts are in the squash message — promote reads them from there.
Filing PR carries both verdicts — proceeding. Censused the next free number myself: 0005. Emitted docs/admission/0005-item-not-found-sound/, byte-identical to the source apart from the header rewrite. zero-information-loss pass
Greenlight PR open. I do not merge it.
Merging the Greenlight PR is the admission. docs/admission/ is on the hard-stop list, so the gate could not approve it — jflores read the diff and approved in his own hand, and mgandia squash-merged.
ADM-0005 now exists. Nothing before this point was binding.
Compiled from intent.md alone: 6 requirements, 9 acceptance criteria, 4 golden assertions, 3 guardrails. Anchor coverage checked both directions — no requirement without a criterion, no criterion without a requirement.
No seed-plan.yml, so I emitted no seed bodies. That file is yours.
You write seed-plan.yml. How the work splits into issues is a judgment that appears in no compiled surface, and two implementations of one slicing rule would drift. Three seeds: the sound asset, the scan-failure trigger, the mute check.
(pass two — selected by the plan being there, not by a flag)
Three seed bodies written to the worktree. I have taken no outward act.
A fresh refuter went at the three seeds against the Build Sheet looking for a dropped, doubled or invented requirement. It found none.
File all three? One yes covers the set.
yes
Filed, and read each one back from GHES: headings, ownership, part:pos, priority:P2 all present on all three. Ledger PR open.
All three VALID; a refuter failed to overturn any. Engine for each: qiiub-work.
Would dispatch 3. Dispatch is report-only, so I invoked nothing. Ledger and apply script are in the PR.
Somebody runs the engine. Nothing mechanical is missing here — the dispatch surface exists and is fail-closed. What is missing is a recorded decision granting it. Until then vmiller types it.
/qiiub-work 1803Premise still true against main. Plan posted on the issue. Built in an isolated worktree, tests first, house gates green. Coverage found file-level evidence for every requirement in the seed.
PR open with its evidence pack.
Fired on opened, nobody asked. Cheap gates, then FINDER → VERIFIER over a checkout. Stamp INT-0001 posted at reviewed_sha: CHANGES-NEEDED 2 blockers. I cannot approve or merge — the verdict is advisory.
Read the stamp. Prepared both fixes on a local branch. Verifier ladder green, and a second adversarial agent confirmed no test was weakened and no Inspector comment edited.
Proposal drafted as INT-0002. I am not pushing — propose-only until the cage exists. Apply it yourself.
New head pushed. Re-stamped: pass. (Had this been a green PR that was then pushed, no trigger would have reached it — pr-sweep exists for exactly that hole.)
Three guards, re-evaluated right before the approval would fire:
1 carrier 2026-09-30 has not passed.
2 checks every required context SUCCESS.
3 hard-stop this PR touches src/QIIUB.Api/Features/.
Guard 3 refuses. I am posting a comment, not an approval — and the comment opens with the line saying a machine composed it.
jflores reads the diff — on a hard-stop path the human is the reviewer of record, not a reader of a verdict — and approves in his own hand. mgandia squash-merges.
Had this been a frontend-only PR, the machine tier would have applied: the gate's approval would have stood, and the merger would have read the verdict instead of the diff. The merge itself is human either way.
Eleven steps, four stops. Everything between the stops is a machine reading an artifact another machine wrote and leaving one behind — and every one of those machines is willing to come back and say the work was not done.
| Term | Meaning |
|---|---|
Verifier / Done = | The machine-checkable condition a loop must satisfy. It must be able to come back false because the work was not done. |
| Mutant · negative control | A deliberately broken copy of the thing under test. Every checker is shown red against one before it is trusted; a check that has never failed has proven nothing. |
| Vacuous pass | A check that reports success without having examined its subject — zero files scanned, an empty list treated as clean. The most common failure class in this repo. Every check must report what it actually checked. |
| Fail closed | When an input is missing or unreadable, treat everything as blocked rather than nothing. |
| Report-only · propose-only | The loop computes the outcome and shows it — a dispatch it would fire, a fix it would push — but takes no outward act. A person does. |
| Hard-stop · INT-0006 | The registered path list (hard-stop-globs.md, 47 entries) where a human must be the reviewer of record. Read from origin/main by every consumer, so a PR cannot clear itself against a list it edited. |
| T1 / T2 | T1: the Inspector's verdict is advisory and a human reads. T2: the verdict is load-bearing and stands unread. R-0037 rules T2 active outside hard-stop paths, mechanical once a machine approval can satisfy branch protection. |
| F5 | The blind-read ledger measuring how often the Inspector passes something a human fails. The demotion instrument for T2. |
| INT-0001 · stamp | The Inspector's one comment per PR head, with reviewed_sha and a four-value verdict. Everything downstream reads it. |
| Gate A · Gate B | The two human grants a loop needs before it acts outward: a per-version self-test grant, and a signed ruling for the class of act. |
| The cage · R-0005 | The pre-receive hook plus bot identity that would let the Fixer push to a scoped ref space. Installed, enforcement=disabled. |
| Ruling · R-NNNN | A signed decision, filed as a vehicle under docs/brainstorm/ with a row in the ruling record. Signed text is never edited; corrections are appended. |
| Grant | Named, one-time, bounded permission for one outward act — a push, a PR, an issue. Consumed on use. A machine takes no outward act without one. |