Deploy All V6

deploy-all-v6 is the orchestration repo for the wider Juicebox V6 stack in this workspace. Use it when you want to deploy or rehearse the ecosystem together instead of deploying packages one by one.

Documentation

• ARCHITECTURE.md — module layout, deploy phases, and cross-package sequencing.
• USER_JOURNEYS.md — end-to-end deploy, resume, and verify flows.
• SKILLS.md — orchestration gotchas and reading order.
• RISKS.md — deployment threat model and accepted risks.
• ADMINISTRATION.md — operator roles, ownership handoff, and recovery posture.
• AUDIT_INSTRUCTIONS.md — what to focus on and how to start.
• DEPLOY.md — operator deployment runbook.
• STYLE_GUIDE.md — code and documentation conventions.
• CHANGELOG.md - V5 to V6 deployment migration changelog.
• references/operations.md — operational procedures reference.
• references/runtime.md — runtime behavior reference.

Overview

This repo does not define protocol behavior of its own. Its job is to stitch together deployment artifacts, cross-package addresses, and multi-chain sequencing for the V6 ecosystem.

It is responsible for:

• workspace-level deployment orchestration
• recovery flows (redeploying from fresh salts after an interruption)
• post-deploy verification
• fork rehearsals of cross-feature compositions

Use this repo when the question is "does the combined deployment still work?" Do not use it as the main place to understand subsystem runtime behavior.

Key scripts

Script	Role
script/Deploy.s.sol	Main end-to-end deployment entrypoint; bump its deployment nonce to recover from an interruption by redeploying from fresh salts
script/Verify.s.sol	Post-deploy verification checks
script/LivePostDeploySmoke.s.sol	Budgeted Sphinx proposal for live post-deploy buyback, loan, and ops smoke checks

Mental model

This repo owns sequencing, not business logic. It is where the intended cross-repo deployment shape is exercised under chain-specific conditions.

Read these files first

1. script/Deploy.s.sol
2. script/Verify.s.sol
3. script/LivePostDeploySmoke.s.sol
4. test/fork/DeployFullStack.t.sol
5. test/fork/DeployResumeRehearsalFork.t.sol

High-signal tests

1. test/fork/DeployFullStack.t.sol
2. test/fork/DeployResumeRehearsalFork.t.sol
3. test/fork/DeployScriptVerification.t.sol
4. test/fork/ResumeDeployFork.t.sol
5. test/fork/SuckerEndToEndFork.t.sol

Integration traps

• this repo has almost no runtime protocol logic of its own, so many assumptions live in sibling packages
• a successful deployment sequence can still encode bad cross-repo configuration
• recovery paths (redeploying from fresh salts) are part of the intended operational surface
• artifact drift and chain-specific environment mismatches are the main failure classes here

Where state lives

• orchestration logic lives in the deployment scripts
• high-signal behavior checks live in test/fork/
• deployed runtime state ultimately lives in the sibling repos this package composes

Workspace use

This repo is a private workspace package, not a published reusable library. Use it from a cloned v6/evm checkout or as a sibling repo in the same multi-repo workspace.

Development

npm install
forge build --deny notes --skip "*/test/**"
forge test --deny notes --fail-fast --summary --detailed --skip "*/script/**"

The test suite is fork-heavy and exercises realistic multi-repo compositions rather than isolated mocks.

Deployment notes

This repo assumes the sibling V6 packages are present and their deployment artifacts are internally consistent. Some phases are intentionally chain-dependent, including skipping parts of the Uniswap stack on networks without the required external infrastructure. Verify.s.sol is a deployment check, not a full runtime review.

Repository layout

script/
  Deploy.s.sol
  Verify.s.sol
  LivePostDeploySmoke.s.sol
test/fork/
  full-stack, recovery, cross-feature, and long-horizon deployment rehearsals

Risks and notes

• this repo amplifies configuration mistakes because it composes many packages at once
• deployment recovery paths should be treated as production code
• fork rehearsals reduce deployment risk, but they do not remove chain-specific operational risk
• artifact drift across sibling packages is one of the main failure modes
• stale verification logic can report green while checking the wrong assumptions

For AI agents

• Do not treat this repo as the source of truth for subsystem behavior.
• Start with the deployment scripts, then use the fork tests to see which deployment and recovery assumptions are pinned.
• When summarizing a failure, name the sibling package that actually owns the affected runtime behavior.