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

package/dist/{chunk-CFMETPKS.js → chunk-NSZXF5VL.js}

@@ -947,8 +947,8 @@ function packageRoot() {
   }
 }
 function studioCliVersion() {
-  if ("0.0.14-alpha.2") {
-    return "0.0.14-alpha.2";
+  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"));
@@ -1230,7 +1230,7 @@ function isTable(value) {
 }
 
 // src/cli/_deploy/deployCli.ts
-var DEPLOY_CLI_VERSION = "0.5.15";
+var DEPLOY_CLI_VERSION = "0.6.2";
 var DEPLOY_CLI_PACKAGE = `@bnbagent/deploy-cli@${DEPLOY_CLI_VERSION}`;
 var require2 = createRequire(import.meta.url);
 function resolveLocalDeployCli() {
@@ -1334,6 +1334,10 @@ function providerPassthrough(studio, table4) {
   return { ...raw };
 }
 function buildDeploySpec(root, opts) {
+  if (opts.target === "nodeops/createos")
+    throw new Error(
+      "CreateOS uses its Node.js SDK adapter; generic cloud spec translation is unavailable."
+    );
   const agentRoot = findSubProjectRoot2("agent", root) ?? root;
   const studio = loadStudioToml3(path7.join(agentRoot, "studio.toml"));
   const name = String(
@@ -1727,6 +1731,7 @@ export {
   entryStemOf,
   devPortOf,
   recipeModeOf,
+  buildZip,
   dryRunBundle,
   DEFAULT_B402_PRICE_USD,
   B402_DEVELOPER_ACCOUNT_URL,

package/dist/{deployCli-AVWKY3GN.js → deployCli-MG3GJCHM.js}

@@ -21,7 +21,7 @@ import {
   runPlatformAccountCommand,
   trialFromDeployCliJson,
   withDeployFiles
-} from "./chunk-CFMETPKS.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.2",
+  "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",
@@ -42,8 +42,8 @@
     "bag": "./dist/bag.js"
   },
   "dependencies": {
-    "@bnbagent/deploy-cli": "0.5.15",
-    "@bnbagent/sdk": "0.5.6",
+    "@bnbagent/deploy-cli": "0.6.2",
+    "@bnbagent/sdk": "0.5.7-alpha.2",
     "ai": "^7.0.29",
     "archiver": "^8.0.0",
     "commander": "^15.0.0",
@@ -53,9 +53,9 @@
     "proper-lockfile": "^4.1.2",
     "smol-toml": "^1.3.0",
     "tar": "^7.4.0",
-    "viem": "^2.54.0",
+    "viem": "^2.56.3",
     "yaml": "^2.9.0",
-    "@bnbagent/studio-runtime": "0.0.14-alpha.2"
+    "@bnbagent/studio-runtime": "0.0.14-alpha.4"
   },
   "devDependencies": {
     "@a2a-js/sdk": "^0.3.14",

package/recipes/agent/recipe.toml

@@ -11,7 +11,7 @@ node = [
     # neutral. The agent project's serving deps (@a2a-js/sdk / MCP SDK / ai)
     # come from the runtimes/<R>/ recipe selected at `bag init` time.
     "@bnbagent/studio-runtime",
-    "@bnbagent/sdk@0.5.6",
+    "@bnbagent/sdk@0.5.7-alpha.2",
     "zod@^3.25.0",
 ]
 

package/recipes/mpp-buyer/recipe.toml

@@ -6,7 +6,7 @@ status = "v0.0.x"
 [dependencies]
 node = [
     "@bnbagent/studio-runtime",
-    "@bnbagent/sdk@0.5.6",
+    "@bnbagent/sdk@0.5.7-alpha.2",
     "ai@^7.0.29",
     "zod@^3.25.0",
 ]

package/recipes/runtimes/agentcore/recipe.toml

@@ -32,7 +32,7 @@ node = [
     # BNBAGENT_RUNTIME_SECRET_ID is set (default secretsmanager mode + platform).
     "@aws-sdk/client-secrets-manager@^3.600.0",
     "@bnbagent/studio-runtime",
-    "@bnbagent/sdk@0.5.6",
+    "@bnbagent/sdk@0.5.7-alpha.2",
     # The LLM work hook (generateText + tools) and the model factory.
     "ai@^7.0.29",
     # Tool input schemas (AI SDK tools + MCP registerTool).

package/recipes/runtimes/azure-foundry/recipe.toml

@@ -29,7 +29,7 @@ node = [
     # on either cloud.
     "@aws-sdk/client-secrets-manager@^3.600.0",
     "@bnbagent/studio-runtime",
-    "@bnbagent/sdk@0.5.6",
+    "@bnbagent/sdk@0.5.7-alpha.2",
     # The LLM work hook (generateText + tools) and the model factory
     # (model.ts buildModel — studio.toml [llm] + the provider key env).
     "ai@^7.0.29",

package/recipes/x402-buyer/recipe.toml

@@ -6,7 +6,7 @@ status = "v0.0.x"
 [dependencies]
 node = [
     "@bnbagent/studio-runtime",
-    "@bnbagent/sdk@0.5.6",
+    "@bnbagent/sdk@0.5.7-alpha.2",
     "ai@^7.0.29",   # AI SDK `tool` wrappers around the buyer functions
     "zod@^3.25.0",  # tool input schemas
 ]

package/skills/bnbagent-studio.md

@@ -1,11 +1,11 @@
 ---
 name: bnbagent-studio
-description: The single entry point for bnbagent-studio - a TypeScript CLI (`bag`) for building a blockchain SELLER agent that earns $U on BNB Chain via ERC-8004 + ERC-8183 + an x402 or MPP B402 payment face (Pieverse LLM inside). Load this skill whenever the user works in a bnbagent-studio / `bag` project, or wants to create/scaffold, deploy, run, debug, operate, or monetize such a seller agent (composable A2A, MCP, and alternative X402/MPP faces; BNB Chain trial, AWS AgentCore, or Azure Foundry). All detailed playbooks ship as references/ files inside this skill - route via the decision tree in the body. When invoked with arguments, treat them as the user's intent and route the same way.
+description: The single entry point for bnbagent-studio - a TypeScript CLI (`bag`) for building a blockchain SELLER agent that earns $U on BNB Chain via ERC-8004 + ERC-8183 + an x402 or MPP B402 payment face (Pieverse LLM inside). Load this skill whenever the user works in a bnbagent-studio / `bag` project, or wants to create/scaffold, deploy, run, debug, operate, or monetize such a seller agent (composable A2A, MCP, and alternative X402/MPP faces; BNB Chain trial, AWS AgentCore, Azure Foundry, or CreateOS). All detailed playbooks ship as references/ files inside this skill - route via the decision tree in the body. When invoked with arguments, treat them as the user's intent and route the same way.
 ---
 
 # bnbagent-studio (the single entry point)
 
-`bnbagent-studio` (CLI: `bag`) wires the `@bnbagent/sdk` protocol layer (wallet / ERC-8004 / ERC-8183 / Pieverse LLM) into a TypeScript agent project, then deploys it as a **single blockchain seller runtime**. A2A, MCP, and X402 are composable public faces selected with `--protocols`; every wallet kind scaffolds A2A + X402 with both ERC-8183 and B402 rails by default (for altana the paid B402 payout lands at the admin address). `bag deploy` uses **scheme C**: every new deploy or redeploy explicitly selects BNB, AWS, or Azure; a recorded deployment is used only to offer an explicit update action, never as a silent default. BNB is a 48h testnet trial and is disabled after expiry. AWS and Azure self-deploy into the user's own account. All cloud lifecycle mutations go through the pinned `@bnbagent/deploy-cli`; the optional AWS CLI is used only by the fail-open, read-only AgentCore quota check in `bag deploy prepare`. AgentCore and Azure Foundry share the unified A2A/X402 entrypoint; Azure rejects MCP. Treat an incompatible provider row as unavailable-do not force through it or mutate the scaffold during deploy.
+`bnbagent-studio` (CLI: `bag`) wires the `@bnbagent/sdk` protocol layer (wallet / ERC-8004 / ERC-8183 / Pieverse LLM) into a TypeScript agent project, then deploys it as a **single blockchain seller runtime**. A2A, MCP, and X402 are composable public faces selected with `--protocols`; every wallet kind scaffolds A2A + X402 with both ERC-8183 and B402 rails by default (for altana the paid B402 payout lands at the admin address). `bag deploy` uses **scheme C**: every new deploy or redeploy explicitly selects BNB, AWS, Azure, or CreateOS; a recorded deployment is used only to offer an explicit update action, never as a silent default. BNB is a 48h testnet trial and is disabled after expiry. AWS and Azure self-deploy into the user's own account. All cloud lifecycle mutations go through the pinned deploy packages (NodeOps uses their Node.js SDK); the optional AWS CLI is used only by the fail-open, read-only AgentCore quota check in `bag deploy prepare`. AgentCore and Azure Foundry share the unified A2A/X402 entrypoint; Azure rejects MCP. Treat an incompatible provider row as unavailable-do not force through it or mutate the scaffold during deploy.
 
 Invoked as `/bnbagent-studio <ask>`? Treat `<ask>` as the user's intent and route it through the decision tree below, exactly like a natural-language ask.
 
@@ -35,13 +35,15 @@ One deployed runtime, one signer: a single valuable Agent serves the selected fa
 | Report a CLI problem or share product feedback | Run `bag feedback`, review the local JSON bundle before attaching it, and read `references/bnbagent-studio-operating.md`; Studio never uploads or submits it automatically |
 | 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 --yes` (and `--allow-multiple` when keeping another provider active). Read `references/bnbagent-studio-use-bnb-trial.md`, `references/bnbagent-studio-use-aws-agentcore.md`, or `references/bnbagent-studio-use-azure-foundry.md` for the selected provider. `bag deploy status` lists every recorded provider; multi-deployment logs/verify/destroy require `--provider`. |
+| 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`. |
+| 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` |
 | Give the agent a native MPP+B402 buyer capability (`bag mpp trust/quote/buy`, mpp-buyer recipe, recipient/realm pins, unknown outcomes) | `references/bnbagent-studio-buying-via-mpp.md` |
 | Extend the EIP-712 signing allowlist (custom contract / new x402 service / diagnose `PolicyViolation` / `X402PolicyError`) | `references/bnbagent-studio-extending-signing.md` |
 | Project uses `[wallet].kind = "twak"` (create / fund / SIWE-bind / container deploy / known limitations) | `references/bnbagent-studio-using-twak-wallet.md` |
+| NodeOps wallet selection, deployment payment or hosting renewal | Read `references/bnbagent-studio-use-createos.md` before choosing a wallet or promising payment/renewal support. |
 | Project uses `[wallet].kind = "altana"` (admin keystore / bounded session / quote checker / x402 allowance / local dev / session-only deploy + renewal) | `references/bnbagent-studio-using-altana-wallet.md` |
 | (Pieverse projects only) Fund the LLM, switch to a paid model, hit insufficient credits (`PieverseBudgetExhaustedError` / `PieverseAccountBalanceExhaustedError`) | skill `funding-pieverse-llm` (project-scope; emitted at `bag init --llm-provider pieverse-llm`) |
 
@@ -56,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.
@@ -65,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] [--backend aws\|azure]` is the primary deploy command; `--backend` is valid only for provider `bnb` and confirms the recipe-derived managed backend. `prepare`, `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.5.15`.
+`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`.
 
 ## 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)
@@ -124,6 +126,8 @@ Proceeding in 3 commands… (interrupt now if anything's off)
 
 Then execute Stage 2 **without further prompts** until you hit a step that genuinely requires user action (funding the wallet).
 
+For NodeOps deployment, first read `bnbagent-studio-use-createos.md`: select account or wallet mode, verify the installed deploy capabilities, and choose a compatible wallet. Use `--destination self` for NodeOps and the user's AWS/Azure account. NodeOps wallet funding uses USDC plus possible BNB approval gas; the optional U-funding guidance below does not cover cloud payment. Pieverse auto-renew renews model credits, not NodeOps hosting.
+
 ## Stage 2 - Generate a todo list (visible to the user)
 
 Build a TodoWrite list. The shape depends on the `wallet kind`. The canonical 8-step layout (evm-local default, Pieverse default LLM; plus a conditional Step 6b for self-hosted durable storage):

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.5.15`), 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.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.
 ---
 
 > **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.5.15`. 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.2`. 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.5.15 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.2 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.5.15` 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.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.
 
 ## Select and authenticate
 

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

@@ -0,0 +1,179 @@
+---
+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.
+---
+
+# 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.
+
+## 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.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`:
+
+```toml
+[deploy.nodeops]
+mode = "account"
+port = 8080
+packaging = "zip"
+# health_path = "/ping"
+# account_id = "your-createos-account-id"
+# environment = "production" # must already exist
+```
+
+Inject `CREATEOS_API_KEY` through the process environment. Use the existing Studio secret workflow for model, wallet and storage credentials; never copy secrets into source or the archive. Studio sends runtime secrets separately from the artifact and excludes the control-plane API Key. The account needs sufficient CreateOS credits; account deployment does not buy credits automatically.
+
+```bash
+bag deploy prepare --provider nodeops
+bag deploy --provider nodeops --yes
+bag deploy list --provider nodeops --json
+bag deploy status --provider nodeops --json
+bag deploy verify --provider nodeops --skip-register
+bag deploy logs --provider nodeops
+```
+
+Readiness builds and validates a temporary artifact without cloud mutation. ZIP packaging needs an HTTP entrypoint compatible with Studio's generated A2A/MCP recipes. For container packaging, set `packaging = "container"` and `image_repository = "ghcr.io/owner/agent"`, supply a Dockerfile and safe `.dockerignore`, and authenticate Docker to the registry. The resulting image must be publicly pullable. TWAK requires a container with its CLI installed.
+
+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 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.
+
+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
+
+Studio checks `/ping` (or `health_path`) and the A2A agent card when enabled. Deploy exits nonzero on health failure, but the cloud resource and `.studio/deployments/nodeops.json` record remain. `status --json` includes `last_health`, a saved observation rather than a new application probe. Retry `verify --skip-register` to refresh it without redeploying or paying. Omitting `--skip-register` may register/update the ERC-8004 endpoint through Studio's normal workflow.
+
+Remote `list` can find projects absent from local records. Status/logs/verify/destroy use locally recorded mode, origin, subject and environment even if configuration later changes. Do not fabricate local records from a similarly named project.
+
+```bash
+bag deploy destroy --provider nodeops                 # preview
+bag deploy destroy --provider nodeops --execute --yes # delete entire project
+```
+
+Deletion removes project environments too; registry images and payment history remain. `--purge` and `--purge-images` are unsupported for NodeOps.
+
+## Wallet deployment through conversation
+
+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.
+
+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.
+
+```toml
+[deploy.nodeops]
+mode = "wallet"
+packaging = "zip"
+port = 8080
+
+[deploy.nodeops.payment]
+protocol = "mpp"
+chain = "bsc"
+asset = "USDC"
+months = 1
+max_per_payment_usd = "5.00"
+max_per_day_usd = "5.00"
+max_per_month_usd = "20.00"
+max_approval_gas_wei = "1000000000000000"
+auto_pay = false
+use_existing_credits = false
+
+[wallet.signing]
+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`:
+
+```bash
+bag deploy wallet --json
+bag deploy prepare --provider nodeops
+# After the user has authorized deployment and payment within the configured caps:
+bag deploy --provider nodeops --yes --pay
+bag deploy status --provider nodeops --json
+bag deploy verify --provider nodeops --skip-register
+```
+
+`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.
+
+## When the user asks to renew
+
+Distinguish hosting renewal from Pieverse LLM-credit replenishment and Altana session expiry. The latter have their own references; neither renews a NodeOps project.
+
+An agent can implement a hosting renewal policy and scheduler. However, this integration has not verified the existing-wallet/project recharge operation or how its result extends the active resource. Public Gateway `/agent/deploy` couples credit purchase with creating a deployment; `months` is a credit price multiplier. Do not invent `bag deploy renew`, treat USDC balance as hosting credits, transfer USDC directly to a quoted recipient, or schedule repeated deployment POSTs as renewal.
+
+For now, inspect recorded status/inventory and report that NodeOps hosting renewal is not executable through Studio. Do not claim auto-renew is enabled. To implement it, first verify a recharge path tied to the existing billing identity, then add budget checks, serialized execution, receipt reconciliation and a scheduler that can still run if the hosted agent stops. This is an integration gap, not evidence that the NodeOps backend cannot renew resources.

package/skills/references/bnbagent-studio-using-altana-wallet.md

@@ -11,7 +11,7 @@ Altana separates trusted administration from runtime authority:
 - `.studio/wallets/altana-session.json` is the one bounded, expiring runtime session and must stay mode `0600`.
 - `WALLET_PASSWORD` is admin-only. The Agent gets `ALTANA_SESSION`, never the password or admin keystore.
 - Generic signing is refused. ERC-8183 uses `sessionQuoteSigner()` and the approved quote checker.
-- The generated project pins `@bnbagent/sdk@0.5.6` and `@altananetwork/sdk@0.7.1`; doctor, readiness, and runtime loading reject version drift. SDK 0.5.4 introduced selector-bound calls, removed session-key token approvals, and requires an admin-provisioned bounded Commerce allowance. Projects upgrading from SDK versions older than 0.5.4 must update it, re-grant with `bag wallet session grant --force`, and redeploy.
+- The generated project pins `@bnbagent/sdk@0.5.7-alpha.2` and `@altananetwork/sdk@0.7.1`; doctor, readiness, and runtime loading reject version drift. SDK 0.5.4 introduced selector-bound calls, removed session-key token approvals, and requires an admin-provisioned bounded Commerce allowance. Projects upgrading from SDK versions older than 0.5.4 must update it, re-grant with `bag wallet session grant --force`, and redeploy.
 - Deployment ships ONLY the serialized session as the `ALTANA_SESSION` runtime secret; the admin keystore and `WALLET_PASSWORD` never leave the operator machine. Renewal after expiry: `bag wallet session grant --force`, then re-run `bag deploy`. Readiness fails on a missing/expired/address-mismatched session, a group/world-readable session file, a session inside the artifact root, or an unresolvable project-local `@altananetwork/sdk`; it warns under 7 days remaining. `bag deploy verify` needs `--skip-register` (no generic signing for the ERC-8004 register).
 - Altana refuses generic message signing, so Pieverse SIWE cannot authenticate `bag llm activate` or runtime credit renewal. `bag init --wallet-kind altana --llm-provider pieverse-llm` is rejected outright; use OpenRouter, OpenAI, or Anthropic (API-key providers). `bag llm activate` and `bag doctor` also flag the combination on projects edited by hand.