Private Pro category · 7 compositions
Authentication
Account entry, recovery, verification, and invitation workflows. These records are manifest-derived and source-free; an implemented status does not imply manual verification, release readiness, entitlement protection, or availability for purchase.
Manifest items
All 7 records currently carry implemented status. A dedicated detail becomes internally discoverable only after release readiness and a reviewed public preview.
Email code entry
Recovery checkpoint
Invite acceptance
Passkey handoff
Workspace chooser
Session expired return
Category contract
- Purpose
- Account entry, recovery, verification, and invitation workflows.
- Declared dependencies
- gummy-field, gummy-input, gummy-button, gummy-alert
- Required review
- light, dark, responsive, keyboard-reviewed, rtl-reviewed, reduced-motion
How to evaluate Authentication blocks
Select an authentication composition for one precise step—sign in, create an account, recover access, verify an address, or accept an invitation—rather than combining unrelated decisions. The right layout makes the primary action obvious and keeps recovery or account-switching routes findable.
Wire the visual shell to the application’s real identity provider and server-side session checks. Preserve password-manager support, autocomplete tokens, visible labels, validation summaries, pending states, and a safe return path. Never treat a client-rendered success screen as proof that identity was verified.
Test new and returning identities, expired and replayed links, throttling, cancelled flows, inaccessible email, and cross-device recovery. Confirm keyboard and assistive-technology output without disclosing whether an untrusted address exists. Paid source and production credentials remain outside this public status page.
Before implementation, document each form’s identity-provider action, session transition, redirect allowlist, error class, audit event, and support fallback. State which verification must occur again on the server and which customer input may be retained after failure. This prevents a visually complete form from concealing an incomplete recovery, invitation, or account-enumeration control.
Boundary
Public pages contain only approved names, purposes, dependency aliases, requirements, status, and any future reviewed image preview. Editable paid source, test paths, release locations, and entitlement details remain private.