test(deploy-server): two-Anvil e2e proof + document deploymentParameters precedence (closes #139)

[robercano-ghbot]

Closes #139 — multi-network deploys end-to-end

This completes the acceptance criterion for #139. The two prior merged PRs built the machinery:

• feat(deploy-server): server-side multi-network support #143 — deploy-server network registry (networks.ts), ?network=<name> on /api/simulate, /api/deploy, GET /api/deployment, per-network deployment/journal dirs.
• feat(studio): network selector + GET /api/networks for multi-network deploys (#139) #145 — studio GET /api/networks discovery, toolbar network selector, unified with the studio's client-side networkOverrides.

#145 deliberately left #139 open on two remaining points. This PR resolves both.

1. networkOverrides vs server deploymentParameters precedence — decided, documented, and proven

The studio bakes its client-side per-network networkOverrides into spec.parameters (a flat default map) at spec-generation time, so at the wire level a studio override arrives as a spec.parameters[name] default in the request body. handleDeploy passes each network's server-side deploymentParameters (keyed under moduleId) to core.deploy(). Core resolves spec.parameters as Ignition defaultValues and deploymentParameters[moduleId] as overrides that win (m.getParameter(name, defaultValue) + resolveSpec.ts's buildResolverParams).

Decision: server-side per-network deploymentParameters override any spec.parameters value for the same name — including studio-baked networkOverrides. Trusted server config wins. This matches the existing security boundary (rpcUrl/deployer keys are server-only, never client-supplied) and is Ignition's own precedence. Documented in server.ts (handleDeploy) and networks.ts (no runtime change — the precedence already held; this makes it explicit and adds an end-to-end proof).

2. Automated two-network end-to-end integration test (stands in for the suggested live smoke test)

New non-mocked test apps/deploy-server/test/e2e/multi-network.e2e.test.ts + a local anvil harness. It spins up two real local Anvil instances, configures two networks (alpha, beta) each with its own RPC, deployer key, deployment dir, and deploymentParameters, then drives the real deploy-server HTTP API end-to-end (no mocked core). It asserts, on-chain via hasRole(DEFAULT_ADMIN_ROLE, …):

• the same spec deploys to both networks with independent journal/resume state (distinct non-empty journals; a re-deploy to alpha resumes to the same address without touching beta);
• correct per-network parameter values on each chain;
• precedence: the server-config admin holds the role on each network and the spec-default (studio-baked networkOverrides) address does not — proving server deploymentParameters override client-supplied spec.parameters.

This is the same real-Anvil pattern already used in packages/core's e2e suite. Because a headless agent cannot perform an interactive studio click-through, this automated, deterministic, chain-level assertion is a stronger and repeatable substitute for the manual two-Anvil smoke test suggested in #145: it exercises the identical code path (studio → HTTP API → core → real chain) and verifies the on-chain outcome, not just wiring.

The e2e is isolated from the fast gate: a new vitest.config.ts exclude keeps it out of pnpm test/pnpm coverage (so anvil-less CI stays green), and it runs via the new pnpm -F @redeploy/deploy-server test:e2e (vitest.e2e.config.ts, pool: forks, 120s/60s timeouts).

Scope / boundary

All changes are confined to apps/deploy-server/ (module boundary respected). server.ts/networks.ts edits are doc-comments only.

Gates

• build / typecheck / lint: PASS
• fast test: PASS (211 tests; e2e excluded)
• coverage: PASS — deploy-server src/** 89.65% stmts (≥80 threshold)
• real e2e (test:e2e, two live Anvil chains): ran (not skipped) and PASSED — 1 test, multi-network deploy proven end-to-end
• Repo-wide forge test was not run: contracts/lib is absent in the isolated worktree (known pre-existing sandbox limitation, same as feat(deploy-server): server-side multi-network support #143/feat(studio): network selector + GET /api/networks for multi-network deploys (#139) #145) — not a regression from this change.

Reviews

Consensus (all lenses) — correctness ✅, tests ✅, security ✅, performance ✅. Correctness independently confirmed the precedence claim against compile.ts/deploy.ts and that the test is non-vacuous; security confirmed the precedence doc reinforces the trusted-config boundary and only anvil dev keys / temp files are used.

🤖 Generated with Claude Code