OrCa local deployment builder
Overview
Create local deployments that let OrCa exercise realistic protocol behavior instead of failing on missing initialization or unrealistic external dependencies.
Required reference
Read ../references/local-deployment.md and ../references/campaign-state-and-autonomy.md.
Sub-agent use
Use a sub-agent when deployment setup requires reading many fixtures, tests, constructors, mocks, or external dependency flows. As a delegated task, return the deployment order, required mocks, seeded state, users, changed files, unresolved risks, and validation command/run recommendation. This work can run in parallel with hint writing, property discovery, or target review if it owns only deployment artifacts and setup notes.
Workflow
- Detect whether the project is Foundry or Hardhat. If neither is present, explain the blocker.
- Inspect existing deployment scripts, fixtures, tests, constructor arguments, initializers, roles, tokens, oracle dependencies, and registries.
- Build one deployment path that deploys the campaign targets and required dependencies once.
- Add mocks only for missing external systems and keep them behaviorally plausible.
- Seed users, balances, approvals, roles, oracle values, liquidity, collateral, debt, shares, and other state needed for ordinary flows.
- Run or inspect the deployment locally when practical so missing roles,
constructor ordering issues, bad mock behavior, and artifact-path problems
are caught before submission.
- Make the deployment output machine-readable in the format OrCa expects for
the chosen framework. If the script cannot expose deployed addresses through
a parseable artifact path, treat that as a blocker instead of assuming a
human can recover them from stdout, return values, comments, or manual
notes.
- Record the deployment script path, deployed target names, users, setup
assumptions, and any submit-readiness blocker in
orca_config/campaign.json
when writing artifacts.
Output
If asked to write files, place the script in the framework-appropriate script/deploy area and keep OrCa campaign metadata under orca_config/. If returning only a design, include the exact deployment order, mocks, users, seeded state, and unresolved risks.
Do not deploy abstract contracts or interfaces. Do not grant ordinary fuzz users broad admin access unless that is the behavior being tested and the campaign notes explain why.
1---2name: audithub-orca-local-deployment-builder3description: Build or update realistic local deployment scripts for OrCa fuzzing campaigns. Use when live-state fuzzing is unavailable or unsuitable, when a Foundry or Hardhat protocol needs an OrCa deployment script, or when setup needs mocks, initialized contracts, roles, balances, approvals, liquidity, oracle values, or default fuzz users.4---56# OrCa local deployment builder78## Overview910Create local deployments that let OrCa exercise realistic protocol behavior instead of failing on missing initialization or unrealistic external dependencies.1112## Required reference1314Read `../references/local-deployment.md` and `../references/campaign-state-and-autonomy.md`.1516## Sub-agent use1718Use a sub-agent when deployment setup requires reading many fixtures, tests, constructors, mocks, or external dependency flows. As a delegated task, return the deployment order, required mocks, seeded state, users, changed files, unresolved risks, and validation command/run recommendation. This work can run in parallel with hint writing, property discovery, or target review if it owns only deployment artifacts and setup notes.1920## Workflow21221. Detect whether the project is Foundry or Hardhat. If neither is present, explain the blocker.232. Inspect existing deployment scripts, fixtures, tests, constructor arguments, initializers, roles, tokens, oracle dependencies, and registries.243. Build one deployment path that deploys the campaign targets and required dependencies once.254. Add mocks only for missing external systems and keep them behaviorally plausible.265. Seed users, balances, approvals, roles, oracle values, liquidity, collateral, debt, shares, and other state needed for ordinary flows.276. Run or inspect the deployment locally when practical so missing roles,28 constructor ordering issues, bad mock behavior, and artifact-path problems29 are caught before submission.307. Make the deployment output machine-readable in the format OrCa expects for31 the chosen framework. If the script cannot expose deployed addresses through32 a parseable artifact path, treat that as a blocker instead of assuming a33 human can recover them from stdout, return values, comments, or manual34 notes.358. Record the deployment script path, deployed target names, users, setup36 assumptions, and any submit-readiness blocker in `orca_config/campaign.json`37 when writing artifacts.3839## Output4041If asked to write files, place the script in the framework-appropriate script/deploy area and keep OrCa campaign metadata under `orca_config/`. If returning only a design, include the exact deployment order, mocks, users, seeded state, and unresolved risks.4243Do not deploy abstract contracts or interfaces. Do not grant ordinary fuzz users broad admin access unless that is the behavior being tested and the campaign notes explain why.
Veridise