@bnbagent/studio-cli 0.0.14-alpha.3 → 0.0.14-alpha.5

package/README.md

@@ -316,7 +316,7 @@ This package is licensed under Apache-2.0 and provided **as is**, without warran
 
 ### CreateOS (NodeOps)
 
-Studio pins deploy 0.6.2 and loads its published Node.js SDK. Configure the agent:
+Studio pins deploy 0.6.3 and loads its published Node.js SDK. Configure the agent:
 
 ```toml
 [deploy.nodeops]
@@ -339,6 +339,6 @@ bag deploy destroy --provider nodeops                 # preview
 bag deploy destroy --provider nodeops --execute --yes # delete project
 ```
 
-Account mode supports ZIP/container deployment, runtime secrets and updates. An unhealthy endpoint makes deploy exit nonzero while preserving `.studio/deployments/nodeops.json`; inspect logs and retry verification. Wallet runtime variables use `settings.runEnvs` through the pinned deploy 0.6.2; the pinned SDK 0.5.7-alpha.2 supports BSC nested Permit2 signing with explicit policy opt-in. The Studio bridge now supports bounded approval transactions with an explicit gas budget during authorized payments. Hosting renewal is not yet integrated. `bag deploy wallet --json` reads Gateway chains and USDC balances without signing or paying. CreateOS uses NodeOps infrastructure; AWS and Azure providers deploy into your own cloud account.
+Account mode supports ZIP/container deployment, runtime secrets and updates. An unhealthy endpoint makes deploy exit nonzero while preserving `.studio/deployments/nodeops.json`; inspect logs and retry verification. Wallet runtime variables use `settings.runEnvs` through the pinned deploy 0.6.3; the pinned SDK 0.5.7-alpha.2 supports BSC nested Permit2 signing with explicit policy opt-in. The Studio bridge now supports bounded approval transactions with an explicit gas budget during authorized payments. Hosting renewal is not yet integrated. `bag deploy wallet --json` reads Gateway chains and USDC balances without signing or paying. CreateOS uses NodeOps infrastructure; AWS and Azure providers deploy into your own cloud account.
 
 The installed skill includes `references/bnbagent-studio-use-createos.md` with configuration, capability limits and recovery steps.

package/dist/bag.js

@@ -72,7 +72,7 @@ import {
   x402SellerIsFree,
   x402SellerPricingState,
   x402SellerUsesB402
-} from "./chunk-YYT75RJ2.js";
+} from "./chunk-WB5Q4NAP.js";
 import {
   validateAgentcoreName
 } from "./chunk-U7IDQ3K5.js";
