Implemented the immutable collection, protected reserve, lifetime mint limit, live SVG metadata, vendored dependencies, ABI and three state previews. Details are in README.md.

Validation passed: forge build, forge test (76 passed, requested fuzz seed), forge fmt --check, and metadata export checks.

Sepolia deployment, confirmed address, transaction link and explorer verification remain pending the separate IMD launch.

I finished the permissions review of src/SqueekCompanion.sol (Access Control, Trust Gap and Asymmetry guides) and found one low-severity issue; nothing critical, high or medium. The results are in .imd-findings.json. The full suite passes (76 tests), and the working tree is unchanged: my scratch test is deleted and git status is clean.

Finding (low): the one-per-wallet limit is keyed only on the caller's address (src/SqueekCompanion.sol:44), so one person can take the whole public supply.

• Reproduction: I wrote a throwaway contract whose constructor calls mint() and then sends the token to one account. Deploying 300 of these per transaction, three times, left that account holding all 900 public tokens. A fresh wallet's mint() then reverted with PublicSupplyExhausted.
• Cost: about 191k gas per token, so roughly six 30M-gas transactions on Sepolia.
• Fix: checking msg.sender == tx.origin would close it but also lock out smart-contract wallets (Safe, ERC-4337), so this is the requester's call. At minimum the README should say the limit is per address. An allowlist or signature gate are the other options.

What holds:

• Reserve: tokens 1–99 are minted to the fixed owner address in the constructor, which never uses msg.sender, so the deploying factory gets no role. Public mints always get ids 100–999, so they can never reach the reserve, and the 999 cap holds.
• Re-entry on mint: the mint counters are written before the receiver callback, so calling mint() again from that callback with the same address reverts.
• No backdoors: there is no owner role, no privileged function, no proxy, and no delegatecall or selfdestruct.
• Approve, setApprovalForAll and the transfer functions: these are stock OpenZeppelin v5 with no overrides. mint_block stays fixed through transfers, as the brief requires.

Trust assumption, not a defect: SqueekCore is an upgradeable proxy. Its admin could change or break state() and roundPage(), which would change or block tokenURI and currentState. Minting, ownership and transfers don't depend on it.

Coverage: every listed entry point has a coverage row. I also checked the constructor, the no-backdoor rule and the SqueekCore dependency. I did not go deep into the state-derivation logic or the SVG rendering, since those belong to the other reviewers.

Created launch.json listing SqueekCompanion with no constructor arguments, matching the accepted ABI.

Only launch.json changed. Local manifest checks and forge build passed; forge test passed all 76 tests with the required fuzz seed.

I found one low-severity issue and nothing medium or higher. The results are in .imd-findings.json: one finding and coverage rows for all 6 entry points, plus 3 invariants. No repository files were changed. I wrote scratch tests under test/scratch/ to check things and deleted them afterwards.

Finding 1 (low): one person can claim all 900 public tokens. See src/SqueekCompanion.sol:44. The limit is one mint per address. A contract that calls mint() from its constructor has no code yet, so the safe-mint step doesn't check whether it can receive NFTs. It can then hand the token on straight away. A small helper contract can create 150 of these throwaway minters in one transaction, which I measured at 20,554,919 gas, under the 30M block limit. Six transactions leave the attacker holding 900 tokens, and a fresh wallet's mint() then fails with PublicSupplyExhausted. The code does what the brief literally says ("max 1 per wallet"), so this is a limit of the design rather than a broken check. Every fix changes the agreed design, so it's the requester's decision: allow only regular wallets (which also shuts out smart-contract wallets), use an allowlist or signature, or accept and document the limit.

What holds:

• Mint: the 999 cap and the "one claim per wallet, ever" record both hold. Public IDs run from 100 to 999, and all bookkeeping is written before the receiver callback, so the callback can't mint a second time.
• Reserve: IDs 1–99 go to 0x3C78…74a0 at deploy, and nothing public can reach them. There is no owner role or backdoor, and no burn.
• Transfers and approvals: these are standard OpenZeppelin 5.4 code. A transfer never resets the claim record or changes mint_block.
• State derivation: I checked it against the live Sepolia Core in a fork test at block 12025000. currentState() returns SLEEPING (frontier 1973, Squeek block 13095), and tokenURI and mint work. The contract's strict checks on Core's round data are correct against live Core: the returned page ends exactly at the frontier, and its work total matches state(). The 3-round and 12-round windows match the brief.

