The review is complete and the findings file is written. The working tree is unchanged apart from the gitignored findings file and scratch proofs.

Outcome. Both owner-trust gaps the requester named reproduce on the tree at 3cf22eb, and I found no further defect in the two application contracts. The findings file holds two medium findings with Foundry proofs and one informational note for the adapter.

Findings written to .imd-findings.json

• Medium, OGClubBox createSeason at line 152. The only timing check is opensAt < closesAt, so the owner can create a 1-wei season that opens at once with a capped piece at weight 2^128-1, buy one box and reveal it three blocks later. That mints any piece, including a previously capped one, with zero notice while the furniture's 7-day minter delay is supposed to announce new minting authority. The proof deploys the box with a fifth constructor word so it compiles before and after the fix. It fails now with the owner holding the capped piece and passes with a seasonNotice check.
• Medium, OGClubFurniture grantMinter at line 51. The immediate path keys on delivered supply, so with sales started and every roll undelivered, a second grant or a re-grant of the revoked box takes effect instantly. The proof has two tests, both failing now and both passing once only the first grant ever is immediate.
• Info, launch.json line 19. The OGClubBox entry has four constructor arguments and notes that describe the immediate-grant rule. Both go stale once the fifth argument exists, and the manifest rule of one entry per parameter would then refuse the file. Notes are within the length limit.

Verification. I confirmed the proofs pass after the fix by applying a minimal candidate change in a throwaway copy outside the repository. The descriptions list every call site that must take the new argument, which I checked against the tree.

The task text cites 122 passing tests. The tree runs 111. That is a count difference only.

Coverage. I read OGClubBox, OGClubFurniture, BlockHeader, MockOG, the deploy script, launch.json, the README owner and deployment sections, the shared test base and the season and minter tests, and the two protected tests. Every state-changing entry point was traced for access, value flow and reentrancy. Nothing was unreachable. The protected factory harness needs verifier inputs and was not executed. The pause, metadata freeze and unrestricted minter interface are documented trust assumptions the brief asks to keep, not findings. Seasons.t.sol has one coverage gap worth closing with the fix: it never creates a season that opens at or before the current time as an adversarial case.

Done. Both owner-trust gaps are closed, every check passes, and nothing was deployed.

What changed in the contracts

• src/OGClubBox.sol takes a fifth constructor argument, the season notice, stored as a public immutable and capped at a new 30-day constant. Creating a season now reverts with a dedicated error unless it opens at or after the current time plus the notice. Season immutability, close and cancel are untouched.
• src/OGClubFurniture.sol gains a public bootstrapped flag. The first successful minter grant is immediate and sets it; every later grant is a 7-day proposal regardless of supply, including re-granting a revoked box. A reverted grant does not spend the bootstrap.

Verification

Tests and supporting files

• New test/SeasonNotice.t.sol covers the exact notice boundary, a fuzzed boundary at arbitrary creation times, the audit's rigged-season scenario, and unchanged close and cancel behaviour.
• Furniture and delivery-edge tests now assert that only the first grant is immediate, that a second grant and a re-grant of the revoked box wait 7 days while nothing has been delivered, and that opens during that wait store their rolls and deliver afterwards. Two tests that encoded the old supply-based rule were replaced.
• The deploy script reads a new SEASON_NOTICE variable. The manifest passes a fifth argument of 0 for Sepolia and its notes describe the new rules. The README documents both rules in the owner powers section and tells the operator to grant the box first and to create each season at least one notice period before it opens.
• ADAPTATION.md lists every change with its reason and notes that the base tree passed 111 tests locally rather than the 122 the brief mentions.

One behavioural detail worth knowing: with a notice of 0, a season can still open in the block it is created, but a backdated opening time is now refused. That follows from the literal rule and is documented in the README.

I found no defect in either fix. The only item I'm reporting is informational. Findings are in .imd-findings.json. It has one finding and 29 coverage rows: one for each of the 26 entry points, plus three for invariants and the header library. No other file was changed.

forge build, forge test (123 passed, 0 failed) and forge fmt --check all pass on the current tree.

Season notice (OGClubBox). This holds. createSeason rejects any opensAt earlier than block.timestamp + seasonNotice and accepts it exactly at that time (src/OGClubBox.sol:168-169). The notice is a constructor argument capped at 30 days and can't be changed later. I found no other way for the owner to buy from a new season before its notice ends. Pause and close stop the owner from buying too, cancel only works before opening, and changing the vault never touches the odds.

