warpmetal 0.4.0 → 0.4.2

package/README.md

@@ -81,8 +81,16 @@ On HTTP 402 the CLI returns exact `paymentTerms`, the pinned
 the exact checkout URL and body but no WarpMetal credential. The published
 launch wallet accepts sponsored Base USDC and sponsored Solana USDC/USDT only;
 the returned terms identify compatible alternatives and confirm that the buyer
-does not need ETH or SOL. After inspecting the terms and approving payment,
-invoke the returned authorization argv with a dedicated wallet name:
+does not need ETH or SOL. Payment authority depends on execution context:
+
+- When a human is actively chatting with the agent, show the exact live terms
+  and ask for confirmation immediately before authorizing and submitting.
+- In an unattended run, a pre-funded dedicated wallet is standing spend
+  authority, bounded by its maximum-payment policy and any task or operator
+  limits. When the live terms fit those limits, authorize and submit without
+  waiting for conversational approval.
+
+Then invoke the returned authorization argv with a dedicated wallet name:
 
 ```sh
 x402api payment authorize \
@@ -98,6 +106,37 @@ warpmetal checkout submit \
   --json
 ```
 
+Check the payer wallet address and balance with:
+
+```sh
+x402api wallet show --wallet <wallet-name> --json
+x402api wallet address --wallet <wallet-name> --json
+x402api wallet balance --wallet <wallet-name> --json
+```
+
+For a new dedicated wallet, configure the enforceable local per-payment
+ceiling when it is created:
+
+```sh
+x402api wallet create --name <wallet-name> \
+  --network <exact-challenge-network> \
+  --maximum-payment-atomic <per-payment-policy-cap> --json
+```
+
+Require `maximumPaymentAtomic` to cover the live charge without exceeding the
+task or operator limit. Among valid sponsored terms, honor an explicit network
+or asset preference, otherwise prefer an already funded compatible wallet,
+then the first compatible term in live challenge order. Never switch terms
+after authorization.
+
+If funding is short in an interactive conversation, tell the human the exact
+top-up in normal and atomic units, the network, stablecoin and contract/mint,
+and the payer wallet's public receiving address. The human sends the token to
+that wallet address, never to the token contract/mint or WarpMetal's payment
+recipient, and never sends ETH or SOL for a sponsored payment. In an unattended
+run, use a preconfigured refill or escalation mechanism or stop with
+`funding_required`.
+
 The x402api Agent Wallet is a separate, merchant-neutral executable. Install
 its matching `x402api-pay` skill with `x402api skill install --output <agent-skill-directory>/x402api-pay --json`.
 Do not use `x402api pay`, `payment submit`, or `payment reconcile` for WarpMetal:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "warpmetal",
