Implemented contracts, tests, vendored dependencies, ABI exports, and deployment documentation.

Checks pass: forge build, 41 tests, forge fmt --check, and ABI consistency—including a clean offline build.

Important: launch policy prevents redirecting the launch pool’s fees. A separate-pool hook is included, with the conflict and required owner settings documented in docs/REVIEW.md and README.md.

Created launch.json with matching constructor references and required pool settings. Only the manifest changed.

forge build passed. All 41 tests passed.

Notes preserve the existing launch-pool fee-routing conflict for independent review.

Review complete. The findings file is written and validated: all three snippets match the tree, and 41 coverage rows answer every listed entry point.

Outcome: no permission bypass, escalation path, or paired-function asymmetry was found in the assigned area. The access model holds: every privileged setter is owner-gated with two-step transfer and disabled renounce, claims require current NFT ownership, free claims require current identity ownership plus a reporter record bound to the same holder, the hook checks both the PoolManager caller and the exact pool key, and the CREATE2 child receives the launch owner, never the factory or transaction origin. Reward accounting is symmetric between the view and claim paths and between the single and batch claim paths. ABI exports match the compiled artifacts, and formatting is clean.

Reported findings:

1. Medium, policy conflict. The brief requires 90% of the launch pool's trading fees to fund rewards. The launch pool's hook is the protocol guard and its fee goes to the payer and IMD by policy, so no contract here can receive those fees. The fee hook rejects the launch pool key with WrongPool and only serves a separate pool the owner initializes. This needs a scope decision, not a code fix.
2. Low, trust assumption. The hook owner sets the fee-token ask with no floor. A reproduction buys 1000e18 LaunchToken of fee inventory for 1000 wei of IMD.
3. Info, trust assumption. The owner can appoint themself reporter and self-certify activity to free-claim. Bounded by one claim per wallet and identity and the supply cap.

Not covered: no launch.json exists in the tree yet, so the manifest itself could not be inspected. The README's constructor table and dependency order were checked against the source instead. The scratch test under test/scratch/ is disposable and nothing else in the tree was changed.

The review is complete. The findings file is valid, all three snippets match the tree exactly, the scratch test is removed, and the working tree holds nothing beyond .imd-findings.json.

Scope covered. I applied the Economic Security, Invariant and Flow Gap guides to all seven source files, read the protected deployment test, fixtures and the builder's review notes, built the project and ran its full suite (41 tests pass). I traced the reward ledger in detail: the cohort retirement loop is monotonic, the nextCap - index subtraction cannot underflow, allocation is path independent, the conservation identity holds across every writer, and view and write paths agree. The fee hook's take and return-delta flow nets to zero against the real PoolManager. No critical or high defect was found, so no proof files were written.

Findings reported (3, in .imd-findings.json):

• Medium, policy conflict. The brief's "90% of trading fees from the v4 pool" cannot be met. The launch pool's hook is the factory's guard and its fees go to payer and IMD. SwarmlerFeeHook hard-codes itself in its pool key and rejects any other key, so it only serves a second pool nobody is obliged to fund. This needs a requester decision before the frontend advertises fee rewards.
• Medium, stranded funds. Deposits are credited to the reserve without regard to remaining claim capacity. After every NFT caps at 1 IMD, the permissionless forwardFees() and any deposit keep locking 90% of each amount forever. Reproduced locally: 756.875 IMD stranded after a 3,000 IMD deposit at mint-out, growing with each further deposit.
• Low, fixed-price sale leak. Token-side fees sell at an owner-set ask with no oracle or expiry. Any ask increase can be front-run at the stale price, and the pool only ever realises the lesser of ask and market.

Coverage. All 39 listed entry points have rows, plus three invariant rows. One row is unreached: no launch.json exists in the tree yet, so the manifest could not be inspected, though the README's proposed constructor arguments are schema consistent.

The review is complete and .imd-findings.json is written and validated: the snippet matches the tree and all 39 listed entry points have a coverage row, plus three invariant rows.

Outcome: no reproducible math defect found in the assigned area. The holding-time reward ledger in src/Swarmlers.sol is exact under integer arithmetic. I traced every division, cast and accumulator against the Math Precision, Boundary and Numerical Gap checklists and then probed the seams with six scratch tests against the real contracts. All six pass.

What I checked in depth:

