The review is complete. The findings file is written, validated against the tree, and every reproduction runs green under test/scratch/ReviewRepro.t.sol.

Outcome: no loss-of-funds, reentrancy, access-control or accounting defect in the five applications. The build, 246 unit and fuzz tests, 12 invariant tests, forge fmt and the Python manifest tests all pass as delivered. Seven entries are recorded in .imd-findings.json.

Findings

• Medium, manifest. launch.json is still the Sepolia recipe. It deploys MockOG and MockSwarmPepe, both public-mint, as the payment token and Pepe collection, and passes a zero raffle notice. On mainnet anyone would mint clubs for free. The Python test asserts that argument list verbatim, so it must change with the manifest.
• Low, FIX 1. The OGClubClubs constructor accepts a vault equal to the Pepe collection or the delegate registry. Half of every payment would be stranded. Reproduced by deploying with those addresses.
• Low, FIX 2. setFootprint only refuses placed ids, so an owner edit that lands before a holder's pending transfer changes its meaning. Reproduced: a floor placement at (3,0) rotation 1 becomes a permanent side-1 wall piece, and a size edit makes a valid 2x2 placement revert. The existing test at test/ClubsReview.t.sol:458 asserts the current behaviour and needs updating.
• Low. OGClubStaking lacks a vault-equals-token sentinel. A swapped argument sends every unstake fee to the token contract.
• Info. Owner trust assumptions across all five contracts, the acknowledged one-bit prevrandao bias with the 256-block re-roll window, and a coverage statement.

Coverage. All five applications, both libraries, both mocks, both scripts, the manifest and the test sites were read in full. Over a public RPC, the mainnet OG token resolved to a Sourcify full match: fixed supply, 18 decimals, no fees, no owner, compatible with the exact-debit payment checks and staking. Swarm Pepes and the delegate registry have code and answer ERC-721 probes, but their source was not read. OpenZeppelin internals were trusted beyond the inherited interfaces.

Next for the adapter: apply FIX 1 and FIX 2 with the batch setter, rewrite launch.json and test/test_launch.py for the five mainnet applications, and document the Safe handoff and setFootprints calldata in the README.

Implemented both fixes, the reproduced staking constructor guard, and the five-application mainnet manifest. Added exact setup calldata, Safe handoff documentation, and ADAPTATION.md.

Validation passed: forge build, all 273 Solidity tests with the supplied seed, 10 Python tests, formatting, and the five-contract constructor rehearsal.

Live deployment and Etherscan verification remain launch-service steps. No transactions were broadcast; confirmed deployed addresses are not yet available.

The mainnet launch.json is complete and verified. No file changes were needed: the working tree at the pinned commit already carries the correct manifest, and the tree is clean.

What the manifest contains

• Five applications in constructor dependency order: OGClubFurniture, OGClubFarmVault, OGClubStaking, OGClubRaffle, OGClubClubs.
• Argument counts match each constructor's parameter list and declaration order, including the eleven-argument clubs constructor.
• Owner and royalty receiver on every contract are $owner. No msg.sender or factory ownership anywhere.
• Mainnet inputs are the existing OG token, Swarm Pepes and delegate.xyz v2 registry addresses from the brief. No MockOG or MockSwarmPepe is listed.
• Prices, points per token day and the raffle notice are the exact values from the brief.
• Only the keys kind, contracts and notes are present. The notes run to about 3,100 characters and document the four owner handoff steps in order, the footprint catalogue, and the Ownable2Step transfer to a Safe for all five contracts.

Verification run on this machine

• forge build succeeded.
• forge test with the verifier's fuzz seed: 273 tests across 42 suites passed, 0 failed.
• forge fmt --check passed.
• A scratch rehearsal deployed all five contracts on an empty chain with chain id 1 using the manifest's exact arguments, confirmed owner, vault, pepes, delegates and price on each, and confirmed the clubs runtime fits the size limit. The scratch test was removed afterward.
• The protected harness itself could not be run locally because it needs verifier-supplied environment values and a floor directory not in this tree. The scratch rehearsal covers the same constructor path.

