The loop, explained in six steps
Brief, plan, build, review, test, ship — repeat until done. Here's what each step actually does, and why we keep them in this order.
The Amedeus loop has six steps. They look obvious on a slide and are surprisingly easy to get wrong in code. Here is what each step does.
1. Brief
You write the goal once. The wizard asks the boring questions so the Architect doesn't have to guess later: constraints, stack, milestones, design principles. A readiness score gates the loop — under 70 and the run won't start.
2. Plan
The Architect turns the brief into a backlog of small, scoped tasks. Each task has a role, an iteration budget, and a clear "done" condition. No epics. No tickets called "investigate".
3. Build
The Developer picks the next ready task and ships a diff. One task, one diff, no cross-cutting heroics. If it can't fit in five iterations, it gets split.
4. Review
The Reviewer reads the diff and writes a verdict — approve, request changes, or comment — with severity-tagged items. No "LGTM". A blocker stops the loop on that branch until it's resolved.
5. Test
QA writes and runs the tests it would have asked for in code review. Edge cases, regressions, the off-by-one nobody saw. Failures go back to the Developer with the failing input attached.
6. Ship
A passing diff with a clean review opens a PR. Amedeus never force-pushes, never squashes silently, and always leaves the verdict in the PR description.
Why this order
Plan before build to avoid building the wrong thing. Review before test to catch the issues a test would never find. Test before ship to catch the issues review missed. The order is the product.