Full-circle development is how we decide whether a feature actually exists. Seven checks, with receipts.
The Zuzora founders · July 2026
You built something. It works on your machine, in the session where you made it. Full-circle asks the question that matters: has it actually landed in the company?
A feature nobody can find, that needs you to babysit it, that nobody notices when it dies, is functionally not there. It's just context bloat with a commit history.
This is the foundational requirement for every feature we fully integrate into a brain, ours or a client's. The seven dimensions below are seven different ways a feature can fail to exist.
Not “is there a file.” Files are easy. The test is that a fresh session, one with no memory of building the thing, asks a natural question and lands on it. If the only way to find it is to already know its exact name, it's lost. So every feature gets a registry row with a real owner and a real status, and a golden query: the question a person would actually ask, which has to return it.
The unattended test. An agent should be able to use it start to finish with zero stops to ask a human. If it's a cron job, it's wired on the right machine, it ran recently, and it exited clean. If it's a gate, feed it something that should trip it and watch it trip. The cheap-out we ban outright: “it's installed” standing in for “it ran.” A job that's loaded but has an empty log is a failure, not a pass.
Our own audit caught us here, and it's the best example in the standard. brain-benchmark, the thing that judges the brain's output quality, sat parked for about three weeks and raised zero flags. Nobody noticed, because raising zero flags is exactly what it looks like when everything is fine. Silence is indistinguishable from health unless something is watching. So every feature that can break gets a health row that flags it within one cycle. And at the strict grade, you have to have seen the alarm fire once: break the thing on purpose, confirm something screams. An untested alarm is a guess.
It shows up on mission-control, the dashboard we actually look at, with its verdict and the date it was last confirmed working. Not in a JSON blob somewhere. Blank cells count as invisible. And the stricter version: the data behind it has to be fresh. A tile showing three-week-old numbers is worse than no tile, because it tells you a comforting lie.
Only for features with human actions in their life: re-run this, approve that, park it, retire it. The bar is that the button round-trips. You click it, the change lands in the actual brain, and reading the record back shows the change. A button that just opens a document, or that updates the screen but not the underlying truth, fails.
The registry entry carries a last-verified stamp: the last time something watched it actually work, with a receipt behind it you can open. Explicitly not the file's modified date, and not the last commit. Those tell you someone touched it, not that it functions. When the stamp goes stale, the grade drops to zero and the gap re-opens on its own.
The company-agnostic core has to come apart cleanly: its own config, no Zuzora identity welded in. Then either it installs into a scratch brain and says hello, or a second live instance already runs in the wild. Our Telegram notifier is the gold standard, because Eric runs a separate one on a personal bot. Proof by existence rather than proof by assertion.
Most of these aren't really about code. They're about whether the company can trust a thing when nobody is in the room with it. That is what done means here: the circle closes, or the work isn't finished.