Ten views and their states, from the PR #26 proposal's list: sign in, sign up, verify email (only when the reviewed manifest enables it), forgot password, reset password, logout, plus the shared loading, validation, rate-limit, unavailable and safe-error states. Every card below is the same component with the same field order and the same copy — only the six manifest tokens differ.
Default · validation · rejected credentials · in-flight
Default · an address that cannot be used
The signup error is deliberately not "that email is taken." Confirming which addresses have accounts is an enumeration oracle, so the message is the same whether the address exists or not. This is package-owned security copy and the proposal forbids a product overriding it.
Pending · success · expired link
These three views must not exist for every product.
capabilities.emailVerification is a boolean in the manifest, and
requiredFleetAuthConformanceCases() only adds
verification-required-before-signin and verification-consume when it
is true. A product with verification disabled should not route to these at all.
Request · sent · choose new · mismatch · expired
"If an account exists for…" is also not hedging. Same reason as
signup: the confirmation is identical whether or not the address is registered.
passwordReset is z.literal(true) in the contract, so unlike
verification these views are mandatory for every product.
Loading · rate-limited · auth unavailable · safe generic error · signed out
Loading is a skeleton of the form, not a spinner on an empty card. The shape of the view is already known before the response arrives, so showing it costs nothing and prevents the layout jump that makes a slow auth screen feel broken.
Same component, same order; the card loses its border and sits edge to edge
emubrain-auth PR #26 at head
c5e5c75.