The review is complete and the findings file is written. No source file changed; only .imd-findings.json and the scratch tests under test/scratch/ are new.

Outcome: no new reproducible defect in the eight job A contracts. The findings file holds two info entries: one stale-documentation note with a reproduction, and one coverage statement.

What I read. All eight launch contracts in full: Params, GameRegistry, RewardPool, FarmRewards, FarmCore, FarmItems, PackSale, StarterClaim, plus their compiled-in libraries and interfaces. I also read the pinned job B code every L3 call path depends on: Economy, FarmEngine, and the relevant functions of FeeRouter, GridOperator, Civic and Season. Not reached: SwarmDesk, V4Market, EndowmentEscrow, Enhancement, Billboards, the standard market adapters, the oracle attestation code, and the keeper, ui and tools directories.

What I verified on this tree with the unchanged foundry.toml.

• The keccak256 of each of the eight creation codes equals the listed creation hash, so the pins in ModuleCode and SwarmCode match the build.
• Every runtime is under the EIP-170 limit. The largest, FarmCore, is well inside it.
• No DELEGATECALL, CALLCODE, SELFDESTRUCT, proxy or initializer. All constructors are nonpayable, make no external call and take static words, so the empty-chain rehearsal cannot park the launch.
• The Params and GameRegistry constructor words satisfy their own range checks.

What I traced and found sound. The 150% output envelope that settlement enforces holds with a worst case near 1.44, because the lock boost is always already in the committed weight and district plus Festival boosts multiply to at most 1.25 × 1.15. Reserved-token conservation across reserve, recycle, pay, spend, scrap, redistribution and season prizes balances. The two-generation weight commitment and expiry buckets stay consistent across re-commit, expiry and re-entry. The vintage ring only ever evicts slots at least eight days old. Both Merkle trees are safe from second-preimage leaves. ERC-1155 custody is soulbound and every receiver-callback path is guarded. Every accepted item in the v3.18 list and the c0e1b0b6 lines was re-read against the code and none is reported again.

The one recorded observation. PackSale decides Mythic eligibility when a pack is opened, not when it is bought. docs/design.md still says eligibility is fixed at commitment, while report-v34 records open-time as the intended v3.4 fix. A holder below level 10 who captures entropy can read the seed and hold the receipt until level 10 to turn a would-be Common into a Mythic. No funds move, so this is an info-level documentation mismatch for the adapter to correct, not a source change.

Prepared job A with production sources and build configuration unchanged. All eight creation hashes match.

Corrected the Mythic documentation and added four passing regression/launch tests. Exact launch inputs and binder handoff are in ADAPTATION.md.

forge build passed. Seeded forge test: 331 passed, 0 failed, 6 fork tests skipped.

Production addresses and the launch number remain pending IMD’s deployment receipt.

The review is complete and the findings file is in place. Nothing in the source tree was changed.

Outcome: no fund-moving or settlement-locking math defect found in the eight L3 contracts. The file .imd-findings.json holds 2 informational findings and 160 coverage rows.

What I verified in depth (Math Precision, Boundary, Numerical Gap guides)

• Output envelope. The InvalidValue guard in FarmRewards settlement would permanently lock a farm's cursor if productive hash exceeded 150% of committed weight. I bounded every multiplier: allocation hash uses the upper Params bounds and full health, event bonus tops out at 15% (Festival clamp), district boost at 25% (season 1500 bps plus war 1000 bps), and lock boost cancels on both sides. Worst stacking is 1.4375, below 1.5. Overclock cannot change under a committed weight because enhancement requires an unequipped, unlocked item.
• Budget conservation. Allocations sum to at most 1.585 × mining against a 1.59 × mining reservation, redistribution shares are floor-summed, so the final dust recycle never underflows and reserve never reverts (mining is at most 1.5% of available).
• Vintage ring. Any credit older than 7 days matures directly, so a slot collision only ever evicts a vintage at least 8 days old. The pending equals matured plus vintages invariant holds on every path, so the assert in consume cannot fire.
• Division and overflow edges. Every divisor (epoch raw, active farm count, farm daily, target) is provably non-zero where used. PackSale's exponent is clamped to ±10e18 before wadExp. All 45 Params defaults sit inside their bounds.
• Entry-epoch pro-rata, beginMining zero-rounding, block-hash window boundaries, payable branches of PackSale, and the 18-decimal balance-delta checks all behave as intended.

