Flow gap (periphery x first principles). The brief specifies onFailure(bytes32,uint8,bytes32,uint16,uint16,bytes) as 'callable only by Intake, emits Failed(requestId, status, reason)' with no restriction on the status value. The Workshop adds a check that reverts for every status except 1 and 2.

The Intake delivers each callback once, inside a try with a 200k gas stipend, and does not retry a reverted delivery. Today the version 2 Intake sends only status 1 (refused) and 2 (no agreement), so nothing is lost at the moment; but the Workshop is immutable and the status is an unsigned, Intake-controlled enum that is appended to over time.

The first time the Intake reports a different terminal status (expired, cancelled, delivery failed), the Workshop silently drops it: the price was already spent, the work stays Pending forever, the gallery never learns the job ended, and nothing on the Workshop side can clear the entry. The check does not protect any funds: onFailure moves no value and the state transition Pending -> Failed is the same for every status, so the restriction only loses information.

Minimal fix: drop the status check (or restrict only status == 0 if a zero value must be excluded) and emit Failed with whatever status the Intake sends.

Invariant note, no funds at risk. The brief says the fee 'goes straight to the Workshop contract'. The hook pays during the swap, before the swapper settles, so the PoolManager must already hold at least fee IMD for take to succeed.

The launch factory seeds the SELF/IMD pool with SELF only (README: 88% of supply to the pool; no IMD), so on the very first buy the manager holds 0 IMD and the fee becomes a hook-owned claim rather than Workshop balance. The same happens whenever the pool's IMD reserve is below 2% of a buy's IMD input (e.g. after heavy selling).

Claims are safe (only redeemable to the fixed Workshop, anyone can call redeemFees()), but nothing redeems them automatically: Workshop.commission()/canCommission() read IMD.balanceOf(workshop) only, and the website shows the same balance, so deferred fees do not count toward the price + bounty threshold or the displayed balance until an external caller spends gas on redeemFees().

This is documented in the README and is acceptable under the brief; it is recorded so the gallery/keeper side plans for it (e.g. the site's commission button, or any keeper, calls redeemFees() first when the hook's claim balance is non-zero). An optional in-contract improvement: in _pay, when take succeeds and the hook already holds claims, burn and take those claims in the same unlock so later swaps sweep earlier deferred fees without a separate call.

Economic-security note, no code change requested. SelfToken is a plain ERC-20 with no transfer restrictions, and the brief explicitly forbids any (no max buy, no blacklist, no owner).

Consequently the 'every trade pays a small fee' funding loop only holds for trades routed through the hooked pool: anyone can initialize a second Uniswap v4 SELF/IMD or SELF/ETH pool without a hook (or a v3/v2 pool), and once that pool is deeper or cheaper (its traders save the 2%), routers and aggregators send volume there and the Workshop's income falls to the fee on whatever residual volume still crosses the hooked pool.

The hook's beforeInitialize only prevents other pools from using this hook; it cannot prevent pools that do not name it. This is inherent to a hook-fee design on a free token and is the trade-off the brief chose; it is recorded so the economics are stated plainly: Workshop funding is proportional to hooked-pool volume, not to SELF volume.

Seam: boundary x invariant. The invariant 'every hook fee lands in the Workshop in IMD' is kept only on the take() fast path. On the catch path the fee becomes an ERC-6909 claim owned by the hook and nothing in the hook ever converts it back: a later swap's _pay() only moves the new fee, even when the manager by then holds far more IMD than the outstanding claim.

The launch factory seeds the pool with tokens only, so at launch the PoolManager holds zero IMD and the very first exact-input buy (the launch's normal first trade) always takes this path. The only way out is redeemFees(), which pays no bounty, is not called by Workshop.commission(), and is not wired into the website (web/app.mjs only sends commission()).

Until someone volunteers, the Workshop balance, canCommission() and the site's 'Funding' countdown all understate the fees actually earned, and the brief's 'the fee goes straight to the Workshop contract' does not hold for those swaps. Funds are not lost (claims are only burnable to the fixed Workshop), so severity is low.

Minimal fix that preserves the design: in _pay(), when take() succeeds (or in afterSwap), also burn any outstanding hook claim up to IMD.balanceOf(poolManager) and take it to the Workshop, so claims self-heal on the next funded swap; keep redeemFees() as a fallback.

Area: Asymmetry (Step 6, a defensive check that should not exist) and Access Control (the guard is stricter than the caller it trusts). The brief defines the failure hook as 'callable only by Intake, emits Failed(requestId, status, reason)'. The Intake is the sole trusted caller, and the only thing the Workshop should check about the call is who sent it and whether the request is its own and still pending.

The extra whitelist on status means a failure the real Intake delivers with any status code outside {1, 2} (the oracle-consumer reference documents 1 and 2 today and does not promise the set is closed) reverts inside the Intake's single 200k-gas delivery attempt.

The Intake records the callback as not delivered and never retries, so the work order is stuck in State.Pending forever, the Failed event is never emitted, the gallery and works(i) show a job that is still in progress, and no on-chain record of the failure reason exists. onResult has no equivalent restriction on resultHash, so the two callbacks are asymmetric: one trusts the Intake's data, the other second-guesses it.

No funds are at stake (the price was already spent and failure callbacks never move value), which is why this is low.

Fix: drop the status check (or only emit it as data), keeping onlyIntake and _pending as the sole guards, so every failure the Intake reports is recorded exactly as the brief specifies.

Area: Access Control / Asymmetry. The brief says onResult 'stores the result and emits Built' and 'must use little gas (under 150k)'; it names no URI cap. The Workshop adds a 2,048-byte cap so the 150k budget holds for every accepted input, which is a reasonable engineering choice and is documented in the README.

It is recorded here because of its failure mode rather than as a defect: the Intake attempts delivery once under a 200k stipend and does not retry, so a result whose URI exceeds the cap reverts inside that attempt and the work stays Pending forever with no Built event, even though the price was paid and the job completed.

Whether a real job.open delivery URI can exceed 2,048 bytes is a property of the Identity.md plane that could not be verified from here (the Intake source is not published on the explorer without an API key). If the plane ever delivers a long URI (for example a data: URI or a gateway URL with a long path), that work is lost from the gallery.

The author should confirm the plane's maximum URI length with Identity.md, or raise the cap to what the 150k budget allows (the measured worst case at 2,048 bytes leaves headroom).

Execution trace across the request/deliver boundary. Workshop.commission() spends the Intake price, then the only way a work order leaves State.Pending is a call from the Intake to onResult or onFailure. onResult reverts for any URI longer than MAX_URI_BYTES (2,048 bytes) before it reaches _pending, so if the network delivers a longer URI the delivery call fails, no Built event is emitted, the work stays Pending with its price already spent, and the gallery never shows it.

The bound is tighter than the gas budget that motivated it: on a Robinhood Chain fork the live Intake's callbackGas() is 200,000, and a cold-storage onResult with a 2,048-byte URI measured 136,184 gas, so a URI of roughly 3,000 bytes would still fit the Intake's budget yet is refused.

The brief fixes no URI length, and nothing in the Workshop can retry or re-request a rejected delivery; the same permanent-Pending outcome follows for onFailure with any status other than 1 or 2 (src/Workshop.sol:120), though the supplied references document only statuses 1 and 2.

This is a liveness gap under a specific, externally controlled input rather than a loss of funds beyond the one price already paid; it is reported so the author can confirm with Identity.md that job.open delivery URIs are always short (a URL or content identifier) or raise the cap toward what 200k gas affords.