@visa/cli 5.0.0-rc.399 → 5.0.0-rc.401

package/README.md

@@ -216,6 +216,20 @@ next step. `get_status` reports the same in `walletKey.tempoKey`. Reopening
 the approval link, in the same tab or a new one, lands on the same approval;
 it never asks again for a code the terminal has already used.
 
+On a machine that already holds its agent, `visa connect` (and `agent_enroll`)
+also looks after the agent's card key. That key's certificate runs to the end
+of the card approval it was issued under, and renewing the limits in the
+Console does not re-issue it. So when the key is due (under 30 days left) or
+has expired, `visa connect` renews it with the same key and the same owner link
+a card purchase would open, and hands you that link. Until the owner approves,
+the old key keeps paying. The answer reports the key as `cardKey`: `live`,
+`renew_due`, `renewing`, `expired` or `none` (no card key on this computer). A
+key that is not due, and an agent without a card key, are left alone. A key
+first issued less than 30 days before its end already runs to the end of the
+approval that was current then, so it is renewed only once it expires. The
+owner is asked one thing at a time: the card key waits while TAP or this
+machine's wallet key still needs the owner; an agent with no wallet renews it.
+
 `visa connect --restart` starts a fresh approval for this machine: choose
 **Replacing** on the approval page to give the same agent new keys (its budget
 and history stay; the old keys are retired and this machine's old local records
@@ -330,7 +344,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. Its `tap` block reports this computer's TAP key (`key`) and the public directory listing (`directory`) separately |
-| `agent_enroll` | The one door. Idempotent, and runs whichever leg is owed: signs the owner in when the session lapsed, answers `already_connected` when this machine already holds a usable agent (so an agent that exists is never answered by minting a second one), and enrolls when none is held. One Approve certifies this machine's wallet, card and TAP keys. On a new computer, the owner can choose "replacing" on the approval page to move an existing agent there; the old computer's keys stop. Pass `restart: true` to force a fresh enrollment, or `setup: "<key>"` to pick up the agent the owner started on the Visa website (this is never answered `already_connected`, even when this machine holds another agent). Without `wait: true` it takes one step and says where the setup is: `awaiting_owner_device_approval` (the owner still has to approve; `browserUrl` is included), `finishing_device_setup` (the owner approved and their page is finishing; call again, nothing for the owner to do) or `connected`. It also returns `tapStatus: { key, directory }`, which is two separate facts: this computer's TAP key (`live`, `renew_due`, `expired`, `missing`) and the agent's public directory listing (`registered`, `pending`, `unavailable`, `unknown` and so on). An unreadable listing never changes `key` |
+| `agent_enroll` | The one door. Idempotent, and runs whichever leg is owed: signs the owner in when the session lapsed, answers `already_connected` when this machine already holds a usable agent (so an agent that exists is never answered by minting a second one), and enrolls when none is held. One Approve certifies this machine's wallet, card and TAP keys. On a new computer, the owner can choose "replacing" on the approval page to move an existing agent there; the old computer's keys stop. Pass `restart: true` to force a fresh enrollment, or `setup: "<key>"` to pick up the agent the owner started on the Visa website (this is never answered `already_connected`, even when this machine holds another agent). Without `wait: true` it takes one step and says where the setup is: `awaiting_owner_device_approval` (the owner still has to approve; `browserUrl` is included), `finishing_device_setup` (the owner approved and their page is finishing; call again, nothing for the owner to do) or `connected`. It also returns `tapStatus: { key, directory }`, which is two separate facts: this computer's TAP key (`live`, `renew_due`, `expired`, `missing`) and the agent's public directory listing (`registered`, `pending`, `unavailable`, `unknown` and so on). An unreadable listing never changes `key`. For a machine that already holds its agent it returns `cardKey` (`live`, `renew_due`, `renewing`, `expired`, `none`) and renews a due card key through the same owner link a card purchase opens: `awaiting_owner_card_approval` with `browserUrl` and `requiresOwnerBrowserApproval: true` when the owner must approve, and `cardKeyError` when the renewal could not finish (call again) |
 | `discover` | Find something to pay for. Takes search text (by default it searches paid services the wallet pays on Tempo), or one URL to read its live charge without paying |
 | `pay` | Pay **from the agent wallet**: MPP on Tempo, in USDC.e. Search text searches; a URL whose 402 offers a Tempo charge pays (without `max` it returns the price and what the agent can spend now). A merchant with no Tempo charge, or a directory listing id, is refused with `merchant_not_supported`. A merchant checkout URL is refused by name — that is `purchase_create` |
 | `history` | Receipts, across every rail, with reconciliation when a payment's outcome is unresolved. Tempo payments are listed under `tempoPayments` |