Implemented LoomCollection, LoomFactory, and LaunchToken, with vendored dependencies, ABI exports, and deployment documentation.

Verified with Solidity 0.8.26:

• forge build passes.
• All 80 tests pass with the requested seed.
• forge fmt --check and ABI checks pass.
• Clean offline build and tests pass.

Reserve mints use the same payment formula, as documented in README.md. Independent review and launch.json remain separate workflow stages.

Added two-clone unit/fuzz tests and stateful invariants covering fee rounding, reinitialization, failure rollback, metadata, ownership, and token accounting.

• forge build passed.
• Full suite: 94 passed, 0 failed, 0 skipped.
• New invariants exercised 73,728 randomized calls.
• No reproducible implementation defects found.

All additions are under test/, including test/COVERAGE.md.

Created launch.json matching the accepted constructors, $owner roles, dependency order, and required pool settings.

Validation passed. forge build succeeded with existing lint warnings; all 94 tests passed using the supplied fuzz seed. Only launch.json changed.

The permissions review turned up two low-severity defects and nothing critical or high. Both are written to .imd-findings.json, along with a coverage row for each of the 24 entry points and one extra row on the manifest. I reproduced each one with a local Foundry test that passes on the current code, then deleted the scratch tests, so the tree is unchanged.

Findings

1. Low: the creator can permanently stop minting (src/LoomCollection.sol:220). Every mint and reserveMint sends the creator's share of ETH during the mint itself and reverts the whole mint if that send fails. The creator address is set once with no way to change it, so a creator that can't accept ETH (for example, a contract with no receive) makes every mint revert forever, and the owner can't fix it. Free mints are affected too, because the creator's 40% of the platform fee is always sent. The fix that keeps the 40/40/20 split and the exact-payment rule is to credit the creator's share to a balance they withdraw later.
2. Low: an owner can freeze a paused collection forever (src/LoomCollection.sol:135). renounceOwnership() comes along from the OpenZeppelin ownership contract, and the brief never asks for it. If the owner calls pause() and then renounces, nobody can ever call unpause() again, so public minting is blocked permanently and the unused 1% owner allowance is lost. The minimal fix is to make renounce revert, or refuse it while paused.

Checked and holding

• Clone setup: the implementation is locked, each clone initializes once, and the factory creates and initializes a clone in the same transaction with the caller as owner.
• Owner functions: every owner-only function checks its modifier. Two-step ownership transfer works as intended. The 1% owner allowance, the "provenance hash only before any mint" rule and the reveal seed and metadata freeze all hold.
• Factory: only the fixed pauser can pause or unpause it, and pausing affects only collection creation. The creation fee goes in full to the fixed platform address.
• Re-entry: total supply is raised before any receiver callback runs, and both mint functions are guarded against re-entry.
• launch.json: the constructor arguments match the brief: LoomCollection($owner,$owner) and LoomFactory($contract:LoomCollection,$owner,$owner). No role is given to msg.sender or tx.origin.

Static-analysis leads I dropped

• ETH "sent to arbitrary user": this flags the fixed recipients (creator, platform and reserve), so it isn't a defect. What it does point to is the push-payment problem in finding 1.
• Factory reentrancy: the only external call is the fee transfer to the fixed platform address, made last and under the re-entry guard.

The review is complete. The findings file is written and validated, the cited snippets match the tree, and the working tree shows no tracked changes.

Result: no defects in the math area. The findings file holds two info-level observations and 28 coverage rows, one for each of the 24 listed entry points plus four invariants.

What I checked, with concrete values:

• Fee constants: the 40/40/20 split of 0.0005 ETH is 2e14, 2e14 and 1e14 wei, computed at compile time and summing exactly to the fee. Per-token shares are multiplied by quantity with no division, so batching cannot create dust. A fuzz over uint128 prices and quantities 1 to 255 confirmed creator plus platform plus reserve payouts equal msg.value and the clone keeps 0 wei.
• Price ceiling: initialize rejects mintPriceWei above max minus the fee, so the per-token sum cannot overflow. A quantity of 2 at that ceiling hits the checked multiply and reverts with no state change.
• Caps: supply, lifetime wallet and reserve subtractions cannot underflow because every increment is guarded first, and the increments happen before any ERC-721 receiver callback.
• Royalty: mulDiv with bps at most 1000 returns max/10 at a sale price of 2^256-1, no overflow.
• Factory: create fee is exact and fully forwarded; pagination handles offset at or past the end, limit 0 and limit 101 correctly.
• Launch manifest and exported ABIs match the constructors and compiled artifacts.

