@artblocks/abx-cli 0.1.0-alpha.60 → 0.1.0-alpha.62

package/skill/SKILL.md

@@ -9,7 +9,7 @@ description: >-
   change an ABX collection, or to determine whether ABX supports a mechanic.
 compatibility: Drives @artblocks/abx-cli on Node 22.13+. Co-versioned with the CLI; install or refresh with `abx skill install`.
 metadata:
-  version: "0.1.0-alpha.60"
+  version: "0.1.0-alpha.62"
 ---
 
 # ABX
@@ -122,9 +122,11 @@ Important boundaries:
   renderers, `--image-base` (a deterministic per-id off-chain still, mutually exclusive with
   `--image-renderer`), and `--resume` (a per-id mint diff — pass the same content flags plus
   `--mint-amount` if the original deploy premint ids).
-- `--onchain-image` works for static 721s and editions in hot or wallet-signing lanes. It cannot be
-  prepared as one cold `--unsigned` bundle because staged transactions depend on prior receipts;
-  the `--sponsor` beta also excludes this staged-content lane.
+- `--onchain-image` works for static 721s and editions in hot, wallet, or sponsored lanes. It cannot
+  be prepared as one cold `--unsigned` bundle because staged transactions depend on prior receipts.
+- Deploy tested custom hooks/renderers from exact compiled initcode with `abx deploy-contract`.
+  ABX sends the bytes; it does not compile, link, audit, or infer constructor types. Test on the
+  paired testnet and source-verify before wiring a production address.
 - A code project may need no public host when its image/traits are computed by Solidity renderers.
   A JavaScript program still needs a deliberate marketplace-image plan even when its animation is
   chain-complete.
@@ -180,8 +182,9 @@ Classify an unusual request as exactly one of:
 4. **Unknown** — no route has been proven. Inspect code/help/contracts and report uncertainty; do not
    turn absence from a no-list into a promise.
 
-Custom Solidity is built and deployed outside `abx`; `abx scaffold-renderer` supplies a Foundry
-starting point. Read [capabilities.md](reference/capabilities.md) before designing a custom mechanic.
+Custom Solidity is built and tested outside `abx`; `abx scaffold-renderer` supplies a Foundry
+starting point, and `abx deploy-contract` can send its exact compiled initcode through any signing
+lane. Read [capabilities.md](reference/capabilities.md) before designing a custom mechanic.
 
 ## Load only the reference needed
 

package/skill/reference/capabilities.md

@@ -64,8 +64,9 @@ A custom mechanic normally lives beside a canonical token rather than replacing
 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.
+ABX scaffolds a Foundry renderer project but does not compile, link, or audit custom Solidity.
+`abx deploy-contract` can send exact compiled creation bytecode through any signing lane. The creator
+or their contract engineer owns code review, verification, upgrade policy, and audits.
 
 ### Custom minter
 
@@ -167,8 +168,7 @@ The toolkit currently does not provide:
 
 - operation on a chain whose capability entry is `disabled`;
 - a secondary-market listing/order-book feature;
-- Solidity compilation/deployment through `abx`;
-- CLI replacement of a deployed code project's script;
+- Solidity compilation through `abx`;
 - 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
@@ -176,7 +176,7 @@ 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
+deployed (including from exact initcode via `abx deploy-contract`). 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.
 

package/skill/reference/code.md

@@ -146,8 +146,9 @@ exclusive on both lanes.
 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
+Start with `abx scaffold-renderer`, then build and test the Solidity project using Foundry. Deploy
+with Foundry or send the exact compiled initcode through `abx deploy-contract`; ABX does not compile,
+link, audit, or infer constructor types. A real collection deploy refuses a renderer address with no
 code.
 
 Enforce these invariants in renderer tests:

package/skill/reference/deploy.md

@@ -38,7 +38,7 @@ Treat custody, resolution, and mutability as separate decisions.
 
 Use `--onchain-image [--compress fastlz]` for static media bytes behind the on-chain metadata
 renderer. It implies on-chain resolution and requires no host or storage provider. It works for 721
-static projects and their editions in hot or wallet lanes. It stages bytes before deployment, so the
+static projects and their editions in hot, wallet, or sponsored lanes. It stages bytes before deployment, so the
 plan has at least two transactions (more when content needs multiple chunks). Cold `--unsigned`
 staging is refused.
 
@@ -149,8 +149,8 @@ a substitute for confirming the actual sale configuration.
 For any edition, say “N ids × M copies per id” and the maximum aggregate supply before spending.
 
 Static edition custody is symmetric with the 721 lanes: on-chain bytes, on-chain JSON with external
-media, inline SVG, and hosted resolution are available. `--onchain-image` uses hot or wallet signing,
-not cold unsigned staging.
+media, inline SVG, and hosted resolution are available. `--onchain-image` uses hot, wallet, or
+sponsored signing, not cold unsigned staging.
 
 Do not import code-edition limits into static editions or vice versa. Use the capability output.
 

package/skill/reference/services.md

@@ -100,10 +100,12 @@ production-network warning before confirmation. Before using it:
    and beta status;
 5. after approval, repeat with `--sponsor`.
 
-The initial lane accepts zero-value factory/contract calls up to the provider policy and a hard
-3,000,000-gas transaction ceiling. It does not support direct CREATE or staged `--onchain-image`
-writes. Never add retries around a sponsored write. An `unknown` outcome means the provider may have
-submitted it: preserve the operation ID and reconcile status before any new send.
+The lane accepts zero-value factory calls, direct contract creation, and receipt-dependent staged
+content groups up to the live network and provider policy. ABX does not impose an additional
+per-transaction gas ceiling. Use `abx deploy-contract` for exact already-compiled creation bytecode;
+ABX does not compile or audit it. Never add retries around a sponsored write. An `unknown` outcome
+means the provider may have submitted it: preserve the operation ID and reconcile status before any
+new send.
 
 Sponsorship is optional service policy, not protocol support. `--send`, `--sign`, and `--unsigned`
 remain first-class bring-your-own alternatives. Honor an explicit choice of any of them. If the

package/skill/reference/setup.md

@@ -124,8 +124,8 @@ human the locally generated signing page; never request or handle their key. On
 chain, sender, target, calldata, value, and ordering before handing transactions over.
 
 `--onchain-image` staging cannot use the cold lane because each chunk transaction depends on the
-receipt of the preceding transaction. Use hot or wallet signing. Do not split staging into a homemade
-offline sequence.
+receipt of the preceding transaction. Use hot, wallet, or sponsored signing. Do not split staging
+into a homemade offline sequence.
 
 `ABX_DEPLOYER_PK` may be written with or without a `0x` prefix — the CLI and SDK normalize it. Foundry's
 `vm.envUint` does not: a custom forge script that reads the same `.env` needs the `0x` form.