@artblocks/abx-cli 0.1.0-alpha.32 → 0.1.0-alpha.34

package/skill/reference/operate.md

@@ -0,0 +1,181 @@
+# Operating an existing ABX project
+
+Use this reference for inspection, minting and sales, transfers, fields, gateways, URI pointers,
+royalties, supply, attachments, refreshes, ownership transfer, and locks.
+
+## Contents
+
+- [Read before writing](#read-before-writing)
+- [Mint and run primary sales](#mint-and-run-primary-sales)
+- [Transfer tokens and authority](#transfer-tokens-and-authority)
+- [Operate metadata and data](#operate-metadata-and-data)
+- [Manage economics and supply](#manage-economics-and-supply)
+- [Lock precisely](#lock-precisely)
+
+## Read before writing
+
+Never infer contract type or current authority from the original launch notes. Read the contract:
+
+```bash
+abx state <address>
+abx tokens <address> --json
+abx contracturi <address>
+abx tokenuri <address> --token <id>
+abx verify <address> --json
+```
+
+Use `abx status` or its remote form for projection/render lifecycle. Record active chain, detected
+family, owner/admin, supply and pause state, minter/payee, royalty/cap, URI renderer/pointers, code
+dependencies, schemas/hooks, and lock state.
+
+Before every write, run its help and dry-run form when available. Confirm sender, target, value,
+token/id/amount, and permanence. Let the CLI validate contract type; do not send raw ABI calls to make
+an operation fit the wrong family.
+
+## Mint and run primary sales
+
+`abx mint` follows the detected family:
+
+- A 1/1 issues its single token.
+- A Series mints the next id in order; `--count` can mint multiple sequential ids.
+- An edition requires `--token-id` except where the contract has only the single 1/1-edition id, and
+  uses `--amount` for copies. `--count` is not an edition synonym.
+
+Confirm the recipient. Minting may trigger a transfer hook; a hook that vetoes mint will revert the
+whole transaction.
+
+### Shared fixed-price minter
+
+Use the shared minter commands for ordinary ETH primary sales:
+
+1. `abx minter configure <token> …` sets price and allocation. Editions require a token id and use a
+   per-id sale configuration.
+2. `abx set-minter <token> --minter <address>` authorizes the minter.
+3. `abx set-primary-payee <token> --payee <address>` declares payout.
+4. `abx unpause <token>` opens minting when the family supports the pause gate.
+5. `abx minter show <token> …` verifies the public sale state.
+6. `abx minter buy <token> …` is the public purchase path; editions use quantity and token id.
+
+Do not call a sale live until price units, allocation, payee, minter address, pause state, and a
+representative purchase are verified. `abx mint-page` scaffolds a client for the shared minter; it does
+not configure the on-chain sale for you.
+
+Use a custom minter for auctions, allowlists, raffles, free claims, ERC-20 pricing, or other issuance
+rules. The custom contract calls the canonical token's mint authority; the token itself remains a
+factory clone. Read [capabilities.md](capabilities.md).
+
+## Transfer tokens and authority
+
+`abx transfer` moves token ownership/copies, not contract administration.
+
+- A 721 transfer names token id and destination.
+- An edition transfer names token id, amount, destination, and source holder because an id can have
+  multiple holders.
+- Creator-token validation or a transfer hook may reject the move. Diagnose the actual revert; do not
+  bypass or clear an enforcement mechanism without the owner's explicit intent.
+
+`abx set-admin --to <address>` transfers contract authority. Treat it as a high-risk, potentially
+irrecoverable handoff:
+
+1. Verify the recipient is correct for the active chain.
+2. Inventory unfinished operations and unlocked surfaces.
+3. State which powers move and which external controllers remain separate.
+4. Receive exact human confirmation.
+5. Execute once, then read state from chain to prove the new owner.
+
+Never interpret a token transfer as a sale listing. ABX has no secondary order book; a marketplace or
+manual transfer handles secondary exchange.
+
+## Operate metadata and data
+
+### URI pointers and renderers
+
+Use `set-token-uri`, `set-contract-uri`, and `set-renderer` only after reading the current configuration
+and verifying the destination. Switching `set-renderer --off` can place an HTTP resolver in front of
+content that remains stored on-chain. Switching to the canonical renderer makes configured on-chain
+fields self-resolving when the contract supports them.
+
+Never hand-build a resolver path. Read `tokenURI`/`contractURI`, decode it, and follow what the
+contract actually returns. A correct-looking URL constructed from memory is not evidence.
+
+### Fields
+
+`abx set-field` writes one metadata field representation at token or collection scope. Representations
+include inline data, reader/chunk pointers, hashes, public locators, and renderer pointers as supported
+by the contract. Collection-scope values act as shared defaults; token-scope values override them.
+
+Use reserved fields such as description, attributes, creator, license, display notes, and links
+according to command help. Verify the resulting provenance in decoded metadata. On-chain-wins means a
+new on-chain value can intentionally supersede a resolver projection.
+
+### Gateways
+
+`abx set-gateway` changes the serving prefix for IPFS/Arweave locator representations without moving
+the content. Verify a representative locator through the new gateway before changing it. A gateway
+repoint is not a re-upload and does not change the committed CID/transaction id.
+
+### Attachments versus parameters
+
+`abx attach <addr> <key> <locator>` records a named artifact. The resolver exposes the complete
+artifacts list and `/data/<key>` retrieval. Bare on-chain metadata cannot enumerate arbitrary field
+keys, so consumers need a resolver to discover all attachments even when each locator is durable and
+hash-anchored.
+
+PostParams are different: the parameter store enumerates schemas and values on-chain. Read schemas
+with `state` and values with `tokens --json`. Parameters do not require a resolver merely to be
+canonical or enumerable.
+
+### Refresh and URI events
+
+`abx refresh` asks external marketplaces to fetch metadata again; it does not fix the metadata or
+mutate canonical state. First prove that the current URI resolves and returns the intended document.
+For editions, `ping-uri` re-emits native URI events for selected ids after a repoint. Use the smallest
+id set needed and verify the new path before signalling indexers.
+
+## Manage economics and supply
+
+Use `set-royalty` to change receiver/rate within the collection's permanent royalty ceiling. Use
+`set-royalty-cap` only to lower that ceiling. State the old and new values and confirm the irreversible
+loss of future headroom.
+
+Series supply caps and edition per-id caps are monotonic downward. Read current minted supply before
+lowering a cap; never propose a value below already minted supply. For editions, name the id and
+distinguish its per-id cap from aggregate collection supply.
+
+Pause/unpause controls the supported mint gate, not transfers or every external minter behavior.
+Read state after changing it.
+
+Primary payee declares sale proceeds; royalty receiver handles secondary royalty reporting. Keep them
+separate. Changing one does not update the other.
+
+## Lock precisely
+
+Lock last, after production-path verification. Every lock freezes a different surface:
+
+| Lock | Freezes | Does not necessarily freeze |
+|---|---|---|
+| `lock-field` | one token/collection field representation | other fields, URI pointer, program, params |
+| `lock-uri` | URI configuration/pointer at selected scope | program/dependencies/params/hooks |
+| `lock-script` | code-project script chunks | dependencies, metadata, params, external renderer code |
+| `lock-dependencies` | dependency list and registry pointer | bytes returned later by a live registry entry |
+| `lock-param-hooks` | configure/transfer/augment addresses | behavior behind an upgradeable address |
+| governed schema/value lock | writes governed by that schema/key | unrelated or ungoverned params; some inherited defaults |
+| ownership transfer | future owner-only authority at this contract | powers held by external minters/hooks/providers |
+
+For a code project, metadata locks alone do not freeze the program. A strong freeze normally requires
+script, dependency, relevant field/URI, hook, and governed-parameter decisions, plus immutable external
+renderer/hook/dependency deployments.
+
+Important qualifications:
+
+- An ungoverned parameter remains writable despite metadata locks.
+- A schema-welded token value is stronger than a collection default inherited by many tokens; the
+  recovery path may still allow a poisoned collection default to be cleared.
+- A registry dependency may return different bytes behind a frozen reference.
+- A locked pointer to an upgradeable proxy fixes the address, not its behavior.
+- A transfer-hook address represents a standing ability to veto mints/transfers. Freezing an empty
+  hook set is the proof that this power cannot later be added.
+
+Use `abx verify` and direct state reads to enumerate what remains mutable. Describe the guarantee as
+specific stored values and addresses that can no longer change; do not promise immutable output unless
+every live input and external implementation has actually been bounded.

package/skill/reference/services.md

@@ -0,0 +1,76 @@
+# First-party services and feedback
+
+Use this reference for the public ABX service, API-key signup, hosted resolver/rendering, or feedback.
+For provider-independent hosting and migration, also read [hosting.md](hosting.md).
+
+## First-party service
+
+The documented endpoints are:
+
+- documentation: `https://docs.abx.io`
+- service: `https://services.abx.io`
+- verified signup: `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`. Signup asks for a name and email, sends a short-lived verification code, then
+returns an API key after the email is verified. Never request an access code, paste the key into a
+command or agent instruction file, or expose it in feedback. An already verified email reuses its
+account and may receive another key, subject to the service's active-key limit.
+
+The service currently provides hosted resolution and managed rendering to any verified free API key.
+That entitlement may later become paid to cover infrastructure. Say so when it affects 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. Do not promise future pricing, quotas, or
+continued free hosting.
+
+Before depending on hosted behavior, inspect the live descriptor with `abx remote abx`; do not infer
+capabilities from this file. Use `--remote abx` on commands that accept a managed remote and verify
+the resulting public surfaces as described in [hosting.md](hosting.md).
+
+## 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.
+
+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 and hosted entitlement; it never grants transaction-signing authority.
+
+Use the CLI instead of hand-written HTTP or retry loops. 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,87 +1,133 @@
-# Setup — install `abx`, configure `.env`, then RPC & troubleshooting
+# Setup and safety
 
-[← back to SKILL.md](../SKILL.md)
+Use this reference when installing ABX, selecting a binary or signer, configuring a new environment,
+or preparing a real transaction.
 
-**First time? Start at [Finding, installing and configuring `abx`](#finding-installing-and-configuring-abx)** —
-that section is the required setup. The RPC and troubleshooting material below it is reference you reach
-for when indexing is slow or a resolver will not serve, not something a first launch needs.
+## Contents
 
-## Finding, installing and configuring `abx`
+- [Resolve the tool before the project](#resolve-the-tool-before-the-project)
+- [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)
 
-`abx` needs **Node ≥ 22.13** at runtime (the projection store uses built-in SQLite, unflagged only from
-v22.13.0 / v23.4.0). On anything older the CLI refuses to start and names the fix — do not work around it
-with `NODE_OPTIONS=--experimental-sqlite`, that combination is untested.
+## Resolve the tool before the project
 
-### Find `abx` before you install it — local first, then global
-
-**Resolve in this order and use the first hit.** Don't jump to a global install; a project-local CLI is pinned in the creator's `package.json` (reproducible, and what `abx skill install` version-locks against), so it wins whenever it exists:
+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
-./node_modules/.bin/abx version   # 1. project-local — PREFER this (invoke as `npx abx <cmd>` once you know it's there)
-abx version                       # 2. a global install already on PATH
+abx version
+abx doctor
+abx capabilities --json
+abx skill install
 ```
 
-- **Probe the local binary by PATH, never with `npx abx`.** The bare `abx` name on npm is an **unrelated squatted package**, so a plain `npx abx` with nothing local *downloads that*. And `--no-install` does **not** make the probe safe or trustworthy: it only skips a *fresh download*, and npm will still happily run any `abx` binary sitting in the npx cache from an earlier run — which can be a stale version (a real sweep saw `--no-install` report a months-old build as the project's CLI) or, if a plain `npx abx` was ever run on that machine, the squatted package itself. `./node_modules/.bin/abx` is unambiguous: it exists in THIS project or it doesn't.
-- In the **abx source repo** (contributor), neither applies: use `pnpm abx <cmd>`, which runs the live `tsx` source.
+`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.
 
-**Nothing found → install.** The package is **`@artblocks/abx-cli`** (not `@artblocks/abx-sdk` — that's the library, and installing it gets you no `abx` binary; a real session lost a cycle to exactly that mistake):
+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.
 
-| Situation | Install | Then invoke as |
-|---|---|---|
-| The creator has a project dir (a `package.json`) — **default** | `npm install --save-dev @artblocks/abx-cli` | `npx abx …` |
-| No project, or they asked for a machine-wide tool | `npm install -g @artblocks/abx-cli` | `abx …` |
+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.
+
+## 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:
 
-Ask before installing **globally** — it's a machine-wide change to their PATH, and the per-project install is the reversible one. A project install needs no permission beyond the usual.
+- `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.
 
-Whichever you land on, **keep using that same invocation for every command in the session** (`npx abx …` vs `abx …`) — don't mix them, or you'll silently drive two different CLI versions. Then run `abx doctor` (preflight: signing key/wallet, RPC, canonical factory, storage).
+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.
 
-`.env` (in the creator's project dir) = **secrets only**:
-- **Signing:** `ABX_DEPLOYER_PK` (the only name read — older `SEPOLIA_FUNDED_PK`/`SEPOLIA_WALLET_PK` are retired, and the CLI's error names them if it finds neither) is needed ONLY for hot/unattended signing. If the creator owns a wallet, prefer **`--sign`** — no key in `.env`. `doctor`'s missing-key ✗ is **not fatal** on the `--sign` path.
-- `ABX_RPC_URLS`, `ABX_PUBLIC_BASE_URL` (remote-resolver custody only), optional `OPENSEA_API_KEY`, plus any backend secret.
-- **One client-side credential grammar: `ABX_REMOTE_<NAME>_URL` + `ABX_REMOTE_<NAME>_TOKEN`** (same normalization as `ABX_RPC_URLS_<CHAIN>`) — a node you run is just the name **`self`** (`deploy-resolver` generates `ABX_REMOTE_SELF_TOKEN` locally; bare `--remote` defaults to it), a managed provider is its own name. `ABX_RESOLVER_ADMIN_TOKEN` is the **resolver's own server-side config** (never read client-side) — a stale copy of it in `.env` with no `ABX_REMOTE_SELF_TOKEN` gets a pointed error naming both vars, and `abx doctor` flags it too. Only `_URL`/`_TOKEN` are read — `ABX_REMOTE_<NAME>_KEY` is ignored (the CLI flags a near-miss name).
+## Select the chain explicitly through the environment
 
-<sub>Working from the abx **source repo** (contributor)? `pnpm install`, then `pnpm abx <cmd>` or `pnpm sandbox`. Every command below is identical.</sub>
+The toolkit supports the chains printed by `abx capabilities`; today those are Base Sepolia by
+default and Ethereum Sepolia via `ABX_CHAIN=sepolia`. There is deliberately no `--chain` flag. The
+CLI refuses it because silently ignoring a wrong-chain request could spend on the wrong network.
 
-**Indexing reads the event log via `eth_getLogs` from the contract's deploy block**, which the CLI records at deploy and forwards to a resolver on `add` — so a normal deploy→index scans a small recent window, is fast on any RPC, and re-indexes incrementally. **If indexing is slow, or a hosted resolver won't serve, ASK IT: `abx status <addr> [--remote <name>]`** reports the lifecycle (`queued`→`backfilling`→`live`, plus `stale`/`failed` with a machine-readable cause), so "still catching up" and "broken" stop looking alike. Then **check the scan floor (is it scanning from block 0?) before blaming the RPC tier** — that mis-diagnosis is a known trap. Range caps, pruned log history, and which endpoint to give a resolver under load are covered below.
+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.
 
-## Choosing an RPC (drives re-index speed)
+## Choose one signing lane
 
-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.**
+Every write uses one of three lanes:
 
-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.
+| Lane | Select | Use when |
+|---|---|---|
+| 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 |
+
+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 or wallet signing. Do not split staging into a homemade
+offline sequence.
 
-**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. Note the limit of that: failover triggers on an *error*, and an endpoint that has **pruned its log history** does not error — it answers `eth_getLogs` with `[]` and HTTP 200, which is a success, so the pool keeps asking it. That is why `abx doctor` **probes every endpoint** and reports a per-endpoint verdict (✓ wide range + archive · ⚠ usable but range-capped · ✗ unusable, with the reason, e.g. *history pruned ~500000 blocks back* / *archive refused* / *wrong network*), then names the best for reconstruction — and why it warns when a **reachable** endpoint can't serve history, since ordering is what decides who answers first. 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.
+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.
 
-**Named remotes follow the same env-name normalization**: `--remote my-provider` reads `ABX_REMOTE_MY_PROVIDER_URL` / `ABX_REMOTE_MY_PROVIDER_TOKEN` (uppercase, non-alphanumerics collapse to `_`). Inspect what's configured with `abx remote` ([hosting.md → Managed providers](hosting.md#managed-providers--a-resolver-someone-else-runs---remote-name)).
+## Prepare without mutating
 
-**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.
+Use command help and dry runs, not guessed syntax:
 
-## Troubleshooting
+```bash
+abx help deploy-code
+abx deploy-code … --dry-run --json
+```
 
-- **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 `ABX_DEPLOYER_PK` 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.
-- **the scan finished but reconstructed 0 events** (`registered …, but with NO reconstructed state`) → for a project you JUST deployed this is transient (the logs haven't propagated; `abx index <addr> --full` in a minute). For a project that is **not new**, suspect **log retention**: several free endpoints keep only days of history and return an empty success past it, which is indistinguishable from "this contract emitted nothing". The CLI now re-runs the scan against **each configured endpoint on its own** before giving up, and names the one that served the logs — put that one FIRST in `ABX_RPC_URLS_<CHAIN>`. `abx doctor` flags a pruned endpoint up front.
-- **`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 remote resolver you just registered** (`abx add … --remote`): it may still be **backfilling** — hit `GET /` (or `abx remote <name|url>`, which lists the projects the token sees) 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 `503` with "its on-chain code has not been folded into the projection yet"** → exactly what it says: the resolver knows this is a code project (from the deployed extensions) but hasn't read its code yet. **Retry** — this is normal right after a register. It only means trouble if it persists, and then it's the scan-floor bug below.
-- **`/a/…` returns `404 {"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 deploy at all — a scan-floor bug, **not** a resolver version/compat gap (do NOT redeploy as a static NFT). The 404-vs-503 split is the diagnosis: 404 on a real code drop means the fold never saw this contract's deploy, which is the scan-floor signature. 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 content** → 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.
-- **a remote command returns 401 unauthorized** → the token the CLI resolved is missing/wrong for that target — the error names the var it used (`ABX_REMOTE_<NAME>_TOKEN` for a named remote, else `ABX_REMOTE_SELF_TOKEN`, else `--remote-token`). Check that var, or rotate the key at the provider if it may have leaked. Named remotes deliberately never fall back to `ABX_REMOTE_SELF_TOKEN` (or the resolver's own server-side `ABX_RESOLVER_ADMIN_TOKEN`).
-- **a remote command returns 403 forbidden** → the key is **valid but not authorized** for this contract/chain — provider-side scoping, not a typo. Don't retry-loop and don't swap tokens blindly: check the provider dashboard, and the descriptor's `chains` (`abx remote <name>`).
-- **register refused with `unsupported_chain`** → the service doesn't serve the project's chain — its descriptor `chains` says which it does. Pick a provider that covers the chain, or self-host.
-- **`/.well-known/abx-service` 404s** → an older self-hosted node (fine if it's yours — the remote commands still work against it once redeployed to the current image) or **not an ABX service at all** — verify the URL with `abx remote <url>` before registering anything; don't register blind.
-- **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.
+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 using `ABX_CHAIN` if not using Base Sepolia.
+4. Add RPC, signer, storage, and remote configuration outside the transcript. For the first-party
+   service, keep `ABX_SERVICES_API_KEY` in the project's ignored `.env`; do not add it or standing
+   signup instructions to `AGENTS.md` or `CLAUDE.md`.
+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.