@mutagent/cli 0.2.119 → 0.2.120

package/dist/bin/cli.js

@@ -22089,7 +22089,7 @@ When a sandbox session ends, the platform checks its work: specs in sync, stage
 runs finished, reports pushed. If something is missing, the session is woken with
 the list and continues. Finish your runs and push your reports before you stop.
 `,
-  "workflows/agent-deployment.md": "# Managed agents: check, deploy and run an agent.md folder\n\nUse this journey when the user has an agent folder whose entry file is a\nlowercase `agent.md` (YAML frontmatter, then the standing prompt), optionally\nwith TypeScript tools, skill folders and files. Read `mutagent agent --help` and\nthe leaf's help before the first use; help owns the flags and the JSON shapes.\nThe CLI compiles the tools and packages the folder. Do not write registration\nglue or forward a path on this machine to the server.\n\nThe format, in one paragraph: `name` (the slug), `description`, `model`\n(`provider/model`, as `mutagent helix models` lists it), `thinking`, `tools`,\n`disallowed_tools` and `skills` are the local brief. Deployment settings sit in\none optional `harness:` block: `tools.builtin`, `tools.modules`, `skills`,\n`files`, `bindings.secrets`, `runtime.mode` (`interactive` or `headless`) and\n`runtime.scaffold` (`standard`). A deployed agent gets exactly the tools and\nskills `harness:` declares. `apiVersion`, `kind` and `metadata` are refused.\n\n1. **Check.** `mutagent agent check <agent.md> --json`. No network, no model call,\n   no tool code runs. Fix every diagnostic before going further.\n2. **Run locally, when the user wants to try it.**\n   `mutagent agent run <agent.md> \"<task>\" --json` runs the task with the local\n   Helix binary and this machine's LLM provider key. It is not isolated and\n   creates nothing in the workspace. It takes a file; a slug is refused.\n3. **Deploy.** `mutagent agent deploy <agent.md> [--env <name>] --json`. `--env`\n   names the slot (the agent in that Environment); without it the default slot\n   is used. One server-side operation validates and stores the package as the\n   next revision and activates it. The server refuses, before writing anything:\n   a model outside the workspace model list, an Environment the workspace lacks,\n   a required secret binding, an inline agent that already has the slug, and a\n   server with no sandbox provider that can stage a package. Report the message\n   as the server words it. Show `_directive.renderedCard` verbatim.\n   `--no-activate` stores the revision and leaves the slot on its active one.\n4. **Run the managed agent.**\n   `mutagent helix agent @<slug> [--env <name>] -p \"<task>\"` runs headless;\n   `--rpc` runs interactive. `@<slug>:vN` pins a revision; `@<slug>:latest` runs\n   the newest validated one. The receipt (reference, sessionId: the hs1_ session\n   id, agent, mode) is one JSON line on stderr: keep the reference. `mutagent helix session attach`,\n   `send` (interactive only), `signal`, `checkpoint`, `checkpoints` and\n   `close-input` take it. Restore of a managed agent's session is refused today;\n   start a new run. A person starts a managed agent run (terminal, Desktop, web); from inside a\n   cloud sandbox the platform refuses the launch (`SANDBOX_CANNOT_LAUNCH`): show the refusal as-is.\n5. **Inspect.** `mutagent agent inspect <slug> [--env <name>] --json` shows the\n   revisions, each slot's active revision and the sessions launched from it.\n   `mutagent agent list --json` lists the workspace's managed agents.\n6. **Roll back or retire.** `mutagent agent activate <slug> --revision vN\n   [--env <name>] --json` makes an older revision active for new runs; running\n   sessions keep theirs. `mutagent agent retire <slug> [--env <name>] --force`\n   disables the slot; `activate` re-enables it. Retire refuses without `--force`\n   in every mode: confirm with the user first.\n\nOn an uncertain deploy or activate (a network error, a 5xx), retry the same\ncommand with the same `--idempotency-key` the error's recovery names; a new key\nis a new request. `mutagent agent inspect --operation <id>` shows the recorded\noutcome of one operation. `pack --output <archive>` writes the archive for\ninspection; the path must be outside the agent folder and replacing a file\nneeds `--force`.\n",
+  "workflows/agent-deployment.md": "# Managed agents: check, deploy and run an agent.md folder\n\nUse this journey when the user has an agent folder whose entry file is a\nlowercase `agent.md` (YAML frontmatter, then the standing prompt), optionally\nwith TypeScript tools, skill folders and files. Read `mutagent agent --help` and\nthe leaf's help before the first use; help owns the flags and the JSON shapes.\nThe CLI compiles the tools and packages the folder. Do not write registration\nglue or forward a path on this machine to the server.\n\nThe format, in one paragraph: `name` (the slug), `description`, `model`\n(`provider/model`, as `mutagent helix models` lists it), `thinking`, `tools`,\n`disallowed_tools` and `skills` are the local brief. Deployment settings sit in\none optional `harness:` block: `tools.builtin`, `tools.modules`, `skills`,\n`files`, `bindings.secrets`, `runtime.mode` (`interactive` or `headless`) and\n`runtime.scaffold` (`standard`). A deployed agent gets exactly the tools and\nskills `harness:` declares. `apiVersion`, `kind` and `metadata` are refused.\n\n1. **Check.** `mutagent agent check <agent.md> --json`. No network, no model call,\n   no tool code runs. Fix every diagnostic before going further.\n2. **Run locally, when the user wants to try it.**\n   `mutagent agent run <agent.md> \"<task>\" --json` runs the task with the local\n   Helix binary and this machine's LLM provider key. It is not isolated and\n   creates nothing in the workspace. It takes a file; a slug is refused.\n3. **Deploy.** `mutagent agent deploy <agent.md> [--env <name>] --json`. `--env`\n   names the slot (the agent in that Environment); without it the default slot\n   is used. One server-side operation validates and stores the package as the\n   next revision and activates it. The server refuses, before writing anything:\n   a model outside the workspace model list, an Environment the workspace lacks,\n   a required secret binding, an inline agent that already has the slug, and a\n   server with no sandbox provider that can stage a package. Report the message\n   as the server words it. Show `_directive.renderedCard` verbatim.\n   `--no-activate` stores the revision and leaves the slot on its active one.\n4. **Run the managed agent.**\n   `mutagent helix agent @<slug> [--env <name>] -p \"<task>\"` runs headless;\n   `--rpc` runs interactive. `@<slug>:vN` pins a revision; `@<slug>:latest` runs\n   the newest validated one. The receipt (reference, sessionId: the hs1_ session\n   id, agent, mode) is one JSON line on stderr: keep the reference. `mutagent helix session attach`,\n   `send` (interactive only), `signal`, `checkpoint`, `checkpoints` and\n   `close-input` take it. Restore of a managed agent's session is refused today;\n   start a new run. A person starts a managed agent run (terminal, Desktop, web); from inside a\n   cloud sandbox the platform refuses the launch (`SANDBOX_CANNOT_LAUNCH`): show the refusal as-is.\n5. **Inspect.** `mutagent agent inspect <slug> [--env <name>] --json` shows the\n   revisions, each slot's active revision and the sessions launched from it.\n   `mutagent agent list --json` lists the workspace's managed agents. Both run on\n   a laptop only: inside a cloud sandbox they fail with `SANDBOX_SCOPE`, and the\n   deployment check is `mutagent factory show <entry> --json` instead.\n6. **Roll back or retire.** `mutagent agent activate <slug> --revision vN\n   [--env <name>] --json` makes an older revision active for new runs; running\n   sessions keep theirs. `mutagent agent retire <slug> [--env <name>] --force`\n   disables the slot; `activate` re-enables it. Retire refuses without `--force`\n   in every mode: confirm with the user first.\n\nOn an uncertain deploy or activate (a network error, a 5xx), retry the same\ncommand with the same `--idempotency-key` the error's recovery names; a new key\nis a new request. `mutagent agent inspect --operation <id>` shows the recorded\noutcome of one operation. `pack --output <archive>` writes the archive for\ninspection; the path must be outside the agent folder and replacing a file\nneeds `--force`.\n",
   "workflows/factory-register.md": `---
 name: mutagent-cli-workflows-factory-register
 description: |
@@ -22119,7 +22119,9 @@ before the first use.
 2. **Validate without writing.** \`mutagent factory add <agentspec-file> --dry-run --json\`.
    The spec is checked in the CLI before anything is sent. Fix each field in
    \`errors[]\` on \`SPEC_INVALID\`.
-3. **Confirm with the user**, then register:
+3. **Confirm with the user (required).** Show the drafted spec's summary (id, kind,
+   name, targets, components) and wait for the user's yes. Never run \`factory add\`
+   without it. Then register:
    \`mutagent factory add <agentspec-file> --json\`. The file's git remote, path and
    HEAD commit are read from its checkout and recorded as v1.
 4. **Show the result.** Render \`_directive.renderedCard\` verbatim, then
@@ -22144,7 +22146,8 @@ A system's spec lists its members under \`spec.multiAgent.members[]\`, each with
 2. \`mutagent factory add <system-agentspec> --dry-run --json\`. The member files
    are read from the system spec's folder for their ids, and each becomes a
    component pinned to its current spec version.
-3. Confirm, then \`mutagent factory add <system-agentspec> --json\`.
+3. Show the system spec's summary and its members, wait for the user's yes, then
+   \`mutagent factory add <system-agentspec> --json\`.
 4. \`mutagent factory show <system-id> --json\` lists the components and their pins.
 
 Changing a member later: push the member's spec, then push the system's spec so
@@ -28771,7 +28774,11 @@ function alreadyGone(error) {
 function notEnded(reference, error) {
   if (!(error instanceof MutagentError) || NOT_ENDED_CODES.has(error.code))
     return error;
-  return new MutagentError("SESSION_END_FAILED", `${reference} was not ended: ${error.message}`, `Run: mutagent helix session end ${reference} --force`);
+  const label = sessionLabel(reference);
+  if (label === reference) {
+    return new MutagentError("SESSION_END_FAILED", `${reference} was not ended: ${error.message}`, `Run: mutagent helix session end ${reference} --force`);
+  }
+  return new MutagentError("SESSION_END_FAILED", `${label} was not ended: ${error.message}. A session is ended by its hs1_ session id: find it in session list, then run mutagent helix session end <hs1_ref> --force.`, "Run: mutagent helix session list --json");
 }
 async function end(reference) {
   if (resolveCredential().kind !== "sandbox-token")
@@ -28791,6 +28798,7 @@ defaults to its own session (MUTAGENT_SESSION_ID).
 Errors (code: recovery):
   CONFIRMATION_REQUIRED  Confirm with the user, then: mutagent helix session end <hs1_ref> --force  (nothing was sent)
   SESSION_END_FAILED     hs1_… was not ended: <reason>. Retry: mutagent helix session end hs1_… --force
+                         (not an hs1_ id: find the hs1_ id with mutagent helix session list)
   MISSING_ARGUMENTS      Pass the hs1_ session id (locally it has no default)
 
 AI Agent Directive:
@@ -40483,4 +40491,4 @@ if (process.env.CLI_VERSION) {
 }
 runCli(process.argv.slice(2), cliVersion);
 
-//# debugId=7B351CAFF933F24B64756E2164756E21
+//# debugId=E30DBAF2E9D42B6F64756E2164756E21

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mutagent/cli",
-  "version": "0.2.119",
+  "version": "0.2.120",
   "description": "Bun-native CLI for the MutagenT AI platform - auth, provider config, and lifecycle-tool installer for AI-native workflows",
   "type": "module",
   "bin": {