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.

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.