foundry

This skill provides specialized instructions for interacting with the CMTAT RuleEngine repository using the Foundry development framework. It is intended for blockchain developers, security auditors, and smart contract engineers working with security token frameworks, ERC-3643 compliance, and transfer restriction logic. Developers can leverage this to streamline their workflow when extending RuleEngineBase contracts, writing unit tests for RBAC or Ownable variants, and executing multi-chain deployments.

• Foundry Test Suite: Standardizes test structure using .t.sol files, HelperContract utilities, and descriptive naming conventions like test_RevertWhen_ to ensure consistency across the project.

• Deployment Scripting: Provides templates for automating contract deployments, handling environment variables for production configurations, and managing multi-chain scenarios using fork-based simulations with vm.createSelectFork.

• Security and Assertions: Details usage of Foundry cheatcodes such as vm.prank, vm.expectRevert, and vm.expectEmit, alongside specialized assertions for checking state transitions and access control roles like DEFAULT_ADMIN_ROLE and MINTER_ROLE.

• Architecture Integration: Offers context on CMTAT compatibility, ERC-1404 restriction codes, and RuleEngine configuration for multi-tenant environments where multiple tokens share a single compliance controller.

• Inputs: The skill expects interaction with standard Foundry commands (forge test, forge script) and assumes familiarity with Solidity 0.8.x and EVM storage patterns.

• Outputs: Provides ready-to-use Solidity boilerplate for unit tests, deployment logic that includes broadcast broadcast/verify steps, and troubleshooting patterns for gas consumption or rule conflicts.

• Constraints: Users must be aware of the 'as-is' status of the repository, the gas cost implications of excessive rule iteration, and the specific requirement to test both the RBAC and Ownable/Ownable2Step variants when modifying core modules.

• Practical Tip: Always utilize the established helper contracts (HelperContract or HelperContractOwnable) to maintain state compatibility across tests and ensure that restriction codes remain unique across your custom rule set to avoid user confusion.