Delivered and committed on main (commit 99b1299). Clean rebuild, all 134 tests, and forge fmt --check pass with solc 0.8.26 pinned; the pinned IdentityMD floor suites also pass against this exact creation code.

What was built

• src/WinToken.sol: plain fixed-supply ERC-20, 10^27 units minted to the deployer, no owner or mint.
• src/WinGameHook.sol: the whole game. Fee in IMD on all four swap shapes (exact-in/out buy and sell), 50% to 3% linear decay over 30 minutes, 90/10 bank/team split, rounds with a 10-minute timer, 3-hour floor and 20% prize for round 1, 5% after, minimum buy of max(8.5 IMD, 20% of next prize) rising 5% per qualifying buy and resetting per round, permissionless settle(), website views and a one-call gameState().
• src/HookFlags.sol and test/mocks/MockERC20.sol at the paths the protected floor tests import.
• script/DeployWin.s.sol: reference deployment whose deploy(Config) the tests call directly.
• README.md (design, assumptions, launch parameters, operations) and docs/REVIEW.md (adversarial review with findings and open items).
• Vendored forge-std, v4-core sources and solmate Owned.sol as plain files, no submodules.

Key design decisions

• Fees are minted as ERC-6909 claims, so the first buy on a WIN-only pool with an empty PoolManager works; claims are redeemed via the hook's own unlock on payouts. This avoids the known take-in-afterSwap failure.
• Buy after the deadline closes the expired round for its real leader before anything else, so post-expiry sniping cannot steal a round. Block stuffing and sequencer ordering are analysed and quantified in the README rather than claimed solved.
• Buyer identity comes from hookData, with a tx.origin fallback for plain wallets, and the trade-offs for smart accounts and relayers are documented.
• The linear fee curve was kept as specified; the README explains why the alternatives are worse against snipers.
• Partial fills on the specified IMD side revert instead of over-charging.

Caveats to be aware of

• No network.json was pinned, so the chain, PoolManager and IMD address are deployment parameters. The tests deploy their own PoolManager and run unchanged under a fork URL, but no fork run happened here because the verifier is offline.
• The review in docs/REVIEW.md is a self-review structured for an independent contributor; it is not the independent review the brief requires, and it lists what that reviewer must close before funds are at stake.
• The launch manifest is written by the separate manifest node; the README section 9 holds everything it needs.

launch.json is written and validates against the launch manifest schema; it is the only file changed (left uncommitted in the working tree).

One thing needs the deployer's attention: pool.initialPrice is only correct if the deployed WIN address sorts below IMD. The token ordering isn't known until the token is deployed, and the schema has a single price field.

• WIN is currency0 (written in the manifest): 125262255113908064987203232, tick −129000.
• WIN is currency1: 50111677533496076234078224273595, tick +129000.

Using the wrong one misprices WIN by about 1.6e11×. This caveat and both values are in the notes.

What the manifest declares:

• Hook: WinGameHook, constructor args ["$poolManager", "$token"], permissions beforeInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta, afterSwapReturnDelta — exactly what getHookPermissions returns (flags 0x20CC).
• Token: WinToken, name WIN, symbol WIN, 18 decimals.
• Pool: paired with 0x5f7bb59365ce557c26dbcaa4ee9d39a4b95b7127, fee 3000, tick spacing 60.
• Notes: 3,607 characters, under the 4,000 cap.

The starting price is snapped to the spacing-60 tick the test fixture uses, so the market cap is 2,499.66 IMD rather than exactly 2,500 (0.014% under). I did this so the initial tick lands on a spacing boundary for the single-sided seeding; say so if you want the exact 2,500 price instead.

Checks I ran:

• Build and tests: forge build succeeds and forge test passes 145 tests. That count includes the protected hook and token suites, which I copied into test/scratch/ and ran against the creation code with the declared flags, supply and decimals.
• Fork run: the repository's 134 tests also pass with --fork-url on chain 4663, where the IMD address resolves to an 18-decimal token with symbol IMD. They deploy their own PoolManager and a mock IMD, so this does not exercise the chain's real PoolManager or IMD.

Two things the brief asks for are still owed, and the notes say so:

• Independent review: docs/REVIEW.md is a self-review by the contributor who wrote the code, not an independent one.
• Fork rehearsal: no test runs against the chain's real PoolManager and IMD token.

