What this is

This release added live preview to the confirming step. When you type a target value, Lens applies it to the clicked element on the page in real time, so you see the change before you commit to a diagnosis. No save. No reload. The element just updates while you type.

It also added a dynamic warning. If the value you typed will be overridden by a higher-specificity rule, Lens says so and names the real source doing the overriding: a theme, a plugin, a page builder, an inline style, or a script. Pseudo-elements got the same treatment, so ::before and ::after now have selectable property cards, live preview, and full triage parity. The property list collapses while you type so the popup stops sitting on top of the element you’re trying to watch.

What it answers

– how do i preview a css change before applying it on my site
– why does my css change not hold even though it looks right
– what is overriding my css when my change keeps getting ignored
– how to see live css changes without editing the stylesheet
– how do i style a before or after pseudo element that won’t change

Why we built it

The diagnosis is more useful when you can watch the change land before you trust it. A value that won’t survive the cascade should say so while you’re still typing it, not after you’ve pasted it.

What this is

This release fixed the cases where Lens named the wrong rule as the winner. On Tailwind v4 and shadcn sites, a padding or margin diagnosis used to point at a 0px base reset instead of the utility class actually setting the value. Logical properties like padding-inline and margin-block now map to their physical longhands at capture, so the winner you see is the rule the browser is really applying.

The verdict copy got more honest across the board. A visibility:hidden ancestor stopped reporting the display:none “your changes have no effect” message and started getting its own finding with an overridable fix. The “only applies at this screen size” verdict now fires only when the rule actually doesn’t match your current viewport, and the engine stopped presenting any winner the browser’s computed value contradicts.

What it answers

– why does lens show a 0px padding winner on a tailwind site
– how do i find which css rule is actually winning on my page
– why does my element say my changes have no effect when it’s just hidden
– how to fix padding-inline and margin-block not matching the real value
– why does the css override work in one place but not the other

Why we built it

A diagnosis tool is worthless the moment it names the wrong rule. These fixes close the cases where the answer was confidently wrong.

Phase 1 of the build-out shipped. 4 correctness items that needed to be in place before any further work could begin.

The first: element coordinates are now captured with every pick. The x, y, width, and height of the element get stored in the capture alongside everything else. This is required for CDP Track 2, which will use the coordinates to resolve @layer priority on cross-origin sites in a later phase.

The second: a double-submit guard was added to the Diagnose button. Clicking it twice rapidly was able to consume 2 credits and write 2 session rows. The guard prevents startDiagnosing() from being re-entered while a diagnosis is already in flight.

The third and fourth: when an extension update happens while a capture is in progress, the service worker now writes a flag to storage. The next time the popup opens, it reads that flag, shows a notice that says “Lens updated while you were capturing. Pick your element again,” and resets to idle instead of trying to resume a capture that’s no longer valid.

What it answers

– why did lens charge me twice for one diagnosis
– what happens when lens updates while i’m capturing
– why does lens say pick your element again after an update
– what is element_rect in the lens capture file
– what shipped in lens phase 1

Why we built it

The double-submit bug was a real credit loss. The update interruption was a known bad state with no recovery path. Both needed to be closed before build-out.

This release closed out the stabilisation pass before build-out begins. Nothing new shipped. Everything that was already in the extension got verified, fixed, or cleaned up.

The biggest fix was the login loop. When a diagnosis returned an auth error, the extension was routing to the login screen without clearing the capture from storage. On the next open, the capture was still there, the user clicked Diagnose again, hit the same error, and ended up in a loop. The fix adds a storage clear at both points in the code where auth failure can happen.

The Vision Capture race was also confirmed and fixed. The popup was opening and polling for capture data before content.js had finished writing it. The polling interval was widened from 200ms to 350ms, giving the write enough time to land.

Several pieces of dead code were removed: a side-panel block that was never reachable, an unused auth message handler in the service worker, and 2 popup functions that referenced HTML elements that don’t exist.

What it answers

– why does lens keep taking me back to the login screen
– why does lens show the idle state instead of my capture
– what was in the lens stabilisation pass
– why does lens not show my element after capturing it
– what dead code was removed from lens

Why we built it

