Dashboard shell scrolls horizontally between 768px and ~890px

[guillermoscript]

Found while verifying #583. Reproduces on every dashboard page, so it is not specific to that work.

Repro

Any /dashboard/* page at a viewport between 768px and ~890px wide. The whole page scrolls sideways; nothing on the right edge is reachable without horizontal panning.

Measured on /dashboard/student (identical on /dashboard/student/courses/:id/exercises and the exercise pages):

viewport	client width	scroll width	overflow	main left / width
700	685	685	0	0 / 685
768	753	878	125px	256 / 622
800	785	878	93px	256 / 622
850	835	878	43px	256 / 622
900	885	885	0	256 / 629
1024	1009	1009	0	256 / 753

Cause

Two things collide at exactly md:

1. The sidebar appears at 768px. useIsMobile() is max-width: 767px, and Sidebar is md:block (Tailwind md = 768px), so at 768 the desktop sidebar renders and takes 256px (SIDEBAR_WIDTH = "16rem"), leaving 497px.

2. SidebarInset cannot shrink into what is left. components/ui/sidebar.tsx:310:

   "relative flex w-full flex-1 flex-col bg-background md:peer-data-[variant=inset]:m-2 ..."
   

   w-full inside a flex row that already contains the 256px sidebar, and no min-w-0, so the flex item will not shrink below its min-content width. Measured min-content is 622px against 497px available.

The min-content floor comes from the header's right-hand cluster (header .ml-auto, the LEVEL / DAY STREAK / COINS chips plus the locale, theme and avatar controls). It measures 545px at 768px and only 128px below 768, because it swaps to its compact form on the same md boundary that turns the sidebar on. So the sidebar appears and the header stops being compact at exactly the same width, and between them they need more room than the viewport has.

Suggested fix

• Add min-w-0 to SidebarInset so the inset can actually shrink. That alone stops the page from scrolling sideways; anything genuinely too wide then has to clip or scroll inside its own container, which is the correct behaviour.
• Consider holding the compact header stats until lg instead of md, or letting the chips wrap, so the header does not demand 545px in a 497px column.

Both are in shared shell components, so this wants its own change with its own check across dashboard pages rather than being folded into a feature PR.

Not in scope for #583/#584

Called out explicitly in #584 so it is not mistaken for a regression there: the branch reproduces it identically on pages it does not touch.

[guillermoscript]

Picking this up. Reproduced it locally before touching anything, and the measurements narrow the diagnosis in one useful way, so here is the plan.

Reproduction (unmodified master, local dev, student@e2etest.com)

page	700	768	800	850	900	1024	1280
/dashboard/student	0	87	55	5	0	0	0
/dashboard/student/courses	0	92	60	0	0	0	0
/dashboard/student/browse	0	87	55	5	0	0	0
/dashboard/teacher	0	0	0	0	0	0	0
/dashboard/admin	0	0	0	0	0	0	0

(numbers are documentElement.scrollWidth - clientWidth, i.e. px of horizontal overflow)

That confirms the mechanism in the report, and refines the scope: the overflow is student-only. Teacher and admin dashboards render the same shell with the same 256px sidebar and stay at zero across the whole range. The difference is the one thing the student header has that the others do not — <GamificationHeaderCard />, gated at app/[locale]/dashboard/layout.tsx:35 on hidden md:block.

So the collision is not "sidebar + header" generally, it is specifically: the sidebar appears at md, and the gamification card appears at md, and both want the same pixels. Everything else in the header cluster (locale, theme, avatar) fits fine.

Root cause

Two independent defects, both real, and both worth fixing:

1. SidebarInset cannot shrink. components/ui/sidebar.tsx:310 is relative flex w-full flex-1 flex-col … with no min-w-0. As a flex item its min-width resolves to auto, so it refuses to go below its min-content width and pushes the document wider than the viewport instead. This is the reason the page scrolls rather than the offending element clipping or scrolling inside itself. It is a latent trap for every future wide child (tables, code blocks, charts), not just this one.

2. The gamification card turns on at the same breakpoint as the sidebar. hidden md:block at app/[locale]/dashboard/layout.tsx:35. Between 768 and ~890 the inset only has ~497–629px, and the card's intrinsic width (shrink-0 Level block plus a fixed w-20/w-24 XP bar, components/gamification/gamification-header-card.tsx:35,44) plus the other controls exceeds it.

Fixing only (1) stops the page scroll but leaves the card cramped in a column too narrow for it; fixing only (2) leaves the shell fragile for any other wide content. Both.

Approach

• components/ui/sidebar.tsx — add min-w-0 to SidebarInset. Page-level fix; also covers /platform/*, which uses the same component.
• app/[locale]/dashboard/layout.tsx — move the gamification card's gate from md to lg (hidden lg:block), and add min-w-0 to the header so it can shrink with its parent.
• components/user-nav.tsx:84-85 — the dropdown already carries the card as the small-screen fallback (flex md:hidden); move that to lg:hidden in lockstep so the card is never absent from both places at once. This is the part that keeps the feature reachable at 768–1023 rather than just hiding it.
• components/gamification/gamification-header-card.tsx — the loading skeleton (line 22) lacks the max-w-full overflow-hidden that the loaded state has, so it is briefly wider than the thing it stands in for. Match them.

Risks

• min-w-0 on SidebarInset is global — it changes every dashboard and platform page. The failure mode it introduces is the opposite one: content that used to widen the page will now clip or scroll within the inset. That is the correct behaviour, but it needs checking across a spread of pages rather than just the three that reproduce, which is what the test below does.
• Moving the card to lg means desktop users between 768 and 1023 lose the always-visible streak/coins chips and get them in the avatar dropdown instead. That is a deliberate trade: the chips are glanceable, not critical, and the alternative is a page that cannot be read without panning.
• The gamification card renders client-side after a fetch, so a naive check can measure the skeleton instead of the real thing. The test waits for network idle plus a settle delay.

Test plan

• A Playwright spec (tests/playwright/specs/overflow-586.spec.ts) that walks student, teacher and admin dashboard pages across 700 / 768 / 800 / 850 / 900 / 1024 / 1280 and asserts scrollWidth === clientWidth at every combination. It fails on master with exactly the numbers in the table above, which is the point — it is a regression test, not a smoke test.
• Before/after screenshots at 768 and 820, including a scrolled-fully-right frame that shows what is currently unreachable.
• npm run typecheck and npm run lint on the changed files.