Implemented ETH-to-IMD swaps, per-user payer accounts, owner-settable configuration/templates, and authenticated result storage and events.

Verified with Solidity 0.8.26:

• forge build passed.
• forge test passed: 44 tests, using the supplied fuzz seed.
• forge fmt --check passed.

Deployment and operational details are in README.md. Before sales, configure the actual pool and validate the body with the live Intake checker; public checker paths returned HTTP 404.

Created launch.json with WebsiteBuyer and matching constructor arguments. No other submitted files changed.

Manifest structure and compiled ABI checks passed. forge build succeeded; all 44 tests passed with the specified fuzz seed.

Notes document that owner pool configuration is required before purchases.

I found three defects: one medium, one low and one informational. None is high or critical, so none needed a proof test. The results are in .imd-findings.json, with a coverage row for each of the 17 entry points plus two for checks I made of the token-balance invariant and the JsonText library. I changed no repository files, and the existing suite passes (44 of 44).

Findings

1. Medium, src/WebsiteBuyer.sol:294. bodyOf always adds "owner":"<caller>" to the body, and the set of keys is fixed in the code. A template only holds the prefix, skill, host flag and enabled flag. The text checks reject ", so no setter can drop the owner key or change the keys. As a result, the owner can't produce the brief's exact body {"objective":"Build a one-page website: <words>","skill":"build-website","host":true}.
   • Why it matters: the protocol reference never puts owner in a job.open body, and it refuses owner for custom_token (unexpected_owner). If the plane refuses it here, or a later action version changes the schema, every purchase spends the user's 0.003 ETH on a refusal. The only remedy is to pause and redeploy.
   • Not confirmed: I couldn't run the body through the live checker (POST /requests/check) because nothing I was given names its host. Whether the plane actually refuses the key is still open.
2. Low, src/WebsiteBuyer.sol:311. A result URI longer than 192 bytes makes onIntakeResult revert. The Intake calls back only once, so the result hash is lost along with the URI, no event is emitted, and the request stays Pending forever. A fix that fits the 200,000 gas limit: always store the hash and emit the full URI, and store the URI only when it fits.
3. Info, src/WebsiteBuyer.sol:194. The leftover IMD stays in the contract as the brief asks, but nothing can ever move it, not even the owner. After setIMD, the old token's balance is stuck too. This is a design question for the requester.

What holds

• Swap path (_buyIMD → unlockCallback): the callback only runs inside the contract's own swap, the whole ETH payment must be swapped, and settlement works for both native ETH and wrapped ETH. The output must be at least the largest of 0.5 IMD, the live Intake price and the caller's minimum.
• Configuration version: it is bumped by every setter, so a purchase built on old settings reverts.
• Payments: each user pays through their own account, the contract's IMD balance drops by exactly the price, and no approval is left behind.
• Callbacks: they are tracked per Intake and settle only once, and changing the Intake doesn't break callbacks still pending from the old one.
• Text checks: JsonText rejects quotes, backslashes, control bytes and malformed UTF-8.
• Callback gas: a 192-byte URI uses 193,266 of the 200,000 gas limit, so it fits.

The static-analysis reentrancy leads don't hold up: the guards and the swap-phase check block them.

Not covered: I didn't check any live mainnet pool, hook or token behaviour, and I didn't run the live body checker.

I found two defects in the economics review: one medium, one low. Both reproduce with scratch Foundry tests, which I deleted afterwards. The source tree is unchanged, and .imd-findings.json holds both findings plus 19 coverage rows: all 17 entry points and 2 invariants.

1. Medium: every request body gets an "owner" key the owner cannot remove (src/WebsiteBuyer.sol:294)

• What happens: bodyOf always adds ,"owner":"<caller>", and setTemplate only controls the objective prefix, the skill and the host flag. So the brief's body, {"objective":"Build a one-page website: <words>","skill":"build-website","host":true}, cannot be configured.
• Reproduction: the owner sets template 0 to exactly the brief's values, and bodyOf(0, alice, "a bakery") still returns …"host":true,"owner":"0x3288…"}.
• Why it matters: the intake reference adds owner only for launch kinds that deploy contracts, and treats bodies as strict. A website job deploys nothing. The per-user payer account already keeps each project with its user.
• Not confirmed: I could not run the plane's /requests/check because its host isn't in the supplied material, and there is no record that the builder ran it either. If the plane refuses owner on a website job, every sale's 0.003 ETH is lost and only a redeploy fixes it, which would make this high.
• Fix: make the owner key an owner-settable part of the template.

2. Low: surplus IMD is locked forever (src/WebsiteBuyer.sol:27)

