@candledottv/cli 0.13.19 → 0.13.20

package/README.md

@@ -135,8 +135,9 @@ chosen words from your saved copy. Clear your terminal's scrollback too: the CLI
 | `candle tee signer remove --key <prefix\|label>` | Removes this machine's key signer once it owns no wallets, and tells the server the signer is gone. Refuses while a wallet is still owned by it. Uses the device token, or the key's own API key. |
 | `candle tee rebind <wallet...> --to-key <prefix\|label>`, `candle tee rebinds [wallet]` | Move TEE wallets to another key on the same account (owner only, preview then `confirm`; funds and the relay signer do not move), and list the rebind history, filtered to one wallet by its id, address or exact label. |
 | `candle tee rename <label\|address\|id> <new-label>`, `candle tee rename --pairs-from <file> [--dry-run]` | Rename one TEE wallet, or 1–256 from a pairs file: the label Candle holds and the vault entry when there is one (owner only; one server call, all or nothing, then one vault commit). |
+| `candle tee check <address\|id\|label>... [--label-prefix <p>] [--sign] [--max <n>] [--rpc-url <url>]` | Check, without spending, that each named TEE wallet can really trade: payable membership, wallet record parity against the swap's own listing, and this machine's signer. `--label-prefix` selects wallets by label, `--json` prints one object per run with each wallet's `checks` and a `summary`, and the exit code is 1 when any check fails. `--sign` also builds a tiny SOL/USDC quote, checks its spend, requests a relay signature, verifies it locally and simulates; it never broadcasts, is capped at `--max` wallets (default 10) and needs `swap:write` |
 | `candle tee new\|enable` | `new` adds a key to an existing `tee-wallets.enc` and refuses when that store is absent (`vault new-key --chain solana`, then `vault promote --from <label> --to-key <prefix>`). `--factor` does not apply. `enable <address> --vault <address>` delegates an existing key with a pinned sweep vault. `vault import-legacy --tee` migrates an existing store. |
-| `candle swap <from> <to> --amount <n>\|--percent <n> --wallet <tee> [--to <tee>] [--wait]` | Quote, confirm and swap through the TEE wallet's bound key; the first buy after a launch is this command, unless `candle launch --buy` made it. The assets decide the chain (ETH, USDG or a 0x token is Hood; SOL, USDC, CNDL or a mint is Solana). SOL or USDC to ETH or USDG, or back, is a bridge through Relay into this key's own TEE wallet on the other chain (`--to` names it when there are several); `--wait` follows it for up to ten minutes. With `--json`, stdout is exactly one JSON value for swaps, token trades, replays and `swap status`: `kind`, `status`, `clientTradeId`, `signature` (the primary transaction, or `null`), `signatures` (a list) and `raw` (the original response). Every human line is on stderr. The keys older versions printed stay beside them. |
+| `candle swap <from> <to> --amount <n>\|--percent <n> --wallet <tee> [--to <tee>] [--wait] [--dry-run]` | Quote, confirm and swap through the TEE wallet's bound key; the first buy after a launch is this command, unless `candle launch --buy` made it. The assets decide the chain (ETH, USDG or a 0x token is Hood; SOL, USDC, CNDL or a mint is Solana). SOL or USDC to ETH or USDG, or back, is a bridge through Relay into this key's own TEE wallet on the other chain (`--to` names it when there are several); `--wait` follows it for up to ten minutes. With `--json`, stdout is exactly one JSON value for swaps, token trades, replays and `swap status`: `kind`, `status`, `clientTradeId`, `signature` (the primary transaction, or `null`), `signatures` (a list) and `raw` (the original response). Every human line is on stderr. The keys older versions printed stay beside them. `--dry-run` (Solana TEE payer only) checks the wallet, builds the quote and checks its spend, then stops: it never signs, sends, prompts or saves an operation, refuses `--yes`, `--percent` and `--client-trade-id`, and refuses embedded, Hood and bridge payers. With `--json` stdout is the per-check results and the quote. |
 | `candle swap status <id> [--kind trade\|swap\|launch] [--wait]` | Read an operation without resending it; `--wait` follows a bridge until it ends. |
 | `candle transfer --to <address\|wallet name\|allowlist label\|vault> --asset <SOL\|USDC\|CNDL\|ETH\|USDG>\|--mint <mint>\|--token <0x...> --amount <decimal\|max> [--wallet <tee>] [--client-id <id>] [--rpc-url <url>] [--yes]` | Move funds out of a TEE wallet through its bound Withdraw key, to the wallet's own pinned vault (`--to vault`, any token, `max` allowed, one SOL transfer at most the server's backstop ceiling, 50 SOL by default) or to another of the account's wallets you linked while signed in or marked trusted (a base asset, counted against the key's caps, which must include a per-asset cap and a USD `--tx-limit`). Where the server has `TEE_WITHDRAWALS_ENABLED` on (it ships off), also to an address on the account's withdrawal allowlist, named by its label, id or address, with the same base-asset rule. The asset decides the chain: ETH, USDG or `--token` moves from a Hood TEE wallet. The destination and its kind are shown before you confirm; Candle builds, the relay signs, Candle broadcasts. `--client-id <id>` (1 to 128 of letters, digits, `.` `_` `:` `-`) names the transfer yourself: reusing an id for a transfer already built or sent is `IDEMPOTENCY_CONFLICT` naming that transfer, so a retry never sends twice. |
 | `candle transfer status <transfer id\|client id> [--json]` | Where a transfer stands, by the id the build returned or the `--client-id` it was sent under: `built` (signable until `expiresAt`), `expired`, `submitted` with its `signature`, `unconfirmed` (may still land; check the chain or `candle activity` before using a new client id), or `failed`. Candle keeps the answer for 24 hours; an older transfer is in `candle activity`. An unknown id is `JOB_NOT_FOUND`. |
