Every configuration of AppShell we support, previewed live. Page layouts are the surface compositions — tool pages, split views, and item details that own their own headers over a chromeless shell. Shell configurations and page templates cover the sidebar model and the base page body. Each frame is a real, isolated instance — the nav is walkable and the sidebar toggle lives in the surface header; read when to use each below its title.
A top-level tool: its own thin header (sidebar toggle · actions · info) over the tool body. The info button — tool education — lives here and only here.
The default surface for any tool a user operates. The page title and controls live in the body; the header stays minimal and carries the tool-education info affordance.
A tool with an item opened beside it — each column owns its header, so the item spans full height while the tool compresses. Responsive: below tablet-landscape it stacks to full-screen route navigation. A tearsheet (coaching / assistant) can overlay it without adding a column.
Use when a user inspects one record without losing the list. Click a list item to open the split (try it at the Tablet width — it stacks); the item header carries a close + a link to its own full-screen page, never the info icon. Use the Coaching / Assistant buttons to float a tearsheet over the split.
The same item surface as the split panel, at its own dedicated URL — full-screen, with the sidebar toggle consolidated into its header and a back to the tool.
Every item detail has a canonical full-screen route it can be linked or deep-linked to (the split panel's expand control lands here). One ItemView renders both — the split column and this page — so there's a single source of truth for an item's layout.
A single record as a full-screen surface: a consolidated item header (back · title · status · actions) over a plain body, no rails.
For a self-contained record with no long structure or side context. The header consolidates the item's identity and actions; a back control returns to the list.
A long item with an in-page navigation rail (a table of contents) beside the content.
For a long document a user reads and jumps around — a dossier, a memo, a spec. The jump-nav rail tracks the current section; the header stays consolidated and info-free.
The richest item surface: jump-nav rail, scrolling content, and a detail panel. Full-screen (not a split) so all three columns get room.
For a complex item that needs both structure and supporting context at once — its sections plus source and score panels. Give it the whole frame; the consolidated header holds the item actions and the sidebar toggle together.
A tool page whose body pairs a section rail with a single focused settings pane.
For workspace or account configuration. It's a tool page (info affordance included) whose body is a two-column section-nav + pane, keeping each settings area scannable.
A tool page whose body leads with glanceable metric tiles, then attention and activity — summary before detail.
For a landing/overview surface. Surface the numbers and what-needs-attention first; encode state as pills so the eye lands where it should.
The full shell: workspace switcher, the navigation as grouped, collapsible sections, notifications, and the signed-in account.
The standard layout for every logged-in page. The sidebar is a stack of labeled sections of menu items (not a tab switcher) — reach for this whenever a surface belongs to the main app navigation.
A single unlabeled nav group, so the sidebar is one flat list of menu items with no section headers.
Use for an app (or embedded surface) whose information architecture is a short, single list that doesn't need grouping yet. Pass one unlabeled nav group and the section headers disappear.
The default shell with showNotifications set to false — the bell above the account is removed.
Use on surfaces with no notification stream to show (internal tools, admin consoles, a product still pre-notifications). It keeps the profile foot clean rather than shipping a bell that opens an empty flyout.
A nav item with an app-owned `children` slot that renders a nested tree beneath it while active.
Use when a single destination needs its own sub-navigation the flat nav can't express — a document tree, a settings sub-menu, a project's sections. The shell just slots your content under the active item; you own its markup and behaviour.
A stripped shell: custom wordmark, a single workspace with no create row, a short flat nav, notifications off.
The starting point when standing up a brand-new app on the shell, or an embedded/standalone surface that should stay quiet. Shows how far the config bends: swap the brand, trim the workspace switcher, drop notifications — all without touching the shell.
The base page template at its default ≤1100px reading measure, with description, header actions, and a toolbar.
The width for the vast majority of pages — reading-length content, forms, detail views. Build every app page with AppPage so titles, spacing, and the header layout stay identical across the product.
AppPage at the ≤1400px wide measure for denser, multi-column surfaces.
Use size="wide" for data-dense pages that need more horizontal room than the reading measure — tables, boards, multi-column dashboards — while still keeping a max width so lines don't sprawl on ultrawide displays.
AppPage with no width cap — content runs edge-to-edge in the page column.
Use size="full" only for canvases that own their own space — a graph viewport, a map, a full-width editor. Reach for it deliberately; most pages want a capped measure so content stays readable.
AppPage plus a ready-made placeholder body: tabs, search + filter, and a bordered empty state.
Drop in for a route that exists in the nav but isn't built yet, so it still reads as a real, consistent page instead of a blank screen. Replace the body with AppPage directly once the page has real content.
A structured page definition — summary, objective, users, jobs, layout, and backend — rendered via BriefScreen.
Use while a page is still being aligned on, before any functionality is built: it captures intent across six facets so the team agrees on what a page is for. The counterpart to PageScaffold for pages you're specifying, not yet shipping.