What this is

2 diagnosis quality problems were identified in live testing and fixed in a single release. The jargon rewrite, which ran a second Haiku API call after the first to rephrase the diagnosis in normal human terms, was removed entirely. It added several seconds to every diagnosis and rarely worked correctly. The system prompt was strengthened instead: it now forbids explaining the CSS mechanism in technical terms and instructs the model to name the concrete source directly. The containsJargon telemetry signal was kept but made non-blocking.

The detectProblemClass scoring was rebalanced. The layout_constraint class had been over-firing because the original scoring counted flex, grid, and overflow:auto signals universally across the full ancestor chain, which are present on almost every modern website. The fix: only genuine constraints count, only the nearest 3 ancestors are inspected, and the total layout contribution is hard-capped at 2. Verified on 2 controlled fixtures.

What it answers

– why does loupely lens diagnosis take so long
– why does loupely lens say layout constraint when it isn’t
– how does loupely lens avoid css jargon in its diagnosis
– does loupely lens still run 2 api calls per diagnosis
– how accurate is loupely lens layout problem detection

Why we built it

A diagnosis that takes 8 seconds and uses CSS jargon isn’t useful. Neither is one that classifies every page as a layout constraint. Both problems were caught in the first live session and fixed before any more sessions ran.