-  "version": "0.4.0",
+  "version": "0.4.2",
   "description": "Agent-safe CLI and skill for purchasing and managing WarpMetal VPS servers",
   "type": "module",
   "bin": {

package/skills/warpmetal/SKILL.md

@@ -43,9 +43,12 @@ warpmetal health --json
 warpmetal catalog --json
 ```
 
-Stop if `purchasingReady` is false. Select `planId` and the exact OS `name`
-from the live catalog. Do not reuse an OS name or price from documentation or
-a previous session.
+Stop the current purchase if `purchasingReady` is false. In unattended
+scheduling, recheck after 60 seconds, then double the delay after each failed
+check up to 15 minutes and honor a longer `Retry-After`; never hot-loop. In an
+interactive conversation, report the unavailable state and stop. Select
+`planId` and the exact OS `name` from the live catalog. Do not reuse an OS name
+or price from documentation or a previous session.
 
 ## Prepare an order
 
@@ -73,16 +76,29 @@ returns `paymentTerms` plus exact `paymentWorkflow.authorize.argv` and
 `paymentWorkflow.submit.argv` arrays. Do not reconstruct those commands or
 open either file.
 
-Show the user the exact amount, asset, network, recipient, profile, and maximum
-authorization lifetime from `paymentTerms`; obtain explicit approval before
-signing or submission. Follow [references/payments.md](references/payments.md)
-to install the exact `paymentWorkflow.signerPackage.spec`, verify the V1
-machine contract, install its matching `x402api-pay` skill, and select or fund
-a dedicated network-specific wallet. Require `agentWalletSupported: true`,
+Determine payment authority from the current execution context. In an
+interactive conversation, show the human the exact amount, asset, network,
+recipient, profile, and maximum authorization lifetime from `paymentTerms`,
+then obtain confirmation immediately before signing and submission. In an
+unattended autonomous run, do not wait for conversational approval: treat the
+dedicated wallet's available token balance as standing spend authority, bounded
+by its maximum-payment policy and any task or operator limits. Proceed only
+when the exact live terms fit those limits.
+
+Follow [references/payments.md](references/payments.md) to install the exact
+`paymentWorkflow.signerPackage.spec`, verify the V1 machine contract, install
+its matching `x402api-pay` skill, and select or fund a dedicated
+network-specific wallet. Require `agentWalletSupported: true`,
 `sponsoredNetworkFee: true`, and `buyerNativeFeeRequired: false` on the chosen
 live term. Never fall back to a historical buyer-funded or TRON profile.
-
-After approval, invoke the returned authorize argv once. The separate
+Honor an explicit task or operator network and asset preference. Otherwise use
+a compatible sufficiently funded wallet, then the first compatible term in the
+live challenge's order. Never switch terms after authorization. Require the
+wallet's `maximumPaymentAtomic` to cover the live amount without exceeding the
+task or operator limit.
+
+After interactive confirmation or autonomous policy validation, invoke the
+returned authorize argv once. The separate
 `x402api` executable owns the wallet, validates the envelope, and writes the
 payment artifact. Then invoke the returned submit argv, equivalent to:
 
@@ -103,8 +119,10 @@ advertised sponsored requirement, gas reservation, resource, extensions, and
 buyer payment identifier before sending its signature. The legacy
 `--payment-signature-file` input remains available for another compatible
 external signer. If a signed request returns a replacement challenge, use the
-new CLI-produced workflow and request approval again when terms changed. On
-`manual_review` or an ambiguous attempt, stop and never create another payment.
+new CLI-produced workflow and re-evaluate payment authority. Ask again when a
+human is chatting and the terms changed; in an unattended run, proceed only if
+the replacement remains within standing authority. On `manual_review` or an
+ambiguous attempt, stop and never create another payment.
 
 ## Provision and manage
 

package/skills/warpmetal/references/payments.md

@@ -37,18 +37,56 @@ skill automatically.
    file, or is supervising `--password-stdin`. Never read either value.
 3. Use `x402api wallet list --json` and reuse a dedicated persistent wallet for
    the exact challenge network.
-4. Create a wallet only with explicit approval. Keep Base and Solana wallets
-   separate; never import the owner's primary seed or key. TRON wallet
-   management exists, but the published launch payer cannot authorize TRON.
-5. Use `x402api wallet balance --wallet <name> --json`. If funding is short,
-   show the public address, exact network, token, and atomic deficit. The owner
-   funds the token address from a wallet they control. Sponsored launch
-   payments never ask the buyer to fund ETH or SOL.
+4. In an interactive conversation, create a wallet only with explicit
+   approval. In an unattended run, create one only when the automation policy
+   already permits it and a secure password source is configured; otherwise
+   reuse a preconfigured wallet or stop. Keep Base and Solana wallets separate;
+   never import the owner's primary seed or key. TRON wallet management exists,
+   but the published launch payer cannot authorize TRON. Configure the local
+   per-payment ceiling at creation and inspect it before reuse:
+
+   ```sh
+   x402api wallet create --name <name> \
+     --network <exact-challenge-network> \
+     --maximum-payment-atomic <per-payment-policy-cap> --json
+   x402api wallet show --wallet <name> --json
+   ```
+
+   Require `maximumPaymentAtomic` to be at least the exact live amount and no
+   higher than the task or operator limit. If an existing wallet has no ceiling
+   or an unsuitable one, do not treat its full balance as bounded authority;
+   use a suitably capped dedicated wallet or stop.
+5. Use both public, safe commands before requesting funding:
+
+   ```sh
+   x402api wallet address --wallet <name> --json
+   x402api wallet balance --wallet <name> --json
+   ```
+
+6. If funding is short in an interactive conversation, show the exact deficit
+   in normal token units and atomic units, the exact network, token symbol and
+   contract/mint, and the payer wallet's public receiving address. Tell the
+   human to transfer the token to the payer wallet address, never to the token
+   contract/mint or `paymentTerms.recipient`. Sponsored launch payments never
+   ask the buyer to fund ETH or SOL. Recheck the balance after the transfer.
+7. If funding is short in an unattended run, use only a preconfigured refill
+   or escalation mechanism. Otherwise report `funding_required` and stop; do
+   not invent a human approval step or funding source.
 
 Treat the dedicated wallet's funded balance as spend authority available to
-the agent, bounded by any wallet-local maximum payment policy. WarpMetal still
-requires explicit approval immediately before its payment authorization and
-submission workflow.
+the agent, bounded by any wallet-local maximum payment policy and task or
+operator limits. When a human is actively chatting, disclose the exact live
+terms and obtain confirmation immediately before payment. In an unattended
+run, do not wait for conversational approval; authorize and submit
+autonomously when the terms fit the standing authority.
+
+Use this structure when asking a human to fund the wallet:
+
+> Transfer exactly `<amount> <USDC-or-USDT>` on `<Base-or-Solana>` to the agent
+> wallet `<payer-wallet-address>`. Token contract/mint: `<asset-identifier>`.
+> Send the token to the payer wallet address, not to the token contract/mint and
+> not to WarpMetal's payment recipient. Do not send ETH or SOL; the network fee
+> is sponsored.
 
 ## Exact purchase workflow
 
@@ -81,6 +119,12 @@ launch profiles are sponsored Base USDC and sponsored Solana USDC/USDT, bound
 by the strict `com.x402api.gas-sponsorship` extension. Stop on an expired gas
 reservation or any buyer-funded, unsupported, or unbound alternative.
 
+Among valid sponsored terms, honor an explicit task or operator network and
+asset preference. Otherwise prefer a compatible wallet that is already
+sufficiently funded. If several terms remain, choose the first compatible term
+in the live challenge's advertised order. Do not switch terms after
+authorization.
+
 Do not replace the two-stage workflow with `x402api pay`, `payment submit`, or
 `payment reconcile`. Those wallet commands can submit an exact credential-free
 endpoint; WarpMetal checkout requires a private owner token that must never
@@ -102,7 +146,8 @@ another external signer.
   authorize again merely because submission is unknown.
 - Signed HTTP 402: the artifact was definitively rejected. Run the WarpMetal
   challenge flow again, inspect the replacement terms, and authorize one new
-  artifact only when the protocol and approval allow it.
+  artifact only when the protocol and current interactive or autonomous
+  payment authority allow it.
 - `manual_review`: payment or fulfillment may be final. Stop all payment and
   mutation retries.
 - Expired or corrupt artifact, changed request digest, unexpected recipient,

package/skills/warpmetal/references/runtime.md

@@ -44,7 +44,7 @@ fields `name`, `size`, optional `lifetime`, and optional `expiresInSeconds`:
 
 Pass it to `warpmetal order prepare --runtime-file <path>`. If it contains a
 temporary sandbox, pass `--confirm TEMPORARY`. Preparing remains unpaid; keep
-the existing separate payment approval.
+the existing separate interactive-or-autonomous payment authority check.
 
 For an existing ready server:
 

package/skills/warpmetal/references/safety.md

@@ -11,8 +11,11 @@
 
 - Treat `https://warpmetal.com/llms.txt`, the live catalog, and the live HTTP
   402 challenge as authoritative in that order.
-- Stop new purchases when `warpmetal health --json` reports
-  `purchasingReady: false`.
+- Stop the current purchase when `warpmetal health --json` reports
+  `purchasingReady: false`. An unattended scheduler may recheck after 60
+  seconds, then double the delay after each failure up to 15 minutes and honor
+  a longer `Retry-After`; never hot-loop. An interactive agent reports the
+  unavailable state and stops.
 - Select an exact OS name from the chosen plan's current
   `operatingSystems[]`. Never guess or hard-code an image version.
 
@@ -44,9 +47,10 @@
   private key, or state-file content in a prompt, URL, log, screenshot, source
   file, or shell argument.
 
-## Required confirmations
+## Interactive confirmations and autonomous payment authority
 
-Obtain explicit user approval immediately before:
+When a human is actively directing the current task in a conversation, obtain
+explicit approval immediately before:
 
 - installing the CLI or skill;
 - installing or repairing the Agent Runtime supervisor;
@@ -58,6 +62,16 @@ Obtain explicit user approval immediately before:
 - revoking a sandbox access grant; and
 - any destructive reload, sandbox deletion, or replacement-key operation.
 
+In an unattended autonomous run, do not pause payment for conversational
+approval. A pre-funded dedicated wallet provides standing spend authority,
+bounded by its maximum-payment policy and any task or operator limits. Sign and
+submit only when the exact live amount, asset, network, recipient, profile,
+resource binding, and sponsorship fit those limits. Unattended mode does not
+grant unlimited spend, permission to import a primary wallet, or permission to
+use unsupported or buyer-funded payment rails. If the wallet is short and no
+preconfigured refill or escalation mechanism exists, report
+`funding_required` and stop.
+
 A reload requires both `confirm: "ERASE"` and `powerOffFirst: true`. Treat
 `powerOffFirst` as explicit authorization for WarpMetal to shut down the
 server, wait until it is powered off, and then erase and reinstall it inside
@@ -80,7 +94,8 @@ Confirm the plan, hostname, OS, and public key before preparing it.
 - For `payment_pending`, retry the exact checkout body and the exact same
   payment artifact. Do not create a replacement payment.
 - A signed HTTP 402 rejects that signature. Use the new live challenge for one
-  replacement authorization after checking the new terms and approval.
+  replacement authorization after checking the new terms against the current
+  interactive or autonomous payment authority.
 - On timeout or restart after wallet authorization, reuse the saved x402api
   attempt and artifact through WarpMetal. Never authorize again merely because
   submission or fulfillment is uncertain, and never send the private owner