Dashboard and Settings

The dashboard is the authenticated surface at config.routes.dashboard (/dashboard), a Server Component that fetches GET /dashboard/status once on the server. Everything under /settings sits in ONE hub behind a vertical rail (settingsNavGroups, packages/config/src/settings-nav.ts); the admin panel beside it keeps its horizontal tab strip (sectionTabsConfig, packages/config/src/section-tabs.ts). Both carry requires (and orgRoles) gates that hide anything the viewer or the active config cannot reach.

Dashboard surface

The page renders from that single server-side fetch - no client loading spinner - and drives the plan cards, security score, team stats, usage chart, and activity grid from one payload.

// GET /dashboard/status - packages/api/src/routes/internal/dashboard.ts (authGuard)
{
  fundedByOther,                             // true when the workspace owner pays, not you
  planName, planId, planType, planExpiresAt, // ALL null when fundedByOther
  isActive,                                  // always present
  organizationCreatedAt,                     // null when single-tenant / no active org
  security: { twoFactorEnabled, emailVerified, activeSessionCount, passkeyCount },
  team: config.tenancy.multiTenant
    ? { memberCount, pendingInviteCount, userRole }
    : null,                                  // null when single-tenant
}

planType is "free" | "lifetime" | "subscription" | null, derived from the resolved billing plan.

Page chrome

Stack an authenticated page's chrome in this order: top bar (the section title, see Navigation), then either the settings rail down the left (anywhere under /settings) or the admin tab row above the content, then PageHeader, then content. The rail is drawn by the section LAYOUT, so it stays on screen while a route resolves; a tab row is drawn by the page. Either way the page renders inside one PageContent column.

PageContent comes from @repo/ui/components/ui/page-content. It caps the readable width, centres the column in the content area, and carries the page padding; the vertical rhythm stays with the page (space-y-* or flex flex-col gap-* via className).

PageHeader comes from @repo/ui/components/ui/page-header and takes optional title, description, and actions. On a hub page or a tabbed page pass only description plus any page action - the lit rail entry or tab is the title. Elsewhere add a title only when it says more than the top bar does (a greeting, a record's name).

The settings hub

ONE hub behind ONE sidebar row (/settings), with a 224px vertical rail down its left. Both shells render the same rail from the same settingsNavGroups, so a destination cannot exist on web and not on desktop by accident.

The admin panel is the one section outside the hub. It lives outside /settings and keeps its tab strip. Organization and Project are runs of the rail with no sidebar rows of their own, so the footer Settings row lights on their pages too.

The rail is three pieces: the data (packages/config/src/settings-nav.ts), the chrome (packages/ui/src/screens/_shared/settings-nav-chrome.tsx - rail frame, phone menu, group boxes, item classes, two-column layout), and a short binder per shell that maps the visible items to its own link primitive. The chrome carries no links, because the two shells route with different ones.

• A group heading is an h2 ABOVE its list, never a word among the items, and a run whose every destination is gated off does not render at all.
• Below 768px the rail becomes a menu - a dropdown whose trigger names the current destination, with the same runs as labels and each entry a real link. A column expanded in place pushed the page off the screen; a menu floats over it. Both shapes render from the same visible-groups data, so they cannot disagree.
• sidebarConfig's Settings row derives its activeMatch from these runs, so the row lights on exactly the pages the rail lists.
• The desktop passes its own feature resolution. ai, aiByok and aiModels fold in the web-only ai.webUi switch, so a desktop-first build resolves them from its own facts instead.

Admin panel

Access is enforced server-side in admin/layout.tsx: any session whose user.role !== "admin" is redirected to config.routes.loginRedirect, and the sidebar link is separately hidden by roles: ["admin"] in config/sidebar.ts. Because the layout gates the whole panel, individual tabs carry no roles gate; only feature flags hide one from an admin.

The admin pages carry their own horizontal tab row, and the sidebar's Admin row opens the section's first enabled tab.