The stage that actually touches your repo.
Everything before this produced documents. This stage produces a commit. It takes the reviewed plan, writes the code, and then spends most of its effort trying to prove that what it wrote is wrong.
It is also the stage that deploys. Once every check has passed, the change goes to production without waiting for anyone to approve it. That is deliberate, and it is the part most engineering leads want to push back on, so it is worth being direct about the trade: review happens through the email you get afterwards and the revert you always have, not through a queue that a change sits in until someone remembers it.
In, and out.
Each stage takes one thing and produces one thing. Nothing runs in parallel, and nothing loops back.
A component-level change plan
A QA-passed change, deployed
What it is good at.
Implementation
Real edits to real components in your repo. No script tag, no runtime overlay.
Technical QA
The build, the types, and the test suite all have to pass.
Functional QA
The page is exercised the way a visitor would, before anything reaches production.
What has to be true before it ships.
Isolated compute
Agents get real access to the codebase, inside a sandbox. They read, write, and run it without touching anything outside that environment.
Real code
Committed changes to real components. No script tag, no runtime overlay, no flicker, and nothing that hurts page speed or search ranking.
Technical and functional QA
The build, the types and the tests have to pass, and the page has to behave the way a visitor would expect. Any failure and nothing ships.
One command back
Because the change is an ordinary commit, undoing it is an ordinary revert. No proprietary rollback, no support ticket.
Vivere needs a Git-based codebase with component-level architecture to work this way. That is a real requirement, not a preference.
Go touch grass.
Vivere is not open yet. Join the waitlist and we will come to you first.