• highfidelity: the required 0.5 IMD deposit gate is unavailablesrc/App.tsx:579

  Now: The store, workshop and listing form are available to a disconnected visitor. The access dialog explicitly says deposits are unavailable and its deposit button is permanently disabled; there is no verified-access state guarding these routes.

  Change to: Make the existing access screen the entry state for visitors without a verified minimum 0.5 IMD deposit, enable the specified deposit flow, and open the three marketplace sections only after confirmation. Preserve both supplied IMD purchase links and the distinction between wallet balance and deposited funds.

  Why: The brief requires users to connect and deposit at least 0.5 IMD before viewing anything. This is an acknowledged missing requirement, not a failed wallet signature or a concealed mock.

  At 390×844 in a fresh Chromium context with no wallet or stored state, open /.

  The catalog renders eight hooks; #workshop and #list also open directly.

  Choose How it works → View access details.

  Actual: “Live deposits are not available yet” and Deposit unavailable has disabled=true.

  Expected: an actionable access gate with confirmed-deposit enforcement before catalog/workshop access.

  No transaction needs to be signed to observe the missing implementation.

• highfidelity: hook creation never calls the IMD swarm or produces a v4 hooksrc/Workshop.tsx:63

  Now: Generate preview synchronously runs planBlocks, a six-regex keyword matcher in src/domain.ts, and advances to a generic concept diagram. Download concept exports JSON metadata; there is no generated contract, IMD API request or 0.5 IMD creation charge.

  Change to: Replace the local planner completion with the specified IMD swarm generation flow, show its pending/error/retry states, charge the disclosed 0.5 IMD through that service, and use the returned hook and liquidity flow in the preview and listing steps.

  Why: The brief asks users to prompt IMD’s API to create their own v4 hooks for 0.5 IMD. A disclosed concept planner does not fulfill executable hook creation.

  At 390×844, open #workshop, select Use an example prompt, then Generate preview and Download concept.

  Actual: immediate “Local concept preview ready.

  No IMD was spent”; downloaded hook-concept.json has kind=hooks-store-concept with prompt/blocks/permissions but no executable hook.

  The entire catalog→unlock→generation→listing walkthrough made ten GET requests for local HTML/JS/CSS/font/art files and zero API or payment requests.

  Expected: IMD generation output and a completed creation-payment state.

  whole reproduction

• highfidelity: listings, routed-volume rankings and seller payouts have no live marketplacesrc/App.tsx:85

  Now: Publishing only appends a Hook to React state and localStorage. Another browser cannot find it. The $5 listing price and creator share are informational, no fees route to a wallet, and the five featured volumes come from hard-coded CATALOG records rather than marketplace usage.

  Change to: Publish the existing listing form’s hook, creator identity, fee recipient and chosen percentage to shared marketplace storage after the specified $5 settlement; read that same published catalog for all visitors, rank its top five by actual routed volume, and fulfill the displayed creator-fee routing terms when a listed hook is used.

  Why: The brief requires listings browsable by everyone, a $5 listing cost, peer-to-peer hook use with fees routed to the creator, and featured hooks ranked by real routed volume. Browser-local records and sample statistics are transparently disclosed but leave these requirements missing.

  whole finding

  At 390×844, finish the example workshop, Continue to listing, enter name ReviewHook2026, description “A review concept for long term liquidity providers.”, share 0.5, and fee recipient 0x3333333333333333333333333333333333333333.

  Publish demo listing.

  Actual: own store search returns one listing and the toast says no fee was charged.

  In a second fresh 1440×900 browser context at the same origin, search ReviewHook2026: result count is 0 and No hooks found is shown.

  The initial featured record remains Evergreen at sample volume $12.4M.

  Expected: a paid public listing available to the second visitor, real ranking data and implemented seller settlement; no wallet-signature failure is being alleged.

  whole reproduction

