loop.the ticket graph & the run loading ↖ mino.mobi

The deliverable is the curve, not the artifacts.

…
–of 7 gates built
–turns taken
–ready for the fleet
–waiting on you

    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.

    THE OPERATOR — outside the loop enabledmay it run at all seats — Show hard lease untiluntil when TICK — the reactor gates: enabled · lease · graph lints · blast radius ALLOCATOR — distributes S, never raises it demand-driven: staffs the bottleneck planmakes work implementdoes work review ×1promotes judgescores mergeintegrates THE GRAPH — the queue unbounded by design. Growing it is free THE BARRIER — sprint close one integrator run, then deploy + score plant.minomobi.com STOP conditions queue depth → backpressure a seat frees → continuation gate failures never buy staff — that way is a stop, not a hire
    the allocator — the only thing that moves review ×1 — the gain control feedback, not command

    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.

    BRIEF ticket + every dead-end & finding THE AGENT Read/Write/Edit Glob/Grep only CONTAINMENT diff inside the declared paths TICKET GATE the bead's own commands, run here OUTBOX validated: no asking, no self-promotion LEDGER + verdict ONE SEAT, ONE BEAD — every box after the agent is a check it cannot perform on itself a failed ticket gate blocks `done` from the ledger …and the turn is recorded as a failure, so the curve keeps an honest point. Turn 1 had no ticket gate: the agent reported done, wrote two files, and the commit step never staged them. Green, and nothing produced.

    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 blocked proposed done knowledge — never scheduled

    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.