This content was flagged for possible cybersecurity risk. If this seems wrong, try rephrasing your request. If you’re doing authorized security work that requires more cyber permissive safeguards, apply for Daybreak access via https://platform.openai.com/settings/organization/status-and-access before retrying.

PREMIUM CAPACITY EXHAUSTED: account_auth_unavailable

The review is written to .imd-findings.json: seven findings (two medium, four low, one info) and a coverage row for all nine entry points. No critical or high defect turned up in the permission model, so no finding carries a proof test. No source file was changed, and the scratch tests I used were removed.

Six of the seven findings were reproduced with scratch tests against the repo's own fixture (mock IMD, local PoolManager, not a fork); the info item follows directly from the code. The numbers quoted in the file come from those runs.

Coverage: claimPrize, unlockCallback and the three WinToken functions hold; afterSwap, beforeInitialize, settle and claimTeamFees carry the findings above. I also recorded rows for beforeSwap and for two invariants (nothing leaves the bank except a prize; no owner, mint or upgrade), all of which hold.

Not reached: no chain or IMD address was pinned and there is no launch.json yet, so nothing was checked on a fork, against the real IMD token, or against a manifest. The single-unlock, zero-capital version of finding 6 is argued from v4's flash accounting, not run; the two-swap version is what I measured.

The audit is finished and .imd-findings.json is written: five findings (one medium, three low, one info) and a coverage row for all nine entry points. I found no critical or high defect in the math, so no finding carries a proof test; each has a reproduction with exact inputs and the numbers I measured in scratch tests, which I then deleted. No tracked file was changed.

Findings

1. Medium — a buy aimed at the lead can silently miss it (src/WinGameHook.sol:326). The buyer cannot ask for "revert unless I become leader", so a buy that falls 1 wei short still executes as an ordinary buy.
   • Exact-output buys: the qualifying amount depends on the pool price. The leader sells just before the challenger's buy, the challenger's cost drops to 9.4404 IMD against a 9.4656 minimum, and the leader keeps both the lead and the original deadline for a net 1.03 IMD. The README claims price manipulation cannot disqualify a buy; that only holds for exact-input.
   • Exact-input buys: once the minimum is prize-linked, any intervening fee raises it. A dust sell moved it from 37.8 to 37.8000059 IMD and a 37.8 IMD buy no longer took the lead.
   • The deliberate version needs the leader to order a transaction ahead of the challenger's; the accidental one needs only one unrelated trade.
2. Low — minimumBuy() and gameState() are wrong after a round expires and before it is settled (:391). The view showed 77.87 IMD while the next buy was actually held to 9.106 IMD, because the swap path closes the round before reading the minimum and the view does not.
3. Low — the 8.5 IMD floor assumes an 18-decimal pair (:65). beforeInitialize never checks the paired currency's decimals. With a 6-decimal IMD no buy could ever qualify and the bank would be locked for good. I could not verify the real IMD's decimals from the inputs, and this case is argued from the arithmetic, not run.
4. Low — taking the lead costs about 6.5% of the stated minimum (:294). Buying 8.5 IMD and selling straight back left the buyer as leader for a net 0.55 IMD. Rounds still end, but the escalation bites much later than the README's "~34 overtakes" (roughly 89). This is the requested rule, so any fix is a scope decision.
5. Info — launch price figures in the README are off (README.md:300). The quoted sqrtPriceX96 is wrong (1.2536e26; the exact value is 1.25271e26), and the 60-tick gap below the position means the first WIN trades at a 2,514.7 IMD market cap, not 2,500.

Coverage

• Holds: settle, claimPrize, claimTeamFees, unlockCallback and the three WinToken functions.
• Carries findings: afterSwap (1 and 4) and beforeInitialize (3).
• Fee and accounting invariants: a 256-run fuzz of mixed swaps with tight price limits and partial fills kept the hook's claims equal to bank + team share + unclaimed prizes, and the fee within 1 wei of the rate, for all four swap shapes.
• Checked by reading: the decay bounds, the escalator cap and the round-1 deadline floor.
• Not reached: nothing ran against a fork or a real IMD token; the tree pins no chain or IMD address. Access-control and wider game-economics questions outside the three math guides were only looked at in passing.

The findings file is in place at the repository root (git excludes it by design via .git/info/exclude), the scratch tests are removed, and the original 134-test suite still passes with the tree otherwise untouched.

Review complete