• highfidelity: the 0.1 IMD protected-view purchase is only a local unlocksrc/App.tsx:729

  Now: Unlock demo details adds the hook ID to client state/localStorage for zero IMD. The revealed content is a sample callback list, and there is no authenticated seller-code delivery or usable purchased hook.

  Change to: Make the existing protected-view action require the specified 0.1 IMD payment, verify the buyer’s entitlement before delivering private hook details, and provide the purchased hook for use. Keep the public benefit summary outside the paid response.

  Why: The brief requires buyers to pay 0.1 IMD to view sellers’ protected work and purchase hooks for use. The checkout honestly calls this a demo, so these are missing production capabilities rather than a transaction that could not be tested.

  At 390×844 without a wallet, open View Evergreen → Preview unlock · 0.1 IMD.

  Actual checkout shows Live viewing price 0.1 IMD but Due in this demo 0 IMD.

  Click Unlock demo details: beforeSwap and afterSwap appear, and localStorage hooks-store:unlocked becomes ["evergreen"] without a payment/API request.

  The panel says source code and deployment would be delivered by the live service.

  Expected: paid authenticated access to the seller’s actual protected hook and its use path.

• highfidelity: ASCII identities do not use IMD token profile generationsrc/components.tsx:233

  Now: AsciiAvatar calls the local avatar(seed) bit-pattern generator in src/domain.ts. Both hook and user identities are local placeholders; the listing preview expressly says live identities will use IMD later.

  Change to: Render and persist the ASCII profile returned by IMD token profile generation for the user and their hook in the existing profile, listing-preview and detail identity positions.

  Why: The brief explicitly requires IMD’s token profile generation for each user/their hook. Local deterministic art meets the ASCII appearance but misses the named service.

  At 390×844, open #list, enter ReviewHook2026 in Hook name and inspect the ASCII preview; then open a store hook’s creator identity.

  Actual labels say Local ASCII preview and Local ASCII identity, and no IMD request occurs. src/components.tsx:240 calls avatar(seed), whose implementation hashes the string locally.

  Expected: the corresponding IMD-generated user/hook profile, not a locally generated substitute.

• highbug: an accepted hook name breaks the library layout on phonessrc/styles.css:962

  Now: The library title is a flex child with its default intrinsic minimum width and no wrapping rule. A valid unbroken 48-character hook name expands the title to 724.875px and pushes its Local demo badge outside the card, widening the entire page.

  Change to: Set .card-title to min-width: 0 and overflow-wrap: anywhere, let the name wrap at its existing font size, and keep .card-title-row > .badge from shrinking. Reuse these rules for every user-supplied title rendered by this card.

  Why: The form explicitly accepts 3–48 characters. Critical names must remain readable, and the review bar prohibits horizontal scrolling and broken layouts at 320 or 390.

  At 320×844 in a fresh Chromium context, open #list.

  Enter Hook name as 48 consecutive W characters ("W".repeat(48)), description “A review concept for long term liquidity providers.” and retain share 0.5; Publish demo listing.

  Actual #library documentElement.clientWidth=320, scrollWidth=784; the 288px card contains a 724.875px title.

  At 390×844, clientWidth=390 and scrollWidth=786, with the badge pushed beyond x=760.

  The long-name screenshots visibly show the page extending horizontally.

  Expected: scrollWidth equals viewport width and the full name and badge fit within the card without clipping or shrinking the name.

  whole reproduction

• highfidelity: building with blocks alone is blocked by a mandatory promptsrc/Workshop.tsx:55

  Now: Generate preview always requires at least 15 prompt characters before it checks selected blocks or custom permissions. A user who builds through the working drag-and-drop controls cannot continue without inventing an additional text prompt.

  Change to: Allow generation when there is a valid prompt OR at least one selected property block OR a custom permission. Apply the minimum prompt length only when the prompt is the sole input, and preserve the error when all three inputs are empty.

  Why: The brief offers prompting, dragging and dropping properties, or custom configuration as alternative ways to build a hook. The current validation makes prompting compulsory even for a completed block-based concept.

  At 1440×900 in a fresh Chromium context, open #workshop, leave What should your hook do? empty, scroll down 500px so Dynamic fees and Your building blocks are both visible, and drag Dynamic fees into the drop area.

  Actual: the selected-block label becomes Dynamic fees and a drop event carries text/plain=dynamic.

  Click Generate preview: it stays on Build your hook with “Describe your hook in at least 15 characters, or use the example prompt.” Repeat by selecting only beforeSwap under Customize v4 permissions: the same guard fires.

  Expected: the selected block or permission is enough to enter Preview the flow without a prompt.

  whole reproduction

