Refactor: Split Project Into Core Transport + Application Layer

Objective

Refactor defensive-sender-receiver-starter into two cleanly separated layers:

Core (src/core/) — A reusable, payload-agnostic cross-chain transport layer with defensive message handling. Knows nothing about vaults, ERC4626, deposits, or redemptions.
Application (src/app/) — The vault-specific deposit/redeem logic that consumes the core. Owns all payload encoding/decoding via codecs.

The core should be extractable into its own package/repo in the future without any vault references.

Target File Structure

src/
├── core/                                    # Reusable cross-chain transport
│   ├── CCIPBase.sol                         # MOVED from src/ccip/CCIPBase.sol (unchanged)
│   ├── CCIPReceiverCore.sol                 # MOVED from src/ccip/CCIPReceiverCore.sol (unchanged)
│   ├── interfaces/
│   │   ├── ICCIPBase.sol                    # MOVED from src/interfaces/ICCIPBase.sol
│   │   └── ICCIPDefensiveReceiver.sol       # MOVED from src/interfaces/ICCIPDefensiveReceiver.sol
│   └── libraries/
│       ├── FailedMessageHandler.sol         # MOVED from src/ccip/libraries/FailedMessageHandler.sol
│       └── UniversalSender.sol              # MOVED from src/ccip/libraries/UniversalSender.sol
│
├── app/                                     # Vault-specific application layer
│   ├── CrossChainVaultDepositor.sol         # MOVED from src/CrossChainVaultDepositor.sol
│   ├── CrossChainVaultRedeemer.sol          # MOVED from src/CrossChainVaultRedeemer.sol
│   ├── CrossChainVaultDepositAndRedeemer.sol # MOVED from src/CrossChainVaultDepositAndRedeemer.sol
│   ├── CCIPVaultBase.sol                    # MOVED from src/ccip/CCIPVaultBase.sol (this is app-layer, not core)
│   └── libraries/
│       ├── VaultDepositCodec.sol            # NEW — extracted from inline decode in CrossChainVaultDepositor
│       ├── VaultRedeemCodec.sol             # NEW — extracted from inline decode in CrossChainVaultRedeemer
│       ├── VaultDepositLib.sol              # MOVED from src/libraries/VaultDepositLib.sol
│       ├── VaultRedeemLib.sol               # MOVED from src/libraries/VaultRedeemLib.sol
│       ├── VaultErrors.sol                  # MOVED from src/libraries/VaultErrors.sol
│       ├── VaultEvents.sol                  # MOVED from src/libraries/VaultEvents.sol
│       └── VaultConfigStorage.sol           # MOVED from src/libraries/VaultConfigStorage.sol
│
├── mocks/                                   # STAYS (unchanged location)
│   ├── MockCCIPRouter.sol
│   ├── EnhancedMockRouter.sol
│   ├── MockCCTPTokenMinter.sol
│   └── MockERC20Token.sol
│
└── vaults/                                  # STAYS (unchanged location)
    ├── SimpleERC4626Vault.sol
    └── README.md

Also update:

examples/
├── CustomCrossChainVaultDepositor.sol       # Update imports
└── CustomCrossChainVaultRedeemer.sol        # Update imports

test/                                        # Update all imports across all test files

script/                                      # Update all imports across all script files

Step-by-Step Instructions

Step 1: Create the directory structure

mkdir -p src/core/interfaces
mkdir -p src/core/libraries
mkdir -p src/app/libraries

Step 2: Move core files

Move these files. They should NOT change internally (no logic changes), only their location changes:

From	To
`src/ccip/CCIPBase.sol`	`src/core/CCIPBase.sol`
`src/ccip/CCIPReceiverCore.sol`	`src/core/CCIPReceiverCore.sol`
`src/ccip/libraries/FailedMessageHandler.sol`	`src/core/libraries/FailedMessageHandler.sol`
`src/ccip/libraries/UniversalSender.sol`	`src/core/libraries/UniversalSender.sol`
`src/interfaces/ICCIPBase.sol`	`src/core/interfaces/ICCIPBase.sol`
`src/interfaces/ICCIPDefensiveReceiver.sol`	`src/core/interfaces/ICCIPDefensiveReceiver.sol`

Step 3: Move application files