The login loop was a direct user report. The Vision Capture race was confirmed live via diagnostics logs. Neither could go into build-out unfixed.

The confirming state got a full redesign. When you capture an element, the popup now expands to 400px and shows the screenshot at full popup width, with the description field below it. The screenshot is right there in the popup: no separate preview page to open, no guessing whether the capture worked.

The extension also got a visual overhaul: new icons, a refreshed popup CSS system, and updated triage page styles.

2 auth stability fixes shipped alongside these. The first corrected a bug where any transient network failure was logging users out. The second removed a synchronous network call that was running after every successful diagnosis.

What it answers

– how do i see my screenshot in lens before diagnosing
– why does lens keep logging me out
– why does the lens popup look different
– what is the lens confirming state
– how do i know lens captured the right element

Why we built this

The screenshot existed in the confirming state but wasn’t visible without opening a separate page. The capture preview page solved that problem but added a step. The expanded popup removes the step entirely.

3 bugs in the diagnosis path were fixed in this batch, all of them causing Lens to route users to “ask a developer” when the problem was actually solvable.

The first: Lens was checking visual properties like box-sizing and transition for override safety, which caused Elementor sites to hit developer handoff on elements that were actually fixable. The check is now scoped to visual properties only.

The second: when a stylesheet’s origin couldn’t be traced, Lens was treating the element as undiagnosable. It wasn’t. The override confidence was raised and the guidance was rewritten without DevTools jargon.

The third: Lens was missing cases where an ancestor element was causing the problem, not the element you clicked. Line-height zero, inline-attribute spacing overrides, and anomalous container heights were added to the ancestor scan, and the Edge Function was updated to surface these as the primary finding when they’re present.

The wrong-element hint was also added: when the captured element has a transparent background or an unresolvable origin, a soft note tells the user the background may be coming from a parent and suggests picking one level up.

What it answers

– why is lens sending simple fixes to a developer
– why does lens say i need a developer when i think i can fix it myself
– why isn’t my elementor element getting a fix suggestion
– how does lens know when the problem is in a parent element
– what does wrong element mean in lens

Why we built it

Diagnosis accuracy is the only thing that matters. Routing a fixable problem to developer handoff is a failed diagnosis.

A lot shipped in this batch. The most visible change: clicking “View captured element” now opens a dedicated preview page with the full screenshot, a description field, the Diagnose button, and a privacy disclosure, instead of rendering an image inline in the popup.

The extension’s screenshot disclosure was also corrected. The old copy said screenshots were “processed and deleted within 30 days.” That wasn’t accurate. The new copy reads: “Stored locally in your browser. Sent to Anthropic only if you run a diagnosis, then deleted immediately.” The privacy policy was updated to match, with a new section on screenshot retention and a corrected Chrome Web Store Limited Use Disclosure.

On the security side, the dev diagnostics tool was accessible to any external URL. That’s been fixed, and a partial refresh token that was showing in the diagnostics page has been removed.

What it answers

– why does the lens extension keep signing me out
– how does lens handle my screenshots
– what data does lens send to anthropic
– how do i see what lens captured before running a diagnosis
– does lens store my website screenshots

What this is

The Cadillac build adds 6 structured fields to every Lens capture file: dom_structure, specificity_ladder, ancestor_scan, dangerous_properties, origin_intelligence, and session_diff. These aren’t extras. They’re what makes the developer briefing precise. Before this build, the capture file described what Lens found. Now it describes what to do about it — minimum specificity to win, ancestor constraints causing the gap above an element, properties that will make content invisible on certain backgrounds, and how the element’s CSS has changed since the last time you clicked it.

Two separate Haiku calls now run on every diagnosis. One writes the founder diagnosis in normal human terms. The other writes the situation_summary for the developer in the capture file — technical language, named selectors, specificity values, origin types. One prompt can’t satisfy both audiences. Two calls means neither output hedges for the other.

Mismatch detection runs before every diagnosis. When your description contains behavioral keywords — “won’t expand,” “doesn’t work,” “nothing happens” — and the CSS classifier found a visual problem, Lens flags the gap. The triage routes to developer handoff regardless of CSS confidence. The capture file still ships. The developer gets both the CSS picture and the flag.