• mediumbug: New releases silently ignores both alternative sort choicessrc/domain.ts:271

  Now: The comparator prioritizes tab=new over filters.sort, while the visible Sort by selector remains enabled. Choosing Name: A–Z or Lowest creator fee changes the selector but never changes the list.

  Change to: When filters.tab is new, replace the enabled Sort by selector with the plain label “Newest first”; keep the existing selector on the other tabs. This makes the visible ordering label agree with the fixed release-date comparator.

  Why: Controls must change the results they label. Users comparing hook names or creator charges currently receive an order that contradicts their selection.

  At 390×844 or 1440×900, open /, use the New releases button in the browse tabs, then select Name: A–Z in Sort by; next select Lowest creator fee.

  Actual order remains Evergreen, Sentinel, Orbit, Stream, Gridline, Grove, Echo, Canopy for all three states.

  Expected alphabetical order starts Canopy, Echo, Evergreen; lowest-fee order starts Canopy (0.1%), Grove (0.15%), Gridline (0.2%).

  Confirmed in Chromium; no wallet or payment is involved.

• mediumbug: changing featured hooks moves the carousel controls and following contentsrc/styles.css:2649

  Now: Featured details use content-dependent height, so summaries with different wrapping move the navigation controls and every following section on each slide. The same component also provides no arrow-key or swipe handling.

  Change to: Reserve the tallest required featured-details height at each existing breakpoint while allowing longer text to grow without clipping, so the five normal slides keep the controls fixed. Wire Left/Right and horizontal swipe to the same slide-selection handler as the existing arrow buttons.

  Why: The supplied carousel checklist requires a stable height and arrow-key/swipe navigation. Moving the control under the visitor’s finger makes browsing the five ranked hooks harder.

  At 390×844 on /, advance from Evergreen to Sentinel with Next featured hook.

  Actual featured-card height changes 645.766→623.375px; carousel controls move from document y=1163.766 to 1141.375 and the following section moves 1231.766→1209.375 (22.391px).

  At 1440×900, changing Orbit to Stream increases card height 399.375→421.766px.

  Focus Feature Evergreen and press ArrowRight, or swipe left across its art at 390: the selected hook stays Evergreen.

  Expected: the normal slides keep one height and these navigation inputs select the adjacent hook.

  whole reproduction

• mediumtaste: five competing slogan blocks replace useful store labelssrc/Store.tsx:334

  Now: The catalog spreads five two-beat slogan blocks across its intro, spotlight, workshop promotion and sidebar. “A little edge. A lot of possibility.” does not identify the hooks beneath it, while the sidebar repeats ownership/commission claims already stated in the footer. The desktop demo banner adds another filler phrase and em dash.

  Change to: Keep “Good hooks. Better pools.” as the signature headline. Replace the spotlight heading with “More hooks to explore” and the workshop-banner heading with “Create a Uniswap v4 hook”. Delete the .sidebar-note block and its reserved spacing so the sidebar ends after Networks. In App.tsx replace the demo-extra text with “ · No funds move.”, retaining the disclosure.

  Why: The copy checklist permits at most three slogan blocks and asks task-oriented section labels. These cuts retain the brand voice, necessary cost disclosures and existing actions while reducing competing copy.

  whole finding

  At 1440×900, load / and scroll through the sidebar and store sections. taste@1 slogans reports 5: “Good hooks.

  Better pools.”, “A little edge.

  A lot of possibility.”, “Big idea?

  Build it.”, “Built by people.

  Owned by you.”, and “Peer-to-peer hooks.

  No platform commission.

  Your keys, your liquidity.” The glyphs check reports the desktop demo-extra em dash.

  The full-page screenshot confirms these are authored interface copy, not quoted listings.

  Expected: one signature headline and concrete section labels, with no duplicate sidebar promotion.

  whole reproduction

Failed in the task.