• What happens: the only token transfers out are exactly the intake price to the user's account and the swap input to the pool. Nothing ever spends or withdraws the extra, and setIMD strands the old token's balance the same way.
• Reproduction: after 3 purchases the contract holds 1.5 IMD, and it is still there after setIMD.
• Why it matters: the brief says the extra stays in the contract, so the defect is that nobody can ever recover it. That also means anyone who sandwiches a purchase down to the 0.5 IMD floor takes value the owner could never have used.
• Fix: an owner-only sweep, which keeps the current rule that each purchase pays from freshly bought IMD.

Checked and holding:

• Swap settlement: the native and wrapped-ETH paths match Uniswap v4-core's sync/_settle, partial fills revert, and no ETH is left behind.
• Payment flow: the contract pays exactly the live intake price, the user's account ends at its starting balance, and its intake approval is cleared.
• Settings and callbacks: every setting change invalidates purchases already in flight, and callbacks are tied to the intake that took the request.
• Callback gas: a 192-byte URI fits the 200,000 gas callback limit, which an existing test covers.
• Static analysis leads: the slither reentrancy-balance leads can't be reached, because the swap callback is gated and the intake is a contract the owner sets and trusts.

I covered the Economic Security, Invariant and Flow Gap guides in full, and left no entry point unreached.

Review complete. The findings file is written and every snippet matches the tree at its cited line.

Outcome: one high finding, two low, one info note, and a coverage row for all 17 entry points plus two invariants, in .imd-findings.json. All 44 existing tests pass. The proof test under test/scratch/OwnerKeyInJobBody.t.sol fails on the current code with the expected body mismatch.

Findings

• High. Hard-coded owner key in every job.open body. bodyOf appends ,"owner":"<caller>" after the template parts, so the body differs from the brief's template and from the only job.open shape the intake reference shows as accepted. The reference reserves owner for launch kinds and says an unexpected key refuses the whole ask with the price spent. The per-user IntakeAccount already makes the project the user's, so the key buys nothing. The worse half is access-control asymmetry: setTemplate cannot reach that suffix, so if the plane refuses it, every purchase burns 0.003 ETH plus 0.5 IMD and the owner cannot repair it without a redeploy. The live checker could not be reached to settle the plane's answer, which the README also admits. Proof test attached.
• Low. Result callback reverts on a URI over 192 bytes. The Intake calls once, so the record stays Pending forever with no hash stored. The failure path has no equivalent limit. The project's own test already shows the stranded state.
• Low. Surplus IMD is dead money and sandwich-exposed. No entry point moves IMD out of the hub, and the caller who sets minImdOut has nothing at stake above the 0.5 IMD floor. Reported as a design consequence to confirm, since the brief says extra stays in the contract.
• Info. Trust assumptions. The owner can point purchases at a malicious pool manager, intake or token. Users are protected by the configuration version binding, and user account balances are never approved beyond the price just sent. renounceOwnership is irreversible.

Coverage: all setters, both callbacks, unlockCallback, the two-step ownership functions and the IntakeAccount entry points hold under the Access Control, Trust Gap and Asymmetry guides. Slither's reentrancy leads are blocked by nonReentrant, the swap phase commitment and balance checks. Aderyn's encodePacked lead is not a hash-identity use. Nothing was left unreached.

Review complete. The findings file is written and validated, and the working tree is untouched apart from the findings file and my scratch tests (gitignored, not kept).

What I covered

I audited the math against the Pashov Math Precision, Boundary and Numerical Gap guides. The contract has no division, scaling or decimal conversion: the only arithmetic is balance deltas with equality checks on every leg. I traced each entry point's bounds (ETH price capped at int128.max for the v4 swap amount, tick spacing and fee ranges matching v4, template and word limits against the 8000-character objective and 16 KiB body caps, UTF-8 validation at every multibyte edge), the exact-input delta equality in unlockCallback, and the sync-then-settle ordering against the real PoolManager. All hold.

The gas boundary that looked like a defect but isn't

