@capxul/cli 4.20.0-beta.26 → 4.20.0-beta.27

package/README.md

@@ -189,7 +189,7 @@ payment's wait carries `--org`.
 ## Personal Payments
 
 ```sh
-capxul payment retry PAYMENT_ID --confirm --json
+capxul payment retry PAYMENT_ID --json
 capxul payment list --json
 capxul payment get PAYMENT_ID --json
 capxul payment wait PAYMENT_ID --timeout-seconds 120 --json
@@ -205,9 +205,11 @@ action. A failed Payment can be a completed observation. The timeout accepts
 1–3600 seconds and includes session restoration. A timeout or unavailable read
 prints exact get/wait commands. Waiting never resubmits a Payment.
 
-Retry returns `{ payments }` and addresses the existing Payment command. It
-never creates a replacement send. It still signs in the terminal through the
-local wallet page until the approval page covers retries.
+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
+confirmation, and `--json` returns `awaiting_approval`, the link and
+`next.argv` for `payment wait <approval id>`. It addresses the existing Payment
+command and never creates a replacement send.
 
 ## Activity
 
@@ -240,7 +242,7 @@ capxul request get REQUEST_ID
 capxul request cancel REQUEST_ID --confirm
 capxul inbox list
 capxul inbox get REQUEST_ID
-capxul inbox pay REQUEST_ID --confirm
+capxul inbox pay REQUEST_ID
 capxul inbox decline REQUEST_ID --confirm
 capxul request list --org ORGANIZATION_ID
 capxul request issue --org ORGANIZATION_ID --input invoice.json --confirm
@@ -248,7 +250,7 @@ capxul request get --org ORGANIZATION_ID REQUEST_ID
 capxul request cancel --org ORGANIZATION_ID REQUEST_ID --confirm
 capxul inbox list --org ORGANIZATION_ID
 capxul inbox get --org ORGANIZATION_ID REQUEST_ID
-capxul inbox pay --org ORGANIZATION_ID REQUEST_ID --permission-id PERMISSION_ID --confirm
+capxul inbox pay --org ORGANIZATION_ID REQUEST_ID --permission-id PERMISSION_ID
 capxul inbox decline --org ORGANIZATION_ID REQUEST_ID --confirm
 ```
 
@@ -521,25 +523,14 @@ instructions with both Organization and Payment IDs.
 ## Organization Payment retry
 
 ```sh
-capxul payment retry P --org O --confirm --json
-capxul payment retry
+capxul payment retry P --org O --json
 ```
 
 Retry addresses the original command and every Payment in that command. It
-creates no replacement send or request key. A terminal can collect the Payment
-ID. JSON and scripted runs require the Payment ID, the Organization, and
-`--confirm`.
-
-Before signing, the preview shows every original Payment, recipient, exact
-asset and quantity, timing, and state. It also shows the original command and
-stored Budget. A human terminal asks one default-no question, including when
-`--confirm` is supplied. The signer starts after this step. A changed prepared cohort
-or actor refuses before signature.
-
-The result is `{ payments }` in the SDK's original order. Submitted Payments
-can still be pending. A failure, timeout, or interruption retains the selected
-Organization, Payment, and verified sibling IDs with same-scope get/wait
-commands. Retry does not claim settlement from a submission hash.
+creates no replacement send or request key. The Organization's retry is
+prepared for your own key and handed over to the approval page; the page
+shows the whole cohort. `--json` returns the link and `next.argv` for
+`payment wait <approval id> --org O`, which follows every Payment to its end.
 
 ## Permissions
 
@@ -612,8 +603,8 @@ capxul org payroll groups save --org O --input group.json --confirm [--json]
 capxul org payroll groups remove G --org O --confirm [--json]
 capxul org payroll terms --org O [--json]
 capxul org payroll list --org O [--json]
