` | SheetContent's rounded panel is a `::before` overlay; a full-width border draws past the rounded corner and leaks 1–2px outside the panel. See `nqui-sheet.md`. | --- ## Auth recipes Auth is the most-requested pattern that the kit must cover well. Get these wrong and consumers feel the whole kit is unreliable. ### 16. Login form (email + password) **Intent:** the canonical sign-in screen. ```tsx

``` **Rules:** - Single primary action ("Sign in") with loading state. Never "Submit". - "Forgot?" link inline with the password label, not below the form. - Errors: specific ("Incorrect email or password.") not generic ("Auth failed"). - `autoComplete` attributes mandatory — password managers depend on them. - Single card, centered. Not a sidebar+content layout for a sign-in screen. ### 17. Signup (OAuth + email) **Intent:** offer one or two OAuth providers + email signup. ```tsx Create your account {/* OAuth row */}

{/* Divider */}

or with email

{/* Email form */}

By creating an account you agree to our{" "} Terms{" "} and Privacy Policy.

``` **Rules:** - OAuth buttons are `variant="outline"` (secondary visual weight — choice, not push). - "Continue with X" not "Sign in with X" — works for both signup and login. - Divider uses a centered label, not just a horizontal line. - Terms/Privacy in muted small text below the form, not as a checkbox above. (Implicit consent on signup is industry standard for SaaS; require explicit checkbox only if you have a legal reason.) - `autoComplete="new-password"` on signup password field (different from login). ### 18. Password reset (two-step flow) **Intent:** request reset, then enter new password. ```tsx // Step 1: request reset Reset your password We'll email you a link to set a new password. // Step 2: success state (after submit)

Check your email

We sent a reset link to {email}. It expires in 1 hour.

``` **Rules:** - ALWAYS show the success state on submit, even if the email doesn't exist. (Security: don't leak whether an email is registered.) - Include the email address in the success message — confirms what the user submitted. - Mention expiration window — manages expectations, reduces support tickets. - "Back to sign in" link in case they came here by mistake. ### 19. Magic link (passwordless) **Intent:** email link, no password ever. ```tsx Sign in to Acme Enter your email — we'll send a sign-in link. ``` **Rules:** - Same security rule as password reset: show success regardless of whether the email is registered. - SSO link below a separator if the product supports both — don't put it inline competing with the primary email flow. ### 20. OTP / 2FA code entry **Intent:** 6-digit verification code (post-login, post-magic-link, or post-signup). ```tsx Enter verification code We sent a 6-digit code to {email}. {error && {error}}

Code expires in {timeLeft}

