Email delivery is a single point of failure, and for a long time it was the only door: a greylisted code, a spam folder or a provider outage locked an owner out of their own company. ADR-0012 layered three ways in so no single channel can do that. The design problem is not the crypto — it is that each door must say exactly what it can do right now, and admit when it cannot.
The fallback order
The login page composes the three in a fixed order, and the order is the argument: provider identity first (fastest, and it proves the email), then the email code as the field every account has, with passkeys offered beside it as the alternate that needs no round-trip at all. The code path is never demoted and never hidden behind a disclosure — it is the universal fallback, so it stays where a half-awake owner already expects it.
Flip the switch above: when the deployment has not configured the provider, the button and its or rule are not rendered at all — not disabled, not greyed, not present-but-broken. That is the whole pattern for a capability that may or may not exist on a given deployment.
Continue with Google
The button is config-gated by a real check, not a build-time guess: the page asks /api/login/provider on mount and renders the button only if the deployment answers that it is enabled. A door that is drawn but cannot open is worse than no door — it converts a missing configuration into an owner who thinks they are locked out.
Visually it is the one place in the product that carries someone else’s brand colors, and it earns the exception the way brand-mark rules always do: Google’s four-color G is a required attribution, it is inline SVG so the door ships no external asset, and it does not become a license for accent color anywhere else on the page. The button itself stays secondary — it is a way in, not the yes.
Passkeys — enrollment and the list
Enrollment lives in Settings under Sign-in & security, built from the standard workspace page grammar — a WorkspaceSection whose meta is the honest count (“2 passkeys” / “None enrolled” / “Reading devices”), a RowList of devices, and a WorkspaceEmpty when there are none. Each row names the device, when it was added, and when it was last used — or says never used, which is a fact an owner deciding what to remove actually needs.
Three details in that specimen are load-bearing. Removal is two-step — the ellipsis in Remove… promises a second beat, and the row swaps to Confirm remove beside a Cancel rather than opening a modal, so the decision stays where the thing being removed is. The enroll button narrates the wait (“Waiting for the browser…”), because the pause belongs to the OS prompt and an owner should know whose turn it is. And the last line is the durability notice.
Honest failure
The three doors share one failure grammar: name what happened, keep the alternative in reach, and never blame the owner. The most-tuned case is the one that is not really an error at all — the browser prompt closed, or this device simply holds no credential. That resolves to a role="status" note, not an alert:
- A cancelled prompt is not an error.
NotAllowedErrormeans the owner closed the sheet or has no credential here — it gets a quiet status line naming the next move, never a red failure. - Lowercase, and no exclamation. “that code didn’t match”, not “Invalid credentials!” The door is embarrassed, not accusing.
- The fallback is already on screen. Every failure copy points at a path the owner can take right now, and that path is visible in the same view — no navigation to recover.
- An offline deployment says so. When the gateway cannot actually send, it answers with a hint and the code step still opens honestly, rather than pretending mail is in flight.