Done. The deliverable is a complete Foundry project at the repository root, verified offline with an empty environment, including from a clean copy containing only the new files.

What was built

• src/BriefsToken.sol: contract BriefsToken, a fixed-supply ERC-20 on OpenZeppelin 5.4.0. Name "Briefs", symbol "BRIEFS", 18 decimals. The constructor takes no arguments, makes no external calls, and mints the whole supply once to msg.sender. There is no owner, minter, burn, pause, blocklist or fee, so launch flows move exact amounts with no exemption list needed.
• script/DeployBriefsToken.s.sol: a reviewable deploy wrapper whose deploy() the tests call directly. It reads no environment variables.
• test/BriefsToken.t.sol: 25 tests covering metadata, the exact supply, minting to the constructor caller through a CREATE2 factory stub and through the script, transfer and allowance success paths, failure paths with ERC-6093 errors, a fuzzed supply-conservation test, absence of the admin, mint, pause and freeze selectors the protected harness probes, no DELEGATECALL, CALLCODE or SELFDESTRUCT in the runtime, and rejection of ETH.
• foundry.toml pins solc 0.8.26 by version, sets bytecode_hash = "none", disables ffi and filesystem permissions. remappings.txt points at the vendored libraries.
• lib/: forge-std 1.9.7 and OpenZeppelin Contracts 5.4.0 as plain files, no .git directories and no .gitmodules.
• README.md documents assumptions, the launch parameters the manifest step owns, deployment, operational responsibilities, security review notes, and the test inventory.

Check results

Check	Result
forge build (offline, empty env)	success, 28 files
forge test (offline, empty env)	25 passed, 0 failed
forge fmt --check	clean
Bytecode	no metadata hash, no link references, runtime 1807 bytes

Slither and Mythril were not available here and did not run. No launch.json was written, and nothing under .git/, .github/ or .env was touched. The working tree is left uncommitted for the upload step.

launch.json is written and is the only changed file. The build compiles and all 25 existing tests pass.

What the manifest says

• Token is BriefsToken, name Briefs, symbol BRIEFS, 18 decimals, with an empty constructorArgs list because the accepted constructor takes no parameters. totalSupply is the exact constant the constructor mints to msg.sender, 1,000,000,000 scaled by 18 decimals.
• Contracts is empty. The accepted tree contains only the token, and the deploy script is a helper, not a launch contract.
• Pool and economics are copied verbatim from the launch reference: IMD as the paired currency, fee 12500, tick spacing 60, the one-to-one initialPrice, and the requester's economics object unchanged.
• Notes describe only the token actually present, including that it needs no $factory, $poolManager or $launchNumber exemptions because nothing is taxed.

Checks run

• A script confirmed the manifest has exactly the schema's six top-level keys, the verbatim economics, the supply matching the constructor, and notes under the 4,000 character limit.
• forge build succeeded and forge test passed 25 of 25.
• git status shows launch.json as the only addition. No configuration, lib, or workflow file was touched.

The review is complete. No defects were found in the math, boundary, or numerical-gap areas, and the findings file records that with full coverage.

What I reviewed. BriefsToken is an unmodified OpenZeppelin 5.4.0 ERC20 with a single constructor mint of a compile-time constant. I confirmed the vendored ERC20, Context, and error interfaces are pristine, that there are no submodules, and that the compiled ABI exposes only the three listed state-changing entry points plus views.

What I checked against the three guides, with concrete inputs.

• Supply constant: the literal flagged by aderyn evaluates to exactly 1e27 at compile time with checked arithmetic, and decimals() returns 18, matching the manifest.
• Transfer boundaries: amount equal to max uint256, supply plus one, whole balance, self-transfer of the whole balance, and zero. Each either reverts with the right ERC-6093 error or moves the exact amount. The unchecked subtraction in _update is guarded by the preceding balance check.
• Allowance arithmetic: fuzzed every allowance below max against every spend up to the supply. The remaining allowance is exactly allowance minus spend, max allowance never decrements, and the balance check still runs under max allowance. A zero-address sender reverts for both zero and nonzero values, so there is no phantom mint path.
• Supply invariant: no mint or burn entry point exists, transfer to the zero address reverts before the burn branch, and a three-party fuzz conserves the sum of balances at 1e27.
• Launch split: 10%, 77% and 13% of 1e27 divide exactly with no dust, and intermediates stay far below overflow.
• External boundaries: no external calls, no payable or fallback paths, no bytes decoding. ETH and unknown selectors revert.