I audited the WIN game economics, invariants and flow gaps in src/WinGameHook.sol and src/WinToken.sol against the Pashov Economic Security, Invariant and Flow Gap guides, plus the v4-security and x-ray checklists. The results are in .imd-findings.json: four findings and fifteen coverage rows, all nine verifier-listed entry points answered.

Findings

1. Medium. A buy that misses the qualifying minimum is silently executed as a plain trade and still pays the full fee. Because each qualifying buy raises the threshold by 5%, a bot that front-runs an at-minimum bid with its own at-minimum bid voids the victim's bid while keeping the lead. Reproduced: victim pays 0.26775 IMD on an 8.925 IMD bid, gets no lead, no error. This is the leader-sandwich case the brief asked to defend; suggested fix is an opt-in "qualify or revert" flag in hookData.
2. Medium. The prize-linked part of the minimum drifts with every trade, including sells, which the brief says never touch the game. Reproduced: a 0.1 IMD sell paying 0.003 IMD of fee moved the minimum enough to void an exact 11.34 IMD bid. Suggested fix is snapshotting the base at round start.
3. Low. While a round is expired but unsettled, the website views describe the dead round. Reproduced: shown minimum 10.33 IMD versus an actual 8.5 IMD floor, and shown prize 5.4 IMD versus an actual next-round prize of 1.09 IMD.
4. Info. Block stuffing has no mechanical defence. The prize is 5% of an uncapped bank, so once the bank exceeds about 20 times the cost of ten minutes of full blocks on the chosen chain, stuffing wins every round. The author documented this residual; I recorded it beside the unpinned chain choice.

What held. Fee math on all four swap shapes in both pool orientations, claim-based fee custody and delta composition, the 90/10 split, round-1 floor and 20% prize, lazy close versus settle() parity, reentrancy and unlock-nesting guards, conservation of hook claims, and the token's three entry points. No critical or high defects were found, so no proof tests were attached.

Not reached. No fork run (no RPC or network.json pinned), no live IMD token behaviour on the selected chain, and no standalone invariant campaign beyond the existing fuzz test.

All four anchors now match the tree, and the working tree shows only the findings file plus my scratch tests, which are both permitted. The review is complete.

Review complete: .imd-findings.json written with 4 findings and 16 coverage rows

Scope covered. I traced the hook's control flow through the Execution Trace, Periphery and First Principles guides: all four swap shapes in both pool orientations against the real Hooks.beforeSwap/afterSwap sign handling, the mint-versus-hookDelta offset, the unlock/burn/take payout path, the round state machine, and the identity decoder. I also verified the vendored lib/v4-core is byte-identical to upstream and ran both pinned protected floor suites against this creation code (all pass). The existing 134-test suite passes.

Findings, most severe first:

1. Medium. The qualifying minimum is read from the live bank at execution time, so the current leader can disqualify a challenger's exact-minimum buy with a dust trade. A 1e6-wei buy moved the minimum by ~300 wei in my repro, and the challenger still paid the full 3% fee without taking the lead. The brief asked for a defence against leader-sandwiching; this is the inverse and has none. Suggested fix: snapshot the prize-linked base per round and per qualifying buy, optionally with a "must qualify" hookData flag that reverts the swap.
2. Low. After the deadline but before settle or the next buy, minimumBuy(), roundNumber(), leader() and nextPrize() report the dead round's numbers. A buy of 8.5 IMD qualified while the view showed 10.85 IMD.
3. Low. A contract that buys without hookData hands the lead and prize to tx.origin (its keeper). The hookData path is unauthenticated, so a router can name itself. Both are documented trade-offs; recorded because the prize goes to a party other than the payer.
4. Info. No fork test exists despite the brief's requirement; no chain was pinned. Recorded as an admission open item rather than a code defect.

What held. Delta accounting sums to zero on every path, partial fills are rejected rather than overcharged, settlement cannot run inside a swap, the three payout entry points share a reentrancy guard, the team wallet is a compile-time constant, and nothing can leave the bank outside the game rules. No critical or high defect was found, so no proof files were attached.

Not reached. Economic tuning of the escalator and first-round incentives, and block-stuffing cost on a specific chain, which belong to the economics specialist.

I added the missing invariant campaign, an adversarial unit/fuzz file and a fork rehearsal, all under test/. forge build succeeds and forge test passes offline: 186 passed, 0 failed, 2 skipped (the two fork suites, which skip themselves without an RPC). No tracked file was modified.

What was added

