There is a rule in this codebase that sounds like bureaucracy and is actually the whole design. An API endpoint that has no passing test does not exist, as far as the rest of the platform is concerned. No frontend can be built against it. Nothing downstream of it will materialize. Giant Context, the website platform I build, treats a test not as proof of quality but as the ticket an endpoint buys to have consumers at all.

That claim needs a mechanism.

Nobody hand-writes the code that touches an endpoint here. The API describes itself in a schema, and a generation apparatus reads that description and materializes the entire client side. The typed methods, the data hooks, the cache keys, the form validation, the mocks and factories, all of it produced, none of it written. Roughly twenty families of files exist purely as outputs of the API's description. The apparatus has its own post. That leaves one consequence. The client of an endpoint is produced, not written, and anything that gates production gates existence.

One endpoint makes it concrete. Creating an organization is declared once, by hand, in the API's schema file:

And this is the file nobody wrote, sitting in the generated package after the apparatus has read the spec:

Same declaration, two languages. The top one I wrote. The bottom one, and the hook that calls it, and the form validation that runs it, the machinery wrote.

The trick is that generation runs first and testing runs last, and in development the entire chain is alive. Every service runs hot. Save a route file and the API reloads itself and its spec updates. The generators read that spec from the running server, so code materializes from a live, healthy API, not from source files sitting still on disk. The watchers take it from there. Regeneration picks up the new description, and the test runners sitting on the affected packages rerun their suites against the freshly materialized code. The chain is not a ceremony you invoke before a push. It is what the room does every time you hit save.

That room is concrete. One command starts the platform as a set of named services:

Sitting among the database proxy, the API, the web client, and the file and AI services are gen, routes, and i18n, the generators themselves, running as peer services, each in watch mode. Generation is not a tool I invoke. It is a service that never stops running, which is what "generation runs first" means mechanically. It is already running when you save. And the ordering was pinned early, in a commit whose title is the idea:

The gate is the precondition on the first step. An endpoint enters generation only with a passing test of its own, even a simple green one. No test, and the machinery produces nothing for it. No hook, no form, no surface. Write the test and the chain runs, and at the far end the full suite, much of it itself generated, proves the materialized system still holds. The test you write opens the gate. The tests the machinery writes close the loop.

There is nothing clever inside the gate. It is sequencing. Classic TDD asks you to hold a discipline, test first, every time, forever. Sequencing removes the choice. The consumers of an endpoint are produced only after its own test passes, so the test comes first by construction, not because anyone is virtuous but because nothing downstream can exist otherwise.