@allscale/cli 1.0.1 → 1.0.3

package/oclif.manifest.json

@@ -204,7 +204,7 @@
           "type": "option"
         },
         "scopes": {
-          "description": "Requested scopes for the eventual agent key, repeatable. Scope strings use `<category>:<tier>`; `:all` implies `:read_only` for the same category. Pairs the approval screen can grant: invoice:{read_only,all}, contact:{read_only,all}, transaction:read_only, wallet:read_only, claim_link:{read_only,all}, store:{read_only,all}. The final set is chosen — and can be overridden — on that screen, and is checked by the backend on each request. The Wallets toggle is on by default and grants `wallet:read_only`, which `wallet list` needs and `invoice pay` needs as ONE of its two scopes — `invoice pay` also needs `invoice:all` — request it here with `--scopes invoice:all` (it is forwarded to the approval screen), and tick the Invoices write tier there, since that toggle starts at Read. Values are checked locally first: an unrecognised `<category>:<tier>` string exits 2 before any pairing session is registered — the same check, and the same exit code, as `otp-login --scopes`. A recognised scope the screen declines to grant is reported after the key is minted, not up front.",
+          "description": "Requested scopes for the eventual agent key, repeatable. Scope strings use `<category>:<tier>`; `:all` implies `:read_only` for the same category. Pairs the approval screen can grant: invoice:{read_only,all}, contact:{read_only,all}, transaction:read_only, wallet:{read_only,all}, claim_link:{read_only,all}, store:{read_only,all}. The final set is chosen — and can be overridden — on that screen, and is checked by the backend on each request. With no requested scopes, every category starts OFF and the user must select at least one. Passing --scopes preselects each exact matching tier the screen can grant. `wallet list` needs `wallet:read_only`. `invoice pay` needs `invoice:all` AND `wallet:all` — its withdrawal registration rides the same broker op as `wallet send` (backend gates the op, not the verb), and the write tier covers its payer-address read via the implication — so request both (`--scopes invoice:all --scopes wallet:all`) to preselect both write tiers, or select both Allow-changes switches before authorizing. `wallet send` requires `wallet:all` the same way; every transfer still requires your in-browser confirmation. Every category recognised as a spelling, so a usable value can be found without guessing: admin:audit, admin:org, admin:user, claim_link, cli_op, contact, invoice, payroll, store, transaction, wallet. claim_link, contact, invoice, store, transaction, wallet carry the tiers listed above. admin:audit, admin:org, admin:user, payroll are in the catalog but granted to NOBODY — every mint path drops them, so no login command can deliver them; this command rejects them locally, before any pairing session. cli_op is attached to every key the backend mints, by both login commands, without being requested — you never need to ask for it, and asking is not an error. Values are checked locally first: an unrecognised `<category>:<tier>` string exits 2 before any pairing session is registered — the same check, and the same exit code, as `otp-login --scopes`. A recognised scope the screen has no toggle for is also rejected locally, with the remediation that actually works: otp-login for operational scopes (or `--allow-unrenderable-scopes` when your web app is newer than this CLI's catalog), nothing for payroll/admin:* — the approval page refuses the whole authorization when even one requested scope is unrenderable, so deferring the answer to the browser would strand you after a pairing session already exists. An explicitly requested `cli_op:*` is not an error: the backend appends it to every pairing-minted key, so it is omitted from the request with a note. If another requested scope remains, the resulting key is identical; if it was the only one, the approval screen starts every category OFF and requires the user to choose at least one. Only a scope the screen renders and the user declines is reported after the key is minted.",
           "name": "scopes",
           "hasDynamicHelp": false,
           "multiple": true,
@@ -216,6 +216,12 @@
           "allowNo": false,
           "type": "boolean"
         },
