@haven_ai/sdk 0.1.35-alpha.0 → 0.1.37-alpha.0

package/dist/index.cjs

@@ -3184,7 +3184,8 @@ var HavenClient = class {
    * Sign a payment's `sign_data` with the correct scheme for its rail.
    *
    * Dispatching on the server-provided scheme means a caller never has to
-   * know which rail an account is on; an unknown scheme is a hard error,
+   * know which rail an account is on; an unknown scheme — or an absent one,
+   * since the legacy AllowanceModule rail retired (#2850) — is a hard error,
    * never a guessed signature. The session rail's 'eip191_userop' is retired
    * (#834) — the backend refuses those intents with HTTP 410 before any
    * sign_data reaches a client, so encountering it here is a hard error too.
@@ -3218,7 +3219,9 @@ var HavenClient = class {
       return signSettlementDelegationTypedData(this.delegateKey, signData.typed_data);
     }
     if (scheme === void 0) {
-      return signHash(this.delegateKey, signData.hash);
+      throw new HavenSigningError(
+        "sign_data.signature_scheme is required \u2014 the legacy AllowanceModule rail that signed the bare hash is retired (#2850). Refusing to guess a signing scheme."
+      );
     }
     throw new HavenSigningError(
       `Unknown sign_data.signature_scheme '${scheme}' \u2014 refusing to guess a signing scheme. Update @haven_ai/sdk.`
@@ -3348,8 +3351,10 @@ var HavenClient = class {
    * allowance/budget summary a settle response carries.
    *
    * #1310/#1311 parity: this is the ONE home for logic that was duplicated
-   * verbatim in `packages/mcp-server/src/tools.ts` and `packages/mcp/src/tools.ts`
-   * (both hosted and local `haven_get_payment_status` handlers) — extracted
+   * verbatim in the hosted and local `haven_get_payment_status` handlers —
+   * `packages/mcp-server/src/tools/state-direct-recovery.ts` since #2809 (it
+   * was `packages/mcp-server/src/tools.ts` when this was written) and
+   * `packages/mcp/src/tools.ts` — extracted
    * here because both packages already depend on `@haven_ai/sdk` and call
    * methods on a `HavenClient` instance, so this needed no new dependency
    * edge. `funded_but_unsettled` is deliberately excluded: that phase means
@@ -4347,8 +4352,8 @@ Your user gives you a **budget on their own account** \u2014 not their wallet, a
 
 Four of the six steps are your user's \u2014 each needs a human signature or a human decision. The rest is yours. If they already have a funded account, start at step 3.
 
-1. **HUMAN \u2014 create the account.** Name, email, password, then a passkey (Face ID / Touch ID) or a wallet. Never offer to enter any of it: you must not have their password, and the passkey is bound to their device. With a terminal, \`npx @haven_ai/cli login --api <api-url>\` afterwards gets you a scoped session for steps 3-4 (that flag or \`HAVEN_API_URL\`, on the first command \u2014 the session then remembers the backend; **the CLI's built-in default is Haven's hosted production backend**, so on any other deployment an omitted flag connects you somewhere real and wrong rather than failing) \u2014 they approve a code in the browser, you never hold their password. It can set up agents and read the account; it cannot sign, approve a budget, move funds, or rotate any agent's keys.
-2. **HUMAN \u2014 fund it.** USDC only, no ETH: Haven sponsors the gas. \`haven wallets funding\` prints the address, the amount **and which chain** in one place; without a CLI session, the dashboard's funding card shows the address and amount and its Receive-funds screen names the chain. Read the chain off whichever you used and put it in your message \u2014 never assume one: a testnet deployment and production both call themselves Haven.
+1. **HUMAN \u2014 create the account.** Name, email, password, then a passkey (Face ID / Touch ID) or a wallet. Never offer to enter any of it: you must not have their password, and the passkey is bound to their device. With a terminal, \`npx @haven_ai/cli@<channel> login --api <api-url>\` afterwards gets you a scoped session for steps 3-4 (that flag or \`HAVEN_API_URL\`, on the first command \u2014 the session then remembers the backend; **the CLI's built-in default is Haven's hosted production backend**, so on any other deployment an omitted flag connects you somewhere real and wrong rather than failing) \u2014 they approve a code in the browser, you never hold their password. The \`<channel>\` in that command is the tag your deployment names \u2014 read it from \`/.well-known/haven.json\` (\`packages.cli.channel\`), never a tag you pick. Do not hold the process open while you wait: under \`--json\`, pass \`--no-wait\` to get the link object back at once, then poll it with \`haven login --poll <device_code>\` \u2014 one round per invocation, exit 3 while it is still pending, 0 once approved. It can set up agents and read the account; it cannot sign, approve a budget, move funds, or rotate any agent's keys.
+2. **HUMAN \u2014 fund it.** USDC only, no ETH: Haven sponsors the gas. \`/.well-known/haven.json\` names \`chains.default\` as the deployment's expected chain, but after login \`haven wallets funding\` prints the address, the amount and which chain in one place; confirm that chain before you message your user. Without a CLI session, the dashboard's funding card shows the address and amount and its Receive-funds screen names the chain; never assume one: a testnet deployment and production both call themselves Haven. Before you write that message, read the manifest: \`environment\` says whether this deployment is \`production\`, and each \`chains.supported\` entry says whether that chain is a \`testnet\`. Real money is at stake only on a non-testnet chain of a \`production\` deployment \u2014 tell your user which case theirs is.
 3. **HUMAN \u2014 create the agent, set its budget**, and paste you the **setup prompt** it hands back. With a CLI session (step 1) you can do this step yourself: \`haven agents connect --name <n> --budget <amount> --token USDC --period <minutes>\` prints the same connector command and approval link; add \`--run\` to do step 4 too.
 4. **YOU \u2014 run the connector command** in that prompt (below). It makes your signing key locally, registering only the public address.
 5. **HUMAN \u2014 approve the budget** with their passkey, in the Haven tab they created the agent in: it advances to the approval step by itself once your run registers.
@@ -4441,7 +4446,7 @@ Start by reading {{HAVEN_ORIGIN}}/for-agents.md \u2014 it is written for you and
 
 Then:
 
-1. Run \`npx @haven_ai/cli login\`. It prints a link and a code and does not need my password \u2014 it must never ask for it. Give me the link straight away and wait for me to approve it in my browser.
+1. Run \`npx @haven_ai/cli@<channel> login\`. The \`<channel>\` in that command is the tag your deployment names \u2014 read it from \`/.well-known/haven.json\` (\`packages.cli.channel\`), never a tag you pick. It prints a link and a code and does not need my password \u2014 it must never ask for it. Give me the link straight away and wait for me to approve it in my browser.
 2. Once I have approved, run \`haven agents connect --name <a name you choose> --budget <amount> --token USDC --period <minutes>\` with the budget I tell you. If I have not given you one, ask me before running it. Add \`--run\` to complete the connection in the same step.
 3. ${AGENT_APPROVAL_RELAY_JSON_SENTENCE}
 4. Once I have approved the budget, verify with the \`haven_get_agent\` tool: \`ready\` means you can pay, \`needs_approval\` means my approval has not landed yet.