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.

What this is

The first real end-to-end diagnosis ran. A click on an Elementor button, a problem class confirmed, a diagnosis returned in normal human terms, a triage route chosen, a session row written to Supabase, and a credit decremented. The full chain worked.

The credit system was verified: zero-credit accounts returned a 402 with the session row still written, annual plan accounts bypassed the credit check, and the insufficient_credits error routed correctly to the no-credits popup state. The full popup state machine shipped: picking_active, confirming, diagnosing, result, no_credits, and error states, each with specific messages and exits. The triage page was built separately, opened from the result state.

A founder description field was added to the confirming state (280 characters, optional), which later fed the developer handoff message. Bold weight was reduced across the popup and the popup result text was trimmed to one sentence plus route label.

What it answers

– does loupely lens actually work end-to-end
– how does loupely lens charge credits for a diagnosis
– what does the loupely lens popup show after a diagnosis
– does loupely lens work with annual plan accounts
– what is the confirming state in loupely lens

Why we built it

Nothing in Phase 2 was worth anything until the diagnosis pipeline ran real. This release proved it did.

What this is

The full CSS capture pipeline shipped across 9 stages. Every aspect of what Loupely Lens captures when you click an element was built in this release: where each CSS rule came from, how it competed against other rules, what the ancestor chain was doing to constrain the element, which nearby elements were interfering, and whether the problem was one of 9 specific visual failure types.

Origin classification assigned each CSS rule to one of 12 categories: theme, plugin-internal, plugin-external, page-builder-cache, css-in-js, mu-plugin, js-injected, inline-attribute, browser-default, and others. isSelectorDynamic detection covered 9 patterns including Styled Components, Emotion, Gutenberg block hashes, and Bricks builder. Ancestor traversal captured 30 levels of parent context, 63 CSS properties each. Competitor detection captured up to 10 nearby elements with their types and relationships. CSS variable resolution chains traced values up to 5 levels deep.

The credential scan ran before the relay write. Schema 3.0.0 structured the output with top-level keys: meta, stylesheet_map, target_element, ancestor_chain, competitors.

What it answers

– how does loupely lens know which plugin is causing a css conflict
– how many ancestor levels does loupely lens capture
– does loupely lens detect css-in-js styled components
– what is included in the loupely lens capture file
– how does loupely lens find competing css rules

Why we built it

The diagnosis is only as accurate as the evidence it reads. Every component of the capture pipeline existed to give the diagnosis model a complete, correctly classified picture of the CSS state.

What this is

The Loupely Lens Chrome extension shipped its first working build. The extension installed on any website in Chrome, the picker activated, and captures downloaded as structured files. The backend infrastructure was built from scratch: a Supabase development project with shared users, credits, and sessions tables, a deployed lens-diagnose.ts Edge Function stub, and the useloupely.com auth callback page and extension-ids.json file that the magic link authentication system depended on.

Authentication shipped end-to-end using magic links. An email field, a send-link button, a 60-second resend countdown, and a post-click idle state. No password. The session survived extension reinstalls and worked across devices. The service worker stored the access token in module scope only, following the Loupely v5.3 auth-manager security model.

Captures were written to chrome.storage.local via a relay mechanism, not via direct download from the content script. The popup read the relay on open and served the download. A diagnostics page was added for internal development use.

What it answers

– how do i install loupely lens chrome extension
– does loupely lens require a password to sign in
– how does loupely lens authenticate without a password
– what does loupely lens capture when you click an element
– does the loupely lens extension work on any website

Why we built it

The narrowest possible working slice first. Every subsequent feature was built on top of this foundation. Nothing else could start until the picker worked, the relay wrote, and the file downloaded.