@@ -233,6 +234,17 @@ table above) runs the same check against the trusted root compiled into the bina
 call required. It is also what `install.sh` uses on a machine with neither. Full walkthrough, including the installer script's own signature and the
 transparency log: [Verify a Candle release](https://docs.candle.tv/developers/verify-a-candle-release).
 
+## Browser confirm for owner steps
+
+Where the API has `OWNER_CONFIRM_ENABLED` on, an owner step made with the device token that widens what the account's keys can do also needs one approval in your browser, signed in as the account owner. The API answers `403 OWNER_CONFIRM_REQUIRED` and changes nothing; the CLI then:
+
+1. Prints what you are approving (a summary the server built), `Open <url>` and `Code: XXXX-XXXX` on stderr, with "Only approve if you just ran this command." It opens the browser only with `--open`. Under `--json` it writes one line to stderr instead, `{"ok":false,"pending":true,"code":"OWNER_CONFIRM_REQUIRED","ownerConfirm":{"userCode","verificationUriComplete","expiresIn","step","summary"}}`, and keeps stdout for the final result.
+2. Waits, polling every few seconds. The code expires 5 minutes after it was issued.
+3. When you approve at `/dev/agent/confirm`, sends the identical request again and prints its result. Deny it and the command exits 1 with `Denied in the browser; nothing changed.`; let it expire and it exits 1 with `The confirmation expired; nothing changed. Run the command again.`
+4. With `--no-wait` it prints the code and exits 7 without waiting. The command does not resume later: run it again without `--no-wait`, or make the change in the console.
+
+One approval covers exactly one request, from this device, for this account. The steps that ask for it: `keys create` (every key, a read-only one included), `keys rotate`, `keys access` when it widens, `keys update --embedded-wallet allow`, `auth login --embedded-wallet allow` when it allows the new key the embedded wallet, `keys signer approve` (not `--reject`), `tee rebind` (not the preview), `wallets allow-launch`, `vault promote --to-key` (one approval per wallet), `keys limit` when it raises, clears or changes the window of a transaction limit, `perps thresholds set` and `clear` when they loosen, and `perps reduce-only off`. The Candle Harness shows the same summary, URL and code when its core mints a key. Narrowing steps never ask: revoking or stopping a key, narrowing access, `rotate --finish`, tightening a limit, `reduce-only on`. An older CLI prints the server's message, which carries the URL and code, but cannot finish the step: update the CLI before this is on. A signed-in console session never sees the confirm.
+
 ## The `--json` contract
 
 For agents and scripts, `--json` guarantees: **stdout carries exactly one JSON value** -- the
@@ -642,3 +654,12 @@ for the complete contract.
 During the verifier upgrade, rotation and finish may return retryable 503 with reason
 `rotation_verifier_not_ready` before changing any credential. Keep the existing secret
 and retry after the service is ready; the API does not silently shorten the grace guarantee.
+
+## Uncertain Hood legs (BE-3072)
+
+On Hood, when a leg's receipt is not confirmed, the CLI reports `LEG_UNCONFIRMED` (exit 3), keeps the
+hash it computed from its own signed bytes, and tells you not to repeat the trade and to read
+`candle swap status <id> --kind trade`. A revert exits 1 before the trade leg succeeded and 3 after.
+`No leg landed` is no longer printed on an empty list: it was never negative evidence; the CLI says
+`No leg is confirmed yet`. JSON output keeps `legEvidence`, `reconciliation`, `recoveryRequired`,
+`safeAction` and `pollAfterMs` from the server. Status makes no signing or send calls.