How a run works
Five stages, each closed by a yes/no vote of the whole council.
Every run goes through the same five stages. A stage ends when the whole council votes yes on its result; only then does the next stage start.
| Stage | What it does | Changes files | Runs the project |
|---|---|---|---|
| 01Understand & Contract | Clarifies the request with you until every model agrees it is understood, then fixes the contract the build must follow — interfaces, data flow, module boundaries and file layout. | No | No |
| 02Plan | Plans the complete structure — folders, files and modules — and settles on one plan. | No | No |
| 03Build | The code stage: only the Writer writes; the others critique and request changes. Right after the council's yes, SAMI runs the project's build and tests if it has any. | Yes | Yes |
| 04Harden | Every model challenges the build for defects, correctness and security gaps; the Writer applies the validated fixes and the project is run again. | Yes | Yes |
| 05Acceptance | A final audit of the finished work and one last run of the project's checks; a failure goes back to the council. | Only to fix a failed check | Yes |
Only the Writer changes files or runs commands; every Guardian can read your project in every stage. Acceptance has no build duty of its own: the Writer changes files there only to fix a failed check, a limited number of times.
Clarification comes first
The first stage always starts by clarifying your task, at every autonomy level. There is no fixed number of rounds: the council keeps asking until it agrees the task is clear. For each question you can pick a suggested answer or write your own.
If a round goes unanswered for too long, the council continues with its best assumptions and the War Room shows Proceeding with the council’s best assumptions… Answers sent after that point are turned away with Clarification window closed — start a new run.
Inside a stage
When the council has more than one model, the models think in a shared ledger: each one adds claims, challenges and proposals, and responds to the entries of the others. An objection stays open until the model that raised it is satisfied, or until the Lead records a decision with the objection preserved. The Lead then writes the stage result and lists every question that is still open.
The vote
Each Guardian votes YES or NO on the stage result. A NO has to explain itself: the models are asked for at least three sentences and at least one concrete piece of evidence, such as a line of code, a log entry or a test result.
A single NO holds the stage. The Lead works with the council toward a genuine YES, so the objection is answered rather than outvoted. If that doesn't happen within a bounded number of rounds, or the run's budget runs out first, the stage moves on with the objection visibly on record. An objection is never silently dropped.
The Execution-Verify Gate
After Build, Harden and Acceptance, SAMI runs your project's own checks (typecheck, lint, tests or build) through the desktop app, and the council sees the real output. This happens when SAMI finds such commands for your project and the desktop app is connected; an empty project has nothing to run yet.
A failed check goes back to the council. The Writer may make a limited number of fixes, and the council always votes again before the stage closes. The check confirms that the project runs; the quality comes from the council's work before it.
Sending work back
Build, Harden and Acceptance can send the run back to Understand & Contract or Plan with a concrete change request when a problem started there. This can happen a limited number of times per run, and the stages after that point run again.
After a run
Each task you send starts a new run through all five stages. On paid plans the council also recalls the key decisions of earlier runs on the same project. If a run was interrupted or paused, Continue resumes it with the earlier run's context (see Troubleshooting).