375px (phone / Android TWA viewport) frames for the host shell's primary mobile
navigation. docs/design-system/portal-ux.md §5 records a real product gap: the
design system's mobile guideline specifies a BottomNav below md (≤768px) and the
BottomNav primitive exists in @fuzefront/design-system, but it is
not wired into the host shell — the shell is drawer-only today, so a phone user has no persistent,
thumb-reach navigation. These frames freeze how the bottom nav mounts in the shell, how it coexists with
the existing slide-in drawer, and the loading / empty / error / safe-area states before any shell code is
written. Built in the fuse-seam design system (tokens only).
Shell chrome present on every authenticated route. Implemented by
mobile-frontend-engineer (responsive shell chrome), not in a federated remote. Reuses the existing
drawer (SidePanel / .sidebar-scrim in Layout.tsx) rather than
adding a second overlay.
The bar in the mobile shell: 3 primary destinations + More, the active-tab fuse-seam indicator, a tab notification badge, collapsed top bar, scrollable content behind a fixed bar.
How bottom nav coexists with the drawer: tapping More opens the existing SidePanel
over a scrim for the long-tail (Billing, Connectors, Profile, Help, Status). Scrim dismiss; More shows
pressed.
Loading (nav renders instantly, never blank), empty (no registered apps), error (apps registry failed — nav still navigable), plus safe-area/notch, ≥44px touch targets, reduced motion and long-label truncation.
Approving these frames approves this inventory. The implementation builds exactly this flow
and these components — it cannot quietly invent a different architecture. No new npm package: the
BottomNav primitive already exists in @fuzefront/design-system; this is shell
wiring in frontend/src.
frontend/src)BottomNav renders max 4 items. The portal
has more destinations than fit, so the bar carries the three highest-frequency phone destinations —
Home (/dashboard), Apps (/applications),
Orgs (/organizations) — and a fourth More tab that opens the existing
drawer for the long tail. Derived from SidePanel.tsx's portal section.toggleSidebar that the top-bar hamburger already calls — one drawer, two entry points, so
there is never a bottom-sheet-vs-drawer split to maintain.aria-current="page", mapped from the router
pathname; a federated app route (/app/<slug>) lights the Apps tab.md and up the bottom nav is hidden and the persistent
SidePanel returns — these frames specify the phone (xs/sm) treatment only.Home / Apps / Orgs / More the right four for the bar, or should Billing
or Connectors take a primary slot over Orgs? (All others live under More.)/app/<slug>), should the bar switch to the app's
injected nav, or always stay portal-level with Apps highlighted? These frames assume
stay portal-level.