The deliverable is the curve, not the artifacts.
This is the viewing surface for an instrumented, budget-governed agent loop. It shows the ticket graph the loop reasons over, what it is allowed to spend, what would make it stop, and — once it has run — how quality moves against turn count. The design record is CLOSED-LOOP.md; the architecture is LOOPS.md.
The machine
the control diagram — how a turn comes to exist, and what stops one
The three inputs along the top are outside the loop — nothing inside it can change them, which is the whole answer to “who expands the number of workers?”: nobody in here can. The allocator only distributes seats the operator has already granted.
Inside a turn
what one seat actually does, and where each claim gets checked
The agent has no Bash, no git and no network — so it cannot reach a branch, cannot write the ledger, and cannot run its own acceptance test. Every gate below runs outside the turn, which is the only way “done” means anything.
Who does what
why the seats are typed rather than fungible
Fungible seats fail specifically: with demand reading implement, the planner never
runs and the queue starves; the other way, the backlog inflates and nothing gets built.
The ratio between plan and implement is the producer/consumer
ratio — expressed as headcount rather than as hope.
How the gain is controlled
Three separate things, often confused for one.
The graph
Everything the loop has ever been asked to do. Finished work is hidden by default — it is nine tenths of the graph and none of the remaining question.
how to read it
Dependency edges run left to right: a bead sits one column past its deepest dependency. Dashed grey edges are parent links. Blocked-ness is derived, never stored — close a dependency and its dependents become schedulable with no edit to them. Click any bead. Findings and dead ends that nothing links to are memory rather than structure — they are listed under what the loop remembers instead of padding out the first column.
Beads are grouped into lanes by the epic they hang off. That is the closest thing here to a phase: one lane is the loop machinery, the other is the thing it is being pointed at, and work under a closed epic is finished scaffolding rather than current business. Showing every done bead makes the first column three hundred rows tall, which is a picture of the archive and not of the work.
Ready queue
Ordered by priority, then by how much finishing it unblocks, then by age.
why that middle term is the point of having a graph
A ready bead with eight dependents is worth more than a ready leaf of the same priority, and a flat list cannot express the difference.
Asks — what the machine wants a human for
Every other input on this page is derived: the graph, the gates, the findings, all of it produced by the loop from things the loop already had. An ask is the one arrow pointing the other way. It gets filed when a turn hits a question no gate can settle — is this fair, does it feel good to play, is this the game we want — and guessing at those is how a loop gets very good at what it can measure and blind to everything else.
An ask never blocks. Answer one whenever you like — next week, out of order, or never — and nothing is parked waiting.
why asking is safe, and what makes an ask valid
An ask carries no dependencies, nothing waits on it, and its kind is permanently unschedulable, so the fleet cannot pick one up and answer it by guessing. The turn that asked ended immediately and will never see the reply; the answer lands as a decision that a later turn inherits as memory. That indirection is what makes asking safe. Each one must say what to do, what to watch for, and what changes on each answer — the validator refuses an ask that cannot.
answers are signed, and they are yours
Signing in uses the shared ATProto OAuth
worker, and an answer is written as a com.minomobi.loop.answer record in
your own repo — not ours. We store nothing, you can delete it, and anyone can verify who
said it. An unsigned box on a public page is a box anyone can fill with anything, which is worth
less than no box at all when the thing being collected is taste.
What the consent screen will ask for. This site requests a narrow
scope — atproto plus write access to com.minomobi.loop.answer
and nothing else — so Bluesky shows you one collection rather than the seventy-collection union
every mino.mobi site shares. That collection is now in the auth worker's metadata ceiling
(mino-auth, deployed 2026-08-05, version c88fafac), which is what
makes the narrow request grantable at all: an authorization server only issues what the client
metadata declares.
If the ceiling and this page ever fall out of step again — they deploy from different branches —
sign-in falls back to the broad union rather than failing. A longer consent screen is a worse
experience than a short one; an identity you cannot obtain is worse than both.
The decision log
Nobody signs off inside a turn. Judgement calls are made, recorded, and reviewed here afterwards.
why review happens after the turn, not inside it
A worker that hits a judgement call makes it, records what it chose and what would reverse it, and carries on — it cannot park a turn waiting for a person. Human review happens here instead, at a coarser grain than the turn, over what was decided rather than in front of it. Decisions tagged answer came from the operator via an ask above, and they are the only entries here the loop could not have produced by itself.
What the loop remembers
Findings and dead ends. Never scheduled — read before work starts, so that turn 30 does not rediscover what turn 4 already paid for.
The curve
Judge score against turn count. This is the measurement the whole programme exists to take: does turn 20 improve on turn 19, or churn?
The governor
The budget is a controller, not a limit — the loop reads its remaining capacity and decides where the marginal turn pays. All three stop conditions are live; a loop that cannot stop is the failure mode, not the feature.