The web UI inside the binary

Running it #

$ ns-brain ui
serving http://127.0.0.1:7788 · opening a browser

$ ns-brain ui --port 8100 --no-open
$ ns-brain ui --host 127.0.0.1

It binds loopback, serves its assets out of the binary and exits when you stop it. There is no daemon to leave running and nothing is written to disk by starting it.

What it shows #

View	What it answers
Brief	Exactly what a session receives at open, rendered rather than piped through a terminal.
Memories	Search and browse with the real ranking behind it, filtered by scope, type, tier and project.
Tree	The scope tree, walked. The fastest way to see a scope somebody invented with a typo.
Events	The activity trail, by kind and by date.
Measures	Series and their bands, which read far better as a shape than as a column of numbers.
Leads	The sales pipeline, for the projects that use it.
Map and stats	Scopes, kinds, pinned memories, counts and which database file you are actually on.

Why it holds no SQL #

A second implementation lived in a Node server.js and drifted three times: the bm25 relevance fix, the project filter after the store merge and the snooze column were each fixed in the client and silently missed there. Three bugs, one cause and the page kept looking right while showing the wrong ranking.

So the rule is: if the UI needs data the CLI cannot produce, it goes into the CLI. Not into the viewer. The viewer moved inside the binary at the same time, because a Node viewer was the one part of the product that broke the promise of having nothing to install and nothing ever installed it anyway.

The one thing it writes #

The rule is not "the UI never writes". It writes exactly one thing: forget, by running ns-brain forget. Which means the pinned refusal, the guardrail refusal and the chain-head refusal arrive on the page as the CLI's own text, with the same wording and the same conditions.

Everything else is a read. Editing, the review queue and conflict resolution are the hosted UI's job.

What guards the page #

A local page is still a page and a browser tab you did not open can still talk to localhost. A write needs proof it came from this process:

A token minted per process, compared in constant time, on every POST.
An Origin check on every POST, so another tab cannot drive it.
A Content-Security-Policy, nosniff and a host allowlist.
Bodies capped at 64KB.
Every innerHTML in the app is a clear-to-empty. Content goes through textContent, so a memory body cannot become markup.

The hosted UI #

On Hive this same UI still runs from the binary on your machine, against the server, because every route it serves is an ordinary command and ordinary commands route. What the server hosts is the organisation's dashboard: people, approvals, credentials, billing and a full export. A hosted memory browser with editing, the review queue and conflict resolution is designed and not built, which is stated here rather than discovered.