• test/invariant/WinGameHandler.sol — a handler with four actors and bounded random actions:

  • Trades: all four swap shapes, buys aimed exactly at / one wei under / just over the minimum, and last-second, on-deadline and post-deadline snipes.
  • Game calls: settle, claimPrize, claimTeamFees.
  • Environment: time jumps, raw-IMD and ERC-6909 donations to the hook, third-party liquidity, and direct calls to the callbacks from a non-manager.
  • Buyer identity: eight hookData / tx.origin variants.

  After every action the hook's full state is compared with a small model restated from the brief.

• test/invariant/WinGameHook.Invariant.t.sol — two campaigns (invariant_money, invariant_game) at 256 runs × depth 50, in four variants: from launch, after round 1, and each with WIN on the other side of the pool. They check:

  • the hook's claims equal bank + team share + unclaimed prizes;
  • the bank is fed only by 90% of fees and drained only by prizes;
  • IMD and WIN are conserved across the system;
  • the round state machine and the minimum-buy formula;
  • past winners are append-only, and round 1 never closes before launch + 3h;
  • the fee curve and the website views agree.

  A scripted test_handlerReachesEveryPath guards against the handler going idle.

• test/WinGameHook.Adversarial.t.sol — 23 tests, most run in both orientations:

  • same-block races;
  • "any qualifying buy gives the field a full ten minutes" (fuzz);
  • the exact qualification boundary (fuzz);
  • identity abuse;
  • claims that must revert;
  • settle one second early and on the deadline;
  • a sell larger than the pool's IMD;
  • order-splitting and dust;
  • round-trip cost (fuzz);
  • gas not growing with winner history;
  • callbacks for the wrong or an uninitialised pool;
  • a winner that swaps from inside its own prize payout.

• test/WinGameHook.Fork.t.sol — launch rehearsal against the chain's real PoolManager, configured by WIN_FORK_RPC_URL, WIN_FORK_POOL_MANAGER and optional WIN_FORK_IMD.

How far it was checked

• Mutation check: I temporarily broke the hook four ways (sells closing a round, lazy close after the leader is overwritten, payout not reducing the unclaimed total, wrong exact-output fee). The invariants caught all four; the source was restored each time.
• Reachability: within 50 calls the campaigns reach settles plus lazy closes, five or more winners, four or more qualifying buys in a round, and prize claims.
• Fork: the rehearsal passes on Base mainnet with a stand-in IMD and with DAI as an 18-decimal real token. It has not been run against the actual IMD token, because the selected chain and IMD address were not pinned to this task — that run is still owed.

Findings (.imd-findings.json)

No critical or high defect turned up. Three items are reported rather than asserted as correct:

1. Low — minimumBuy() overstates the minimum while a round is expired but unsettled. A buy in that window is judged against the next round's reset minimum, so a buy one wei under the displayed value takes the lead. In the proof the view shows 9.37 IMD while 8.5 IMD is enforced. A self-contained failing proof test is attached.
2. Info — the hook binds to the first pool anyone initialises with it, with any counter-currency, price and tick spacing. This is safe with the factory's atomic deploy-and-initialise, but not through script/DeployWin.s.sol, which leaves a gap.
3. Info — the 8.5 IMD floor is the raw constant 8.5e18, and IMD's decimals are never checked. With a non-18-decimal token no buy could qualify and the bank would be locked. The for

Done. git status is clean apart from ignored paths, so no tracked file was touched; .imd-findings.json holds 11 findings and 13 coverage rows (all 9 entry points plus 4 invariants), and every path/line/snippet was verified against the tree.

Summary of the review

Reproduced and kept (specialist findings, merged):

All reproductions were run in test/scratch/Repro.t.sol (9/9 pass, i.e. each attack succeeds on the current code), with the exact numbers quoted in the JSON.

