The app concept argues one shell across the product and the console. This is the third density of that same shell, and the same stylesheet dresses it — which is the whole claim, because the native app in the build today is not a density of anything. It is a separate design system. The mobile PRD widened scope from three jobs to four, and that arithmetic is what settles the nav question: switch the generation below and watch how many places each shell can actually reach.
All fifteen destinations the mobile PRD v3 puts in scope, counted against the shell on the left. The count describes what this shell can reach — never what the product contains.
mobile/app/(app)/_layout.tsx), plus the
Menu sheet the concept added on 2026-07-25 to avoid a fifth screen. Between them they reach
eight of fifteen and strand seven — and that bar was already full at three jobs.
v2 named three jobs and drew a boundary — companion, not a port — that excluded the composer, search and anything admin-shaped. The build crossed all three of those lines, and the largest screen in the app is now the governance surface. v3 stops pretending otherwise and adds the fourth job the code already does. What keeps it honest is not depth, it is posture: three jobs arrive from outside and must resolve in seconds; the fourth is what you opened the app to do.
Approve or deny what is waiting on you, from the notification where the OS allows. Under fifteen seconds, measured.
A five-second read on where things are. A sentence, not a dashboard — three things need you, nothing's on fire.
Speak or share on the move. The share sheet only exists on a phone, so mobile leads here and web follows.
Your profile, your hats, your library, your people, your plan, your support. You navigated here on purpose, so full depth is correct.
PRD.mobile-v3.md §2, ratification D3.
And which direction each surface travels — because three of them have no implementation anywhere.
| Surface | Web | Native | Direction |
|---|---|---|---|
| Files · Library · Shelf | None | None | Mobile-first — concept already drawn at 390px in shelves-mobile-v1.html; schema landed, no surface on either platform |
| Workspace — the hat | Functions | None | Mobile-first — switchWorkspace() exists on the Orgs screen; no shell-level switcher anywhere. Mobile can ship the first one |
| Support intake | 3 sinks | None | Mobile-first — the phone is where you are when it breaks, and it can attach device, build and object without asking |
| Governance — requests | Live | Live | Parity. 449 lines, the largest screen in the app |
| Profile | Live | Name only | Port. Emails, verification, handle — RCTX-373 |
| Network — people | Live | None | Port, after the naming fix — see below |
| Plan · billing | Live | Live | Parity |
connect-wizard.ts), the Loop referral programme (native
connect.tsx), and people (web connections.ts, network.ts).
The phone shows the least common of the three under the most contested name. The drawer above
uses the proposed split — Connect for the handshake, Network for people,
Loop for the programme — which folds into the lens-glossary ratification and gets
enforced by check_vocab.py.
/brand/generated/relay-tokens-v36.css through the same aliases the app and console concepts use. No local palette, no new token.app-mobile-v2.html, and the reason the drawer works: nothing underneath is ever lost.a43470a) and is corrected here.app-mobile-v2.html in the same change, or the disagreement just moves.
Full list: relay-board/docs/product/PRD.mobile-v3.md §8.