The manifest is written, the build succeeds, and all 59 tests pass with the pinned fuzz seed. The only new file in the tree is launch.json.

What launch.json contains

• One contract, WebsiteBuyer, with the single constructor argument $owner. Its constructor takes only an owner address for Ownable2Step and calls no other contract, so it deploys on the empty rehearsal chain.
• IntakeAccount is deliberately not listed. WebsiteBuyer creates one per buyer with CREATE2 on their first purchase, setting itself as hub and the buyer as user. A factory-deployed instance would have the factory as hub and would be unusable.
• Notes describe the hardcoded constants (IMD, PoolManager, the native ETH/IMD pool key, the initial Intake v2 address), the buyWebsite flow, the owner's setIntake and setPaused powers, and the result and failure callbacks. The notes are well under the 4000-character limit.

Checks run

• The JSON parses with exactly the keys kind, contracts and notes.
• forge build compiles cleanly, with only pre-existing lint hints.
• forge test with the verifier's fuzz seed passed every test, including the deployment test that confirms the owner is the launch wallet and not the factory.
• git status --porcelain shows only launch.json as new.

I added three test files. The whole suite passes with the verifier's seed: 75 tests in 10 suites (two are my throwaway probes in test/scratch/, which gets deleted). I found no critical or high defects, and I reported four smaller issues in .imd-findings.json instead of writing tests that treat them as correct.

What I added (all under test/):

• WebsiteBuyerInvariant.t.sol: random sequences against the existing mocks, about 10,000 calls per run with no unexpected reverts. Three buyers make good and bad purchases while results and failures arrive, callbacks are faked, the owner pauses, switches between up to three Intakes, and IMD and ETH are sent to the contract directly. Every expected refusal is checked for its exact reason. After every step these hold:
  • the contract never holds ETH, and its IMD only ever equals what was sent to it directly;
  • every wei a buyer spends ends up in the pool;
  • the treasury gets exactly the prices, each buyer gets exactly their leftover IMD, and no IMD is created or lost;
  • each buyer's payer account holds nothing, approves nothing, never changes and is never shared;
  • each stored request matches who paid, through which account, at what price and on which Intake, and a result or failure is recorded only once.
• RealPoolInvariant.t.sol: the same checks against the real Uniswap v4 PoolManager code with real liquidity, while another trader moves the price both ways. A purchase may only fail because the IMD came back below the price, or because the pool could not fill a tiny or out-of-range amount. In either case nothing moves.
• WebsiteBuyerEdges.t.sol: 12 failure-path and edge tests, including:
  • a buyer's future account address funded before their first purchase;
  • purchases of the largest possible ETH amount and of 1 wei;
  • pausing twice or unpausing when not paused;
  • bad words refused before the price is read;
  • no owner field in the body;
  • a failed callback that the Intake cannot retry;
  • result URIs of up to 192 bytes stored within the Intake's 200,000-gas callback limit.

Findings in .imd-findings.json:

• Low: words that aren't valid UTF-8 are accepted. For example, buyWebsite(hex"fffec080") succeeds and pays the 0.5 IMD. The resulting body isn't valid JSON, so the Intake will probably refuse it, and the price is not refunded.
• Info: a result URI of 200 bytes or more runs out of the 200,000-gas callback limit, and that request stays Pending for good. The ipfs:// and fallback URI formats in the docs are 80–110 bytes, so they fit.
• Info: the only slippage protection is the live Intake price, so a sandwich attack can take a buyer's entire leftover IMD. The brief asks for this design.
• Info: IMD sent straight to the contract can never be used or recovered, because there's no sweep function.

Still owed: none of this ran against live mainnet. The Intake and IMD token are local mocks.

The review is complete and .imd-findings.json holds four findings plus coverage rows for all 12 entry points and three invariants. No source file was changed and the scratch tests were removed.

What I checked. The Math Precision, Boundary and Numerical Gap guides against both contracts. There is no division, scaling or unbounded narrowing cast anywhere in src/. The msg.value bound, the full-fill check at the v4 price limit, the native sync-then-settle sequence, the balance equalities and the exact-debit check in the payer account all hold, and I confirmed them on the vendored real PoolManager. The hardcoded pool key hashes to the brief's pool id. All 59 existing tests pass.

Findings, by severity:

• Medium, buyWebsite line 111. The only output floor is the live Intake price, so a sandwich can take the whole surplus the brief promises back to the buyer. Reproduced on the real v4 math: a 0.01 ETH purchase that honestly returns 9.4 IMD returns 130621 wei of IMD after a front-run, and still succeeds. A 2 ETH front-run against a 1 ETH purchase is net profitable for the attacker. The README lists this as an assumption, and fixing it needs a scope decision because the brief fixes the signature, so I framed the options rather than prescribing one.
• Low, onIntakeResult line 191. Result URIs longer than about 200 bytes exceed the 200k callback stipend. Measured: 192 bytes delivers, 224 does not, and the record then stays Pending with the hash lost too.
• Low, onIntakeFailure line 199. A failure status outside 1 and 2 reverts and strands the record Pending with no settle path. No funds depend on it.
• Info, bodyOf line 170. The byte filter admits bytes that are never valid UTF-8, so a buyer can pay for a body the plane may refuse. Whether the plane refuses or substitutes could not be verified from here, so it is recorded as information only.

No critical or high finding was found, so no proof test is attached.

The review is complete and written to .imd-findings.json at the repository root. No source, config or test files outside test/scratch/ were changed.

Outcome. The permission model is sound. Every entry point was traced: hub-only ask, user-only execute, PoolManager-only unlockCallback with a single-use flag, callbacks bound to the Intake that accepted each request, and OpenZeppelin two-step ownership with an explicit constructor owner. No permission bypass, confused deputy or inconsistent guard exists. The existing suite of 59 tests passes.

Findings reported, all with concrete reproductions I ran locally:

1. Medium. Surplus IMD has no floor. The only output check is received >= price, so an unprivileged searcher can sandwich a purchase and take everything above the Intake price. On the vendored real PoolManager with 20e18 liquidity, a 7.6 ETH front-run cut the buyer's surplus from 0.443 IMD to 0.0046 IMD and netted the attacker 0.339 ETH. The one-argument interface the brief asked for is the root cause, so the fix needs a scope decision on adding a bound argument.
2. Low. Live price is uncapped. A price change landing before the buyer's transaction is paid in full, up to the whole swap output. Reproduced: price raised to 1.9 IMD, the buyer paid 1.9 IMD instead of 0.5.
3. Low. Action id is a constant. If the Intake retires job.open@job-1 for job-2, every purchase reverts ActionNotSold and setIntake cannot repair it. The intake-client reference requires the action to be owner-settable.
4. Info. Owner trust assumptions. setIntake can redirect every future price to arbitrary code, and pause plus renounceOwnership freezes purchases permanently. Pending requests stay bound to their original Intake, so paid work is unaffected.

Coverage. All 12 listed entry points have rows, plus three invariants and one row per assigned guide. Uniswap settlement math and token edge cases are marked unreached as outside my area.

The review is complete. The findings file is written at the repository root and the scratch tests are removed, so the tree contains only the review output.

What I checked

I audited the Economic Security, Invariant and Flow Gap failure modes against src/WebsiteBuyer.sol and src/IntakeAccount.sol. The existing suite passes with 59 tests. I also ran the full purchase against a mainnet fork through the local RPC, so the live Uniswap v4 pool, the live IMD token and the live Intake were exercised rather than mocked. A 0.00112 ETH purchase and a 1 ETH purchase both succeeded. The Intake pulled exactly 0.5 IMD to its treasury and returned a request id. The hub and the payer account ended with zero IMD and zero allowance. IMD moved exact amounts and returned true, so the fee-on-transfer and void-return guards are not triggered by the real token.

Findings written to .imd-findings.json

• Medium: the only output bound is the live price, so the surplus is sandwichable. The swap runs to the minimum tick limit with no deadline and accepts any output at or above 0.5 IMD. On the live pool, about 388 ETH of virtual reserves at roughly 455 IMD per ETH, a 10 ETH purchase can be cut from about 4,388 IMD to about 844 IMD for about 3.2 ETH of searcher profit. I reproduced it locally on the vendored PoolManager: the victim's surplus fell from 46.67 IMD to 4.98 IMD while the call still succeeded and the attacker netted about 17 ETH. The README acknowledges the exposure and the one-argument interface is the cause, so I framed it as a documented design gap with its concrete cost and a possible overload with a caller bound.
• Info: result URIs above about 192 bytes cannot be stored within the 200,000-gas callback. A 224-byte URI fails and the record stays Pending forever. Today's protocol URIs are 78 to about 100 bytes, so nothing fails on current inputs.

Coverage

All 12 listed entry points have a row. One is marked finding for buyWebsite. The other 11 hold, with the owner's Intake redirection, pause and renounce powers recorded as trust assumptions rather than bypasses. Four invariant rows cover zero custody between calls, one payer per buyer, the exact body bytes, and the live dependency state.

