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

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -20,11 +20,71 @@ The protected product flow has three explicit parts:
20
20
  3. **Use** — `visa pay` and the `pay` tool enforce that authority's own policy
21
21
  and approval boundary on every call.
22
22
 
23
- Card payment is unavailable in this build: a `pay` target that answers no 402
24
- challenge refuses with `card_browser_checkout_removed`, even with a saved card,
25
- grant or tester flag. Another enrollment or card grant will not enable payment.
26
- UCP discovery and checkout preparation do not prove Visa payment support.
27
- Preserve the existing merchant checkout for the owner to continue with the merchant.
23
+ ## Protected card purchase preview
24
+
25
+ This is an explicit gated preview exception to the eight general commands and six general tools. It does not change the general `pay` URL dispatcher. The `capabilities.capabilities.card.preview` block returned by `get_status` separates callable tools and the selected protected device proof; current authority is checked per purchase, and live payment readiness remains unverified.
26
+
27
+ For the initial **Codex + local MCP on your own device** cohort, builds that list
28
+ `purchase_create`, `purchase_retrieve`, and `purchase_cancel` expose one protected
29
+ purchase resource. Preview access still requires the current owner eligibility,
30
+ verified card, device, spending limits and disclosure approval. Tool presence is
31
+ not evidence of live merchant compatibility; `card.available` remains false until
32
+ launch acceptance. Hosted MCP does not expose this device-bound path yet.
33
+
34
+ ```bash
35
+ visa purchase create --request checkout.json
36
+ visa purchase create --resume <resume-id>
37
+ visa purchase retrieve <purchase-id>
38
+ visa purchase retrieve <purchase-id> --include card
39
+ visa purchase cancel <purchase-id>
40
+ ```
41
+
42
+ `checkout.json` contains `merchantCountryCode` and the exact final
43
+ `terms` described in the [purchase guide](https://app.visacli.sh/docs/protected-card-purchases).
44
+ Fixed protocol fields and `requestKey` are optional; the client fills them deterministically. Before setup, create saves the exact nonsecret request and returns a durable `resumeId`.
45
+ Resume with `visa purchase create --resume <resume-id>` or MCP `purchase_create {resumeId}`; the original file or stdin is no longer needed. The reference stays bound to the selected owner and agent. Repeating the unchanged request also resumes it. Never put funding-card details in this file. Use `--agent <existing-agent-id>` when selection is ambiguous.
46
+
47
+ Create reuses the existing protected identity and card. A fresh user gets the
48
+ existing owner ceremony; an existing agent gets only missing card/device approval.
49
+ An expired identity setup link does not require re-enrollment. Follow the single
50
+ `next` action: show `open_url` to the owner, wait for a bounded `retry`, or explicitly
51
+ retrieve the issued card when instructed. CLI `next.argv` is an argument array,
52
+ not shell source; execute it as argv without concatenating it into a command.
53
+
54
+ Ordinary reads contain no card credential. **`--include card` / `include:"card"`
55
+ explicitly returns issued purchase credentials to stdout or the MCP tool result,
56
+ which may enter agent/chat history.** The owner must consent to that disclosure.
57
+ Original funding-card details and native signing keys are never returned. A
58
+ cryptogram is not a generic CVC; the host must establish actual merchant support.
59
+
60
+ On macOS/Linux, a host with access to the same filesystem can add `--delivery file`
61
+ (MCP: `delivery:"file"`) to the explicit card read. The result returns only
62
+ `credentialFile.path` and ordinary status; the issued credential is saved in a new
63
+ owner-only directory under `~/.visa-cli/purchase-deliveries` (or `VISA_CLI_HOME`).
64
+ Remove the file after use with `visa purchase clear-files --all`. New file deliveries also sweep earlier files past their cryptogram expiry or a 24-hour local retention cap. No background cleanup runs while the CLI is closed. This still requires `agent_history` consent; reading it
65
+ into the model can expose it to history. Windows file delivery refuses, hosted
66
+ MCP cannot consume this local path, and write failures never fall back to stdout.
67
+ Retry the same purchase and delivery option after fixing storage.
68
+
69
+ Before merchant submission, call `purchase_retrieve` with `observed:"submission_started"`
70
+ (CLI: `visa purchase retrieve <purchase-id> --observed submission_started`). Report a
71
+ challenge as `buyer_action_required`, an order response as `order_reported`, or a
72
+ failed/interrupted submission as `submission_failed`. Keep the same host checkout:
73
+ `check_checkout` never means click Pay again. Reports cannot settle or release
74
+ funds; a reported order remains unverified. After any report, further credential
75
+ reads are refused. Do not combine `observed` with `include:"card"`.
76
+
77
+ The host owns discovery, cart, browser and submission. UCP is optional preparation
78
+ or a verified compatible payment path. Issuance is not proof of payment. Preserve
79
+ the purchase ID after interruption; cancellation cannot release issued or uncertain
80
+ liability. Hosted parity and the live canary remain tracked under [#9367](https://github.com/Visa-Crypto-Labs/Visa-mono/issues/9367).
81
+
82
+ Public SDK packaging is deferred until an integrator needs direct TypeScript access.
83
+ CLI and local MCP already use one shared purchasing client.
84
+
85
+ A cold local MCP process can list and call protected enrollment/purchase tools
86
+ without an employee RC code. Other RC tools, private resources and Tasks retain
87
+ their access checks; purchase authority still comes from owner approval.
28
88
 
29
89
  ## Install
30
90
 
@@ -99,7 +159,7 @@ The server now exposes:
99
159
  - JSON Schema 2020-12 tool inputs and outputs, `structuredContent`, namespaced result metadata, cache hints, and receipt `resource_link` blocks.
100
160
  - Resources for agent status, capabilities, recent activity, and canonical `visa://receipt/{transactionId}` receipts.
101
161
  - Prompts for pairing/funding, spend inspection, safe purchasing, and receipt reconciliation, with completion support.
102
- - The `io.modelcontextprotocol/tasks` extension. Its presence does not make card payment available: a card checkout refuses before creating approval work.
162
+ - The `io.modelcontextprotocol/tasks` extension. Its presence does not make card payment available: `pay_merchant` refuses before creating approval work.
103
163
  - Multi-round-trip `input_required` URL elicitation with HMAC-protected, client-bound request state when the client supports URL elicitation but not Tasks.
104
164
  - The `io.modelcontextprotocol/ui` Visa Control Center MCP App at `ui://visa/control-center`.
105
165
 
@@ -205,7 +265,7 @@ is required, so the CLI never guesses which agent may spend.
205
265
 
206
266
  ## MCP tools (v4 surface)
207
267
 
208
- Six tools are served. There used to be thirty-five, which is more names than
268
+ Six general tools plus three protected-device preview tools are served to RC-authorized runtimes. Cold runtimes can list and call get_status, agent_enroll and the purchase preview without an employee code; protected owner rollout and authority still apply. There used to be thirty-five, which is more names than
209
269
  anyone can hold, and most of them existed because a ceremony needed a door
210
270
  rather than because an agent needed a verb.
211
271
 
@@ -221,6 +281,9 @@ a name that was ever real has to stay readable here.
221
281
  | `discover` | Find something to pay for. Takes search text, or one listing to read its live challenge without paying |
222
282
  | `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 |
223
283
  | `history` | Receipts, across every rail, with reconciliation when a payment's outcome is unresolved |
284
+ | `purchase_create` | Gated device preview: create/resume exact checkout using existing owner setup |
285
+ | `purchase_retrieve` | Preview: ordinary status, bounded host observation, or explicit include:card credential delivery |
286
+ | `purchase_cancel` | Preview: stop further work; issued or uncertain liability remains |
224
287
  | `feedback` | Send feedback on a tool result, with the owner's explicit confirmation |
225
288
  | `agent_capabilities` | **Removed.** Its capability map is a block of `get_status` |
226
289
  | `agent_login` | **Removed.** `agent_enroll` runs the sign-in leg when that is the one owed |