Output. .imd-findings.json holds an empty findings list and seven coverage rows, all holds, covering the three entry points, the constructor, and the invariants above. The scratch probe under test/scratch/ is gitignored and not part of the submission. The existing 25-test suite passes.

The review is complete. No defects were found in the Economic Security, Invariant or Flow Gap areas, and .imd-findings.json holds an empty findings list with eight coverage rows.

What was reviewed. The token at src/BriefsToken.sol is OpenZeppelin 5.4.0 ERC20 plus a no-argument constructor that mints a compile-time constant of 1e27 minor units to msg.sender. There are no other state-changing functions, no owner, no hooks, and no external calls. Static analysis flagged only a large numeric literal, which is the intended supply constant and not a defect.

Checks performed against the three guides:

• Economic Security. No fee, rebase, blacklist or pause behavior exists, so no launch flow can arrive short and no value can be extracted atomically. I simulated the 10/77/13 percent split through transfer and approve plus transferFrom, then claims and a buy/sell round trip. Every recipient held exactly its share and the factory ended at zero.
• Invariant. A 256-run, 128,000-call Foundry invariant with random transfer, approve and transferFrom traffic kept the sum of balances equal to a constant total supply with zero handler reverts. Self-transfer and self-transferFrom conserve balance and spend allowance correctly.
• Flow Gap. The periphery dependency is the vendored library itself. The five OpenZeppelin files the token compiles against are byte-identical to the published npm 5.4.0 release, and the library is committed as ordinary files with no submodule.

Coverage. All three verifier-listed entry points are marked holds, plus rows for supply immutability, exact launch flows, library provenance, opcode restrictions and manifest expectations. Nothing was left unreached. The protected harness could not be run locally because it needs Uniswap v4 core, which is not vendored, so pool-side behavior was verified by direct transfer and transferFrom simulation instead.

The scratch test lives in test/scratch/ and is gitignored. No tracked file was changed.

Review complete. The Briefs token has no defects in the Access Control, Trust Gap or Asymmetry areas, and the findings file records a clean result with full coverage.

What I checked

• Access control. The compiled ABI exposes exactly three state-changing functions: approve, transfer and transferFrom. There is no owner, minter, pauser, blocklist, initializer, receive or fallback. A fuzz over unknown selectors confirmed every other call reverts. The runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Constructor and launch flow. The whole supply of 1e27 minor units is minted once to the constructor's caller, which is the factory under CREATE2. The constructor takes no arguments, so the manifest has nothing to resolve. The internal mint is unreachable after construction.
• Asymmetry. Both transfer paths reach the same OpenZeppelin update routine. Allowances decrement by exactly the spent value, no branch skips validation or charges on one side only, and there is no admin variant of any user function. A fuzz confirmed no caller, including the deployer, can move a holder's balance with zero allowance, and that approve writes only the caller's own allowance row.
• Trust gap. The token holds no fee, recipient, oracle or economic parameter, so no privileged action can redirect value. The launch economics live in the factory, outside this tree.
• Dependency integrity. The five vendored OpenZeppelin files the token compiles against are byte-identical to upstream v5.4.0, and lib contains no git submodules.

Tools run. The project build and its 25 tests pass. My five scratch fuzz tests passed and were removed. Slither and aderyn output from the verifier reported nothing above a style note on the numeric literal, which is a compile-time constant and not a defect.

Not covered. Nothing in my area was left unreached. Pool seeding, swap behaviour and manifest contents belong to the other specialists and to the protected launch test, which this token's plain transfers satisfy by construction.

The file .imd-findings.json holds an empty findings list and eight coverage rows: one for each of the three entry points and five for the invariants above.

Review complete. No defects found in the assigned area, and .imd-findings.json holds an empty findings list with a full coverage record.

What was audited. The Briefs token at src/BriefsToken.sol is a 33-line contract: it inherits OpenZeppelin 5.4.0 ERC20 unchanged and adds one constructor that mints the fixed supply to the deployer. I traced all three state-changing entry points against the Execution Trace, Periphery and First Principles guides, plus the constructor, the conserved-supply invariant, the vendored base contracts, and the compiled runtime.

Checks performed