From	To
`src/CrossChainVaultDepositor.sol`	`src/app/CrossChainVaultDepositor.sol`
`src/CrossChainVaultRedeemer.sol`	`src/app/CrossChainVaultRedeemer.sol`
`src/CrossChainVaultDepositAndRedeemer.sol`	`src/app/CrossChainVaultDepositAndRedeemer.sol`
`src/ccip/CCIPVaultBase.sol`	`src/app/CCIPVaultBase.sol`

Why CCIPVaultBase.sol moves to app, not core: Open this file and inspect it. It contains vault-specific custom errors and events (references to vaults, deposits, shares, redemptions, etc.). Despite living in src/ccip/, it is application-layer knowledge — the core transport should have no concept of vaults. If CCIPVaultBase.sol contains any errors or events that are genuinely transport-level (not vault-specific), split those out into a separate file in src/core/ and keep only the vault-specific ones in src/app/CCIPVaultBase.sol. If everything in it is vault-specific, move the whole file as-is. Additionally, consider whether CCIPVaultBase.sol should be merged into the existing VaultErrors.sol and VaultEvents.sol files to reduce redundancy — if the errors and events in CCIPVaultBase.sol overlap with or complement what’s already in those files, consolidate them. Use your judgment, but do not lose any error or event definitions in the process.

Step 4: Create codec libraries

Find wherever message.data or the CCIP message payload is decoded inline in CrossChainVaultDepositor._processMessageMemory (and the sender-side encoding if any exists). Extract that into a dedicated library.

How to find the fields for each codec:

Open CrossChainVaultDepositor.sol and find _processMessageMemory.
Search for where message.data (or the data bytes parameter) is decoded — look for abi.decode(...) calls on the message data.
The types and variable names inside that abi.decode call ARE the codec’s Payload struct fields.
If the decode is not a single abi.decode but is spread across multiple lines or helper functions, trace the full decode chain and collect all fields that are extracted from the raw bytes.
Do the same for CrossChainVaultRedeemer.sol.

For example, if you find this inside _processMessageMemory:

(address vault, address beneficiary, uint64 destChain, uint256 minShares) = 
    abi.decode(message.data, (address, address, uint64, uint256));

Then the codec becomes:

struct Payload {
    address vault;
    address beneficiary;
    uint64 destinationChainSelector;
    uint256 minSharesOut;
}

Create src/app/libraries/VaultDepositCodec.sol:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.26;

library VaultDepositCodec {
    uint8 constant VERSION = 1;

    struct Payload {
        // POPULATE THIS: use the exact fields found in the abi.decode call
        // inside CrossChainVaultDepositor._processMessageMemory
    }

    function encode(Payload memory p) internal pure returns (bytes memory) {
        return abi.encodePacked(VERSION, abi.encode(
            // all fields from Payload struct, in order
        ));
    }

    function decode(bytes memory data) internal pure returns (Payload memory) {
        uint8 version = uint8(data[0]);

        if (version == 1) {
            bytes memory body = new bytes(data.length - 1);
            for (uint256 i = 0; i < body.length; i++) {
                body[i] = data[i + 1];
            }
            // abi.decode body using the same types as the Payload struct
            // return Payload(...)
        }

        revert("UnsupportedVersion");
    }
}

Create src/app/libraries/VaultRedeemCodec.sol following the same process — extract from CrossChainVaultRedeemer._processMessageMemory.

Then update CrossChainVaultDepositor._processMessageMemory and CrossChainVaultRedeemer._processMessageMemory to use the codec:

import {VaultDepositCodec} from "./libraries/VaultDepositCodec.sol";

// Inside _processMessageMemory:
VaultDepositCodec.Payload memory p = VaultDepositCodec.decode(message.data);
// Then use p.vault, p.beneficiary, etc. instead of inline decoding

IMPORTANT: Handling CrossChainVaultDepositAndRedeemer:

This contract handles both deposit and redeem messages in a single receiver. Open CrossChainVaultDepositAndRedeemer._processMessageMemory and determine how it currently differentiates between deposit vs redeem messages. There are three likely patterns:

It checks a field in the decoded data (e.g., an enum or uint8 action type) — if so, formalize that as the first byte type tag in both codecs.
It checks the token type or some other heuristic — if so, refactor to use an explicit type tag byte prefix instead, which is more robust.
It always expects the same payload shape — unlikely given it does both deposit and redeem, but if so, create a single combined codec.

The target pattern for the combined contract should be:

function _processMessageMemory(..., bytes memory data, ...) internal override {
    uint8 messageType = uint8(data[0]);
    bytes memory payload = _sliceBytes(data, 1); // everything after first byte

    if (messageType == 0x01) {
        VaultDepositCodec.Payload memory p = VaultDepositCodec.decode(payload);
        _handleDeposit(p, tokenAmounts);
    } else if (messageType == 0x02) {
        VaultRedeemCodec.Payload memory p = VaultRedeemCodec.decode(payload);
        _handleRedeem(p, tokenAmounts);
    } else {
        revert UnknownMessageType();
    }
}

If the standalone CrossChainVaultDepositor and CrossChainVaultRedeemer only ever receive one message type each, they can skip the type tag prefix and decode directly. The type tag is only needed for the combined contract. In that case, the combined contract’s sender-side must prepend the type tag, while the standalone contracts’ senders do not. Document this difference clearly in both codec libraries with a comment explaining when the type tag byte is present vs absent.

Step 5: Update all import paths

Every file that imports from the old paths needs updating. This is the bulk of the work.

Pattern for core files (internal imports between core files):

// Old:
import {CCIPBase} from "./CCIPBase.sol";
import {FailedMessageHandler} from "./libraries/FailedMessageHandler.sol";

// New (within core, use relative paths):
import {CCIPBase} from "./CCIPBase.sol";                              // if same directory
import {FailedMessageHandler} from "./libraries/FailedMessageHandler.sol"; // if in core/

Pattern for application files importing core:

// Old:
import {CCIPReceiverCore} from "./ccip/CCIPReceiverCore.sol";
import {CCIPVaultBase} from "./ccip/CCIPVaultBase.sol";
import {FailedMessageHandler} from "./ccip/libraries/FailedMessageHandler.sol";
import {UniversalSender} from "./ccip/libraries/UniversalSender.sol";
import {ICCIPDefensiveReceiver} from "./interfaces/ICCIPDefensiveReceiver.sol";
import {VaultDepositLib} from "./libraries/VaultDepositLib.sol";

// New:
import {CCIPReceiverCore} from "../core/CCIPReceiverCore.sol";
import {CCIPVaultBase} from "./CCIPVaultBase.sol";
import {FailedMessageHandler} from "../core/libraries/FailedMessageHandler.sol";
import {UniversalSender} from "../core/libraries/UniversalSender.sol";
import {ICCIPDefensiveReceiver} from "../core/interfaces/ICCIPDefensiveReceiver.sol";
import {VaultDepositLib} from "./libraries/VaultDepositLib.sol";

Pattern for test files:

// Old:
import {CrossChainVaultDepositor} from "../src/CrossChainVaultDepositor.sol";
import {MockCCIPRouter} from "../src/mocks/MockCCIPRouter.sol";

// New:
import {CrossChainVaultDepositor} from "../src/app/CrossChainVaultDepositor.sol";
import {MockCCIPRouter} from "../src/mocks/MockCCIPRouter.sol";  // mocks didn't move

Pattern for script files:

// Old:
import {CrossChainVaultDepositor} from "../src/CrossChainVaultDepositor.sol";

// New:
import {CrossChainVaultDepositor} from "../src/app/CrossChainVaultDepositor.sol";

Pattern for example files:

// Old:
import {CrossChainVaultDepositor} from "../src/CrossChainVaultDepositor.sol";

// New:
import {CrossChainVaultDepositor} from "../src/app/CrossChainVaultDepositor.sol";

Step 6: Update remappings.txt

Add remappings for the new structure if helpful. This is optional but can make imports cleaner:

@core/=src/core/
@app/=src/app/

If you add these, imports become:

import {CCIPReceiverCore} from "@core/CCIPReceiverCore.sol";
import {VaultDepositCodec} from "@app/libraries/VaultDepositCodec.sol";

Decision: Only add remappings if the existing project already uses them heavily. Otherwise relative paths are fine and more explicit.

Step 7: Delete old empty directories

After moving all files, remove:

rm -rf src/ccip/
rm -rf src/interfaces/
rm -rf src/libraries/

Verify no files remain in these directories before deleting.

Step 8: Verify compilation

forge build

Fix any remaining import path issues until compilation succeeds.

Step 9: Run tests

forge test

All existing tests should pass with zero logic changes. This is purely a structural refactor.

Validation Rules (How to Know You Did It Right)