+        "allow-unrenderable-scopes": {
+          "description": "Forward a scope to the approval screen even when this CLI's catalog says the screen has no toggle for it. Escape hatch for a stale catalog: the screen-grantable list above is a MIRROR of the web app's approval screen and can lag a frontend release, and without this flag a lagging mirror makes such a scope impossible to request until a CLI update ships. The screen stays the authority — if it truly cannot render the scope it refuses the WHOLE authorization after the pairing session exists (the stranding the local check normally prevents), so use this only when you have reason to believe the web app is newer than this CLI. Scopes no login path can mint (payroll/admin:*) are still rejected locally; this flag does not touch them.",
+          "name": "allow-unrenderable-scopes",
+          "allowNo": false,
+          "type": "boolean"
+        },
         "yes": {
           "char": "y",
           "description": "Skip the interactive confirmation and start the pairing immediately. Only a BARE invocation is ever prompted, so passing any flag already skips it; use this to say so explicitly. Automation that allocates a pty for stdin/stdout/stderr and runs the command bare is indistinguishable from a human — that is the case this flag exists for.",
@@ -247,10 +253,10 @@
     "logout": {
       "aliases": [],
       "args": {},
-      "description": "Clear cached credentials (session token + store keys) for a profile. By default, clears BOTH the OS keychain and plaintext file store. With --insecure-storage or ALLSCALE_INSECURE_STORAGE=1, clears only plaintext files and never probes the keychain; omit/unset that opt-in when a full-machine sweep is wanted. If the keychain is suppressed or unavailable, a bare logout fails closed after attempting the plaintext-file cleanup.",
+      "description": "Clear cached credentials (session token + store keys) for a profile. By default, clears BOTH the OS keychain and plaintext file store. With --insecure-storage or ALLSCALE_INSECURE_STORAGE=1, clears only plaintext files and never probes the keychain; omit/unset that opt-in when a full-machine sweep is wanted. If the keychain is suppressed or unavailable, a bare logout fails closed after attempting the plaintext-file cleanup. A bare interactive invocation asks for confirmation before anything is removed; any flag (or --yes) skips the prompt, and machine callers are never prompted.",
       "examples": [
-        "$ allscale logout",
-        "$ allscale logout --profile staging"
+        "$ allscale logout --profile staging",
+        "$ allscale logout --yes"
       ],
       "flags": {
         "json": {
@@ -292,6 +298,13 @@
           "name": "insecure-storage",
           "allowNo": false,
           "type": "boolean"
+        },
+        "yes": {
+          "char": "y",
+          "description": "Skip the interactive confirmation and clear the credentials immediately. Only a BARE invocation is ever prompted, so passing any flag already skips it; use this to say so explicitly. Automation that allocates a pty for stdin/stdout/stderr and runs the command bare is indistinguishable from a human — that is the case this flag exists for.",
+          "name": "yes",
+          "allowNo": false,
+          "type": "boolean"
         }
       },
       "hasDynamicHelp": false,
@@ -467,7 +480,7 @@
           "type": "option"
         },
         "scopes": {
-          "description": "Scopes the minted agent key should carry, repeatable. Scope strings use `<category>:<tier>`; `:all` implies `:read_only` for the same category. Pairs that reach a real operation today: invoice:{read_only,all}, contact:{read_only,all}, claim_link:{read_only,all}, transaction:{read_only,all}, store:{read_only,all}, wallet:{read_only,all}. transaction:all, wallet:all reach only their category's READS — no write operation is wired to either today, so the `:read_only` tier grants exactly as much; prefer it unless you have a reason to hold the wider scope. Other pairs are accepted by the catalog but grant nothing, and this command does NOT warn when a requested scope is clipped — verify with `allscale scope` after minting. Values are checked locally first: an unrecognised `<category>:<tier>` string exits 2 before any OTP is sent — the same check, and the same exit code, as `device-login --scopes`. Required — the backend deliberately has no full-permission default. Requested scopes are clipped to your account's role; granted scopes are checked by the backend on each request.",
+          "description": "Scopes the minted agent key should carry, repeatable. Scope strings use `<category>:<tier>`; `:all` implies `:read_only` for the same category. Pairs that reach a real operation today: invoice:{read_only,all}, contact:{read_only,all}, claim_link:{read_only,all}, transaction:{read_only,all}, store:{read_only,all}, wallet:{read_only,all}. transaction:all — read-only in practice: no write operation is wired there today, so the `:read_only` tier grants exactly as much; prefer it unless you have a reason to hold the wider scope. `wallet:all` additionally lets the key register `wallet send` transfers; every transfer still requires your in-browser confirmation. Other pairs are accepted by the catalog but grant nothing, and this command does NOT warn when a requested scope is clipped — verify with `allscale scope` after minting. Every category recognised as a spelling, so a usable value can be found without guessing: admin:audit, admin:org, admin:user, claim_link, cli_op, contact, invoice, payroll, store, transaction, wallet. claim_link, contact, invoice, store, transaction, wallet carry the tiers listed above. admin:audit, admin:org, admin:user, payroll are in the catalog but granted to NOBODY — every mint path drops them, so no login command can deliver them, and requesting them gains nothing. cli_op is attached to every key the backend mints, by both login commands, without being requested — you never need to ask for it, and asking is not an error. Values are checked locally first: an unrecognised `<category>:<tier>` string exits 2 before any OTP is sent — the same check, and the same exit code, as `device-login --scopes`. Required — the backend deliberately has no full-permission default. Requested scopes are clipped to your account's role; granted scopes are checked by the backend on each request.",
           "helpGroup": "REQUIRED",
           "name": "scopes",
           "required": true,
@@ -695,7 +708,7 @@
     "whoami": {
       "aliases": [],
       "args": {},
-      "description": "Show the current authenticated identity from the stored credential (agent-key sessions report business_id / scopes / expiry; legacy password sessions decode the cached JWT). No network call.",
+      "description": "Show the current authenticated identity from the stored credential (agent-key sessions report business_id / scopes / expiry; legacy password sessions decode the cached JWT). No network call. The reported `api_base` is the endpoint this session resolves to — its saved profile pin, else this build's own environment. A published build ignores ALLSCALE_API_BASE, and says so on stderr rather than echoing it as the session endpoint; an internal build honours the variable, so it is echoed there. Either way, a resolved endpoint that networked commands would refuse — an untrusted origin, or a real AllScale environment outside this build's signing binding, whether it came from the variable or from the profile's saved pin — is disclosed on stderr. This command stays usable offline and never fails closed.",
       "examples": [
         "$ allscale whoami",
         "$ allscale whoami --profile prod"
@@ -1586,7 +1599,7 @@
           "required": true
         }
       },
-      "description": "Pay an invoice where you are the payer, from your AllScale wallet. Use `allscale invoice sent` to list the invoices you owe (add --status SENT --status ACKNOWLEDGED --status FAILED for the ones you can start paying). An OVERDUE invoice cannot start a new payment: if an earlier attempt of yours may still be in flight, reconcile that first — otherwise ask the issuer to extend its due date, which revives it. Resolves the invoice's destination + amount, moves the funds via the same signing path as `wallet send` (the transfer is confirmed in the browser), then reports and confirms the payment. Needs TWO scopes: `invoice:all` to create, report and confirm the pay intent, and `wallet:read_only` to look up the address you are paying FROM. Neither LOGIN flow grants `invoice:all` for you: on `device-login` the Invoices toggle starts at Read, so tick its write tier on the approval screen; on `otp-login` pass BOTH --scopes invoice:all --scopes wallet:read_only, because naming any scope turns every unnamed category off.",
+      "description": "Pay an invoice where you are the payer, from your AllScale wallet. Use `allscale invoice sent` to list the invoices you owe (add --status SENT --status ACKNOWLEDGED --status FAILED for the ones you can start paying). An OVERDUE invoice cannot start a new payment: if an earlier attempt of yours may still be in flight, reconcile that first — otherwise ask the issuer to extend its due date, which revives it. Resolves the invoice's destination + amount, moves the funds via the same signing path as `wallet send` (the transfer is confirmed in the browser), then reports and confirms the payment. Needs TWO scopes: `invoice:all` to create, report and confirm the pay intent, and `wallet:all` to register the withdrawal — the same broker op `wallet send` uses (backend gates the op, not the verb); it also covers the payer-address lookup, since `:all` implies `:read_only`. Neither login flow adds these scopes for you. A bare `device-login` starts every category OFF: request BOTH --scopes invoice:all --scopes wallet:all to preselect them, or turn on both Allow-changes switches on the approval screen. On `otp-login`, pass the same two --scopes values because it requests only explicitly supplied scopes, has no implicit scope defaults, and the final grants are clipped to your account's role.",
       "examples": [
         "$ allscale invoice pay 65ab1234567890abcdef0123",
         "$ allscale invoice pay 65ab1234567890abcdef0123 --chain bsc --stable-coin USDT"
@@ -1941,7 +1954,7 @@
           "type": "option"
         },
         "auto-create-contact": {
-          "description": "If --to-email doesn't resolve to an existing contact, auto-create the contact (using the email + your business as owner; name defaults to the full email address, override with --contact-name) and proceed with the invoice. Ignored when the contact already exists (safe to leave on in scripts). Requires --to-email; not valid with --to-contact-id.",
+          "description": "If --to-email doesn't resolve to an existing contact, auto-create the contact (using the email + your business as owner; name defaults to the full email address, override with --contact-name) and proceed with the invoice. Ignored when the contact already exists (safe to leave on in scripts). Under an agent key, the full send needs contact:all and invoice:all, plus wallet:read_only unless you pass --wallet-id. A bare device-login approval starts every category OFF and its new key replaces the old one, so select Contacts write and Invoices Allow changes plus Wallets read (unless using --wallet-id) in the same re-login. Requires --to-email; not valid with --to-contact-id.",
           "exclusive": [
             "to-contact-id"
           ],
@@ -1975,7 +1988,7 @@
           "type": "option"
         },
         "payment-type": {
-          "description": "What the invoice is denominated in AND which stablecoin it may be paid with: 0 = fiat (pair with --currency-int), 1 = USDT, 2 = USDC. Passing 1 or 2 EXPLICITLY pins the invoice to that coin — a payment arriving in the other stablecoin is rejected, and the payer's email names only this coin. Omit the flag and the invoice accepts whichever stablecoins your business is configured for (it is still denominated in USDT, the default). For 0 the amount is fiat but settlement is still in a stablecoin, so the payer may likewise use any coin your business accepts. Run `allscale describe create_payment` for the full list. Default: 1 (denomination only — omitting the flag pins nothing).",
+          "description": "What the invoice is denominated in AND which stablecoin it may be paid with: 0 = fiat (pair with --currency-int), 1 = USDT, 2 = USDC. Passing 1 or 2 EXPLICITLY pins the invoice to that coin — a payment arriving in the other stablecoin is rejected, and the payer's email names only this coin. Omit the flag and the invoice accepts whichever stablecoins your business is configured for (it is still denominated in USDT, the default). For 0 the amount is fiat but settlement is still in a stablecoin, so the payer may likewise use any coin your business accepts. Any other value is rejected locally (exit 2) — the backend would otherwise issue an invoice in an undocumented asset. Default: 1 (denomination only — omitting the flag pins nothing).",
           "name": "payment-type",
           "default": 1,
           "hasDynamicHelp": false,
@@ -3015,7 +3028,7 @@
     "wallet:send": {
       "aliases": [],
       "args": {},
-      "description": "Withdraw a stablecoin from your AllScale wallet to an EVM address. The transfer is confirmed in the browser; the CLI prints the transaction hash and explorer URL only after its on-chain receipt confirms.",
+      "description": "Withdraw a stablecoin from your AllScale wallet to an EVM address. The transfer is confirmed in the browser; the CLI prints the transaction hash and explorer URL only after its on-chain receipt confirms. Needs `wallet:all` on an agent key: it registers the withdrawal op (`wallet:read_only` alone cannot). Every transfer still requires your in-browser confirmation.",
       "examples": [
         "$ allscale wallet send --idempotency-key order-1042 --to 0x1234567890abcdef1234567890abcdef12345678 --amount 100 --chain ethereum",
         "$ allscale wallet send --idempotency-key order-1043 --to 0x1234567890abcdef1234567890abcdef12345678 --amount 50 --chain polygon --stable-coin USDC",
@@ -3156,5 +3169,5 @@
       ]
     }
   },
-  "version": "1.0.1"
+  "version": "1.0.3"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@allscale/cli",
-  "version": "1.0.1",
+  "version": "1.0.3",
   "description": "Command-line interface for AllScale — drives the same actions a user can take in app.allscale.io",
   "keywords": [
     "allscale",