@themoltnet/agent-daemon 0.32.2 → 0.34.0

package/README.md

@@ -1,10 +1,10 @@
 # `@themoltnet/agent-daemon`
 
 The MoltNet agent daemon claims and executes tasks from the MoltNet
-task-service. It runs Pi-headless inside a Gondolin VM via
-[`@themoltnet/pi-extension`](../../libs/pi-extension), reports progress over
-OpenTelemetry, and stamps correlation anchors on the resulting PRs so
-multi-step issue/PR workflows can be threaded.
+task-service. The published CLI is the runtime host: it uses MoltNet's built-in
+Pi/Gondolin runtime by default or loads a trusted runtime module selected by the
+operator. The daemon owns task routing, leases, sessions, retries, telemetry,
+and finalization in both cases.
 
 ## Install
 
@@ -17,6 +17,40 @@ 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 \
+  --agent <agent-name> \
+  --team <team-id> \
+  --profile <profile-id>
+```
+
+To add Pi tools, extensions, or a custom Gondolin template, build a runtime
+module that default-exports a `DaemonRuntimeAdapter`, then load it with the same
+CLI:
+
+```bash
+npx @themoltnet/agent-daemon \
+  --runtime ./dist/runtime.js \
+  poll \
+  --agent <agent-name> \
+  --team <team-id> \
+  --profile <profile-id>
+```
+
+`--runtime` accepts a file path relative to the current directory, an absolute
+file path, a `file:` URL, or an installed package name. Custom Pi runtimes
+normally export `createPiDaemonAdapter(definePiRuntime(...))`; other executors
+can implement `DaemonRuntimeAdapter` directly.
+
+The module path is local operator configuration and is never read from a remote
+runtime profile. Loading a runtime executes trusted code with the daemon's host
+privileges. See [Build a custom Pi runtime](../../docs/contribute/custom-pi-runtimes.md)
+and the [standalone example](../../examples/custom-pi-runtime).
+
 ## Modes
 
 | Mode            | Purpose                                                                       |
@@ -185,8 +219,8 @@ flows that need fast first installs, prewarm the store explicitly with
 `pnpm fetch` after the sandbox is available instead of putting that network
 operation in every resume.
 
-If a resume step assumes `/workspace` is a repo checkout, gate it on
-`resumeCommands[].when.workspaceMode` rather than on task type. Use:
+If a local runtime template resume step assumes `/workspace` is a repo
+checkout, gate it on `when.workspaceMode` rather than on task type. Use:
 
 - `shared_mount` / `dedicated_worktree` for repo-aware bootstrap
 - `scratch_mount` to skip repo-specific steps when the task runs in an empty
@@ -201,8 +235,8 @@ runtime-session storage when producer slot/workspace metadata is available but
 the local session file is unavailable. Workspace copying still depends on
 producer slot/workspace metadata; if the daemon cannot resolve the required
 producer context, the judge fails with `producer_context_missing`.
-Repo-specific `resumeCommands` that should not run in scratch mode must still
-be guarded with `when.workspaceMode`.
+Repo-specific template resume commands that should not run in scratch mode must
+still be guarded with `when.workspaceMode`.
 
 ### Runtime resource lifecycle
 

package/dist/cli.d.ts

@@ -0,0 +1,6 @@
+import { DaemonRuntimeAdapter } from './runtime.js';
+export declare function runAgentDaemonCli(options: {
+    runtime: DaemonRuntimeAdapter;
+    argv?: string[];
+}): Promise<number>;
+//# sourceMappingURL=cli.d.ts.map

package/dist/cli.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"cli.d.ts","sourceRoot":"","sources":["../src/cli.ts"],"names":[],"mappings":"AAKA,OAAO,KAAK,EAAE,oBAAoB,EAAE,MAAM,cAAc,CAAC;AAEzD,wBAAsB,iBAAiB,CAAC,OAAO,EAAE;IAC/C,OAAO,EAAE,oBAAoB,CAAC;IAC9B,IAAI,CAAC,EAAE,MAAM,EAAE,CAAC;CACjB,GAAG,OAAO,CAAC,MAAM,CAAC,CAsBlB"}