c36dc36819
All checks were successful
check / check (push) Successful in 22s
Verifies the mobile layout from #5 with a real browser engine instead of by hand on a phone. make frontend-viewport-test builds dist/, serves it from the same digest-pinned nginx image and the same nginx.conf the shipping container uses, and drives a digest-pinned headless Chrome against it over CDP. Viewport widths are derived from the app's own CSS rather than from a list of phone models: the @media conditions in src/styles.css and any Tailwind responsive prefixes in the markup are parsed, and each breakpoint is tested one pixel below, exactly on, and one pixel above. max-width: 768px matches at 768, and a generic 375px test sails past that boundary entirely. Four anchor viewports are added with stated reasons: a 320px floor, a desktop baseline, and two phone-landscape sizes straddling the breakpoint. Assertions are on computed layout, not screenshots: horizontal overflow, elements past the viewport edge, clipped text (deliberate ellipsis truncation excluded), 44x44 minimum tap targets, and genuine reflow of the host rows checked on both flex-direction and geometry. Probing and gateway detection are asserted to still run at narrow widths, since the early-return mobile path rejected in #8 is what would silently regress. Screenshots are written to tmp/viewport/ as artifacts alongside the results, not as the evidence. puppeteer-core rather than playwright: it is the one variant of either that never downloads or bundles a browser, so the browser stays a digest-pinned image and the npm side is pinned by yarn.lock integrity. The browser container runs on an --internal docker network with no route off the host; the harness answers the app's latency probes itself from a fixed delay table so the rows render a realistic spread of value widths. Kept out of make check: it needs Docker and takes minutes, where make test has to stay under 20 seconds. Every check guards its own presence, so none can pass against a page it is not measuring. The tap-target check in particular would otherwise be inert: an empty undersized set means both "all controls are big enough" and "the selectors have gone stale", and the size comparison alone cannot tell those apart. Each selector therefore declares the minimum number of visible instances the page must contain, per selector rather than in total, so one stale selector out of four fails rather than only all four at once. Layout expectation is likewise refused rather than guessed. A width is narrow when a max-width block matches (desktop-first, what the app does today) or, for a min-width-only mobile-first set, when it falls below every breakpoint; a set mixing both cannot be resolved from the conditions alone, because which block owns the reflow is a property of the rules inside it, so the run fails with an explanation instead of testing the right widths against the wrong expectation. The harness was observed failing before being trusted, four times: a planted 900px fixed-width element in a host row; the mobile reflow rule neutered; the tap-target threshold lowered so nothing was undersized and .pin-btn then renamed, which took the check from 8/8 green at every touch viewport to failing at all six, naming the stale selector; and a second media block added so the breakpoint set mixed max and min, which aborted the run. All reverted. Against the current layout it reports two real defects, filed as #42 (horizontal overflow at 320px) and #43 (tap targets below 44x44).