Not reached

I did not inspect the liquidity distribution outside the active tick range, so the sandwich figures use the active range's virtual reserves and are conservative if liquidity thins further out. No critical or high finding was found, so no proof test was attached.

The review is complete and written to .imd-findings.json with three findings and a coverage row for all twelve entry points plus three invariants. No source files were changed; the scratch tests are removed.

What I verified. I traced the whole purchase path on a mainnet fork against the live PoolManager, the live IMD token and the live Intake v2, not just the mocks. The pool id matches the hardcoded key, the pool is initialized with liquidity, job.open is priced at 0.5 IMD, and a real purchase ends with the hub and payer account holding nothing and no allowance left. I also fetched the Intake's verified source and drove both its result and failure callbacks into the hub from the real writer address, under its real 200k stipend. Both delivered and the encodings match.

Findings, most severe first:

• Medium, buyWebsite has no output floor beyond the Intake price. The swap runs with no price limit and the only check is received >= 0.5 IMD. On the fork, a 1 ETH purchase returned about 448 IMD surplus; after a 200 ETH front-run it returned about 227 IMD and still succeeded. The brief fixes the one-parameter interface, so I flagged it as a scope decision: add a minimum-output argument, or document that buyers should send only slightly more than the price needs.
• Low, result callback cost is close to the stipend. Storing the full URI costs about 170k gas for a 101-byte URI. Delivery stops between 192 and 224 bytes, after which the request stays Pending forever with no hash recorded. Documented plane URIs fit, but with little margin.
• Low, invalid UTF-8 passes the words filter. A lone 0xFF or 0xC3 byte is accepted, the ETH is swapped and the price is paid, and the plane will refuse the body off chain. The brief's literal refusal list does not cover it, so it is low.

Coverage. All entry points in my area hold except the two carrying findings. The owner powers (setIntake, setPaused, renounceOwnership) are recorded as trust assumptions rather than defects. I could not exercise the plane's actual refusal of invalid UTF-8, only the on-chain acceptance; the finding says so.

The review is complete and .imd-findings.json holds seven merged findings plus a 15-row coverage record.

What I did. I read both contracts, the manifest, the mocks and the test base, built the project with sizes, ran the existing 71 non-invariant tests (all pass), and reproduced every specialist lead in two scratch suites under test/scratch/. The sandwich ran on the vendored real Uniswap v4 PoolManager at the hardcoded addresses.

Findings kept, after merging duplicates:

• Medium, no output floor beyond the live price. Four specialists and the tester reported the same root cause at the received < price check. Reproduced: a 2000 ETH front-run cut a 50 ETH buyer's surplus by 89 percent while the call still succeeded, and the attacker netted 17.2 ETH. Kept at medium because the loss is the buyer's surplus under public-mempool conditions and the brief fixed the one-argument interface, so it needs a scope decision.
• Low, URI above about 192 bytes exhausts the 200k callback stipend. Reproduced the threshold: 192 bytes delivers, 224 does not, and the request stays Pending with no hash recorded.
• Low, failure status outside 1 or 2 reverts and strands the record Pending. Reproduced with status 3.
• Low, action id and asset are constants. Retiring job-1 at the same Intake address makes every purchase revert ActionNotSold with no owner setter. Reproduced.
• Low, invalid UTF-8 bytes pass the words filter. Three reports merged. Reproduced on chain; the plane's refusal itself is stated as unverified.
• Info, owner and Intake operator trust assumptions, including the live-price race that converts the buyer's ETH margin into price, and pause plus renounce freezing purchases. Two permission reports merged.
• Info, IMD sent directly to the hub is stuck. Reproduced.

My own pass found nothing additional. The unlock callback is gated to the PoolManager during the contract's own unlock, settles native ETH after a sync reset, and enforces a full exact-input fill. Both callbacks check the accepting Intake and Pending state. Runtime size is 10,426 bytes, the constructor touches no external code, and launch.json matches the constructor. The static-analysis leads did not reproduce as defects. No finding reached high or critical, so no proof file is attached.

Done. The manifest is revised and only launch.json changed.

What I found

• The accepted contracts were revised in the latest round. WebsiteBuyer gained an owner-settable action id with setAction, a buyWebsiteWithMinimum purchase with a surplus floor and deadline, strict UTF-8 word validation, and a 128-byte cap on stored result URIs.
• The constructor is unchanged: one address owner_ parameter, no external calls, no code requirements. IntakeAccount is created per buyer at runtime and is not a launch contract.
• The previous manifest's structure was already correct, but its notes described the older implementation.

