@bananapus/omnichain-deployers-v6 0.0.26 → 0.0.28

package/ADMINISTRATION.md

@@ -1,156 +1,29 @@
 # Administration
 
-Admin privileges and their scope in nana-omnichain-deployers-v6.
-
 ## At A Glance
 
 | Item | Details |
-|------|---------|
-| Scope | Omnichain project launch, hook composition, sucker deployment, and the deployer's data-hook proxy behavior. |
-| Operators | Project owners and delegates, the `JBOmnichainDeployer`, and the configured `JBSuckerRegistry` with its wildcard token-mapping grant. |
-| Highest-risk actions | Launching a project with the wrong hook composition, terminal configuration, or cross-chain setup, then assuming it can be rewritten later. |
-| Recovery posture | The deployer's immutable dependencies cannot be edited in place. Project-level recovery usually means launching corrected rulesets or redeploying the broader project path. |
-
-## Routine Operations
-
-- Validate all deploy-time hook choices, 721 settings, and sucker configuration before using `launchProjectFor` or `launchRulesetsFor`.
-- Keep the distinction clear between per-ruleset composed hooks and the deployer's permanent proxy role.
-- Use the deployer when you want its tax-free sucker and mint-permission behavior; otherwise, do not assume it is a drop-in replacement for arbitrary hook wiring.
-
-## One-Way Or High-Risk Actions
-
-- Constructor-time wildcard permissions and immutable references on the deployer cannot be changed afterward.
-- Launch-time hook composition choices determine how future pay and cash-out flows are merged for that ruleset.
-- A bad omnichain deployment can leave a project with a cross-chain shape that is expensive to unwind operationally.
-
-## Recovery Notes
-
-- If the project is still administratively flexible, queue new rulesets or use project-level migration paths to move to corrected hook composition.
-- If the deployer's own immutable assumptions are wrong, recovery means deploying a new deployer path rather than trying to hot-fix the existing one.
-
-## Roles
-
-| Role | How Assigned | Scope |
-|------|-------------|-------|
-| Project owner | Holds the project's ERC-721 (minted by `JBProjects`) | Per-project. Can delegate via `JBPermissions`. |
-| Permitted operator | Granted specific permission IDs by the project owner through `JBPermissions` | Per-project, per-permission. ROOT (1) grants all. Wildcard projectId=0 grants across all projects. |
-| Registered sucker | Deployed via `JBSuckerRegistry.deploySuckersFor` (requires DEPLOY_SUCKERS permission) | Per-project. Gets 0% cash-out tax and mint permission automatically. |
-| JBSuckerRegistry | Set at construction, granted MAP_SUCKER_TOKEN for all projects (projectId=0 wildcard) | Protocol-wide. Maps tokens for sucker bridging. |
-
-## Privileged Functions
-
-### JBOmnichainDeployer
-
-| Function | Required Role | Permission ID | Scope | What It Does |
-|----------|--------------|---------------|-------|--------------|
-| `deploySuckersFor` | Project owner or operator | `DEPLOY_SUCKERS` | Per-project | Deploys new cross-chain suckers for an existing project via the sucker registry. The same operation also applies token mappings on the new suckers, so existing projects must already have the registry arranged as an authorized `MAP_SUCKER_TOKEN` operator for that project. |
-| `launchRulesetsFor` | Project owner or operator | `LAUNCH_RULESETS` + `SET_TERMINALS` | Per-project | Deploys a 721 tiers hook, launches new rulesets with terminal configuration for an existing project. Has a simplified overload without `deploy721Config`. |
-| `queueRulesetsOf` | Project owner or operator | `QUEUE_RULESETS` | Per-project | Queues new rulesets for an existing project. If tiers provided, deploys a new 721 hook. Otherwise, carries forward the 721 hook from the latest ruleset. Has a simplified overload without `deploy721Config`. |
-
-### Permissionless Functions
-
-| Function | Who Can Call | What It Does |
-|----------|-------------|--------------|
-| `launchProjectFor` | Anyone | Creates a new project with a 721 tiers hook (even with 0 tiers) and suckers. The ERC-721 is minted to the specified `owner`. Returns `(projectId, hook, suckers)`. Has a simplified overload without `deploy721Config` that uses a default empty-tier 721 config. |
-| `beforePayRecordedWith` | JBMultiTerminal (via controller) | View function: always calls the 721 hook (when its address is non-zero) for specs, then calls the custom hook (if configured and `useDataHookForPay` is set) with the reduced amount. Merges results. |
-| `beforeCashOutRecordedWith` | JBMultiTerminal (via controller) | View function: returns 0% cash-out tax for registered suckers. Calls 721 hook first (from `_tiered721HookOf`, if `useDataHookForCashOut: true`), then calls custom hook (from `_extraDataHookOf`, if `useDataHookForCashOut: true`) with the updated values from the 721 hook. Both hooks' specifications are merged. If neither has the flag set, returns original values. |
-| `hasMintPermissionFor` | JBController | View function: returns true for registered suckers, otherwise checks the custom hook in `_extraDataHookOf`. |
-| `extraDataHookOf` | Anyone | View function: returns the stored `JBDeployerHookConfig` for a project/ruleset pair (the custom data hook). |
-| `tiered721HookOf` | Anyone | View function: returns the stored 721 hook and `useDataHookForCashOut` flag for a project/ruleset pair. |
-
-## Deployment Administration
-
-**Who can deploy omnichain projects:** Anyone. The `launchProjectFor` function is permissionless. The caller specifies an `owner` address that receives the project ERC-721.
-
-**Deployment flow:**
-1. The deployer deploys a 721 tiers hook via `HOOK_DEPLOYER` (even with 0 tiers).
-2. It configures rulesets via `_setup721()`, sets itself as the data hook wrapper.
-3. It calls `controller.launchProjectFor`, which mints the project ERC-721 to `address(this)`.
-4. It transfers 721 hook ownership to the project (requires project NFT to exist).
-5. It optionally deploys suckers via the sucker registry.
-6. It transfers the project ERC-721 to the specified `owner`.
-
-**Configurable parameters at deployment:**
-- Ruleset configurations (duration, weight, decay, approval hooks, splits, fund access limits, metadata flags).
-- Terminal configurations (which terminals accept which tokens).
-- 721 tiers hook configuration (tier pricing, supply, metadata, categories — can be empty for 0 tiers).
-- Sucker deployment configuration (which chains, which deployers, token mappings).
-- Salt for deterministic cross-chain address matching.
-
-## Cross-Chain Controls
-
-| Action | Who | Mechanism |
-|--------|-----|-----------|
-| Deploy suckers for existing project | Project owner or DEPLOY_SUCKERS operator | `deploySuckersFor` calls `SUCKER_REGISTRY.deploySuckersFor`; because the registry also applies the initial mappings, existing projects must pair this with a project-level `MAP_SUCKER_TOKEN` arrangement for the registry |
-| Deploy suckers during project launch | Project deployer (anyone) | Included in `launchProjectFor` if `salt != bytes32(0)` |
-| Map sucker tokens | JBSuckerRegistry | Granted MAP_SUCKER_TOKEN at construction with projectId=0 wildcard |
-| Grant 0% cash-out tax to suckers | Automatic | `beforeCashOutRecordedWith` checks `SUCKER_REGISTRY.isSuckerOf` |
-| Grant mint permission to suckers | Automatic | `hasMintPermissionFor` checks `SUCKER_REGISTRY.isSuckerOf` |
-
-**Existing-project operator note:** `deploySuckersFor` looks like a deployment-only action at the top level, but it is intentionally a deploy-and-map flow. If an existing project delegates `DEPLOY_SUCKERS` without also arranging `MAP_SUCKER_TOKEN` for the registry, the transaction will fail once the registry reaches the mapping step.
-
-**Cross-chain determinism:** The salt for sucker deployment is combined with `_msgSender()` (`keccak256(abi.encode(salt, _msgSender()))`). Deploying from the same sender address with the same salt on each chain produces matching sucker addresses.
-
-## Data Hook Proxy Pattern
-
-`JBOmnichainDeployer` acts as a data hook proxy. When set as a project's `dataHook` in ruleset metadata, it wraps up to two inner hooks:
-
-1. **721 tiers hook** (`_tiered721HookOf[projectId][rulesetId]`): Handles NFT-based pay/cashout logic.
-2. **Extra data hook** (`_extraDataHookOf[projectId][rulesetId]`): An optional custom hook for additional pay/cashout logic.
-
-### Call flow for `beforePayRecordedWith`:
-
-```
-Terminal -> Controller -> JBOmnichainDeployer.beforePayRecordedWith()
-  1. Call 721 hook's beforePayRecordedWith (always, when its address is non-zero)
-     -> Get pay hook specifications and the total split amount
-  2. Call extra hook's beforePayRecordedWith (if useDataHookForPay is set on extra hook config)
-     -> Amount is reduced by what the 721 hook already allocated
-  3. Scale the extra hook's weight proportionally to the project's share of the payment
-  4. Merge both hooks' specifications and return
-```
-
-### Call flow for `beforeCashOutRecordedWith`:
-
-```
-Terminal -> Controller -> JBOmnichainDeployer.beforeCashOutRecordedWith()
-  1. Check if caller is a registered sucker -> return 0% cash-out tax (fee-free bridging)
-  2. Call 721 hook's beforeCashOutRecordedWith (if useDataHookForCashOut is set on 721 config)
-     -> Get cashout hook specifications and adjusted values
-  3. Call extra hook's beforeCashOutRecordedWith (if useDataHookForCashOut is set on extra config)
-     -> Receives updated values from 721 hook
-  4. Merge both hooks' specifications and return
-```
+| --- | --- |
+| Scope | Omnichain launch orchestration and wrapper behavior |
+| Control posture | Mixed deployer logic, project permissions, and registry trust |
+| Highest-risk actions | Wrong hook composition, wrong sucker wiring, and bad registry trust |
+| Recovery posture | Often requires redeploying or re-launching around bad wiring |
 
