Giant Context builds and hosts websites, and the console is the authenticated portal where customers manage theirs. Every form in that console validates against a schema no one wrote on the client.

Drift is the default condition of web forms. The server holds an opinion about what a valid organization name is. The form holds another. The opinions live in different files, usually in different languages, and every schema change is an invitation for them to disagree. The user is the one who finds the disagreement. They fill out a form the client blesses and meet a 400 the server sends anyway, or they fight an input rule the server stopped caring about a year ago. The client is working from a copy of what the server accepted the last time someone checked.

There is no drift in this console, and discipline has nothing to do with it. The client's opinion is generated from the server's, so there is only one opinion.

The form system was not built as a feature. It follows from a decision that predates every form in the product: the API is the source of truth, and everything downstream of it is materialized. The database is strongly typed and migrated in writing. The API routes declare their request and response schemas. From those declarations the machinery generates the typed client, the zod validation, the data hooks, the query cache keys, and the mocks and factories the tests run on.

One week into the repository:

The commit that generates the console's routes generates the form hooks three bullets later. Forms were never designed here. They came out of the architecture that was already there.

A route in the API declares its request schema: the field names, types, bounds and patterns. Fastify enforces that schema at the boundary, so a request that violates it never reaches a handler. The server's half of validation is part of the framework rather than something added on top.

The same declarations feed the API's self-description, published as an OpenAPI spec. A generator compiles that spec into the client's half: a typed API client and zod schemas, one per operation.

This is what comes out the far end, in the generated client:

No one wrote that zod. The route declared its shape and the generator did the rest. The slug regex in the form is the same regex the server enforces, not because anyone kept them aligned but because there is one regex. When the route's declaration changes, this file changes at the next generation pass and the form's behaviour changes with it. The rule lives in one place, so there is nowhere else for it to go stale.

What remains for a form to be is three references and a factory call. Which schema, which endpoints, which cache keys. A 320-line utility called createCoreForm ties them together. From its doc comment:

Every argument in that call is generated. The schema, the client methods, the cache keys. The factory wires the schema into the form resolver, so fields validate as the user types. It wires the client methods into mutations, so submit is typed end to end. And on success it invalidates the resource's cache keys, so the queries refetch and every surface showing that data updates, the same reactive loop that handles any other write. A form submission is one more mutation through the same path everything else takes.