Phones are out of scope for kit work (owner, sitting 1, D10, 2026-10-23). The kit builds no phone shell, and no app is promised a phone layout.
This guide exists because someone will still be asked for one. A prototype once shipped with navigation that could not be reached at 390px. The guide says what the kit does at that width, what the app has to supply, and what to build when the request is real.
Audience: an agent (or person) asked to make an app, or one screen of it, work at 390px.
Everything below was read from the kit source and from the 2026-10 sweep findings, not from a phone. Nothing here has been rendered on a device, so treat each claim as UNCONFIRMED until you look at the app at 390px yourself.
What the kit does at 390px today#
| Part | What happens | What the app must do |
|---|---|---|
| Sidebar | Below the lg breakpoint it becomes a fixed icon rail 64px wide. Group kickers, labels, the top slot and the collapse toggle are hidden. | Host a menu button in the topbar and compose Sidebar with hideToggle. Doc 8 promises a built-in hamburger that AppShell does not have. |
| Topbar | A fixed 64px row. The actions cluster does not shrink, so four controls ran 731px inside a 326px header. | Show at most two controls at 390px and fold the rest into one menu. Search collapses to an icon. |
| Fit-to-viewport pages | A page that bounds itself to the viewport (doc 9 §A3) squeezes a fill-height table to 57px at 390px. | Release the fit below lg: the page scrolls, and the table keeps a floor of about three rows. |
| Tables | Shaped columns shed their lowest-priority columns or scroll sideways with an edge shade (doc 6 §A5). | Give each column a shape and a priority, so the phone sheds sensibly. |
| Toolbars | The bar wraps and search takes its own full row (doc 7 §A1). | Nothing, as long as the toolbar is the kit's. |
| Page header | Actions wrap to a left-aligned row under the title (doc 9 §D). | Keep the title short enough to fit on one line. |
| Page inset | The shell inset is 1.5rem below lg, which is large on a phone. | Set a smaller inset in the app's page frame if the width matters. |
The law behind it#
The overview's sixth law says every composite declares its narrow behaviour. A header, toolbar, table, footer or sidebar rail that has no stated answer at 390px is a defect, even when nobody asked for a phone. For a screen the owner has not asked to be phone-ready, the minimum is that the page does not scroll sideways and every action is still reachable, and narrow-overflows-viewport and narrow-row-wraps check that.
When the request is real#
Decide these in order. The owner has not ruled on any of them for the kit, so take them as the app's own and write them in its CANON-NOTES.md.
1. How the navigation is reached. The research seat recommended an off-canvas drawer inside AppShell below lg. It is not built.
- A hamburger on the topbar opens the same sidebar content as a left overlay with a scrim.
- It closes on route change, Escape and scrim click.
- Labels and kickers show in full inside it.
- Until the kit has it, build it from
SidebarwithhideToggle, a modal-style scrim and your own open state. - An app with three icons can keep the rail.
2. What the topbar sheds. Below sm the title is a span that truncates and the row may grow past 64px. Actions fold by priority into one overflow menu, as the table's row actions already do. The cap is two visible controls at 390px.
3. How master-detail works. A tree, a list and a record cannot share 390px.
- Three panes at
xl, two atlg(the tree becomes a drawer or a select), one below that. - At one pane the list is the screen, and opening a record pushes it with a Back control.
- The list pane width is a token, never a hand-typed
w-80, which once left the detail pane 6px wide. - A collapsed pane is a labelled rail, not a 40px chevron.
- Follow this as a recipe first. Build a
MasterDetailcomponent only after the recipe has been followed twice.
4. Where the page scrolls. A fit-to-viewport page is a wide-screen privilege. Below lg the shell and the page release to page scroll (h-auto, no overflow-hidden). A fill-height table keeps a floor of about three rows, so the worst case is a short table inside a scrolling page.
Checks#
Open every route at 390 and at 1440, in both themes, and read the render. Run the kit standard against each route: the horizontal-overflow checks name the screens that scroll sideways. Nothing in the kit asserts 390px behaviour on its own, so a screen you did not open is a screen you did not check.
Not covered#
- Search in the topbar is a three-column grid with no narrow form; make it an icon below
sm. - A side panel is in-flow only. A phone wants it as an overlay, and the drawer in step 1 and that overlay should share one scrim.
- The 57px figure comes from a scour probe and its flex chain was not traced to a single file. It may live in the page frame rather than the table.
- Speedway's fit-viewport shell is app code under the product freeze (
speedway/CLAUDE.md); releasing it at narrow widths is a CSS change to schedule, not to slip in.