Status

What runs today

The coldest page on this site. The roadmap is a ledger of intent; this is a ledger of evidence. Something appears in the first list only if it has been exercised by running the application, and the word “green” at the bottom is defined rather than asserted.

Never deployed

Start here, because it conditions everything below. This repository has never been deployed to a Cloudflare account. Not to production, not to staging, not once.

That is enforced rather than merely true. The 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 a first deploy would involve is written down and has never been executed.

Exercised by running it

Your own domainLive

  • Receiving. Mail arrives on a domain routed to the Worker, is parsed, and lands in the mailbox’s own store with its attachments.
  • The client. Folders, threaded conversations, search operators, rich-text compose, drafts, reply and forward, inbound attachments, per-mailbox settings.
  • Access control. Workspaces, four roles, per-mailbox grants, invitation-only membership, and revocation that takes effect on the next action of a session already open.
  • The agent. One per mailbox: reads, searches, triages and drafts, and stops at a server-rendered approval card before any move or read-mark. It has no send tool and no delete tool.
  • Inbound safety. Prompt-injection scanning that gates automatic drafting and fails closed.
  • MCP, in part. The eight read and draft tools, over OAuth 2.1 with PKCE, with owner- and admin-managed clients. The other six refuse.

Written but unproven

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.

Not built

Named so nobody has to guess whether they are quietly in progress. They are not.

  • Gmail, Outlook, Zoho and generic IMAP. Not built, not partially built. This is the largest single piece of work outstanding and the reason the product speaks only to a domain you route yourself.
  • Mobile applications, on any platform. A browser extension.
  • Integrations outside mail, calendar included.
  • Automation rules that run without a person.
  • Pricing, plans and billing.
  • Any certification, external audit, penetration test or bug bounty.

What green means here

“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:

  • A linter or formatter suppression comment, in any of the common spellings.
  • A TypeScript diagnostic suppression — @ts-expect-error, @ts-ignore, @ts-nocheck.
  • A coverage-ignore directive.
  • A disabled, focused or placeholder test — .only, .skip, .todo.
  • A double type assertion, the as unknown as escape hatch.

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.

Join the waitlist

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.

We store the address you type, plus a hashed form of your IP address so the form can be rate-limited. One email when sign-ups open, and nothing after that. We do not share the list, and there is no analytics or third-party script on this site.

See also: what is planned and in what order, and what we do not claim.