Qlarity

Governed browser inspection: named inspectors that take data, never code.

Overview

Two bad habits kill debugging time. An agent guesses what a page is doing, or it asks a human to go and look. Both are avoidable, because the answer is sitting in DevTools and takes two seconds to read.

Qlarity opens a real page in an isolated headless session and answers runtime questions directly: computed styles, pseudo-element rules, DOM reads, storage, element counts, bounding boxes. Every session runs in its own browser context, reaches only origins the operator has declared, and leaves an evidence trail.

Named inspectors: data in, never code

This is the design decision the whole plugin rests on.

An inspector is a parameterised read. It takes a selector and a property. It does not take a code string. computed_style with h1 and color is a read; browser.eval("...") is a remote code execution primitive wearing a debugging costume.

bash

quox qlarity inspectors                                    # what reads are available
quox qlarity read https://example.com --inspector computed_style \
  --selector "h1" --properties "color,font-size"

The read verb is a one-shot: it opens the page, runs the inspector, prints the result, and closes the session.

Arbitrary JavaScript is not simply unavailable, it is routed through approval:

bash

quox qlarity eval <url> <script>

This files an inbox item and exits. It never runs inline, not even for an operator, because a tool that can be talked into running arbitrary JS on an internal origin is a lateral-movement primitive, and the approval queue is what keeps a persuasive prompt from being enough.

Origins

Two layers, deliberately separate:

bash

quox qlarity allowlist     # what this deployment may inspect at all (host-level)
quox qlarity origins       # what THIS org may inspect (org-level, self-service)

An org adds and removes its own origins without touching the host allowlist, and cannot reach outside it. The host operator sets the outer boundary once.

Sessions

bash

quox qlarity sessions          # what this org has open
quox qlarity close <sessionId> # free a browser context
quox qlarity health            # service health through the governed proxy

Every session gets its own browser context, owned by the org that opened it. Sessions are capped and expire, because leaked headless browsers are not a theoretical problem: a leaked Chromium can peg a CPU at 99% for days, which is exactly why the idle and lifetime caps below exist.

Limits and honest status

3 sessions per org, 5 minute idle timeout, 30 minute maximum lifetime, on the paid tier. Free tier has zero sessions.
Allowlisted origins only. An origin nobody declared is refused. This is intentional and is not a bug to work around; a governed inspector that inspects anything is not governed.
Chromium today. The interesting future case is WebKit, because Safari-only render bugs are invisible to a Chromium-first automation market. That is not shipped, and this page will not claim it until it is.
Reads, not interaction. Inspectors read state. Driving a flow (clicking through a wizard, filling a form) is not what this is.
Authenticated pages are the rough edge. Inspection of a page behind a login the inspector does not hold is not solved.

For the current per-surface maturity map, see STATUS_AND_LIMITS_DEVSUITE.md in the dashboard repo.