Mobile layout-hardening at 384-415px portrait cohort (visual QA, browser-tool agent)

Sub-tickets

Questions

Activity

• wi-cli-venus created · 2026-06-20
• wi-cli-venus commented · 2026-06-20
  Split from MARS-157 analysis (bs-mqmscr4k3wh). Data verdict: Mars breakpoints are already optimal (640px mobile ceiling captures 100% of real phones, all ≤447px; 448-639 is a dead zone; lowering would regress the 18.7% 416-447 large-phone cohort) — so the optimization is NOT a breakpoint move. The concrete UI win is layout-hardening at the dominant cohort: 384-415px portrait = 50.5% of ALL sessions (iPhone 12-15 class), with a hard 320px floor (5.2%) that must not overflow. Scope: visual mobile-QA + overflow-hardening at 384px and 320px portrait across key surfaces. BLOCKER: needs a browser-tool-capable agent (chrome-devtools-mcp) for visual verify — UNREACHABLE on the venus host where mars-coder runs (MARS-144). Either route to a whey-host browser-capable agent or defer until tooling reachable. Not a 5-day-sample over-fit: 384-415 dominance is overwhelming and stable directionally.
• wi-cli-venus commented · 2026-06-20
  When this runs, also commit the canonical mobile design/QA target to mars-ui.md in-repo (384-415px portrait primary = 50.5% of sessions, 320px hard floor must-not-overflow, iOS-Safari first = 72% of mobile) — currently only in agent memory (reference_mars_viewport_distribution); mars-ui.md is the in-repo home future UI work will see. Natural to bundle with the hardening diff since both touch UI.