-**`useDataHookForCashOut` / `useDataHookForPay` flags:** These flags control whether each hook participates in a given operation. For the **extra data hook**, the flags are stored per-ruleset in the `JBDeployerHookConfig` struct -- if the flag is `false`, that hook is skipped entirely and the original values are returned unchanged for that hook's portion. The **721 hook** behaves differently: it is **always** called during `beforePayRecordedWith` when its address is non-zero (no `useDataHookForPay` check), but for `beforeCashOutRecordedWith` it respects the `useDataHookForCashOut` flag stored in `JBTiered721HookConfig`.
+## Purpose
 
-**Write-once storage:** Both `_tiered721HookOf` and `_extraDataHookOf` mappings are written once during `_setup721()` and never updated. New rulesets can reference different hooks, but existing ruleset-to-hook mappings are permanent.
+This repo controls how omnichain projects are launched and wrapped, not the low-level runtime logic of suckers or 721 hooks.
 
-## Immutable Configuration
+## Control Model
 
-These values are set at deployment and cannot be changed:
+- launch paths are largely permissionless for new projects
+- later ruleset changes depend on project permissions
+- registry and sucker trust surfaces can widen authority if misconfigured
 
-| Property | Type | What It Is |
-|----------|------|-----------|
-| `PROJECTS` | `IJBProjects` | The ERC-721 contract for project ownership. |
-| `HOOK_DEPLOYER` | `IJB721TiersHookDeployer` | The deployer for 721 tiers hooks. |
-| `SUCKER_REGISTRY` | `IJBSuckerRegistry` | The registry for deploying and tracking suckers. |
-| `PERMISSIONS` | `IJBPermissions` | The permissions contract (inherited from JBPermissioned). |
-| Trusted forwarder | `address` | The ERC-2771 trusted forwarder for meta-transactions. |
-| MAP_SUCKER_TOKEN grant | Permission | Granted to SUCKER_REGISTRY at construction for all projects (projectId=0). Cannot be revoked by this contract. |
+## Recovery
 
-**Data hook mappings** (`_tiered721HookOf[projectId][rulesetId]` and `_extraDataHookOf[projectId][rulesetId]`) are write-once per ruleset ID. They are set during `_setup721()` and never updated or deleted.
+- bad launch wiring usually means a new deployment path rather than a local patch
 
 ## Admin Boundaries
 
-What admins **cannot** do:
+- this repo does not override locked runtime behavior in sibling repos
 
-- **Cannot upgrade the deployer.** JBOmnichainDeployer has no upgrade mechanism, proxy pattern, or self-destruct.
-- **Cannot change immutable references.** PROJECTS, HOOK_DEPLOYER, SUCKER_REGISTRY, PERMISSIONS, and the trusted forwarder are all immutable.
-- **Cannot modify stored data hooks.** Once a ruleset's hooks are stored in `_tiered721HookOf` and `_extraDataHookOf`, they cannot be changed. New rulesets can use different hooks, but existing mappings are permanent.
-- **Cannot bypass permission checks.** All post-deployment admin functions require JBPermissions verification against the project owner.
-- **Cannot revoke sucker privileges.** Once a sucker is registered in JBSuckerRegistry, it automatically gets 0% cash-out tax and mint permission for its project. Revocation must happen at the registry level.
-- **Cannot set the deployer as its own data hook.** `_setup721()` explicitly reverts with `JBOmnichainDeployer_InvalidHook` if a hook is `address(this)`.
-- **Cannot use a controller that doesn't match the project.** `_validateController` reverts with `JBOmnichainDeployer_ControllerMismatch` if the provided controller is not the project's actual controller in the directory.
-- **Cannot steal project ownership during deployment.** The deployer holds the project ERC-721 only transiently and transfers it to the specified owner in the same transaction.
-- **Cannot drain funds.** The deployer never holds or manages token balances. It only orchestrates configuration.