• Reward index and cohort retirement. Each increment is clamped to the time target, the next cap and reserve / activeCount, and totalAllocated grows by exactly increment × activeCount. The sum of every token's earned amount equals the global allocation after every probed step, including mid-cohort reserve exhaustion followed by a refill, an increment landing exactly on a cap, reserve dust smaller than the active count, and a 100-year elapsed period at the maximum duration.
• Underflow DoS path. The cap minus index subtraction cannot underflow because birth indices are non-decreasing in token id and the cursor advances exactly when the index reaches a cap. A receiver re-entering checkpoint during a mint sees consistent state.
• Rate floor. The per-second rate is floored, so an NFT reaches the 1 IMD cap one second after the configured duration. The README already documents this, so it is not reported as a defect.
• Hook fee math. The ceil-rounded quote charges 1 wei for 1 wei at price 1, the 512-bit mulDiv cannot overflow silently, and the fee delta taken inside the v4 callback nets to zero against the returned hook delta in PoolManager.modifyLiquidity.
• Art. The rarity permutation is a bijection yielding exactly the documented tier counts, and the flagged divide-before-multiply is intentional grid math.

One info item recorded. With 2,475 distinct mint cohorts, the first checkpoint after mass cap expiry costs about 8.3M gas. That is well under the block limit and the ledger stays exact, so it is reported only so the operator can budget a keeper call.

Static-analysis leads from Slither and Aderyn all resolved as intentional or non-issues: the strict equalities are exact-landing checks, the uninitialised locals are deliberate defaults, and the packed encoding is string assembly rather than a hash input.

Nothing outside my area rose to a severe defect. The launch-pool fee-routing conflict is already recorded by the builders in docs/REVIEW.md for the other reviewers.

The review is complete. The findings file is valid, both quoted snippets match the tree line for line, the scratch test is removed, and the working tree has no stray files.

Outcome. The on-chain logic holds across my area. I found no loss-of-funds or permission defects, so no finding carries a proof test. Two findings are recorded in .imd-findings.json, plus a coverage row for every one of the 39 listed entry points and three extra rows for invariants, periphery and the manifest.

Findings reported

• Medium, policy conflict. The brief promises 90% of the v4 pool's trading fees to NFT rewards, but the launch pool's hook is the factory's initialization guard and its fee goes to the payer and IMD. The fee hook's own key check rejects that pool, and the separate pool it serves has no reserved liquidity. The builder already flagged this as R1; I confirmed it independently with a concrete call that reverts with WrongPool.
• Low, configuration deferred past launch. The hook deployer takes the public PoolManager address through an owner setter after launch rather than a constructor argument, so the attested manifest cannot describe the child hook's manager, salt or pool key. The fix is a fourth constructor argument with the code check kept in the deploy path.

What I verified and how

• Traced the reward ledger end to end. Each active NFT receives the same per-funded-second increment, the index never passes the first active cohort's cap, cohorts retire in mint order, and the sum of per-token earnings equals the allocated total. The project's invariant suite plus my boundary scratch test both pass.
• Traced the v4 hook delta accounting against the vendored Hooks and PoolManager code. Taking the accrued fees and returning them as the hook delta nets to zero for the hook and leaves the LP with principal only.
• Checked the activity registry, the CREATE2 helper, the art library's rarity permutation, and all five exported ABIs against the build. All consistent.
• Full suite: 41 tests pass. Static-analysis leads were all benign on inspection.

Not reached. No launch.json exists yet, so the manifest row is marked unreached. The Python ABI checker could not run on this worker because python3 is absent; I compared the ABIs with node instead.

Added failure-path tests, fuzzing, and three multi-actor invariant campaigns, entirely under test/.

Validation passed: 91 tests, 0 failures, 0 skips, including 49,152 calls across the new invariant campaigns. Both forge build and forge test --offline succeeded.

Coverage notes in test/TESTING.md document offline limitations and the existing launch-pool fee-routing conflict.

Review complete. The findings file at the repository root holds six findings and a coverage record for all 38 entry points plus two invariant rows. No source, config or test file outside my scratch directory was changed.

What I found

• Medium, policy conflict. The brief's "90% of v4 pool trading fees" cannot reach the reward pool. The launch pool carries the factory's initialization guard as its hook and pays fees to the payer and IMD by policy. SwarmlerFeeHook accepts only its own pool key and reverts WrongPool for the launch key, which I reproduced against the vendored PoolManager. Three specialists reported this; merged into one finding. It needs a requester decision, not a code patch.
• Medium, stranded funds. IMD deposited beyond the collection's 2,500 IMD lifetime reward capacity is locked in the reserve forever. I reproduced the economics specialist's scenario exactly. After every NFT caps, the reserve holds 756.875 IMD that no function can move, and permissionless forwardFees keeps adding to it.
• Low. The owner-set fixed ask for token-side fees can be front-run on every raise and underpriced by the owner. Two specialists reported this; merged into one.
• Low. SwarmlerHookDeployer takes the public PoolManager address through a post-launch setter instead of a constructor argument, against the launch rules.
• Info. The reporter key can self-certify free claims, and a worst-case checkpoint costs 8.27M gas. Both reproduced and kept as trust and operations notes.