What I changed

• Rewrote the notes in launch.json to match the accepted source: the mutable intake and action defaults, the new protected purchase function, the tightened setIntake checks, the setAction power, and the result URI storage rule.
• Contracts list and constructor arguments are unchanged: WebsiteBuyer with the single argument $owner.

Verification

• Manifest has exactly the keys kind, contracts and notes. The contract name is a valid 12-character identifier, every argument is a string, and the notes are 2057 characters.
• forge build succeeds and forge test passes all 73 tests with the verifier's fuzz seed.
• git status shows launch.json as the only modified file.

I've updated my tests to match the revised contract. forge test passes all 90 tests with the verifier's fuzz seed, and forge build succeeds.

The implementation changed after my last round, and three of my tests broke because they asserted the old behaviour. The changes to the contract were deliberate, so I changed the tests, not the expectations about correctness:

test/WebsiteBuyerEdges.t.sol

• URI storage: the old fuzz test expected every URI up to 192 bytes to be stored. It now covers 0–255 bytes and checks that every URI is emitted, the request is marked done with its hash, and the URI is stored only up to the 128-byte cap.
• New edge tests: a boundary test at exactly 128 and 129 bytes, and a 4096-byte URI that still settles within the 200,000-gas callback limit.
• Failure status: a status of 7 is now recorded as a failure. A status of 0 sent to the failure callback is now the case where the contract refuses delivery and the request stays pending.

test/WebsiteBuyerInvariant.t.sol

• Updated handler: result URIs now run up to 255 bytes, and the tracked state accounts for the storage cap. Failure delivery now covers statuses 1 and 2, any later nonzero status (recorded), and 0 (refused).
• New handler action: random call sequences now include the new buyWebsiteWithMinimum. Its minimum surplus is set around the actual surplus so both sides of the threshold, and equality, get hit, and its deadline is one second ago, now, or later. The existing invariants apply to it: the contract never holds ETH, IMD is conserved, and a refused purchase moves nothing.

One finding, in .imd-findings.json (low severity): result URIs longer than 128 bytes are emitted but not stored (src/WebsiteBuyer.sol:280). A request then shows as done with an empty URI, which goes against the brief's "store and emit each request's result hash and URI". The previous version stored URIs of at least 192 bytes within the gas limit, so the cap is lower than it needs to be. Realistic IPFS and fallback URIs are about 80–115 bytes, so they fit under it. test_resultURIStorageCapBoundary pins the current behaviour at the boundary so the report can be reproduced.

Review complete. The findings file holds an empty findings list and a full coverage record, and the tree is unchanged apart from it.

Outcome: every prior finding is settled, nothing new reproduces.

• Sandwich on the surplus (medium): fixed. The new buyWebsiteWithMinimum(words, minSurplus, deadline) reverts on an expired deadline and on a surplus below the floor, after the swap and before any account creation or Intake payment. I reproduced the floor, the raised-price race and the deadline on the mock pool. The project's real PoolManager test with a 2000 ETH front-run of a 50 ETH purchase reverts at 99% of the quote and passes. The one-argument form keeps the live-price floor the brief specifies, and the README directs clients to the bounded form.
• Long result URI loses the result (low): fixed. Done and the hash are always written, the URI is emitted always and stored only up to 128 bytes. With every storage slot cooled, URIs of 78 to 192 bytes all deliver under the 200k stipend. The 128-byte callback measured about 170k gas cold, so the test writer's claim that the cap is lower than needed does not hold once slots are cold. I dropped that item.
• Unknown failure status strands the request (low): fixed. Status 3 is recorded as Failed with its reason, and a second callback is refused.
• Action id was a constant (low): fixed. Owner-only setAction moves purchases to a new version and keeps the same payer account, reproduced through the retire-and-move scenario.
• Invalid UTF-8 accepted (low): fixed. The structural RFC 3629 check refuses 0xff, overlongs, lone continuations, surrogates, truncated sequences and code points above U+10FFFF before any swap, and accepts every valid scalar.
• Trust assumptions and donated IMD (info): author's dispute accepted. Both are requested or intended behaviour and are documented in the README. They are recorded in the file as settled rather than reopened.

The author noted they could not compile locally. It compiles here, and the full suite passes with 90 tests including 7 invariants. The manifest has only the three schema keys, one contract with $owner, and notes of 2057 characters. All 14 entry points are answered holds.