The triage page is rebuilt as a 3-layer structure. Option 1 (try it yourself) appears only when the route is diy_override or diy_settings. Option 2 (developer or AI handoff) is always visible on every triage page, regardless of route, without any click to reveal. The feedback form sits collapsed behind a link. Every CSS override and settings instruction carries a permanent “In testing — verify before applying” badge.

If a diagnosis is wrong, the credit comes back. Submit the feedback form within 48 hours, select a reason, and Lens refunds 1 credit automatically. One refund per diagnosis. The feedback row writes to Supabase and fires a Resend notification on every submission — inside the window or out.

Three bugs closed. The Vision Capture timing race that left the popup showing idle instead of confirming is fixed with a 6-retry polling loop covering 1200ms. The MutationObserver false-positive that cancelled active picks on pages with widget DOM mutations is fixed with a node count threshold — 10 or more non-Loupely element nodes required to treat a mutation batch as navigation. The auth callback bug that cleared capture keys during token refresh is fixed with a preserve branch in the auth handler.

What it answers

– what’s in the loupely lens capture file
– how do i know what specificity to use to override a css rule
– why does the css fix not work when i apply it
– what does loupely lens do when something looks wrong on my site
– what happens if the lens diagnosis is wrong

Why we built it

The capture file has always carried the right raw data. The Cadillac build is the layer that turns raw data into a briefing a developer can act on without asking follow-up questions. Session diff tells you whether the last change made anything better. Ancestor scan tells you which parent element is causing the gap. Specificity ladder tells you exactly what to write to win the cascade. The data was there. Now it’s organized.

What this is

2 session-breaking bugs were found in live testing and fixed in a single release. The first: if you clicked an element that was part of the WordPress admin bar, Lens ran a diagnosis on it, consumed a credit, and returned a result for an element that only exists for logged-in admins. The fix built a 3-layer guard: content.js flags is_wp_admin via closest(‘#wpadminbar’), popup.js checks the flag before entering the confirming state, and lens-diagnose.ts verifies server-side. The guard was verified live against span.ab-icon, an admin bar element that had been picked in testing without the user realising it.

The second: if the AI returned an empty result, the popup showed a blank screen and still decremented the credit. The null result guard fixed this. When claudeResult is null, the session row is flagged null_result: true, no credit is decremented, and the popup shows a specific message instead of a blank screen.

What it answers

– why did loupely lens diagnose my wordpress admin bar
– does loupely lens charge me if it diagnoses the wrong element
– what happens if loupely lens returns an empty diagnosis
– does loupely lens refund credits for a null result
– how does loupely lens detect the wordpress admin bar

Why we built it

A credit charged for a null result and a credit charged for an admin bar element are both the same broken promise. Both were caught in testing and fixed before any paying user could hit them.

What this is

The ancestor traversal performance budget was exceeded in the previous release. The root cause was buildMatchedRuleMap: it ran a CSS selector match test against every rule in every stylesheet for every ancestor level, making the cost O(ancestors times total rules). On a 121-stylesheet fixture, that was about 96,000 match tests per pick, with buildMatchedRuleMap accounting for 93% of total ancestor time.

The fix restructured the function so per-rule preprocessing (selector split, pseudo-strip, origin classification) ran once per page and the result was reused across the full ancestor chain. A conservative pre-filter was added to fast-reject simple single-token rules before calling el.matches(). The output-equality contract was verified: the rule map fingerprint was identical before and after the change across 30 maps and 646 total entries.

The final performance sweep at 5 runs showed ancestor traversal at 135 to 163 milliseconds across all runs. Every run under budget, with 37 milliseconds of headroom at worst.

What it answers

– why is loupely lens slow on wordpress with many plugins
– how fast is loupely lens on a plugin heavy wordpress site
– does loupely lens work on sites with 100 plus stylesheets
– how did loupely lens fix its ancestor traversal performance
– what is the loupely lens performance budget for css capture

Why we built it

The target user has a plugin-heavy WordPress site. That is the exact profile that hits 100-plus stylesheets and would have felt the performance problem hardest. The fix was required before launch.