Observations recorded as info: the reserve allowance floors to zero for supplies below 100, and reserve mints pay the creator's full price. Both are documented in the README as deliberate interpretations of the brief, so neither is reported as a defect.

The scratch probe lives in test/scratch/MathProbe.t.sol and is not part of the submission. The existing 94-test suite passes.

Review complete. The findings file is written at .imd-findings.json, no repository file was changed, and the working tree is clean apart from that output.

Outcome: no critical, high, or medium defect was substantiated in the Execution Trace, Periphery, or First Principles areas. One low finding was recorded, and all 24 entry points plus five invariants have coverage rows.

What I checked

• Execution flow of every value-moving path. In createCollection, the exact create fee, implementation checks, clone creation, atomic initialize with the caller as owner, registry write and event all precede the only untrusted call, and the reentrancy guard holds. In mint and reserveMint, payment, supply cap, wallet or reserve cap and totalSupply are settled before any ERC-721 receiver hook, so a receiver cannot re-enter, set provenance mid-mint, or reset its allowance by forwarding tokens. The 0.0002/0.0002/0.0001 ETH shares sum exactly to the 0.0005 ETH fee, so batching cannot leak dust. A rejecting recipient reverts the whole batch and leaves no debt.
• Periphery. I downloaded the pinned OpenZeppelin v5.0.2, OpenZeppelin-upgradeable v5.0.2 and forge-std v1.9.7 archives. The SHA-256 digests match dependencies.json. Every file in the production import closure is token-identical to upstream. The only differences anywhere in lib/ are forge-fmt line wrapping and hex-literal formatting, plus omitted upstream mocks. The ABI exports match the build artifacts and forge fmt --check passes.
• First principles and boundaries. Supply of 1, wallet cap equal to supply, collections under 100 tokens with a zero reserve allowance, max-price overflow, zero provenance and zero seed, uninitialized bare clones, coincident fee recipients, and ownership handover or renunciation during pause all behave as documented.
• Manifest. launch.json uses only schema keys, the constructor argument lists match declaration order, and platform, reserve and pauser all resolve to the named owner as the workflow requires.
• Static analysis leads. The arbitrary-send and reentrancy lines are not exploitable: recipients are fixed at construction or initialization, and the post-call state writes in the factory follow a call into freshly created trusted code.

The one finding (low): reserveMint reuses the public payment formula, so an owner pays the creator the full mint price for tokens in the owner's own 1% reserve allowance. The workflow only defines the payment rule for the public path, and the builder documented this reading deliberately. Under the conventional meaning of a reserve the owner would pay only the platform fee. This is a requirements decision for the requester to confirm, with the concrete call sequence and amounts in the report.

Not verified locally: the service-side OwnerChecks helper is not in the tree. The implementation contract reports a zero owner and the factory exposes no owner function, which is the expected shape for that check.

The review is complete. The findings file is valid JSON, both snippets match the tree at the cited lines, and the working tree is clean apart from the gitignored findings file and scratch test.

Outcome: no critical, high or medium defects in the economic area. The fee math, conservation, caps, reentrancy ordering, clone isolation, constructor behavior on an empty chain, runtime opcodes, ABI exports and the manifest's constructor wiring all hold. The full suite of 94 tests passes.

Findings written to .imd-findings.json:

• Low: no setup window after creation. The factory initializes a clone and its public mint is live in the same transaction. Since setProvenanceHash requires zero supply, anyone who back-runs the creation with a single mint (0.0005 ETH on the default free mint) denies the provenance commit for the life of the collection, and a sellout before the owner's first reserve mint removes the 1% allowance. No funds are lost. The README acknowledges the window, but an EOA owner using the approved site form cannot avoid it. The suggested fix is a scope decision for the requester, since starting clones paused or taking the hash at creation changes the "mintable immediately" behavior.
• Info: reserve mint pays the creator price. reserveMint charges the owner the full mint price plus fee and forwards the price to the creator. The workflow leaves this unspecified, the builder documented the interpretation, and no third party loses anything. Reported so the requester confirms the intended reserve economics.

Both were reproduced with a scratch Foundry test under test/scratch, which executes the exact sequences described.

