@projectpac/onboard

Setting a node up, once, for every door that offers to.

There are three ways to get a node -- download the app, paste the one-liner, or hand an agent the install document -- and they used to build different shapes of node. The app wrote an executor config naming a session file and a transcript; the script printed a --command line carrying neither, and never ran it. Same words, different node.

What differs between the doors is presentation. Everything else is here: which harness an answer resolves to, what that harness is run with, how pi is installed and signed in, the turn that proves a model answers before a node is built around it, and the order all of it happens in.

Two entrypoints

| import | what | may reach a process | | ------------------------------ | ----------------------------------------------------- | ------------------- | | @projectpac/onboard/contract | the defaults, the answers, the harness table | no | | @projectpac/onboard | installing pi, the trial, pi's api, the orchestration | yes |

The split is not tidiness. The desktop renderer compiles against the DOM and may import exactly one module of the app's, because a boundary type that drags node's fetch in behind it makes the two libraries disagree about what a request body is. /contract is what a window may have; esbuild's browser platform is what enforces it.

Where it sits

Strictly below the cli, which is what keeps it acyclic: the cli depends on this, the app depends on both, and nothing here imports either. Starting and stopping a node stays the cli's one exception to being a client, and this package spawns pac setup by resolved bin rather than doing any of it itself.