Coverage

My own pass over the reward ledger, hook delta accounting, mint and claim paths, manifest and contract sizes found nothing the specialists missed. The full suite passes and the manifest matches the constructors in order and type.

The responses file is in place at the repository root. The harness deliberately excludes it from git through the workspace's exclude list, as it does for .imd-blocked.json, so it is read from the tree rather than the commit. Nothing further is pending.

Outcome

All six findings are answered in .imd-responses.json. Two were fixed in source, four are reproduced and answered without code changes. The full suite passes: 43 tests across 8 suites, forge fmt --check clean, ABI exports match the build.

Fixed

• Stranded reserve (medium). Reproduced exactly as reported: 765.875 IMD locked after a sold-out, fully capped collection received more deposits. Swarmlers now exposes remainingRewardCapacity() (the 2,500 IMD lifetime bound minus allocated and reserved rewards) and credits each deposit's reward share only up to that capacity, with the remainder going to the creator in the same transaction. The checkpoint preserves the sum of reserve and allocation, so the bound is exact. Two new tests cover the split arithmetic and the reviewer's exact scenario, and the shared solvency check now asserts the capacity bound in every unit, fuzz and invariant run.
• PoolManager as a constructor argument (low). SwarmlerHookDeployer takes the PoolManager as a fourth immutable argument, stored without a code probe so the empty-chain constructor check passes, and refuses initCodeHash, predict and deploy until that address has code. The setter is removed. I re-verified the Ethereum PoolManager read-only today: it has code on chain id 1 and answers owner(). The manifest line in the docs now carries it as a literal fourth argument.

Reproduced, left as designed, docs sharpened

• Launch-pool fees (medium). True by construction: the launch pool's hook and fee beneficiaries are fixed by the pinned policy, which says they are not an open question. The README and review notes now state that the launch pool funds 0% of NFT rewards under this policy, name the two voluntary routes (payer deposits claimed fees through depositProceeds, or a separately funded hook pool), and say the requester must decide before the site advertises trading-fee rewards. I did not write .imd-blocked.json, because the pinned terms forbid asking the requester about the pool's fee allocation and the other fixes would otherwise not ship.
• Fixed-ask MEV (low), reporter self-certification (info), worst-case checkpoint gas (info). Each reproduces and is the documented trust or liveness assumption. The ask front-run adds no exposure beyond a stale ask already allowed, so the code stays. Operations docs now call for a keeper checkpoint() after large funded periods.

Not done. No Slither or Mythril run, no mainnet fork, no deployment, and no launch.json, all by assignment scope.

The manifest is re-derived from the revised tree. Only launch.json changed.

What was stale. The revised SwarmlerHookDeployer constructor now takes four arguments, with the Uniswap v4 PoolManager added as an immutable fourth parameter. The previous manifest listed three, which would have failed the factory's constructor check.

What I changed in launch.json

• Added the fourth constructor argument for the hook deployer: the Ethereum Uniswap v4 PoolManager, written in lowercase as the schema requires. The README documents this address for that parameter, and I confirmed it on chain 1 through the local RPC. It has code and answers owner().
• Rewrote the notes to describe the revised behaviour: the immutable PoolManager pin with no code probe in the constructor, the 2,500 IMD reward-capacity bound with excess credited to the creator, the permissionless maintenance calls (sync proceeds, creator withdrawal, checkpoint, metadata refresh, fee forwarding), the fee-token sale at an owner-set ask, and the unchanged launch-pool fee conflict left for independent review.

Unchanged. Kind, token fields (LaunchToken, Swarmlers, SWARMLER, 18), the first two contracts and their arguments, contract order, and the pool block exactly as the "This launch" section gives it.

Verification

• JSON is valid, has only schema keys, no odd-length or uppercase hex, notes are 2,602 characters, and every contract name is unique and under 32 characters.
• Each constructorArgs count matches the constructor in both source and the exported ABI (1, 2, 4).
• forge build and forge test pass offline: 44 tests, 0 failures. That includes a scratch test that deploys the three contracts in manifest order on an empty chain with the manifest's exact arguments and checks owners, wiring and the PoolManager value.
• git diff --stat shows launch.json as the only modified tracked file. The scratch test lives under test/scratch and is not submitted.