``` **Rules:** - Auto-submit when 6 digits entered — don't make the user click Verify after typing the last digit. - Show the email so users know which inbox to check. - "Resend code" rate-limited (30-60s cooldown). Show countdown, then enable. - Errors are specific: "Incorrect code." not "Verification failed." ### 21. Email verification banner (post-signup) **Intent:** unobtrusive reminder for unverified accounts. ```tsx {!user.emailVerified && ( Verify your email Check {user.email} for a verification link. {" "} )} ``` **Rules:** - Use `Alert` (informational), not a modal — don't block the user. - Place at the top of the app shell, above main content. - Resend link inline in the description, not as a separate button. - Don't dismiss it permanently — let it persist until verified. ### 22. SSO landing (enterprise) **Intent:** workspace/email entry → redirect to SSO provider. ```tsx Sign in with SSO Enter your work email to find your organization. Use email and password instead ``` **Rules:** - Hide the actual SSO provider from the user — they enter email, the system figures out the provider from the domain. - Always offer an escape hatch ("use password instead") in case SSO is misconfigured or the user is on a personal account. --- ## Single-surface / refined recipes These recipes apply when the surrounding shell uses single-surface mode (see `ELEVATION.md` Mode 3 — landing pages, docs, content-first apps). They're cleaner alternatives to recipes that work well on multi-surface shells but feel heavy without surrounding chrome. ### 23. Active nav indicator (inset bar, not bg-fill) **Intent:** mark the active route in a sidebar / docs nav without using `bg-accent` as a pill. Used by Linear sidebar, Notion docs, Vercel docs, Boneyard. ```tsx [ "relative flex items-center gap-2 rounded-md px-3 py-1.5 text-sm transition-colors", // INSET LEFT BAR — appears only when active. 2px wide, full row height, // sits in the left padding without shifting the label. "before:absolute before:left-0 before:top-1/2 before:-translate-y-1/2", "before:h-4 before:w-[2px] before:rounded-full before:bg-foreground", "before:opacity-0 before:transition-opacity", isActive ? "text-foreground font-medium before:opacity-100" : "text-muted-foreground hover:text-foreground hover:bg-muted/40", ].join(" ") } > {item.label} ``` **Rules:** - Bar is **2px wide** — wider reads as a divider, narrower disappears at low DPI. - Bar uses **`bg-foreground`** (or the brand color) — needs full contrast to register as an active marker. - Active row gets **bolder text** (`font-medium`) AND the bar. Either alone is too weak; both together makes the active state unambiguous. - Hover on inactive rows uses **`bg-muted/40`** — a soft pill — so hover and active are distinguishable (active = bar + bold; hover = soft pill). - **Do NOT also fill with `bg-accent`** — defeats the point. The bar+bold combo IS the indicator. **When to use this instead of bg-fill pill:** - Single-surface shell (no surface contrast available — bg-fill would clash with the borderless canvas) - Docs / marketing / content-first app where the nav is meant to defer to the content - Sidebars where 6+ items would create too many filled pills if multiple states were highlighted **When to KEEP bg-fill instead:** - Dense product UI with high information density (Linear's issue list nav, our PMO sidebar with badges + icons + counts) — there, the bg-fill survives the noise better than a thin bar. ### 24. Concept demonstration (show, don't tell) **Intent:** explain an abstract feature by pairing the REAL artifact with the ABSTRACT artifact side-by-side in one frame. Used by Boneyard (real UI vs skeleton), Vercel marketing (code before vs after), Anthropic docs (prompt vs response). ```tsx

{/* Top — labels for each half, monospace-ish small caps */}

Real UI Skeleton

{/* Body — the two artifacts, equal-width, same vertical rhythm */}

{/* REAL — full-fidelity rendering with colour, icons, labels, data */}

{/* ABSTRACT — same shapes/positions but stripped of colour and detail */}

``` **Rules:** - **Equal column widths** — asymmetry implies one is more important than the other; for "concept = output" pairing, they need to read as equals. - **Same vertical rhythm** — both halves use the same `gap-*` values so eye-line moves left-right at the same heights. Misaligned rows kill the visual rhyme. - **The contrast IS the explanation** — don't add an arrow or "→" between them. The user's brain does the comparison automatically. - **Real side gets all the colour** — accent colors, icons, brand. The abstract side stays monochrome / grey. The colour drop-off is the second signal that "this is the stripped version." - **Containing frame is borderless or has the lightest possible border** (`border-border`) — heavy frame would compete with the contrast inside. - **Labels go above each half** in tiny uppercase muted text — not floating labels in the middle, not headers in their own rows. The labels are minor; the demonstration is the point. **Don't use this pattern for:** - Single concepts that don't benefit from comparison (just show the thing) - More than 2 panels — 3+ becomes a comparison table, different recipe - Steps in a sequence — use a numbered flow, not a side-by-side --- ## Combo synthesis — how to think about new ones When you face a situation not listed here, ask: 1. **What is the user's verb?** (browse, decide, create, confirm, monitor, configure) 2. **Is it inline (in flow) or modal (interrupts flow)?** 3. **Does it need depth?** (overlays, drawers) or **breadth?** (always visible) 4. **What's the smallest set of components that achieves it without decoration?** Then check `COMPONENTS_INDEX.md` decision trees, pick the components, and verify against this file's anti-recipes before writing JSX.

Page title