Front-end layout QA — high-level pointers (local fallback)

conkeldurr tells you what is objectively wrong with a page’s rendered layout. The detailed, current responsive conventions — the team’s breakpoints, minimum tap-target and font sizes, how to trace an overflow to its CSS source, and when DOM bloat justifies a template refactor versus a one-off fix — live in the team wiki (set OUTLINE + OUTLINE_API_URL and the report links them directly). This file is the minimal high-level fallback for when the wiki isn’t configured: direction only, deliberately not step-by-step, so there’s no detailed content to drift out of sync with the wiki.

• Horizontal overflow — the flagship defect; trace the offending element’s width/margin/padding on the reported device, don’t just hide the scrollbar.
• DOM bloat — a heavy tree slows layout and interaction; prefer trimming markup or lazy-rendering over adding more CSS to compensate.
• Small tap targets — interactive elements need real hit area, not just visual size; padding counts toward the target, not just the visible glyph.
• Tiny fonts — below the legible floor is a readability defect, not a design choice to defend.
• Heading order — headings should nest without skipping levels; fix the document structure, not just the visual size of the text.
• Mobile + desktop together — a defect that only shows on one viewport is still a defect; check the device the finding names before calling something fixed.
• When to refactor vs patch — a DOM-bloat finding on a single page is a patch; the same finding across a whole template family is a refactor.

Full playbook → the team wiki’s front-end layout & responsive QA standards.