The console

alloy console serves a local, strictly read-only web UI over your working-tree corpus. It is the fastest way to see what the trust machinery has computed - drift, coverage, gaps - instead of reading JSON.

alloy console                 # serves on the default port
alloy console --port 8080     # pick a port

It binds 127.0.0.1 and rejects any request whose Host header is not loopback, so it is a local inspector, not a shared service.

It sees what agents see

The console composes the same knowledge scope an agent composes at the same working directory: your repo's own corpus, every source it references with alloy add, and any other repo open beside it. The header's second row is that scope line, verbatim - the same [scope] primary=… peers=… deps=… an agent's answer carries - with a chip for anything worth knowing about it (a reference collapsed into an open working tree, an unavailable one and the command that fixes it, a legacy lock).

You can start it from three places:

• Inside a repo - that repo is the primary; its referenced sources are in scope.
• Above several repos - open the folder that holds them (no file is needed there) and the console composes every child repo's knowledge base. The first child in name order is the primary; --root <dir> reorders.
• With an explicit path - alloy console <path-to-corpus> serves that corpus alone, as before.

Every per-source screen (Browser, Coverage, Freshness, Gates, Governance, Proposals, Sources) carries a source: picker in its pane title, and the choice rides the URL as ?corpus=. A referenced source browses read-only - its docs, graph nodes and search hits are there because an agent here can reach them - but coverage, freshness, gates, governance and proposals are maintained by its own repo, so those screens say so instead of showing an empty report.

What it shows

The console renders the same pure functions the CLI uses, so nothing it shows can disagree with alloy status or alloy validate:

• Corpus browser and doc inspector - read any doc of any source in scope with its provenance, lifecycle state, supersession banners, and the qualified keys it builds on (each one a link into the playground).
• Graph - the whole scope's relationship structure as a live force-directed map: related edges, supersession chains, and the dotted builds_on edges that cross from your docs into a referenced source. Colour by category, group or source; toggle a source's nodes off; "reached only" keeps just the referenced docs something of yours builds on. The best first look at a freshly established corpus.
• Resolver playground - resolve a query key (qualified keys like foundation/sdk:user resolve in that source) and watch redirect-versus-silence change as you switch the active view. This is the quickest way to feel what a view does.
• Search across every source in scope, each hit badged with where it came from and cited in the qualified form.
• Sources - the management surface: every source in scope with its kind, locator, declared ref, pin, transport and view; an unavailable one with its reason and the exact command to run; a legacy lock with alloy migrate. Read-only, with the commands to copy. Beneath it, the discovery inventory of the picked working tree.
• Coverage - EXTRACTED / EXCLUDED / UNKNOWN per source, with the UNKNOWN queue and the exclusion rationales. The place to see what still needs triage.
• Freshness - per-unit drift, with the changed-file lists behind each drifted unit.
• Gap queue - ranked unresolved-query telemetry: what agents looked for and did not find.
• Quality-gate roster - the validators and their state.

Read-only is structural

Read-only here is not a convention you could accidentally break - it is enforced by construction. There are no POST routes at all. Sources resolve in a no-checkout mode (a source that would need a fetch is reported "skipped" rather than fetched), and a full sweep of every request writes nothing - not the repo, not the checkout cache, not query telemetry. To see live data for a source that reads an external checkout, point ALLOY_SOURCE_PATH_<NAME> at a local clone before starting the console; this repo's own self: source needs no such override.

When to reach for it

Use the console when you want to demonstrate the corpus (a browsable view of coverage and freshness reads better than a terminal), when you are triaging UNKNOWN and want the queue and rationales side by side, or when you are tuning a view and want to watch resolution change live. For scripting and CI, use alloy status --json instead - the console is for humans looking, not for machines gating.