All the audit follow-ups and the IMD integration are in place. forge build, forge test and forge fmt --check pass. That is 80 tests (the original 39 unchanged), run with both the pinned seed and the verifier's seed. Nothing was deployed and no paid request was submitted. The Python SDK tests fail here with "local transaction failed", and they fail the same way on the untouched foundation commit, so the cause is this environment rather than these changes; I couldn't run them.

Audit fixes

• Chain-rejection test: the old test is kept. A new one (test/AuditFixes.t.sol) checks Ethereum, Base and Robinhood mainnets, plus random unknown chains, on every release path: factory constructor, deploy, both scripts and the shared deployment code. A deploy with a correctly matched spec still gets refused, so only the chain policy can be what stops it. The allowed testnet IDs deploy and verify end to end in local simulation.
• Checksum evidence: lib/SHA256SUMS holds the upstream hashes. I re-downloaded all 80 upstream files and they match those hashes. But 18 files actually in lib/ differ from upstream. Each difference is exactly what forge fmt produces from the upstream file, and the bytecode compiled from either version is identical. lib/ is protected, so I left it and put the corrected evidence in docs/checksums/. script/verify-vendored.sh checks it offline. docs/DEPENDENCIES.md corrects the earlier "copied unchanged" claim.
• Salt mining: the audit finding is real. A full 131,072-candidate page costs about 46M gas, above common eth_call caps. A page now stops early when gas runs low and returns the nonce to resume from. With too little gas for even one candidate it reverts InsufficientGas. A search capped at 10M gas per call finds the same salt as an uncapped one. The Python SDK accepts these shorter pages.
• Mainnet restriction: the restriction belongs to this factory release, not to the hook. The hook constructor only requires the spec's chain to match the chain it runs on. A later reviewed factory release can allow mainnet without changing the hook, its bytecode or the spec, so nothing is permanently blocked. A test shows a hook deployed directly on chain 1 is not recognised by the Store's factory.
• Swap limit: I decided it caps only amountSpecified, not both sides. Capping both would break existing passing tests and change the hook's bytecode. A test shows an exact-output swap at the limit paying more than the limit in input. The reasons are in the README.

IMD integration (src/imd/HookJobRequester.sol, details in docs/IMD_INTEGRATION.md)

• Opening a job: the creator's wallet approves IMD to the contract and calls openJob, which places an Intake v2 requestWithFailure job.open. The owner's body template must name forge build, forge test and adversarial review. The creator's text is validated and quoted as untrusted data.
• Tracking and callbacks: jobs are tracked by the Intake's request ID. Result and failure callbacks are accepted only from the Intake, only for this contract's own open jobs, and only once. Each job and each review request has a deadline after which its requester can expire it.
• Review status: "passed" can only come from an IdentityMD oracle answer signed for this contract, with minimum panel size and agreement. It is checked against the protocol's test vector. Nothing ever shows "audited".
• Status page: site/index.html reads job status straight from the chain over JSON-RPC, with no backend and no call to api.imd.fun.
• Tests: all of this is tested against a mock Intake, including replay, wrong sender, forged, tampered, expired or weak-panel answers, deadlines and the 200,000-gas callback limit.

Blocker and what needs a live pilot

• Review status: without the oracle step, a static site cannot tell whether review passed. The job completion from the Intake is unsigned and carries no verdict.
• **job.open details