<>
Loupely Lens Changelog
Every release, documented. What shipped, what changed, and why it matters.
18 releases
Loupely Lens delivers its first real diagnosis end-to-end
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.
Improvements 4
- Credit system verified: 0-credit accounts return 402 with session row preserved, annual plans (bundle) bypass credit check and return credit_balance_remaining: null
- Full popup state machine shipped: loading, unauthenticated, idle, picking_active, confirming, diagnosing, result, no_credits, and error states
- Triage page built: triage.html, triage.css, triage.js with route-specific display, copy buttons, and download
- Founder description field added to confirming state: 280 characters, optional, feeds developer handoff message
The full CSS capture pipeline ships: origin classification, ancestor traversal, and schema 3.0.0
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.
Improvements 9
- Origin classification built: 12 categories covering theme, css-in-js, mu-plugin, page-builder-cache, plugin-internal, js-injected, and flex-computed detection
- IsSelectorDynamic extended to 9 patterns, adding Styled Components, Emotion (2 patterns), Gutenberg block hashes, and Bricks builder to the original 4
- GetAccessibleSheets extended to traverse @layer block rules, @container rules with a hard cap at 200, and document.adoptedStyleSheets
- Losing rules cap added at 10 per property in buildMatchedRuleMap, with a meta.losing_rules_truncated flag when exceeded
- Ancestor traversal built from scratch: 30 levels, 63 computed properties each, selection_context on every entry, chain ends at body
- CSS variable resolution chains added: up to 5 levels deep, color-first ordering, _variableChainTruncated flag when truncated
- Competitor detection added: overlap competitors, flex and grid siblings captured, html/body/ancestors/descendants excluded, cap at 10 with _competitorsTruncated flag
- Problem detection added: detectProblemClass scores captures against 9 problem classes and writes problem_class_detected, problem_class_confidence, and problem_classes_secondary to the relay
- Credential scan added before relay write, scanning inline style attributes, data attributes, and URL query strings
Loupely Lens ships: extension foundation, magic link auth, and capture relay
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.
Improvements 9
- Supabase development project created with users, credits, and sessions tables, RLS policies, and a new-user trigger
- Lens-diagnose.ts stub deployed to the development Supabase project, returning a test diagnosis response on a valid JWT
- Useloupely.com/auth-callback page and extension-ids.json deployed, enabling the magic link auth callback flow
- Manifest updated: ExtPay removed, content scripts scope changed to any website (*://*/*), externally_connectable set to loupely.com
- Service worker rebuilt with onInstalled, onStartup, GET_AUTH_TOKEN, SIGN_OUT, and token storage in module scope only
- Magic link authentication shipped end-to-end with 60-second resend countdown and idle state on successful sign-in
- Capture relay built: content script writes ll_capture_result and ll_capture_ready to chrome.storage.local; popup reads relay on open and triggers the file download
- Stale and corrupt relay keys handled: age check clears expired captures, corrupt JSON clears keys without crashing
- Diagnostics page added at lens-diagnostics.html with storage viewer, inject test values, Copy All, and auto-refresh