package/ARCHITECTURE.md

@@ -2,79 +2,30 @@
 
 ## Purpose
 
-`nana-omnichain-deployers-v6` launches Juicebox projects that are ready for both tiered NFTs and cross-chain suckers from day one. It also acts as a wrapper data hook so it can compose a 721 hook with an optional extra data hook while granting suckers tax-free cash outs and mint permission.
+`nana-omnichain-deployers-v6` packages a Juicebox project, a 721 hook, and sucker deployment into one omnichain launch surface.
 
-## Boundaries
+## System Overview
 
-- `JBOmnichainDeployer` is both a deployer and a live hook wrapper. Those two roles are inseparable.
-- The repo composes `nana-721-hook-v6` and `nana-suckers-v6`; it should not duplicate their internal logic.
-- Project accounting still happens in the core protocol.
+`JBOmnichainDeployer` launches the project, stores per-ruleset hook composition, and wraps sucker behavior so bridge-triggered flows can bypass project-specific logic where intended.
 
-## Main Components
+## Core Invariants
 
-| Component | Responsibility |
-| --- | --- |
-| `JBOmnichainDeployer` | Project launch, ruleset queueing, hook composition, and sucker-safe cash-out policy |
-| config structs | 721 hook config, extra hook config, and sucker deployment config |
-| `IJBOmnichainDeployer` | Public deployer and inspection interface |
+- launch wiring must match the intended omnichain project shape
+- hook composition must stay consistent with the created ruleset IDs
+- sucker-specific privileged paths must remain limited to trusted suckers
+- project NFT ownership and hook ownership must end in the intended place
 
-## Runtime Model
+## Trust Boundaries
 
-### Launch
+- bridge runtime trust lives in `nana-suckers-v6`
+- 721 runtime trust lives in `nana-721-hook-v6`
+- this repo mainly owns orchestration and wrapper semantics
 
-```text
-caller
-  -> launch project or queue rulesets through the deployer
-  -> deployer installs itself as the ruleset data hook
-  -> deployer deploys or carries forward the 721 hook
-  -> deployer optionally deploys sucker pairs with deterministic salts
-  -> project ownership is transferred to the intended owner
-```
+## Security Model
 
-### 721 Hook Carry-Forward (Queue Path)
+- the main risks are hook composition, ruleset ID prediction, and registry-trusted sucker bypasses
+- this repo is not the source of underlying bridge or 721 behavior, but it can wire them together incorrectly
 
-When `queueRulesetsOf` is called without new tiers, the deployer carries the existing 721 hook forward. The source ruleset is chosen with this precedence:
+## Source Map
 
-1. **Latest queued ruleset** — if its approval status is `Approved` or `Empty` (no approval hook) and it has a hook config stored in the deployer.
-2. **Current active ruleset** — fallback when no qualifying queued ruleset exists.
-
-This ensures that a recently queued (and approved) ruleset's hook config takes precedence over a potentially stale active ruleset. The `useDataHookForCashOut` flag is also preserved from whichever source ruleset is selected.
-
-### Pay And Cash-Out Wrapping
-
-```text
-runtime callback
-  -> if the actor is a registered sucker, return the special tax-free / mint-enabled path
-  -> otherwise call the 721 hook first when configured
-  -> then call the extra data hook when configured
-  -> merge hook specs in order and return the combined result
-```
-
-## Critical Invariants
-
-- Suckers must be able to bridge without getting trapped behind custom cash-out policies.
-- Hook order matters: the 721 hook runs first, and the extra hook receives the updated context.
-- The deployer's predicted ruleset IDs must stay aligned with `JBRulesets` behavior; the storage keys depend on it.
-- Every project launched through this repo gets a 721 hook surface, even if it starts with zero tiers.
-- Carry-forward must prefer the latest approved queued ruleset over the current ruleset to avoid losing hook config from a recently queued update.
-
-## Where Complexity Lives
-
-- This repo hides composition complexity behind a simple launch surface, which makes stale assumptions dangerous.
-- Ruleset ID prediction is a subtle but central storage keying mechanism.
-- The sucker exception path intentionally short-circuits normal hook composition and must stay easy to reason about.
-
-## Dependencies
-
-- `nana-core-v6` for project launch and hook interfaces
-- `nana-721-hook-v6` for tiered NFT behavior
-- `nana-suckers-v6` for cross-chain transport
-- `nana-ownable-v6` for project-following hook ownership
-
-## Safe Change Guide
-
-- Review launch-time logic and runtime-hook logic together. This repo is easy to break by fixing only one side.
-- When changing hook composition, verify both payment and cash-out ordering.
-- If you touch ruleset ID prediction, test same-block and queued-ruleset edge cases explicitly.
-- Keep deterministic salt handling stable across chains; address predictability is part of the feature.
-- Treat "transparent wrapper" claims as something to prove continuously, not assume.
+- `src/JBOmnichainDeployer.sol`

package/AUDIT_INSTRUCTIONS.md

@@ -1,72 +1,29 @@
 # Audit Instructions
 
-This repo launches projects that are immediately composed with 721 hooks and sucker deployments. Audit it as a privileged deployer and runtime data-hook participant.
+Audit this repo as an orchestration layer that composes 721 hooks, suckers, and optional extra data hooks.
 
-## Objective
+## Audit Objective
 
 Find issues that:
-- launch projects with incorrect rulesets, terminals, or hook ownership
-- grant cash-out or mint privileges to non-suckers
-- mis-scale weight or tax behavior during omnichain-specific data-hook flows
-- leave deployed hook or sucker ownership in the wrong hands
-- create inconsistent behavior between local-only and omnichain project launches
+
+- launch the wrong project shape
+- miscompose hooks or wrapper behavior
+- grant privileged sucker behavior to the wrong addresses
+- create cross-chain drift or bad deterministic assumptions
 
 ## Scope
 
 In scope:
-- `src/JBOmnichainDeployer.sol`
-- `src/interfaces/`
-- `src/structs/`
-- deployment scripts in `script/`
-
-Key dependencies:
-- `nana-core-v6`
-- `nana-721-hook-v6`
-- `nana-suckers-v6`
-
-## System Model
-
-`JBOmnichainDeployer` is a launch surface that can:
-- create a new Juicebox project
-- deploy and configure a 721 hook
-- configure rulesets and terminals
-- deploy suckers and register them for the project
-- participate in pay or cash-out accounting as a data hook where needed
-
-## Critical Invariants
 
