# Page Patterns
Payd Labs products reuse a small set of page types. Keep these patterns stable
across projects so users can move between tools without relearning structure.
## Admin Dashboard
Use for Stables, OneLink, Secret Share, Sentinel, Knowhere, and similar tools.
Structure:
1. Fixed header and sidebar.
2. Compact page title.
3. Metric cards or action row.
4. Status breakdown, operational table, or recent activity.
Rules:
- Do not add a marketing hero to dashboard home pages.
- Keep metrics in a 2-by-4 responsive grid.
- Put filters above tables, not in separate decorative cards.
- Prefer exact record state over generic copy.
## Login And OTP
Structure:
1. Centered logo and product name.
2. Optional one-line product purpose.
3. Error alert if needed.
4. Surface card with form.
5. OTP step in the same card.
Rules:
- Card max width is usually `max-w-sm`.
- Logo height is 28-32px.
- Product title is 18px.
- Form labels are 12px.
- Primary action is full width and accent green.
- OTP values use mono or fixed numeric boxes.
## Checkout Or Payment
Use for customer-facing payment flows.
Structure:
1. Header with Payd logo and theme control.
2. Centered or constrained payment panel.
3. Amount, network, asset, address, timer, and action.
4. Success, expired, failed, and underpaid states.
Rules:
- Use the same tokens but allow more whitespace.
- Amounts and addresses should not shift during polling.
- QR containers can use larger radius, but still need border and surface logic.
- Keep copy direct and action-oriented.
## Docs Site
Use for API and design references.
Structure:
1. Header or docs shell with logo and theme toggle.
2. Sidebar or local nav.
3. Prose content with code samples, tables, and callouts.
Rules:
- Prose `h1` can be 32px.
- Prose `h2` is around 22px with bottom border.
- Code blocks use JetBrains Mono, 13px, 1.7 line height.
- Tables use the same border and header treatment as app tables.
## Control Plane
Use for Sentinel and Knowhere-style infrastructure tools.
Structure:
1. Same admin shell.
2. Summary cards for system status.
3. Tables for deployments, domains, projects, previews, and audit events.
4. Explicit action rows for deploy, promote, rollback, restart, verify.
Rules:
- Keep irreversible or infrastructure-changing actions approval-gated.
- Use warning and error states for operational risk.
- Keep system output readable in monospace or dense tables.
- Avoid user-facing internal readiness labels. Show actual status and next
available action.
## Detail Page
Structure:
1. Back or breadcrumb action.
2. Title, status pill, primary metadata.
3. Cards for grouped facts.
4. Table or event list for history.
5. Action panel where needed.
Rules:
- Use mono for record IDs, hashes, addresses, and API paths.
- Use secondary text for labels.
- Put destructive actions away from routine actions.
## Empty States
Empty states are compact:
- Icon if useful.
- One sentence that names the empty data.
- One clear action if available.
Do not use empty states to explain internal project readiness.
Design System