src/core/ has ZERO references to: vault, ERC4626, deposit, redeem, shares, VaultDepositLib, VaultRedeemLib, VaultErrors, VaultEvents, VaultConfigStorage, CCIPVaultBase, or any codec. Run grep -ri "vault\|erc4626\|deposit\|redeem\|shares" src/core/ and confirm zero results (excluding generic variable names like address that happen to appear — use judgment).
src/app/ imports from src/core/ but never the reverse. Core never imports from app. Run grep -r "from.*app/" src/core/ and confirm zero results.
Codec struct fields match the original inline decode. Open the original abi.decode call you extracted from each _processMessageMemory. Verify every field is present in the codec’s Payload struct with the same types and same order. No fields should be lost or reordered.
Codec libraries exist at src/app/libraries/VaultDepositCodec.sol and src/app/libraries/VaultRedeemCodec.sol with both encode and decode functions.
CrossChainVaultDepositor._processMessageMemory uses VaultDepositCodec.decode(data) instead of inline abi.decode.
CrossChainVaultRedeemer._processMessageMemory uses VaultRedeemCodec.decode(data) instead of inline abi.decode.
CrossChainVaultDepositAndRedeemer._processMessageMemory routes between codecs using a type tag or the same mechanism it originally used to differentiate message types.
CCIPVaultBase.sol lives in src/app/, NOT in src/core/. Confirm it contains only vault-specific errors/events. If any transport-level errors/events were found and split out to core, confirm they exist in a separate file under src/core/.
No error or event definitions were lost during the CCIPVaultBase.sol move. If it was merged into VaultErrors.sol/VaultEvents.sol, diff the combined result against the originals to confirm nothing was dropped.
forge build succeeds with no errors.
forge test passes all existing tests with no failures.
No files remain in the old src/ccip/, src/interfaces/, or src/libraries/ directories. Run find src/ccip src/interfaces src/libraries -type f 2>/dev/null and confirm no output.

What NOT to Change

Do not modify any contract logic, storage layout, function signatures, or behavior. This is a file organization and import path refactor only (plus codec extraction).
Do not rename any contracts, libraries, interfaces, or functions.
Do not change foundry.toml beyond what is needed for the new paths (if anything — the default src = "src" should still work).
Do not touch lib/ dependencies.
Do not modify mock contracts or vault contracts beyond updating their import paths.
Do not change test assertions or test logic — only update import paths.

Success Criteria

After the structural refactor is complete and all existing tests pass, complete the following additional work. This is NOT optional — the refactor is not done until all of these are delivered.

1. Test Coverage

1a. Core Transport Layer Tests (`test/core/`)

Create a dedicated test suite for the core in isolation, proving it works without any vault logic. These tests must import ONLY from src/core/ and mocks — never from src/app/.

First, create a MockProcessMessage contract that inherits CCIPReceiverCore with a minimal _processMessageMemory implementation (just stores the arguments or emits an event) to test the core in isolation without vault logic.

CCIPReceiverCore tests:

Message received from allowed sender/chain → calls _processMessage virtual hook with correct arguments
Message received from disallowed sender → reverts
Message received from disallowed chain → reverts
Message processing reverts → message stored in FailedMessageHandler with correct messageId, payload, and reason
Message processing reverts → MessageFailed event emitted with correct data
Message processing succeeds → MessageProcessed event emitted
Retry of failed message → calls _processMessage again with original payload
Retry of failed message that succeeds → message marked resolved in FailedMessageHandler
Retry of failed message that reverts again → message remains in failed state with updated reason
Retry of non-existent messageId → reverts
Double processing of same messageId → reverts (if applicable)
Access control on retry → only authorized role can call

TokenRecoverable tests (if this abstract exists in core):

Recover ERC20 tokens that are not actively in use → succeeds, tokens transferred to recipient
Recover native ETH → succeeds
Attempt to recover tokens that _getRecoverableBalance excludes → reverts or recovers zero
Access control → only authorized role can call recovery
Recovery of zero balance → handles gracefully

FailedMessageHandler tests:

Store a failed message → retrievable by messageId
Store multiple failed messages → all retrievable
Pagination of failed messages → returns correct pages
Mark message as resolved → no longer appears as unresolved
Store message with maximum payload size → no truncation

UniversalSender tests:

Send to EVM chain → correct CCIP message constructed
Send to Solana chain → correct CCIP message constructed with SVM encoding
Send with zero token amount → handles correctly (reverts or sends message-only)
Fee estimation → returns correct fee for given message

CCIPBase tests:

Constructor sets router correctly
supportsInterface returns true for expected interfaces
Access control roles are set correctly on deployment

1b. Codec Tests (`test/app/`)

VaultDepositCodec tests:

Encode then decode roundtrip → all fields match original values
Decode with version 1 → correct fields extracted
Decode with unsupported version → reverts
Decode with truncated data → reverts
Decode with extra trailing bytes → handles gracefully (does not corrupt fields)
Encode produces deterministic output → same input always gives same bytes
Fuzz test: encode(decode(data)) roundtrip with random valid inputs

VaultRedeemCodec tests:

Same categories as VaultDepositCodec above, adapted for redeem fields

Cross-language codec test (if frontend SDK exists):

If frontend/lib/ contains TypeScript encoding logic, add a Foundry FFI test that:

Calls a Node script to encode a payload in TypeScript
Passes the hex output to a Solidity test that decodes it via the codec
Asserts all fields match

1c. Integration Tests

Full end-to-end: encode payload → send via mock CCIP router → receiver processes → vault deposit/redeem executes
Failed message flow: encode payload → send → processing reverts → stored as failed → retry → succeeds
Recovery flow: tokens stuck in receiver → _getRecoverableBalance returns correct amount → recovery succeeds

1d. Coverage Target

Run forge coverage and report the results. Target:

src/core/ — 100% line coverage, 100% branch coverage
src/app/libraries/*Codec.sol — 100% line coverage, 100% branch coverage
src/app/ contracts — at least match the existing coverage level (do not regress)

2. Security Analysis (Trail of Bits Style)

Produce a file docs/audit/POST_REFACTOR_SECURITY_REVIEW.md containing a security review of the core transport layer. Write this from the perspective of a Trail of Bits auditor — assume adversarial users, composability risks, and edge cases. This review should be rigorous enough that an external auditor reading it would say “they already caught the obvious stuff.”

2a. Threat Model

Define the threat model for the core:

Trust boundaries: What is trusted (CCIP router, admin roles) vs untrusted (message payloads, source chains, senders)?
Assets at risk: Tokens in transit, tokens in failed message recovery, tokens stuck in the contract
Adversary capabilities: Malicious sender on allowed chain, compromised admin, front-running, griefing

2b. Attack Surface Review

For each contract in src/core/, enumerate:

External/public functions — who can call them, what state they modify
Access control correctness — are roles assigned correctly, can they be escalated
Reentrancy vectors — which functions make external calls before state updates, is ReentrancyGuard applied correctly
DoS vectors — can an attacker cause ccipReceive to revert in a way that permanently blocks message processing? Can they grief the failed message store (e.g., fill storage)?
Token handling — are SafeERC20 methods used consistently? Are allowances reset after use? Are fee-on-transfer tokens handled?
Failed message recovery — can an attacker exploit the retry mechanism? Can they front-run a retry? Can recovery be used to drain tokens that aren’t actually stuck?

2c. Invariants

List the invariants that must always hold for the core. Examples to adapt based on actual implementation:

Every CCIP message is either processed successfully OR stored in FailedMessageHandler. None are silently dropped.
A failed message can only be retried by an authorized role.
A failed message can only be resolved once (no double-spend on retry).
_getRecoverableBalance must never return more than the contract’s actual token balance.
Token recovery cannot extract tokens that are mid-flight in an unresolved failed message.
The core never decodes or inspects message.data — it passes bytes through opaquely.

Write these as Foundry invariant tests in test/core/invariants/CoreInvariants.t.sol where practical.

2d. Known Risks & Mitigations

Document any known risks that consumers of the core should be aware of:

What happens if the CCIP router is upgraded or compromised?
What happens if an admin key is compromised?
What are the gas limits for ccipReceive and what happens if processing exceeds them?
What is the maximum payload size and what happens if it’s exceeded?
Are there any centralization risks in the access control model?
How does the contract behave under chain reorgs?
What are the trust assumptions consumers inherit by using this core?

2e. Codec-Specific Security

Can a malformed payload cause the codec to return incorrect but non-reverting results?
Are there any ABI decoding edge cases with the version byte prefix (e.g., data that’s exactly 1 byte long)?
If the combined contract uses a type tag, can an attacker send a deposit message to a redeem handler or vice versa?
Can payload versioning be exploited by replaying old-version messages after an upgrade?

3. Reusability & Consumer Experience Analysis

Produce a file docs/CORE_CONSUMER_GUIDE.md that serves as the documentation someone would read when importing the core into a new project. This is the “developer experience” deliverable — the thing that makes the core actually useful as a standalone package.

3a. Quick Start

Show the minimal code needed to build a new application on top of the core:

// Minimal example: a new receiver that just logs messages
import {CCIPReceiverCore} from "@core/CCIPReceiverCore.sol";

contract MyReceiver is CCIPReceiverCore {
    constructor(address router) CCIPReceiverCore(router) {}

    function _processMessageMemory(
        // ... exact parameters from the actual virtual function
    ) internal override {
        // Your application logic here
    }
}

Fill in the exact function signatures from the actual code — do not use placeholder parameters. A developer should be able to copy-paste this and have it compile.

3b. API Surface Documentation

For every virtual or override hook in the core that a consumer touches, document:

Function signature with parameter descriptions
When it’s called in the message lifecycle
What the consumer must do in their implementation
What the consumer must NOT do (e.g., “do not make external calls that could revert here unless you want the message to go to failed state”)
Return value expectations if any
Gas considerations — is there a gas ceiling the implementation should stay under?

3c. Integration Checklist

Provide a checklist a developer follows when building a new receiver:

Adapt this list based on the actual core API — add or remove items as needed after inspecting the virtual hooks available.

3d. Anti-Patterns

Document what NOT to do when building on the core:

Do not decode message.data inside the core or modify CCIPReceiverCore
Do not override ccipReceive or _ccipReceive — override _processMessageMemory only
Do not store application state in the core contracts’ storage slots
Do not assume message ordering — CCIP does not guarantee order
Do not put user-facing recovery logic in the core — that belongs in the application layer
Do not use tx.origin or rely on msg.sender inside _processMessageMemory — the caller is always CCIPReceiverCore

Expand this list based on actual footguns discovered during the refactor.

3e. Separation Proof

Add a test file test/core/SeparationProof.t.sol that proves the core works without the application layer:

Deploy MockProcessMessage (the minimal mock receiver from section 1a) with no vault logic
Send a mock CCIP message through it
Verify processing, failure handling, retry, and recovery all work
This test file must NOT import anything from src/app/

This test is the definitive proof that the core is independently deployable and functional.

3f. Package Extraction Readiness

Verify that src/core/ could be copied to a standalone repository and function independently:

All imports within core are relative (no references to files outside src/core/)
The only external dependencies are OpenZeppelin and Chainlink CCIP (no application-level deps)
No hardcoded addresses, chain selectors, or environment-specific values in the core
All configuration is passed via constructor or admin functions, nothing is baked in

Document the exact foundry.toml and remappings.txt that a standalone core repo would need.

4. Deliverables Checklist

When complete, the following files must exist and be non-empty:

New test files:

test/core/CCIPReceiverCoreTest.t.sol
test/core/FailedMessageHandlerTest.t.sol
test/core/UniversalSenderTest.t.sol
test/core/CCIPBaseTest.t.sol
test/core/TokenRecoverableTest.t.sol (if applicable based on whether this abstract exists)
test/core/SeparationProof.t.sol
test/core/invariants/CoreInvariants.t.sol
test/app/VaultDepositCodecTest.t.sol
test/app/VaultRedeemCodecTest.t.sol

New codec files:

src/app/libraries/VaultDepositCodec.sol
src/app/libraries/VaultRedeemCodec.sol

New documentation:

docs/audit/POST_REFACTOR_SECURITY_REVIEW.md
docs/CORE_CONSUMER_GUIDE.md

New mock (for core testing):

src/mocks/MockProcessMessage.sol (minimal CCIPReceiverCore implementation for isolation testing)

Updated files (imports only):

All files in test/ compile and pass
All files in script/ compile
All files in examples/ compile

Final verification commands — run all of these, all must succeed:

# Build
forge build

# All tests pass
forge test -vvv

# No core→app dependency
grep -r "from.*app/" src/core/ && echo "FAIL: core imports app" || echo "PASS"

# No vault references in core
grep -ri "vault\|erc4626\|deposit\|redeem\|shares" src/core/ && echo "FAIL: vault refs in core" || echo "PASS"

# Separation proof test passes in isolation
forge test --match-path test/core/SeparationProof.t.sol -vvv

# Coverage report
forge coverage

# Old directories cleaned up
find src/ccip src/interfaces src/libraries -type f 2>/dev/null && echo "FAIL: old dirs not cleaned" || echo "PASS"