Visual regression
Record approved baselines, capture deterministic screenshots across routes and breakpoints, and separate pixel sensitivity from the amount of visual change allowed.
Lint UI is an open-source, local-first quality gate I am designing and building to catch visual regressions, responsive layout defects, and accessibility problems in the same workflow developers already use to catch problems in code.
Modern frontend work is increasingly fast, especially when AI is involved. A screen can move from an idea to working code in minutes, but the quality checks around it are still often manual: resize the browser, inspect a few routes, notice what moved, and hope nothing subtle broke elsewhere.
I wanted UI quality to behave more like code quality: explicit, repeatable, local-first, and able to run in CI. The product started as a visual-regression prototype, then narrowed into a more trustworthy v1 contract around visual comparison, high-confidence layout checks, accessibility, evidence, and predictable exit behavior.
Record approved baselines, capture deterministic screenshots across routes and breakpoints, and separate pixel sensitivity from the amount of visual change allowed.
Focus v1 on high-confidence defects: horizontal overflow, elements outside the viewport, and clipped text rather than broad heuristics that create noise.
Run axe-core in the same pass, preserve actionable rule evidence, and let projects decide which impact levels should fail the gate.
Keep current screenshots, diffs, selectors, bounds, JSON results, and a self-contained HTML report so a failure explains what happened.
Use predictable exit semantics for quality failures versus execution errors, with a GitHub Actions path that can start non-blocking while a project builds confidence in the signal.
Remove or reject configuration that is not implemented. Authenticated flows, hosted review, token enforcement, and noisy heuristics stay out of v1 until evidence justifies them.
I am actively running Lint UI against the things I build, including this portfolio. The Antid repository keeps approved visual baselines in Git and runs the gate in GitHub Actions while dogfood sessions continue to accumulate. That makes the portfolio both a project and a test target.
The loop has already changed the product. A below-fold check was left out after it produced noise on mobile. The HTML report was then tested by Lint UI itself, exposing contrast, landmark, and mobile overflow problems. Those defects were fixed and the same checks passed on the rerun.
Evidence changes the product contract. Features stay narrow until they are trustworthy enough to become part of the gate.
UI review should happen where code is built and checked, not only after a handoff or before release.
A narrow check with clear evidence is more useful than a clever heuristic developers learn to ignore.
Use real projects to find false positives, workflow friction, and missing evidence before turning an experiment into a feature.
Lint UI is still in active v1 dogfooding. The core now combines visual regression, responsive layout checks, accessibility validation, local artifacts, and CI-oriented result semantics. The case study will evolve with the product rather than pretending the experiment is finished.