Findings reported (both info)

1. FarmCore.level NatSpec documents age caps of 5 at one day and 7 at three days; the code gives 6 and 9. Concrete: a 1-day-old farm with 1200 XP is level 6 and may place rarity-3 items.
2. StarterClaim.resolve emits an expired flag that is always false, since capture only succeeds with a non-zero hash.

Coverage: all 81 L3 and traced-L4 entry points plus three invariants are marked holds or finding. The 79 L1/L2/L4 entry points outside the math area are honestly marked unreached. Existing LazyAccounting tests were run and pass (9 of 9). No proof test files were needed since no finding is high or critical.

The review is complete and .imd-findings.json is written in the repository root. No source or test files were changed.

Outcome

One finding, severity medium, with a coverage record for all 157 listed entry points.

• Live endowment precondition fails. The runbook requires the escrow at 0x1194…21fb to hold at least 200M tokens before the keeper forwards them to RewardPool. On Robinhood Chain today the escrow holds zero, forwarded() is false, and the exact 200M principal sits in the binder wallet 0x6d51…d007. Until that wallet moves the tokens, EndowmentEscrow.forward and RewardPool.fundEndowment revert, every epoch closes with a zero budget, and all pack sale paths revert because the pool is never endowed. The finding cites the escrow's zero-balance revert and includes the exact read calls that reproduce the state. No source fix exists; the repair is a transfer from the binder wallet to the escrow before forwarding, or a plain transfer to RewardPool. The donate path does not count toward the principal.

What I verified as holding

• The config hash recomputes exactly from the four constructor words, and the eight creation hashes in the brief match this build via the existing job A launch test, which passes.
• All job A contracts were traced against the Execution Trace, Periphery and First Principles guides: the two-generation weight bookkeeping in FarmRewards, the settlement envelope (I confirmed the 1.5x cap cannot be exceeded because event and district multipliers top out at about 1.32x and the active boost never exceeds the committed boost), vintage tax slots, the reserve and recycle conservation across claim, spend, scrap and autoRepair, pack and starter entropy state machines, item custody guards, and the Params defaults against enum order and bounds.
• The escrow's zero-balance revert means a premature forward call cannot consume the one-shot, so there is no permanent trap.

Coverage summary

The unreached rows are job B and L2 internals that job A calls into (Season, GridOperator, Enhancement, FeeRouter market execution) and were not traced in depth within the budget.

Created launch.json with the eight contracts in exact order and the approved constructor arguments.

• All eight creation hashes match.
• forge build passed.
• Seeded forge test: 331 passed, 0 failed, 6 live-chain tests skipped.
• No source or configuration files changed.

New addresses and the launch number remain pending deployment; indices 0–7 and the binder handoff are recorded in the manifest.

The review is complete and the findings file is written. The only change in the tree is .imd-findings.json, which the repo excludes from tracking.

Outcome: no new defect in the assigned area. The permission model of the eight job A contracts holds against the Access Control, Trust Gap and Asymmetry guides, so the findings list is empty.

What I verified:

• Guard map. Every state-changing function in Params, GameRegistry, RewardPool, FarmRewards, FarmCore, FarmItems, PackSale and StarterClaim was classified by caller. No storage variable has a writer with a weaker guard than its intended one.
• Confused-deputy paths. Every L4 call into L3 that names a player passes msg.sender or an opt-in value. Beneficiaries are never caller-chosen.
• Paired surfaces. Wallet and pending charge paths, pack purchase variants, equip and unequip, claim and claimFree, and the pause cooldown were diffed. Differences found are conservative or already accepted.
• Launch inputs. All eight creation-code hashes, the six ModuleCode pins and the game config hash recompute from this build and the stated constructor words. The pin test passes.
• Escrow and bind. The escrow pays the module at role 0 of the Desk-bound registry, which confirms the accepted twin-race reasoning.