Not a finding, but worth knowing: Core emitted no events in the roughly 12 hours of history my free Sepolia RPC could reach, and its frontier stayed at round 1973. The NFT dates everything from that frontier, so during a pause in settlement it keeps showing the last settled state. If settlement ever stalls just after a stretch of activity, it would keep showing RUNNING. The brief asks for this frontier-based rule and the README documents the behaviour, so I didn't report it. I couldn't find out how often Core normally settles: the docs site blocked my requests, and the RPC had no older history.

I didn't attach a proof test, since that's only required for critical or high findings. The steps to reproduce are in the finding. The existing suite passes: 76 tests.

I found no defects I could back with a concrete failing input, so .imd-findings.json has an empty findings list and 10 coverage rows. That covers all 6 listed entry points (all holds) plus the constructor, the state derivation against live Core, and two invariants. No repository files were changed; the scratch fork test I wrote was deleted and the working tree is clean.

What I checked, using the Execution Trace, Periphery and First Principles guides:

• The project's own suite: all 77 tests pass.
• mint(): the claim flag, the counter, the token ID (100–999) and the mint block are all written before the _safeMint receiver callback. A re-entrant mint reverts with AlreadyMinted, and a receiver that rejects the token undoes the whole mint. The counter goes up by exactly one per mint and stops at 900, so public mints can never reach the reserved IDs 1–99.
• Constructor: the 99 reserve tokens go to 0x3C78…74a0 via _mint, which makes no external call, so deployment works on an empty chain. That address has no code on Sepolia, so it is an ordinary wallet and can hold the tokens. There is no owner role and no reserve function.
• Transfers and approvals: these use unmodified OpenZeppelin 5.4 ERC-721 code. They never touch the mint flags or mint blocks, so mint_block stays fixed through transfers.
• State derivation against the real SqueekCore: I ran the contract on a Sepolia fork. It returned SLEEPING at frontier 1973 and Squeek block 13095; the last round with work was 1910. tokenURI cost about 475k gas.
  • Live calls confirmed what the contract assumes about roundPage: start and end are the ledger positions at the window edges, the checkpoints hold running totals of work, and certifiedThroughRound equals throughRound.
  • Live Core reverts only when the range ends past the frontier or more than 16 records are requested. The contract does neither.
  • The windows match the brief: work in the last 3 rounds means RUNNING, otherwise work in the last 12 means NAPPING, including when the frontier is below 12 or 3.

Not a finding, but worth knowing: SqueekCore's frontier moves only when its reporter settles rounds. It sat at 1973 for over 20 minutes, more than two 10-minute rounds, and the contract follows the brief in reading it. So if settlement stops, the NFT keeps showing the last settled state instead of drifting to sleep. The README already says this.

What I couldn't reach:

• The public RPC keeps only about 128 blocks of history, so I couldn't replay the contract against past RUNNING or NAPPING moments on chain. Those states rest on the mocked tests plus the live data structure matching the mock.
• The SqueekCore docs and published ABI are behind a Cloudflare challenge, so I checked the interface against live calls rather than the docs.
• I made no proofs, since there were no high or critical findings.

I found no defects in the math area (precision, boundaries and numerical gaps). .imd-findings.json has an empty findings list and 11 coverage rows. All six listed entry points are marked holds, and five more rows cover the invariants I checked. No repository files were changed; my scratch tests in test/scratch/ have been deleted.

What I checked, against the live SqueekCore proxy on Sepolia (public endpoint ethereum-sepolia-rpc.publicnode.com):

