_feeFor compares |amountSpecified| against getLiquidity(id)/100 read before the swap. When the price sits outside every position (active liquidity 0, or below 100 units), the cutoff is 0 and any non-zero swap is classed as a whale swap. That includes tiny swaps that move the price back into liquidity and then trade through it.

The fee is fixed for the whole swap from that pre-swap reading. This follows the literal wording of the spec, but the README does not mention it, and no test covers it.

The constructor only bounds fees by LPFeeLibrary.MAX_LP_FEE (1_000_000), and the README states that value is valid. v4-core Pool.swap reverts with InvalidFeeForExactOut whenever the effective swap fee is >= 1_000_000 and amountSpecified > 0. A hook deployed with whaleFee = 1_000_000 therefore cannot execute any exact-output swap above the cutoff. Exact-input whale swaps would still pay a 100% fee.

The immutable fee cannot be repaired without a new hook and pool.

The README and NatSpec promise that the rule applies to exact-input (negative) and exact-output (positive) swaps in both directions. The only positive amountSpecified in the suite is int256(cutoff) in test_exactlyAtThresholdPaysBaseFee, which expects BASE_FEE and does not go through a real swap. Both real-swap threshold tests use negative amounts with fixed direction flags (true/false).

No test uses a positive amount just over the cutoff, so a bug in the positive branch would pass.

The pool has 1e24 liquidity on [-120,120], so in-range reserves are about 6e21 per token. The 'just under' swap of about 1e22 token0 and the 'just over' swap of about 1e22+1 both exceed that and run to MIN_SQRT_PRICE+1, crossing out of range. The tests only compare the fee field in the Swap event.

They never assert that the LP fee was actually charged (amounts out, feeGrowth, or the difference between the two swaps). They also do not show a swap of about 1% of L staying inside the active range. This weakens the just-under/just-over evidence the task asks for.

The tests also do not check that liquidity changes move the cutoff, that two pools using the hook keep isolated state, or that afterInitialize stores baseFee (getSlot0 lpFee). test_rejectsStaticFeePool uses a bare vm.expectRevert(), so any revert satisfies it.

The fee is decided per beforeSwap call from that call's specified amount. The README notes the discontinuity but not that it can be evaded. Also, PoolManager liquidity is in L (sqrt(x*y)) units, not token units, so for tokens with differing decimals or a price far from 1 the '1%' is not economically 1% of reserves or TVL.

Both follow the requested design, so this is an observation rather than a defect.