Add AOXC standalone library & manifest, Foundry installer, script/test refactors

[aoxc]

Motivation

• Expose a machine-readable, chain-consumable AOXC library surface and manifest so external chains/CLIs (e.g. aoxchain) can safely consume approved wrapper modules.
• Provide a deterministic Foundry installation/runbook to make local developer and CI setup idempotent and easier to reproduce.
• Harden deployment/rehearsal/verification scripts and runtime code paths with safer imports, explicit type checks and small API/constructor fixes for auditability.

Description

• Documentation and tooling: add README sections for Foundry installation and AOXC library integration, plus a new docs/AOXCHAIN_LIBRARY_INTEGRATION.md and docs/AOXC_STANDALONE_LIBRARY_LAYOUT.md describing the integration/standalone layout.
• Foundry helper & manifest generator: add script/install_foundry.sh (idempotent installer/validator) and script/generate_library_manifest.py (scans src/aoxc-library and emits src/aoxc-library/manifest/approved-modules.json).
• Library surface and registry/factory: add src/aoxc-library with IAoxcModule, AoxcModuleRegistry, AoxcModuleFactory, thin wrapper AoxcDaoManagerModule, example modules (AoxcExampleTokenModule, AoxcExampleTreasuryModule), and the generated approved-modules.json manifest.
• Script & contract refactors and safety fixes: switch to explicit named imports (e.g. import {Script} from "forge-std/Script.sol"), add owner-helper internal checks in several small bridge/vault contracts, add bounds checks and safe casts with forge-lint comments in registry/finance modules, and fix a sentinel revert argument to match the expected type.
• Tests updated: test files updated to named imports, use SafeERC20 where appropriate and IERC20(...).safeTransfer(...), and include small deterministic fixes for proxy initialization casting.

Testing

• Ran forge build to compile the full repository and verify import changes; the build completed successfully.
• Ran the full test suite with forge test (unit + integration) and forge test --fuzz (fuzz tests); all automated tests passed.
• Executed the manifest generation script locally (python3 script/generate_library_manifest.py) to produce src/aoxc-library/manifest/approved-modules.json for CI consumption.

---

Codex Task

[chatgpt-codex-connector]

💡 Codex Review

aoxcon-evm/src/aoxc-library/system/registry/AoxcModuleRegistry.sol

Line 39 in be108a3

function registerModule(address module, bytes32 moduleType) external onlyOwner {

Permit factory to register deployed modules

AoxcModuleFactory.deployModule always calls REGISTRY.registerModule(...), but registerModule is restricted by onlyOwner; in the normal setup where an EOA/multisig owns the registry to call setTemplate, every deployment reverts because the registry sees msg.sender as the factory contract. The only workaround is transferring registry ownership to the factory, which then blocks future template updates, so either deployment or upgradeability is effectively broken.

---

aoxcon-evm/script/generate_library_manifest.py

Line 35 in be108a3

import_match = IMPORT_RE.search(text)

Resolve base import from inherited contract, not first import

parse_file sets base_import from the first import match in the file, which is not necessarily the import of the inherited base contract; for example, AoxcExampleTreasuryModule imports OpenZeppelin tokens before IAoxcModule, and the generated manifest now records @openzeppelin/contracts/token/ERC20/IERC20.sol as its base_import. This makes the published manifest inconsistent and can mislead downstream CLI/CI consumers that trust it as source-of-truth metadata.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".