@haven_ai/connect 0.10.0-alpha.0 → 0.12.0-alpha.0

package/README.md

@@ -3,9 +3,16 @@
 Connect Agent 2 local connector.
 
 This command runs in the user's agent environment. It generates the agent
-signing key and API key locally, stores them locally, and sends Haven only the
-public signing address, proof signature, and API-key hash. Haven never receives
-the private key or plaintext API key.
+signing key and API key locally, stores them locally, and sends Haven the
+public signing address, a proof signature, and the API key's hash and display
+prefix. The same registration request also carries the one-time setup token
+and its challenge id, non-secret labels (runtime, connector version, MCP server
+name, run mode, connector context) and the install capabilities (whether the
+connector can write the runtime config, and whether a restart is required).
+Every request through its API client (setup resolve and register, status
+reports, the agent identity read) names the connector and its version in an
+`X-Haven-Client` header (#3303); the read-only hosted probes behind `--doctor`,
+`--unwire` and the post-install check send none. Haven never receives the private key or plaintext API key.
 
 ## Are you an AI agent whose user has no Haven account yet?
 
@@ -36,8 +43,13 @@ installs a signer that skews against it — the signer refuses to sign an
 
 The connector writes owner-only credential files outside the project by default:
 
-- `~/.haven/agents/<agent-id>/identity.json` contains the Haven API key.
-- `~/.haven/agents/<agent-id>/signer.json` contains the local signer key.
+- `~/.haven/agents/<slug>/identity.json` contains the Haven API key.
+- `~/.haven/agents/<slug>/signer.json` contains the local signer key.
+
+`<slug>` is the agent's MCP pair name: derived from its display name by
+default (#3737), or what you pass as `--name`. A `--bare` or `--replace` setup
+without `--name` uses `~/.haven/agents/<agent-id>/` instead (see
+[Running several agents in one runtime](#running-several-agents-in-one-runtime)).
 
 The API key identifies the agent. It cannot spend by itself. Payments still need
 the locally held signer key and the user-approved on-chain Haven wallet rules.
@@ -121,6 +133,7 @@ also select its OWN directory with `--doctor --name <slug>` or
 | `superseded` | It holds credentials, but no config entry points at it. Reported, never silently skipped — its API key may still spend. |
 | `retired` | Tombstoned (see below); key material removed. |
 | `orphaned` | No usable identity and no tombstone. |
+| `parked` | Holds only the `rekey-pending.json` of an unfinished `--rekey` (#1915): loose key material, no agent. |
 
 The exit code is non-zero if **any** wired agent fails **any** check
 (`level: failed` — see the next section; an advisory does not count) — not
@@ -503,7 +516,9 @@ need its full public identifier can inspect the owner-only, non-secret
 `identity.json` or `signer.json` for diagnostics because they contain secrets.
 
 For Hermes, Connect stores the hosted-MCP API key in the matching owner-only
-`.env` file and keeps only `Bearer ${MCP_HAVEN_API_KEY}` in `config.yaml`.
+`.env` file and keeps only `Bearer ${<the pair's env key>}` in `config.yaml`:
+`MCP_HAVEN_<SLUG>_API_KEY` for a named pair (the default since #3737), or
+`MCP_HAVEN_API_KEY` for the bare pair (`--bare` or `--replace` without `--name`).
 Hermes requires its Python MCP SDK support to be installed. If Haven tools do
 not appear after restart, run `pip install mcp` in the Hermes environment, then
 restart Hermes and check `hermes mcp list`.
@@ -554,8 +569,8 @@ already-configured machine behaves as follows (characterized in
 - **A default setup names its pair from the agent's display name
   ([#3737](https://github.com/d-hinders/Haven-AI/issues/3737)) and never
   collides.** Without `--name`, `--bare` or `--replace`, the connector derives
-  the slug itself (`proposeServerSlug`: slugified display name, `agent`
-  fallback, numeric suffix when taken) and wires `haven-<slug>` /
+  the slug itself (`deriveServerSlug`, over `proposeServerSlug`: slugified
+  display name, `agent` fallback, numeric suffix when taken) and wires `haven-<slug>` /
   `haven-signer-<slug>` — de-collided against **every** directory under the
   credential root (retired and key-removed ones included, so a slug freed by
   `--unwire` is never reused), and marked `-dev` on a non-production backend
@@ -602,8 +617,8 @@ already-configured machine behaves as follows (characterized in
 - **The previous agent is not revoked by a re-run — with or without
   `--replace`.** Local retirement is local: its authority remains whatever
   its on-chain rules and the Haven agent page say. Use **Remove agent…** on
-  the Haven agent page for agents you no longer use (or the superseded-agents
-  revoke on the setup screen). Connect never calls revoke — that
+  the Haven agent page for agents you no longer use; the setup screen lists
+  the other agents but offers no revoke (#3830). Connect never calls revoke — that
   route is owner-authenticated, and an agent credential revoking a sibling
   agent would be an agent editing its own authority.
 - **A re-run never overwrites an existing credential file.** A write that would
@@ -645,7 +660,8 @@ nothing already wired needs changing — it is the one flag (besides
 The slug is **1–32 lowercase letters, digits and single hyphens**, validated
 before anything is written, and **immutable once wired** — it is the server name
 and tool prefix every host depends on. `haven`, `signer` and `signer-*` are
-refused, because their derived names would collide with another pair's.
+refused, because their derived names would collide with another pair's;
+`haven-signer` is refused too.
 
 > A current connector reports the resolved server name (`haven`, or
 > `haven-<slug>`) to Haven at registration, and the dashboard shows it on each
@@ -653,7 +669,8 @@ refused, because their derived names would collide with another pair's.
 > browser ([#1878](https://github.com/d-hinders/Haven-AI/issues/1878)). It is a
 > label, not authority — nothing keys off it.
 >
-> Agents connected before that shipped read **"MCP name not recorded"**: Haven
+> Agents connected before that shipped show **not recorded** in the *MCP server
+> name* row of their Settings tab: Haven
 > genuinely does not know, and guessing would name the wrong pair for anyone who
 > used `--name`. They keep working exactly as they are; `--doctor` on the machine
 > still maps them, and reconnecting records the name.
@@ -736,9 +753,9 @@ a skew that is not there. Use the channel your dashboard hands out.
 Without the flag the doctor checks the runtime the setup recorded in the
 agent directory's `last-connect-outcome.json` (#3120), and the `runtime_config`
 verdict says which runtime it resolved and from which file; when no
-record names one, the `runtime_config` check FAILS with "Runtime is unknown —
-the runtime config was NOT checked" and the exit code is 1 — never a pass on a
-config it did not open. `--repair` rewrites that config, so the runtime it
+record names one, the `runtime_config` check FAILS ("Runtime is unknown — no
+runtime flag was given …", then "The runtime config was NOT checked.") and the
+exit code is 1 — never a pass on a config it did not open. `--repair` rewrites that config, so the runtime it
 rewrites is named on the command line rather than inherited from a record on
 disk: a flagless `--repair` is refused before anything runs.
 
@@ -768,7 +785,9 @@ probe is a note, never a verdict. Connect never revokes or deletes
 credentials itself — it reports, you decide. The setup completion output
 names the other agent directories the moment the new agent is created, for
 the same reason.
-One honest limit: "newest" is decided by file mtime, so a restored backup or
+One honest limit: when neither `--name` nor `--credentials-dir` picks the
+agent, the doctor describes the newest wired directory by file mtime, so a
+restored backup or
 a sync tool that rewrites timestamps can make doctor examine the wrong
 directory as current — before revoking anything, confirm the agent id
 against the Haven agent page, which is the authority on which agent is
@@ -782,9 +801,10 @@ the STORED credentials. It never touches keys and never needs a new token.
 from ONE agent's stored credentials. With more than one agent credential
 directory under `~/.haven/agents` — or when `--doctor` was itself given
 `--credentials-dir` — every repair line the doctor prints names the agent it is
-about with `--credentials-dir <dir>`, and a `--repair` without
+about with `--credentials-dir <dir>`, and a `--repair` without `--name` or
 `--credentials-dir` is refused — nothing is changed — with one exact command
-per live agent (its agent id beside it); a retired directory is listed as
+per live agent (its agent id and the pair it owns beside it: `--name <slug>`
+for a named pair, `--credentials-dir <dir>` for the bare one, #3799); a retired directory is listed as
 "retired — not a repair target" and never offered. Without that, "the newest directory" was a
 guess, and it re-wired a different agent than the one the doctor described.
 Every "update your signer" hint Haven emits names the flagless

package/dist/cli.cjs

@@ -276,9 +276,9 @@ var init_runtime_manifest = __esm({
       mcpPackage: "@haven_ai/mcp",
       mcpVersion: mcp.MCP_VERSION,
       sdkPackage: "@haven_ai/sdk",
-      sdkVersion: "0.10.0-alpha.0",
+      sdkVersion: "0.12.0-alpha.0",
       signerPackage: "@haven_ai/signer",
-      signerVersion: "0.10.0-alpha.0",
+      signerVersion: "0.12.0-alpha.0",
       // Sourced from the SDK, never a literal (#1161). This field read '20.0.0'
       // while every package's `engines` said `>=24` and the docs said `>=24.0.0`,
       // so the guard that was supposed to enforce the floor waved Node v23 through
@@ -4703,7 +4703,7 @@ var init_runtime = __esm({
     init_tombstone();
     init_local_mcp_runtime();
     init_runtime_manifest();
-    CONNECTOR_VERSION = "0.10.0-alpha.0";
+    CONNECTOR_VERSION = "0.12.0-alpha.0";
     PRODUCTION_CHAIN_ID = 8453;
     UUID_SHAPE = /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i;
     CONNECTOR_CLIENT_IDENTITY = `@haven_ai/connect/${CONNECTOR_VERSION}`;