Not done here, by design

Etherscan verification and the five deployed addresses come from the launch service after deployment. The manifest step writes only launch.json and claims no live deployment.

The review is complete. The findings file at .imd-findings.json holds an empty findings list and a 64-row coverage record (all 59 listed entry points plus five invariants). The untracked files git shows are the sandbox's device-node placeholders, not files I created.

Result: no reproducible defect in the economics area. Every entry point was traced against the Economic Security, Invariant and Flow Gap guides, and the value flows behave as specified.

What I verified, beyond reading the code:

• Live dependencies on chain 1. The OG token at the manifest address is a plain fixed-balance ERC-20 (verified source via Sourcify, decimals 18, supply 1e9). It has no fee, blacklist, hook or rebasing, so the exact-receipt checks in the club payment path and the staking and vault balance deltas cannot be tripped by the token. Swarm Pepes answers ownerOf, and the delegate registry has code.
• Owner handoff calldata. The README and deploy script bytes decode to exactly the brief's 24-entry catalogue (id 23 is the only wall piece), the two base URIs and the right selectors. This matters because FIX 2 makes a wrong catalogue irreversible.
• Conservation invariants. Club payments move floor(p/2) to the dead address and the rest to the vault with before/after receipts; staking balance equals total staked and points change only by time-weighted accrual or spends; the vault's balance always covers its reservations; points spent equal tickets times price, and prizes mint exactly once per consumed win bit. All 13 invariant suites and the 259 unit tests pass locally.
• Flow seams. Placement into clubs cannot strand furniture (mint-into-clubs and multi-element batches revert), floor masks and wall lengths are supersets across levels so upgrades never invalidate pieces, raffle entries roll back fully on a failed spend, and claims stay retryable after receiver failures.

Trust assumptions, not defects, already documented in the README: the withhold-until-expiry re-commit bias of the future-block randomness, validator influence on prevRandao, a spender's power over any account's points, the irreversible one-step renounce, and the immediate first grant consuming each contract's bootstrap.

Not reached: statistical uniformity of the Feistel permutation and a quantified proposer-lookahead bias. Both are noted as accepted limitations in the README.

Review complete. The findings file is written and validated, with no substantiated defects in the assigned area and a coverage row for every one of the 58 listed entry points plus five invariant rows.

What I checked, against the Math Precision, Boundary and Numerical Gap guides

• Staking accrual arithmetic. The denominator for 18 decimals is 8.64e22, which fits the 80-bit remainder slot. The two-slot accrual (mulDiv plus mulmod carry) is exact: a 1-wei stake earns exactly one point-wei after 86400 seconds, confirmed with a probe test. The unstake fee rounds up toward the vault, and the amount > fee guard prevents underflow. Intermediates cannot overflow with bounded time and rate.
• Club payments and geometry. All four prices are even, so the burn and vault legs are equal. The placement mask's highest bit is 255, so no shift escapes the bitmap. I probed the level-1 floor, the level-3 L-shaped notch, level-4 corners, the door tiles, the side-1 door position, wall lengths per level, rotation swap, uint8-max coordinates and rotation values 4 and 255 with concrete inputs, and every case reverted with the specified error or succeeded as intended.
• Raffle counting. Ticket, prize and wallet-cap values are bounded to 2^48 - 1 before every uint48 narrowing. The prize binary search stays in range because line ends are strictly increasing. The Feistel permutation is a bijection for every size from 1 to 70 by exhaustive probe, on top of the existing fuzz. The commit and draw windows meet at target + 256 without overlap.
• Vault budget. Reserved can never exceed the balance because claims reduce both by the same amount and nothing else moves tokens out. Claim, cancel and release windows are disjoint at their boundaries.
• Live mainnet dependencies. On a mainnet fork I confirmed the OG token has 18 decimals, is a minimal ERC-20 whose transfers to the dead address credit its balance (its totalBurned is only a counter), and that a full mint, upgrade, stake and unstake cycle succeeds against the real token, Swarm Pepes and delegate registry.
• Handoff calldata. The README's URI, sale-open and 3,332-byte setFootprints calldata match cast's encoding of the catalogue byte for byte, and the launch.json numerics match the brief.

