The run loop

You do not have to know any of this to use Styre. It is here because trusting a tool that writes code on your behalf is easier when you know what it does with its time.

A run moves through five phases. Every step is written down before it runs, so a run that dies can pick up where it stopped instead of starting over.

First: provision

Before any of the phases, Styre installs what your project needs in order to build — the prepare command for each component in your profile.

This runs first for a reason: a missing toolchain should stop a run in its first minute, not after an hour of work that then cannot be verified. If provisioning fails, the run stops immediately rather than retrying.

1. Design

Styre reads your ticket and plans against your actual repo, reading files, tests and config before proposing anything.

The plan is then broken into work units — independently buildable pieces, each tagged with the kind of work it is and the files it expects to touch. How many units come out decides the shape of the rest of the run: a single-unit change takes a shorter path, while several units get the plan itself reviewed before any code is written.

Design is also where your acceptance criteria become tests. Each checklist item on your ticket gets a test written against it before implementation starts, and each must fail against today’s code — a test that already passes proves nothing. This is why criteria naming a specific observable output matter so much; see Writing a ticket.

2 & 3. Implement and verify

These two interleave. Each work unit is built and then checked before the next one starts, rather than everything being written and tested at the end.

For each unit:

• An agent writes the code and its tests in an isolated worktree.
• Styre reconciles what actually changed against what the plan said would change.
• Your build and test commands run against the result.
• The acceptance tests written during design have to come back green.

If anything comes back red, that unit loops — it goes back to be fixed and re-checked, with the failure fed back in. The next unit does not start until this one holds up.

The agent does not commit, and cannot reach your accounts

Agents work inside a temporary worktree, and that worktree is the only thing they can write to. They get no GitHub, tracker or branch tools, and your GITHUB_TOKEN, LINEAR_API_KEY and JIRA_API_TOKEN are stripped from their environment. Styre holds the credentials and makes every commit itself.

4. Review

A separate reviewer reads the finished work cold, with no memory of having written it, against the plan and the repo.

Blocking findings send the work back. This is the last thing standing between the change and your pull request, and it is deliberately not the same agent marking its own homework.

5. PR

Styre commits, pushes the branch, and opens the pull request against your default branch.

It then takes one look at CI status and exits. It does not wait for checks to go green, and it never merges. What you get is a branch, a pull request, and a run that has already worked hard to make it correct.

When something goes wrong

The default response to a failure is to absorb it and carry on, not to stop and ask. A red build, a failing test, a blocking review finding — each routes the work back to the step that can fix it, carrying the failure with it.

That looping is bounded. Styre gives up and asks for a human when:

Condition	Why it stops
A single step fails 3 times	Something is wrong that retrying will not fix.
The same failure repeats twice in a row	The loop is not learning, it is spinning.
An acceptance criterion still fails after 2 rewrites	The criterion probably cannot be tested as written.
Provisioning fails at all	The environment is wrong; retrying does not help.
The run makes no progress for 3 rounds	Nothing is advancing.

Individual steps are time-boxed too — around an hour for design and review, half an hour for implementation work, less for verification.

A run that exhausts its budget exits nonzero and tells you why. A run that dies for a reason that is not its fault — a session limit, or running out of credits — parks instead, keeping its state so you can pick it up later. See Recovering a run.

Why the verdicts mean something

Everything that decides whether work is done comes from something that actually ran: your build, your tests, the acceptance tests, and a reviewer that did not write the code. No step grades its own output, and no agent’s self-assessment counts as evidence.

That is the whole reason the loop is shaped this way, and it is why a run takes longer than asking a model for a patch.

---

Next: Recovering a run — what to do when a run stops before the pull request.