-1. Launch configuration is faithful
-The deployed project must end up with the exact hook, ruleset, and ownership configuration the caller requested.
-
-2. Sucker privileges stay restricted
-Zero-tax or mint-permission behavior intended for legitimate suckers must not be reachable by arbitrary contracts or stale registry entries.
-
-3. Weight and accounting scaling are correct
-If the deployer proxies or modifies hook outputs, the resulting project token issuance and reclaim math must still match intended economics.
-
-4. Ownership transfer is complete
-Deployer-created hooks and helper contracts must not retain silent control after initialization.
+- `src/JBOmnichainDeployer.sol`
+- related tests under `test/`
 
-## Threat Model
+## Start Here
 
-Prioritize:
-- empty or malformed ruleset configurations
-- hook ownership transfer races
-- registry-based privilege spoofing
-- reentrancy around project launch and initialization
-- stale assumptions when optional sucker deployment is skipped
+1. `src/JBOmnichainDeployer.sol`
 
-## Build And Verification
+## Verification
 
-Standard workflow:
 - `npm install`
 - `forge build`
 - `forge test`
-
-Existing tests emphasize:
-- reentrancy and attack paths
-- hook composition
-- weight scaling
-- omnichain fork and stress scenarios
-
-High-value findings typically show either a bad project launch state or a non-sucker actor receiving omnichain-only privileges.

package/README.md

@@ -3,7 +3,12 @@
 `@bananapus/omnichain-deployers-v6` launches Juicebox projects with cross-chain suckers and a 721 hook already wired in. It is the package you use when the default project shape should be omnichain from day one.
 
 Docs: <https://docs.juicebox.money>
-Architecture: [ARCHITECTURE.md](./ARCHITECTURE.md)
+Architecture: [ARCHITECTURE.md](./ARCHITECTURE.md)  
+User journeys: [USER_JOURNEYS.md](./USER_JOURNEYS.md)  
+Skills: [SKILLS.md](./SKILLS.md)  
+Risks: [RISKS.md](./RISKS.md)  
+Administration: [ADMINISTRATION.md](./ADMINISTRATION.md)  
+Audit instructions: [AUDIT_INSTRUCTIONS.md](./AUDIT_INSTRUCTIONS.md)
 
 ## Overview
 
@@ -12,15 +17,13 @@ The deployer wraps multiple launch concerns into one surface:
 - deploy or carry forward a tiered 721 hook
 - install itself as the project's data-hook wrapper
 - compose the 721 hook with an optional extra custom hook
-- grant tax-free and mint-safe behavior to project suckers
+- wrap sucker flows so project-specific cash-out taxation and mint-permission logic can be handled safely
 - deploy suckers deterministically across chains
 
-The wrapper exists so suckers can bridge without being blocked by project-specific cash-out tax logic while the project still keeps its own data hooks.
+The wrapper exists so sucker-triggered flows can be exempted from project-specific cash-out taxation and related mint-gating logic where needed while the project still keeps its own inner data hooks.
 
 Use this repo when the default project shape is "Juicebox project plus 721 hook plus cross-chain bridge." Do not use it when a project is single-chain or does not need the wrapper semantics around suckers.
 
-If the question is "how do suckers bridge?" start in `nana-suckers-v6`. If the question is "how does a 721 hook behave?" start in `nana-721-hook-v6`. This repo is where those components are packaged together and wrapped.
-
 ## Key Contract
 
 | Contract | Role |
@@ -42,6 +45,20 @@ This repo owns orchestration plus runtime wrapping:
 3. `nana-721-hook-v6/src/JB721TiersHook.sol`
 4. the extra hook repo, if the deployment composes one
 
