@visa/cli 4.1.0-rc.308 → 4.1.0-rc.309

package/dist/skills/pair-visa-agent/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: pair-visa-agent
-description: Set up a Visa CLI v4 agent through the single protected enrollment implementation, using the entrance this build advertises, and report its live capabilities honestly. The owner always approves in their browser. Use when the user says "pair my agent", "connect Visa", "enroll my Visa CLI", "set up my agent", or "let this agent pay".
+description: Set up a Visa CLI v4 agent through the single protected enrollment implementation (MCP `agent_enroll` or `visa agent enroll`), and report its live capabilities honestly. The owner always approves in their browser. Use when the user says "pair my agent", "connect Visa", "enroll my Visa CLI", "set up my agent", or "let this agent pay".
 compatibility: Needs the `visa` CLI (`npm i -g @visa/cli@rc`) — run `node scripts/setup.mjs` to install it if missing — plus network access to the Visa authorization service. Works in OpenClaw, Hermes, Claude Code, Codex, or any Agent Skills runtime.
 allowed-tools: Bash(visa:*) Bash(visa-cli:*) Bash(node:*) Bash(npm:*) Bash(npx:*)
 metadata:
@@ -29,19 +29,22 @@ metadata:
 
 # Set up a Visa agent
 
-One command carries everything: this runtime's identity, the binding to **this
-device**, and the spending limits — behind a **single** owner approval in their browser.
+One protected enrollment carries everything: this runtime's identity, the binding to
+**this device**, and the spending limits — behind a **single** owner approval in their
+browser.
 
-**Today, the command is run by the OWNER in their terminal.** On one-door builds that
-advertise it, an agent may instead call `agent_enroll` and hand the owner its returned
-link, or the owner runs `visa agent enroll`. These are two entrances to the exact same
-protected enrollment implementation: the same native signer, Authority routes, owner
-browser approval, and limits. Never invent or mix in a second ceremony.
+It has two entrances to the exact same protected enrollment implementation: the same
+native signer, Authority routes, owner browser approval, and limits. Never invent or mix
+in a second ceremony.
+
+- **You have the Visa MCP server mounted:** call `agent_enroll` and hand the owner the one
+  link and short code it returns. Call it again with `wait: true` once they have the page
+  open; it finishes activation only after they approve.
+- **The owner is at a terminal:** they run the command below.
 
 ```
 # the human runs this:
-visa agent enroll-protected \
-  --authority-url <origin> --auth-url <origin> --url <origin> --wait
+visa agent enroll --wait
 
    → it prints a URL and a short code
    → the human opens the URL and enters the code at /agent/enroll/protected-agent
@@ -49,8 +52,8 @@ visa agent enroll-protected \
    → the command finishes; `get_status` now reports pairing.paired: true
 ```
 
-All three origins are required today; the operator supplies them. If the human does not
-know them, ask — do not guess an origin, and never construct a Visa URL yourself.
+The installed CLI selects its own service origins from its release channel. Never ask
+for, guess, or construct a Visa URL.
 
 Running the same command again resumes an interrupted enrolment; `--restart` replaces an
 unclaimed request with a fresh code. `--ceiling <usd>` and `--per-transaction <usd>`
@@ -61,12 +64,16 @@ propose limits the owner confirms on the approval page.
 `setup_start`, `setup_status`, `setup_resume`, `setup_cancel`, `setup_agent`,
 `enroll_agent`, `agent_connect`, `agent_connect_poll`, `agent_connect_cancel`,
 `agent_handoff_claim` and `agent_pairing_cancel` are gone, along with the `visa setup`
-group and `visa agent pair|create|verify|enroll|enroll-claim|claim|pairing-resume|connect|grant-card|grant-wallet|grant-activate|grant-claim|handoff-claim`.
+group and `visa agent pair|create|verify|enroll-claim|claim|pairing-resume|connect|grant-card|grant-wallet|grant-activate|grant-claim|handoff-claim`.
 
 Calling any of them returns one refusal:
 
 ```json
-{ "code": "legacy_door_removed", "kind": "caller", "fix": "visa agent enroll-protected" }
+{
+  "code": "legacy_door_removed",
+  "kind": "caller",
+  "fix": "visa agent enroll (shell) or agent_enroll (MCP)"
+}
 ```
 
 That code means the door no longer exists. **Relay the replacement and stop.** Do not
