@artblocks/abx-cli 0.1.0-alpha.8 → 0.1.0

package/skill/reference/services.md

@@ -0,0 +1,173 @@
+# First-party services and feedback
+
+Use this reference for the public ABX service, API-key login, hosted resolver/rendering, or feedback.
+For provider-independent hosting and migration, also read [hosting.md](hosting.md).
+
+## Contents
+
+- [First-party service](#first-party-service)
+- [Creator wallet and sponsorship](#creator-wallet-and-sponsorship)
+- [Feedback targets](#feedback-targets)
+
+## First-party service
+
+The documented endpoints are:
+
+- documentation: `https://docs.abx.io`
+- service catalog, account, and control: `https://services.abx.io`
+- public token data: `https://resolver.abx.io` (discover it from the catalog; do not hardcode it)
+- OAuth discovery: `https://services.abx.io/.well-known/oauth-authorization-server`
+- manual signup fallback: `https://services.abx.io/signup`
+
+The first-party provider has the built-in remote name `abx`:
+
+```bash
+abx remote abx
+```
+
+It needs `ABX_SERVICES_API_KEY` in the project's ignored `.env`; it does not need
+`ABX_REMOTE_ABX_URL`. When the key is absent, use:
+
+```bash
+abx auth login
+```
+
+The CLI starts the OAuth device flow and shows a verified browser URL plus a matching short code.
+The human completes name, email, one-time-code verification, and approval in that browser. The CLI
+polls at the provider-declared interval, receives the API key, and writes it directly to ignored
+`.env` without printing it. The browser never receives the key. Do not ask the human to paste an OTP
+or key into chat. `--no-open` leaves the browser handoff as a link; `--force` is required to replace
+an existing local credential, but does not revoke the displaced provider key. For normal rotation,
+run `abx auth logout` and then `abx auth login`; reserve `--force` for recovery. The CLI refuses
+tracked or unignored `.env` files.
+
+The issued API key is long-lived and remains valid until it is revoked. Reuse the stored key across
+tasks and agent sessions; do not start a new login merely because a task or conversation ended. If
+`abx remote abx` authenticates successfully, no login is needed. `abx auth login` also detects an
+already loaded credential and reuses it instead of issuing another.
+
+In an agent runner, start `abx auth login --no-open` with a short initial yield or a resumable
+background session. Relay the printed URL and code immediately while that same process keeps polling,
+then resume it after human approval. Do not start another login or add an outer retry loop. If the
+runner cannot yield control while a command waits, ask the human to run the command in their terminal.
+
+Logout only for intentional teardown, suspected compromise, deliberate rotation, or to free an
+active-key slot. When revoking, do not only delete the local value:
+
+```bash
+abx auth logout          # first-party service
+abx auth logout <name>   # another OAuth-capable named remote
+```
+
+Logout discovers the provider's RFC 7009 endpoint, revokes the current key, and only then removes the
+matching `.env` assignment. If the key came from a shell or another environment source, the CLI
+revokes it and tells the human where it still needs to be unset. A repeated logout with no active
+local credential is safe.
+
+An account may have up to five active keys. The service stores hashes, so it can list key metadata
+but cannot recover a lost secret. Use `abx auth keys` to inspect active keys and
+`abx auth revoke-key <key-id>` to revoke an unused non-current key. Use `abx auth logout` for the
+current key. Only create another key when a separate environment actually needs its own credential.
+
+Use `/signup` only as the manual recovery path. It shows the raw key once, so the human—not the
+agent—must place it in `.env`. An already verified email reuses its account and may receive another
+key, subject to the same limit.
+
+Availability, pricing, and quotas are service policy rather than protocol guarantees. Confirm current
+terms before making a durable hosting choice and keep the exit route explicit: the same remote-service
+contract supports another provider or a creator-operated resolver/effects deployment.
+
+Before depending on hosted behavior, inspect the live descriptor with `abx remote abx`; do not infer
+capabilities from this file. A remote is a provider catalog and may advertise different HTTPS
+origins for token resolution, control, account operations, and creator wallets. Trust the advertised
+interface endpoint, not a guessed hostname. Use `--remote abx` on commands that accept a managed
+resolver and verify the resulting public surfaces as described in [hosting.md](hosting.md).
+
+## Creator wallet and sponsorship
+
+An account with a verified email can use one persistent ABX creator wallet. The
+`ABX_SERVICES_API_KEY` identifies the account but cannot sign. `--sponsor` discovers the provider's
+`abx-creator-wallet/v1` endpoint and provisions or reuses the wallet. The first sponsored command
+asks the human to match one code and approve a Privy agent grant. The CLI keeps the rotating grant in
+the operating system's credential store and reuses it for up to 30 days, unless the creator revokes
+it first. The request-signing key remains memory-only. A reused grant removes another browser step; it does
+not remove the dry run, transaction summary, or production confirmation.
+
+The approval is authority for the agent to use the creator wallet, not approval of one displayed
+transaction. Review each exact network and transaction plan in the terminal. The creator can inspect
+and revoke active grants at `https://services.abx.io/authorize`.
+
+Treat the live descriptor and account capabilities as the authority for sponsored networks. The
+public [network table](https://docs.abx.io/docs/reference/deployments) is the human-readable summary,
+but it does not guarantee sponsorship for an account or moment. When the creator has not selected
+another signer, prefer this lane for an eligible testnet operation. For production, prove the flow on
+the paired testnet and repeat the production warning before confirmation. Before using it:
+
+1. run `abx auth login` if the account has no API key;
+2. inspect `abx capabilities --json` and the command help;
+3. run the same command with `--dry-run --json`;
+4. summarize the network, creator-wallet address, transaction group, zero value, permanent choices,
+   and any experimental or beta status;
+5. repeat with `--sponsor`; if no usable grant exists, give the human the verified URL and code and
+   resume the same command after approval.
+
+The lane accepts zero-value calls and receipt-dependent staged content groups up to the live network
+and provider policy. ABX does not impose an additional per-transaction gas ceiling. Use
+`abx deploy-contract` for exact already-compiled creation bytecode; its sponsored path calls the
+keyless CREATE2 proxy because provider-backed raw creation is unsupported. The constructor therefore
+sees the proxy as `msg.sender`; use explicit constructor arguments for ownership. ABX does not
+compile or audit it. Never add retries around a sponsored write. An `unknown` outcome means the
+provider may have submitted it: preserve the operation ID and reconcile status before any new send.
+
+Sponsorship is optional service policy, not protocol support. `--send`, `--sign`, and `--unsigned`
+remain first-class bring-your-own alternatives. Honor an explicit choice of any of them. If the
+provider does not advertise the chain, the account is ineligible, or the transaction group exceeds
+policy, select one of those lanes rather than refusing the underlying operation. Do not use
+sponsorship on a production network unless the live descriptor, account capabilities, and command
+all explicitly support it. Never infer eligibility merely because the CLI recognizes the lane.
+
+## Feedback targets
+
+`abx feedback` has two deliberately separate targets:
+
+| Intent | Command | Recipient |
+|---|---|---|
+| ABX protocol, contracts, CLI, SDK, skill, or docs | `abx feedback` | core ABX team |
+| A remote provider's resolver, rendering, auth, or operations | `abx feedback --remote <name>` | that provider |
+
+For first-party hosted-service feedback use `--remote abx`. A third-party remote can advertise the
+optional `abx-service-feedback/v1` interface and operate its own feedback store. Never send
+provider-specific incidents through core feedback merely because both first-party targets currently
+share infrastructure.
+
+Discovery and report previews are public. Submission (`--yes`) and `--mine` require the same key
+created by `abx auth login`; login once rather than creating a separate feedback credential. Run the
+command without report flags to inspect its live schema and instructions. To report, provide the
+required structured flags; use `--detail-file` or `--context-file` rather than fragile shell quoting
+for longer content. The CLI shows the exact destination and payload first. Review and redact the
+preview with the human, then repeat with `--yes` only after explicit approval.
+
+```bash
+# Preview core feedback; nothing is sent.
+abx feedback --area cli --kind bug --summary "Concise summary" --detail-file report.md
+
+# After the human approves this exact preview.
+abx feedback --area cli --kind bug --summary "Concise summary" --detail-file report.md --yes
+
+# Provider-specific preview.
+abx feedback --remote abx --component rendering --kind bug --summary "Concise summary"
+
+# Review reports previously submitted with the current key.
+abx feedback --mine
+abx feedback --remote abx --mine
+```
+
+Do not attach `.env`, credentials, wallet/session URLs, full transcripts, or unrelated source files.
+Prefer the smallest reproduction and relevant version/chain/address context. The API key authenticates
+the reporter; hosted-service entitlement is evaluated separately. It never grants transaction-signing
+authority.
+
+Use the CLI instead of hand-written HTTP or retry loops. The device flow already handles pending,
+slow-down, and transient polling responses until its fixed expiry. Treat `401` as missing/invalid credentials,
+`403` as recognized credentials without the required entitlement, and schema/interface errors as a
+request or provider-contract mismatch. Read [diagnose.md](diagnose.md) and make one state transition.

package/skill/reference/setup.md

@@ -1,36 +1,221 @@
-# Environment detail — RPC & troubleshooting
-
-[← back to SKILL.md](../SKILL.md)
-
-## Choosing an RPC (drives re-index speed)
-
-Reconstruction reads the event log via `eth_getLogs` **from the contract's deploy block** — the CLI records it at deploy and forwards it to a resolver on `add`, and discovers it on-chain (a getCode binary search) for a contract it didn't deploy here. So a normal deploy→index scans a *small, recent* window and is fast on **any** RPC. Providers cap the getLogs block range very differently **and these caps change** — treat any number as illustrative, re-verify before you quote it. *(Illustrative, Jun 2026: Alchemy free ≈10 blocks/call, Infura/Chainstack free ≈2000, PublicNode/dRPC vary; no-key public endpoints are the lowest-friction to try.)* The toolkit **auto-chunks**, so any RPC yields correct state — but a range cap is **not** cost-free to shrug off: a **from-genesis** or long-span reconstruction, or a resolver serving many code projects under load, is slow and rate-limit-prone on a capped endpoint. `abx doctor` rates each endpoint and flags a capped one; treat that flag as a real infra signal, not noise. **First diagnosis when indexing is slow or a hosted resolver won't serve: is it scanning from block 0? Check the scan floor before the RPC tier.**
-
-When `abx doctor` flags a tight range, or a reconstruction would be large/slow — **a decision point: research and present, don't power through:**
-1. **Do your own current research** (the limits rot) — find a free, range-generous, archive-capable endpoint for this chain *right now*.
-2. **Present clear choices with current specifics** — (a) point `ABX_RPC_URLS` at a higher-range endpoint *(recommended for anything large)*, with the exact signup/URL steps you found; or (b) stay on the current RPC and accept the wait.
-3. The CLI **stops a large job with an estimate** instead of grinding through thousands of requests; a better RPC is the real fix. To chunk through anyway, re-run with `--yes` (or raise `ABX_GETLOGS_MAX_CHUNKS`); `ABX_GETLOGS_RANGE` tunes the window.
-
-**One RPC var, network-scoped.** `ABX_RPC_URLS` is a comma/space-separated list of endpoints **for the active `ABX_CHAIN`** (there is no singular `ABX_RPC_URL`). The client **fails over** across them at request time — a request one endpoint rejects (a too-wide `eth_getLogs`) is retried on the next — and `abx doctor` **probes every endpoint** and reports a per-endpoint verdict (✓ wide range + archive · ⚠ usable but range-capped · ✗ unusable, with the reason, e.g. *archive refused* / *wrong network*), then names the best for reconstruction. So list a couple, let `doctor` pick, and order the list best-first. For **multiple chains**, set `ABX_RPC_URLS_<CHAIN>` (e.g. `ABX_RPC_URLS_BASE_SEPOLIA`, `ABX_RPC_URLS_SEPOLIA` — the default `ABX_CHAIN` is `base-sepolia`) — a per-chain list that overrides the bare var, never mixed, so one network's endpoints can't leak into another. The var *names* a network but the URL could point anywhere, so before any write the toolkit **verifies `eth_chainId` matches `ABX_CHAIN`** and hard-fails on a mismatch (reads stay unguarded/fast) — that's what makes "which network is this?" a checked fact, not a guess.
-
-**Re-index is incremental by default** — it resumes from the last-indexed block and only fetches new blocks, so routine re-indexing (after an owner op, or just refreshing) stays instant *regardless* of the range cap. Even the **first** reconstruction scans only from the **deploy block** (not genesis), so range/archive capability bites only on a genuinely long span — a forced full replay (`abx index --full`, a fresh projection, or the dashboard's "Re-index from chain" — the durability proof) of a contract deployed long ago. A "why is this scanning millions of blocks?" moment almost always means the scan floor is wrong (block 0), not that the RPC is inadequate.
-
-## Troubleshooting
-
-- **doctor: signing key** → **not fatal — a missing key is a fork, not a blocker.** A key in `.env` is only needed to sign *unattended* (hot lane). To sign in a browser wallet instead, run the write with `--sign` and no env key is needed. Offer both: add `SEPOLIA_WALLET_PK` (or `SEPOLIA_FUNDED_PK` / `ABX_DEPLOYER_PK` — any one) for autonomous signing, **or** use `--sign`. **deployer unfunded** → fund the printed address from a faucet for the active chain (Base Sepolia by default, else Sepolia).
-- **a write reverts with no clear reason (`--onchain-image` / staging)** → don't thrash by retrying variations. Get the actual reason: re-run the same call read-only with `cast call <addr> "<sig>" <args> --rpc-url <one of your ABX_RPC_URLS>`, which surfaces the revert string. The classic culprit is a stale chunk store (deployed before a contract upgrade) — the toolkit now detects this and auto-deploys a current store with a yellow notice, so you shouldn't hit the silent revert, but verify the resolved chunk-store/factory addresses are live (`cast code <addr>`; `abx doctor` / `abx status` print the factory) if anything looks off. **Never silently switch the representation you told the user you'd use** (e.g. fall back from `reader` to `inline`) — if the path changes, say so and why.
-- **storage 'cloud' missing accessKeyId/…** → set `ABX_S3_*` in `.env`. **'ipfs' unreachable** → Kubo not running or `PINATA_JWT` missing.
-- **re-index slow, or a "scan too large" stop** → **first check the scan floor: is it indexing from block 0 instead of the deploy block?** That's the usual cause of a "huge" scan (an `add` that lost the deploy block). The floor is `flags['from-block'] → the stored deploy block → on-chain discovery`; if none resolve, the CLI refuses rather than sweeping genesis. Only once the floor is correct does the RPC's `eth_getLogs` range matter: the toolkit chunks automatically, but a genuinely large job stops with an estimate rather than grinding. Real fix then: research a current higher-range free endpoint and set `ABX_RPC_URLS` (`abx doctor` reports your range); or re-run with `--yes` to chunk through. **archive-range getLogs refused** → use an archive-capable provider.
-- **`serve`/resolver returns `{"error":"unknown project"}`** → the resolver you hit doesn't have that contract in *its own* projection store **yet**. Two distinct situations — diagnose which, and NEVER default to "RPC limit":
-  - **A hosted resolver you just registered** (`abx add … --remote`): it may still be **backfilling** — hit `GET /` (or `abx status --remote`) to see if it's appearing. If it's slow or stuck, the cause is almost always a **from-genesis scan (from-block=0)**, not the RPC tier — a fixed `abx add` forwards the deploy block, so re-run it and confirm the floor. (Fixed in-toolkit: a first remote add now forwards/derives the deploy block and refuses a genesis default.)
-  - **A local `abx serve`**: a **store/port** problem. Usual causes, in order: (1) a **stale/duplicate `abx serve` from an old session** holds the port and serves a *different* store — hit `GET /` and see what it lists; (2) you're serving a different store directory than the deploy indexed into; (3) the contract was never registered there. Fix the server/port/registration.
-- **`/a/…` returns `{"error":"no live view — not a code project"}` on a project that IS a code drop** → the resolver indexed *above* the deploy block, so it never saw the `code` field written at deploy — a scan-floor bug, **not** a resolver version/compat gap (do NOT redeploy as a static NFT). This is the *opposite* of the genesis bug: the floor is too **high**, not too low. It happened when a `--sign` code deploy spanned blocks (deploy at N, mint at N+2) and the mint block was recorded as the floor. Confirm: `GET /api/project/<addr>` → `collectionFields` is `[]` and `fromBlock` sits above the deploy block. Fix: `abx add <addr> --remote <url> --from-block <deployBlock>` — a *changed* floor forces a full replay that picks up the `code` field. Find the true deploy block with `abx add <addr>` locally (it prints "deploy block N (discovered on-chain)"). (Fixed in-toolkit: `deploy-code` now records the clone-CREATION block, and discovers it on-chain rather than trusting the last-tx receipt.)
-- **directory-mode live view 302s to a doubled URL** (`https://arweave.net/https://arweave.net/<txid>/index.html`) → the `code` locator was stored as a full gateway URL and the gateway got prefixed again. Fixed in-toolkit (deploy stores the bare txid/CID; the resolver serves an already-absolute locator verbatim). A resolver image built before the fix still doubles — redeploy it to pick up the resolver-side tolerance.
-- **the thumbnail stays a placeholder on a HOSTED resolver even after `abx render` reports `ran=1`** → the render bytes landed in a store the hosted resolver can't read. A local `abx render` with the default `fs` backend writes to your laptop; `ipfs`/`arweave` write a LOCAL key→CID index the resolver doesn't have. Fix: render **to** the resolver — `abx render <addr> --remote <resolver>` (uploads to your `ABX_STORAGE_BACKEND` home and **publishes** a locator/bytes the resolver serves), or stand up the runner beside it (`abx deploy-effects --resolver-url <resolver>`). Only a SHARED `s3`/`cloud` bucket makes a bare local render visible to a hosted resolver. Confirm with `abx verify <addr>`.
-- **resolver won't start / errors about `ABX_PUBLIC_BASE_URL`** → it refuses a placeholder `.example` base (a scaffold leftover) or a `localhost` base in a hosted image (`ABX_HOSTED=1`), because it bakes that base into every image/animation URL it serves — a bad one serves dead links, so a loud fail beats silent breakage. Set `ABX_PUBLIC_BASE_URL` to the resolver's real public URL (`fly secrets set ABX_PUBLIC_BASE_URL=https://<app>.fly.dev`, or your custom domain). The current scaffold bakes the real platform hostname by default, so this only bites a hand-edited/old artifact or a stripped env.
-- **a hosted resolver LOST its index (or its render thumbnails) after a redeploy** → the SQLite projection wasn't on a persistent volume. The scaffold creates `fly volumes create abx_data` **before** the first deploy so the store lives on `/data` (the mount); if you deployed WITHOUT the volume, the store sat on ephemeral disk and a redeploy wiped it. Fix: ensure the volume exists (`fly volumes list`), then re-index (`abx add <addr> --remote --from-block <deployBlock>`). Note published **render locators + traits live on that same volume** (producer-published, not chain-derived), so restoring them after a volume loss needs a runner re-sweep, not just a chain replay — re-run `abx render <addr> --remote <resolver>` (idempotent; it re-publishes from the storage home without re-rendering) or let the effects service sweep.
-- **the project's on-chain `tokenURI` points at a HOSTED resolver but it isn't serving** → **do NOT "fix" it by running `abx serve` locally and handing over a `localhost` link.** The baked URL is the hosted one; a local serve resolves for no one but you. Fix the HOSTED resolver instead: re-run `abx add <addr> --remote` (now forwards the deploy block), check `GET /` on the host, and vet its RPC with `abx doctor`. A local serve is only ever the answer when the baked base is that same local machine.
-- **port hygiene before `serve`** → check the port is free first (`lsof -i:8787`). If an old session holds it, kill that process or serve this project on a distinct `--port <n>` (and point its `--public-base-url`/tokenURI accordingly) — a stale server silently answering on the port is the #1 cause of "works for me, `unknown project` for everyone."
-- **serving code projects is RPC-heavier than static art** → the live view rebuilds `tokenData` per request, and template-mode script chunks + data-backed (`String`/`Bytes`) params are read **live per view** (scalar PostParams come from the indexed projection, so they don't hit RPC each view). A resolver serving many code projects under marketplace traffic wants a range-generous, reliable RPC — this is a genuine scaling consideration, distinct from the getLogs range cap above.
-- **wallet lane: "no injected wallet"** → the human has no extension wallet; fall back to the hot lane (`--send`) if they're comfortable, or the cold lane for a Safe.
-- **owner op reverts** → the signer isn't the owner/holder. Check `abx status` / the `/api/project` state for the current owner; sign as that wallet.
+# Setup and safety
+
+Use this reference when installing ABX, selecting a binary or signer, configuring a new environment,
+or preparing a real transaction.
+
+## Contents
+
+- [Resolve the tool before the project](#resolve-the-tool-before-the-project)
+- [Upgrade when a release is available](#upgrade-when-a-release-is-available)
+- [Never expose secrets](#never-expose-secrets)
+- [Select the chain explicitly through the environment](#select-the-chain-explicitly-through-the-environment)
+- [Choose one signing lane](#choose-one-signing-lane)
+- [Prepare without mutating](#prepare-without-mutating)
+- [New environment checklist](#new-environment-checklist)
+
+## Resolve the tool before the project
+
+Inside the ABX source repository run `pnpm abx …`; elsewhere run the installed `abx`. A bare global
+binary inside the repository may be older than the source. Start with:
+
+```bash
+abx version
+abx doctor
+abx capabilities --json
+abx skill install
+```
+
+`abx doctor` reports binary provenance, CLI/skill drift, active chain, RPC health and history reach,
+wallet readiness, canonical factories, storage, and configured remotes without exposing credentials.
+Treat a red check as an actionable setup state, not as permission to improvise a workaround.
+
+The shipped skill is named `abx`. `abx skill install` installs it to `.claude/skills/abx` and
+`.agents/skills/abx` by default; `--agent`, `--global`, and `--target` narrow the destination. During
+the rename transition the installer moves a recognized `abx-self-host` folder to
+`.abx-skill-backups/` before installing the new name. It preserves custom bytes rather than deleting
+them. For a custom skills parent, run `abx skill install --target <that-parent>`; do not move or merge
+the old folder manually. Restart the agent after installation.
+
+ABX requires Node 22.13 or newer. Prefer a project-local npm dependency for reproducible automation;
+use a global install for interactive machine-wide use. Avoid repeated `npx` execution when version
+provenance matters because caches can outlive an upgrade.
+
+## Upgrade when a release is available
+
+Treat an `update available` notice or an outdated `npm` row in `abx doctor` as a recommendation to
+upgrade before planning a deployment or preparing a write. Do not silently change a global install
+or a project's dependencies; tell the creator which version is installed, which version is
+available, and give the command for that install:
+
+```bash
+# Global install
+npm install -g @artblocks/abx-cli@latest
+
+# Project-local install
+npm install --save-dev @artblocks/abx-cli@latest
+```
+
+The latest ABX release retains support for canonical projects made with earlier releases unless a
+specific contract generation is explicitly quarantined for a security or correctness reason.
+Updating the CLI does not redeploy or mutate a project. New deployments may use newer factories or
+defaults, so rerun help, capabilities, and the JSON dry run after upgrading.
+
+Then refresh the copied skill in the same scope reported by the CLI, restart the agent, and check the
+environment again:
+
+```bash
+abx skill install           # project copy
+abx skill install --global  # global copy, when reported
+abx doctor
+```
+
+If the creator defers the upgrade, say so once and continue only with the installed release's live
+help and capability output. Never assume a newer flag or behavior exists in an older binary.
+
+## Never expose secrets
+
+Do not open, search, quote, or print `.env`. Do not echo variables to test whether they exist. Do not
+paste a private key into a command line, generated file, wallet page, bug report, or transcript.
+
+Sensitive values include:
+
+- `ABX_DEPLOYER_PK` and any wallet key;
+- credential-bearing `ABX_RPC_URLS*` values;
+- `PINATA_JWT`, S3/R2 keys, `ABX_SERVICES_API_KEY`, other remote-provider tokens, effects/admin
+  tokens;
+- Arweave JWK contents and browser signing-session URLs.
+
+Use `abx doctor`, `abx remote <name>`, `abx storage show --check`, and redacted CLI errors. If a tool
+ever emits an unredacted credential-bearing endpoint, stop, rotate the credential, and report the
+output bug without repeating the secret.
+
+## Select the chain explicitly through the environment
+
+Read the full `chains` array from `abx capabilities --json`. Do not rely on a remembered network
+list. ABX is adding networks, and status may change between releases. There is no `--chain` flag
+because ignoring a wrong-chain request could spend on the wrong network.
+
+Choose a production chain by intended users, then measured cost. Use the `pairedChain` reported by
+capabilities for the test run. Large onchain payloads cost more on every network, so compare the dry
+run with Arweave, IPFS, or cloud custody.
+
+Before any transaction on an `experimental` or `beta` network, name the network and support level,
+explain what the transaction or transaction group will do, and state the relevant contract,
+configuration, and real-funds risks. ABX has not had an independent third-party audit; bugs,
+misconfiguration, and nondeterministic agent behavior may cause permanent loss. Link to the open
+source, use-at-your-own-risk implementation at
+https://github.com/ArtBlocks/abx. Qualify the same flow on the paired testnet before production.
+
+Use per-chain RPC variables when operating more than one chain. `abx doctor` checks chain identity,
+wide-range `eth_getLogs`, archival reach, and nonce coherence. Put a healthy archive endpoint first:
+fallback transports rotate on errors, not on a successful but pruned empty log response.
+
+The local projection and managed Arweave identity remain in `.abx-self-host/` unless
+`ABX_DATA_DIR` overrides it. That runtime directory is separate from the renamed `abx` skill and is
+not being renamed. Back up the managed Arweave key with `abx storage backup-key`; never print it.
+
+Every WRITE command (`deploy*`, `add`, `index`, `mint`, `set-*`, …) resolves `.abx-self-host`
+strictly relative to the current directory — it never searches upward, so it never creates a
+project's state somewhere unexpected. A handful of READ commands (`status`, `state`, `verify`,
+`doctor`, `capabilities`, `tokens`, `tokenuri`, `contracturi`, `inspect`, `minter show`) DO search
+upward, git-style, for an already-existing `.abx-self-host` if the current directory doesn't have
+one of its own — bounded at the home directory, a `.git` root, or the filesystem root. Practical
+consequence: `cd`-ing into a project's `contracts/` subdirectory before `abx status` still finds
+that project; the same `cd` before `abx add`/`abx deploy*` creates a NEW, empty node right there
+instead. If a status/verify/etc. answer looks emptier than expected, or a write seems to have
+landed in the wrong place, run bare `abx status` — its `data: <path>` line names the exact
+directory that answered, including a note when it was found by searching upward — or set
+`ABX_DATA_DIR` explicitly rather than guessing. See [Local data
+directory](https://docs.abx.io/docs/using-abx/self-hosting#local-data-directory) for the full rule.
+
+## Choose one signing lane
+
+Every write uses one of four lanes:
+
+| Lane | Select | Use when |
+|---|---|---|
+| Sponsored | `--sponsor` | The live remote advertises sponsorship for this chain and command |
+| Hot | `--send` or default | An environment key may sign unattended |
+| Wallet | `--sign --for 0x…` | A human approves in their browser wallet |
+| Cold | `--unsigned --for 0x…` | A multisig/offline signer needs prepared transactions |
+
+Honor an explicit creator choice. Otherwise run `abx capabilities --json`, the command help, and
+`abx remote abx`. Prefer `--sponsor` when the provider advertises the active chain, the command and
+transaction group are eligible, and sponsorship is enabled—especially on a testnet, where it removes
+wallet and faucet setup. Sponsorship is provider policy, not protocol support: if it is unavailable,
+paused, or ineligible, fall back to the appropriate bring-your-own lane rather than treating the ABX
+operation as unsupported.
+
+Select the lane before the JSON dry run. The signer can affect ownership, salts, and predicted
+addresses. If the lane changes, rerun the dry run and summarize the revised plan before execution.
+
+Run `abx doctor --for <address>` before a wallet or cold operation. On the wallet lane, give the
+human the locally generated signing page; never request or handle their key. On the cold lane, verify
+chain, sender, target, calldata, value, and ordering before handing transactions over.
+
+`--onchain-image` staging cannot use the cold lane because each chunk transaction depends on the
+receipt of the preceding transaction. Use hot, wallet, or sponsored signing. Do not split staging
+into a homemade offline sequence.
+
+`ABX_DEPLOYER_PK` may be written with or without a `0x` prefix — the CLI and SDK normalize it. Foundry's
+`vm.envUint` does not: a custom forge script that reads the same `.env` needs the `0x` form.
+
+For any one EOA, run one write command at a time. ABX obtains pending and latest nonces once, takes the
+safe maximum, increments locally, waits for newly deployed code when a following transaction targets
+it, and throws typed reversion errors. Starting concurrent processes bypasses that serialization.
+
+## Prepare without mutating
+
+Use command help and dry runs, not guessed syntax:
+
+```bash
+abx help deploy-code
+abx deploy-code … --dry-run --json
+```
+
+A dry run may read contracts, probe endpoints, analyze files, or verify an address, but it does not
+send or store. Address prediction is meaningful only when the salt and deployer are pinned. Use
+`abx predict` when another contract or resolver must know the collection address before deployment.
+
+Before any real send, confirm:
+
+- active chain and deploying/owning address;
+- contract family and edition arithmetic;
+- name, symbol, royalties and royalty ceiling;
+- deploy-time options such as burnability and creator-token enrollment;
+- custody, public resolution, image/animation/trait surfaces;
+- mint amount, value, transaction count, and expected gas;
+- every irreversible lock or authority transfer.
+
+Do not make a real send merely because a dry run exited successfully. The dry run is the plan; the
+human confirmation authorizes execution.
+
+## New environment checklist
+
+1. Install Node 22.13+ and the desired CLI version.
+2. Install the co-versioned skill with `abx skill install`, then restart the agent.
+3. Select the testnet with `ABX_CHAIN` when the default is not appropriate.
+4. Add RPC and storage configuration outside the transcript. If the live first-party remote
+   advertises sponsorship for the chosen chain and command, recommend it before asking the creator
+   to configure a signer. Otherwise configure one of the bring-your-own lanes. For first-party hosted
+   services, run `abx auth login --no-open` in a short-yield or resumable session: immediately hand
+   its verified browser URL and matching code to the human, then resume that same polling process.
+   Let the CLI store `ABX_SERVICES_API_KEY` in ignored `.env` without printing it. Never ask for the
+   email OTP or key in chat, start duplicate login sessions, or add standing login instructions to
+   `AGENTS.md`/`CLAUDE.md`. The key is long-lived: reuse it across tasks and agent sessions. Run
+   `abx auth keys` before creating a separate credential if the account is at its five-key limit;
+   revoke an unused non-current key with `abx auth revoke-key <key-id>`. Run `abx auth logout` only
+   for intentional teardown, compromise, rotation, or cleanup of the current key.
+5. Run `abx doctor` and resolve every red check relevant to the chosen lane.
+6. Run `abx storage show --check` when bytes will leave the local disk.
+7. Run `abx remote <name>` before relying on a configured managed service.
+8. Run command help, then a JSON dry run.
+9. Confirm the plan and only then execute.
+
+For an eligible first-party account, `--sponsor` replaces local key and faucet setup with an
+account-bound creator wallet. The first use opens a Privy agent grant; later commands reuse that
+grant for up to 30 days, unless the creator revokes it first. Do not ask for another browser approval when the
+CLI resumes an existing grant. Use sponsorship only when the live descriptor and account
+capabilities advertise the active chain. Test the exact flow on the reported paired testnet before
+production. Read [services.md](services.md) before using it. Sponsorship is zero-value and never a
+reason to skip the dry run or transaction summary.

package/assets/renderer-scaffold/src/interfaces/IAbxFieldRenderer.sol

@@ -1,32 +0,0 @@
-// SPDX-License-Identifier: MIT
-pragma solidity ^0.8.20;
-
-/// @title IAbxFieldRenderer — the contract your in-chain art implements
-/// @notice A field renderer returns ONE metadata field's value, COMPUTED from chain state
-///         (the token's seed + PostParams, its owner, anything readable on-chain). The ABX
-///         metadata renderer staticcalls it to build `tokenURI` — e.g. an `image` renderer's
-///         SVG becomes `data:image/svg+xml;base64,…`. Deploy your renderer, then wire it with
-///         `abx deploy-code --image-renderer <address> [--attributes-renderer <address>] --onchain-uri`.
-///
-/// @dev THE FIVE INVARIANTS (a reverting or malformed renderer bricks the WHOLE tokenURI —
-///      the metadata renderer staticcalls you with NO try/catch):
-///        1. NEVER revert for ANY (token, tokenId, field) — including the collection surface
-///           `tokenId == type(uint256).max` (used by `contractURI`). Return a neutral value.
-///        2. Return the correct `contentType` (`image/svg+xml` for an image; `application/json`
-///           for an `attributes` array).
-///        3. Guard `field`: revert only a truly unsupported field (a deploy-time miswiring), but
-///           still never revert on the fields you DO render.
-///        4. `view` + deterministic: same chain state → same bytes.
-///        5. Bounded output: keep it small (a few hundred bytes of SVG) so `tokenURI` stays a
-///           cheap single eth_call. `forge test` the never-revert cases before you wire it.
-interface IAbxFieldRenderer {
-    /// @param token   the ABX collection contract (read its params via {IAbxParams}).
-    /// @param tokenId the token, or `type(uint256).max` for the collection surface.
-    /// @param field   which field to compute (e.g. `"image"`, `"attributes"`).
-    /// @return contentType MIME of `data` (e.g. `image/svg+xml`, `application/json`).
-    /// @return data        the field's finished bytes.
-    function render(address token, uint256 tokenId, bytes32 field)
-        external
-        view
-        returns (string memory contentType, bytes memory data);
-}

package/assets/renderer-scaffold/src/interfaces/IAbxParams.sol

@@ -1,26 +0,0 @@
-// SPDX-License-Identifier: MIT
-pragma solidity ^0.8.20;
-
-/// @title IAbxParams — read the token's on-chain params (seed + collector PostParams)
-/// @notice Your renderer reads live state through this. Each value is a `bytes32`; `isSet` tells
-///         you whether it exists (fall back to a default if not — see invariant #1). `valueIsHash`
-///         is true when the on-chain value is a keccak commitment to off-chain bytes (a literal
-///         scalar param like a `seed` or a `HexColor` palette is NOT a hash — check `!valueIsHash`).
-///
-///         The tokenData merge rule: a token-scope value overrides the contract-scope one. The
-///         common pattern is `tokenParam` first, then `contractParam` as a fallback (see the
-///         `_param` helper in MyRenderer.sol).
-interface IAbxParams {
-    /// Returns the token-scope param: its bytes32 `value`, `valueIsHash` (true if it commits to
-    /// off-chain bytes — a literal scalar like a seed/HexColor is false), and `isSet` (does it exist).
-    function tokenParam(uint256 tokenId, bytes32 key)
-        external
-        view
-        returns (bytes32 value, bool valueIsHash, bool isSet);
-
-    /// @notice The contract-scope (collection-wide) value — the fallback when a token has none.
-    function contractParam(bytes32 key)
-        external
-        view
-        returns (bytes32 value, bool valueIsHash, bool isSet);
-}

package/dist/inspect.d.ts

@@ -1,48 +0,0 @@
-/**
- * `abx inspect <script.js>` — static analysis of a generative script, BEFORE picking a lane.
- *
- * The membrane fix behind this: an agent (or creator) should DERIVE the deployment lane from what
- * the script actually needs — are there traits? are they reproducible on-chain? how big is the
- * assembled document (does a single `tokenURI` eth_call even fit)? — instead of guessing "fully
- * on-chain!" and walking it back. This module is the pure analysis; `cmdInspect` formats it.
- *
- * Static only — it never executes the script (that's the resolver/runner's job, and executing
- * untrusted art in the CLI would be a footgun). Everything here is regex/heuristic over the source.
- */
-export type TraitFeasibility = 'none' | 'exact-likely' | 'careful' | 'infeasible' | 'unknown';
-export interface ScriptAnalysis {
-    bytes: number;
-    estChunks: number;
-    traits: {
-        present: boolean;
-        keys: string[];
-    };
-    paramHints: string[];
-    prng: {
-        seeded: boolean;
-        usesBareRandom: boolean;
-        usesMathRandom: boolean;
-        usesNoise: boolean;
-    };
-    depHints: string[];
-    looksP5: boolean;
-    feasibility: {
-        verdict: TraitFeasibility;
-        reason: string;
-    };
-    doc: {
-        estBytes: number;
-        deps: string[];
-        fitsSingleCall: boolean;
-        unknownDepSizes: boolean;
-    };
-    runtime: {
-        readsTokenData: boolean;
-        reportsTraits: boolean;
-        wrongGlobal: string | null;
-    };
-}
-export declare function analyzeScript(source: string, declaredDeps?: string[]): ScriptAnalysis;
-/** A one-line lane recommendation derived from the analysis (the decision-tree output). */
-export declare function recommendLane(a: ScriptAnalysis): string;
-//# sourceMappingURL=inspect.d.ts.map

package/dist/inspect.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"inspect.d.ts","sourceRoot":"","sources":["../src/inspect.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAgBH,MAAM,MAAM,gBAAgB,GAAG,MAAM,GAAG,cAAc,GAAG,SAAS,GAAG,YAAY,GAAG,SAAS,CAAC;AAE9F,MAAM,WAAW,cAAc;IAC7B,KAAK,EAAE,MAAM,CAAC;IACd,SAAS,EAAE,MAAM,CAAC;IAClB,MAAM,EAAE;QAAC,OAAO,EAAE,OAAO,CAAC;QAAC,IAAI,EAAE,MAAM,EAAE,CAAA;KAAC,CAAC;IAC3C,UAAU,EAAE,MAAM,EAAE,CAAC;IACrB,IAAI,EAAE;QAAC,MAAM,EAAE,OAAO,CAAC;QAAC,cAAc,EAAE,OAAO,CAAC;QAAC,cAAc,EAAE,OAAO,CAAC;QAAC,SAAS,EAAE,OAAO,CAAA;KAAC,CAAC;IAC9F,QAAQ,EAAE,MAAM,EAAE,CAAC;IACnB,OAAO,EAAE,OAAO,CAAC;IACjB,WAAW,EAAE;QAAC,OAAO,EAAE,gBAAgB,CAAC;QAAC,MAAM,EAAE,MAAM,CAAA;KAAC,CAAC;IACzD,GAAG,EAAE;QAAC,QAAQ,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,EAAE,CAAC;QAAC,cAAc,EAAE,OAAO,CAAC;QAAC,eAAe,EAAE,OAAO,CAAA;KAAC,CAAC;IAM3F,OAAO,EAAE;QAAC,cAAc,EAAE,OAAO,CAAC;QAAC,aAAa,EAAE,OAAO,CAAC;QAAC,WAAW,EAAE,MAAM,GAAG,IAAI,CAAA;KAAC,CAAC;CACxF;AAsDD,wBAAgB,aAAa,CAAC,MAAM,EAAE,MAAM,EAAE,YAAY,GAAE,MAAM,EAAO,GAAG,cAAc,CAqEzF;AAED,2FAA2F;AAC3F,wBAAgB,aAAa,CAAC,CAAC,EAAE,cAAc,GAAG,MAAM,CA0BvD"}