What runs today

Start here, because it conditions everything below. The product application Worker has never been deployed to production or staging. The separate marketing-site Worker serving this page is live; it holds only the waitlist database and no mailbox binding or product secret.

The application boundary is enforced rather than merely true. Its deployment configuration still holds its deliberate placeholders — no database identifier in either remote environment, reserved example domains, and empty lifecycle identities — so a topology gate fails, and both deploy commands fail on that gate before anything is built. The count of remaining placeholders is printed on every quality run. Both deployment workflows are parked in a directory the CI system does not read, and re-enabling them is a deliberate move rather than a merge.

So: no production users, no sessions, no uptime record, no incident history and no service level. What the application's first deploy would involve is written down and has never been executed.

One item, and it is the important one.

Sending. The outbound path is built and it is built carefully: the message is persisted before any job is published, delivery runs as a durable background job with bounded retries and a dead-letter queue, there is exactly one provider-call boundary, and provider message identifiers are recorded so delivery can be reconciled per recipient.

What it has never had is a live provider on the other end. Until it has been exercised end to end against one — including bounces, rejections, deferrals and the ugly cases — we will keep calling it unverified, and no page on this site will describe sending as working. It is the thing blocking everything else.

“The tests pass” is worth nothing without the definition. One command gates every change, and it runs, in order: formatting, a quality policy, a design-token drift check, a design lint, a deployment-topology check, a linter, a full type check, both test suites, and a production build. Any one of them failing fails the whole thing.

The quality policy is the unusual one. It fails the build on five things that are normally allowed:

The effect is that the usual way to make a red build green — silence the thing that is complaining — is itself a build failure. A check in this repository cannot be turned off quietly; it can only be deleted, in a diff, on purpose.

Two design checks have the same character, and both exist because of a real bug rather than a principle. One fails when a colour utility names a token that does not exist, because the failure mode of a misspelled design token is silence: the text still renders, in the wrong colour, and looks deliberate. The other regenerates the shared token stylesheets and diffs them, so the palette on this website and the palette in the application cannot drift apart by hand-editing either one.

Now the limits, which matter more than the list. No test in this repository sends an email, calls a real model provider, or touches a real Cloudflare account: the model is a local fixture and the mail binding is absent by construction, so the suite cannot spend money or deliver a message. Everything about real delivery is therefore unverified by definition — which is the same sentence as the sending section above, arrived at from the other direction.

When something moves from the third list to the first, the waitlist is where that is announced — one email, when sign-ups open, and nothing after that.