No mobile navigation exists — Navbar and DashboardShell sidebar are both hidden entirely below the md breakpoint

Overview

There is no mobile navigation anywhere in this app. Not a broken one, not a partial one — none. Below Tailwind's md breakpoint (768px), the primary nav and the entire dashboard sidebar simply disappear, with no hamburger menu, drawer, or any other affordance to reach what they contained.

src/components/layout/Navbar.tsx:

<nav className="hidden items-center gap-6 text-sm font-medium text-slate-600 dark:text-slate-400 md:flex">
  {links.map((link) => ( <Link ...>{link.label}</Link> ))}
  <div className="group relative">
    <button className="flex items-center gap-1 ...">Dashboards <ChevronDown .../></button>
    <div className="invisible absolute ... group-hover:visible group-hover:opacity-100">
      {dashboardLinks.map((link) => ( <Link ...>{link.label}</Link> ))}
    </div>
  </div>
  {user && ( <Link href={`/reputation/${user.username}`} ...>Reputation</Link> )}
</nav>

The entire <nav> — Bounties, Milestones, the Dashboards dropdown (Contributor/Maintainer/Sponsor), and the signed-in Reputation link — is hidden by default and only becomes visible at md:flex. There is no second, mobile-specific nav rendered anywhere else in the file, no hamburger button, no <Sheet>/drawer component, nothing. Below 768px, the header (src/components/layout/Navbar.tsx:26-101) renders only the logo, the NetworkBadge, the ThemeToggle, and the sign-in/avatar controls on the right — every single navigational link in the app becomes completely unreachable from the header.

src/components/dashboard/DashboardShell.tsx has the identical problem for the dashboard sub-navigation:

<aside className="hidden w-56 shrink-0 md:block">
  <div className="sticky top-24">
    ...
    <nav className="mt-3 space-y-1">
      {items.map((item) => ( <Link ...>{item.icon}{item.label}</Link> ))}
    </nav>
    ...
    <nav className="mt-3 space-y-1">
      {roleSwitcher.map((r) => ( <Link ...>{r.label}</Link> ))}
    </nav>
  </div>
</aside>

Same pattern: hidden w-56 shrink-0 md:block, no mobile equivalent. On a phone, a signed-in contributor/maintainer/sponsor visiting /dashboard/* gets the page's main content (stats, charts, claims list) but has no way to navigate to any of the sidebar's items ("Overview," "Browse bounties," "Reputation," "Milestones," "Team," "Payments," or the role switcher) except by typing URLs directly or using links that happen to appear inline within the page body itself.

Given the app's own README explicitly says nothing about desktop-only support, and this is a payments-adjacent dApp where a real number of users will reasonably expect to browse bounties, check dashboards, or manage a wallet connection from a phone, this is a significant, verifiable, and entirely unaddressed gap — not a partial implementation with a bug in it, but the complete absence of any responsive navigation pattern in the codebase.

Requirements

• Add a mobile navigation pattern to Navbar.tsx — a standard hamburger-triggered menu/drawer that surfaces everything currently only available in the hidden md:flex nav (Bounties, Milestones, the Dashboards group with its three links, and — when signed in — the Reputation link and sign-out control).
• Add an equivalent mobile pattern to DashboardShell.tsx's sidebar — either a collapsible drawer, a bottom nav, or a top-of-page dropdown/select that surfaces the same nav items and role-switcher links available in the hidden md:block <aside>.
• The mobile menu/drawer must be fully keyboard-operable and screen-reader-accessible: a labeled toggle button (aria-expanded, aria-controls), focus trapping or at least logical focus order while open, and closing on Escape and on navigation.
• Verify the "Dashboards" dropdown's current desktop implementation (group-hover-based, CSS-only) doesn't itself need touch-specific handling as part of this work — :hover doesn't fire on touch devices, so even where it is visible at wider tablet breakpoints that still allow touch input, confirm the dropdown is actually reachable via tap, not just mouse hover, since group-hover alone is a common source of "invisible unless you have a mouse" bugs.

Acceptance Criteria

• At viewport widths below 768px, every link currently only available in Navbar.tsx's hidden md:flex nav is reachable through a mobile menu.
• At viewport widths below 768px, every link currently only available in DashboardShell.tsx's hidden md:block sidebar (including the role switcher) is reachable through some mobile-appropriate UI.
• The mobile menu toggle is operable via keyboard alone (Tab to reach it, Enter/Space to open, Escape to close) and exposes correct ARIA state.
• The "Dashboards" grouped links remain reachable via touch at any breakpoint where the existing hover-based dropdown is otherwise still in use.
• No regression to the existing desktop (md: and above) navigation.

Additional Notes

Precise references:

• src/components/layout/Navbar.tsx:35-65 — the entire <nav className="hidden ... md:flex"> block; :22-103 for the full component showing there is no alternate mobile rendering path anywhere in the file.
• src/components/dashboard/DashboardShell.tsx:71-117 — the entire <aside className="hidden w-56 shrink-0 md:block"> block, with the primary nav (:76-95) and role-switcher nav (:100-115) both inside it and both invisible below md.
• The "Dashboards" dropdown's hover-only mechanism: src/components/layout/Navbar.tsx:41-59, using Tailwind's group/group-hover:visible group-hover:opacity-100 with no onClick/keyboard toggle at all — confirmed there's no JS-driven open/close state for this dropdown either, it's pure CSS :hover.

Relationship to other issues: distinct from #24 ("Retrofit full WAI-ARIA keyboard support into the Tabs component") — that's about the Tabs UI primitive used for in-page filtering (e.g. Active/Completed claims), not top-level site navigation. Distinct from #48 ("Fix Navbar loading-state flashes and multi-role rendering logic") and #10 in this batch (CallbackClient's post-login redirect target) — both of those are about which links/roles get shown to a signed-in user, not about whether the navigation is reachable on a mobile viewport at all; this issue is orthogonal to role-based content and applies identically regardless of how those are resolved.

Implementation sketch: a common, low-risk pattern here is a useState-driven mobileMenuOpen boolean in Navbar.tsx, a hamburger <button aria-expanded={mobileMenuOpen} aria-controls="mobile-nav" onClick={...}> shown only below md (md:hidden), and a full-screen or slide-in panel rendering the same links/dashboardLinks/conditional Reputation link already defined in the file (no new data needed, just a second render path for the existing arrays). For DashboardShell, a simpler <select>-based nav switcher or an accordion/drawer triggered from a small toolbar above children on narrow viewports would reuse the existing items/roleSwitcher arrays with no new data model.

Test/reproduction plan: at a viewport width below 768px (e.g. via window.innerWidth mocking or a real responsive/E2E test), assert the mobile menu toggle is present and, once activated, that all expected links (href values matching links/dashboardLinks) are present in the DOM and clickable/focusable. Repeat for DashboardShell's sidebar items and role switcher.