Driving the built app through headless Chrome at 320/360/390/414/768/
992/1200px across every public route, and in Arabic, Hebrew and German,
turned up four real defects. All four are verified fixed by re-running
the same sweep: 42 route/width combinations, no horizontal overflow.
A long URL or identifier in a chat message made the conversation pan
sideways ~200px on a phone. `overflow-wrap: anywhere` on the bubble, not
`break-word`, because only `anywhere` counts toward the min-content
width — and it was the min-content width driving the scroll area, so
`break-word` would have wrapped the text and left the panning intact.
The mission page slid sideways 8-12px at every width below the
container's max-width. A row's horizontal gutter becomes a negative side
margin of half its width and the container only cancels that up to
`g-4`; the two `g-5` rows there poked 12px past the viewport. Restricting
the wide gutter to large screens still failed at exactly 992px, because
a scrollbar narrows the viewport below what the breakpoint assumes, so
the horizontal gutter goes entirely — the columns stack below lg and the
vertical gutter is what does the visible work.
The document advertised `lang="en"` while rendering Arabic. Direction was
already synced on language change; the language itself was not, which is
what a screen reader announces from and what the browser selects a font
and hyphenation dictionary with.
Footer links and the password-reset link were 19-22px tall, under the
24px minimum, and sit at the bottom edge of a phone where tapping is
least accurate. The remaining sub-24px link is a mailto inline in a
sentence, which the guideline exempts.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0165r11RzqkMqWWXfJE8tAVU