-capxul org payroll run --org O --input run.json --request-key K --confirm [--json]
-capxul org payroll run --org O --resume K --confirm [--json]
+capxul org payroll run --org O --input run.json --request-key K [--json]
+capxul org payroll run --org O --resume K [--json]
 capxul org payroll get --org O R [--json]
 capxul org payroll wait --org O R --timeout-seconds 120 [--json]
 ```
@@ -640,16 +631,18 @@ refuse before client work.
 In a human terminal, `capxul org payroll run` guides the current Organization,
 Budget, settlement asset, date, roster or known Parties, and actual payout
 quantities. Roster amounts and terms are reference data. The complete preview
-shows each recipient and Safe, quantity, raw units, and adjustment. One
-default-no approval precedes signing, including when `--confirm` is supplied.
-Machine runs require exact scope, input, key, and `--confirm`.
+shows each recipient and Safe, quantity, raw units, and adjustment. The run
+is then prepared and handed over to the approval page, the one and only
+confirmation. Machine runs require exact scope, input and key; `--json`
+returns the approval link and `next.argv` for `payment wait <approval id> --org O`.
 
 The command saves the exact input in protected storage under the verified actor,
 Organization, and key before execution. `--resume K` restores that snapshot.
 It requires the same explicit Organization and cannot combine fresh input or
 another key. Payroll accepts email and Party references. Raw external addresses
 are outside the current run contract.
-Success returns `{ run, requestKey }`; submission does not prove settlement.
+`--resume K` prepares the same run again, so it reopens a pending approval
+rather than paying twice.
 
 Get returns the full authorized run detail, command, ordered items, and recorded
 times. Wait observes the exact run without polling or submitting. It keeps
@@ -1205,9 +1198,10 @@ External funding requires the correct network, balance, gas, and any exact token
 approval. Payment goes through the Payments contract with the validated snapshot.
 Inspect the resulting state and receipt before reporting payment complete.
 
-CLI `inbox pay` retains its existing CLI signing flow. It does not depend on the
-hosted checkout page. A rejected signature or uncertain reply is not permission
-to send another Payment. Use the printed readback and recovery instructions.
+CLI `inbox pay` prepares the request's Payment and hands over to the approval
+page, as `payment send` does. It does not depend on the hosted checkout page.
+A rejection on the approval page is not permission to send another Payment.
+`--resume` reopens the approval of a request whose Payment is already prepared.
 
 Checkout links do not create recurring billing, automatic debits, booking,
 refunds, or QR codes.

package/dist/browser/signer.js

@@ -19641,10 +19641,19 @@ get: Operation.query("activity.overlays.get", {
 		name: String$1,
 		explorerUrl: String$1
 	});
+	/**
+	* Whose money the operation moves: the person's own, or an Organization's,
+	* which a reader follows through that Organization's scope.
+	*/
+	const ApprovalActorSchema = Union([Struct({ kind: Literal("personal") }), Struct({
+		kind: Literal("organization"),
+		orgId: NonEmptyString
+	})]);
 	/** What the person reads before they sign. */
 	const ApprovalSummarySchema = Struct({
 		title: String$1,
 		from: Struct({
+			kind: Literals(["personal", "organization"]),
 			label: String$1,
 			address: AddressSchema$1
 		}),
@@ -19666,6 +19675,7 @@ get: Operation.query("activity.overlays.get", {
 		url: String$1,
 		kind: Literals(APPROVAL_KINDS),
 		state: Literals(APPROVAL_STATES),
+		actor: ApprovalActorSchema,
 		summary: ApprovalSummarySchema,
 		operation: ApprovalOperationSchema,
 		/** Who must sign: the owner key of the paying Safe. */
@@ -23850,7 +23860,11 @@ complete: Operation.mutation("profiles.onboardings.complete", {
 				seedNativeReadiness: "operator.fixtures.seedNativeReadiness",
 				seedPrerequisites: "operator.fixtures.seedPrerequisites"
 			},
-			identities: { purgeByEmail: "operator.identities.purgeByEmail" }
+			identities: {
+				purgeByEmail: "operator.identities.purgeByEmail",
+				/** One Account and every row that refers to it, unless it has Payments or an Organization tie. */
+				purgeAccount: "operator.identities.purgeAccount"
+			}
 		},
 		/** Organizations' internal functions; its public rows join from `OPERATIONS`. */
 		organizations: {
@@ -24100,7 +24114,11 @@ emitChanged: "payroll.groups.emitChanged" }
 				recordUse: "applications.bootstraps.recordUse",
 				resolve: "applications.bootstraps.resolve"
 			},
-			keys: { issue: "applications.keys.issue" },
+			keys: {
+				issue: "applications.keys.issue",
+				/** Operator-only: revoke one key by its id, whoever owns it. */
+				revokeById: "applications.keys.revokeById"
+			},
 			quickstarts: {
 				claim: "applications.quickstarts.claim",
 				mint: "applications.quickstarts.mint"
@@ -27661,6 +27679,14 @@ emitChanged: "payroll.groups.emitChanged" }
 			}
 		};
 	}
+	Struct({
+		permissionId: AuthorizePayrollRunExecutionInputSchema.fields.permissionId,
+		asset: AuthorizePayrollRunExecutionInputSchema.fields.asset,
+		period: AuthorizePayrollRunExecutionInputSchema.fields.period,
+		items: AuthorizePayrollRunExecutionInputSchema.fields.items,
+		requestKey: optional(AuthorizePayrollRunExecutionInputSchema.fields.requestKey)
+	});
+	runs.authorize.name;
 	//#endregion
 	//#region ../../packages/sdk/src/platform/transport/wire.ts
 	/**
@@ -36292,14 +36318,6 @@ query Role($id: String, $block: Int) {
 	init_toFunctionSelector();
 	toFunctionSelector("setTransactionUnwrapper(address,bytes4,address)");
 	toFunctionSelector("assignRoles(address,bytes32[],bool[])");
-	Struct({
-		permissionId: AuthorizePayrollRunExecutionInputSchema.fields.permissionId,
-		asset: AuthorizePayrollRunExecutionInputSchema.fields.asset,
-		period: AuthorizePayrollRunExecutionInputSchema.fields.period,
-		items: AuthorizePayrollRunExecutionInputSchema.fields.items,
-		requestKey: optional(AuthorizePayrollRunExecutionInputSchema.fields.requestKey)
-	});
-	runs.authorize.name;
 	//#endregion
 	//#region ../../node_modules/.pnpm/axios@1.17.0/node_modules/axios/lib/helpers/bind.js
 	/**