Coverage record:

All 157 listed entry points have a row. The unreached rows are job B, L1 and L2 contracts outside this area that none of the L3 guards depend on. Three extra rows record the invariants checked.

Review complete. The findings file is written and validated; the working tree has no source changes.

Outcome

The L3 economics hold up. I found no fund-loss, misdirection or settlement-bricking defect in the eight launched contracts. The file .imd-findings.json holds two findings and a coverage row for every listed entry point.

Findings

• Low, pack price dilution. The pack price basis is net mining divided by the number of farms with any committed weight, not by hash. Splitting the same items across one-item wallets lowers every subsequent pack's price. In a Foundry run the basis fell about tenfold and the price went from roughly 2.9M to 224k tokens after 18 one-item farms joined two real ones. No funds move wrongly; it is a pricing-intent gap under the accepted no-whale-cap rule. Scratch test at test/scratch/Dilution.t.sol reproduces it.
• Info, stale reservation comment. The code reserves 159% of mining while the comment above it still says 116.5%. I verified the 159% is correct and sufficient.

What I verified in depth

• Reserve conservation across every reserve, recycle, pay and credit path, including scrap allowance, season prize, referral and claim tax redistribution.
• The per-farm envelope cannot be exceeded. Event, district and festival boosts combine to at most 1.4375 times committed weight against a 1.5 limit, so the settlement revert that would lock a cursor is unreachable through the pinned modules.
• Weight commitment generations, expiry buckets and pro-rata entry reconcile with the epoch denominator.
• The loadout snapshot cannot be re-rolled within an epoch, so productive hash always derives from the loadout the weight was committed from.
• Launch inputs: all eight creation hashes match the task list and the ModuleCode pins, and the recomputed GAME_CONFIG_HASH matches.

Coverage

The unreached rows are the V4Market hook callbacks, the FeeRouter ETH deposit paths, GridOperator resolution and a few Season lottery functions. They are outside the assigned area and were not traced within the time budget.

Added failure-path tests and three stateful invariant campaigns. Coverage and limitations.

Validation passed: forge build, seeded full suite (369 passed, 0 failed, 6 fork tests skipped), and final targeted checks.

Pinned sources and configuration remain unchanged. No deployment was broadcast.

Review complete. The findings file is written at the repository root with four findings and a 157-row coverage record.

What I verified

• All eight creation-code hashes from the local build match the task's expected hashes and the pins in ModuleCode. Runtime sizes are all under the 24,576-byte limit, with FarmCore the largest at 22,361 bytes.
• The recomputed GAME_CONFIG_HASH from the four manifest words matches the stated value.
• The manifest in launch.json has only the schema keys, eight unique contracts in dependency order, string arguments, and backward references.
• Constructor words pass every constructor guard: heartbeat 200 is inside 200..5000, the cap is exactly 1e18, both roots are non-zero, and the 200M endowment is under the 250M ceiling.

Specialist findings, settled

• Kept, low: pack price is a per-farm mean, so splitting hash across one-item wallets drives the curve toward its floor. I re-ran the scenario in a scratch test and got the same numbers the specialist reported, roughly a 10x drop in average daily and 12.9x in price going from 2 to 20 farms.
• Kept, info: the 116.5% reservation comment versus the 159% code, the level NatSpec age caps that disagree with maxLevelByAge, and the StarterResolved expired flag that can never be true. Each reproduced by reading the cited lines.
• Dropped: the audit_flow medium about the escrow holding zero tokens. I queried Robinhood Chain at block 88284865. The escrow now holds the full 200M principal plus dust, the binder wallet holds zero, and forwarded is still false. The runbook's step-2 precondition is met, so the finding no longer reproduces.

Coverage

All 157 entry points have a row. The 72 job A entry points and 24 of the L4 entry points that job A calls directly are marked holds or finding with a one-line reason. The remaining 61 rows, mostly Civic, Billboards, Enhancement, Season claims, the V4Market hook and the Desk oracle paths, are honestly marked unreached as outside this launch and beyond the budget.

No critical or high findings, so no proof files were attached. The scratch test directory was removed and no repository file was changed.