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

package/dist/bag.js

@@ -72,7 +72,7 @@ import {
   x402SellerIsFree,
   x402SellerPricingState,
   x402SellerUsesB402
-} from "./chunk-YYT75RJ2.js";
+} from "./chunk-NSZXF5VL.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-MG3GJCHM.js");
   const controller = new AbortController();
   const timer = setTimeout(() => controller.abort(), CAMPAIGN_CHECK_TIMEOUT_MS);
   try {

package/dist/{chunk-YYT75RJ2.js → chunk-NSZXF5VL.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.4") {
+    return "0.0.14-alpha.4";
   }
   const file = path4.join(packageRoot(), "package.json");
   const pkg = JSON.parse(fs4.readFileSync(file, "utf-8"));

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

@@ -21,7 +21,7 @@ import {
   runPlatformAccountCommand,
   trialFromDeployCliJson,
   withDeployFiles
-} from "./chunk-YYT75RJ2.js";
+} from "./chunk-NSZXF5VL.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.4",
   "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",
@@ -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.4"
   },
   "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.

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)

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

@@ -11,6 +11,44 @@ Use Studio's `nodeops` provider for NodeOps-hosted infrastructure. AWS and Azure
 
 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.2; 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
 
@@ -63,7 +108,9 @@ Read this section before choosing a wallet for NodeOps. Use `evm-local` for the
 
 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.
 
-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)`. 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`: