@capxul/cli 4.20.0-beta.29 → 4.20.0-beta.30

package/README.md

@@ -1,7 +1,8 @@
 # Capxul CLI
 
-The CLI provides email OTP login, persistent first-party sessions, terminal-owned
-signup, personal and Organization contacts, a bundled Openfort wallet page,
+The CLI provides email OTP login, persistent first-party sessions, a handover to
+the web app for Account setup, personal and Organization contacts, a bundled
+Openfort wallet page for Organization setup,
 backend profile and account reads, diagnostics, and one global collection
 preference. It requires Node 24 or later on macOS or Linux.
 
@@ -228,7 +229,11 @@ payment to whoever funded it; `redirect` sends it to someone else. For an
 Organization's held payment only an Owner may cancel or redirect it; anyone else,
 a Budget member included, is refused before anything is prepared. Both hand over
 to the approval page as `send` does, then read the Payment until the chain shows
-the step (`payment wait <approval id>` reports them once sent).
+the step (`payment wait <approval id>` reports them once sent). A cancelled
+payment keeps the amount it was for. A cancel or redirect of a payment that is
+no longer held is refused (`WRONG_STATE`, exit 2) with `Payment <id> is already
+cancelled.` or the state it is in. A held payment that was never signed reads
+`failed`, not `scheduled`.
 
 Retry prepares the retry of the exact Payment and hands over to the approval
 page, exactly as `payment send` does: the page is the one and only
@@ -481,10 +486,10 @@ Organization's treasury with `--org`. Balance shows exact asset quantities and
 available fiat valuations. An unavailable valuation or failed read is not zero.
 `address` uses the SDK's address and network.
 
-`account retry --display-name NAME --country CC --handle HANDLE` is the first
-setup: it creates the Profile, the personal Account and its wallet, as
-`auth login` offers to on a terminal. Without Profile fields, `account retry`
-resumes the setup of the existing Account.
+Account setup finishes in the Capxul web app, not in the CLI: it creates your
+wallet, which needs you in a browser, and the CLI never opens one. `account retry`
+reads your Account; when it is not ready, it prints the web app link. Run it again
+to check: it returns the same handover until the Account is ready.
 
 ## Organization commands
 
@@ -626,7 +631,10 @@ read `status`. `--json --wait` writes the approval link to stderr as one
 `approval.awaiting` event and returns once it is followed through.
 `--timeout-seconds` bounds how long the CLI follows it (default: until the
 approval lapses). A follow that runs out of time fails with exit 5 and names the
-wait command. After an interruption or uncertain result, retain the original
+wait command. The same write run again with a request key whose command was
+already sent opens no approval and shows no link: it reads the command and
+prints `Already applied: …` (or where it stands), with the command's view in
+`command`. After an interruption or uncertain result, retain the original
 input, Organization ID, key, command ID, and execution ID. The key alone cannot
 restore wizard/stdin input.
 
@@ -853,7 +861,9 @@ known, the command lists your Organizations instead of guessing one.
 `--json` writes one version 1 envelope to stdout. Success contains `data`: the
 SDK's own value for the command, with no CLI wrapper. A list is the SDK page,
 `{ items, nextCursor }`; pass `nextCursor` back as `--after` where the command