The findings file is excluded by the harness's own git exclude list, so it is collected out of band as intended. The work is complete.

Outcome: the suite builds and passes against the revised source, with 98 tests across 16 suites and 0 failures, run offline.

What broke and what I changed. The latest accepted source commit changed two things under my tests. The deployer now takes the PoolManager as an immutable fourth constructor argument with no setter, and the collection now caps the reward share of any deposit at the remaining lifetime capacity, crediting the overflow to the creator. My previous suite assumed the old setter and a fixed 90/10 split, so the build failed. The revision touches only the files that depended on that:

• test/helpers/HookFixture.sol uses the four-argument constructor.
• test/HookAdversarial.t.sol drops the setter calls, and the ownership-handoff test now proves that a second handoff cannot redeploy or rebind the child. Two new tests cover the empty-chain story: a manager address without code is accepted by the constructor, refused by every view and by deploy until code exists there, then bound immutably into the child and its address. A different manager argument yields a different child address.
• test/RewardsStateful.t.sol models the capacity overflow in the creator ghost from ghost values alone, adds an invariant that reward credit never exceeds 2,500 IMD and that the contract's capacity view agrees with the ghosts, and pins a sequence that drives funding past capacity through deposits, a late sync after accrual, and a paid mint at zero capacity.
• test/RewardsAdversarial.t.sol adds a 1,000-run fuzz of the deposit split against an independent oracle through both the pull and direct-transfer paths, plus the exact-fill and one-wei-over boundaries and the all-to-creator path at zero capacity.
• test/TESTING.md records the additions.

One informational finding is written to the findings file. Capacity is sized to the maximum supply rather than the minted supply, so reserve for unsold NFTs stays unreachable while they remain unsold, which contradicts the review note's claim that nothing is left to sweep. Reproduction with exact numbers is included. It is a disclosure point rather than a code defect, so no test asserts either way.

Still owed by later work: fork validation of the live IMD token, the Identity registry, and the Ethereum PoolManager, as before. Nothing was committed, and no files outside test/ were changed.

The review is complete. The findings file is written, snippets verified against the tree, the scratch tests are removed, and the working tree is clean apart from the findings file.

Both round-1 blocking findings are settled.

• Stranded reserve (dd09d704) is fixed. remainingRewardCapacity() bounds the reward share of every deposit at 2,500 IMD minus what is allocated or reserved, and the excess goes to creator credit in the same call. I reran the original scenario: after a 3,000 IMD deposit onto a sold-out, fully capped collection the reserve is zero, the extra 10 IMD lands on creator credit, and every NFT still claims 1 IMD.
• Deployer PoolManager (9fa76a10) is fixed. The manager is now the immutable fourth constructor argument, stored with no code probe so the empty-chain floor passes, and deploy refuses while the address has no code. The manifest lists it lowercase as the fourth entry and the exported ABI matches the compiled constructor.
• Launch-pool fee routing (740400d1) reproduces exactly as before and cannot be changed in source under the pinned launch terms. The README and review doc now disclose it plainly. I downgraded it to info: a confirmed policy/brief conflict that needs a requester decision and careful frontend wording, with nothing left for the author to fix.

Advisory items on the fee-token ask, reporter self-certification, and worst-case checkpoint gas are unchanged and now documented as trust assumptions. They stay at info. I added one info disclosure from the independent tester: capacity counts all 2,500 possible NFTs, so reserve for unminted NFTs idles until they are minted. It is drawn down by later mints, so it is not a loss.

No new defects. The full suite passes (98 tests), launch.json is schema-valid with correct constructor arities, contract sizes are well under the limits, and the static-analysis leads all resolved as benign on inspection. Coverage answers all 38 entry points plus two invariant rows.

Done. The frontend is built, validated, exported and committed on top of the pinned source commit.

What was delivered

• web/: Vite + React 18 + TypeScript app with wagmi 2 and viem 2, plus package.json, lockfile, tests, scripts/manifest.mjs, README.md, DESIGN.md and a web/.gitignore for node_modules.
• dist/: the static export with relative base, five ABI JSON files, favicon, og image and imd-deployment.json.
• docs/FRONTEND_VALIDATION.md and docs/DESIGN.md.

