The web face

One page, no build step, no assets. pac ui serves it:

pac ui            # http://127.0.0.1:7454
pac ui --port 8080

What it shows, first, is what every flow on the node produced -- read through the results surface, so the page knows no flow's route -- then what the node holds, read through the sources surface the same way, and then the trace, runs and their turns, sessions, peers, and the installed plugins with whether each is actually running. A node without @projectpac/results or @projectpac/sources installed says so in place of that tab.

Why it is not served by the control API

The spec is explicit that a UX is a client of the API and not part of the node: the faces of the control API are "clients of this API rather than parts of it". So this is a second UX that happens to speak HTML, served by a little server of its own rather than by the daemon.

That server does two things, and both are the point:

• It serves one file. No script, style, or image comes from anywhere, and the page says so in its own content-security-policy. A page that cannot fetch from elsewhere cannot send a node's state elsewhere.
• It proxies the API and adds the token. The browser never holds the token, everything the page does is same-origin, and the node needs no cross-origin allowance to be looked at. The proxy will only sign for an allowlist: reads, and enabling or disabling one plugin.

Everything else a token can do -- installing or removing a plugin above all, which runs somebody else's code -- is deliberately not something a page can ask for. Those are the CLI's, where the operator types them.