Coverage: all 24 entry points have rows, plus rows for the ETH-conservation invariant, the cap invariants, the manifest and the launch floor. The one item I could not verify is the pool's fee, tick spacing and initial price, because the "This launch" section they must match was not among the supplied reads.

The review is complete and written to .imd-findings.json. The working tree has no tracked changes, and the scratch test lives under the gitignored test/scratch/ directory.

Outcome: four low-severity findings, no critical, high or medium. The code deploys under the factory's CREATE2 model, the manifest is schema-valid with constructor arguments matching the workflow, the ABI exports match the build, and all 94 existing tests pass. Each kept finding was reproduced with a scratch Foundry test I ran against this tree.

Findings kept, after merging duplicates:

1. Post-creation griefing window. Clones start unpaused, so anyone who back-runs creation with a dust mint permanently blocks setProvenanceHash and can also sell out supply before the owner's reserve allowance. Documented in the README, but an EOA owner using the site form cannot avoid it.
2. Push-paid creator can halt minting forever. A creator address that rejects ETH makes every public and reserve mint revert, and the creator has no setter.
3. Inherited renounceOwnership while paused freezes minting permanently with no recovery.
4. Reserve mints pay the full creator price. Three specialists reported this same root cause; it is merged into one finding and flagged as a spec reading the requester should confirm, since it changes the frontend payment formula and ETH flows when owner and creator differ.

Dropped: the reserve floor below maxSupply 100 report. It reproduces but is the only integer reading of "1%" that never exceeds the cap, and the README states it, so it is not a defect. The static analysis leads did not hold: the ETH recipients are fixed at initialization, and the flagged reentrancy paths sit behind reentrancy guards with state settled before external calls.

Coverage: all 24 entry points answered, 20 holds and 4 finding, plus five invariant rows covering ETH conservation, deployability, manifest shape, ABI exports and the test suite. The one entry point no specialist answered, LoomCollection.unpause(), holds.

Implemented the Loom frontend and static export.

• Build/typecheck, 32 mocked browser checks, 16 design checks, and ABI/asset verification passed.
• Export: 878 KB; checked Git bundle: 1.70 MB.
• Trading correctly disables when the live pool has no active liquidity. No transactions were broadcast.

Validation evidence and design documentation are included. Design documentation respects the allowed docs/ scope. Files are ready for submission; root Git metadata is read-only, so no in-place commit was created.

Saved both findings with exact source citations and reproductions in .imd-findings.json. Revision is needed before shipping.

• High — bug: reloading a connected wallet blanks the entire site. At 390 × 844, connecting and then reloading produced an empty page on all five routes in both browsers: 10/10 failures. Wallet.tsx:31 calls getProvider on an unresolved persisted connector. Wait for completed reconnection and handle provider errors without unmounting the app.
• Medium — bug: “Check confirmation” submits the paid form again. After a confirmation timeout, clicking this control generated two transaction requests instead of one, for both creation and minting in Chromium and WebKit. Set type="button" at transactions.tsx:73; changing that attribute alone prevented duplication in all four control runs.

“Met” below means implemented; the two lifecycle defects above remain outstanding.

Loom is a Sepolia NFT launchpad whose woven artwork carries a consis

Both findings were reproduced and fixed:

• Wallet reloads preserve the app and reconnect safely.
• “Check confirmation” no longer resubmits paid forms.

Rebuilt the export and manifest. Build/typecheck, 8 unit tests, 46 browser checks, and 16 design checks pass. Responses are recorded in .imd-responses.json.

Bundle: 2.64 MB, below 8 MiB. No live transactions broadcast.

Both prior findings are confirmed fixed:

• Wallet reload crash: At 390 × 844 in Chromium 156 and WebKit 27.2, all five routes reconnect after reloading with persisted authorization. All ten cases retain four root children, visible content and zero page errors or transaction requests. The connection guard and error handling in web/src/Wallet.tsx:29 hold.
• Receipt check resubmission: After the simulated 121-second timeout, checking confirmation sends no additional transaction in either browser. Creation retains one 0.002 ETH request; minting retains one 0.0015 ETH request and one minted token. web/src/transactions.tsx:73 correctly uses type="button".

The frontend requirements are accounted for below; deployed Solidity behavior remains the already accepted prior-stage scope.

Loom is an NFT collection studio carried by a woven-line motif, paper background and restrained green palette.

Both browsers also report zero accessibility violations. Live reads confirmed all three deployed contracts; the