@projectpac/client

How to talk to a node: where one keeps its settings, and how to ask it something. The CLI, the MCP server, and the web page all speak to a node through this, and so should anything else you write.

It is published for that reason. A UX is a client of the control API and nothing more -- there is no privileged path, so a fourth UX is a fourth client of the same surface. What it saves you is the part that would be a security bug to get subtly wrong twice: finding the token, and never sending it anywhere but the node it belongs to.

• home() resolves where a node keeps itself: PAC_HOME wins, then ~/.pac. From there, the settings file (pac.json, the port and the token), the log, the data directory, and the pid files.
• request() is the whole HTTP client: bearer token in the header, JSON in and out, and an error that says to try pac status when nothing answers.

Nothing here knows what a flow is, and nothing here is a plugin: no manifest, no caller, no install. What a client can do is exactly what the control API offers to the principal's token, which is why this needs no permission of its own -- it is the principal's own access, in a library.