New finding none of the four reported (#1, high, with proof): launch.json carries one initialPrice (= getSqrtPriceAtTick(-129000), so the math specialist's "…231" was off by one), which is the 2,500 IMD market cap only if WIN's address sorts below the IMD address. beforeInitialize ignores the uint160 price entirely. In the other ordering — roughly 63% of random token addresses — the hook permanently binds to a pool where the first WIN sells at a 403,672,527,210,761 IMD market cap, with no owner to fix it. The attached Proof_Orientation.t.sol fails on this tree for that reason and passes once beforeInitialize refuses a price that doesn't match the briefed cap for the observed ordering.

Dropped / folded: the README sqrt misquote (math #5) was folded into finding 1; flow #4's "no fork test" was updated to reflect the fork suite that now exists but skips without an RPC.

could not restore accepted work: dependency did not apply: fatal: transport 'file' not allowed

could not restore accepted work: dependency did not apply: fatal: transport 'file' not allowed

The revision is complete. All ten findings were reproduced on the starting tree before anything was changed, and every one has an answer in .imd-responses.json.

Verification on the result

Fixed in src/WinGameHook.sol

• Starting price (high, proof). beforeInitialize now derives the expected tick from the ordering it observes (−129,000 when WIN is currency0, +129,000 otherwise) and reverts WrongStartingPrice outside ±300 ticks. The proof fails on the old tree and passes now. Both exact prices are exposed by launchSqrtPriceX96(bool) and listed in the README.
• Voided challenges (medium). hookData accepts abi.encode(buyer, mustLead). A flagged buy that falls short at execution reverts NotQualifying, so the challenger pays gas and no fee. All three reviewer cases are tested. Unflagged buys keep the brief's literal rule.
• Identity (medium). With no hookData the hook now asks the router for msgSender() before falling back to tx.origin, so a smart account through the Universal Router is credited correctly. The remaining residual (router with neither) is tested by name and documented.
• Unpayable winner (low). settle() always closes the round and pushes the prize best-effort; on failure it emits PrizeDeferred and leaves the prize claimable. A payout attempted inside an open manager lock is refused up front with ManagerUnlocked.
• Stale views (low). minimumBuy(), nextPrize() and roundNumber() project the post-close state once the deadline has passed, matching what afterSwap enforces. pendingPrize() and new gameState() fields describe the closing round.
• Decimals (low). The paired currency must report 18 decimals or initialization reverts.

Disputed, with reasoning recorded

• Stranger initialization. Both proposed hook-level checks can kill the real launch under a factory flow this tree cannot see (CREATE2 helper, position-manager initialization, no manifest placeholder for the pair). The reference script now initializes in the same call, and the README states the atomicity requirement.
• Sell-back lead, open team claim, block stuffing. Each is the brief's rule as written. The README claim that a sell-back "gains nothing" was wrong and is corrected with the measured cost (6.47% of the minimum). The mechanical alternatives are listed for the requester in docs/REVIEW.md section E.

For the deployer: the manifest's single initialPrice is only right when the deployed WIN address sorts below IMD. The hook now refuses the mismatch loudly, so the manifest node must write the price after the token address is known or pin the token's salt.

I updated launch.json to match the current hook. It validates against the launch manifest schema, the build passes, and all 179 repository tests pass. I also ran the two protected floor suites against the built hook declaring flags 0x20CC, and all 10 tests passed. No other file is modified.

What stayed the same, because the current code still matches it:

• Contracts: WinGameHook and WinToken.
• Hook constructor arguments: ["$poolManager", "$token"].
• Permissions: beforeInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta and afterSwapReturnDelta, which is exactly what getHookPermissions returns.
• Pool: paired with 0x5f7bb59365ce557c26dbcaa4ee9d39a4b95b7127, fee 3000, tick spacing 60, and initialPrice 125262255113908064987203232. That price is tick −129000, a 2,500 IMD starting market cap, and the hook's own price test checks the same number.

What changed: the notes (3,603 of 4,000 characters). Since my last round the hook has gained several behaviours the notes didn't describe:

• Starting price check: beforeInitialize now rejects a starting price more than 300 ticks from the briefed one for the token order it sees (error WrongStartingPrice).
• Buyer identity: the hook takes the buyer from hookData first, then from the router's msgSender(), then from tx.origin.
• "Must lead" flag: a buyer can set it so their buy reverts if it misses the minimum at execution, instead of paying the fee without taking the lead.
• Settlement: settle() always closes the round. If IMD refuses the winner, the prize waits in a claimable balance (claimPrize).
• Review status: docs/REVIEW.md now records an independent review's findings, E1–E10, and what was done about each.

Before deploying:

• Token address order: the price in the manifest is only correct if the deployed WIN address sorts below IMD. If it sorts above, the hook expects 50111677533496076234078224273595, and pool creation will revert with the manifest's value rather than open a mispriced pool. The deployer must either place WIN below IMD or use the other value.
• Fork rehearsal still owed: the tests use their own PoolManager and a mock IMD, so nothing has yet run against the selected chain's real PoolManager and IMD.
• Block stuffing: this is only deterred economically. The review leaves it as a decision for the requester and recommends a fixed cap on the prize once the chain is known.

Everything is in place. Summary of this revision:

What I found when reproducing

The advisory finding reproduces (fork suite skips without WIN_FORK_RPC_URL), but the tree was not in the state it described: forge test on the merged tree failed 7 of my own tests. The other contributor's accepted revision of src/WinGameHook.sol changed the view semantics while an expired round waits for settle() — roundNumber(), nextPrize(), minimumBuy() now describe the next round, and the closing round moved to a new pendingPrize() and gameState().pending* fields — and added a mustLead hookData flag. My assertions encoded the old semantics; the hook's new behaviour is documented and consistent, so these were stale tests, not a defect.

Changes (all under test/)

• WinGameHook.Adversarial.t.sol — two tests now read the expiring round's prize from pendingPrize() and additionally pin nextPrize() == (bank − pending) × 5%.
• invariant/WinGameHook.Invariant.t.sol — round-state, minimum-buy and website-view checks now cover both the running and the expired-pending case with exact formulas; minimumBuy() is cross-checked against the handler's independent model; the new pending* view fields are asserted.
• invariant/WinGameHandler.sol — drives the new must-lead path: a refused must-lead buy must leave fee, bank, round and lazy-close untouched with the exact NotQualifying revert; a landed one must lead; a flagged sell must be refused with MustLeadOnlyOnBuys. Coverage counters added to the "harness is not vacuous" script.
• WinGameHook.Fork.t.sol (the finding) — the four rehearsal tests now run unconditionally on the vendored PoolManager as a control (WinGameHookRehearsalTest/Flipped), with the fork runners reusing the same bodies and still skipping honestly. Since this machine had network, I ran the fork variant against the real Base, Arbitrum and Ethereum PoolManagers (stand-in IMD, both orientations, 8/8 each) and recorded blocks in the file header.

Results

• forge test: 239 passed, 0 failed, 2 skipped (the two network-gated fork runners); invariants 256 runs × 50 depth × 4 campaigns, zero violations.
• .imd-responses.json written with verdict fixed and the full detail. No .imd-findings.json: nothing I tested reveals a defect in the revised hook.

What remains open and cannot be closed offline — stated in the response rather than papered over: the selected chain's real IMD (decimals/transfer semantics) and WIN's ordering against its address; test_rehearsal_imdHasEighteenDecimals is the gate for that once a chain is pinned.

Review settled. Summary of this round:

Previously reported, now confirmed fixed (each re-run with my own scratch reproductions, not just the author's tests):

1. Orientation/price — my attached proof Proof_a30bd48ea51f now passes: beforeInitialize converts the supplied price to a tick and reverts WrongStartingPrice unless it is within ±300 of ∓129,000 for the observed ordering (src/WinGameHook.sol:283-287).
2. Short buy silently executed — abi.encode(buyer, true) hookData reverts NotQualifying inside afterSwap; verified fee-free reverts for the dust-buy, leader-requalify-and-sell-back, and exact-output-undercut triggers.
3. tx.origin fallback — _resolveTrader now probes the router's msgSender() before tx.origin; a 4337-style trade (vm.prank(bob, bundler)) through a msgSender router credits bob.
4. settle() reverting for an unpayable leader — settle() finalizes unconditionally and defers via PrizeDeferred; round closes, accounting holds, claimPrize works once unblocked.
5. Stale views after expiry — minimumBuy()/nextPrize()/roundNumber() project the post-close state; a flagged buy of shown−1 wei reverts, shown value leads, round-1 pending shows 5% terms.
6. Decimals — paired currency must report 18 decimals at initialization.
7. Fork suite — rehearsal bodies now run offline on the vendored PoolManager.

Disputed by the author, dispute accepted (not reopened): stranger binding under non-atomic deployment (factory is atomic; deploy script can now initialize in the same call), buy-and-sell-back cost, open claimTeamFees(), block stuffing — all are the brief's rules or requester decisions, now documented accurately.

Fresh pass over the changed lines (try/catch payout, ManagerUnlocked guard, 64-byte hookData parsing, msgSender probe, view projection): nothing new reproducible. Protected floor suites pass with flags 0x20CC (3/3 hook, 7/7 token); full suite 240 passed, 0 failed, 2 network-gated skips.

.imd-findings.json holds an empty findings list and 13 coverage rows (all 9 entry points holds, plus invariants and residuals). No tree files were modified; scratch tests live only under test/scratch/.