Not reached. Nothing in my area was left unexamined. Access control, economics and ownership semantics outside the numeric lens were only read, not traced, and are recorded as holding only where no arithmetic touches them.

The scratch probe and fork test live under test/scratch/ and are not part of the submission.

Review complete. The findings file holds an empty findings list and a full coverage record of 63 rows (all 59 listed entry points plus four invariants). The scratch tests are removed and the working tree is clean.

Result: no reproducible defect in my area (Execution Trace, Periphery, First Principles). Everything I traced behaves as the brief specifies, including both requested fixes.

What I verified, beyond reading

• Built the project and ran every suite locally: 259 unit and fuzz tests plus 14 invariant tests pass, forge fmt --check is clean, and the 10 Python manifest tests pass.
• Fork-tested the five contracts against the live mainnet dependencies. The real OG token is a 2.2 KB plain ERC-20 with 18 decimals and no pause, blacklist or proxy, so the 50/50 burn and vault split and the receipt checks succeed. A real Swarm Pepe holder minted and upgraded a club, a delegate registered through the real delegate.xyz v2 registry minted on the holder's behalf, and staking accrued and exited correctly.
• Probed the edges I traced by hand: mixed-wallet claimTo reverts, a single-win redirect into the Clubs contract reverts without consuming the win, multi-id furniture batches into Clubs are refused while a single-id batch follows the placement rules, and 1 wei stakes accrue and exit as designed.
• Confirmed Fix 1 (vault equal to Pepes or registry is rejected) and Fix 2 (footprints final once set, atomic batch setter) are implemented and tested, and that the manifest lists exactly the five applications with static mainnet addresses, $owner, no mocks, and notes under the 4,000 character limit.

Periphery checked: the RLP header parser only accepts canonical encodings (my hand-built non-canonical header was rejected), and the keyed Feistel permutation is a bijection onto the ticket and prize ranges.

Not reached: statistical uniformity of the permutation and header parsing under a future header format are covered only by the existing fixture and fuzz tests, not by independent proofs. The one-bit proposer bias on the draw seed and the permissionless prize push to rejecting receivers are documented design limits, not defects, so I did not report them.

The review is complete and the tree is clean apart from the findings file.

Outcome: no reproducible defects in the Access Control, Trust Gap or Asymmetry area. .imd-findings.json holds an empty findings list and 63 coverage rows, one for each of the 59 listed entry points plus four invariants, every row marked holds with a reason.

What I verified

• Permission map. Every owner-only setter on all five contracts is guarded, no storage variable has a weaker second writer, and no constructor uses msg.sender or tx.origin for ownership. The only permissionless writers of role state are the two activate functions, which need an owner-made proposal inside its 7 to 14 day window. There is no path to a minter or spender role that skips the bootstrap-or-delay rule.
• Asymmetry pairs. grant/activate/cancel/revoke mirror exactly between Furniture and Staking. setFootprint and setFootprints share one private setter, so the batch has identical per-item rules and is all-or-nothing. claim and claimTo share one consume path, and claimTo checks msg.sender against every wallet group. Vault claim and releaseSeason use complementary boundary checks at opensAt plus 90 days. commitDraw retargeting is only possible once draw is already impossible, so the two never overlap.
• Trust gaps. The raffle, as privileged minter and spender, only spends msg.sender's points and only mints owner-defined prize ids to the entry wallet or the wallet's own redirect. Approved club operators and furniture operators gain only powers weaker than the transfer right they already hold, matching the README.
• Fix 1 and Fix 2. Both constructor sentinels are present and tested. Footprints are final once set, and the legacy locked flag and footprintOf ABI are unchanged.
• Deliverable consistency. launch.json has only the schema keys, five unique names, correct argument counts and the brief's mainnet addresses, with notes at 3,109 characters. The README selectors and the 3,332 byte footprint calldata decode to the exact 24-entry catalogue.
• Verify list. forge build, all 273 Foundry tests, forge fmt --check, the ten Python tests under unittest, and the offline five-contract rehearsal all pass. On a mainnet fork, OG transfers debit and credit exactly with 18 decimals, Swarm Pepe reports ERC-721, and the delegate registry has code.

