What this is

Latency instrumentation was added to the sessions table: two permanent fields, server_latency_ms and image_sent, recorded on every session from this release forward. The first datapoint: Haiku averaged 5.6 seconds text-only, with about 2 seconds of overhead. Latency was dominated by Haiku, not by the extension pipeline.

The @container cap, which had been shipping in every version without ever working, was fixed. The original check used containerRule.type === 12, which was incorrect: container rules are post-freeze CSS rule types that return 0 in current Chrome, not 12. The check never matched, so the cap never fired. The fix used instanceof CSSContainerRule. Verified via a 3-point fixture test at 150, 200, and 250 container queries.

Performance instrumentation was built into the diagnostics page: last_capture_timings, a pass/fail panel, and per-sub-step timing. The PERF sweep on a 121-stylesheet stress fixture showed PERF-1 and PERF-3 passing, and PERF-4 (ancestor traversal) exceeding its budget at 192 to 234 milliseconds against a 200-millisecond budget.

What it answers

- how fast is loupely lens css diagnosis
- does loupely lens measure diagnosis latency
- what was wrong with the loupely lens container query cap
- how does loupely lens measure performance
- what is the loupely lens ancestor traversal speed

Why we built it

You can't fix what you don't measure. The latency instrumentation built the data moat. The performance sweep found the one budget that was failing.

What this is

19 shadow tests ran against the production build. 9 full passes, 7 partials needing better fixtures, 0 hard failures. No wrong routes, no crashes, no regressions. Shopify layout, Webflow overlap, Squarespace platform detection, Styled Components CSS-in-JS, flex-computed gap, popup close during diagnosis, session row fields: all passed cleanly. The 7 partials (dense DOM depth, wrong element picked, Tailwind losing rules, dark mode, adoptedStyleSheets, preference_breakage, variable chain truncation) needed fixture improvements but none were launch blockers.

Glossary tooltips shipped in the same build: 21 technical terms on the triage page with hover and tap definitions in normal human terms. Mobile-friendly tap interaction. Never in the diagnosis text itself. Optional teaching affordance, never forced.

What it answers

- has loupely lens been tested on real websites
- does loupely lens work on shopify and webflow
- what are the glossary tooltips in loupely lens
- does loupely lens pass shadow tests before launch
- what does loupely lens milestone c mean

Why we built it

The shadow tests were the gate between building the product and trusting it on real user sites. Milestone C meant the product worked against real-world diversity, not just controlled fixtures.

What this is

The triage output layer shipped. Every CSS diagnosis now routes to one of 4 specific next steps: a CSS override you paste yourself (with an editable code block and platform-specific navigation instructions), a settings change in your page builder or theme, a developer handoff with a numbered sequence and pre-written message, or a file prepared for an AI tool. The route was determined by the CSS evidence in the capture, not by the diagnosis model's judgment.

8 warning types were added to the result page: page-builder-cache (fix may be overridden on next save), css-in-js (class name will change on rebuild), dynamic selector, !important, inline-attribute, selector breadth, preference_breakage, and animation. These appeared inline with the triage instructions.

The confirming state was redesigned. The detection card was removed. The description-first flow replaced it: you describe what you see, then confirm. A free download path was added so you could download the capture file without running a diagnosis. The auth callback bug that caused the popup to revert to sign-in form after the first diagnosis was fully resolved.

What it answers

- what does loupely lens tell me to do after a diagnosis
- does loupely lens give me the css code to paste
- how does loupely lens handle elementor css overrides
- what are the loupely lens triage warning messages
- what changed in the loupely lens confirming state

Why we built it

The diagnosis alone wasn't useful. The triage route was the product. Without it, knowing what was wrong was just information without an action.

What this is

The picker overlay was cancelling itself about 2 seconds into every pick. The root cause was the MutationObserver AJAX-navigation cancel, which was watching all DOM mutations and firing on the picker's own hover mutations (tooltip text changes, outline style changes). It was treating the picker's own activity as a page navigation and cancelling the pick.

The fix moved the picker deadline timer from the popup (which closes the instant picking starts, making its timer useless) into content.js, which owns the page context and survives the full pick. The timer was raised to 60 seconds. The MutationObserver was updated to ignore attribute and characterData mutations and picker-owned nodes, firing only on genuine childList navigation changes. The picker was verified stable through 24 seconds of deliberate hovering.

What it answers

- why does loupely lens picker cancel on its own
- why does the loupely lens overlay disappear when i hover
- loupely lens picker keeps cancelling before i click
- how does loupely lens picker timeout work
- why did my loupely lens pick fail before i clicked

Why we built it

A picker that cancels during normal hover is unusable. This was the most disruptive live-testing failure and was fixed before any other work continued.

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.