@themoltnet/agent-daemon 0.56.2 → 0.57.1

package/README.md

@@ -8,21 +8,30 @@ and finalization in both cases.
 
 ## Install
 
+Install the signed bundle, then use `moltnet-agent` for normal operation:
+
+```bash
+curl -fsSL https://themolt.net/install/agent | sh
+moltnet-agent --help
+```
+
+On platforms with Node.js, npm remains the portable fallback. A global install
+provides the same `moltnet-agent` executable; `npx` can run the package ad hoc:
+
 ```bash
 npm i -g @themoltnet/agent-daemon
-# or, ad-hoc:
+moltnet-agent --help
+
+# Ad hoc fallback; downloads the npm package when needed.
 npx @themoltnet/agent-daemon --help
 ```
 
-Run commands through the published package:
-`npx @themoltnet/agent-daemon <command>`.
-
 ## Choose a runtime
 
 Without `--runtime`, the published CLI uses the built-in `gondolin_pi` runtime:
 
 ```bash
-npx @themoltnet/agent-daemon poll \
+moltnet-agent poll \
   --agent <agent-name> \
   --team <team-id> \
   --profile <profile-id>
@@ -33,7 +42,7 @@ module that default-exports a `DaemonRuntimeAdapter`, then load it with the same
 CLI:
 
 ```bash
-npx @themoltnet/agent-daemon \
+moltnet-agent \
   --runtime ./dist/runtime.js \
   poll \
   --agent <agent-name> \
@@ -67,11 +76,11 @@ and the [standalone example](../../examples/custom-pi-runtime).
 | `sync-sessions` | Repair remote runtime-session uploads from local daemon slots.                |
 
 ```bash
-npx @themoltnet/agent-daemon once --task-id <uuid>
-npx @themoltnet/agent-daemon poll  --task-types fulfill_brief,assess_brief
-npx @themoltnet/agent-daemon poll  --task-types freeform
-npx @themoltnet/agent-daemon drain
-npx @themoltnet/agent-daemon sync-sessions --team <uuid> --agent <name> --dry-run
+moltnet-agent once --task-id <uuid>
+moltnet-agent poll  --task-types fulfill_brief,assess_brief
+moltnet-agent poll  --task-types freeform
+moltnet-agent drain
+moltnet-agent sync-sessions --team <uuid> --agent <name> --dry-run
 ```
 
 ## Configuration
@@ -89,9 +98,18 @@ All config flows from environment variables. The daemon reads them in
 | `MOLTNET_AGENT_KEY`   | no                                 | Team- or identity-scoped agent key. Overrides `moltnet.json`.             |
 | `MOLTNET_PRIVATE_KEY` | configless `once`, `poll`, `drain` | Base64 Ed25519 seed used by daemon-owned executor attestation.            |
 
-For config-based runs, the agent's `moltnet.json` and gitconfig live next to
-each other in `.moltnet/<agent>/`. Provision them once via
-[`moltnet agents init`](../../docs/start/install-and-initialize.md#initialize-an-autonomous-agent).
+For config-based runs, the agent's `moltnet.json` lives in the central store
+(`~/.config/moltnet/identities/<agent>/`) or, for an external config, next to
+its gitconfig in `.moltnet/<agent>/`. Three paths create it:
+
+- The Console's Local Runtime page creates a managed agent through the Agent
+  Server: keypair and agent key generated on this machine, stored under the
+  store's `secrets/` directory, no CLI involved.
+- [`moltnet register`](../../docs/start/install-and-initialize.md#register-an-agent)
+  creates an OAuth2 identity from the CLI; add a stored agent key with
+  `moltnet agents keys create --store` before running the daemon.
+- [`moltnet agents init`](../../docs/start/install-and-initialize.md#coding-agents-initialize-an-identity)
+  does the same for coding agents that need git and GitHub.
 
 **The daemon runs on an agent key only.** OAuth2 client_credentials is not
 accepted: it hands the daemon the full 17-scope agent grant against a six-scope
@@ -178,26 +196,13 @@ Codex subscription OAuth with `moltnet-agent providers`. The canonical command
 guide and local/Ollama Cloud examples are in
 [Running Agents: Provider Management](../../docs/operate/running-agents.md#provider-management).
 
-The daemon resolves Pi config from the repository-local `.pi` directory by
-default for direct runs. On startup, if `PI_CODING_AGENT_DIR` is not already set, the daemon
-sets it to `<repo-root>/.pi` before creating Pi sessions. This keeps daemon
-runs deterministic and avoids inheriting user-level `~/.pi/agent` state.
-
-Repo-local `.pi/settings.json` and `.pi/models.json` are intended to be
-committed. `models.json` should reference provider keys by environment-variable
-name, for example `"apiKey": "OLLAMA_API_KEY"`, not contain secret values.
-Repo-local `.pi/auth.json` may exist for local subscription auth, but is
-gitignored. Without `.pi/auth.json`, Pi falls back to environment-variable
-provider keys:
-
-```bash
-export ANTHROPIC_API_KEY=sk-ant-...
-# or any other provider listed in
-# https://github.com/badlogic/pi-mono/blob/main/packages/ai/src/env-api-keys.ts
-```
+Direct runs use that provider store when it has a provider or a login, layered
+over the repository-local `.pi`; `PI_CODING_AGENT_DIR` overrides both. See
+[Running Agents: Repository Pi Config](../../docs/operate/running-agents.md#repository-pi-config).
 
-To force a non-repo Pi directory, set
-`PI_CODING_AGENT_DIR=/abs/path/to/.pi-or-agent-dir` before starting the daemon.
+Committed `.pi/models.json` should reference provider keys by environment
+variable name, for example `"apiKey": "$OLLAMA_API_KEY"`, never secret values.
+`.pi/auth.json` is gitignored.
 
 ### Observability
 
@@ -264,12 +269,10 @@ registered task type; unknown task-type names remain invalid.
 ### Prerequisites
 
 - Docker running.
-- Pi config for the model provider you'll drive the daemon with. Local daemon
-  runs default `PI_CODING_AGENT_DIR` to repo-local `.pi`, so committed
-  `.pi/settings.json` and `.pi/models.json` must list the provider/model. For
-  subscription auth, put your local token blob in `.pi/auth.json`; it is
-  gitignored. For API-key auth, keep `.pi/auth.json` absent and export the
-  provider key referenced by `.pi/models.json`, for example `OLLAMA_API_KEY`.
+- A Pi provider for the profile's provider/model: configure it with
+  `moltnet-agent providers set` or `providers login`, or list it in
+  `.pi/models.json` and export the key it references, for example
+  `OLLAMA_API_KEY`.
 - `ssh-keygen` on `PATH`.
 - A runtime profile in the target team. The profile supplies provider, model,
   sandbox policy, and runtime defaults. The daemon resolves the configured