The 200k callback stipend at the maximum 192-byte URI is tight. My first measurement read 219k, but a genuinely cold transaction (purchase in setUp, writer's complete as the test body) costs 193,266 gas, matching the suite's own number. The margin is 3.4%, so the stated maximum holds today.

Findings reported

1. Medium, buyWebsite slippage floor. The swap output floor is max(caller's minImdOut, constant 0.5 IMD, live price). The caller gets the same website regardless of how much IMD is bought, so they have no reason to set minImdOut, and the owner has no setter to raise the floor. On the real v4 PoolManager with a 0.05% pool, a 1.3 ETH front-run cut the contract's surplus from 2.489 IMD to 0.033 IMD and netted the attacker 0.00154 ETH after fees. The README acknowledges sandwiching but delegates protection to the uninterested party. Proposed fix keeps the design: an owner-settable output floor or rate folded into the same max().
2. Info, surplus is unrecoverable. No sweep exists and setIMD orphans the old balance. Documented as deliberate, flagged only because the brief's "extra stays in the contract" could mean retained rather than locked forever.

Coverage

All 17 listed entry points have rows (16 hold, buyWebsite carries finding 1), plus two invariant rows. Nothing was left unreached.

Added failure-path, fuzz, and stateful invariant coverage under test/.

• forge build passed.
• Full offline suite passed: 77 tests, using the required seed.
• Three invariants passed 16,384 randomized calls.
• No confirmed implementation defects found.

Intake behavior is mocked; real Uniswap v4 integration is tested locally.

Review complete. The findings file is written at .imd-findings.json with five findings and a 19-row coverage record. No repository file was changed. The scratch tests were removed.

What I kept, after reproducing each against the code

• Medium, hard-coded body keys. The owner key is appended by bodyOf outside the template, and no setter can remove it or change the key set. I ran the specialist's proof and it fails with the exact bytes they quoted. The reference's own job.open hub template carries no owner key. Admission of that key stays unverified since the public checker returned 404 from three hosts. Three specialist reports merged into this one.
• Medium, margin extractable by sandwich. I reproduced the attack on the vendored v4 PoolManager with a 0.05% pool. The hub's surplus fell from about 2.49 IMD to 0.03 IMD and the attacker netted ETH. With a 0.3% pool at the same depth the attacker loses, so the loss is conditional on pool fee and depth. The only floor is a compile-time constant plus a buyer-chosen minimum.
• Low, result URI over 192 bytes reverts the callback. The hash is lost and the request stays Pending forever. The project's own test asserts this state. Two reports merged.
• Info, surplus IMD has no exit path. The brief says the extra stays in the contract, so this is a design confirmation for the requester. Four reports merged.
• Info, owner trust assumptions. Documented powers, not bypasses. Users are protected by the configuration version check.

What I checked myself beyond the specialists

The swap callback guards, settlement order, delta checks, callback namespacing, the per-user account isolation, JSON text validation, contract sizes, and the manifest all hold. The full suite passes with 77 tests. The static analysis leads were either covered by the findings above or did not reproduce.

Open item for the author. Before sales, run the exact bodyOf output through the protocol's real request checker. That answers whether finding 1 is a latent total loss per sale or only a configurability gap.

I fixed the three code findings and answered all five in .imd-responses.json. forge build, forge fmt --check and forge test (with the verifier's fuzz seed) all pass: 50 tests, up from 44. Runtime size is 17,925 bytes, under the 24,576 limit.

I reproduced every finding before changing anything, and the numbers matched the reviewer's exactly.

Fixed:

• Body key set was fixed in the code (medium). A template is now the owner's JSON pieces with gaps, as in the reference hub. Each gap is filled with either the caller's words or the caller's address.
  • The default body still includes "owner", because the brief asks for the owner to be passed.
  • The owner can switch to the reference body without owner with one setTemplate call. A test confirms those exact bytes reach the Intake, still paid from the caller's own account.
  • Templates must have exactly one words gap, at most 8 gaps and 8,192 bytes, which keeps every body under the Intake's 16 KiB limit. Words are still rejected if they contain a quote, a backslash or a control character, so they can't add keys.
• Sandwich on the retained IMD (medium). I added an owner-set minimum IMD per purchase, imdFloor. It starts at 0.5 IMD and can't go lower, and changing it bumps the configuration version. Purchases now require at least the largest of the buyer's minimum, imdFloor and the live Intake price. A new test replays the reviewer's attack on a 0.05% pool with the floor at 2.36 IMD: the sandwiched purchase reverts, and the attacker ends with less ETH than they started with.
• Long result URIs left requests stuck (low). The result callback now always marks the request done and stores the result hash. A URI longer than 192 bytes isn't stored but is emitted in full in the event; a 4,096-byte URI is tested within the Intake's 200,000-gas callback limit.

Disputed, with no code change:

• Surplus IMD can never leave the contract (info). The brief says "extra stays in the contract", so I didn't add a withdrawal. The README now states the IMD is locked permanently, and that adding an owner withdrawal before launch is the requester's call.
• Owner trust assumptions (info). These are intended powers. The README now spells them out, including that renounceOwnership can't be undone.

Still open before sales:

• owner key unverified. I couldn't confirm the Intake accepts owner on job.open. The request checker still isn't reachable: identity.md is an unrelated site returning 404, two subdomains gave no answer, and www redirected. The operator should send a sample body to the real checker first; if it refuses owner, the README gives the exact call to remove it.
• Floor must be set after the pool. Until the owner raises imdFloor, only the 0.5 IMD minimum applies, so the sandwich risk stays open. The README's "After launch" table explains how to set it from a price quote and when to update it.

Tests that used the old template format were updated, and one that asserted the old stuck-request behaviour was replaced. Changes are in src/WebsiteBuyer.sol, the two test files, README.md and SECURITY.md.

I left launch.json unchanged: it already matches the accepted code, and this round came with no findings to fix. forge build succeeded and forge test passed all 50 tests.

What I checked against the code:

• One contract. WebsiteBuyer is the only contract the manifest lists. Its constructor is (owner_, intake_, imd_) at src/WebsiteBuyer.sol:153, and the manifest fills it with $owner, the Intake v2 address 0xa43e6f75ee006411f79ac1c84120606c2330de82, and the IMD token 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7. That token address is the same one the existing deployment test uses.
• IntakeAccount is not listed, which is correct. WebsiteBuyer creates one for each user on their first purchase, so it isn't a separate deployment.
• Starting settings match the brief. The price starts at 0.003 ETH and the job is job.open@job-1. The website body template is built in the constructor and adds the buyer's address as the site's owner.
• Notes are accurate. They say purchases will fail until the owner sets up a Uniswap v4 ETH/IMD pool, since the contract starts with none. They also say the local tests haven't checked live pool liquidity or whether the Intake accepts the request body.

I updated the test suite for the implementation's new template format, and forge test now passes with the verifier's fuzz seed: 83 tests in 8 suites, none failing. That includes both invariant tests, which ran 256 random call sequences of 16,384 calls with no reverts.

The build had broken because src/WebsiteBuyer.sol changed after my last round. Templates used to be set as a prefix, a skill and a host flag. They are now a list of JSON text pieces with gaps between them, each gap filled by either the caller's words or the caller's address.

Changes:

• test/helpers/SiteTemplate.sol (new): a small helper that builds the brief's website template in the new format. Both the edge tests and the invariant handler use it.
• test/WebsiteBuyerEdges.t.sol:
  • The test that changes every setting and checks an earlier quote is refused now sets the template the new way.
  • The template-limits test now checks the new rejection error, InvalidTemplate. It covers a template with no gap for the caller's words, one over the 8,192-byte limit, and one whose piece and gap counts don't match. Each rejection leaves the stored template and the configuration version unchanged.
  • The maximum-length test fills the template close to the 8,192-byte limit and adds 2,000 bytes of words. The body still parses as JSON with the user's address as owner and stays under 16 KiB.
• test/invariant/WebsiteBuyerHandler.sol: the random sequences switch the template's host flag and enabled state through the new format. The invariant now compares the stored template's text instead of a host field that no longer exists.

I found no new defect in the changed code, so I did not write a .imd-findings.json. I left test/README.md as it was.

All three fixes hold and no new defect reproduced. The findings file reports an empty list with full coverage.

Settled findings

• Owner key compiled in (medium): fixed. A template is now owner JSON parts around Words and Caller slots. My scratch test confirmed one setTemplate call yields the reference body byte-for-byte without the owner key, the key set can be reshaped, and words with a quote still revert. Default template 0 keeps the caller as owner per the brief. Live checker admission of that key remains unverified and the README says so.
• Surplus sandwich (medium): fixed. I replayed the 0.05% pool scenario on the vendored PoolManager. With the deploy-time floor the 1.3 ETH front-run still extracts the surplus, which is expected since no pool exists at deploy. With the floor at 2.36 IMD the sandwiched purchase reverts, the searcher ends below their starting ETH, and the honest purchase clears. Residual loss is bounded by the owner's tolerance and documented.
• Long URI strands the request (low): fixed. The callback always stores the hash and sets Done, stores the URI only when it fits, and emits the full URI. 193 and 4096 byte URIs settle under the 200,000-gas stipend.
• Locked surplus and owner trust assumptions (info, disputed): both reproduce as described and match the brief's stated design. The README documents them. No finding.

Fresh pass on the changed code. I checked template bounds against the Intake's 16 KiB limit, reentrancy through hooks and the Intake during the swap and ask, callback namespacing, the manifest shape, and contract sizes. Nothing reproducible. Full suite passes (83 tests). Scratch files were removed and the tree is unchanged apart from the findings file.