One instant minter grant (OGClubFurniture). This holds. bootstrapped is only ever set to true, and nothing clears it, including an ownership transfer. After the first grant, a new minter can only come from a proposal that has waited its 7 days. A grant rejected for the zero address does not use up the instant grant. revokeMinter also deletes any pending proposal, so a revoked box can't be switched back on from an old one.

Finding (info), src/OGClubFurniture.sol:68. A matured proposal never expires. If the owner proposes a helper minter and nobody activates it, anyone can still call activateMinter a year later. The helper can then mint in that same block, with no new announcement in between. This meets the written rule, since the notice was public and pendingMinters stays readable. It does weaken the "public notice before new permissions" purpose the README describes. Adding an activation window would change the agreed rule, so that is your call. The smaller alternative is to document that a matured proposal stays live until cancelled.

Rest of the area.

• Delivery during a re-grant delay: opens store their rolls and deliver succeeds after activation.
• Header library: BlockHeader.decode only reads a header that already matched the block hash, and its length checks hold.
• Deploy script and launch.json: both pass the new fifth argument ("0" in the manifest), and the manifest's keys and notes are valid.
• Static-analysis leads: I checked the slither and aderyn items and none is a real defect. The "uninitialized" variables are meant to start at zero. Each strict-equality check either compares against a value that can't occur or compares identifiers. The reentrancy reports involve the fixed token and furniture contracts behind nonReentrant.

No test proof is attached, because proofs were only required for critical or high findings.

The findings file is validated, the scratch test is removed, and the tree is clean apart from the review output. The review is complete.

Result: both owner-trust gaps are closed correctly, with one low-severity trust-assumption gap recorded.

I checked the delivered code against the Access Control, Trust Gap and Asymmetry guides, traced every listed entry point, and confirmed the toolchain state:

• forge build succeeds (lint warnings only), all 123 tests pass, forge fmt --check exits 0.
• Season notice (createSeason) enforces opensAt >= block.timestamp + seasonNotice with an exact boundary. The notice is immutable, capped at 30 days in the constructor, and no other code path writes seasons, so there is no bypass. closeSeason and cancelSeason are unchanged.
• One-shot minter bootstrap (grantMinter) takes the immediate branch only while bootstrapped is false and flips it in the same call. Rejected calls do not spend it. Every later grant, including re-granting the revoked box at zero supply, only writes a 7-day proposal. activateMinter is reachable solely through that proposal path.
• The deploy script, every test fixture and launch.json pass the fifth constructor argument. The manifest has only the schema keys, string arguments, unique short names, and notes under 4,000 characters.
• The README documents both rules and the two post-deploy steps.

The one finding (low): the season notice is transparency only. The owner can announce a rigged season honestly, pause purchases before it opens, then unpause, buy, and re-pause in a single transaction, so nobody else can ever buy. With the vault set to the owner the purchase costs nothing net. This is within the requested design and the owner's intended powers, so I classified it as an undocumented trust assumption rather than a defect of the two requirements. The suggested fix is a README sentence in the owner-powers section. A hard guarantee would be a scope decision for the requester. I verified the sequence with a scratch Foundry test before reporting it.

.imd-findings.json holds this finding plus a 30-row coverage record: all 26 listed entry points marked holds except setPaused, which references the finding, and four extra rows for the manifest, deploy script, README and the forge checks.

The review is complete and written to .imd-findings.json. No files in the tree were changed, and the scratch test directory was removed.

Outcome: no defects of medium severity or above in the economics, invariant and flow-gap area. The two owner-trust gaps are closed as specified. Build, all 123 tests and the formatting check pass on this tree.

What I verified

• The season notice is enforced in createSeason against the immutable, 30-day-capped value, with the boundary exact and the only writer of season terms. Close and cancel are unchanged.
• The furniture's first successful grant is the only immediate one, the flag never clears, and every later grant including a re-grant of the revoked box waits seven days regardless of supply. Purchases made before a revoke still open and store their rolls, and delivery resumes after activation.
• Cap accounting holds on every pick path: ordinary, guaranteed tenth box, its re-roll, and fallback. The box never holds payment tokens and only ever pulls from the buyer, so the owner cannot spend buyer allowances.
• The deploy script, every test constructor and launch.json pass the fifth argument. The manifest has only the schema keys, arguments in declaration order, and notes under the length limit.

Two info-level notes recorded, each with a reproduction I confirmed in a scratch test:

• Ten-pack guarantee becomes a certainty. Once all rare-tier entries but one have sold out, the next ten-pack's tenth box is that remaining piece every time, not at its published weight. Documented behaviour, but the README's "may have a higher or lower tier" understates it.
• Notice is not access. The owner can keep buying paused through the notice and buy alone in one atomic unpause, buy, pause. This is equivalent to the seven-day minter delay's power, so it stays within the trust model, but the owner-powers wording slightly overstates what the notice guarantees.

Coverage has 33 rows: every listed entry point plus the invariants, the manifest and the toolchain checks. One row is unreached: the real mainnet payment token is not in the tree, so a fee or reflection token making every buy revert could not be ruled out beyond the README's existing requirement for an ordinary ERC-20.

The review is complete and the findings file is written.

Outcome: no math, boundary or numerical-gap defect survived verification. The one entry in .imd-findings.json is an info-level note, and the coverage record answers all 26 entry points plus four invariant rows.

What I checked, in the three assigned guides' terms

• Math precision: the price times count guard, the burn split through mulDiv, and the vault remainder. Rounding sends at most 1 wei of burn to the vault per purchase. A probe with price 1 and 99.99% burn confirmed burn 0 and vault 1, which is dust with no compounding.
• Boundaries: sale window inclusive at opensAt and exclusive at closesAt, cancel allowed only strictly before opening, reveal window live at a 256-block gap and expired at 257 which matches blockhash availability, summed weights allowed to reach exactly 2 to the 128, and the 30-day notice cap. All probed and holding.
• Numerical gap (gas reserve seam): at the lowest gas at which open succeeds, a receiver that burns the entire mint budget still leaves enough reserve to store ten distinct rolled IDs. I measured this for both a live ten-pack and an expired ten-pack. The 63/64 rule still forwards the full one million gas at that threshold.
• RLP header parsing: canonical-length checks, the number and mixHash field constraints, and the whole-input list requirement all hold. The suite already has real mainnet fixtures and malformed-input fuzzing.
• Furniture: the bootstrap flag is set only after the zero-address check, a second grant waits seven days at zero supply, revoke clears any pending proposal, and activation is inclusive at the deadline.

The info note: with a zero notice, createSeason now rejects an opensAt in the past, which the code at the base commit accepted. That is what the brief's explicit rule requires and the README documents it, but it is a behaviour change relative to the "behaves as today" clause, so I recorded it for the judge rather than treating it as a defect.

Verification state: forge build, the full suite of 123 tests, and forge fmt --check all pass on the unchanged tree. My scratch probes were removed, so the only file I left behind is the findings JSON.

The review is complete and .imd-findings.json is written with four findings and a full coverage record. The working tree is clean.

Outcome: the revision holds. Both owner-trust gaps are closed as the brief specifies, and I found no defect that reopens the work.

• Rule 1 (season notice) is correct. The fifth constructor argument is immutable, capped at 30 days, exposed as a view, and createSeason enforces the lower bound after the existing parameter checks. Boundary, fuzz, close and cancel tests pass.
• Rule 2 (one bootstrap grant) is correct. The flag is set only in the immediate branch and never cleared, a reverted grant does not spend it, and a re-grant of the revoked box waits seven days while opens store their rolls.
• Tests, script, manifest, README all pass the new argument. The manifest has only the three schema keys, five string arguments for the box in declaration order, and notes under the limit. Build, 136 tests and fmt check all pass. Runtime size is well under the limit and constructors make no external calls.

Findings kept, all at info severity. Each was reproduced against the tree and none is a defect in the requested behavior:

1. Pause can make an announced season owner-only. Merged the audit_permissions and audit_economics reports into one. The owner can hold the pause through the notice and atomically unpause, buy and re-pause at opening, paying itself when it is the vault. Reproduced with a scratch test. This is within the owner powers the brief asks for, so it is a trust assumption for the README, not a bypass.
2. Notice 0 refuses a backdated opensAt that the old code accepted. The brief's literal rule wins and the README documents it. Kept as a tooling note.
3. A matured minter proposal never expires. Pre-existing and unchanged by this task.
4. Ten-pack guarantee turns the last remaining rare into a certainty. Reproduced, with one correction to the specialist's claim: the certainty is at pack level. One of eight previewed packs took the rare in an earlier box and the tenth fell to the fallback. This is the documented guarantee working as designed.

The scratch test used for reproduction was deleted after the run. No files other than the findings file were created.