• Execution Trace: sentinel inputs (zero address, zero amount, max uint, max minus one allowance), self-transfer and self-transferFrom, owner calling transferFrom without allowance, from equal to the zero address reaching the mint branch, truncated calldata, value sent to nonpayable functions. All revert or conserve balances as intended.
• First Principles: the constructor's assumption that msg.sender is the intended holder was tested through a direct call, a CREATE2 factory stub and an intermediate contract. The supply always lands on the direct creator, never tx.origin. The supply constant evaluates to exactly 10^27 and decimals is 18.
• Periphery: the five OpenZeppelin files in the token's compile graph are byte-identical to the 5.4.0 package fetched from the npm registry. The GitHub raw host was refused by the sandbox, so npm served as the upstream copy. Other vendored files differ only in formatting and are not imported by the token.
• Bytecode: an independent opcode scan of the compiled runtime found no DELEGATECALL, CALLCODE, SELFDESTRUCT or any call-family opcode. There is no receive or fallback.
• Static analysis leads: slither reported nothing. The aderyn large-literal note points at a readable underscore-separated constant that the existing test confirms evaluates correctly.
• The existing 25-test suite passes, and 12 scratch probes I wrote also passed before I removed them.

Not reported. The standard ERC-20 approve-overwrite race is inherent to the standard and documented in the coverage row rather than filed as a defect. No files in the tree were modified.

Work is complete and verified. Here is the recap.

Outcome. Added an invariant suite over random call sequences and an edge-case/property suite beside the existing unit tests. All three suites pass together: 63 tests, with the invariant run driving 25,600 handler calls per full run. No defects were found in the token, so no findings file was written. Only paths under test/ changed, and no submodule or configuration was touched.

Files added

• test/invariant/BriefsTokenHandler.sol: a handler with six actors, a ghost ledger of balances and allowances, and nine bounded entry points. Four of them exercise failure paths inside sequences and assert the exact ERC-6093 error and unchanged state. Two probe non-ERC-20 selectors (mint, burn, pause, upgrade, permit, random bytes) and ether deposits from every actor including the deployer.
• test/invariant/BriefsToken.invariant.t.sol: seven invariants. Fixed supply, sum of balances equals supply, every balance and allowance equals the ghost ledger, nothing stranded at the zero address or on the token, no ether held, runtime codehash unchanged, metadata constant. An afterInvariant hook guards against a vacuous run by requiring successful transfers, checked reverts, and rejected foreign calls in each sequence. Inline config sets 256 runs at depth 100.
• test/BriefsTokenEdges.t.sol: 37 unit and fuzz tests at 1000 runs covering one wei, whole supply, supply plus one, max uint, self-transfer as identity, round-trip, additivity of split transfers, multi-hop conservation, exact revert payloads, approve overwrite and idempotence, max versus max-minus-one allowance semantics, zero-address from and to ordering, zero-value transferFrom without allowance, unknown selectors, truncated calldata, calls carrying value, and launch constraints (contract identifier within 32 bytes, supply fits int128 and uint96, runtime equals compiled runtime).

Grounding. The invariants were checked for teeth against a scratch mutant that skims one wei per transfer. Both the ledger and the sum-to-supply invariants failed on it within the first sequence, so a fee, reflection, or hidden mint in a future revision would be caught.

Implementation review. The vendored OpenZeppelin 5.4.0 ERC20 and Context sources are unmodified, and the token adds only a constructor mint. Two of my initial test expectations were wrong rather than the contract: a zero-amount transferFrom from the zero address reverts on the approver check, not the sender check, and the fuzzer can draw the token's own address as a caller. Both were corrected in the tests, and the behaviour is standard.

The review is complete and recorded in .imd-findings.json with zero findings and five coverage rows. No tracked file was changed.

What I checked

• The token in src/BriefsToken.sol is OpenZeppelin 5.4.0 ERC20 plus a no-argument constructor that mints the full supply to the caller. The vendored library files are the standard implementation with no edits to transfer, allowance or mint logic.
• The constant supply equals the manifest's totalSupply exactly, decimals return 18, and the constructor arguments list is empty on both sides.
• The compiled ABI exposes only the standard ERC-20 functions and two constant getters. There is no owner, mint, burn, pause, blocklist or upgrade path, and the runtime has no delegatecall, callcode or selfdestruct.
• The project's own suite passed: 63 tests including a 256-run invariant campaign.

Specialist input

All five specialists reported no findings, so there was nothing to reproduce or merge. The one aderyn lead, a large numeric literal, is a compile-time constant written with digit separators and is not a defect.

Coverage

All three entry points are marked holds, with the traced guard, state change and failure path given per row. Two extra rows record the fixed-supply and no-privilege invariants.