-takes one. `--fields a,b` keeps only those fields of `data` (`amount.value`
+takes one. A list whose next cursor would show the same page again fails with
+exit 1 and `The list did not advance past the cursor <cursor>`, so a paging loop
+ends. `--fields a,b` keeps only those fields of `data` (`amount.value`
 reaches inside an object; a list keeps `nextCursor` and picks from each item).
 `--fields` without `--json` refuses, and so does a typo: a name the result lacks that is a
 letter or two off a name it has (exit 2, `field: "fields"`); the message names it, the
@@ -1010,17 +1020,26 @@ This CLI establishes a first-party BetterAuth session. An older native
 Logout clears the selected email's session and attempts to revoke any native
 grant that was stored before the first-party flow replaced it.
 
-`capxul auth login` and `capxul account retry` stay separate commands. On a
-terminal, each command is a wizard. `auth login` asks for the email and a masked
-OTP. It accepts the code as a paste. It retries an invalid code at most three
-times for one request. After sign-in, an incomplete account gets one offer to
-continue setup in the same command. `account retry` authenticates first, then asks
-for the Profile fields: display name, two-letter country code, and handle. A
-known value is the prompt default, so Enter keeps it.
+On a terminal, `auth login` is a wizard. It asks for the email and a masked OTP.
+It accepts the code as a paste. It retries an invalid code at most three times
+for one request.
 
-The browser opens only when the shared Core onboarding journey needs Openfort
-wallet readiness. It shows wallet status only. It has no email, OTP, Profile, or
-approval form.
+`auth login` and `account retry` never open a browser, in any output mode. When
+your Account is not set up, they print where to finish it:
+
+```text
+Signed in as person@example.com.
+Account setup required.
+Finish setting up your Account in your browser, signed in as person@example.com:
+  https://app.staging.capxul.com/
+Then check it with: capxul account retry --email 'person@example.com'
+```
+
+With `--json`, `data` carries the same handover:
+`setupState: "setup-required"`, `status: "awaiting_setup"`, `setupUrl` and
+`next.argv` (`["capxul", "account", "retry", "--email", EMAIL, "--json"]`, with the
+`--org` and `--env` you typed). That read exits 0 and returns the handover again,
+or the ready report. `capxul schema auth login` declares the shape.
 
 Ctrl+C or Ctrl+D at a wizard prompt cancels the command. The command prints no
 success result and exits 130. A step that already finished keeps its result: a
@@ -1041,67 +1060,33 @@ After sending a code, the output names `capxul auth verify <code>`. If
 verification has no waiting sign-in, the error names `capxul auth login`.
 Neither command prints the code itself.
 
-If account setup or its final read fails recoverably, the CLI prints an exact
-`account retry` continuation with your email and Profile fields. Run it with the
-same protected CLI home to resume the saved session. Explicit access/input
-refusals and non-retryable failures require their stated correction first.
-
 Human profile/status output labels your Profile fields and available Account,
 wallet and Smart Account identifiers. Failed setup includes its stage and error
 code. These reads do not open the wallet browser. `--json` retains the structured
 result, including the same Profile and lifecycle values.
 
 A machine run never prompts. `auth login` with `--otp-stdin` sends the OTP and
-verifies one code from stdin. It returns the tagged result
-`setupState: "setup-required"` when the account needs setup. It does not start
-setup work, so sign-in never becomes signup.
-
-A fresh machine signup does verification and setup in one command. State every
-Profile field; a missing field refuses with exit 2:
-
-```sh
-# Supply only the delivered OTP through stdin.
-capxul account retry --email "$TEST_EMAIL" --otp-stdin \
-  --display-name "Test Person" --country GH --handle test_person --json
-```
+verifies one code from stdin. It returns the profile report, with the setup
+handover when the Account is not ready. It starts no setup work.
 
 `--otp-stdin` reads up to 64 bytes, ending at EOF. Pipe from a secret provider or
 use input redirection from a protected file. An invalid value refuses with exit 2.
-For `account retry`, a missing `--otp-stdin` refuses with exit 2 before the command
-starts client work. Only `auth verify <code>` accepts a code as an argument: the
-code is single-use and expires in minutes. Codes are never persisted in the
-continuation or included in output.
-
-The local page binds to an OS-selected loopback port. A random launch capability
-is redeemed once and removed from the URL before Openfort starts. The page receives
-only the authenticated wallet token and encryption session in memory. Closing it
-ends the current wallet attempt. Re-run `account retry` with the same CLI home to
-resume the same Profile and Account without another OTP while the backend session
-remains valid.
-
-`account retry` returns only two readiness results. `setupState: "ready"` is a
-personal Account that the Account readiness owner reads as ready and deployed,
-and its data carries the public identifiers: the Profile, the public wallet
-address (`smartAccount.signerAddress`), the personal Smart Account address
-(`smartAccount.smartAccountAddress`), the Account ID
-(`lifecycle.accountId`), and the ready status. Any other state returns the typed
-recoverable result `setupState: "setup-required"`, with the lifecycle, its
-failure code, and the command that resumes the journey. A ready Account starts
-no wallet work, so a retry keeps the one Profile, wallet, Smart Account, and
-Account. An interruption keeps the stored session and stores no code, so the
-next command resumes the same setup.
+Only `auth verify <code>` accepts a code as an argument: the code is single-use
+and expires in minutes. Codes are never persisted or included in output.
+
+`setupState: "ready"` is a personal Account that the Account readiness owner
+reads as ready and deployed. Its data carries the public identifiers: the
+Profile, the public wallet address (`smartAccount.signerAddress`), the personal
+Smart Account address (`smartAccount.smartAccountAddress`), the Account ID
+(`lifecycle.accountId`), and the ready status. Any other state is
+`setupState: "setup-required"` with the lifecycle, its failure code, and the
+handover above.
 
 A ready personal Account continues the same journey into Organization creation
 with `capxul org create --name NAME --handle HANDLE --country CC`. The create
 command records the safe recovery handle for that Organization, so an
 interruption or a restart resumes the exact same Organization.
 
-The CLI checks `--display-name`, `--country`, and `--handle` before it opens a
-client, so a malformed value refuses with exit 2 and no code is sent. The handle
-check covers the grammar only: a handle that another person holds, and a reserved
-handle, refuse through the identity owner after sign-in. Both refusals name the
-handle, and neither offers verification-code recovery for a Profile problem.
-
 The version 2 `first-party-session` record stores the opaque provider credential
 in the existing protected plaintext store. Its scope includes the application
 key, issuer, environment, and email. Each process validates restoration with the
@@ -1112,21 +1097,19 @@ local sign-out remains in effect.
 
 `account show` returns a backend-read Profile and account lifecycle without opening
 the browser. Successful email authentication can return `setupState: "setup-required"`.
-`account retry` returns `setupState: "ready"` only after Core reads a ready Account.
+`account retry` returns `setupState: "ready"` only after Core reads a ready Account;
+otherwise it returns the web app handover.
 After logout, profile reads refuse with `NOT_AUTHENTICATED` and exit 3. An invalid
 or expired OTP refuses with exit 2.
 
-Resume an existing personal Account after incomplete setup:
+Find where to finish an incomplete personal Account:
 
 ```sh
-capxul account retry --email you@example.com --confirm --timeout-seconds 120
-capxul account retry --email you@example.com --wizard
+capxul account retry --email you@example.com
 ```
 
-The terminal shows the verified session, Account ID and current lifecycle before
-confirmation. A ready Account starts no wallet work. Missing Account or Profile
-state directs to `account retry`. A deadline stops waiting; check `account show`
-for the same session before retrying.
+It writes nothing and opens no browser. Missing Account or Profile state in other
+commands directs to `account retry`.
 
 Read an Organization treasury or deposit target:
 

package/dist/browser/signer.js

@@ -15200,7 +15200,9 @@ faucetMint: Operation.action("accounts.grants.faucetMint", {
 			needsYou: NullOr(Struct({
 				requestsToPay: ArraySchema(String$1),
 				payrollToApprove: ArraySchema(String$1),
-				paymentsToRetry: ArraySchema(String$1)
+				paymentsToRetry: ArraySchema(String$1),
+				/** The caller's capped Budgets in the Organization with nothing left this period. */
+				budgetsUsedUp: ArraySchema(String$1)
 			})),
 			/** The newest rows of the actor's activity. */
 			recentActivity: NullOr(ArraySchema(ActivityItemSchema))
@@ -15857,7 +15859,8 @@ ensure: Operation.action("documents.memos.ensure", {
 					"verified",
 					"mismatch",
 					"provider_failure",
-					"applied"
+					"applied",
+					"abandoned"
 				]),
 				executionState: Literals([
 					"unprepared",
@@ -18044,7 +18047,8 @@ list: Operation.query("payroll.terms.list", {
 				"verified",
 				"mismatch",
 				"provider_failure",
-				"applied"
+				"applied",
+				"abandoned"
 			]),
 			status: Literals([
 				"pending",
@@ -19543,7 +19547,9 @@ loadBudgetLeft: "permissions.authorities.loadBudgetLeft" },
 					/** The prepare action's transaction: authorize, plan and save the command. */
 					prepareIntent: "permissions.commands.prepareIntent",
 					/** The submit action's transaction: record the accepted UserOperation. */
-					completeExecution: "permissions.commands.completeExecution"
+					completeExecution: "permissions.commands.completeExecution",
+					/** The prepare's cleanup: a saved command whose UserOperation could not be built ends. */
+					abandonUnbuilt: "permissions.commands.abandonUnbuilt"
 				},
 				configurations: {
 					prepareIntent: "permissions.configurations.prepareIntent",