What does a verified build have to pass?
A build isn't done when the code is written — it's done when it survives all six.
Every file builds cleanly. Syntax errors and broken imports never reach you — they're caught and repaired before the run continues.
The app starts in a clean sandbox and stays up — no crash on launch, no silent white screen.
Each screen in the plan is visited and answers. Dead routes, broken links, and error pages fail the run.
The promises from your plan — "booking a spot decreases availability" — are each driven end-to-end and checked individually. Your proof list uses your words.
Security checks carry the shield: customer details hidden unless signed in, secrets out of the code, sign-in actually required where you said it should be.
Every screen re-checked at phone width — nothing cut off, nothing unreachable, tap targets big enough for thumbs.
Who checks the build?
The agent that writes your code and the agent that checks it are separate — different roles, different context, different incentives. The verifier only sees the plan's promises and the running app, so it tests what you asked for, not what the builder thinks it built.
When a check fails, the failure goes back to the builder with the specific broken promise — and the run repeats until every gate is green or we stop and tell you honestly.
See your first proof this week.
Request the beta, describe an app, and watch the verifier drive it. The proof does the convincing.
