@artblocks/abx-cli 0.1.0-alpha.20 → 0.1.0-alpha.22

package/CHANGELOG.md

@@ -1,5 +1,1086 @@
 # @artblocks/abx-cli
 
+## 0.1.0-alpha.22
+
+### Minor Changes
+
+- 1b6b741: Rename "artist" to "creator" throughout, including the protocol vocabulary
+
+  ABX is a tool for creators generally. Art remains a first-class use case, but it should not be baked
+  into the product's framing — and it was, down to the on-chain identifiers.
+
+  **Breaking, and deliberately a clean break** (pre-launch, folded into the one redeploy that four
+  rounds of security remediation already required — deferring would have meant either living with the
+  old vocabulary permanently or spending a second deployment on a word):
+
+  - `AuthOption` is now `Creator`, `TokenOwner`, `Address`, `CreatorOrTokenOwner`, `CreatorOrAddress`,
+    `TokenOwnerOrAddress`, `CreatorOrTokenOwnerOrAddress`. Order is unchanged, so the `uint8` values
+    are identical — only the names moved. Users type these: `--schema key:Type:Creator`.
+  - The on-chain collection metadata field keys `artist` / `artist_links` are now `creator` /
+    `creator_links`. These are `bytes32` keys written on-chain and emitted verbatim into every
+    collection's `contractURI` JSON.
+  - CLI flags `--artist` / `--artist-links` are now `--creator` / `--creator-links`. No aliases.
+  - `@artblocks/abx-token-api` renames its `art` module to `content`: `generateArt` →
+    `generateContent`, `artContentHash` → `contentHash`.
+  - `AbxMetadataRenderer.SPEC_VERSION` is **7**, and `isCurrentRenderer` gates on it. A v6 renderer
+    emits a different member key, so it is genuinely behind, not cosmetically so.
+
+  Package CHANGELOGs are left alone on purpose: they record what past alpha versions actually shipped,
+  and rewriting them would make the release history lie about flag names that really were `--artist`.
+
+- 1b6b741: A purchase now carries the terms the buyer accepted — closing the one path by which a project owner
+  could take more than the buyer agreed to.
+
+  Both shared fixed-price minters take a mandatory **terms guard** — not a slippage allowance; see the note
+  below — and revert a new `SaleTermsChanged()` when the live sale doesn't match:
+
+  ```solidity
+  purchase(address token, address expectedPaymentToken, uint256 maxPrice)
+  purchaseTo(address token, address to, address expectedPaymentToken, uint256 maxPrice)
+  // 1155 — the bound is the TOTAL, since qty multiplies it
+  purchase(address token, uint256 id, uint256 qty, address expectedPaymentToken, uint256 maxTotalPrice)
+  purchaseTo(address token, uint256 id, uint256 qty, address to, address expectedPaymentToken, uint256 maxTotalPrice)
+  ```
+
+  `configure` takes effect immediately and has no timelock. On the ETH lane that was largely contained
+  (`msg.value` must equal `price`), but an ERC-20 sale settles `safeTransferFrom(buyer, payee, price)`
+  against a standing allowance — so an owner who front-ran a pending purchase with a huge price spent the
+  buyer's whole approval, and one who switched the sale to a different ERC-20 reached an allowance granted
+  somewhere else. `address(0)` as `expectedPaymentToken` means ETH. There is deliberately no "no maximum"
+  sentinel: a bound that can be defaulted away is the bug being fixed.
+
+  SDK (breaking): `preparePurchase` / `preparePurchase1155` take the live terms — `sale`, exactly what
+  `readSaleConfig` / `readSaleConfig1155` returns — instead of a hand-computed `value`. They derive the
+  ETH to attach (`price`, or `price × quantity`) and the bound from those terms, so the payment and the
+  guard cannot desync. Pass `maxPrice` / `maxTotalPrice` to state a wider ceiling (a UI that tolerates a
+  small move rather than making the buyer re-sign); it widens the guard only, never the payment. New
+  exported type `PurchaseTerms`.
+
+  **`maxPrice` is not slippage tolerance on the ETH lane, and the docs no longer imply it is.** The minter
+  requires `msg.value == price` (an equality) and V1 has no refund path, so an in-flight ETH purchase
+  reverts if the price moves in _either_ direction, however wide the ceiling. Real tolerance exists only on
+  the ERC-20 lane, where the live `price` is pulled from the buyer's allowance and anything at or below the
+  ceiling settles.
+
+  CLI: `abx minter buy` hands the terms it just read to the SDK (the price × quantity math now lives in
+  one place), and the scaffolded `abx mint-page` binds each mint to the terms the page is displaying —
+  if the owner re-prices mid-click the mint reverts, nothing is charged, and the page tells the buyer to
+  review the new price. Re-pricing a live sale therefore fails the buys already in flight, by design:
+  pause first if you want a clean cutover.
+
+  **Deploy note:** this is a runtime change to two shared singletons, so both need a redeploy on every
+  supported chain (CREATE2 + canonical salts, so the new addresses are identical cross-chain) and the new
+  addresses recorded in `packages/sdk/src/deployments.ts` +
+  `site/content/docs/reference/deployments.mdx`. Until then the CREATE2-prediction-vs-manifest tests fail
+  on purpose — that is the drift detector doing its job, not a broken test.
+
+- 1b6b741: The configure hook can see a blob's size and contents — so creators can police it instead of the protocol
+
+  `IAbxConfigureHook.onParamConfigured` gains two arguments:
+
+  ```solidity
+  function onParamConfigured(
+      uint256 tokenId,
+      bytes32 key,
+      bytes32 value,          // the literal on the scalar path; keccak256(data) on the blob path
+      address updatedBy,
+      uint256 dataLength,     // 0 on the scalar path; data.length on the blob path (never 0 there)
+      address dataBlobAddress // address(0) on the scalar path; the live SSTORE2 pointer otherwise
+  ) external;
+  ```
+
+  **Why.** On a multi-copy edition params belong to the id, so a holder-writable `String`/`Bytes` key is
+  shared: one holder could store large values and make the shared id's document expensive for every
+  co-holder. An independent audit asked for a protocol byte ceiling. A ceiling would cap every project
+  to police a configuration almost nobody wants — but the alternative we had documented, "the creator
+  constrains it in their own hook", was not actually possible: the hook only ever saw `keccak256(data)`.
+  It could not learn the length, could not read the content, and could not read the new value from
+  storage either, because nothing had persisted yet. Now it can, and no protocol limit is imposed.
+
+  **The bytes are not forwarded** — a blob can be nearly a full contract's worth of data, and putting it
+  in calldata would make every configure call pay for it whether the hook looks or not. A hook enforcing
+  a size ceiling reads `dataLength`; a hook that needs content calls `SSTORE2.read(dataBlobAddress)` and
+  pays for exactly what it asked for. Guaranteed: `keccak256(SSTORE2.read(dataBlobAddress)) == value`.
+
+  **Two things to know when writing one.** `tokenParamData(tokenId, key)` still returns the OLD value
+  inside the hook (that is what "before the value persists" means — and it lets you veto a regression).
+  And the blob is written _before_ the hook, because an address is meaningless until the contract behind
+  it exists; so a veto happens after the writer paid to store the bytes. The accepted path costs the
+  same as before, only rejection wastes, and it wastes only the rejecting writer's own gas.
+
+  `ConfigurableParams` is extension **v3** — the beacon's `extensionVersion` is how an integrator tells
+  which calling convention a deployed token uses. A hook written for the 4-argument form will revert
+  against a v3 token, and vice versa.
+
+  Addresses: `AbxParamsLib` moved, `AbxEditionLib` with it (it links it), and the four token types that
+  compose `ConfigurableParams` moved with their factories — `SeriesCode`, `EditionCode`,
+  `OneOfOneEdition`, `EditionImage`. The two ERC-721 image types and their factory, `AbxMetadataLib`,
+  `AbxCodeLib`, the renderer, chunk store, seed source and both minters keep their addresses.
+
+- 1b6b741: Renderer spec v10 projects four long-reserved keys; edition trust anchors move
+
+  **Renderer spec v10.** Four keys the spec reserved from the start were projected on chain by nothing:
+  `background_color` and `youtube_url` (token), `banner_image` and `featured_image` (collection). A
+  documented reserved key that no surface emits is a hole rather than a saved byte — a creator sets it,
+  observes nothing, and cannot tell whether the tool or the marketplace is at fault. All four now project
+  when their representation is chain-reachable, and are omitted when unset. `isCurrentRenderer` gates on
+  10; a v9 renderer silently drops them.
+
+  **`collaborators` is no longer a reserved key.** It was in the registry, projected by neither plane, and
+  because reserved keys are excluded from the resolver's `artifacts` listing, setting it on chain did
+  nothing observable anywhere. It is now an ordinary creator key — which means it **does** list in
+  `artifacts`. Put a collaborator list in a named artifact (`abx attach`) or in `description`.
+
+  **The resolver's two collection image keys are now symmetric with the renderer.** `featured_image` is a
+  top-level `contractURI` key instead of artifacts-only, and `banner_image` projects for every
+  chain-reachable representation instead of only `url` (an `inline` or `reader` banner used to vanish).
+
+  **Docs now carry the three-list split** — which keys both planes project, which are the off-chain
+  resolver's alone by design (`abx_provenance.status`, operator overlay, effects/live-view, the
+  `artifacts` listing, collection `image` courtesy, `image_data`, off-chain-decode values), and which are
+  not reserved at all. That split is the thing to read before adding a key to either surface: drift on a
+  key both planes _can_ emit is what produced three earlier remediations.
+
+  **Addresses.** The three edition factories move (trust anchors) along with their implementations, and
+  the renderer moves. `AbxEditionLib`, `AbxMetadataLib`, `AbxCodeLib`, `AbxParamsLib`, all three ERC-721
+  factories, the chunk store, the seed source, both minters and both generators keep their addresses.
+  Existing clones keep running their frozen implementations; re-point a live collection at the new
+  renderer with `abx set-renderer` rather than redeploying it.
+
+- f64a31f: Expose `lockScript` above the contract layer — the lock that actually freezes a code project's work.
+
+  `SeriesCode`/`EditionCode` have always had `lockScript()` (and `scriptLocked()`), but nothing above
+  the ABI surfaced it: the SDK had no `prepareLockScript`, the CLI had no `lock-script` command, and the
+  skill's immutability guidance told creators that `lock-field` + `lock-uri` made a project "provably
+  immutable". For a generative/code drop that is false — those freeze only the _metadata_; the owner can
+  keep rewriting the on-chain program (`setScriptChunk`/`removeLastScriptChunk`) until the script is
+  locked. Agents building on ABX repeatedly missed that the program could be frozen at all.
+
+  - **SDK:** new `prepareLockScript({contract, chainId})` (mirrors `prepareLockDependencies`).
+  - **CLI:** new `abx lock-script <address>` command (any signing lane), plus `abx verify` now reports
+    the script and dependency lock state for code projects (`script: locked/UNLOCKED`, with a nudge to
+    `lock-script` when the program is still mutable) — read from the already-indexed state, no extra RPC.
+  - **Skill:** the immutability guidance now names the full freeze for a code drop
+    (`lock-script` + `lock-dependencies` + `lock-field`/`lock-uri`, plus `set-schema … lock=now` for a
+    param value), corrects the "provably immutable" claim, and surfaces PostParams as a first-class
+    `deploy-code` capability (not only a generative feature) in the `SKILL.md` description and decision
+    tree so collector-settable on-chain parameters are discoverable.
+
+- 1b6b741: Independent-audit remediation: `abx_provenance` reshaped, `abx_params` removed, hook ABI widened
+
+  An independent adversarial audit of the contracts found no Critical or High issue, no theft path and
+  no cross-project reach — but four Mediums, eight Lows and five architectural notes. Everything is
+  addressed. Consumer-visible changes:
+
+  **`abx_provenance` entries are now `{field, source, note}`.** They lost `onChain`, which was wrong in
+  both directions — a `url` reported `false` although the URL string is stored on chain, while an
+  `inline` value of `"https://…"` reported `true` for a pure pointer — and `verifiedAgainstChain`,
+  which was hardcoded `null` on every entry. `source` says where the bytes came from; whether a value
+  resolves on chain is visible in the value, and that judgment belongs to the reader. The off-chain
+  resolver drops `onChain` for the same reason (it was exactly `status === 'on-chain'`) and keeps
+  `status`, which it can genuinely compute.
+
+  **`abx_params` no longer appears in `tokenURI`.** It was emitted by the on-chain renderer AND the
+  resolver and parsed back by nobody. Params enumerate directly from the contract — `tokenParamKeys`,
+  `tokenParam`, `paramSchemaKeys` — which is canonical, needs no indexer, and is what a chain-only
+  reader should use; a code project's script still receives them through `tokenData`. Traits for
+  marketplaces belong in `attributes`, unchanged.
+
+  **A computed `image` locator now lands verbatim.** A field renderer returning
+  `("text/uri-list", "ipfs://…")` was being data-wrapped into `data:text/uri-list;base64,…`, which no
+  marketplace dereferences. `image` and `animation_url` now share one implementation of the rule.
+
+  **`IAbxTransferHook.onTokenTransfer` gains `operator` and `amount`.** Without them a hook on a
+  shared-supply ERC-1155 cannot tell a real transfer from a zero-amount no-op — which let any address
+  fire the param lifecycle for an id it held no copy of. The token also refuses to notify on
+  zero-amount and self-transfers.
+
+  **`pingURI` is owner-only**, and `paramSchemaHead` / `selectOption` are new: resolving one selected
+  option no longer copies the whole option table on every render.
+
+  `AbxMetadataRenderer.SPEC_VERSION` is 8. Every canonical address moves — every token type is now
+  library-linked, including the two ERC-721 image factories, because the metadata field store was
+  externalized into the new `AbxMetadataLib` to restore EIP-170 headroom before any fix was stacked on
+  top of 187 bytes of margin.
+
+  The CLI now warns when `--copies` meets a holder-writable `--schema`: on an edition, params belong to
+  the id, so every holder shares one value and the last writer wins.
+
+- 1b6b741: The custom seed source is now a real choice, not a documented one
+
+  We tell creators — in the docs, in `AbxSeedSource`'s own NatSpec, and in `deploy-code --help` — that the
+  canonical mint seed is pseudorandom and that the answer for anything lottery-like is to point
+  `seedSource` at their own `IAbxSeedSource` over commit-reveal or a VRF oracle. On-chain that was always
+  true. In the toolkit it was not: there was no flag, no owner command, and the only route was an
+  `ABX_SEED_SOURCE` env var validated as nothing more than "has code at this address". A doc/code
+  contradiction of our own making, now closed at both ends.
+
+  **Deploy:** `abx deploy-code --seed-source <0x…|canonical>` (and the `--copies` edition lane). Omitting
+  it is unchanged — the canonical `AbxSeedSource` from the manifest, bootstrapped on a chain that lacks
+  one — and `--no-seed` still means no mint-time seed at all. Passing both is refused rather than resolved
+  in someone's favour. `ABX_SEED_SOURCE` keeps working and is no longer the unchecked lane.
+
+  **After deploy:** `abx set-seed-source <address> <0x…|canonical|none>` — owner-only, same positional
+  grammar as `abx set-transfer-validator`. It surfaces the on-chain `setSeedSource(address)` that nothing
+  reached before. **Future mints only**: a seed settles the instant it is assigned, so nothing already
+  minted changes. The command says so, names the count of tokens already carrying a seed from the old
+  source, and points out that a part-sold drop then spans two sources — public on the spine
+  (`SeedSourceSet`) but not something an early buyer is told, so pause and say so.
+
+  **`abx state` now prints the seed source**, labelled: `none`, the canonical singleton, or `CUSTOM`. It is
+  the one setting an owner can re-point mid-sale that changes what a later buyer receives, and it was
+  readable nowhere.
+
+  **Both writes probe the address first, and `code.length > 0` is not the check.** The SDK gained
+  `probeSeedSource` — one `eth_call` to `seed(uint256,address)`, which must return 32 bytes — plus
+  `readSeedSource`, `prepareSetSeedSource`, `assertSeedSourceUsable`, and a `SeedSourceUnusableError`
+  carrying a structured verdict. Four shapes are refused, each with its own message: **no code**;
+  **empty return** (the permissive-fallback shape — a Safe, an uninitialised proxy, an EIP-7702-delegated
+  EOA; pasting your own wallet is the common way in); **a return under 32 bytes**; and **a revert** (either
+  the wrong address entirely, or a real source not yet armed — `seed()` is called synchronously inside the
+  mint and its revert bubbles, so a source that cannot answer now cannot answer at mint either). The
+  interface is non-`view` on purpose, but an `eth_call` simulates a state-keeping source fine, so
+  commit-reveal and oracle-fed sources probe without sending anything. This matters because a
+  misconfigured seed source is **completely silent**: the write succeeds, `seedSource()` reads back what
+  you set, the event fires, `abx state` shows it — and then every mint of the collection reverts in the
+  token's `bytes32` decode. Same spirit as `CreatorToken._requireHasCode`.
+
+  **Naming fix: a `seed` param schema is not a "re-roll", and no longer described as one.** The governed
+  path is `configureTokenParam(tokenId, "seed", value)` — **the caller supplies the value**. Nothing is
+  re-randomized and the seed source is never consulted again; with an unbounded `Uint256Range` the
+  authorized party may set any 32-byte value, repeatedly, until they like the output. "Re-roll" promises a
+  buyer a fresh random draw they could reasonably expect to be fair, which is not what they get. It is a
+  collector-chosen (or creator-chosen) seed, and the docs, the specs, and the skill now say that. The
+  substance that was correct is unchanged: the schema is a pre-sale commitment (declarable only before the
+  collection's first seed exists), `paramSchema("seed")` is the buyer's read, and the type must be a
+  literal/scalar one.
+
+  **Dropped a stale warning** in the skill about a `seed` schema changing how the seed decodes off-chain
+  while the on-chain generator injects raw hex — `tokendata.ts` returns the raw hex for `seed`
+  unconditionally, ahead of the schema branch, so the wire format is invariant across both surfaces and
+  there is nothing left to warn about.
+
+  **Also corrected: `maxPrice` is a terms assertion, not slippage tolerance.** On the ETH lane the minter
+  requires `msg.value == price` (an equality) and V1 has no refund path, so an in-flight ETH purchase
+  reverts if the price moves in _either_ direction, however wide the ceiling — widening `maxPrice` on an
+  ETH sale buys the buyer nothing. Real tolerance exists only on the ERC-20 lane, where the live price is
+  pulled from the buyer's allowance. `specs/protocol/minter-spine.md` and
+  `site/content/docs/protocol/minting.mdx` said "a price cut still settles" without that distinction.
+
+- 1b6b741: Renderer spec v9: a computed image is carried once, not twice
+
+  A field-renderer-produced image was emitted as the reserved `image` key **and again** inside the
+  `artifacts` manifest, then the whole document was base64-encoded around both copies. On the
+  on-chain-SVG lane that roughly doubled the inner payload of `tokenURI` — the one read this protocol
+  most wants to stay within ordinary RPC limits.
+
+  The data-plane spec always allowed an on-chain renderer to omit entries duplicating reserved keys it
+  already emits ("an EVM-efficiency reduction, never a semantic one"). The renderer now takes that for
+  every reserved key, so on a fully-on-chain project `artifacts` is absent rather than empty. Nothing is
+  lost, because the entry's only unique contribution was a `mimeType` and a `data:` URI states its own.
+  The off-chain resolver still emits the complete listing, duplicates included — that asymmetry is the
+  spec's, and it is now documented on both surfaces.
+
+  Also removed: three orphaned param getters on the renderer (`paramKeysOf`, `paramSchemaOf`,
+  `paramDataOf`), stranded when v8 took params out of `tokenURI`, whose NatSpec still claimed `tokenURI`
+  called them.
+
+  `AbxMetadataRenderer.SPEC_VERSION` is **9** and `isCurrentRenderer` gates on 9. Only the renderer
+  moves — nothing links it, so no factory or implementation address changes. Existing on-chain-URI
+  projects keep resolving through the v8 renderer until re-pointed with `abx set-renderer`.
+
+- 1b6b741: Upgrading from alpha.12/alpha.13 — what breaks, in one place
+
+  This release lands the contract-audit branch. It is a **compatibility break with earlier alphas**, which
+  is fine at this stage (greenfield alpha, no backwards-compatibility promise) but is worth having in one
+  list rather than spread across a dozen changesets. Nothing here is a deprecation with a migration
+  window; the old shapes are gone.
+
+  **Every canonical address moved**, and four manifest fields are new (`metadataLib`, `paramsLib`,
+  `codeLib`, `editionLib` — the delegatecalled write-path libraries). Resolve through `getDeployment` and
+  the upgrade is transparent; anything you have _stored_ keyed by a factory address is not. A project
+  indexed from a superseded anchor reads `isCanonical: false` against the new manifest — correct, since it
+  is what a creator sees if they don't redeploy, but it is a data question, not a version bump.
+
+  **The metadata document changed: renderer spec v4 → v9.** If you assemble or assert on it:
+
+  - `abx_provenance` entries lost `onChain` (it was exactly `status === 'on-chain'`, and wrong in both
+    directions) and `verifiedAgainstChain` (hardcoded `null` on every entry). `source` and `status` stay.
+  - The `abx_params` block is gone from **both** lanes. Params enumerate from the contract —
+    `tokenParamKeys` / `tokenParam` / `paramSchemaKeys` — which is canonical and needs no indexer; a code
+    project's script still receives them through `tokenData`.
+  - `artist` / `artist_links` are now `creator` / `creator_links` (reserved on-chain collection field
+    keys), and `AuthOption.Artist*` is `AuthOption.Creator*` (numeric values unchanged).
+  - A computed `image` locator (`text/uri-list`) lands **verbatim** instead of being wrapped into a
+    `data:` URI no marketplace dereferences.
+  - The on-chain renderer no longer duplicates a computed image into `artifacts`. The off-chain resolver
+    still emits the complete listing — that asymmetry is specified, not a bug.
+  - Four long-reserved keys now project on chain: `background_color`, `youtube_url` (token) and
+    `banner_image`, `featured_image` (collection). `featured_image` also becomes a top-level resolver key
+    instead of artifacts-only, and `banner_image` projects for every chain-reachable representation
+    rather than `url` alone.
+  - `collaborators` is **no longer reserved** — projected by neither plane and excluded from `artifacts`
+    by its own reserved-ness, so it did nothing. It is now an ordinary creator key that does list.
+
+  **`tokenData` divergences fixed, so rendered output can change:** a contract-scope `seed` no longer
+  leaks into a token's `tokenData` (the on-chain generator never read one), `seed`'s wire format is always
+  raw 32-byte hex regardless of schema, and `</script` escaping is case-insensitive to match the on-chain
+  generator. Cached renders for affected code projects should be re-derived.
+
+  **Removed:** `paramKeysOf`, `paramSchemaOf`, `paramDataOf` on `AbxMetadataRenderer` — orphaned when
+  params left `tokenURI`. Read the token directly instead.
+
+  **Two hook interfaces widened** (`ConfigurableParams` is extension **v3**; a hook built for the old
+  signature reverts against a v3 token): `IAbxTransferHook.onTokenTransfer` gained `operator` + `amount`;
+  `IAbxConfigureHook.onParamConfigured` gained `dataLength` + `dataBlobAddress`.
+
+  **Additive:** `ParamHooksFrozen` folds into `ParamHooks.locked`; `paramSchemaHead` + `selectOption`
+  replace pulling a whole option table to resolve one index; `readParamHooks`; `abxJs()` / `gunzipScript()`
+  on the generator for piecewise document assembly; and the three ERC-1155 ABIs now carry
+  `MetadataUpdate` / `BatchMetadataUpdate` / `DefaultMaxSupplySet`, which were emitted but not decodable.
+
+- 1b6b741: Transfer-validator authorization has one home, and the five affected trust anchors move
+
+  `CreatorToken1155.setTransferValidator` performed no authorization at all, and the library it
+  delegates to performed none either. What protected the three edition token types was that each one
+  _overrode_ the setter to run the caller check first — one guard in three copies, sitting in front of
+  an unguarded mixin whose own comment claimed the tokens carried no override. Nothing deployed was
+  vulnerable, but a fourth edition type that simply inherited the mixin would have shipped an
+  unauthenticated `setTransferValidator`, which decides whether collectors' tokens can move at all.
+
+  The guard now runs in the mixin, the overrides are gone, and the function is no longer `virtual` —
+  so the arrangement is enforced by the compiler rather than by a comment. A dead
+  `_requireMinterOrOwner` in `ExternalMinter`, whose NatSpec wrongly advertised it as the mint-time auth
+  check (the real one also enforces `paused()`), is deleted in the same pass.
+
+  **Both changes are source-only** — the compiled runtime bodies are byte-identical before and after,
+  measured across all ten affected artifacts. Only the metadata hash differs, and since that is part of
+  the initcode, the CREATE2 addresses move. Five factories and their implementations are redeployed and
+  re-verified on Sepolia and Base Sepolia: `SeriesImageFactory`, `SeriesCodeFactory`,
+  `OneOfOneEditionFactory`, `EditionImageFactory`, `EditionCodeFactory`. Everything else — the 1/1 image
+  factory, all four libraries, the renderer, chunk store, seed source, both minters, both generators —
+  keeps its address.
+
+  Projects deployed from the superseded factories keep working, but `abx` will report their anchor as
+  an older version. Redeploy from the anchors in the refreshed manifest.
+
+### Patch Changes
+
+- 1b6b741: `ABX_CHAIN` in a `.env` now actually selects the chain
+
+  Found by a cold sandbox agent: the creator asked for Sepolia, put `ABX_CHAIN=sepolia` in `.env`, and
+  got a **Base Sepolia** preview with no error. The agent scored it 3/5 and called it "a serious trust
+  problem for a tool whose entire pitch is 'here's exactly what would be deployed'". It was right.
+
+  `config.ts` derives `CHAIN` as a module-level const, so it evaluated while the import graph loaded —
+  before `main()` called `loadDotEnv()`. Every other setting escaped this by being read lazily inside a
+  function (`storageOptions()`, the signing key at send time), by which point `.env` was loaded.
+  `ABX_CHAIN` was the one eager read, and the worst one to lose: on a funded send it is a wrong-chain
+  deploy with real artifacts at an address nobody meant.
+
+  The same ordering hid a second symptom: `assertKnownChainEnv()` also runs at module scope, so a typo
+  like `ABX_CHAIN=mainnet` in `.env` read as "unset" and the CLI quietly used the default instead of
+  printing its "not a chain this toolkit ships / mainnet is not supported yet" refusal. Both are fixed
+  by loading `.env` before the chain is derived, and both are covered by tests.
+
+- 1b6b741: Externalize the code-custody READ surfaces into `AbxCodeLib` — B22 step 2, buying back the bytes the ERC-4906 audit fix spent
+
+  The audit remediation that made `OnChainMetadata`'s field writes emit ERC-4906 (closing a real finding:
+  that surface mutated `tokenURI` silently, so a correct indexer served the pre-edit document forever) cost
+  ~96 B per token, and `SeriesCode` and `EditionCode` had no room for it — both fell under the 150 B EIP-170
+  floor `contracts/test/CodeSize.t.sol` guards. That is precisely the trigger condition `docs/10-backlog.md`
+  B22 was written for, and step 2 was the prescribed answer.
+
+  The `IAbxOnChainScript` and `IAbxDependencies` view bodies now live in `AbxCodeLib`, next to the write
+  paths that were already there — `scriptChunkCount`/`scriptChunk`/`scriptLocked` and
+  `dependencyCount`/`dependencyByIndex`/`dependencyRegistry`/`dependenciesLocked`. The mixins keep the
+  functions (same signatures, same ABI, same ERC-165 ids) as **raw-calldata passthroughs** through a new
+  shared `AbxCodeDelegate` base, which forwards the call's exact calldata to the library and returns the
+  return data untouched. Storage still resolves in the token's own ERC-7201 namespaces and events still log
+  from the token — that is what `delegatecall` buys.
+
+  Raw, not typed, on purpose: B22 step 1 measured a _typed_ shell (`return AbxCodeLib.f(...)`) **growing**
+  the token by ~855 B, because decoding the library's return value and re-encoding it at the call site costs
+  more than the extracted body saves. The same mistake was made again during this remediation, on
+  `setTokenField`/`setContractField`, and reverted. The price of the raw form is that `AbxCodeLib`'s read
+  signatures are now part of every composing token's external ABI — same signature ⇒ same selector is the
+  whole mechanism — so they must track the interfaces verbatim; both the library and the mixins now say so.
+
+  EIP-170 margins, before → after:
+
+  | contract      | before | after   | floor |
+  | ------------- | ------ | ------- | ----- |
+  | `SeriesCode`  | 125    | **529** | 150   |
+  | `EditionCode` | 132    | **507** | 150   |
+
+  `AbxCodeLib` grew 3,905 → 4,961 B and still has ~19.6 KB to spare. Nothing else moved: `OnChainScript` and
+  `Dependencies` are composed **only** by `SeriesCode` and `EditionCode`, and both already linked
+  `AbxCodeLib`, so no contract gained a library dependency and the other four tokens are byte-identical.
+
+  No behavior change and no ABI change — the read signatures, return types, mutability, ERC-165 ids and the
+  `ScriptIndexOutOfRange`/`DependencyIndexOutOfRange` error selectors are all preserved (the errors stay
+  declared on the mixins so they remain in each token's ABI, and now revert from the library's
+  identically-named, identically-selectored twin). This does move the implementation bytecode, so it rides
+  the redeploy this remediation already requires: `AbxCodeLib`, both code tokens, and their factories (and
+  therefore the factory trust anchors) all get new addresses.
+
+- 1b6b741: CREATE2 for library deployments, as the standard process — and delete the false belief that said it was impossible
+
+  An audit found that two ERC-1155 token types were held library-free, and an EIP-170 size floor relaxed, on
+  the recorded belief that linking a delegatecalled library costs a factory its CREATE2-deterministic address.
+  That belief is false, and the committed broadcast artifacts always refuted it: every recorded library deploy
+  went through the keyless CREATE2 proxy, `AbxParamsLib` landed at ONE address on Sepolia and Base Sepolia
+  from deployer nonces **215 apart** (a nonce is not an input to a CREATE2 address), and both library-linked
+  factories have held chain-identical addresses across four deploy generations.
+
+  What was true was narrower and self-inflicted: `deploy.ts` deployed its libraries with `send({to: null})` —
+  a plain EOA `CREATE` — **by its own choice**, so _it_ could not predict them. `create2.ts` and both code
+  factory deploy functions then wrote that local limitation up as a property of libraries in general, and the
+  repo proceeded to contradict itself (`deployments.ts` and `reference/deployments.mdx` describe the correct
+  mechanism a few files away).
+
+  The SDK now does what the docs already claimed:
+
+  - Both bootstraps (`deploySeriesCodeFactory`, `deployEditionCodeFactory`) deploy every write-path library
+    through the keyless proxy at the canonical `AbxSalts` salts — `abx.lib.params.v1`, `abx.lib.code.v1`,
+    `abx.lib.edition.v1`, mirrored in `ABX_SALT` and pinned against `AbxSalts.sol` by a new test — and then
+    CREATE2 the linked factory at its own salt. **An SDK-bootstrapped chain and a forge-bootstrapped chain now
+    produce identical addresses** (verified: the SDK's predictions equal what
+    `DeployLibraries.s.sol --sig 'predict()'` prints).
+  - Idempotent, out of necessity rather than politeness: the proxy _reverts_ on an occupied address, so a
+    library already on-chain is linked against instead of redeployed — which is also what makes a partially
+    bootstrapped chain recoverable by re-running.
+  - New: `predictParamsLib`, `predictCodeLib`, `predictEditionLib`, `predictSeriesCodeFactory`,
+    `predictEditionCodeFactory`, plus exported `libPlaceholder` / `linkLibraries` / `LIB_FQN`. Both code
+    factories therefore gained the CREATE2 self-heal every other canonical anchor has — and need no version
+    probe for it, because code at a CREATE2 address is bytecode-bound to the build that predicted it.
+
+  **Fixes a real crash on the way past.** `deployEditionCodeFactory` could not succeed at all: it deployed
+  `abxEditionLibBytecode` raw, but `AbxEditionLib` itself delegatecalls `AbxParamsLib`, so its shipped
+  bytecode carries an unlinked `__$…$__` placeholder — not hex, so the RPC rejected it with an opaque
+  `Invalid byte sequence`. The old guard only checked the _factory's_ bytecode, never the library's. The
+  library is now linked before it is deployed, and `linkLibraries` throws with the offending placeholder named.
+
+  **The trap that IS real, now written down** (`create2.ts`, `reference/deployments.mdx`): a library's address
+  is a function of its creation bytecode, so build settings move it. Linking _after_ compilation — substituting
+  into solc's placeholder, what forge's automatic linking and the SDK both do — cannot change that bytecode.
+  Handing solc the addresses at build time (`--libraries src/…:Lib:0x…`) writes the map into
+  `settings.libraries` in every artifact's metadata, and the metadata hash is appended to the creation
+  bytecode: measured here, that moves the library's own address and the linked factory's initcode. Optimizer
+  profile does the same (the code tokens compile at 200 runs). Both failures are invisible until two chains
+  disagree, so the docs now say to compare `predict()` against the SDK's predictions rather than assume.
+
+  Docs and specs swept for the old claim: `reference/deployments.mdx` (the salts, and a "libraries go first"
+  bootstrap step naming `DeployLibraries.s.sol` and its `predict()` dry run), `reference/contracts.mdx`
+  (`AbxEditionLib` was missing from the library taxonomy entirely), `reference/sdk.mdx`,
+  `specs/self-host-toolkit/deployment.md`, and the `abx-self-host` skill's code-projects reference. No
+  addresses were invented: nothing is redeployed yet, and the two manifest-drift tests still stand as the
+  detectors waiting on it.
+
+- 1b6b741: `abx doctor` stops calling a dust balance "funded", and its provenance line stops guessing how you invoked it
+
+  Both found by cold agents in the clean room, one of them twice.
+
+  **Funding had two states where it needed three.** A wallet holding `0.000000000848940602 ETH` — 848
+  gwei, enough for nothing — reported as `funded`, in full wei precision, with no faucet link, because the
+  test was `balance > 0n`. An agent then spent its whole run preparing a deploy it could not send and
+  named the quiet funding signal as its top friction. Now: zero is `empty`, below 0.001 ETH is
+  `too little to deploy` with a faucet link, and anything above reads `funded` at six decimals instead of
+  eighteen. The floor is a readout threshold, **not** a refusal — we don't estimate anyone's gas, and a
+  cheap L2 deploy below it is the caller's call.
+
+  **The `binary` line said `source checkout (pnpm abx)`** even when the caller had typed a bare `abx` that
+  happened to resolve to a checkout. `source` was right; the parenthetical named an invocation that never
+  happened. It now says what is running rather than how you typed it. A provenance line that misstates the
+  invocation undermines every readout sitting next to it.
+
+  Not changed, deliberately: `deploy --dry-run` still refuses to print an address without `--salt`. An
+  agent asked for a non-final example address to skip the two-step dance, but the salt is the only thing
+  that pins the address, and printing a real-looking one that won't be the deployed address is the exact
+  failure that refusal exists to prevent.
+
+- 1b6b741: Editions: the buyer picks the work, and the skill stops promising a freeze we withdrew
+
+  **Say what the edition mint flow actually is.** The 721 Series lane and the edition lane answer "who
+  picks the work?" in opposite ways, and only the 721 half was written down. `IAbxSequentialMint` takes a
+  recipient and mints `nextTokenId` — nothing is selectable. The edition minter is keyed `(token, id)`, so
+  `purchase(token, id, …)` _names the work_, and on an `EditionCode` project each id carries its own
+  `seed`, drawn at that id's **first** mint because the seed belongs to the work rather than to a copy.
+  Choosing the id therefore chooses the seed. That is the product, not a leak: an edition is copies of a
+  known work, and seeing what you are buying is the normal case.
+
+  Two consequences are now documented rather than left to be discovered:
+
+  - Buying an **already-minted** id is choosing among settled, publicly readable works.
+  - Buying an **unminted** id draws its seed with the buyer's chosen `id` in the preimage — a real
+    selection surface (compute each candidate id's seed in a view loop, buy the best), bounded by which ids
+    have a configured sale and by `maxInvocations`. This is the same grinding surface the recipient `to` was
+    removed from the preimage to avoid, and `id` cannot be removed the same way, because it _is_ the
+    work. So `AbxSeedSource`'s "accept-or-decline, not choose" is now stated as the **721-lane** property
+    it is, everywhere it appeared (`protocol/code-projects`, `specs/protocol/code-projects`,
+    `specs/protocol/event-spine`, the skill).
+
+  **Creator mints the supply, then lists on secondary** is documented as a first-class way to run an
+  edition: no minter, no allocation, no pause to manage, and every seed settles under the creator's own
+  transactions. It needs nothing new — the owner may always mint, paused or not, up to the id-space and
+  per-id caps — and it composes with a sale (reserve to self, price the rest).
+
+  **The shipped skill's frontmatter no longer advertises "freeze/lock a project so it can never change"** —
+  the exact promise `SKILL.md`'s own body walks back. It now names what a lock actually freezes (fields, URI
+  config, script, dependencies) plus the new param-hook freeze, so the sentence that gets the skill _picked_
+  agrees with the sentence that tells the creator the truth. The router stayed a router: the seed paragraph
+  and the Solidity-lane paragraph were compressed to pay for the new material, with the depth in
+  `reference/code-projects.md`.
+
+- 1b6b741: Stop promising immutability the locks don't deliver — and name the residual owner powers in one place
+
+  **The claim that was wrong.** With the field lock, URI lock, contract-URI lock, script lock and
+  dependency lock _all_ engaged, the rendered output can still change, two ways. **Params have no lock at
+  all** — they aren't fields, so no field lock reaches them, and the renderer projects the whole enumerated
+  set into `tokenURI` as `abx_params` (a program reads the same set as `tokenData`). And a
+  **`Resolution.Registry` dependency is re-fetched from the registry contract on every read** —
+  `lockDependencies` freezes the ref and the registry pointer, not another contract's storage. `abx verify`
+  reported `chain-complete` on both sides of a registry swapping its library bytes, and the CLI was telling
+  people "a fully immutable code drop is lock-script + lock-dependencies + lock-field/lock-uri".
+
+  Every unqualified verdict is now qualified rather than deleted, because locking a pointer _is_ part of the
+  story: `lock-uri`, `lock-script` and `lock-dependencies` narration, their `--help` entries, `abx verify`'s
+  chain-complete pass (which now says the flag describes **where** bytes come from, not that they're frozen),
+  `GeneratorStatus.chainComplete`'s doc comment, the `lockScript` SDK docs, `protocol/metadata`,
+  `protocol/params`, `protocol/code-projects`, `reference/cli`, the operate guide, `specs/protocol/*`, and the
+  skill's SKILL.md · `reference/decisions.md` · `reference/code-projects.md` · `reference/operating.md`. The
+  line the toolkit now gives a creator is **"your metadata is locked"**, with the stronger claim reserved for
+  a project whose graph is on-chain `0x…` deps plus locked fields. Stated once per place the decision is made,
+  not restated everywhere.
+
+  Framed as a capability as well as a caveat: a token that _deliberately_ live-adapts to on-chain conditions
+  is a legitimate and interesting thing to build, and it's the same mechanism that makes it possible.
+
+  **New page: [What a project owner can do](https://abx.docs.artblocks.io/protocol/owner-powers/).** There was
+  nowhere a collector could read what powers the creator retains. It states both halves plainly, with the read
+  for each. What an owner **can** do: re-point or suspend an enrolled 721C/1155C transfer validator (and block
+  transfers entirely with one that reverts — though if they renounce ownership, anyone may suspend it and
+  nobody can re-arm it); change price, payee, allocation and pause on a live sale with no timelock; keep
+  receiving primary-sale proceeds after selling the project, because `primaryPayee` doesn't move on
+  `transferOwnership`; mint reserves outside the minter's allocation, since assigning a minter grants the whole
+  remaining cap rather than a slice; change royalty receiver and bps forever; re-point metadata subject to the
+  locks above; swap the seed source; reassign a token's seed _iff_ a `seed` schema was declared before the
+  collection's first seed existed; and walk away. What they provably **cannot** do: take a buyer's funds beyond
+  the terms that buyer signed for (`purchase`/`purchaseTo` require `expectedPaymentToken` and a maximum, and
+  revert `SaleTermsChanged`); exceed a supply or per-id edition cap; rewrite or clear a settled seed; reach
+  another project through any shared singleton (the renderer and chunk store hold no storage, the generator's
+  wiring is `immutable` with no setters, the seed source is a stateless view namespaced by caller, and the
+  minters key everything per token and hold no funds); or take a token out of a collector's wallet — there is no
+  owner-only transfer, burn, or clawback anywhere in the protocol.
+
+  Framing, deliberately: ABX is self-serve, the creator is a privileged role, the protocol's job is to keep
+  that role away from a collector's funds and tokens, and the residual powers are disclosed so a collector can
+  price them. Not an accusation — a creator who destroys their own collection has destroyed what they were paid
+  for. The point is that "trust me" should be optional.
+
+- 1b6b741: `minter configure` no longer tells an edition its minter is unassigned when it isn't
+
+  The readiness footer `abx minter configure` prints after configuring an edition sale read
+  `minter()`, `primaryPayee()` and `paused()` through the ERC-721 1/1 ABI, which has none of them. The
+  call threw client-side, the `.catch` swallowed it into a zero address, and a correctly-configured
+  edition was told to go run `set-minter` and `set-primary-payee` — both of which it had already done.
+
+  This is the same bug `minter show` had, fixed on 2026-08-05; only the show path was corrected then.
+  The footer now reads through the edition ABI, and a live regression test covers it, so the two paths
+  can't drift apart again.
+
+- 1b6b741: Gate on-chain content by what a node will READ, not by what it costs to write
+
+  The documented on-chain envelope — ≲24 KB/file, ≲256 KB/project — was a _storage-cost_ figure sold as a
+  support envelope, and the CLI's only loud warning fired on the project total. Measurement says the
+  binding constraint is somewhere else entirely: **`tokenURI` reassembles the whole document on every
+  call**, and that cost is **superlinear** — EVM memory expansion is quadratic, so the per-KB rate climbs
+  with size. Across the 10–100 KB range that decides most projects it measures **~360,000–405,000 gas per
+  KB**, rising to ~460,000/KB at 187 KB and ~510,000/KB at 256 KB. `inline` and `reader` land within ~1% of
+  each other up to 75 KB (the cost is the renderer's string building, not the storage mechanism) and
+  diverge above it (~5% at 187 KB, ~10% at 256 KB, as the chunk store's quadratic read loop takes over), so
+  `--compress fastlz` makes a field cheaper to write and not one gas cheaper to read.
+
+  Measured with `forge` (`OneOfOneImage` + `AbxMetadataRenderer`, callee execution gas for one `tokenURI`
+  call, `reader` staging at 22,000-byte chunks):
+
+  | on-chain content | `tokenURI` gas | per KB  |     | on-chain content | `tokenURI` gas | per KB  |
+  | ---------------- | -------------- | ------- | --- | ---------------- | -------------- | ------- |
+  | 3 KB             | 1,123,327      | 374,000 |     | 100 KB           | 40,254,159     | 403,000 |
+  | 10 KB            | 3,588,993      | 359,000 |     | 128 KB           | 53,559,735     | 418,000 |
+  | 23 KB            | 8,346,220      | 363,000 |     | 187 KB           | 86,021,071     | 460,000 |
+  | 40 KB            | 14,740,366     | 369,000 |     | 256 KB           | 131,269,134    | 513,000 |
+  | 50 KB            | 18,759,333     | 375,000 |     |                  |                |         |
+  | 75 KB            | 29,137,215     | 388,000 |     |                  |                |         |
+  | 90 KB            | 35,868,124     | 399,000 |     |                  |                |         |
+
+  geth's `--rpc.gascap` defaults to 50M, hosted providers commonly cap lower, and L1 block limits sit in
+  the mid-30-millions — so a project at the _documented_ ceiling could not be read by a normal node, and
+  from ~90 KB (~36M gas) up no contract can read it inside a transaction at all. Note what the 100 KB
+  refusal is: a **margin**, not the wall. 100 KB reads at ~40M, and geth's own 50M default is not
+  exhausted until ~120 KB; the refusal sits early because hosted providers cap well below geth.
+
+  The gate now sits on that axis, per token (each `tokenURI` assembles only its own content, so a
+  300-piece collection of 5 KB works is fine while one 256 KB work is not):
+
+  - **from ~40 KB — warn.** Reads need a deliberately high-gas RPC.
+  - **past ~100 KB — refuse**, with `--allow-unreadable-onchain` as the override. The refusal names the
+    three ways forward and says plainly what the override accepts: rendering needs a high-gas endpoint and
+    most marketplaces and indexers will show nothing. It fires on the **dry run** too, so a creator meets it
+    before spending gas rather than after the first staging transaction.
+
+  Live on every path that puts bytes on-chain: `deploy --onchain-image`, `deploy-series --onchain-image`,
+  both `--copies` edition twins, and `set-field --file`. New in the SDK: `classifyOnchainReadSize`,
+  `tokenUriGasEstimate` (fitted to the measurements, so it tracks the superlinearity instead of
+  multiplying by a flat rate), `TOKEN_URI_GAS_PER_KB_LOW` / `TOKEN_URI_GAS_PER_KB_HIGH` (the measured
+  10–100 KB envelope — there is deliberately no single flat `TOKEN_URI_GAS_PER_KB`, because there is no
+  single rate), `ONCHAIN_READ_WARN_BYTES`, `ONCHAIN_READ_REFUSE_BYTES`, `ONCHAIN_READ_GETH_CAP_BYTES`
+  (where geth's 50M default actually runs out, so the refusal can be described as the margin it is)
+  (`exceedsOnchainSoftLimit` stays, now documented as the _write_-cost predicate it always was). The
+  whole-collection 256 KB warning stays as well, relabelled as write cost only, since it never said
+  anything about readability.
+
+  Two things deliberately not done. **No on-chain guard and no gas check** — a read happens off-chain, a
+  read too large for one node is an RPC-capability problem, and bricking a contract is worse than needing a
+  capable endpoint. And the **code lane still only warns**, at the same 40 KB threshold and now quoting the
+  gas figure: `abx inspect`'s document size is an estimate that undercounts unknown dependencies, and a
+  registry-hosted library like p5 is legitimately ~200 KB, so the honest move there is to name the cost and
+  point at the generator's piecewise getters (`document`, `tokenDataJson`, `dependencyTag`, `abxJs`,
+  `gunzipScript`, `registryScriptChunk`) rather than block a shipped lane on a heuristic. Those getters are
+  now in the SDK's generator ABI, which claimed to carry "the piecewise reads" while omitting three of them.
+
+  The docs and the `abx-self-host` skill were swept in the same pass: `protocol/onchain-storage` carries the
+  measured table and the corrected envelope, `protocol/code-projects` gains a piecewise-read section, and
+  the skill's Quick start and `reference/decisions.md` lead with "40 KB is the number, not 256 KB" plus the
+  rule that the override is a creator's deliberate choice and never a way to clear a warning.
+
+- 1b6b741: Round-3 audit remediation: link the two ERC-1155 image anchors, and stop guarding by name
+
+  `EditionImage` and `OneOfOneEdition` became library-linked in the previous round, but neither the
+  SDK nor the forge scripts were updated. `predictEditionFactory()` and
+  `predictOneOfOneEditionFactory()` hashed **unlinked** bytecode — and viem does not reject a
+  `__$…$__` placeholder, it UTF-8-encodes it, so both returned a confident hash of ASCII garbage for
+  a trust anchor, and `ops.ts` would have broadcast that bytecode as initcode. Both now link
+  `AbxEditionLib` (itself linked against `AbxParamsLib`) and ensure the libraries exist first.
+
+  Two addresses move as a result: `EditionImageFactory` and `OneOfOneEditionFactory`. Both are
+  pre-launch and pending the redeploy gate.
+
+  This was the third instance of one bug class, and the existing guard missed it because it checked
+  two factories **by name**. The replacement is exhaustive by construction: it reverse-looks-up which
+  initcode each `predict*` actually hashed, drives every `prepareDeploy*` and every `deploy*`
+  orchestrator against a stub chain, and asserts no `__$` placeholder survives anywhere — so the next
+  library-linked contract is covered without anyone remembering to add it.
+
+  Also: every SDK deploy now goes through CREATE2 at a canonical salt (the 1/1 and Series anchors were
+  still plain `CREATE`, landing at nonce-dependent addresses that could never match the manifest), and
+  the CLI no longer tells creators an ERC-1155 edition emits no ERC-4906 — both lanes emit it now.
+
+- 1b6b741: Warn when an explicit `--salt` has an all-zero guard prefix
+
+  The factory reads a salt's leading 20 bytes as an access guard: the caller's own address means only
+  that signer may deploy with it, all-zero means anyone may. Omitting `--salt` gives you the pinned
+  form. But only `abx predict` ever explained this — the deploy commands took an explicit `--salt`
+  verbatim and said nothing.
+
+  So a creator who pinned a vanity salt with a zero prefix and announced the predicted address was
+  handing it to whoever deployed there first, and the front-runner ends up as `owner()`, because
+  ownership is set by `initialize` rather than by the prediction. The 2026-08 security review
+  reproduced that.
+
+  It warns rather than refuses: a zero prefix is the right choice for a deliberately shared,
+  caller-independent deployment. The check lives in the flag parser, which is the one place every
+  command passes through.
+
+- 1b6b741: Say the honest thing about the mint seed: pseudorandom, not lottery-grade
+
+  The canonical `AbxSeedSource` stopped hashing the recipient (`to` is accepted and ignored) because a
+  buyer names the recipient in `purchaseTo`, which turned a caller-supplied field into a search space —
+  grind candidates in a view loop, buy once at the winner. Dropping it removes cheap _targeting_, and
+  nothing more: the seed is still derived entirely from on-chain values, so it is **deterministic after
+  the fact** (replayable from the block — the property that makes generative output verifiable) and
+  **not secret before it** (a contract minting in the same transaction can compute the seed it would
+  receive and revert unless it likes the result).
+
+  The docs and the toolkit now say that where a creator decides, instead of implying more than the
+  contract delivers:
+
+  - `deploy-code --help` spells out what `--no-seed` opts out of, and the deploy plan prints the same
+    note beside the `seed source` line it already showed — on the 721 and edition lanes both.
+  - The `abx-self-host` skill gained a one-paragraph router entry in **Code projects** and a
+    **Seeds — pseudorandom, not lottery-grade** section in `reference/code-projects.md`: fine where the
+    seed diversifies output and the distribution is the product, not fine for a raffle, a prize draw,
+    or any drop where one rare outcome is worth materially more than mint price. The escape hatch is
+    named rather than hinted at — the creator's own `IAbxSeedSource` over commit-reveal or a VRF oracle,
+    which is a per-project swap, not a fork of ABX (and is now reachable as `--seed-source` /
+    `abx set-seed-source` — see the companion entry).
+  - Both also document the seed's new governance rule: a `seed` param schema can only be declared
+    **before the collection's first seed exists**, so whether a seed's value may be re-set — and by
+    whom — is a pre-sale commitment a buyer reads with `paramSchema("seed")` (or `abx state`), not
+    something added after a sellout. That schema is deliberately **not** described as a "re-roll":
+    the governed write is `configureTokenParam(tokenId, "seed", value)` and the caller supplies the
+    value, so it is a chosen seed, not a fresh random draw.
+
+  The public docs (`site/content/docs`), the protocol specs, and `contracts/README.md` were swept in the
+  same pass; no claim that the seed is "unpredictable" survives anywhere.
+
+- 1b6b741: Fix `abx skill install` and `abx scaffold-renderer` on a published npm install
+
+  Reported from the field on v0.1.0-alpha.21: `abx skill install` — the canonical way to install the
+  agent skill, and the first thing the quickstart tells you to run — failed on every fresh global npm
+  install with `✗ bundled skill not found`. The reporter's diagnosis was exactly right.
+
+  `resolveBundledSkill()` computed the package root as
+  `resolve(fileURLToPath(import.meta.url), '..', '..')`. That is correct for a module compiled to
+  `dist/main.js` and off by one for `dist/commands/scaffold.js`, which is a level deeper — so it landed
+  on `dist/` and looked for `<pkg>/dist/skill`. The assumption was written when the function lived one
+  level up and quietly broke when it moved into `commands/`.
+
+  Two more instances of the same root cause came out with it:
+
+  - **`abx scaffold-renderer` was broken the same way** and had not been reported — it looked for
+    `<pkg>/dist/assets/renderer-scaffold`.
+  - **The "am I running from source?" guard** matched `/src/<one-segment>$`, so it read false for
+    anything under `src/commands/`. On its own that was harmless; together with the root fix it would
+    have made a dev run prefer `<pkg>/skill` — gitignored prepack output — over the canonical skill,
+    which is how the canonical skill once got overwritten by a copy eight versions behind.
+
+  Nothing caught any of it because a dev run never has the published layout: running from source, both
+  resolvers fall back to the repo copies and work regardless of the arithmetic. So the fix is structural
+  rather than a third `..`: one `packageRootFrom()` that walks up to the CLI's own name-checked
+  `package.json`, depth-independent by construction, plus `packaging.test.ts` — which builds a published
+  layout in a temp dir and walks it from several depths, and fails the build if counted-`..` root math
+  comes back in any spelling.
+
+  Workaround on alpha.21, if you're on it:
+  `cp -r $(npm root -g)/@artblocks/abx-cli/skill ~/.claude/skills/abx-self-host`
+
+- 133ecbc: Add `abx submit-app` — optional post-deploy listing in the ABX App Store.
+
+  Not folded into deploy. After a collection exists, the agent offers it, confirms catalog copy with the creator (name / summary / description — not the collection's NFT metadata), then mints through the gated minter and writes params in gas-capped batches. Already-claimed collections skip the mint (same as `/update`). Shipped Base Sepolia registry + minter; override with `--registry` / `--minter`.
+
+- 1b6b741: The param transfer hook is a veto, not best-effort — say so everywhere, and ship the lock that answers it
+
+  The transfer hook used to swallow its own revert, and every surface promised that the parameter
+  lifecycle "must never block a transfer". That promise could not be kept, so it is withdrawn rather than
+  restated: Solady runs the ERC-721/1155 **receiver acceptance check after the hook**, so on the `safe*`
+  variants — which marketplace fills wrap — a hook that is cheap when a wallet estimates gas and expensive
+  when the transfer lands starves the work that comes after it, with or without a gas cap. Swallowing
+  bought a guarantee that was false in exactly the cases people use, while making an honest hook's failure
+  invisible.
+
+  So the contract now calls the hook plainly (no swallow, no gas budget, no assembly), **its revert fails
+  the transfer**, and — because a mint and a burn are transfers from/to `0x0` — a reverting hook also stops
+  minting for that project, including through the shared minter. That is deliberate: a hook is always the
+  creator's own contract, which is why it may block issuance while the transfer _validator_, usually a
+  third party's, never sees mint or burn.
+
+  The mitigation is a lock, and it is now reachable end to end:
+
+  - **SDK** — `prepareLockParamHooks({contract, chainId})`, the sibling of `prepareLockScript` /
+    `prepareLockDependencies`. Plus two reads: `readParamHooks` (the trio) and `readParamHooksLocked`,
+    which establishes the freeze without a getter by simulating `setParamHooks` with the current trio and
+    watching for `ParamHooksLocked` — and returns `undefined`, never a cheerful `false`, when a node won't
+    answer.
+  - **CLI** — `abx lock-param-hooks <address>`. Owner-only, one-way, every signing lane, `--dry-run`
+    guarded. It prints the exact three addresses it will freeze, states what is given up (arming a
+    transfer veto, arming a configure veto, re-pointing or clearing the augment hook) and that there is no
+    way back, and distinguishes the two cases: freezing an **empty** set is how a project _proves_ it can
+    never arm a transfer veto, while freezing a set that already contains a hook pins which contracts can
+    run — it does not disarm them.
+  - **`abx state`** now prints the three hooks and whether they are frozen, next to the transfer validator,
+    because that pair is the read a buyer performs. `abx verify` warns on an armed-but-unfrozen transfer
+    hook. `abx set-param-hooks` states the veto at the moment a transfer hook is armed.
+  - **Reconstruction** — `ParamHooksFrozen` folds into `ProjectState.paramHooks.locked`. The event is
+    declared only by `AbxParamsLib`, so `spineEventAbi` now unions that ABI (its other events dedup away):
+    without it the one-way lock on a hook that can veto a transfer was invisible to every consumer that
+    folds the spine.
+
+  Swept for the withdrawn promise: `protocol/params` (which gained a section on why it died),
+  `protocol/owner-powers` (the hook is now on **both** lists — an unlocked hook set as a live power, a
+  frozen one as a guarantee), `specs/protocol/event-spine`, `specs/protocol/user-stories`, the spine event
+  doc strings, and the `abx-self-host` skill (`SKILL.md`'s lock bullet plus the operating and code-project
+  references). No surface still says "best-effort", "reverts are swallowed", or "never blocks a transfer",
+  and a CLI test now fails if one comes back.
+
+- 1b6b741: Transfer validator: preflight what the chain actually refuses, and stop calling `setTransferValidator` owner-only
+
+  Two corrections, both in the direction that was costing someone something.
+
+  **The preflight was a bare `getCode`, and the chain's check is not.** `validateTransfer` returns nothing,
+  so there is no ABI decode to fail — which means any address whose fallback succeeds for an unknown
+  selector passes a has-code check and then waves **every** transfer through, while ERC-165,
+  `getTransferValidator()` and the extension beacon all report enforcement as ON. A Safe does exactly this
+  (`FallbackManager.fallback()` returns empty when no handler is set), as do an uninitialised proxy and a
+  7702-delegated EOA, and a creator pasting their own Safe is the likely real case. The contract's guard was
+  rewritten to probe with a selector no validator implements and require it to **fail**; the toolkit now
+  asks the same question, with the same selector, through the new SDK `probeTransferValidator` (verdicts:
+  `ok` · `no-code` · `permissive-fallback` · `unreachable`). Both call sites use it — `abx
+set-transfer-validator` and `deploy --721c` — so a creator gets a refusal that names what is actually
+  wrong instead of passing the CLI and reverting on chain against an error whose documented meaning ("no
+  code on this chain") was false for their address.
+
+  **`setTransferValidator` is owner-only only while there is an owner.** Once `owner() == address(0)`
+  **anyone** may suspend enforcement by passing `address(0)`, and nobody may ever arm a validator again —
+  the dead-man release for a validator that reverts every transfer on a collection with nobody left to
+  re-point it, which would otherwise strand every collector's token permanently. Four surfaces still said
+  owner-only, and the SDK's was wrong in the direction that matters: an integrator reading it would refuse
+  to build the suspension a stranded holder needs. Corrected in `creator-token.ts` (module header plus
+  `prepareSetTransferValidator`), `protocol/royalty-enforcement`, `protocol/interfaces`, and
+  `specs/protocol/interfaces`, each stating the asymmetry: an ownerless collection can only ever be moved
+  _toward_ transferability, so this hands a stranger no power over a live project.
+
+- Updated dependencies [1b6b741]
+- Updated dependencies [1b6b741]
+- Updated dependencies [1b6b741]
+- Updated dependencies [1b6b741]
+- Updated dependencies [1b6b741]
+- Updated dependencies [1b6b741]
+- Updated dependencies [f64a31f]
+- Updated dependencies [1b6b741]
+- Updated dependencies [1b6b741]
+- Updated dependencies [1b6b741]
+- Updated dependencies [1b6b741]
+- Updated dependencies [1b6b741]
+- Updated dependencies [1b6b741]
+- Updated dependencies [1b6b741]
+- Updated dependencies [1b6b741]
+- Updated dependencies [1b6b741]
+- Updated dependencies [1b6b741]
+  - @artblocks/abx-sdk@0.1.0-alpha.14
+  - @artblocks/abx-token-api@0.1.0-alpha.17
+  - @artblocks/abx-indexer@0.1.0-alpha.15
+  - @artblocks/abx-storage@0.1.0-alpha.14
+
+## 0.1.0-alpha.21
+
+### Patch Changes
+
+- 528c6c6: Close most of the ERC-1155 edition CLI parity gaps (B28), give every command one unknown-flag posture
+  (B30), and add the per-holder edition balance read (B31).
+
+  Each B28 item was checked against the tree before any code was written: **none needed a Solidity
+  change.** The contracts and SDK ops were already per-id and standard-neutral, so all of this is CLI
+  plumbing and **no redeploy, address churn, or Etherscan re-verification is involved.**
+
+  **Edition custody is now symmetric with the 721 side** — each lane verified live on testnet, not just
+  by dry run:
+
+  - **`deploy-series --copies` gains pattern 2: off-chain image, on-chain JSON, nothing to run.** The 721
+    Series had the whole branch; `EditionImage` never got it, so a multi-artwork **raster** edition had no
+    no-server option at all. A uniform file extension uploads the folder as ONE directory and bakes a
+    single `{id}`-substituting collection field, so the collection costs one field instead of N; mixed
+    extensions fall back to per-id `url` fields. Verified at
+    `0x4e7e2d1aA951d99046323a620a2a5891b1195452`, where `uri(0|1|2)` resolve to `…/0.png`, `…/1.png`,
+    `…/2.png` off one template and all three fetch at their source byte sizes. This gap had real design
+    consequences: a cold agent asked for "3 artworks × 25 copies each", hit the SVG-only refusal, and
+    split the collection into **three separate single-artwork contracts** to get the permanence it wanted.
+  - **`--onchain-image` works on both edition lanes, on the hot AND wallet lanes.** It was refused
+    outright on `deploy-series --copies` and hot-lane-only on `deploy --copies`; one sign session now
+    covers the chunk writes plus the deploy, and the staging txs are counted in the `approvals` line the
+    session's own total is derived from. Verified at `0x0A71382207a980c23E26a54F2b815072da41761A`:
+    `uri(id)` returns a `data:image/svg+xml;base64` image with zero `http(s)` anywhere in the document.
+    `EditionImage` also now treats `--onchain-image` as implying on-chain resolution — every sibling lane
+    already did, and without it the flag would have demanded a resolver URL for a drop whose bytes are
+    already on-chain.
+  - **`deploy-code --copies` accepts on-chain `--dep`/`--dep-registry`.** `EditionCode` already inherited
+    the `Dependencies` extension and called `_initDependencies()`; the legs come from the SDK's shared
+    `dependencySetupCalls`, so the two lanes cannot encode `setDependency` differently. So "an edition of
+    my p5 sketch, with p5 coming from the chain" is a real lane now — verified on Sepolia at
+    `0xC403CB9B956Ca814F1934d8d2A44fc1D2023EFB3`, where `abx verify` reports **chain-complete — every
+    dependency resolves to proven on-chain bytes; no server, gateway, or CDN in the graph**, with a 233 KB
+    inline `animation_url`.
+  - **The cold lane stays refused for `--onchain-image`**, deliberately and identically on all four paths:
+    staging is a sequence where each chunk tx's receipt feeds the next, so it cannot be signed offline.
+    This replaces an edition-specific "tracked as a follow-up" note with the real, shared reason.
+
+  Still open on the edition lanes, and recorded in B28: `deploy-code --copies` has no `--code-dir` or
+  field renderers, and `deploy-code --resume` has no edition path (that one is genuinely new per-id diff
+  logic, not a port).
+
+  **Every command now has one unknown-flag posture.** Roughly 35 commands — `state`, `add`, `index`,
+  `migrate`, `configure-param`, `set-field`, `set-royalty`, `set-minter`, `pause`/`unpause`, `verify`, … —
+  silently ignored an unrecognized flag, so `abx set-royalty --bsp 500` did something quietly different
+  from what was asked. Allowlists now live in one file and are applied once in the dispatcher; it warns
+  rather than refuses (a false refusal would break a working script, and `deploy*` still refuses via its
+  own exhaustive sets).
+
+  The obvious implementation — deriving each allowlist from the command's own `usage` string — was tried
+  and **rejected on evidence**: shared helpers read flags that appear in no usage string anywhere
+  (`storageOverrides()` reads twelve, pulled in by six commands; `--remote-token` by five), so deriving
+  would have warned on valid flags. That is worse than the silence it replaces, because a notice people
+  learn to distrust stops working for the real cases too. The sets are explicit instead, composed from
+  named groups, and a test reads each command's `--help` to assert every flag it **documents** is accepted
+  — the direction that would produce false warnings.
+
+  **`abx tokens <addr> --holder 0x..`** adds a `held` column — `balanceOf(holder, id)` per id, a live head
+  read. It answers the one question supply/cap cannot, and the one a funded agent had to leave blank after
+  transferring a copy (it correctly declined to fabricate the recipient's balance rather than guess).
+  Refused on a 721, where the owner column already answers it. Also: `deploy-series`' `[2] On-chain
+renderer` step now prints the renderer address instead of an empty header, and `abx verify` no longer
+  ends in two ⚠ on a healthy fully-on-chain **image** drop (the code-project checks are scoped to the code
+  twins; a static drop has no program and no `animation_url` by design).
+
+- 528c6c6: ERC-1155 editions: the trust-anchor and on-chain-URI checks told the truth about 721s only, and four
+  membrane gaps around them (2026-08-05 wave-4 agent sweep — 12 cold agents, one funded end-to-end run
+  on Base Sepolia).
+
+  The 1155 contracts themselves were fine: a funded run took an edition from deploy through
+  `tokenuri` → mint more copies → transfer one copy → lower the per-id cap, verifying every step
+  against the chain. What shipped wrong was everything that _describes_ an edition.
+
+  - **`abx verify` reported EVERY canonical edition as `canonical: NO`.** `detectCanonicalFactory`
+    probed only the three 721 anchors and, on no match, fell back to the 721 1/1 factory — whose
+    `isAbxClone` answers **false**, not "unknown". So the one signal platforms allowlist against was
+    confidently inverted for the entire edition line (the function's own docstring promised
+    "canonicity just shows unverified, never wrong"). All six anchors are now probed. **Editions
+    registered before this fix keep the wrong factory in the local projection** — `abx forget <addr>`
+    then `abx add <addr>` re-detects it.
+  - **`abx verify`'s on-chain-URI probe called the ERC-721 `tokenURI` selector on editions**, which
+    exposes `uri(id)`. It reverted for every edition, so verify could never confirm that a
+    fully-on-chain edition resolves — and it printed the raw multi-line viem dump (Contract Call /
+    args / Docs / Version) into a creator-facing readout. The probe now switches on `contractType`
+    (matching `reconstruct.ts`, which already did), reports which accessor it read so an edition is
+    never described in 721 terms, and readout errors are trimmed to their first line.
+  - **An address with no contract was reported as a specific type: `OneOfOneImage`.**
+    `detectTokenKind`'s three probes are each `try/catch → false`, so nothing-deployed and
+    no-extensions-composed were indistinguishable and the ladder fell through to its `1of1` default.
+    `abx set-max-supply` and `abx minter buy` then told edition owners _"…is a OneOfOneImage (721) —
+    drop your edition flags"_ for a mistyped address or, far more often, the wrong `ABX_CHAIN` (the
+    default is base-sepolia, so any Sepolia contract hit this immediately) — advice that removes the
+    _correct_ flags. The existence check now lives inside `detectTokenKind`, so all 13 call sites
+    inherit it; it fails **open** on an unreadable `getCode`, so an RPC blip never becomes a
+    "no contract" claim.
+  - **`abx transfer --token-id <n>` silently transferred id 0.** `transfer` spells the id `--token`
+    while every sibling command (`mint`, `set-max-supply`, `minter …`) spells it `--token-id`, and an
+    unrecognized flag was simply ignored — so an agent that learned the name from `mint` moved the
+    **wrong artwork** with no warning. `--token-id` is now an accepted alias; disagreeing values are
+    refused rather than silently preferring one.
+  - **The edition deploy previews dropped lines their 721 twins print.** All three edition lanes
+    omitted `approvals N wallet approval(s)` from the dry-run readout — which the skill promises "every
+    preview" prints and tells the agent to state up front, so on an edition the agent had nothing to
+    tell the creator about how many wallet prompts were coming (`deploy-code --copies` had it only in
+    the `--confirm` sentence, which is off by default). `deploy --copies` and `deploy-series --copies`
+    also omitted the "resolves ON-CHAIN via the renderer — no resolver, no server" line, which is
+    precisely the guarantee an edition creator is asking about, and `deploy-series --copies` never
+    showed `paused`. All six lanes now print the approval count; the 1155 paths say `uri()`.
+  - **Owner-op writes now surface a stray flag instead of swallowing it.** `mint`, `transfer`,
+    `set-max-supply`, and `minter configure|show|buy` warn on an unrecognized flag (warn, not refuse —
+    per `unknownFlags`' contract, a false warning must never break a script). These are the commands
+    where the 1155 semantics live in _optional_ flags that default rather than fail: a typo'd
+    `--amount 50` minted 1 copy and a typo'd `--quantity 5` bought 1 and paid 1×, both in total
+    silence. The broader gap — ~35 commands with no unknown-flag notice at all — is filed as B30.
+
+  A second verification sweep (six more cold agents, one funded) confirmed each fix above from a fresh
+  start and turned up four more, all fixed here:
+
+  - **A supply cap could be raised in `--dry-run` and only revert on send.** Both twins —
+    `set-max-invocations` (721) and `set-max-supply` (1155) — printed the new cap as fact for a value
+    the chain forbids, then reverted for real. A clean dry run is read as permission to send. Both now
+    read the current cap first and refuse up front; the 1155 side also refuses a cap **below** live
+    supply (the second way it reverted). Both guards fail **open** on an unreadable getter, since the
+    chain enforces the invariant anyway. (The 721 guard needed the Series ABI — reading `maxInvocations`
+    through the 1/1 ABI that `read()` uses throws, which would have made the guard silently never fire.)
+  - **`abx refresh` told edition owners ERC-4906 had already pinged marketplaces.** An ERC-1155 edition
+    emits no ERC-4906 at all — that is precisely why `ping-uri` exists — so the one sentence a creator
+    reads after editing metadata said "already handled" when nothing had been, and `ping-uri --help`
+    said the opposite. Two commands contradicting each other on the new lane. `refresh` is now
+    kind-aware and names `ping-uri` for editions.
+  - **`abx verify` ended in two ⚠ on a perfectly healthy fully-on-chain image drop** — "generator
+    reports NO code" and "no animation_url" — because the code-project lane runs whenever a tokenURI
+    renderer is set, which is true for every on-chain project, image or code. A static image has no
+    program and no `animation_url` by design. Three separate agents named this as the worst thing about
+    `verify`, and one said plainly it would make a creator distrust future real warnings. The code-lane
+    checks are now scoped to the code twins; a static drop gets one informational line instead. (This
+    was pre-existing on the 721 path too, not an editions regression.)
+  - **`EditionImage`'s SVG-only refusal was a thinner copy of its 721 twin's** — the Series version names
+    three routes (`--onchain-image`, `--backend ipfs|arweave`, or host off-chain); the edition version
+    said only "drop `--onchain-uri`". A cold agent asked for "3 artworks × 25 copies each" read that,
+    concluded there was no no-server option for one contract, and **fanned the collection out into three
+    separate single-artwork contracts**. The refusal now states the real options for the lane and says
+    explicitly that the off-chain-image-URL-in-on-chain-JSON route exists only per-artwork via
+    `abx deploy --copies` — one contract per artwork, not one collection. The underlying capability gap
+    is recorded in B28.
+
+  One knock-on from the first fix: the `false` branch of the canonical readout said _"not a clone of the
+  **configured** factory"_ (singular), which now understates the check and misdirects the reader — six
+  anchors are probed, so a `false` means no trust anchor the CLI knows deployed this contract, and the
+  usual real cause is a **superseded** factory or a hand-deployed contract, not a misconfiguration. It
+  now says so, and points at `abx doctor` for the current anchors.
+
+  Also: `deploy --help` no longer calls the edition sale stack (`--minter`/`--primary-payee`/
+  `--unpaused`) "required" — it is optional, and an agent handed a creator hardcoded addresses as
+  mandatory because of it; `set-field --help` now lists all eleven `--representation` values (it showed
+  seven, omitting `url-template`, `renderer`, `sha256`, `inline-gzip`); and `abx doctor`'s label column
+  widened so `edition factory` no longer runs into its address.
+
+  The skill-drift ✗ now names **which** copy is stale and prescribes the command that actually clears
+  it — `abx skill install` writes the project-local copy only, so a stale **global** copy produced a ✗
+  whose own remedy could not fix it. Six agents hit it in one sweep; several re-ran the install
+  repeatedly and one left its sandbox to read `~/.claude/skills` to work out what the tool meant.
+
+- 528c6c6: Wave-6 validation sweep: stop three help strings from denying features that work, make `storage show`
+  honor the flags it advertises, and name the byte custody on both Series lanes.
+
+  Nine cold agents re-drove the edition surface after the B28/B30/B31 work. **Every new lane is reachable
+  and no re-run regressed** — the situation that previously fanned "3 artworks × 25 copies" out into three
+  separate contracts now reports _"Contracts deployed: 1, not 3"_; `--onchain-image` + edition + browser
+  wallet went 4/5 at Haiku after being refused outright; the on-chain-dep edition lane went 3/5 → 4/5; the
+  wrong-chain diagnosis went 2/5 → 3/5 on the strength of the new monotonic-cap guard. **B30 produced zero
+  false warnings across all nine**, including a run that control-tested the mechanism with a deliberate
+  bogus flag, and a funded run that exercised ~10 commands with real writes.
+
+  What the sweep found was mostly **documentation still describing behavior the same branch had replaced** —
+  the failure mode a test suite cannot catch, because tests assert what the code does and none of them read
+  the prose that tells an agent what to try:
+
+  - **`deploy --help`** said `--onchain-image` is "hot lane only on an edition (not yet wired for `--sign`)".
+    It works on the wallet lane. Now states the real rule: hot and `--sign` both work; `--unsigned` is
+    refused everywhere, 721 and edition alike, because each chunk tx's receipt feeds the next.
+  - **`deploy-code --help`** listed `--dep`/`--dep-registry` among flags "refused in code" for `--copies`.
+    They work. An agent verified all four flags directly and called this out as _"the dangerous direction:
+    it would talk a creator out of a feature that actually works."_ Now says they work, and names the
+    Sepolia-only registry constraint.
+  - **The `EditionImage` SVG-only refusal** — a message rewritten earlier in the same branch — still said
+    `--onchain-image` "is not wired on the edition-series lane yet", after that branch wired it. It now
+    lists all four real routes for raster art in one contract.
+  - **`abx refresh`'s ERC-4906 claim had no edition caveat** in the skill or `site/using-abx/guides/operate`,
+    even though the CLI itself was made kind-aware earlier in the branch. The skill's _"`abx refresh` is the
+    only nudge"_ was flatly false for an edition, where `ping-uri` is required.
+
+  Two real product fixes, both surfaced by the new warning doing its job:
+
+  - **`abx storage show` now honors `--backend`/`--gateway`/the rest of the storage override set.** It read
+    env-only while its own output said _"choose per command: `--backend` … `--gateway`"_ — advertising flags
+    it then discarded and always reporting `backend: fs`. This was invisible until every command grew an
+    unknown-flag notice, which correctly flagged it (the flags really were ignored). A resolution preview
+    that can't preview a resolution is the one thing it exists to do. Provenance now reports `--backend` as
+    a source, alongside env and default.
+  - **Both `deploy-series` lanes now name the byte custody** (`storage: ipfs (--backend) — byte custody for
+the image(s)`), as the 1/1 lane always has. A creator asking for "images on IPFS" had no way to confirm
+    from the preview that their collection would pin there; the flag was accepted in silence.
+
+  Also documented, not changed: the ids × copies arithmetic. `deploy-code --copies 100` takes its id space
+  from `--max`, which **defaults to 16** — so "an edition of 100" without `--max 1` means up to 16 different
+  variations × 100 copies each. The dry-run states the real shape (`up to N id(s), M copies each`) and always
+  did; nothing taught the translation, so the skill now does, for all three commands.
+
+  Three legibility nits were routed to B32 rather than fixed: `abx state` naming a contract "Series" where a
+  refusal calls it "SeriesCode"; the Base-Sepolia default appearing only in a subordinate clause of the
+  "no contract" error (three straight waves have lost time to it); and `--onchain-image` on a folder of large
+  rasters honestly reporting 35 wallet approvals with no nudge toward the cheaper lane.
+
+  Two agent claims were checked and **rejected** so they don't get "fixed" into regressions: the skill does
+  _not_ say `--onchain-image` is refused on an edition series (it documents the `--unsigned`-only refusal
+  correctly), and `abx predict` does _not_ silently pick the 721 factory without `--copies` — it labels the
+  lane, yields a different address, and echoes `--copies` in its reproduce line.
+
+- Updated dependencies [528c6c6]
+  - @artblocks/abx-sdk@0.1.0-alpha.13
+  - @artblocks/abx-indexer@0.1.0-alpha.14
+  - @artblocks/abx-storage@0.1.0-alpha.13
+  - @artblocks/abx-token-api@0.1.0-alpha.16
+
 ## 0.1.0-alpha.20
 
 ### Minor Changes