Quox Dev Suite · Qlarity · governed browser inspection
Look at the page yourself, with a receipt.
Qlarity opens the page in an isolated headless session and answers the question directly, and every look it takes is logged, witnessed and yours to audit.
In plain words
What it is, where it lives, when to reach for it
- What is it
- A browser inspection service in the Quox Dev Suite: it opens a page headless and reports what it finds.
- Where do I use it
- In your terminal through the quox CLI, against pages on origins your org has allowlisted.
- When would I use it
- When you need to know what a live page is actually doing before calling a fix done.
- How do I use it
- Run
quox qlarity read <url> --inspector <name>; it opens the page, answers, and keeps the receipt.
Ask precisely
Data in, never a code string.
An agent that calls a UI fix done on a passing unit test has only done half the job: the answer lives in the browser, in a computed style, a pseudo-element, a storage key.
Each inspector answers one question shape. You name an element and a property; you never hand the browser arbitrary code just to read a style.
computed_style
the style the browser actually resolved
pseudo_style
the ::before and ::after rules behind half of all misdiagnosed bugs
text_content
what the node really says
attribute
any attribute, verbatim
count
how many match
bounding_box
where it sits and how big
storage
local and session storage, read-only
structured calls · no eval required
Blast radius
A browser that cannot wander.
Each session is its own browser context, never shared, org-checked on every call, dead after five idle minutes and thirty total. The page’s own network is default-deny: only hosts you allowlist load, everything else is aborted and listed in the result. Wildcards are refused. The metadata endpoint and your internal services are unreachable by construction.
default-deny egress · 3 sessions per org · 30 min lifetime
The receipt
Every look on the record.
Opening a session, opening a page, every inspection and every eval request emits an envelope into the audit chain and is hash-witnessed. And because nobody can decide in advance which script is safe, running arbitrary JavaScript is always an approval: a human says yes, on the record, every time.
six AEE intents · WARD-witnessed · eval is always an approval
Where it fits
Three ways to find out what is actually happening.
Debugging a page usually goes one of three ways: a human pastes the console, an agent is handed a browser it can click and type with, or it is handed Qlarity. Only one of the three hands back a verdict instead of a transcript.
| Check | Qlarity | “Paste me the console” | Generic browser MCP tools |
|---|---|---|---|
| Evidence written to disk | Yes. Every call appends to evidence.jsonl before the result returns; a failed write fails the call. | No. Gone the moment the tab closes. | Not by default. |
| Assertions, not eyeballs | Yes. Named checks return pass or fail with measured evidence, not a picture to interpret. | No. A human reads the pixels. | No. Still a screenshot or a DOM dump to interpret. |
| Layout health in one call | Yes. Overflow and its cause, sub-44px tap targets, sub-12px text, images with no dimensions. | No. | Not a standard primitive. |
| Responsive sweep | Not yet. A session runs at one viewport, so checking breakpoints means a session per breakpoint. | Manual, one viewport at a time. | Manual, one call per breakpoint. |
| Runs headless, no window | Yes. A disposable Chromium profile, no port opened. | No. Needs your own visible browser. | Usually, yes. |
| Drives the page (click, type, fill) | No, by design. Inspect only: a smaller surface to worry about. | You do the driving. | Often, yes. |
| Announces what it checked | Yes. States the URL and the check before running it. | Whatever the human types. | Not a convention. |
Where you drive it
Dashboard, terminal, and counting.
A dashboard view for the session and its findings, and seven CLI subcommands for scripted checks: health, allowlist, inspectors, sessions, close, read and eval. Agent tools over MCP are on the roadmap, so your fleet will file its own inspection requests through the same gate.
quox qlarity · 7 subcommands
▸ coming · qlarity agent tools over MCP
The verification specialist
The one that will not say fixed without looking.
Every dev suite needs a member whose only job is to check. Qlarity is that member: it opens the page, reads the console, measures the layout and hands back a verdict, not a guess.
An agent that calls a UI fix done on a passing unit test alone has only done half the job; Qlarity is how the other half gets done, and it is why an agent that skips it should be told to name the blocker rather than ask a human to look instead.
That is the same discipline running through the rest of the platform: an honest refusal is worth more than a plausible guess, and a correction made in the open beats a claim that quietly turns out wrong. Qlarity does not have an opinion about your code. It has evidence.
Driven, not described
The refusals are the product
A real session against a live instance, viewer role, no set-up. Nothing can be inspected until an origin is declared, and declaring one is an admin act: both answers below are the governance working, not the tool failing.
$ quox qlarity allowlist policy: default-deny no origins declared: nothing can be inspected (safe default) $ quox qlarity origins add https://quox.ai 403 Changing the QLarity allowlist requires an org admin $ quox qlarity inspectors computed_style · pseudo_style · text_content · attribute count · bounding_box · storage data in, never code: arbitrary eval always goes to the approval inbox
Part of a bench
One of the dev suite.
Qlarity is the inspection member of the Quox dev suite, alongside planning, build and documentation tooling. It stands alone today and joins the suite bundle as the bench fills out.
blueprint · clarify · build
Where it stands
What's proven, what's still beta.
The maturity map for the whole surface, current as of the last audit. Nothing here is marked Stable yet: every capability is Beta or Experimental, and the status doc says so in writing.
- Default-deny egress: live-verified 2026-07-31 against a real fixture page, a call to the metadata endpoint 169.254.169.254 and a call to the collector on its internal address were both aborted by the interceptor
- The seven named inspectors: live-verified, pseudo_style returned a real content, opacity and z-index from an actual ::before rule, the exact class of bug this inspector exists for
- The governed boundary at the collector: live-verified through the running proxy, unauthenticated calls return 401 and an unlicensed org returns 403 on both /health and /sessions
- The HTTP service surface: org-scoped session, open, inspect and eval routes, with no default org so an unknown tenant never silently becomes some tenant
- Per-session browser isolation and lifecycle reaping are Beta: ownership is re-checked on every call and ownership errors are indistinguishable from not-found, but this has not been soak-tested at scale
- The dashboard plugin has a manifest, route, nav entry and a native view, but is not yet built into the running dashboard, so the view is not visible on this box today
- The CLI is Beta: health, allowlist, inspectors, sessions, close, read and eval all route through the collector proxy, but only the refusal path is verified; the licensed pass-through has not been tested end to end
- The licensed (positive) path through the governed boundary is unproven: the gate is shown to refuse correctly, not yet shown to admit correctly, because granting a licence is an owner decision, not a code change
- Agent tools (qlarity_*) are Beta: four real tools exist (open, inspect, eval, close), granted to a single agent so far
- Arbitrary eval is Experimental, always a human approval by design: with no HITL sink wired yet, it returns 501 rather than running code, so the approval flow itself is untested here
- Authenticated inspection is not supported: unauthenticated pages only, it will not log into your app
- Per-organisation allowlists are live: an org admin declares the origins their sessions may inspect, from the dashboard or with quox qlarity origins add, without an operator touching the host. The install-wide default still applies on top. Widening to internal targets stays operator-only by design
- Screenshots are not implemented: the proxy assumes JSON or text, no binary passthrough exists yet
Ready when you are
Stop asking the page. Ask Qlarity.
Governed inspection for every dev server your team runs, sold on its own in the store.