• Round windows: the 12-round window starts after max(F-12, 0) and the 3-round running window after max(F-3, 0), where F is the last settled round. Both subtractions are guarded so they can't underflow. The docs say the start round is excluded and rounds are numbered from 1, and the live Core agrees: roundPage(0,12,16) returns round 1. A start equal to the end, as at round 0, is accepted. Only an end past F or more than 16 records reverts, and the contract can't send either.
• The contract's page checks: I ran it on a Sepolia fork and fetched live pages at 28 values of F. These covered F = 1–4 and 11–14 and the edges of the real activity in rounds 1906–1922. Every page met every condition the contract checks, so its revert guards never fire on real data. The classification was right at both window edges.
• The total-work check: the Core's current total work (148,986) equals the page's end value at F = 1973, so that cross-check holds.
• Squeek block height: cumulativeBlockUnits / 1e9 gives 13,095, which matches the Core's own blockHeight. The Core's configured units per block is also 1e9. Rounding down gives completed blocks, as intended.
• Decoding: a deployed copy decodes the live state() and roundPage() results and returns SLEEPING, height 13,095 and frontier 1973. tokenURI costs about 475k gas.
• Supply: reserve IDs are 1–99, public IDs 100–999, and the mint stops at 900 public tokens. There is no burn, so totalSupply() stays exact. The reserve address has no code on Sepolia, so minting the reserve without the receiver check is safe there.
• ERC-721 base: the vendored OpenZeppelin v5.4.0 files match upstream once formatting is ignored. The transfer and approval entry points are not modified.
• Tests and static analysis: the existing suite passes (76/76). The six aderyn notes are style points or intended behaviour, not defects.

Two observations I left out of the findings (the code follows the brief on both and the README documents them):

• The Core's reporter has stopped. Settled rounds end at 1973, but the clock is at round about 2496, roughly 87 hours behind. Every token is frozen on the last settled state. That happens to be SLEEPING, but if the outage had started during activity, all tokens would show RUNNING until the reporter resumes. This also matters for Job 2 and the "show all three states" check: live data currently gives only SLEEPING.
• mint_block uses Ethereum block numbers. It shows the Sepolia block (about 12,025,141) right next to squeek_block (about 13,095). The brief doesn't say which unit to use, and the README states the choice.

What I couldn't check:

• Replays at past blocks, because the public node has pruned that state. Instead I fed past values of F into the live pages, but the total-work check could only be tested at the current F.
• How the Core behaves while paused.
• The Core proxy itself, since it is upgradeable and outside this contract's control.

Added adversarial state, callback, mint-limit, reserve, and authorization tests, plus two invariant campaigns.

forge build and forge test pass: 108 passed, 0 failed, using the required seed.

Only test/ files were added. No confirmed production defects found.

Review complete. The findings file is written at .imd-findings.json with two low findings and ten coverage rows, and the scratch tests are removed.

Outcome: no critical, high or medium defect. The contract does what the brief asks, and I verified it against the live Sepolia SqueekCore, not only the mock.

What I checked

• Build and the full suite pass (108 tests, including the invariant runs).
• The pinned read interface matches the published SqueekCore v3 ABI field for field.
• On a Sepolia fork the derivation ran against the real proxy: frontier 1973, the page checks hold, result SLEEPING at height 13095, and tokenURI renders. A historical window with active rounds confirmed strictly increasing cumulative work, end equal to the last checkpoint, and start equal to the point position, so the InvalidCorePage guards cannot spuriously revert.
• The five ERC-721 entry points are stock OpenZeppelin v5.4.0 with no override. mint commits all effects before the receiver callback, ids 100 to 999 can never reach the reserve, and the 900 cap is enforced.
• The manifest has only the schema keys and an empty argument list matching the parameterless constructor. The constructor makes no external calls, so it deploys on an empty chain.
• All six aderyn lines are intentional or harmless.

Findings kept

1. Low, merged from permissions and economics. The one-per-wallet rule is per address. A contract that mints in its constructor and transfers the token out lets one actor take all 900 public tokens in six transactions. I reproduced it with a scratch test. The check is correct as written, so this is a design limit for the requester to decide on, at minimum by disclosing it in the README.
2. Low, new. Five vendored OpenZeppelin files do not match the checksums recorded in docs/dependencies.json, and VALIDATION.md claims they all matched. I fetched the upstream v5.4.0 files: the recorded hashes are genuine and the vendored copies differ by formatting only, so behaviour is unaffected. The provenance record is still wrong for the delivered tree.

One note, not a finding: the constructor costs about 7.2M gas for the 99 reserve mints. The launch gas ceiling must cover it, which I could not check from here.