@artblocks/abx-cli 0.1.0-alpha.31 → 0.1.0-alpha.33

package/skill/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "ABX"
+  short_description: "Launch and operate ABX NFT projects"
+  default_prompt: "Use $abx to plan and safely execute this ABX project workflow."

package/skill/reference/capabilities.md

@@ -0,0 +1,187 @@
+# Capability questions and extension seams
+
+Use this reference before answering whether ABX can support an unusual mechanic. The goal is neither
+automatic optimism nor reflexive refusal; it is a proven route with explicit cost and limits.
+
+## Contents
+
+- [Use the four-way classification](#use-the-four-way-classification)
+- [Inspect the machine-readable contract](#inspect-the-machine-readable-contract)
+- [Use canonical extension seams](#use-canonical-extension-seams)
+- [Map mechanics to seams](#map-mechanics-to-seams)
+- [Respect deploy-time prerequisites](#respect-deploy-time-prerequisites)
+- [Know the supported boundary](#know-the-supported-boundary)
+
+## Use the four-way classification
+
+Classify the request as one of:
+
+1. **Native** — a current CLI command/flag combination performs it directly.
+2. **Extension** — a custom minter, hook, field renderer, seed source, or transfer validator performs
+   it while the token remains a canonical factory clone.
+3. **Unsupported/foreclosed** — the capability contract lists it as unsupported, or the existing
+   contract's immutable type/options exclude the prerequisite.
+4. **Unknown** — no supported route has been demonstrated. Inspect help, implementation/contracts,
+   and state; report uncertainty if it remains unproven.
+
+Never infer “unsupported” from the absence of a flag. Never infer “possible” merely because an item is
+absent from a short no-list. A capability claim needs a native lane or an exact extension seam.
+
+Give the creator the route, engineering required, authority model, gas/hosting/reach tradeoff,
+irreversible prerequisites, and verification plan. “Possible” without those qualifiers is not useful.
+
+## Inspect the machine-readable contract
+
+Run:
+
+```bash
+abx capabilities --json
+abx help <relevant-command>
+```
+
+The capability contract reports native deployment lanes, EditionCode/static edition differences,
+extension seams, deploy-time choices, and currently unsupported product boundaries. For an existing
+collection, also run `abx state`; capability depends on the contract already deployed, not only on
+what the newest CLI could deploy today.
+
+Use a deploy command's `--dry-run --json` for a concrete plan. It is the source of truth for the
+active chain, artifacts, signer, storage, addresses, transaction count, and measured warnings.
+
+## Use canonical extension seams
+
+A custom mechanic normally lives beside a canonical token rather than replacing it.
+
+| Seam | Wired with | Runs | Can veto? |
+|---|---|---|---|
+| Custom minter | `abx set-minter --minter 0x…` | before/calling issuance | it controls whether it calls mint |
+| Configure hook | `abx set-param-hooks --configure 0x…` | before a governed parameter write persists | yes |
+| Transfer hook | `abx set-param-hooks --transfer 0x…` | on mint, transfer, and burn | yes |
+| Augment hook | `abx set-param-hooks --augment 0x…` | while token data is assembled | no; computes/adds/overrides data |
+| Image/traits renderer | deploy-code renderer flags | while on-chain metadata fields render | a revert can break that read; design never-revert |
+| Seed source | `abx set-seed-source` | future code-token mints | supplies mint-time seed input |
+| Transfer validator | `--721c` then `set-transfer-validator` | standards-track transfer validation | yes, according to validator |
+
+One external contract may implement several hook/minter roles. Test it against a real deployed clone,
+not a mock that approximates ABX callbacks.
+
+ABX scaffolds a Foundry renderer project but does not compile or deploy custom Solidity. The creator
+or their contract engineer owns code review, deployment, verification, upgrade policy, and audits.
+
+### Custom minter
+
+Series and editions can authorize one minter contract. Use it for pricing/allocation rules that do not
+fit the shared fixed-price minter: auctions, allowlists, raffles, free claims, ERC-20 payment, escrowed
+issuance, or other pre-mint logic. The minter eventually calls the token's canonical mint entry point.
+
+A plain 1/1 has no Series minter seam. Decide whether the requested issuance model actually requires
+a Series/edition before deploying.
+
+### Configure hook
+
+The configure hook receives the proposed typed parameter write before it persists. Its revert rejects
+the write. It can enforce monotonicity, one-time writes, cross-contract authorization, payload shape,
+or size bounds. For blob-backed strings/bytes, validate length before reading large data and read the
+provided data pointer using the documented SSTORE2 convention.
+
+The previously stored value remains visible during validation, enabling comparisons. A rejected
+write may still have paid for preparatory blob storage; front ends should simulate before asking for a
+signature.
+
+### Transfer hook
+
+The transfer hook runs for mints (`from == 0`), ordinary transfers, and burns (`to == 0`). Reverting
+vetoes the entire operation. It can implement vesting, soulbinding, redemption, escrow settlement,
+provenance counters, and lifecycle rules.
+
+It cannot initiate a transfer; it only observes or rejects one. Burn-based mechanics require the
+collection to have been deployed burnable. On editions, ids may have many holders, so shared per-id
+state cannot model a single current owner.
+
+### Augment hook
+
+The augment hook is a read-time view seam. It may read other contracts, an oracle, block state, or
+stored params and return final token-data strings. Use it for live/derived state or computed data that
+should not be stored.
+
+Volatile augmentation makes the live view change without an event or stored write. A marketplace still
+remains a snapshot until it is rendered again. If a custom Solidity field renderer needs augmented
+state, it must read/call the relevant hook/state itself; field-renderer calls do not receive a prepared
+token-data object.
+
+## Map mechanics to seams
+
+| Request | Primary route | Prerequisites/limits |
+|---|---|---|
+| Auction, allowlist, raffle, free claim | custom minter | Series or edition mint authority |
+| ERC-20 priced mint | custom minter | payment logic/audit outside ABX |
+| Soulbound or timed transfer lock | transfer hook | deploy-code; hook also sees mint |
+| Burn-to-redeem/combine | external controller/minter + burnable; optional transfer/augment hooks | ABX provides seams, not the atomic combine implementation |
+| Escrow tied to token lifecycle | minter + transfer hook | external value-holding contract |
+| Monotonic level/high-water mark | governed param + configure hook | schema and old-value comparison |
+| Structured collector configuration | governed param + configure hook | typed payload and bounded size |
+| Holder of another token may configure | schema address auth or configure hook | cross-contract read |
+| Art reacts to oracle/block/other contract | augment hook or renderer direct read | disclose live/non-deterministic behavior |
+| Timed reveal | augment hook or renderer logic | live view versus still refresh distinction |
+| On-chain SVG and coherent traits | image + attributes renderers | never-revert Solidity implementations |
+| Large raster stored on-chain | `--onchain-image` | measured write cost and endpoint-dependent read reach |
+| Royalty-aware transfer validation | ERC-721C/ERC-1155C validator | opt-in at deploy; marketplace compatibility varies |
+
+When several routes work, prefer the smallest authority surface. Use the stock fixed-price minter
+instead of custom Solidity for an ordinary sale; use a schema without a hook when static authorization
+is sufficient; use an on-chain renderer only when its durability/reach/cost trade is desired.
+
+A transfer hook only observes or vetoes a burn; it does not initiate two burns or mint a replacement.
+For combine mechanics, prove the controller's burn authorization and canonical mint call against a
+real clone, make the transition atomic and replay-safe, and define pair/history storage. On ERC-721,
+`--max` is a lifetime id cap and burns do not reopen slots, so reserve replacement-id headroom or use
+a supply policy that does not require new ids. On a burnable edition, a burn frees live per-id supply,
+but every copy of an id shares its id-level seed and PostParams.
+
+## Respect deploy-time prerequisites
+
+Ask about mechanics before deployment. These decisions cannot be retrofitted:
+
+- static versus code-capable contract type; hooks/PostParams require SeriesCode or EditionCode;
+- ERC-721 versus ERC-1155 edition shape through `--copies`;
+- burnability;
+- ERC-721C/ERC-1155C enrollment.
+
+Other choices may be mutable but become irreversible when locked: URI configuration, fields, script,
+dependencies, hooks, governed values/schema, royalty ceiling, and owner authority. An existing project
+may therefore be capable in protocol terms but foreclosed by its current type or locks. Say that
+specifically instead of saying ABX as a whole cannot do it.
+
+Use `abx predict` to break address cycles where an external controller needs the token address at its
+own construction and the token must reference the controller during deployment. Confirm the guarded
+salt/deployer and predicted address before deploying either side.
+
+## Know the supported boundary
+
+The toolkit currently does not provide:
+
+- mainnet deployment or unsupported-chain recipes;
+- a secondary-market listing/order-book feature;
+- Solidity compilation/deployment through `abx`;
+- CLI replacement of a deployed code project's script;
+- retrofitting a deploy-time contract type, burnability, token standard, or creator-token enrollment.
+
+Do not recommend another protocol automatically when one of these applies. State the boundary and
+stop unless the creator asks for alternatives.
+
+Also distinguish unsupported tooling from possible external engineering. For example, ABX does not
+compile a custom hook, but a hook is an intentional supported seam once independently built and
+deployed. Conversely, “arbitrary Solidity exists” is not proof that every behavior is safe or
+compatible: analyze callback timing, authority, reverts, reentrancy, shared edition state, gas, and
+upgradeability.
+
+Before finalizing a custom mechanic, document:
+
+1. canonical token family and deploy-time prerequisites;
+2. external contracts and their roles/owners/upgrade paths;
+3. callback inputs, state transitions, and every veto path;
+4. mint/transfer/burn behavior including editions;
+5. parameter schema and authorization;
+6. live versus settled/rendered state;
+7. locks and the exact guarantee they create;
+8. unit, fork, and end-to-end test plan;
+9. collector-facing disclosure of remaining powers.

package/skill/reference/code.md

@@ -0,0 +1,210 @@
+# Code projects, renderers, and PostParams
+
+Use this reference for `preview`, `inspect`, `deploy-code`, JavaScript/build projects, Solidity field
+renderers, marketplace stills and traits, seeds, dependencies, parameters, and code-project locks.
+
+## Contents
+
+- [Choose the runtime lane](#choose-the-runtime-lane)
+- [Design every public surface](#design-every-public-surface)
+- [Preview and inspect honestly](#preview-and-inspect-honestly)
+- [Plan JavaScript projects](#plan-javascript-projects)
+- [Plan Solidity field renderers](#plan-solidity-field-renderers)
+- [Use PostParams and hooks](#use-postparams-and-hooks)
+- [Handle seeds and dependencies](#handle-seeds-and-dependencies)
+- [Verify and freeze](#verify-and-freeze)
+
+## Choose the runtime lane
+
+`deploy-code` selects a code-capable canonical contract. It supports four useful input shapes:
+
+| Shape | Core flags | Typical surfaces |
+|---|---|---|
+| On-chain JavaScript template | `--script <file>` | on-chain program; hosted or on-chain assembled live document |
+| Build directory | `--code-dir <dir>` | uploaded application bundle; resolver/live view |
+| Solidity-computed fields | `--image-renderer` and/or `--attributes-renderer` | on-chain SVG image and/or traits |
+| Hybrid | script plus field renderers | program animation plus Solidity image/traits |
+
+Without `--copies`, the contract is SeriesCode (ERC-721). With `--copies <n|open>`, it is EditionCode
+(ERC-1155): N generated ids, each with multiple copies. EditionCode currently supports scripts,
+dependencies, and field renderers. It does not support `--code-dir`, `--image-base`, or `--resume`.
+Run `abx capabilities --json` immediately before planning.
+
+For one generated work with 100 copies, use `--max 1 --copies 100`. Omitting `--max 1` leaves the
+default multi-id space, producing multiple generated ids with 100 copies available for each id.
+
+A creator who needs parameters or hooks must use a code-capable contract even if the output is a
+static-looking SVG or image. This is a deploy-time type decision.
+
+## Design every public surface
+
+A code project is not one URL. Decide each surface separately:
+
+- **Program/animation** — the live JavaScript document or absence of one.
+- **Marketplace image** — a rendered still, a deterministic image URL, an on-chain Solidity SVG, or
+  an explicit placeholder during development.
+- **Marketplace traits** — renderer-computed JSON, resolver/effects output, or intentionally omitted.
+- **PostParams** — canonical typed state on the token contract, consumed by the program/renderers.
+- **Attachments** — named files served through a resolver's artifacts/data surface.
+
+“The program is on-chain” does not prove that image and traits are on-chain. “The animation works”
+does not prove a marketplace thumbnail exists. Write a surface matrix before deployment and verify
+each row after minting.
+
+## Preview and inspect honestly
+
+Use `abx preview` while authoring and `abx inspect` before choosing a deployment lane.
+
+Preview uses the canonical runtime envelope, dependency order, and token-data shape with synthetic
+inputs. It is a high-fidelity authoring preview, not an end-to-end deployment proof. It does not prove:
+
+- that a chosen dependency resolves on the target chain;
+- that the deployed generator or renderer fits an RPC's read allowance;
+- that real minted seeds and PostParams are consumed correctly in every state;
+- that marketplace metadata contains image and attributes;
+- that a hosted resolver/effects/storage path is reachable.
+
+Use `--shoot` for representative frames. Exercise more than the default seed and every user-facing
+parameter. Then run `abx inspect` to analyze dependencies, deterministic seed usage, declared traits,
+document size, and lane fit. Treat findings as evidence and the deploy dry run/testnet verification as
+the final proof.
+
+Avoid unseeded randomness, wall-clock dependence, environment-only assets, and network fetches when
+claiming reproducibility. A live-data design is valid; label it live rather than deterministic.
+
+## Plan JavaScript projects
+
+### On-chain program, hosted resolution
+
+Use `--script` with `--public-base-url` when a resolver should assemble the live document and expose
+mutable metadata/render surfaces. The script remains on-chain; the public metadata path is HTTP.
+This is normally the most interoperable lane for a sale where thumbnails must update continuously.
+
+Run an effects service for derived stills and traits:
+
+- `abx effects` runs locally and blocks; use it for development or a co-located operator.
+- `abx deploy-effects --resolver-url <url>` scaffolds a continuously running service.
+- `abx render <addr> [ids] --remote <resolver>` performs a one-shot/backfill render.
+
+The renderer must store its bytes in a backend the resolver can retrieve. A hosted resolver cannot
+read a laptop-local `fs` store. Managed providers may advertise managed rendering; confirm with
+`abx remote <name>` rather than assuming it.
+
+### On-chain program and on-chain live document
+
+Use `--script --onchain-uri` when the generator can assemble the animation document entirely from
+on-chain program/dependency bytes. This can remove an always-on resolver for the live program.
+
+Check the deploy dependency report and `abx verify` before calling it chain-complete: a registry
+dependency may resolve through a CDN instead of on-chain bytes. Large assembled documents may exceed
+some endpoints' `eth_call` allowance; report the measured reach, not “any RPC forever.”
+
+For a JavaScript lane, the marketplace image remains a separate decision. With no resolver watcher,
+a still published to a deterministic public `--image-base` is a manual/backfill surface: rerun render
+after relevant parameter changes. An on-chain animation plus automatically updating off-chain still
+requires an operator watching state.
+
+EditionCode does not currently accept `--image-base`. Give it an on-chain image renderer, or run a
+resolver/effects path (`deploy-effects` for continuous rendering; `render --remote` for one-shot
+publication). Do not treat its on-chain animation as a marketplace still.
+
+### Build directory
+
+Use `--code-dir` for an application bundle whose files are uploaded and addressed as a code artifact.
+It requires external storage and public resolution. Inspect the built output, not only the source
+tree, and verify that every referenced asset is included. `--code-dir` is not yet supported with
+`--copies`.
+
+## Plan Solidity field renderers
+
+`--image-renderer <address>` stores an `IAbxFieldRenderer` pointer for the metadata image field;
+`--attributes-renderer <address>` does the same for traits. With `--onchain-uri`, the canonical
+metadata renderer calls them on-chain. A renderer-only project needs no JavaScript program and no
+effects runner.
+
+Start with `abx scaffold-renderer`, then build, test, and deploy the Solidity project using Foundry.
+ABX does not compile or deploy custom Solidity. A real deploy refuses a renderer address with no
+code.
+
+Enforce these invariants in renderer tests:
+
+- `render(token, tokenId, field)` must not revert for unminted ids, missing params, boundary values,
+  unexpected callers, or retired schema state.
+- Return the correct media type and valid complete content: SVG for image, JSON attributes array for
+  traits.
+- Derive image and traits from the same seed/state model.
+- Bound loops and output. Test realistic worst cases through an RPC call, not only local unit gas.
+- Treat a renderer or hook address lock as a pointer lock. Use immutable deployments for stronger
+  permanence claims; an upgradeable proxy can change behavior behind a locked address.
+
+Solidity image/attributes renderers work on both SeriesCode and EditionCode, including renderer-only
+editions. They eliminate off-chain stills only for the fields they compute; a separate JavaScript
+animation may still exist.
+
+## Use PostParams and hooks
+
+PostParams are typed, schema-governed state stored on-chain. Use `--schema` at deployment or
+`abx set-schema` later, then `abx configure-param` through the governed path. Inspect current type,
+authorization, and lock grammar with command help instead of memorizing it.
+
+Model parameters deliberately:
+
+- Define a stable key and type; do not change a key's meaning across versions.
+- Choose creator, token-owner/holder, or address authorization to match the actual state model.
+- Validate input in the UI and again in a configure hook when the rule must be enforced on-chain.
+- Treat string/bytes values as potentially large and price/limit them appropriately.
+- Retire or weld a governed parameter only after the current value and defaults are verified.
+
+### Edition shared state
+
+On EditionCode, parameters belong to an **id**, not an individual physical copy. If token id 3 has
+100 holders, they all read the same value for id 3. With holder authorization any holder may write it;
+the last valid writer wins. This is good for communal state and wrong for “name my personal copy.”
+Use one id per personalized work when per-holder state is required.
+
+A holder-writable large string/bytes parameter can also expand the shared id's metadata beyond common
+RPC read reach. State this before deployment and use schema validation/hooks to bound it when needed.
+
+### Hooks
+
+SeriesCode and EditionCode expose three configurable hook addresses:
+
+- configure hook: validates/vetoes governed writes before they persist;
+- transfer hook: observes every mint, transfer, and burn and may veto the operation;
+- augment hook: computes additional/overriding token data during reads.
+
+Hooks are extension seams, not ordinary CLI flags. Build and deploy them outside ABX, wire them with
+`abx set-param-hooks`, test against a real clone, and read [capabilities.md](capabilities.md). A
+transfer-hook revert fails mints as well as secondary transfers. Freeze the addresses with
+`abx lock-param-hooks` only after testing every lifecycle transition.
+
+## Handle seeds and dependencies
+
+Seeds are generated at mint and drive reproducible variation. `abx inspect` identifies common seed
+misuse, but test multiple real token-data fixtures. A custom seed source affects future mints and is
+an external contract pointer; verify its code/interface and disclose who can change its behavior.
+
+Dependencies are ordered; index 0 is the runtime. A `name@version` reference resolves through the
+collection's dependency-registry pointer, while a `0x…` reference reads a data contract directly.
+Registry availability is chain-specific. Read the deploy dependency report: a named dependency can
+be valid yet served from a CDN, which means the document is not chain-complete.
+
+`lock-dependencies` freezes the reference list and registry pointer, not necessarily the bytes a live
+registry entry returns. Use immutable on-chain data contracts for a stronger frozen-dependency claim.
+
+## Verify and freeze
+
+After deploying and minting representative ids:
+
+1. Read `abx state`, `abx tokens --json`, and `abx tokenuri`.
+2. Open the animation/live view using actual minted token data.
+3. Fetch the marketplace image and inspect `attributes` from token metadata.
+4. Run `abx verify` and resolve placeholder, chain-complete, dependency, or render warnings.
+5. Change every intended parameter through its authorized path; confirm still refresh behavior.
+6. Exercise mint, transfer, and burn paths if hooks or burnability are involved.
+7. Verify dependency and renderer addresses and whether their code is upgradeable.
+8. Lock only the surfaces the creator has explicitly chosen to freeze.
+
+A fully frozen code-project posture may involve URI/field locks, `lock-script`,
+`lock-dependencies`, `lock-param-hooks`, and governed parameter locks. Those locks cover different
+state. Describe exactly what each freezes; never summarize them as “the output can never change.”

package/skill/reference/creator-token.md

@@ -1,99 +1,94 @@
-# Royalty enforcement — opt-in creator token (ERC-721C / ERC-1155C)
-
-[← back to SKILL.md](../SKILL.md)
-
-**Read this ONLY because the creator brought it up** (royalty enforcement, "make OpenSea pay my
-royalties", ERC-721C/ERC-1155C, transfer restrictions, a transfer validator). If they didn't, this file
-has no business in the conversation: **plain ERC-721 (or plain ERC-1155, for an edition) is the default
-and the recommendation**, every deploy flow already does the right thing with zero `--721c` flags, and
-offering enforcement unprompted reads as a nudge toward a restricted asset. Never present `--721c` as a
-checklist item, a "should we also…", or a row in the deploy readout for a creator who never asked.
-
-**Same flag, both standards.** `--721c` is the one flag for creator-token enrollment everywhere — on a
-721 deploy (`deploy`/`deploy-series`/`deploy-code` with no `--copies`) it enrolls **ERC-721C**; on the
-same commands with `--copies` (an edition) it enrolls **ERC-1155C** instead. Same validator registry,
-same recommended validator, same permanence rule, same UX — only the ERC-165 discovery ids and the
-per-transfer call differ, both invisible to a creator (below).
-
-## The stance (how to frame it when asked)
-
-- **Plain ERC-721 — or plain ERC-1155 for an edition — is the more sovereign asset (the default)**:
-  no third-party contract on the transfer path, tradeable everywhere, nothing anyone — creator
-  included — can later switch off. ABX royalties are already on-chain via ERC-2981
-  (`abx set-royalty`); marketplaces *choose* whether to honor them.
-- **721C/1155C is enforcement for creators who specifically want it**: transfers are checked by a
-  validator contract, and sales that don't route through an authorized venue revert. It is a real
-  trade-off, decided at deploy, **permanently** — present it transparently, recommend it only when
-  the creator's stated goal is enforcement, and get an explicit yes before enrolling.
-- **The honest market picture (2026) — say it, don't oversell**: enforcement via 721C effectively
-  means **OpenSea** plus venues on Limit Break's Payment Processor. OpenSea's own help docs say
-  enforcement limits sales to those venues; Magic Eden's EVM marketplace shut down March 2026, and
-  Blur never honored 721C. The trade: enforced royalties on OpenSea, in exchange for not trading on
-  venues the validator doesn't authorize.
-
-## What enrolling does (the facts to relay)
-
-- **Deploy-time, permanent, both directions.** A plain ABX token (721 or 1155) can **never** grow
-  transfer restrictions later (that's a feature — collectors of unenrolled tokens keep that promise
-  forever), and an enrolled one never sheds the standard. No retrofit exists; the only path to
-  enrollment for a live plain collection is a redeploy.
-- **Suspend ≠ un-enroll.** The owner can re-point the validator or set it to zero (enforcement off,
-  token **stays** enrolled — the owner can re-enable any time). Collectors can see enrollment via
-  ERC-165, suspended or not.
-- **Mints and burns are NEVER validated** — no validator policy can brick minting, the shared
-  fixed-price minter (721 or edition), or a delegated minter.
-- **The recommended validator** (`--721c recommended`, or bare `--721c`) is OpenSea's
-  StrictAuthorizedTransferSecurityRegistry — the same registry, same address, for both standards.
-  Under it, owner-initiated wallet-to-wallet transfers pass; non-authorized operators revert. One
-  decision, done.
-- **On an edition, validation is per `(id, amount)`, not per token.** ERC-1155C's validator call
-  carries the transferred amount and isn't a view (unlike 721C's), and a batch transfer loops one
-  validator call per id — invisible to a creator, but the reason a large batch transfer on an
-  enrolled edition costs more gas than an unenrolled one.
-
-## Commands
+# ERC-721C / ERC-1155C transfer validation
+
+Use this reference only when the creator asks about creator-token standards, transfer validation,
+royalty-enforcement compatibility, validator selection, or changing/suspending validation.
+
+## Separate three mechanisms
+
+- **Royalties** declare a receiver and basis points through the token's royalty interface. They do
+  not force a marketplace to pay.
+- **Creator-token enrollment** opts the collection into ERC-721C or ERC-1155C validation at deploy.
+  Transfers consult a validator selected by the owner.
+- **ABX transfer hooks** are code-project extension callbacks and may implement arbitrary project
+  lifecycle rules. They are not creator-token validators.
+
+These mechanisms can coexist and may each reject a transfer for a different reason. Diagnose the
+actual contract state and revert path.
+
+## Enrollment is deploy-time
+
+Pass `--721c recommended|0x…` on the selected deploy command to create the creator-token variant. The
+same flag chooses the ERC-1155C twin when `--copies` selects an edition. Absence creates the ordinary
+ERC-721/ERC-1155 family.
+
+Enrollment cannot be added or removed after deployment. Ask before spending:
+
+- Does the creator actually want standards-track transfer validation?
+- Which validator and security policy should govern transfers?
+- Is the intended marketplace/wallet flow compatible on the target chain today?
+- Who may later change or suspend the validator?
+- Is the stronger restriction worth the interoperability and owner-power tradeoff?
+
+Do not default into enrollment merely because the creator set a royalty. Do not present it as a
+guarantee of payment across all marketplaces.
+
+## Select and validate the validator
+
+`recommended` resolves the toolkit's current recommended creator-fee validator for the active chain.
+An explicit address must be a deployed validator contract that actually implements the expected
+interface and rejects unsupported calls. A Safe, EOA, empty proxy, or permissive fallback is not an
+enforcement policy even if it has code.
+
+Let the CLI probe the address. Do not bypass a refusal with a raw transaction. For a custom validator,
+review and test:
+
+- transfer behavior for owner, approved operator, marketplace conduit, and ordinary recipient;
+- mint and burn behavior where the standard invokes validation;
+- upgrade/administration powers and who controls them;
+- failure behavior when external registries are unavailable;
+- ERC-721 versus ERC-1155 amount/batch semantics;
+- interaction with an ABX transfer hook.
+
+Marketplace allowlists, registry addresses, and supported flows change. Use current command output,
+the validator's primary documentation, and a testnet transaction rather than a dated compatibility
+table in this skill.
+
+## Operate an enrolled collection
+
+Read current enrollment and validator state with `abx state`. Use:
 
 ```bash
-# Enroll at deploy — all three deploy commands take the flag (absent = plain, forever):
-abx deploy|deploy-series|deploy-code … --721c [recommended|0x<validator>]
-# On an edition deploy (--copies), the SAME flag enrolls ERC-1155C instead — nothing else changes.
-abx deploy --copies <n|open> … --721c [recommended|0x<validator>]
-
-# Operate an ENROLLED collection (owner-only, any signing lane, --dry-run works):
-abx set-transfer-validator <addr> 0x<validator>   # re-point enforcement
-abx set-transfer-validator <addr> none            # suspend (stays enrolled)
-abx set-transfer-validator <addr> recommended     # the chain's recommended validator
-
-abx state <addr>   # shows a "721C validator" row ONLY when enrolled ("suspended" when zero);
-                    # an enrolled EDITION shows the same row labeled "1155C validator" — same
-                    # ERC-165 id + getter on both standards, so detection is identical
+abx set-transfer-validator <address> recommended
+abx set-transfer-validator <address> 0x...
+abx set-transfer-validator <address> none
 ```
 
-Enrolling prints one plain statement of what enforcement means — relay it, don't embellish. An
-un-enrolled deploy prints nothing about 721C/1155C.
-
-**One exception to "owner-only", worth knowing before you tell a collector they're stuck:** once a
-collection's `owner()` is the zero address (renounced), **anyone** may send the `none` (suspend) form,
-and **nobody** may ever arm a validator again. It's the release valve for an abandoned collection whose
-validator reverts every transfer — the only thing a stranger can do is make the tokens transferable, never
-the reverse. So a creator who plans to renounce should hear the trade: "renounced **and** still enforcing
-royalties forever" is not a state this protocol offers.
-
-## Refusals the CLI enforces (don't fight them; relay the reason)
-
-- **`--721c none`/zero at deploy** — refused: a zero validator never enrolls, and "enrolled but
-  suspended" is not a deploy-time state. Plain (721 or 1155) is already the default; drop the flag.
-- **`--721c recommended` on a chain with no known validator** — refused, naming the chains that have
-  one. Pass an explicit deployed validator address instead; never guess one.
-- **A validator address that isn't a validator** — refused before any gas at deploy AND at re-point
-  (the contract reverts `InvalidTransferValidator()`); a mixed-case address must pass its EIP-55
-  checksum. **Two shapes are refused, not one:** no code at all, and an address that answers *any*
-  call successfully — a **Safe**, an uninitialised proxy, or a 7702-delegated EOA. `validateTransfer`
-  returns nothing, so there's no decode to fail and such an address would enforce nothing while
-  `getTransferValidator()` and ERC-165 both reported enforcement as ON. If a creator offers their Safe
-  address, that's the refusal you'll get — relay it as "that's a wallet, not a validator", and point at
-  `recommended`. A real deploy also refuses to enroll blind when the RPC can't answer (a dry-run
-  defers it).
-- **`set-transfer-validator` on a plain, unenrolled collection** — refused up front (721 or 1155):
-  enrollment is a deploy-time decision and this collection didn't enroll. Do not retry with different
-  flags; if the creator truly needs enforcement, that's a redeploy conversation.
+Run command help for current syntax and a dry run before writing. Setting `none` suspends the active
+validator where supported; it does not convert the contract back to a plain non-C token. Enrollment
+and the associated owner power remain part of the contract's permanent type.
+
+Before changing the validator:
+
+1. Read the current validator, owner, royalty, minter, and transfer-hook state.
+2. Explain whether the change tightens, loosens, or suspends transfer policy.
+3. Test representative transfers using the intended marketplace/operator on testnet.
+4. Receive exact human confirmation.
+5. Execute once and re-read state.
+
+If a transfer fails, do not clear the validator as a generic repair. Determine whether the failure
+comes from the creator-token validator, an ABX transfer hook, token ownership/approval, pause/mint
+rules, or the receiving contract. Changing enforcement is a policy decision, not troubleshooting.
+
+## Disclose owner powers precisely
+
+Collectors should know:
+
+- the collection is permanently enrolled in the creator-token variant;
+- the current validator address and whether it is upgradeable;
+- who can change or suspend that validator;
+- whether a separate ABX transfer hook can veto transfers/mints;
+- whether hook addresses are locked;
+- the royalty rate, receiver, and permanent ceiling.
+
+A locked ABX hook set does not lock the creator-token validator, and creator-token enrollment does not
+freeze royalties. List each power separately.