feat(deploy): deploy via an existing factory — model and wizard flow

[alanhwu]

Implements #25.

Deploy contracts by calling an already-deployed factory, with every contract that call produces treated as a first-class deployment: predicted address, a step id later steps can point at, run artifact, and verification.

How products are discovered

A deploy function that returns addresses already declares what it creates, and names each one:

deploy(revenueToken, revenueRecipient, threshold, owner, configSetter, salt)
   outputs: jar:address, releaser:address

So the wizard reads the factory's ABI, lists the functions that could deploy, and reports what each produces — "this call deploys 2 contracts: jar, releaser" — rather than asking anyone to hand-write signatures.

The same fact solves prediction. An eth_call of that function — same arguments, same sender — returns the addresses it would create, so every product of a call is predicted at once, with:

• no predict helper required (the motivating factory exposes predictJar but no predictReleaser),
• no reconstruction of a salt the factory transforms (this one scopes it to msg.sender so callers cannot squat each other's addresses),
• no need to know a product's constructor arguments, which the factory supplies itself.

One call, several products

The transaction is a plain call step, and every product points at it — no product carries the call, so none is privileged:

call-factory      kind: 'call'   target: <factory>, signature: 'deploy(…) returns (address jar, address releaser)', args
product-jar       kind: 'deploy' strategy: { kind: 'factory', fulfilledBy: 'call-factory', output: 'jar' }
product-releaser  kind: 'deploy' strategy: { kind: 'factory', fulfilledBy: 'call-factory', output: 'releaser' }

Because every product is a real deploy step, pointers, the run artifact and verification work with no new concepts — a jar+releaser factory can have its releaser configured by later call steps even though nobody knows its address when the plan is written. The post-receipt path needed no change: any non-create strategy already means "the address is the predicted one, confirmed via getCode before the lane advances", which is exactly right for a factory call whose receipt carries no contractAddress.

The "Deploy via factory" flow

The wizard now has a first-class door: a Deploy via factory action on the Deployments page, beside "New deployment". It opens the wizard with the Contracts station replaced by a Factory setup step:

1. Pick the factory's own contract from a repo (ArtifactPicker) — its ABI drives everything; the factory itself is never deployed by the run.
2. Enter the factory's deployed address (per-chain overrides live on the generated call step, where the existing per-chain target UI already is).
3. Pick the deploy function from a dropdown of state-changing, address-returning candidates, each labelled with what it deploys.
4. Ignite states "this call deploys N contracts: jar, releaser" and asks for an artifact per output — the same ArtifactPicker, once per product. One artifact may back several outputs; product contract ids append the output name so they never collide.

The setup step is deliberately structure-only. The call's arguments are filled on the generated Factory call card in Steps, which has the full argument editor — real parameter names, pointers, signer fill, per-chain overrides — instead of a lesser duplicate in the setup (the stored signature keeps parameter names and the returns clause, so argument keys survive the trip through the plain call step and core still discovers products from the outputs). Product cards ask only for what the operator has power over: a factory supplies its product's constructor arguments onchain and Ignite builds no initcode for it, so the constructor and library editors are gone from factory products, and a fulfilled product — which sends no transaction of its own — also drops gas, value and signer, all of which live on the fulfilling call.

Continue materializes the canonical shape above into the draft and the rest of the wizard runs unchanged. Materialization is a reconciliation anchored on a call-step id minted when the flow starts: re-entering the Factory step and remapping an output replaces exactly that product, keeps operator edits to the call step, and never duplicates steps. Before materialization the setup fields edit staging state; afterwards the address binds directly to the generated call step, so the setup step and the step card cannot disagree.

Structural safety follows the model: a product cannot be moved above its call (fulfilledBy must resolve to an earlier step), the fulfilling call cannot be removed from under its products, its function is read-only on the call card (products read their addresses from its outputs; the Factory step is where the function changes), and deploying plain contracts from a repo abandons an un-materialized factory setup instead of mixing the two flows.

One entry point, deliberately

The per-step "Factory" strategy option is retired from the strategy picker. It was the wrong door: it forces the operator to declare "I am deploying TokenJar" before describing the call, and it cannot express the multi-product shape without hand-wiring fulfilledBy across step cards. Everything it could do, the flow does. What remains for steps that already carry the strategy (hydrated workflows, existing drafts): the option still displays, FactoryStrategyFields still renders for carry-the-call steps, and a fulfilled product shows which call deploys it instead of a dead form. Flow-generated plans round-trip through save-as-workflow and re-hydration (the new fulfilledBy branch in planFromDraft maps them back); the legacy carry-the-call form still does not round-trip (plan target vs draft factoryAddress), which is one more reason the flow is the single entry.

Fixes the flow surfaced

Walking the flow end to end against a live chain exposed four real gaps, each now fixed with a test written first:

• Factory drafts were silently lost on reload — the persisted-draft strategy union had no factory variant, so the whole session reset. Additive fix, no storage-key bump.
• ArtifactPicker could not see the session workspace — it listed only local/cloned/orphaned repos, so on a fresh setup (workspace-only, exactly where this flow starts) it rendered "No options found".
• Validation demanded constructor arguments from factory products (core/validation.ts) — but the factory supplies those onchain; every valid factory plan failed review. Products now skip the constructor check while the deploy call keeps full argument discipline (as the call step, or against the deploy function for a carry-the-call step).
• Factory-only plans showed no predicted addresses — the create2 item's "no create2 steps" early return dropped the eth_call predictions on the floor. They now flow into the review details, and the provisional chip prefers the prediction's own note ("returned by deploy(…)") over the misleading "mined during run".

Verified against a live chain

Full walkthrough on a local Anvil (chain 31337) with tjar's Factory actually deployed: Deployments → Deploy via factory → pick Factory + its address → deploy(…) → map jar→TokenJar, releaser→ExchangeReleaser → named args → Chains/RPC/Signers → Review. Review came back all green with one factory transaction scheduled, no transaction for either product, and both predicted addresses byte-identical to a direct cast call of the deploy function with the run's signer as sender. A call step added in Steps targeted the releaser through a pointer and simulated successfully via eth_simulateV1 — the pointer resolved to the predicted address and the call executed against the contract the simulated factory call had just created.

Testing

Core: factory.test.ts (10) and factorySchedule.test.ts for the model — including the canonical call-plus-products shape — plus new factoryValidation.test.ts (3) for the review fixes. Frontend: 34 new tests across the signature helpers (tuple expansion, product naming), the draft reducers (materialization, reconciliation, remap-replaces-one-product, structural guards), planFromDraft's fulfilledBy branch, draft persistence round-trips, the setup blocker, the entry action, repoChoicesFor, and the provisional label.

Suites: core 1340 passed (the 3 failures are the documented flaky repos/versionMaterialization.test.ts, failing on clean main with a different subset per run), frontend 310 passed (was 276), type-check clean in all three packages, @ignite/api builds. New files are prettier-clean; every touched existing file's formatting posture is unchanged (verified by stash/--check/pop diff). The pre-existing no-useless-escape lint error in artifact.ts reproduces on main.

Not included

Call-only runs — a plan with no deployment at all (a governance handoff or config batch against existing contracts) still requires at least one contract. Noted in #25 as a follow-up; nothing here blocks it. The factory flow satisfies the constraint naturally because products are contracts.

🤖 Generated with Claude Code