Not covered. pytest is not installed, so the Python suites ran through unittest instead. Etherscan source verification and reporting deployed addresses need a live deployment that does not exist yet. Economic and randomness analysis beyond the permission lens was left to the other specialists.

Added fuzz and invariant tests under test/ covering batch atomicity, immutable footprints, queued placements, ownership handoffs, and furniture custody.

Validation passed:

• 279 Foundry tests with the required seed
• 10 Python tests
• forge build and forge fmt --check
• Five-contract constructor rehearsal

No implementation or configuration files changed. Validation was local; no mainnet deployment was performed.

I found no defects I could reproduce. .imd-findings.json holds {"findings":[]} and a coverage record with 60 rows: all 58 listed entry points marked holds, each with a one-line reason, plus two invariant rows. I changed no tracked files. The Python tests left __pycache__ folders behind and I deleted them; git status is clean.

What I ran

• Build and tests: forge build passes, and forge test passes 279 of 279 tests across 44 suites. forge fmt --check passes, and the 10 Python manifest tests pass (run with unittest, since pytest isn't installed).
• Rehearsal: forge script script/DeployMainnet.s.sol:DeployMainnet --chain-id 1 deploys all five contracts locally using only constructors and prints the handoff. The constructors make no calls to other contracts, so they would also run on an empty chain.
• Calldata: I re-encoded the README's calls with cast and compared them byte for byte. Both setBaseURI calls, setSaleOpen(true) and the 3,332-byte setFootprints call all match. The catalogue in script/club-footprints.json and in DeployMainnet.catalogue() matches the brief exactly. The grant selectors 0x261707fa and 0x5a4b6198 are correct.
• Size: OGClubClubs, the largest contract, is 16,089 bytes deployed and 17,844 bytes of creation code, well under both limits.

The two fixes

• Fix 1: At src/OGClubClubs.sol:133-139, the constructor now also rejects vault == pepes, and vault == delegates when delegates is nonzero, with UnexpectedTokenDebit. Tests for both cases are at test/ClubsReview.t.sol:625-628.
• Fix 2: _setFootprint reverts with FootprintLocked whenever the footprint is already set, placed or not. setFootprints is owner-only, rejects mismatched lengths with BadFootprint, applies the same rules to each item, and rolls back the whole batch on any failure. A duplicate id inside one batch reverts too. footprintOf, the FootprintSet event and the placement data format are unchanged. Tests in test/ClubsFootprints.t.sol cover a second set on the same id, pending floor and wall placements keeping their size and kind, and the batch rules.

launch.json

• It has only the keys kind, contracts and notes, and lists five applications with no mocks.
• The arguments follow each constructor's declaration order and use the brief's addresses and values, with $owner for every owner and royalty receiver.
• The notes are 3,109 characters and describe the ordered owner handoff and the later Safe transfer.

Leads I dropped

• Specialists: all four reported no findings, so there was nothing to merge.
• Static analysis: none of the slither or aderyn leads reproduced:
  • "weak PRNG" is ordinary modulo arithmetic.
  • The reentrancy warnings are covered by nonReentrant guards and balance checks after each transfer, against the standard OG token.
  • The flagged local variables start at zero on purpose.
  • The "storage array edited with memory" warning points at a read-only view.
  • The uint48 casts are bounded by MAX_TICKETS.
• Unrequested staking change: the staking constructor now also rejects a vault equal to the token. That goes beyond the two requested fixes. It only refuses an invalid setup and leaves staking behaviour unchanged, and ADAPTATION.md records it as an earlier reproduced finding, so I didn't report it.

Not done here

• Etherscan source verification and the five live mainnet addresses can't be produced by a review; they come from the launch service after deployment. The README says so and gives forge verify-contract commands with the correct constructor arguments for each contract.

A clean review is not proof the code has no defects.