@@ -214,15 +221,14 @@ be signed in on the approval page. A different account there fails closed.
 
 ## Core flow
 
-- [ ] **Ask for the three origins** if you were not given them: `--authority-url`,
-      `--auth-url`, `--url`. They come from the operator. Never guess one.
+- [ ] **Do not ask for service origins.** The installed CLI selects its Auth and web
+      origins from the release channel; Authority is private behind Auth.
 - [ ] **Sign the owner in** (above), so the wallet leg has a session to bind to.
-- [ ] **Use the entrance this build advertises.** Today, give the owner the
-      `visa agent enroll-protected ... --wait` command in a code block they can copy.
-      On a one-door build, call `agent_enroll` and relay its returned link, or give the
-      owner `visa agent enroll`. Never fall back to a retired setup tool.
-- [ ] **Relay what the active entrance returns.** Show an MCP-returned URL as a bare,
-      tappable value. For the current terminal flow, the owner follows the URL and code
+- [ ] **Start the one enrollment.** Call `agent_enroll` and relay its returned link and
+      code, or give the owner `visa agent enroll --wait` in a code block they can copy.
+      Never fall back to a retired setup tool.
+- [ ] **Relay what the entrance returns.** Show an MCP-returned URL as a bare,
+      tappable value. For the terminal flow, the owner follows the URL and code
       printed in their own terminal. The code goes into the browser at
       `/agent/enroll/protected-agent`; it is not authority in chat.
 - [ ] **Tell them what they are approving**: this device, and the spending limits. One
@@ -352,12 +358,13 @@ BEFORE it is signed), then `wallet_pay`. The served wallet tools are `wallet_dis
 address + faucet), and `wallet_export` (export key material — dangerous). All spending is
 gated by the owner-approved local policy caps.
 
-Card: `start_card_mandate`, then `pay_merchant`. The first card purchase asks the owner
-for a spending mandate within the budget they already approved.
+Card: not available in this build. Visa CLI ships no browser checkout (#8940), so
+`start_card_mandate` returns `card_browser_checkout_removed` and creates no mandate, and
+every `pay_merchant` action refuses with the same code. Nothing is charged. Do not offer
+card checkout to the user, and do not relay a card approval URL; the wallet rail above is
+the payment path.
 
-The current card rail uses VIC browser checkout through `pay_merchant` after
-`start_card_mandate`; do not claim that browser checkout is unavailable before the card
-retirement change lands. On a hosted runtime, **every payment requires the owner's browser
+On a hosted runtime, **every payment requires the owner's browser
 approval** until the protected no-tap executor lands. Enrollment, a session, or a spending
 grant does not approve a later hosted payment. Relay the hosted approval URL and wait for
 the owner's decision before reporting success or retrying.
@@ -441,8 +448,8 @@ mailbox, key proof, recovery factor, or permission to spend.
 - Never fetch or submit the review URL on the human's behalf. They review and approve it
   in their own browser.
 - Never invent a secondary path when a call fails. Preserve the local state, surface the
-  error, and resume through the same protected entrance. On today's build, repeat the
-  same `visa agent enroll-protected ... --wait` command.
+  error, and resume through the same protected entrance: call `agent_enroll` again, or
+  repeat the same `visa agent enroll --wait` command.
 - Never call a retired door to "check whether it still works". `legacy_door_removed` is a
   final answer, not a transient failure.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@visa/cli",
-  "version": "4.1.0-rc.308",
+  "version": "4.1.0-rc.309",
   "description": "Visa CLI runtime for stable agent identity and separately authorized payment capabilities",
   "bin": {
     "visa-cli": "./bin/visa-cli.js",

package/server.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
   "name": "io.github.visa-crypto-labs/visa-cli",
-  "version": "4.1.0-rc.308",
+  "version": "4.1.0-rc.309",
   "title": "Visa CLI",
   "description": "Pair a human-approved agent identity, configure payment capabilities separately, and discover and pay x402 services from your AI coding assistant.",
   "websiteUrl": "https://github.com/Visa-Crypto-Labs/Visa-mono/tree/main/packages/cli#readme",
@@ -9,7 +9,7 @@
     {
       "registryType": "npm",
       "identifier": "@visa/cli",
-      "version": "4.1.0-rc.308",
+      "version": "4.1.0-rc.309",
       "transport": {
         "type": "stdio"
       },