@@ -771,7 +771,7 @@ import {
 var CAMPAIGN_DOC_URL = "https://www.bnbchain.org/en/blog/bnb-agent-studio-is-live-on-bnb-chain-ai-agents-from-one-prompt";
 var CAMPAIGN_CHECK_TIMEOUT_MS = 6e3;
 async function fetchCampaignActive() {
-  const { bnbPlatformApiUrl: bnbPlatformApiUrl2 } = await import("./deployCli-63QLUHXM.js");
+  const { bnbPlatformApiUrl: bnbPlatformApiUrl2 } = await import("./deployCli-LWBTA7X3.js");
   const controller = new AbortController();
   const timer = setTimeout(() => controller.abort(), CAMPAIGN_CHECK_TIMEOUT_MS);
   try {
@@ -3612,9 +3612,13 @@ async function signNodeOpsApproval(wallet, tx, policy) {
     "gas",
     "gasPrice",
     "data",
-    "from"
+    "from",
+    "account",
+    "chain"
   ]);
-  if (Object.entries(tx).some(([k, v]) => v !== void 0 && !fields.has(k)) || tx.chainId !== 56 || tx.type !== "legacy" || typeof tx.to !== "string" || tx.to.toLowerCase() !== USDC.toLowerCase() || tx.from !== void 0 && String(tx.from).toLowerCase() !== wallet.address.toLowerCase() || tx.value !== void 0 && tx.value !== 0n || !Number.isSafeInteger(tx.nonce) || Number(tx.nonce) < 0 || typeof tx.gas !== "bigint" || tx.gas <= 0n || typeof tx.gasPrice !== "bigint" || tx.gasPrice <= 0n || tx.gas * tx.gasPrice > BigInt(policy.maxApprovalGasWei) || typeof tx.data !== "string")
+  if (Object.entries(tx).some(([k, v]) => v !== void 0 && !fields.has(k)) || tx.chainId !== 56 || tx.chain !== void 0 && (tx.chain === null || typeof tx.chain !== "object" || tx.chain.id !== 56) || tx.account !== void 0 && String(
+    typeof tx.account === "string" ? tx.account : tx.account?.address
+  ).toLowerCase() !== wallet.address.toLowerCase() || tx.type !== "legacy" || typeof tx.to !== "string" || tx.to.toLowerCase() !== USDC.toLowerCase() || tx.from !== void 0 && String(tx.from).toLowerCase() !== wallet.address.toLowerCase() || tx.value !== void 0 && tx.value !== 0n || !Number.isSafeInteger(tx.nonce) || Number(tx.nonce) < 0 || typeof tx.gas !== "bigint" || tx.gas <= 0n || typeof tx.gasPrice !== "bigint" || tx.gasPrice <= 0n || tx.gas * tx.gasPrice > BigInt(policy.maxApprovalGasWei) || typeof tx.data !== "string")
     throw new Error(
       "Rejected a transaction outside the bounded BSC USDC approval policy."
     );
@@ -9041,7 +9045,7 @@ function requireDurablePassword(projectRoot) {
   const persisted = getEnvVar(envPath, PASSWORD_ENV2);
   if (!persisted) {
     throw new Error(
-      `refusing to create a keystore with an unpersisted ${PASSWORD_ENV2}. Edit ${envPath}, set ${PASSWORD_ENV2} there, and retry; do not pass wallet passwords on the command line.`
+      `refusing to create a keystore with an unpersisted ${PASSWORD_ENV2}. For a new wallet/import, add --save-password to privately save the current shell password in ${envPath}, or use --generate-password to generate one. Do not pass wallet passwords on the command line.`
     );
   }
   if (persisted !== password) {
@@ -9101,6 +9105,9 @@ function registerWallet(program) {
   ).option(
     "--generate-password",
     "For a new evm-local wallet, generate a CSPRNG password and persist it privately before creating the keystore."
+  ).option(
+    "--save-password",
+    "For a new evm-local wallet/import, privately persist WALLET_PASSWORD from the current shell; never accepts a password argument."
   ).option("--project-root <path>", "Override project root.").action(
     act(
       wrap2(
@@ -9219,6 +9226,11 @@ async function createProjectWallet(opts, projectRoot) {
     walletCfg = loadWalletCfg(projectRoot);
   }
   const kind = walletKind(walletCfg);
+  if (opts.savePassword && (kind !== "evm-local" || opts.generatePassword)) {
+    throw new Error(
+      "--save-password requires evm-local and cannot be combined with --generate-password."
+    );
+  }
   if (kind === "twak") {
     return cmdNewTwak(projectRoot, walletCfg);
   }
@@ -9263,13 +9275,24 @@ async function createProjectWallet(opts, projectRoot) {
     );
     return 1;
   }
+  if (opts.savePassword && (anchored || existingKeystores.length)) {
+    throw new Error(
+      "--save-password is only for a new wallet/import; use the existing wallet's original saved password."
+    );
+  }
   const privateKey = await resolvePrivateKeyArg(opts.privateKey);
   const priorPersistedPassword = getEnvVar(
     envLocalPath10(projectRoot),
     PASSWORD_ENV2
   );
-  const password = opts.generatePassword ? generateLocalWalletPassword() : requireDurablePassword(projectRoot);
-  if (opts.generatePassword) {
+  const password = opts.generatePassword ? generateLocalWalletPassword() : opts.savePassword ? requirePassword2() : requireDurablePassword(projectRoot);
+  if (opts.savePassword && priorPersistedPassword && priorPersistedPassword !== password) {
+    throw new Error(
+      "Refusing to replace a different saved WALLET_PASSWORD; make the existing durable password authoritative first."
+    );
+  }
+  const savedPassword = opts.generatePassword || opts.savePassword;
+  if (savedPassword) {
     setEnvVar(privateEnvPath(projectRoot), PASSWORD_ENV2, password);
   }
   let provider;
@@ -9288,7 +9311,7 @@ async function createProjectWallet(opts, projectRoot) {
     } catch {
       walletWasWritten = false;
     }
-    if (opts.generatePassword && !walletWasWritten) {
+    if (savedPassword && !walletWasWritten) {
       setEnvVar(
         privateEnvPath(projectRoot),
         PASSWORD_ENV2,
@@ -9301,12 +9324,12 @@ async function createProjectWallet(opts, projectRoot) {
     persistAddress(projectRoot, provider.address, opts.keystoreDir);
   } catch (cause) {
     throw new Error(
-      "The wallet and its password were saved, but writing the address to studio.toml failed. Restore file permissions, then run `bag wallet new` without --generate-password to adopt the saved wallet.",
+      "The wallet and its password were saved, but writing the address to studio.toml failed. Restore file permissions, then run `bag wallet new` without --generate-password or --save-password to adopt the saved wallet.",
       { cause }
     );
   }
   printOut(provider.address);
-  if (opts.generatePassword) {
+  if (savedPassword) {
     printErr(
       `Password stored (0600): ${envLocalPath10(projectRoot)} (WALLET_PASSWORD)`
     );
@@ -15177,7 +15200,7 @@ async function loadNodeOpsSdk() {
       ).resolve("@bnbagent/deploy-provider-nodeops/sdk");
     } catch {
       throw new Error(
-        "Installed deploy package lacks the NodeOps Node.js SDK. Reinstall Studio with its pinned @bnbagent/deploy-cli 0.6.2 dependency."
+        "Installed deploy package lacks the NodeOps Node.js SDK. Reinstall Studio with its pinned @bnbagent/deploy-cli 0.6.3 dependency."
       );
     }
   }
@@ -15628,7 +15651,7 @@ async function inspectNodeOpsWallet(root, deps = {}) {
   const sdk = await (deps.sdk ?? loadNodeOpsSdk)();
   if (!sdk.createGatewayWalletClient)
     throw new Error(
-      "The installed deploy SDK lacks Gateway wallet queries. Reinstall Studio with its pinned deploy 0.6.2 dependency."
+      "The installed deploy SDK lacks Gateway wallet queries. Reinstall Studio with its pinned deploy 0.6.3 dependency."
     );
   const address = cfg.options.walletAddress ?? (deps.wallet ?? getWallet3)().address;
   if (typeof address !== "string" || !address)
@@ -19266,7 +19289,7 @@ function resolveTarget(opts, root, destination = agentDeployDestination(root)) {
   return readStackRuntime(root) ?? "agentcore";
 }
 function validateRuntimeAgainstStack(target, force, root) {
-  if (target === "platform" || target === "platform-azure") {
+  if (target === "platform" || target === "platform-azure" || target === "nodeops") {
     return null;
   }
   const stackRuntime2 = readStackRuntime(root);
@@ -19800,14 +19823,20 @@ async function cmdDeploy(opts, deployArgs) {
       printErr("error: --backend does not apply to CreateOS");
       return 2;
     }
-    const readiness = await runPrepare({
-      target: "nodeops",
-      projectRoot: root
-    });
-    if (readiness.exitCode() !== 0) {
-      for (const check of readiness.checks)
-        printErr(`${check.level}: ${check.message}`);
-      return readiness.exitCode();
+    const storageExit = enforceSkipPrepareStorageGate(opts, root, "nodeops");
+    if (storageExit !== null) return storageExit;
+    if (!opts.skipPrepare) {
+      let readiness = await runPrepare({
+        target: "nodeops",
+        projectRoot: root,
+        force: opts.force
+      });
+      readiness = applyStorageGuard(readiness, root);
+      readiness = bypassBrokenStorageIfForced(opts, readiness, root);
+      if (readiness.exitCode() !== 0) {
+        renderPrepareHuman(readiness, true);
+        return readiness.exitCode();
+      }
     }
     try {
       const record2 = await deployNodeOps(root, { pay: opts.pay === true });
@@ -23078,7 +23107,7 @@ function registerEnv(program) {
     "Resolve .env.local under this project root (mirrors `bag config --project-root`); ignored when --file is given."
   ).addHelpText(
     "after",
-    "\nNote: wallet unlock passwords are intentionally REJECTED here \u2014 studio\nnever accepts them as command-line arguments. Keep evm-local in the shell:\n  export WALLET_PASSWORD=...\nFor twak, edit .studio/.env.local yourself and set:\n  TWAK_WALLET_PASSWORD=...\nNever pass either value through chat or argv. See docs/guides/user-guide.md \xA710."
+    "\nNote: wallet unlock passwords are intentionally REJECTED here \u2014 studio\nnever accepts them as command-line arguments. For a NEW evm-local wallet/import,\nread the password privately in your terminal, export WALLET_PASSWORD, then use\n  bag wallet new --save-password\nAdd --private-key to import through a hidden prompt, or --private-key - for stdin.\nFor an existing wallet, keep its original password in the owner-only .studio/.env.local.\nFor twak, edit .studio/.env.local yourself and set:\n  TWAK_WALLET_PASSWORD=...\nNever pass either value through chat or argv. See docs/guides/user-guide.md \xA710."
   ).action(
     act(
       (key, value, opts) => cmdSet2(key, value, opts.file, opts.projectRoot)
@@ -23119,7 +23148,7 @@ function resolveEnvPath(fileArg, rootArg) {
 }
 function cmdSet2(key, value, fileArg, rootArg) {
   if (WALLET_PASSWORD_KEYS.has(key)) {
-    let guidance = "Set it for this shell instead:\n  export WALLET_PASSWORD=...\n\u2014 every `bag` command reads it from the environment.";
+    let guidance = "For a NEW evm-local wallet/import, read the password privately in your terminal, export WALLET_PASSWORD, then run `bag wallet new --save-password` (add --private-key for a hidden key prompt, or --private-key - for stdin). For an existing wallet, keep its original password in the owner-only .studio/.env.local. Never replace an existing wallet password.";
     if (key === "TWAK_WALLET_PASSWORD") {
       guidance = "Edit .studio/.env.local yourself and add:\n  TWAK_WALLET_PASSWORD=...";
     }

package/dist/{chunk-YYT75RJ2.js → chunk-WB5Q4NAP.js}

@@ -947,8 +947,8 @@ function packageRoot() {
   }
 }
 function studioCliVersion() {
-  if ("0.0.14-alpha.3") {
-    return "0.0.14-alpha.3";
+  if ("0.0.14-alpha.5") {
+    return "0.0.14-alpha.5";
   }
   const file = path4.join(packageRoot(), "package.json");
   const pkg = JSON.parse(fs4.readFileSync(file, "utf-8"));
@@ -1230,7 +1230,7 @@ function isTable(value) {
 }
 
 // src/cli/_deploy/deployCli.ts
-var DEPLOY_CLI_VERSION = "0.6.2";
+var DEPLOY_CLI_VERSION = "0.6.3";
 var DEPLOY_CLI_PACKAGE = `@bnbagent/deploy-cli@${DEPLOY_CLI_VERSION}`;
 var require2 = createRequire(import.meta.url);
 function resolveLocalDeployCli() {

package/dist/{deployCli-63QLUHXM.js → deployCli-LWBTA7X3.js}

@@ -21,7 +21,7 @@ import {
   runPlatformAccountCommand,
   trialFromDeployCliJson,
   withDeployFiles
-} from "./chunk-YYT75RJ2.js";
+} from "./chunk-WB5Q4NAP.js";
 export {
   BNB_PLATFORM_API_URL,
   BNB_PLATFORM_API_URL_ENV,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bnbagent/studio-cli",
-  "version": "0.0.14-alpha.3",
+  "version": "0.0.14-alpha.5",
   "description": "Skills-first toolkit and bag CLI for BNB Chain seller agents: ERC-8004 identity, ERC-8183 escrowed commerce, and x402 payments.",
   "keywords": [
     "bnb-chain",
@@ -42,7 +42,7 @@
     "bag": "./dist/bag.js"
   },
   "dependencies": {
-    "@bnbagent/deploy-cli": "0.6.2",
+    "@bnbagent/deploy-cli": "0.6.3",
     "@bnbagent/sdk": "0.5.7-alpha.2",
     "ai": "^7.0.29",
     "archiver": "^8.0.0",
@@ -55,7 +55,7 @@
     "tar": "^7.4.0",
     "viem": "^2.56.3",
     "yaml": "^2.9.0",
-    "@bnbagent/studio-runtime": "0.0.14-alpha.3"
+    "@bnbagent/studio-runtime": "0.0.14-alpha.5"
   },
   "devDependencies": {
     "@a2a-js/sdk": "^0.3.14",

package/skills/bnbagent-studio.md

@@ -36,7 +36,7 @@ One deployed runtime, one signer: a single valuable Agent serves the selected fa
 | Implement what the Agent sells, tune pricing, publish over A2A and/or MCP, defend disputes (seller flow) | `references/bnbagent-studio-selling-via-8183.md` |
 | Sell one paid or FREE HTTP request through the selected B402-backed x402 or MPP rail (pricing choice; paid merchant application, RSA key, credentials, IP allowlist, activation) | `references/bnbagent-studio-selling-via-b402.md` |
 | Deploy / redeploy / status / logs / destroy | Run `bag deploy` and explicitly choose a provider. Non-interactive deploy requires `--provider bnb\|aws\|azure\|nodeops --yes` (and `--allow-multiple` when keeping another provider active). Read `references/bnbagent-studio-use-bnb-trial.md`, `references/bnbagent-studio-use-aws-agentcore.md`, `references/bnbagent-studio-use-azure-foundry.md`, or `references/bnbagent-studio-use-createos.md` for the selected provider. `bag deploy status` lists every recorded provider; multi-deployment logs/verify/destroy require `--provider`. |
-| CreateOS / NodeOps account or wallet deployment, wallet balances, health failure, payment recovery | Read `references/bnbagent-studio-use-createos.md`. Prefer account mode for seller agents; check wallet secret/signing limits before any payment. |
+| Build an agent and deploy it to NodeOps; CreateOS account/wallet deployment, wallet balances or payment recovery | Read `references/bnbagent-studio-use-createos.md` first; also read the scaffolding reference for a new project. Use its task-completion flow to select compatible defaults, honor an explicit hosting-payment protocol and verify the deployed business operation. |
 | Wire chain-read tools into the Agent's LLM (AI SDK `tool()` wrappers, or any TS agent framework) | `references/bnbagent-studio-wiring-llm-tools.md` |
 | Buy a service from another ERC-8183 seller via CLI - incl. testing your own seller from the buyer side (v2/internal - NOT the v1 seller product flow) | `references/bnbagent-studio-buying-via-8183.md` |
 | Give the agent a PAID x402 capability - CMC market data / Binance Bazaar (B402) merchants / any pay-per-call API (`bag x402 trust`, x402-buyer recipe, 402 buyer errors) | `references/bnbagent-studio-buying-from-bazaar.md` |
@@ -58,7 +58,7 @@ Next to this file: this skill installs as a directory with a `references/` subdi
 ## 5 core commitments (always honor)
 
 1. **Agent project code is user-owned** - recipe-emitted files are theirs to edit; studio doesn't auto-rewrite them.
-2. **Private keys live in a user-controlled environment, never transmitted to studio or third parties** - the encrypted keystore lives at the workspace root, outside the deploy codeLocation (no packaging path can bundle it). Altana keeps its admin keystore there and gives the runtime only a bounded session — local `bag dev` and deploy both receive the session (`ALTANA_SESSION`), never the admin keystore. Other supported deploy paths inject only their required wallet material into the selected runtime secret channel. (Scoped, consented exception: provider `bnb`, the 48h testnet trial - testnet-forced, throwaway wallet recommended.)
+2. **Keep wallet material out of chat, source and build artifacts; describe the runtime custody boundary accurately.** The encrypted keystore lives at the workspace root, outside the deploy codeLocation. Payment integrations use public signing interfaces without private-key export. Deploying an evm-local agent separately sends its encrypted keystore and unlock password to the selected runtime through the provider's runtime-secret channel, so that runtime can sign. NodeOps hosts that runtime on third-party infrastructure in both account and wallet modes; do not promise that its operator never receives usable wallet material. Use an existing wallet only within the user's authorized custody scope; otherwise prepare a dedicated deployment wallet and explain funding requirements. Altana's supported runtime paths receive only `ALTANA_SESSION`, not the local admin keystore; this does not make Altana compatible with NodeOps hosting payment. The BNB trial remains testnet-only with a throwaway wallet recommended.
 3. **Signing is fixed handler code, never an LLM-callable tool** - the ERC-8183 rail exposes bounded `negotiate` / `notify_funded` flows and the x402 rail exposes a bounded request handler; raw/arbitrary signing is never exposed. Read-only chain queries remain read-only tools.
 4. **SDK protocol layer stays pure** - studio's opinions don't pollute `bnbagent-sdk`.
 5. **The user can jump ship at any point** - emitted code is theirs to edit / fork / migrate; studio depends on no closed SaaS. Emitted code imports from `@bnbagent/studio-runtime` and depends on that runtime lib (not the CLI), so uninstalling the `@bnbagent/studio-cli` package never breaks a deployed agent.
@@ -67,7 +67,7 @@ Treat ERC-8183 amounts as decimal strings at CLI/config boundaries and `bigint`
 
 ## CLI groups at a glance
 
-`init`, `scan`, `recipe`, `skills`, `wallet`, `erc8004`, `erc8183`, `x402`, `mpp`, `agents`, `config`, `env`, `dev`, `doctor`, `feedback`, `audit`, `deploy`, `platform`, `llm`, `bundle`, `budget` - see `bag --help` for details. `bag deploy [--provider bnb\|aws\|azure\|nodeops] [--backend aws\|azure]` is the primary deploy command; `--backend` is valid only for provider `bnb` and confirms the recipe-derived managed backend. `prepare`, `list`, `verify`, `status`, `info`, `destroy`, `logs`, and `fix-gitignore` remain lifecycle subcommands (`deploy agent` is a deprecated compatibility alias). Provider deploy/status/logs/destroy and deploy-time credential validation are delegated to pinned `@bnbagent/deploy-cli@0.6.2`.
+`init`, `scan`, `recipe`, `skills`, `wallet`, `erc8004`, `erc8183`, `x402`, `mpp`, `agents`, `config`, `env`, `dev`, `doctor`, `feedback`, `audit`, `deploy`, `platform`, `llm`, `bundle`, `budget` - see `bag --help` for details. `bag deploy [--provider bnb\|aws\|azure\|nodeops] [--backend aws\|azure]` is the primary deploy command; `--backend` is valid only for provider `bnb` and confirms the recipe-derived managed backend. `prepare`, `list`, `verify`, `status`, `info`, `destroy`, `logs`, and `fix-gitignore` remain lifecycle subcommands (`deploy agent` is a deprecated compatibility alias). Provider deploy/status/logs/destroy and deploy-time credential validation are delegated to pinned `@bnbagent/deploy-cli@0.6.3`.
 
 ## Tool surface
 

package/skills/references/bnbagent-studio-scaffolding-agent.md

@@ -9,6 +9,8 @@ description: When the user wants to create a brand-new blockchain SELLER from ze
 
 Procedure for **greenfield** seller creation. Audience: Claude Code (or another agent) running in an empty directory with shell + edit access.
 
+For a request that already selects NodeOps, first read `bnbagent-studio-use-createos.md` and follow its build-and-deploy task flow. Its targeted intake and provider choices override the generic form, platform default and AWS-specific provisioning below. Do not make the user complete the full technical questionnaire or confirm a provider they already selected. Use this reference's project-generation mechanics, then return to the NodeOps reference for payment, deployment and business verification.
+
 **Different from** the `bnbagent-studio-adding-to-project.md` reference (in this same references/ directory): that one adds to an existing repo; this one creates from zero.
 
 ## The single seller runtime (current workspace layout)
@@ -164,7 +166,7 @@ Build a TodoWrite list. The shape depends on the `wallet kind`. The canonical 8-
 
      Do not run or explain the upstream `twak setup` wizard. `twak-init` uses the project-pinned binary, runs `twak init --json`, verifies an authenticated read, generates and persists `TWAK_WALLET_PASSWORD`, creates/adopts the project-dedicated no-keychain wallet, and anchors the address. No separate `bag wallet new` step exists. For CI, the user may place `TWAK_ACCESS_ID` + `TWAK_HMAC_SECRET` in `.studio/.env.local` themselves; never route them through chat. Reuse an existing wallet only with explicit `--twak-home <home-style-path>`; `--twak-home ~` is a discouraged opt-in to the main wallet. Load `bnbagent-studio-using-twak-wallet.md` for the exact security and deploy contract.
 
-   - **evm-local** (default): the new-wallet TTY happy path generates `WALLET_PASSWORD` with the OS CSPRNG, persists it privately, then creates the encrypted keystore in-process. After `--no-onboard`, run `(cd app/agent && bag wallet new --generate-password)` for the same non-interactive safe path. It refuses to replace an existing or anchored wallet. For an existing encrypted v3 file, prefer `bag init ... --wallet-kind evm-local --evm-keystore <path>` and use the file's original password; Studio copies and verifies the file without re-encrypting it. To import a raw key, use the hidden `bag wallet new --private-key` prompt or stdin; never pass the key inline.
+   - **evm-local** (default): the new-wallet TTY happy path generates `WALLET_PASSWORD` with the OS CSPRNG, persists it privately, then creates the encrypted keystore in-process. After `--no-onboard`, run `(cd app/agent && bag wallet new --generate-password)` for the same non-interactive safe path. It refuses to replace an existing or anchored wallet. For an existing encrypted v3 file, prefer `bag init ... --wallet-kind evm-local --evm-keystore <path>` and use the file's original password; Studio copies and verifies the file without re-encrypting it. To import a raw key into a new wallet, use `bag wallet new --private-key --generate-password` (hidden key prompt) or `--private-key - --generate-password` (stdin). For a user-selected password, the user privately reads/exports `WALLET_PASSWORD` in their own terminal and replaces `--generate-password` with `--save-password`, which persists it privately and refuses existing wallets or a different saved password. Never pass a key or password inline.
 
 5. **Fund the wallet - OPTIONAL; do NOT block on it.** The default `auto/free` LLM model runs at $0 and AgentCore deploy consumes no wallet balance, so a brand-new seller can scaffold, run `bag dev`, and deploy with an empty wallet. `bag doctor` and `bag deploy` only **WARN** (never block) on zero balance. Funding is needed later only for: a paid LLM model, on-chain settle, paying positive-price ERC-8183 job buys, or buying/smoking a PAID B402 request. A FREE ERC-8183 buy needs no U escrow or ERC-20 approval, but still needs the ERC-8183 state-changing calls and their gas/paymaster path. A FREE B402/x402 request needs neither token funding nor a facilitator call. When funding is needed, the wallet uses **TWO distinct U balances on TWO chains** (same wallet address, same private key, different chains):
    - **tBNB (gas)** on BSC testnet: message the official Telegram bot https://t.me/bnbchain_official_bot with `I would like to get tBNB to my wallet <address>` (up to 0.3 tBNB/day; replies with the tx hash). More options: https://docs.bnbchain.org/bnb-smart-chain/developers/faucet/

package/skills/references/bnbagent-studio-use-aws-agentcore.md

@@ -1,6 +1,6 @@
 ---
 name: bnbagent-studio-use-aws-agentcore
-description: When the user wants to deploy or operate a bnbagent-studio project on AWS Bedrock AgentCore - deploy with `bag deploy --provider aws` (all cloud lifecycle mutations are delegated to pinned `@bnbagent/deploy-cli@0.6.2`), inspect with `bag deploy status` / `logs --provider aws` / `verify --provider aws`, and tear down with `bag deploy destroy --provider aws --execute [--purge]`. Also covers AWS credential prerequisites, the optional read-only quota probe, and the runtime-secret channel.
+description: When the user wants to deploy or operate a bnbagent-studio project on AWS Bedrock AgentCore - deploy with `bag deploy --provider aws` (all cloud lifecycle mutations are delegated to pinned `@bnbagent/deploy-cli@0.6.3`), inspect with `bag deploy status` / `logs --provider aws` / `verify --provider aws`, and tear down with `bag deploy destroy --provider aws --execute [--purge]`. Also covers AWS credential prerequisites, the optional read-only quota probe, and the runtime-secret channel.
 ---
 
 > **Reference file** of the `bnbagent-studio` router skill - installed at `bnbagent-studio/references/` and loaded on demand (not a standalone skill). Route here via the router's decision tree.

package/skills/references/bnbagent-studio-use-azure-foundry.md

@@ -1,6 +1,6 @@
 ---
 name: bnbagent-studio-use-azure-foundry
-description: When the user wants to deploy or operate a bnbagent-studio project on Azure AI Foundry Hosted Agents - scaffold with `bag init --runtime azure-foundry`, deploy either to the managed platform with `bag deploy --provider bnb --backend azure` or directly with `bag deploy --provider azure`; all cloud lifecycle execution is delegated to pinned `@bnbagent/deploy-cli@0.6.2`. Native MCP is not supported on Azure; use AgentCore for MCP.
+description: When the user wants to deploy or operate a bnbagent-studio project on Azure AI Foundry Hosted Agents - scaffold with `bag init --runtime azure-foundry`, deploy either to the managed platform with `bag deploy --provider bnb --backend azure` or directly with `bag deploy --provider azure`; all cloud lifecycle execution is delegated to pinned `@bnbagent/deploy-cli@0.6.3`. Native MCP is not supported on Azure; use AgentCore for MCP.
 ---
 
 > **Reference file** of the `bnbagent-studio` router skill - installed at `bnbagent-studio/references/` and loaded on demand (not a standalone skill). Route here via the router's decision tree.
@@ -31,7 +31,7 @@ Procedure for deploying and operating the seller Agent on **Azure AI Foundry Hos
 
 1. **Bun 1.3+ (`bunx`) on PATH** - the pinned `@bnbagent/deploy-cli` runs through it.
 2. **Docker running** - the image is built locally (linux/amd64) before push.
-3. **An Azure subscription** the operator may provision in (Foundry account/project, container registry, hosted agent). Before a local self-deploy, run `bunx --bun @bnbagent/deploy-cli@0.6.2 login --provider azure`; use OIDC/service-principal credentials in CI.
+3. **An Azure subscription** the operator may provision in (Foundry account/project, container registry, hosted agent). Before a local self-deploy, run `bunx --bun @bnbagent/deploy-cli@0.6.3 login --provider azure`; use OIDC/service-principal credentials in CI.
 
 ## ⚠️ Foundry gotchas (read before deploying)
 

package/skills/references/bnbagent-studio-use-bnb-trial.md

@@ -9,7 +9,7 @@ description: Use when deploying or operating a bnbagent-studio seller on the BNB
 
 Treat this provider as a temporary testnet sandbox. Require a throwaway wallet, keep `bsc-testnet`, and explain that the runtime signing material is transmitted to the operator's managed secret store for the trial. Never use a mainnet key. Exception: `wallet.kind='altana'` ships only the bounded, budget-limited, revocable session - the throwaway-wallet advice does not apply; tighten the session instead (`bag wallet session grant --force --budget-u <small> --expiry-days <short>`) and never run `bag wallet new` on an altana project (it breaks the session's `[wallet].address` anchor).
 
-All auth and cloud lifecycle work must cross the pinned `@bnbagent/deploy-cli@0.6.2` boundary. Do not call a cloud CLI or platform REST routes directly. The managed backend is recipe-derived: `agentcore` uses AWS; `azure-foundry` uses Azure. For headless managed Azure, confirm with `bag deploy --provider bnb --backend azure --yes`; never treat `--backend` as a cross-cloud recipe converter.
+All auth and cloud lifecycle work must cross the pinned `@bnbagent/deploy-cli@0.6.3` boundary. Do not call a cloud CLI or platform REST routes directly. The managed backend is recipe-derived: `agentcore` uses AWS; `azure-foundry` uses Azure. For headless managed Azure, confirm with `bag deploy --provider bnb --backend azure --yes`; never treat `--backend` as a cross-cloud recipe converter.
 
 ## Select and authenticate
 

package/skills/references/bnbagent-studio-use-createos.md

@@ -1,16 +1,54 @@
 ---
 name: bnbagent-studio-use-createos
-description: Deploy and operate Studio agents on CreateOS through the nodeops provider and published deploy 0.6.2 SDK. Covers account credentials, ZIP/container packaging, runtime secrets, health recovery, project lifecycle and wallet payment restrictions.
+description: Deploy and operate Studio agents on CreateOS through the nodeops provider and published deploy 0.6.3 SDK. Covers account credentials, ZIP/container packaging, runtime secrets, health recovery, project lifecycle and wallet payment restrictions.
 ---
 
 # Deploy and operate on CreateOS
 
-Use Studio's `nodeops` provider for NodeOps-hosted infrastructure. AWS and Azure providers remain separate choices for infrastructure in the user's own cloud account. Studio pins `@bnbagent/deploy-cli@0.6.2` and resolves the published `@bnbagent/deploy-provider-nodeops/sdk` through that dependency. No local deploy checkout, source override or Bun process is required for NodeOps.
+Use Studio's `nodeops` provider for NodeOps-hosted infrastructure. AWS and Azure providers remain separate choices for infrastructure in the user's own cloud account. Studio pins `@bnbagent/deploy-cli@0.6.3` and resolves the published `@bnbagent/deploy-provider-nodeops/sdk` through that dependency. No local deploy checkout, source override or Bun process is required for NodeOps.
 
 ## Check the installed CLI
 
 Run `bag --version` and `bag deploy --help`. Confirm that `nodeops` is advertised before following this reference; older Studio releases lack the adapter. If absent, use the main skill's approved upgrade workflow. Do not bypass Studio with a raw provider deployment, because it omits Studio packaging, secrets and resource records.
 
+The generic router's minimum version does not establish NodeOps compatibility. Use the release's documented CLI version with deploy 0.6.3; an alpha may be required while npm `latest` lacks this integration. Do not repeatedly install `latest` without checking its capabilities. Reuse existing installation authorization and verify the selected CLI's version and provider after installation.
+
+## Complete a build-and-deploy request
+
+For requests such as "build a simple agent and deploy it to NodeOps", carry the task through implementation, local testing, deployment and a real business request to the deployed endpoint. Use the scaffolding reference for project mechanics; this section takes precedence over its generic intake form and AWS/platform defaults for a NodeOps task.
+
+- Infer routine technical choices from the request and existing project. Ask only for missing information that affects the outcome: what the agent should do, access/pricing intent when material, unavailable credentials/funding, or an unapproved spending limit. If a useful simple behavior was delegated to you, choose it and state the assumption. Do not require the user to choose a protocol, signer, build transport or cloud architecture. Keep prior authorization; do not repeatedly ask for the same budget approval.
+- Preserve an existing deployment's recorded identity and configuration. For a new project, honor an explicit mode; a request to pay NodeOps with x402 or MPP selects wallet mode. Otherwise reuse a configured account/API Key when available, or use wallet mode. Do not require a CreateOS account merely because the workload is an agent. Account is the suitable existing option when in-place updates or logs are required; do not silently change a wallet choice to obtain those features.
+- For a new wallet-mode project without an explicit payment selection, prefer `evm-local`, BSC USDC and MPP. Preserve an existing compatible wallet and configured chain/protocol. The MPP preference is based on the standalone live probe, not a claim that Studio's full live E2E is already certified. An explicitly requested x402 payment sets `[deploy.nodeops.payment].protocol = "x402"`; never fall back to MPP silently. Check the Gateway's advertised chains and the actual deployment challenge. A missing matching offer is a blocker, not permission to change the payment terms.
+- Use `--destination self --no-onboard` for NodeOps, with ZIP for a compatible Node workload; select Dockerfile source when required by its dependencies. The generated runtime template name does not mean deployment to AWS. NodeOps runs through the Node.js SDK and does not require Bun, AWS credentials or AgentCore provisioning. Keep the agent's business network separate from the hosting-payment chain; BSC USDC hosting payment does not authorize changing the agent's business network or enabling its seller-payment rail.
+- Implement the requested behavior and verify a representative local input/output before paying for deployment. Use the explicit business configuration below instead of the scaffold's paid defaults. A generated stub is not a completed application. Reuse available model/storage configuration and collect missing secrets only through the local secret workflow. Configure an appropriate persistent store if the requested behavior produces durable deliverables; do not claim local filesystem storage is durable cloud storage. Complete the public buyer URL preflight below before submitting any deployment POST.
+- Check the wallet and prepare the artifact with the commands below. Show the estimated/actual hosting cost and enforce the approved caps; example caps are not authorization. Funding and credential entry may require the user's wallet or terminal. Once authorized, complete the deployment and verification without handing ordinary CLI steps back to the user. An unavailable prerequisite should leave a working local implementation and a precise explanation of what remains.
+
+Hosting-payment x402 and selling the agent's service through x402 are separate choices. A request to "pay NodeOps using x402" changes only the hosting-payment configuration. Do not add merchant onboarding or enable a paid seller face on that basis. For an ambiguous "use x402" request, resolve it from context; ask one short clarification only when both interpretations remain plausible. If paid agent service is also requested, read the seller reference and verify its provider prerequisites separately.
+
+### Choose an explicit business interface before initialization
+
+Bare `bag init` defaults to A2A plus a paid B402 face and both commerce rails. Do not inherit those defaults for a request that only authorizes NodeOps hosting payment. Keep an existing project's chosen business interface and prices. For a new project, resolve the intended service access and price from the user's request; if unclear, ask about free versus paid access in product terms, not about protocol internals.
+
+For an A2A seller using ERC-8183 jobs, explicitly pass `--protocols A2A --rails 8183`. For a user-approved zero-price job service, the initialization shape is:
+
+```bash
+bag init <name> --destination self --wallet-kind evm-local --no-onboard \
+  --protocols A2A --rails 8183 --erc8183-price 0 \
+  --network <business-network> --llm-provider <configured-provider> \
+  --storage-provider <configured-store>
+```
+
+Replace the placeholders with the selected business settings. Zero ERC-8183 price removes token escrow, but job creation/funding-state transitions, on-chain gas and deliverable submission still apply; it is not anonymous free HTTP access. For a paid ERC-8183 service, replace `0` with the agreed price in token base units. Do not add `--payment-protocol x402` to select NodeOps hosting payment: that init flag configures the agent's seller face. Set hosting payment only in `[deploy.nodeops.payment]`.
+
+The current NodeOps readiness path rejects an X402/MPP-only B402 business service with `x402_forced_dormant_runtime`, including zero-price mode. Do not recommend `--protocols X402 --rails b402 --b402-price 0` as a working NodeOps shortcut, bypass readiness, or add an unused ERC-8183 rail just to turn a blocker into a warning. If the user requires ordinary anonymous HTTP or a paid B402-only service, complete the local business implementation and identify the missing supported deployment/serving path before incurring hosting costs. NodeOps hosting-payment x402 remains a separate supported adapter path.
+
+### Finish with an operational agent
+
+After `deploy`, use the saved project/deployment IDs to poll status and run `bag deploy verify --provider nodeops --skip-register`. Complete and verify any prearranged domain routing, fetch the Agent Card and check its advertised `url`, then send a representative request through that public business address and check the returned result against the local expectation. Health HTTP 200 and an Agent Card alone do not prove the agent works. For ERC-8183, a successful `negotiate` or `notify_funded` acknowledgement is insufficient: exercise the authorized buyer/job flow through the deliverable result, including gas even for zero token escrow. For paid business requests, use the configured buyer/payment flow within its separately authorized budget; never add a public bypass or disable billing to make verification pass. Register the agent only if requested or already authorized, after verifying its advertised public URL.
+
+Deliver the working URL, a usable request example, the observed business result, deployment identifiers and available payment receipt/cost evidence. If existing credits paid for deployment, say so rather than claiming x402/MPP settlement was exercised. Clearly report any remaining business or payment verification gap. On an uncertain payment or acknowledged deployment failure, follow the recovery rules below; do not start a new paid deployment as a retry. Do not delete a successfully delivered resource as test cleanup unless requested.
+
 ## Account mode for seller agents
 
 Add to `app/agent/studio.toml`:
@@ -40,9 +78,16 @@ Readiness builds and validates a temporary artifact without cloud mutation. ZIP
 
 Redeploying in account mode updates the matching project. If another provider remains active, automation needs `--allow-multiple`. Preserve the account pin when managing an existing project. Studio rejects ambiguous identities rather than selecting one silently.
 
-## Public buyer URL
+## Public buyer URL preflight — before any deploy POST
+
+For the generated A2A card or a business payment challenge, resolve the public base URL before deployment. Set `BNBAGENT_PUBLIC_URL` in workspace `.studio/.env.local` with `bag env set BNBAGENT_PUBLIC_URL <public-base-url>` (no `/x402` or `/mpp` suffix). Studio also supplies it as `AGENTCORE_RUNTIME_URL`. Without it, these generated URLs fall back to localhost; `verify --skip-register` checks HTTP reachability and does not validate the Card's advertised URL. This is a skill preflight requirement, not a check already enforced by the CLI.
+
+- **Account:** reuse a known stable environment URL or an already configured domain where available. If initial provisioning is needed to obtain the address, account mode supports a subsequent configuration/code deployment to the same project. Include that second deployment in the authorized plan and verify the current endpoint afterward; do not call the initial health-only result complete.
+- **Wallet:** the initial deployment's generated URL is not known in advance, and this adapter cannot update runtime variables or redeploy the same project afterward. Use a known user-controlled public hostname only with a concrete, authorized routing plan, such as an existing reverse proxy that can be pointed at the returned service URL after deployment. Configure the hostname in runtime variables before the first upload, then execute and verify that routing after deployment. Do not invent a NodeOps custom-domain API or assume the wallet SDK provisions the hostname.
+
+If wallet mode has neither a usable stable address/routing plan nor an already implemented and tested way for the application to advertise its correct public origin, stop before the deploy POST and explain the missing prerequisite. Keep the local implementation ready. Do not pay first and propose editing local `.env` afterward, redeploy to learn another URL, or silently switch to account mode. A plain health probe may be deployed without discovery for an explicitly scoped infrastructure test, but it is not delivery of the requested operational agent.
 
-Before opening the service to buyers, set `BNBAGENT_PUBLIC_URL` in workspace `.studio/.env.local` to the stable public base URL (without `/x402` or `/mpp`). Studio synchronizes it for payment challenges and also supplies `AGENTCORE_RUNTIME_URL`, the legacy variable used by generated A2A agent cards. Use a stable CreateOS environment URL or your configured domain; a deployment-specific URL can change on the next upload. Studio does not infer a domain or claim that a successful health probe validates the card's advertised URL. After configuring it, deploy the account project and inspect `/.well-known/agent-card.json` before registering the endpoint.
+After deployment, inspect the A2A Card's `url` and any applicable business payment resource URL: they must use the intended public origin, never localhost, a bind address or an unrelated deployment. Exercise that advertised address, not just the provider's generated health URL. Preserve records and report a remaining verification gap if this fails; do not pay for a replacement as recovery.
 
 ## Health, records and recovery
 
@@ -61,9 +106,11 @@ Deletion removes project environments too; registry images and payment history r
 
 Read this section before choosing a wallet for NodeOps. Use `evm-local` for the currently tested Studio signing path. Turnkey implements the required public signing interfaces but still needs provider-specific live acceptance testing. TWAK lacks generic EIP-712 signing; Altana's session `x402.pay` is not wired into Gateway authentication/payment. Do not silently replace an existing wallet to work around these limits.
 
-Studio pins published deploy 0.6.2, which supports runtime credentials through `settings.runEnvs`, independently of the uploaded archive. The 2026-09-10 standalone live probe confirmed Dockerfile deployment, BSC MPP settlement and runtime variable injection; the installed-package integration suite covers the Studio path with injected HTTP responses. These do not establish secret-vault encryption, redaction or variable rotation. If readiness reports an older SDK without runtime variable support, follow the approved CLI upgrade workflow; do not use a source override or embed credentials in the artifact.
+Studio pins published deploy 0.6.3, which supports runtime credentials through `settings.runEnvs`, independently of the uploaded archive. The 2026-09-10 standalone live probe confirmed Dockerfile deployment, BSC MPP settlement and runtime variable injection; the installed-package integration suite covers the Studio path with injected HTTP responses. These do not establish secret-vault encryption, redaction or variable rotation. If readiness reports an older SDK without runtime variable support, follow the approved CLI upgrade workflow; do not use a source override or embed credentials in the artifact.
 
-For a new project, follow the scaffolding reference with `--destination self --wallet-kind evm-local --no-onboard`, install dependencies, and run `(cd app/agent && bag wallet new --generate-password)`. Reuse an initialized wallet instead of generating another. Configure model/storage credentials using the existing local secret workflow; never collect private keys, passwords or API keys in chat. A wallet used to pay NodeOps is not automatically compatible with every runtime wallet backend.
+For evm-local workloads, runtime variables include the encrypted `WALLET_KEYSTORE_JSON` and its `WALLET_PASSWORD`. NodeOps therefore receives the material needed by the deployed agent to unlock and use that wallet. The claim "no private-key export" applies to the hosting-payment signer, not to runtime custody. Explain this boundary when choosing the deployment wallet, honor existing custody authorization and prefer a dedicated wallet for new third-party-hosted agents. Do not display or log the secret payload or imply that keystore encryption keeps it inaccessible to a runtime that also receives the password.
+
+For a new project, use the explicit business-interface initialization above, install dependencies, and run `(cd app/agent && bag wallet new --generate-password)`. To import a raw key with a new generated password, use `bag wallet new --private-key - --generate-password` with the key supplied by the user through stdin. If the user requires their own password, they privately read/export `WALLET_PASSWORD` in their terminal and run `bag wallet new --private-key - --save-password`; the flag persists it in `.studio/.env.local` (0600) and refuses existing wallets or a different saved password. Never put passwords or private keys in argv. Reuse an initialized wallet within its authorized custody scope instead of generating another. Configure model/storage credentials using the existing local secret workflow; never collect private keys, passwords or API keys in chat. A wallet used to pay NodeOps is not automatically compatible with every runtime wallet backend.
 
 Merge the following into `app/agent/studio.toml`. These amounts are example spending caps, **not a NodeOps quote**; use the user's approved limits. Keep existing signing-policy entries.
 
@@ -90,6 +137,20 @@ extra_domains = [[56, "0x000000000022D473030F116dDEE9F6B43aC78BA3"]]
 extra_primary_types = ["PermitWitnessTransferFrom"]
 ```
 
+For a wallet workload that needs a Dockerfile, merge the following into the same `[deploy.nodeops]` table, preserving the payment and signing tables:
+
+```toml
+[deploy.nodeops]
+mode = "wallet"
+packaging = "container"
+build = "remote"
+port = 8080
+```
+
+Provide `app/agent/Dockerfile`, a safe `.dockerignore`, and a process that listens on the configured port. This uploads source for NodeOps to build; do not add account-only `image_repository`, Docker registry credentials, an existing image reference or platform selection. `build="remote"` is required by the wallet SDK and is not inferred from `packaging="container"`. Runtime secrets still travel separately through `settings.runEnvs`, never in the Dockerfile or build context.
+
+For an explicit BSC x402 hosting-payment request, change only `protocol = "mpp"` to `protocol = "x402"` in this example. The BSC USDC token, Permit2 signing policy, bounded approval and spending caps still apply. Deploy handles the `PAYMENT-REQUIRED` challenge and `PAYMENT-SIGNATURE` response; do not route this deployment through the general `bag x402 buy` command. Gateway advertisement and injected-response integration tests cover this option; a real Studio x402 deployment and business invocation still need live acceptance testing.
+
 Studio uses public wallet signing operations, never private-key export. SDK `0.5.7-alpha.2` supports the nested EIP-712 types. BSC payment uses USDC at `0x8AC76a51cc950d9822D68b83fE1Ad97B32Cd580d`, not the U token used for Pieverse/jobs. The wallet needs USDC and, when allowance is insufficient, BNB for gas. `max_approval_gas_wei` explicitly caps a bounded USDC-to-Permit2 approval. Studio signs only chain 56 legacy `approve` transactions to this token and spender, within the approved amount/gas caps; it rejects arbitrary transactions. The approval is available only during an authorized payment (`--pay`, or configured `auto_pay`), not readiness/status. Without that gas option, allowance must already be sufficient.
 
 Run the following from `app/agent`:
@@ -103,11 +164,13 @@ bag deploy status --provider nodeops --json
 bag deploy verify --provider nodeops --skip-register
 ```
 
+`--skip-prepare` skips readiness checks only; the fatal storage guard and deploy SDK validation still run. `--force` does not override fatal storage or wallet signing checks. The explicit `--force-deploy-broken-storage` override permits knowingly deploying broken/local storage with a warning; do not add it merely to get a deployment through. `prepare --provider nodeops` selects the cloud provider, not a local runtime named nodeops.
+
 `deploy wallet` is read-only and reports on-chain USDC. `createosCredits: null` means unknown hosting credits, not zero. Funding and hidden credential entry may require the user's terminal/wallet. Base/Arbitrum require their exact USDC domain and validity-window policy instead of the BSC Permit2 configuration. `RPC_URL_BSC` overrides the default `https://bsc-dataseed.bnbchain.org`; RPC requests have bounded timeouts and do not retry broadcasts automatically.
 
 `--yes` confirms deployment; `--pay` additionally authorizes payment within the caps. An initial deploy POST may consume existing credits and create a project even without a payment challenge. `use_existing_credits` is the separate choice for credits shared by active projects. `auto_pay=true` additionally requires the approved `pay_to` recipient pin. It automates payment when deployment is invoked; it does not schedule renewal.
 
-Wallet deployments are create-only. Use `status` and `verify` after an acknowledged build failure, timeout or uncertain response; retain `.studio/deployments/nodeops.json` and deploy's durable journal under `~/.bnbagent-deploy/nodeops/payments/`. All callers of a wallet must share one journal for budget aggregation and locking. Do not change names, clear the journal or submit another payment to recover an unknown outcome. Logs, existing-image deployment, named-environment management and in-place updates are not exposed by the current wallet adapter.
+Wallet deployments are create-only. Use `status` and `verify` after an acknowledged build failure, timeout or uncertain response; retain `.studio/deployments/nodeops.json` and deploy's durable journal under `~/.bnbagent-deploy/nodeops/payments/`. With deploy 0.6.3, a verified pre-broadcast failure releases the reservation and a retry can resume the same deployment. An ambiguous approval broadcast, a submitted payment, or an old reservation without preparation evidence must remain blocked for reconciliation; missing resource IDs are not proof that payment failed. All callers of a wallet must share one journal for budget aggregation and locking. Do not change names, clear the journal or submit another payment to recover an unknown outcome. Logs, existing-image deployment, named-environment management and in-place updates are not exposed by the current wallet adapter.
 
 ## When the user asks to renew