Reviewers as the backbone
In satelle, each step's work has to be accepted by a reviewer before the story moves on: the plan before coding starts, the code before integration, integration before release, and the release before the story is done. This post explains how that works and why.
Every change is a story
In satelle, every change starts as a story. No file can be edited until a story is open and in a step that allows editing, and a gate enforces that rule. A story walks a route: plan, code, integration, release, done. Each step's agent does its work first, and reviewers then judge what it produced. The story moves on only when that work is accepted.
What a reviewer is
A reviewer is a separate agent with read-only access. It cannot change the work it is judging. It judges evidence, not intent: what the change does and what the record shows, not what the author says they meant.
Two model families on the plan
The plan is reviewed by a panel of two, from different model families. Today that is Claude Opus fast and Cursor's Composer, and both have to accept. The plan gets two independent readings before any code is written.
What it catches
In the two features from the last post, review caught design faults at the planning stage. One plan duplicated logic that already existed. Another contradicted one of its own criteria. Both went back and were fixed before a line of code was written.
Strong where it builds, focused where it checks
Our split is simple. Running the work, planning, coding and taking actions go to the strongest model, Opus. Reviewers matter just as much to the workflow, but their job is narrower, so they can be focused, cheaper models.
Next in the series: why satelle runs each repo's own process instead of a fixed one.
To be continued.