Runtime configuration lives only in dist/imd-deployment.json. The app fetches it and the referenced ABIs at startup, builds the wagmi chain from its network block, and takes every Uniswap address from there. The manifest's identity fields, contract set, pool key, network and walletAddChain were verified byte-for-byte against the handoff, all four ABI keccak hashes match, and every exported file's SHA-256 is listed.

Controls on the page: connect wallet, switch network with wallet_addEthereumChain fallback on 4902, approve and mint, eligibility preflight and free claim, owned Swarmlers with claim, batch claim, pair and refresh, reward pool deposit with approval step, checkpoint, sync, creator payout, SWARMLER swap with quoter simulation, slippage and the two Permit2 steps, fee hook forwarding, fee-token purchase and deployment, and an owner-only setup panel for reporter, reward duration and opening the mint.

Validation results

The Better Interface review found eight items, including a real bug where the switch-network button stayed disabled off-chain, a below-the-fold mint control at 390, and a light-mode button contrast of 3.81:1. All were fixed before the final build and are recorded with file locations in the validation document.

Limitations to note

• No transaction was broadcast. Success paths after signing are untested on chain, and minting, claims, rewards and the fee hook are still unconfigured on mainnet, so those states were observed only as disabled controls with reasons.
• WebKit, screen readers, native zoom and RTL were not exercised.
• DESIGN.md could not be placed at the repository root because the write scope excludes it. It is at web/DESIGN.md with a copy in docs/.

Requirements, one line each

• "shows Swarmlers": met, web/src/Gallery.tsx renders the six newest from on-chain token URIs; live load showed #20 to #25 with rarity labels.
• "claim eligibility": met, web/src/ClaimPanel.tsx reads eligible, status, identityClaimed, walletClaimed as the identity ID is typed.
• "pairing instructions": met, the "How pairing works" section in web/src/App.tsx plus the Pair form under each owned Swarmler.
• "reward status": met, web/src/RewardsPanel.tsx facts and per-token claimable, earned and paid values.
• "free claim only for verified active Identity MD holders": met, the claim checks the activity registry and shows "No activity reporter is configured yet".
• "All other mints cost exactly 0.25 $IMD": met, price read from MINT_PRICE, approve-exactly-then-mint flow in web/src/MintPanel.tsx.
• "25 creator supply": met, "Minted 25 of 2500" read live.
• "Rarity tiers": met, gallery and owned items show the tier.
• "Dynamic tokenURI": met, Refresh metadata control and on-chain images.
• Wallet connection, wrong-network switch and add: met, web/src/WalletButton.tsx and web/src/NetworkBanner.tsx.
• Swap controls: met, web/src/SwapPanel.tsx quotes through the Quoter and executes through the Universal Router with Permit2.
• Observability of each action's states: met, TxStatus in web/src/ui.tsx covers checking, signing, mining, done, error.
• Tests: met as committed in web/test/unit.test.ts; not re-run here because web/node_modules is absent.
• dist/imd-deployment.json: met. All 11 asset SHA-256 values match the files, the four contract entries, poolKey, network and walletAddChain match the handoff byte for byte, no extra keys, and the app loads it at runtime in web/src/config.ts. The ABI JSON is identical to docs/abi; I did not recompute the keccak hashes.
• "host it on IPFS at a public URL": after review.
• "90% of trading fees from the v4 pool": needs the requester. The contracts do not route launch-pool fees, and the site says so plainly in the Reward pool card, so this is not faked.

The idea. A plain, warm-toned dashboard for minting and holding Swarmlers, carried by one device: the amber spider mark and accent against a paper background.

Findings written to .imd-findings.json (five, none high):

• Medium, bug. The Trade card shows "connect to read" for liquidity and pool tick because public StateView reads share one query gated on the wallet address.
• Medium, fidelity. The Fee hook card's "IMD held" reads the connected wallet's balance, not the hook's, and the forward button is disabled on the viewer's balance. Only reachable once the hook is deployed, so verified from source.
• Medium, bug. Your Swarmlers refetches ownerOf for every token every 15 seconds, about 100 multicall requests per cycle at the brief's 2,500 supply.
• Low, accessibility. The disabled first-screen mint button fades the price label to roughly 2.4:1 in light mode.
• Low, taste. The Reward pool lead is two sentences joined by a semicolon and repeats values the facts grid already shows.

Limits. The probe ran with Playwright from the home directory and passed everything. WebKit could not launch on this machine because system libraries are missing, so the Safari pass is from source only; the stylesheet uses no feature WebKit lacks. No wallet was available, so signing paths were judged from their disabled, pending and error states. Scratch files were removed and no tracked file was changed.