@projectpac/web
v0.1.0
Published
Part of PAC: @projectpac/web.
Readme
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 8080What it shows: the consent queue (answerable), the trace, runs and their turns, sessions, peers, the human's sources by name and description, the installed extensions with whether each is actually running, and the policy document.
Why it is not served by the control API
The spec is explicit that an interface is a client of the API and not part of the node: "a CLI, a GUI, or an MCP server is a client of this API and needs no manifest". So this is a second interface 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, answering one consent question, and enabling or disabling one extension.
Everything else a token can do -- ingesting the human's data, replacing the policy, installing or removing an extension -- is deliberately not something a page can ask for. Those are the CLI's, where a human types them.
