Run the queue with /next

What the queue is

Every plan you save gets a row in your project's analysis index, with a status. The plans whose status is Ready to run, on the branch you are on, are the queue. /next takes them in number order, builds each one, opens it in your browser to check that what the plan promised is there, and writes back where each one got to as its status, which the index shows. The index and the plans live in the toolkit, in the Projects section, so those write-backs never become commits in your repository.

Plans on another branch are not run, whatever their status; the run tells you they exist. A plan only moves to another branch when you ask for it. A plan that rests on another one runs only when that one is on the same branch.

It does not ask before starting: each plan was already confirmed in the conversation that planned it. What it does first is tell you which plans will run, which it leaves alone, and why. That is the moment to narrow the queue if you want only some of them.

An empty queue is an answer, not a problem.

The statuses in the index

A plan's status is kept by the toolkit beside the document, never written inside it.

Ready to implement is a different status, and the queue never takes it. It belongs to a business analysis whose scope is settled and which still has to be planned with /plan-prompt. Ready to run is the far end of the same work: the technical plan is closed and only the building is left.

Plans that rest on other plans

A plan can name the plans it rests on. It runs only once each of them is implemented, already built earlier in the same run, or ahead of it in the queue. When one is not, the plan is skipped for this run and named on the opening announcement with everything it is still waiting for. Its row stays at Ready to run, so the queue asks again the next time it is read.

When what it waits for is blocked, waiting, paused or rejected, nothing will move it on its own, and the report says so: that one is somebody's to act on.

A plan can also wait for a fix in another repository. That case is in Send a defect to the repository that owns it.

Several plans at once

Every plan is built in its own git worktree — a separate working copy of your repository — even when the queue holds just one. Up to six are built side by side. Each one that comes back is merged into your working branch, and only then is it checked in the browser.

Each plan is built from what it says. Its technical plan, at the end, is guidance: where the code turns out different from it, the build decides, the run records what it found in the plan, and nothing stops to ask you. A technical choice you answered while planning is followed as you answered it. A plan carrying a drawing you approved is built toward that drawing, and the browser check compares the finished screen with it.

There is one browser, so the checks run one after another, in batches. A batch holds up to five plans that need the same browser state: the same user, the same team, the same settings. A large plan gets a batch of its own.

Some plans have to wait their turn:

• Two plans naming the same file are never built at the same time. The later one waits until the earlier one is merged, and builds on top of it.
• A plan that reshapes screens across the whole application runs last and alone.
• A plan resting on another waits until that one is merged.

You see one table when the run announces the queue, again after each step, and once more at the close — whatever path the run takes, and even when the queue holds a single plan. It counts what is done, building, waiting for the browser, being checked, waiting for you to press a button, queued, waiting for their correction, waiting for another plan, waiting on your answer, blocked, or rejected; a status with nothing in it still gets its row. The table is how you know the run is still working, so it is never skipped: it opens the message for each step, and a step reported without it is a fault the run puts right in that same message. A plan that takes a long time to build shows nothing new of its own until it comes back: it already counts as building from the table that showed it starting, and the last table you saw is still where the run stands.

The table keeps the same rows, in the same order and with the same columns, for the whole run, however long it gets: only their names are in your language. Ask for the status in any words — "status", "update the table", "how is it going" — and the answer is that table as it stands. A plan being rebuilt for a correction shows as building again, then as waiting for the browser and being checked, like on its first try, with "attempt N of 3" beside it. A plan under "Waiting for their correction" is only one whose rebuild has not started yet, usually because there is no free place yet, or another plan it must wait for is still building.

Some controls refuse to be pressed by the browser extension, such as the buttons on a payment provider's test authentication page. When that happens, the run prepares one clean tab, tells you which tab and which button to press, and checks the result itself.

Only when your assistant cannot isolate an agent in a worktree do the plans run one at a time instead: build, then check, then the next. It is the same queue, only slower — it still picks up new plans, asks you nothing about the work, and shows you the same table at the same moments.

Plans that turn up while it runs

The queue is read again after every step. A plan you save while the run is working, or a plan you unblock by answering its questions in another conversation, is taken up by the same run — you do not have to start it again. When nothing is left to build or check, the queue is read one last time: anything new keeps the run going, and if there is nothing, the run closes and reports. It never sits waiting for plans that do not exist yet.

A question written into the plan

The run never stops to ask you anything about the work, or whether to keep going, whether it is building several plans or one — the one thing it may ask of you is a button only you can press. If you ask it something while it runs, it answers and keeps going. When a plan needs a decision only you can make, the question is written into the plan itself, under Open questions: numbered, with its options, what depends on the answer, and an empty answer line. The plan's row moves to Blocked, whatever did not depend on the answer is built and kept, and the rest of the queue keeps going.

You answer in another conversation, whenever you want, and the assistant there writes each answer into the plan. The next time the queue is read — or as soon as you say so — each answer moves into the section that records the questions asked and the answers they got, the Open questions section goes, and the plan returns to Ready to run as long as nothing else stands against it. If the run is still going, it picks the plan up again itself. An answer line left empty keeps the plan blocked.

Nothing is asked at the end either: the report lists each plan waiting for answers, with its questions written out in full.

When the check fails

When the browser check finds that something the plan promised is not there, it writes the correction into the same plan, as a numbered entry of its Validations section: what failed, how it was reproduced, the solutions considered and the one chosen. No new document and no new number is created. The queue builds the same plan again from that entry — redoing only what is not done — and checks the whole plan again.

That cycle runs three attempts at most, counting the first build. A pass marks the plan as implemented. A third failure blocks the plan with its three entries in view, the last one opening with a rethinking of the plan, and sends it back to /plan-prompt: a plan that fails three times needs rethinking, not a fourth try.

Only a failed check whose entry chose a solution enters the cycle. A check that could not run — no browser connected, credentials nobody has — blocks the plan with what was missing, and the run moves on.

Plans written by /design-catalog

A plan /design-catalog wrote gets one more check. Once the browser check passes it, and before it is marked implemented, ux-designer opens the screens it built and judges them against your catalogue and your identity manual. When they follow both, the plan is implemented. When they do not, the designer's correction is written into the same plan's Validations section, and the queue builds from it, checks it and reviews it again, within the same three attempts; a plan that spends them goes to /plan-prompt, like any other plan. You are not asked about that correction: you already confirmed the plan, and the correction only brings what was built back to it. This review never runs beside another check in the browser, and plans written by any other command do not get it. How those plans are proposed and written is in Design a product catalogue.

What a run leaves behind

Each plan's status in the index, each checklist row marked done or blocked with its reason, and the commits that built the code. Implemented plans stay until their code reaches your main branch, and /finish, run from there, removes them; to clear rejected ones too, or to renumber, use Delete finished in the Projects section — see Your projects and their documents. The report at the end says what ran, what passed, what is blocked and where each blocker goes, and lists every question waiting for your answer. Nothing is pushed.

Next

• Planning before building — where the plans in the queue come from.
• Send a defect to the repository that owns it — what a plan waiting on another repository is waiting for.
• Pending findings — where the things a run noticed, and was not asked to fix, are written down.