+## Integration Traps
+
+- this repo wraps hooks and bridge flows together, so ownership and hook-order assumptions matter as much as deployment salt
+- ruleset ID prediction is a real implementation dependency
+- the deployer can carry forward an existing 721 hook shape, so stale hook assumptions can leak across deployments
+- bridge-safe wrapper behavior is part of the runtime trust model
+
+## Where State Lives
+
+- orchestration and wrapper logic: `JBOmnichainDeployer`
+- bridge runtime state: `nana-suckers-v6`
+- 721 tier state: `nana-721-hook-v6`
+- extra hook behavior: the additional repo composed into the deployment
+
 ## Install
 
 ```bash
@@ -81,7 +98,12 @@ script/
 
 ## Risks And Notes
 
-- ruleset ID prediction is part of the implementation strategy and should be treated as a real assumption
+- ruleset ID prediction is part of the implementation strategy
 - hook composition order matters because the 721 hook runs before any extra custom hook
-- using the default empty-tier 721 config is convenient, but teams should still decide explicitly whether the hook participates in cash-out behavior
-- deterministic salts help with cross-chain address alignment, but only when the sender and configuration match exactly
+- default empty-tier 721 config is convenient, but teams should still decide explicitly whether the hook participates in cash-out behavior
+- deterministic salts only help with cross-chain address alignment when sender and configuration match exactly
+
+## For AI Agents
+
+- Describe this repo as an orchestration and wrapper layer, not as the source of sucker or 721 runtime behavior.
+- Start with `JBOmnichainDeployer`, then inspect the sibling repo that owns the behavior being questioned.

package/RISKS.md

@@ -29,6 +29,7 @@ This file focuses on the risks in the deployer layer that launches Juicebox proj
 - **Sucker cashout bypass.** Any address registered as a sucker for a project gets 0% cashout tax rate and full reclaim. If a malicious sucker is registered (via compromised `SUCKER_REGISTRY`), it can drain the project's surplus.
 - **Weight manipulation via extra data hook.** `beforePayRecordedWith` forwards to the extra data hook, which can return any `weight`. A malicious hook can inflate token minting or set weight=0 to block minting.
 - **721 hook amount splitting.** The deployer computes `projectAmount = context.amount.value - totalSplitAmount`. The 721 hook's returned weight (already adjusted for splits via `JB721TiersHookLib.calculateWeight`) is used directly -- no proportional scaling is applied. If the 721 hook returns a `totalSplitAmount >= context.amount.value`, `projectAmount` is set to 0 and weight becomes 0 -- no tokens are minted for the payment.
+- **Cross-chain sender dependence in sucker deployment salts.** `deploySuckersFor` salts deployments with `keccak256(abi.encode(userSalt, _msgSender()))`. This prevents replay collisions, but it also means the same logical project deployed by different operators on different chains will not get matching deterministic sucker addresses.
 
 ## 3. Access Control
 
@@ -41,6 +42,7 @@ This file focuses on the risks in the deployer layer that launches Juicebox proj
 - **Ruleset ID collision.** `_setup721` stores hook configs at `block.timestamp + i`. If `latestRulesetIdOf >= block.timestamp` (rulesets already queued this block), `queueRulesetsOf` reverts with `RulesetIdsUnpredictable`. An attacker who queues rulesets in the same block as the legitimate owner can front-run and block their queue attempt. Gas impact: `queueRulesetsOf` costs ~200-400k gas per ruleset queued. The collision only occurs when two transactions queue rulesets in the same block for the same project — race condition window is one block (~12 seconds on L1, 2 seconds on L2).
 - **External hook revert.** `beforePayRecordedWith` and `beforeCashOutRecordedWith` call external hooks without try-catch. A reverting hook blocks all payments or cashouts for that project/ruleset. For cash-outs, if the 721 hook reverts, the custom hook is never reached (the revert propagates before it). Gas impact: the direct call into the extra data hook has no gas limit, so a gas-griefing hook can consume the entire transaction gas. The 721 hook call is similarly unbounded.
 - **721 hook deployment revert.** `HOOK_DEPLOYER.deployHookFor` is called without try-catch. A failing deployment blocks the entire project launch.
+- **Unexpected safe NFT receipt reverts, but non-safe transfers can still strand assets.** `onERC721Received` only accepts `PROJECTS` NFTs. Safe transfers of any other ERC-721 revert instead of being accepted. The narrower residual risk is `transferFrom` or other non-safe delivery into the deployer, which bypasses the receiver hook and has no generalized rescue path.
 
 ## 5. Reentrancy Surface
 
@@ -53,7 +55,8 @@ This file focuses on the risks in the deployer layer that launches Juicebox proj
 
 - **Hook config keyed by predicted rulesetId.** Configs stored at `block.timestamp + i` must match the actual rulesetId assigned by the controller. If the controller assigns different IDs (e.g., due to approval hook delays), the stored configs become unreachable -- payments/cashouts fall through to default behavior (no 721 handling, no extra hook).
 - **Carried-forward 721 hook on queue.** When `tiers.length == 0`, `queueRulesetsOf` carries forward the hook from a previous ruleset. The source is selected by first checking `latestQueuedOf(projectId)` — if the queued ruleset's approval status is `Approved` or `Empty` and it has a stored hook config, that config is used. Otherwise it falls back to `currentOf(projectId)`. If neither has a hook deployed through this deployer, the mapping is empty and the call reverts with `JBOmnichainDeployer_InvalidHook`. The `useDataHookForCashOut` flag is also preserved from whichever source ruleset is selected.
-- **ERC721Receiver restriction.** `onERC721Received` only accepts from `PROJECTS`. Any other NFTs sent to this contract are permanently lost.
+- **ERC721Receiver restriction.** `onERC721Received` only accepts from `PROJECTS`. Non-project NFTs sent via `safeTransferFrom` revert cleanly; non-safe transfers can still become stuck because the deployer has no generalized rescue function.
+- **Empty simplified launch config reverts.** The convenience overload that derives a default 721 config from `rulesetConfigurations[0]` reverts with `JBOmnichainDeployer_NoRulesetConfigurations()` when called with an empty ruleset array.
 - **Cross-reference: sucker registration.** The deployer grants `MAP_SUCKER_TOKEN` to `SUCKER_REGISTRY` with `projectId=0` (wildcard). This means the registry can map tokens for ALL projects deployed through this deployer. See [nana-suckers-v6 RISKS.md](../nana-suckers-v6/RISKS.md) for the full sucker lifecycle risks.
 - **Cross-reference: core reentrancy.** The deployer delegates to `JBController` and `JBMultiTerminal` for all fund operations. See [nana-core-v6 RISKS.md](../nana-core-v6/RISKS.md) section 3 for the reentrancy surface of these contracts.
 
@@ -65,6 +68,7 @@ This file focuses on the risks in the deployer layer that launches Juicebox proj
 - `beforePayRecordedWith` uses the 721 hook's weight directly (already split-adjusted by `JB721TiersHookLib.calculateWeight`), so no additional scaling is applied.
 - Self-reference prevention: `rulesetConfigurations[i].metadata.dataHook` cannot be `address(this)` after `_setup721`.
 - Project NFT ownership: after `_launchProjectFor`, the project NFT is owned by `owner`, not the deployer.
+- `deploySuckersFor` uses the same `_msgSender()` on every chain when deterministic cross-chain peer symmetry is expected.
 
 ## 8. Accepted Behaviors
 

package/SKILLS.md

@@ -2,39 +2,24 @@
 
 ## Use This File For
 
-- Use this file when the task involves deploying core projects with suckers and optional 721 or custom data-hook composition in one flow.
-- Start here, then open the deployer or composition-focused tests depending on whether the question is about setup, permissions, hook wrapping, or runtime delegation.
+- Use this file when the task involves omnichain project launch, sucker deployment, or wrapped 721-hook composition.
+- Start here, then decide whether the issue is in launch orchestration, hook composition, or bridge-specific runtime behavior.
 
 ## Read This Next
 
 | If you need... | Open this next |
 |---|---|
-| Repo overview and launch model | [`README.md`](./README.md), [`ARCHITECTURE.md`](./ARCHITECTURE.md) |
-| Deployment implementation | [`src/JBOmnichainDeployer.sol`](./src/JBOmnichainDeployer.sol), [`script/Deploy.s.sol`](./script/Deploy.s.sol) |
-| Input and output types | [`src/structs/`](./src/structs/), [`src/interfaces/`](./src/interfaces/) |
-| Guard rails, attacks, or hook composition behavior | [`test/JBOmnichainDeployerGuard.t.sol`](./test/JBOmnichainDeployerGuard.t.sol), [`test/OmnichainDeployerAttacks.t.sol`](./test/OmnichainDeployerAttacks.t.sol), [`test/Tiered721HookComposition.t.sol`](./test/Tiered721HookComposition.t.sol), [`test/regression/`](./test/regression/) |
-
-## Repo Map
-
-| Area | Where to look |
-|---|---|
-| Main contract | [`src/JBOmnichainDeployer.sol`](./src/JBOmnichainDeployer.sol) |
-| Types | [`src/structs/`](./src/structs/), [`src/interfaces/`](./src/interfaces/) |
-| Scripts | [`script/`](./script/) |
-| Tests | [`test/`](./test/) |
+| Repo overview and architecture | [`README.md`](./README.md), [`ARCHITECTURE.md`](./ARCHITECTURE.md) |
+| Main deployer | [`src/JBOmnichainDeployer.sol`](./src/JBOmnichainDeployer.sol) |
+| Bridge runtime | [`../nana-suckers-v6/src/JBSucker.sol`](../nana-suckers-v6/src/JBSucker.sol) |
+| 721 hook runtime | [`../nana-721-hook-v6/src/JB721TiersHook.sol`](../nana-721-hook-v6/src/JB721TiersHook.sol) |
 
 ## Purpose
 
-Single-transaction deployment and wrapper layer for Juicebox projects that need a 721 hook, cross-chain sucker support, and optional extra data-hook composition from day one.
-
-## Reference Files
-
-- Open [`references/runtime.md`](./references/runtime.md) when you need hook-composition order, sucker exemptions, per-ruleset storage behavior, or the main runtime invariants.
-- Open [`references/operations.md`](./references/operations.md) when you need launch and queue behavior, permission and salt assumptions, test breadcrumbs, or the common stale-data traps.
+Orchestration and wrapper layer for launching projects with suckers and a 721 hook already wired in.
 
 ## Working Rules
 
-- Start in [`src/JBOmnichainDeployer.sol`](./src/JBOmnichainDeployer.sol) for both deployment and runtime wrapping behavior. This repo is orchestration plus a live data-hook wrapper, not a pure deploy script package.
-- Treat ruleset ID prediction, hook-carry-forward logic, and salt derivation as high-risk. Small changes there can orphan config or break deterministic deployment.
-- When a bug mentions suckers, tax-free cash outs, or mint permission, verify whether the early-return wrapper behavior is the real cause before changing downstream hooks.
-- If a task mentions 721 or custom-hook behavior, confirm whether the issue lives here or in the composed repo before patching wrapper logic.
+- Start in [`src/JBOmnichainDeployer.sol`](./src/JBOmnichainDeployer.sol).
+- Treat ruleset ID prediction as a real implementation dependency.
+- Keep wrapper behavior and the underlying 721 or sucker behavior separate in your reasoning.

package/USER_JOURNEYS.md

@@ -1,70 +1,63 @@
 # User Journeys
 
-## Who This Repo Serves
+## Repo Purpose
 
-- teams launching Juicebox projects that should be cross-chain from day one
-- deployers composing a tiered 721 hook with sucker support and optional extra hooks
-- operators evolving rulesets without breaking sucker-safe wrapper behavior
+This repo launches projects that are omnichain from the start.
 
-## Journey 1: Launch A Project Across Chains In One Flow
+## Primary Actors
 
-**Starting state:** the project wants an initial Juicebox launch plus 721 hook plus sucker package instead of separate setup steps.
+- operators launching omnichain projects
+- teams composing 721 hooks with extra data hooks
+- auditors checking bridge-wrapper behavior
 
-**Success:** the project launches with its omnichain-capable shape already installed.
+## Journey 1: Launch An Omnichain Project
 
-**Flow**
-1. Call `JBOmnichainDeployer` with the project launch config, 721 config, sucker deployment config, and any extra hook composition.
-2. The deployer launches the base Juicebox project and either deploys or wires the tiered 721 hook.
-3. It wraps the hook composition so future rulesets can keep sucker-safe behavior while still preserving project-specific hook logic.
-4. Deterministic salts are used so sibling-chain deployments can be coordinated with confidence.
+**Actor:** deployer.
 
-## Journey 2: Coordinate Deterministic Deployment Inputs Across Chains
+**Intent:** launch a project with a 721 hook and suckers already wired in.
 
-**Starting state:** multiple chain deployments need to line up so the same project shape exists everywhere.
+**Main Flow**
+1. Build the intended ruleset and hook composition.
+2. Launch the project through `JBOmnichainDeployer`.
+3. Deploy or wire the sucker pair and transfer control to the intended owner.
 
-**Success:** teams can predict addresses, salts, and wrapper behavior before doing the live rollout.
+**Failure Modes**
+- wrong hook composition
+- cross-chain deployment drift
+- wrong sucker peer wiring
 
-**Flow**
-1. Fix the deployer inputs that drive deterministic addresses for suckers and hook packaging.
-2. Reuse those inputs consistently on each chain.
-3. Validate that the controller, hook ownership, and sucker expectations still line up across the resulting deployments.
+## Journey 2: Deploying Suckers for an Existing Project
 
-## Journey 3: Carry Forward An Existing 721 Hook While Queueing New Omnichain Rulesets
+**Actor:** project owner who wants to add cross-chain sucker bridges to an already-launched project.
 
-**Starting state:** the project already has a 721 hook and wants future omnichain-aware rulesets without replacing that collection.
+**Intent:** deploy suckers via `JBOmnichainDeployer.deploySuckersFor()` for a project that was not originally launched through the omnichain deployer (or needs additional suckers after launch).
 
-**Success:** the deployer carries the existing hook forward, stores it against the queued ruleset, and preserves the ownership and wrapper assumptions bridge flows need.
+**Background**
 
-**Flow**
-1. Queue the next ruleset through the deployer using the path that reuses the existing 721 hook (pass zero tiers).
-2. The deployer selects the source hook: it first checks the latest queued ruleset (if approved or with no approval hook), then falls back to the current active ruleset. This prevents losing a recently queued hook config.
-3. The `useDataHookForCashOut` flag is preserved from whichever source ruleset is selected.
-4. Validate the controller and queued ruleset inputs before relying on the result.
-5. Confirm the queued ruleset now points at the carried-forward hook rather than accidentally dropping the 721 layer.
+When a project is freshly launched through the omnichain deployer, the deployer contract temporarily holds the project NFT. This means it automatically satisfies the `DEPLOY_SUCKERS` permission check because it is the project owner at that moment. After sucker deployment, it transfers the NFT to the intended owner.
 
-## Journey 4: Compose A Tiered 721 Hook With A Custom Extra Hook
+For projects that already exist and are owned by someone else, the deployer no longer holds the project NFT. The permission check in `deploySuckersFor()` requires that the caller has `DEPLOY_SUCKERS` permission from the project owner. Since the omnichain deployer enforces this check internally via `_requirePermissionFrom`, the project owner must explicitly grant this permission before calling the function.
 
-**Starting state:** the project wants standard tiered NFTs plus some extra product logic.
+**Main Flow**
+1. The project owner calls `JBPermissions.setPermissionsFor()` to grant the `DEPLOY_SUCKERS` permission (from `JBPermissionIds`) to the `JBOmnichainDeployer` contract address, scoped to their project ID.
+2. The project owner (or any caller with the appropriate permission) calls `JBOmnichainDeployer.deploySuckersFor()` with the project ID and sucker deployment configuration.
+3. The deployer verifies that the caller has `DEPLOY_SUCKERS` permission from the project owner.
+4. The deployer deploys the suckers via the sucker registry and returns their addresses.
 
-**Success:** the extra logic composes with the 721 hook and sucker wrapper instead of overriding them unsafely.
+**Failure Modes**
+- Calling `deploySuckersFor()` without first granting the deployer `DEPLOY_SUCKERS` permission will revert with a permission error.
+- Granting the permission to the wrong address (e.g., the caller's EOA instead of the deployer contract) will not satisfy the check, since the deployer enforces permission on behalf of the project owner against its own address.
+- Forgetting to scope the permission to the correct project ID will cause the call to fail.
 
-**Flow**
-1. Provide the extra-hook config when launching through `JBOmnichainDeployer`.
-2. Let the deployer remember which composition belongs to each ruleset.
-3. Make sure bridge flows still bypass or special-case the right tax and data-hook behavior.
+**Key Difference from Journey 1**
 
-## Journey 5: Evolve The Project After Launch Without Breaking Bridge Paths
+In Journey 1 (fresh launch), permission is implicit because the deployer owns the project NFT during deployment. In Journey 2 (existing project), permission must be explicitly granted via `JBPermissions` before sucker deployment can proceed.
 
-**Starting state:** the project is live and future rulesets need new metadata, hook composition, or payout behavior.
+## Trust Boundaries
 
-**Success:** ruleset changes preserve the special wrapper assumptions that let suckers bridge cleanly.
-
-**Flow**
-1. Queue the next ruleset through the omnichain-aware deployer surface.
-2. Keep track of which hook stack should apply for that future ruleset.
-3. Confirm that sucker flows still land on the mint-safe and tax-safe path the wrapper was designed to preserve.
+- this repo wraps runtime behavior but does not replace the underlying 721 or sucker repos
 
 ## Hand-Offs
 
-- Use [nana-suckers-v6](../nana-suckers-v6/USER_JOURNEYS.md) for the bridge mechanics after the project has been launched with suckers.
-- Use [nana-721-hook-v6](../nana-721-hook-v6/USER_JOURNEYS.md) for the standard tier and resolver behavior that this repo packages into the omnichain launch.
+- Use `nana-suckers-v6` for bridge runtime behavior.
+- Use `nana-721-hook-v6` for tiered NFT runtime behavior.

package/foundry.toml

@@ -14,6 +14,8 @@ runs = 1024
 depth = 100
 fail_on_revert = false
 
+[lint]
+exclude_lints = ["pascal-case-struct", "mixed-case-variable"]
 [fmt]
 number_underscore = "thousands"
 multiline_func_header = "all"

package/package.json

@@ -1,33 +1,33 @@
 {
-    "name": "@bananapus/omnichain-deployers-v6",
-    "version": "0.0.26",
-    "license": "MIT",
-    "repository": {
-        "type": "git",
-        "url": "git+https://github.com/Bananapus/nana-omnichain-deployers-v6"
-    },
-    "engines": {
-        "node": ">=20.0.0"
-    },
-    "scripts": {
-        "test": "forge test",
-        "coverage": "forge coverage --match-path \"./src/*.sol\" --report lcov --report summary",
-        "deploy:mainnets": "source ./.env && export START_TIME=$(date +%s) && npx sphinx propose ./script/Deploy.s.sol --networks mainnets",
-        "deploy:testnets": "source ./.env && export START_TIME=$(date +%s) && npx sphinx propose ./script/Deploy.s.sol --networks testnets",
-        "artifacts": "source ./.env && npx sphinx artifacts --org-id 'ea165b21-7cdc-4d7b-be59-ecdd4c26bee4' --project-name 'nana-omnichain-deployers-v6'"
-    },
-    "dependencies": {
-        "@bananapus/721-hook-v6": "^0.0.33",
-        "@bananapus/buyback-hook-v6": "^0.0.27",
-        "@bananapus/core-v6": "^0.0.34",
-        "@bananapus/ownable-v6": "^0.0.17",
-        "@bananapus/permission-ids-v6": "^0.0.17",
-        "@bananapus/suckers-v6": "^0.0.25",
-        "@openzeppelin/contracts": "^5.6.1",
-        "@uniswap/v4-core": "^1.0.2"
-    },
-    "devDependencies": {
-        "@bananapus/address-registry-v6": "^0.0.17",
-        "@sphinx-labs/plugins": "^0.33.2"
-    }
+  "name": "@bananapus/omnichain-deployers-v6",
+  "version": "0.0.28",
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/Bananapus/nana-omnichain-deployers-v6"
+  },
+  "engines": {
+    "node": ">=20.0.0"
+  },
+  "scripts": {
+    "test": "forge test",
+    "coverage": "forge coverage --match-path \"./src/*.sol\" --report lcov --report summary",
+    "deploy:mainnets": "source ./.env && export START_TIME=$(date +%s) && npx sphinx propose ./script/Deploy.s.sol --networks mainnets",
+    "deploy:testnets": "source ./.env && export START_TIME=$(date +%s) && npx sphinx propose ./script/Deploy.s.sol --networks testnets",
+    "artifacts": "source ./.env && npx sphinx artifacts --org-id 'ea165b21-7cdc-4d7b-be59-ecdd4c26bee4' --project-name 'nana-omnichain-deployers-v6'"
+  },
+  "dependencies": {
+    "@bananapus/721-hook-v6": "^0.0.35",
+    "@bananapus/buyback-hook-v6": "^0.0.27",
+    "@bananapus/core-v6": "^0.0.34",
+    "@bananapus/ownable-v6": "^0.0.17",
+    "@bananapus/permission-ids-v6": "^0.0.17",
+    "@bananapus/suckers-v6": "^0.0.25",
+    "@openzeppelin/contracts": "^5.6.1",
+    "@uniswap/v4-core": "^1.0.2"
+  },
+  "devDependencies": {
+    "@bananapus/address-registry-v6": "^0.0.17",
+    "@sphinx-labs/plugins": "^0.33.2"
+  }
 }

package/references/operations.md

@@ -25,4 +25,4 @@
 
 - [`test/JBOmnichainDeployer.t.sol`](../test/JBOmnichainDeployer.t.sol) for baseline deploy and queue flows.
 - [`test/TestAuditGaps.sol`](../test/TestAuditGaps.sol) for pinned edge cases.
-- [`test/fork/`](../test/fork/) when cross-repo integration behavior matters more than isolated unit logic.
+- [`test/Tiered721HookComposition.t.sol`](../test/Tiered721HookComposition.t.sol) when cross-repo integration behavior matters more than isolated unit logic.

package/references/runtime.md

@@ -25,4 +25,4 @@
 - [`test/Tiered721HookComposition.t.sol`](../test/Tiered721HookComposition.t.sol) for hook-composition behavior.
 - [`test/JBOmnichainDeployerGuard.t.sol`](../test/JBOmnichainDeployerGuard.t.sol) and [`test/OmnichainDeployerAttacks.t.sol`](../test/OmnichainDeployerAttacks.t.sol) for safety properties.
 - [`test/OmnichainDeployerReentrancy.t.sol`](../test/OmnichainDeployerReentrancy.t.sol) for wrapper security assumptions.
-- [`test/OmnichainDeployerEdgeCases.t.sol`](../test/OmnichainDeployerEdgeCases.t.sol), [`test/invariants/`](../test/invariants/), and [`test/regression/`](../test/regression/) for edge behavior.
+- [`test/OmnichainDeployerEdgeCases.t.sol`](../test/OmnichainDeployerEdgeCases.t.sol), [`test/JBOmnichainDeployer.t.sol`](../test/JBOmnichainDeployer.t.sol), and [`test/TestAuditGaps.sol`](../test/TestAuditGaps.sol) for edge behavior.

package/src/JBOmnichainDeployer.sol

@@ -412,7 +412,9 @@ contract JBOmnichainDeployer is
         // This prevents disproportionate reclaim when tokens bridge away but surplus stays.
         effectiveSurplusValue = context.surplus.value
             + SUCKER_REGISTRY.remoteSurplusOf({
-                projectId: context.projectId, decimals: 18, currency: uint256(uint160(context.surplus.token))
+                projectId: context.projectId,
+                decimals: context.surplus.decimals,
+                currency: uint256(context.surplus.currency)
             });
 
         // Will hold the 721 hook's cash out specifications (always 0 or 1 element).
@@ -444,6 +446,7 @@ contract JBOmnichainDeployer is
             hookContext.cashOutTaxRate = cashOutTaxRate;
             hookContext.cashOutCount = cashOutCount;
             hookContext.totalSupply = totalSupply;
+            hookContext.surplus.value = effectiveSurplusValue;
 
             // Forward to the extra hook. It may further change the tax rate, count, and return hook specs.
             // We discard the inner hook's effectiveSurplusValue — this contract computes the cross-chain values.
@@ -923,7 +926,9 @@ contract JBOmnichainDeployer is
     /// @param projectId The ID of the project to validate the controller for.
     /// @param controller The controller to validate.
     function _validateController(uint256 projectId, IJBController controller) internal view {
-        if (address(controller.DIRECTORY().controllerOf(projectId)) != address(controller)) {
+        address current = address(controller.DIRECTORY().controllerOf(projectId));
+        // Allow address(0) for fresh projects that haven't launched rulesets yet.
+        if (current != address(0) && current != address(controller)) {
             revert JBOmnichainDeployer_ControllerMismatch();
         }
     }

package/src/structs/JBDeployerHookConfig.sol

@@ -3,7 +3,6 @@ pragma solidity ^0.8.0;
 
 import {IJBRulesetDataHook} from "@bananapus/core-v6/src/interfaces/IJBRulesetDataHook.sol";
 
-// forge-lint: disable-next-line(pascal-case-struct)
 struct JBDeployerHookConfig {
     IJBRulesetDataHook dataHook;
     bool useDataHookForPay;

package/src/structs/JBOmnichain721Config.sol

@@ -8,7 +8,6 @@ import {JBDeploy721TiersHookConfig} from "@bananapus/721-hook-v6/src/structs/JBD
 /// @param useDataHookForCashOut Whether the 721 hook should handle cash outs (via beforeCashOutRecordedWith).
 /// @param salt A salt to use for the deterministic 721 hook deployment. Combined with `msg.sender` internally, so
 /// cross-chain deterministic addresses require the same sender on each chain.
-// forge-lint: disable-next-line(pascal-case-struct)
 struct JBOmnichain721Config {
     JBDeploy721TiersHookConfig deployTiersHookConfig;
     bool useDataHookForCashOut;

package/src/structs/JBSuckerDeploymentConfig.sol

@@ -5,7 +5,6 @@ import {JBSuckerDeployerConfig} from "@bananapus/suckers-v6/src/structs/JBSucker
 
 /// @custom:member deployerConfigurations The information for how to suck tokens to other chains.
 /// @custom:member salt The salt to use for creating suckers so that they use the same address across chains.
-// forge-lint: disable-next-line(pascal-case-struct)
 struct JBSuckerDeploymentConfig {
     JBSuckerDeployerConfig[] deployerConfigurations;
     bytes32 salt;

package/src/structs/JBTiered721HookConfig.sol

@@ -3,7 +3,6 @@ pragma solidity ^0.8.0;
 
 import {IJB721TiersHook} from "@bananapus/721-hook-v6/src/interfaces/IJB721TiersHook.sol";
 
-// forge-lint: disable-next-line(pascal-case-struct)
 struct JBTiered721HookConfig {
     IJB721TiersHook hook;
     bool useDataHookForCashOut;

package/test/audit/CodexNemesisAudit.t.sol

@@ -57,27 +57,35 @@ contract CodexNemesisAudit is Test {
         vm.mockCall(hookAddr, abi.encodeWithSelector(IJBOwnable.transferOwnershipToProject.selector), abi.encode());
     }
 
-    function test_poc_launchRulesetsFor_revertsWhenProjectHasNoControllerYet() public {
+    function test_poc_launchRulesetsFor_succeedsWhenProjectHasNoControllerYet() public {
         JBOmnichainDeployer deployer =
             new JBOmnichainDeployer(mockSuckerRegistry, hookDeployer, permissions, projects, address(0));
 
         vm.mockCall(
             address(controller), abi.encodeWithSelector(IJBController.DIRECTORY.selector), abi.encode(directory)
         );
-        // A freshly created project with no controller yet is valid for core launchRulesetsFor,
-        // but the deployer rejects it before the controller can set itself as first controller.
+        // A freshly created project with no controller yet — the M-14 fix allows address(0) through.
         vm.mockCall(
             address(directory),
             abi.encodeWithSelector(IJBDirectory.controllerOf.selector, PROJECT_ID),
             abi.encode(IERC165(address(0)))
         );
+        // Mock controller.launchRulesetsFor to return a rulesetId.
+        vm.mockCall(
+            address(controller),
+            abi.encodeWithSelector(IJBController.launchRulesetsFor.selector),
+            abi.encode(uint256(1))
+        );
 
         JBRulesetConfig[] memory configs = new JBRulesetConfig[](1);
         configs[0] = _makeRulesetConfig();
 
         vm.prank(projectOwner);
-        vm.expectRevert(JBOmnichainDeployer.JBOmnichainDeployer_ControllerMismatch.selector);
-        deployer.launchRulesetsFor(PROJECT_ID, configs, new JBTerminalConfig[](0), "memo", controller);
+        (uint256 rulesetId,) =
+            deployer.launchRulesetsFor(PROJECT_ID, configs, new JBTerminalConfig[](0), "memo", controller);
+
+        // Verify the call succeeded and returned a valid rulesetId.
+        assertGt(rulesetId, 0, "launchRulesetsFor should succeed for fresh project with no controller");
     }
 
     function test_poc_deploySuckersFor_requiresHiddenPermissionForDeployerItself() public {