@visa/cli 5.0.0-rc.335 → 5.0.0-rc.336

package/README.md

@@ -20,6 +20,12 @@ The protected product flow has three explicit parts:
 3. **Use** — `visa pay` and the `pay` tool enforce that authority's own policy
    and approval boundary on every call.
 
+Card payment is unavailable in this build: a `pay` target that answers no 402
+challenge refuses with `card_browser_checkout_removed`, even with a saved card,
+grant or tester flag. Another enrollment or card grant will not enable payment.
+UCP discovery and checkout preparation do not prove Visa payment support.
+Preserve the existing merchant checkout for the owner to continue with the merchant.
+
 ## Install
 
 macOS and Linux:
@@ -93,7 +99,7 @@ The server now exposes:
 - JSON Schema 2020-12 tool inputs and outputs, `structuredContent`, namespaced result metadata, cache hints, and receipt `resource_link` blocks.
 - Resources for agent status, capabilities, recent activity, and canonical `visa://receipt/{transactionId}` receipts.
 - Prompts for pairing/funding, spend inspection, safe purchasing, and receipt reconciliation, with completion support.
-- The `io.modelcontextprotocol/tasks` extension for durable, pollable `pay_merchant` approval work. Task lifecycle is owner-scoped in the auth service; an MCP-process restart fails an in-flight checkout closed instead of replaying it.
+- The `io.modelcontextprotocol/tasks` extension. Its presence does not make card payment available: a card checkout refuses before creating approval work.
 - Multi-round-trip `input_required` URL elicitation with HMAC-protected, client-bound request state when the client supports URL elicitation but not Tasks.
 - The `io.modelcontextprotocol/ui` Visa Control Center MCP App at `ui://visa/control-center`.
 
@@ -106,7 +112,7 @@ There is one protected enrollment, and two entrances onto it.
 | Situation | Door | What it does |
 |---|---|---|
 | Any machine, any state | `visa connect [client]` | Mounts the MCP server, signs the owner in, enrolls this machine's agent, renews the device lease, installs the Claude Code HUD. Idempotent: a second run changes nothing and says so |
-| An agent, from inside a chat | `agent_enroll` | The same workflow. Runs the sign-in leg when the session lapsed and the enrollment leg when no agent is held |
+| An agent, from inside a chat | `agent_enroll` | The same workflow. Runs the sign-in leg when the session lapsed, the device leg when the agent's wallet key is missing or revoked, and the enrollment leg when no agent is held |
 
 Order matters and is not negotiable: sign-in must precede enrollment, because
 the enrollment record is stamped with the transport profile that is active when
@@ -211,7 +217,7 @@ a name that was ever real has to stay readable here.
 | Tool | Description |
 |------|-------------|
 | `get_status` | Everything about this machine in one answer: the owner signed in, the agent this machine holds, its limits, its capabilities, and what is owed next |
-| `agent_enroll` | The one door. Idempotent: it signs the owner in when the session lapsed and enrolls when no agent is held, rather than making an agent choose between two tools |
+| `agent_enroll` | The one door. Idempotent, and runs whichever of three legs is owed: signs the owner in when the session lapsed, RECONNECTS this machine's wallet key when it is missing or revoked (that key is held in this machine's own custody, so nothing on a server can repair it), and enrolls when no agent is held. It checks the repair before enrolling, so an agent that already exists is never answered by minting a second one; pass `restart: true` to force a fresh enrollment |
 | `discover` | Find something to pay for. Takes search text, or one listing to read its live challenge without paying |
 | `pay` | Pay. The RAIL COMES FROM THE TARGET: search text searches, a listing id pays over the wallet, a payment-gated URL pays over whichever rail its challenge asks for |
 | `history` | Receipts, across every rail, with reconciliation when a payment's outcome is unresolved |