The Software Factory

A row qualifies when it is proposed, its prerequisites have shipped and its risk class is R3 or lower (the six classes are set out below). Rows for design or review work stay with a person. Each slice gets four hours a try and two tries. Uncommitted work left in the repo stops the run before it starts, and the first slice that fails outright stops the chain with everything left as it is.

A slice that meets a question only a person can answer is parked in an Awaiting ruling lane, and the chain moves on to the next row. Once it is ruled on, the row goes back in the queue. A slice that stops short for a reason the runner cannot name gets its second try on the next setting in a short fixed list of models.

Since 28 September the chain runs on a copy of the runner's code, taken when Start is pressed and kept outside the repo. A slice that changes the runner ships like any other, and the change takes effect at the next Start, which lists it first. A slice that touches the safety settings themselves, such as an assistant's permissions or the block on download commands, stops the chain until a person has reviewed it. The roadmap and the tests are not copied, so a slice can still change those.

The runner does not take a session's word for it. A slice counts as shipped only once its row is in the shipped register. Each slice commits its work on this machine as it goes.

The chain runs on a flat-rate Claude plan, so it has no dollar limit of its own. The cost shown on the board is what the same work would cost at API list prices. When the plan runs out of hours, the chain waits and checks again every 15 minutes, for up to six hours, and picks the same slice back up once the plan allows it. Waiting does not use one of its two tries.

With notifications switched on, a phone gets a heads-up when the work the chain may take is nearly gone, a count when closeout steps are confirmed, and the reason when the chain stops. A stop that needs a person is marked urgent. Every slice also records which model and effort it ran on, so what a run cost can be compared against what it was given to work with.

Which slices run and in what order, approvals, and what happens to each review finding. Since August the AI settles routine bookkeeping questions itself, under a standing instruction, and each ruling is recorded as the AI's, made under that instruction. A question that needs a person stops the slice, and in the chain that slice is set aside so the queue keeps moving.

It writes the kickoff, builds the slice, runs the checks, writes the records and suggests the next step, with one clear recommendation. In the chain it also closes each slice and commits it.

Written before work starts: what the slice will do, what is in and out of scope, the rules it must follow (quoted by ID), how success will be checked, the named checks, and a spending limit when models are involved. The closeout is judged against exactly this.

Short by rule, about 200 words: the outcome (shipped, partial or abandoned), the commits, what changed, and each check with its result. Two fields can never be left out. Manual check says what to click or run to see the result directly, and User docs says what changed in the user guide. A slice with nothing to show writes N/A and says why, and a slice that changed Studio's code cannot use N/A for Manual check. Since 8 September the manual check is written as a card: where to go, the steps to take, what a pass looks like and what a failure looks like.

Nine fixed steps: file the record in its phase document, update the phase index, the user guide, memory and the changelog, then move the row to the shipped register, tidy the queue, commit, restart the server if it changed, and check that the click pass can be built. The row moves near the end, because updating the docs is part of the slice. New rows are added the moment they exist, including every deferral. Since August a command drafts the four follow-up entries from the closeout record, and marks every sentence that needs a person.

The reviewer's verdict is pasted into the reviewed document word for word, and every finding gets a written decision: fold it in (with the edit), reject it (with the reason), or defer it (with the row that now owns it). The AI suggests each decision. A person makes it.

Every review returns a verdict (GO | CONDITIONAL-GO | NO-GO), findings ranked most severe first, answers to the document's open questions, and a list of what it tried and failed to break. The verdict does not decide on its own. A NO-GO whose findings are rejected can still ship, and the record says so. What the reviews have returned is on the codex page.

The real work queue, inside the roadmap. Every row has an ID, a role, a risk class and its gates, and every slice starts from a row. The roadmap page shows it in full.

Small fixes to how Studio looks and behaves, with no ceremony: an entry goes in whenever something is spotted. Screenshots attach by file name, so an entry never needs editing to gain an image. Fixes launch from Build mode one at a time or as a batch.

Changes that never reached the docs, found by comparing the git log with the changelog, then worked as ordinary doc updates.

Docs-only work moves at the speed of conversation. Work that spends money must set a limit first, and work that writes or grants power needs a written design before any code. The risk classes make that a rule, so it never rests on a judgement made in a hurry.

Every slice ends with a clear outcome and a recommended next step. The Manual check field means a claim can always be tested by hand, and an N/A has to come with a reason.

The documents hold the whole state of play. The AI's memory points at them and never replaces them. A new session on a new machine can pick up from the repo alone.

An author reviewing its own design shares its own blind spots. A fresh reviewer with a fixed prompt does not. Disagreements are recorded in plain view, and a person makes the call.