Appearance

Consumer Marketplace Spec ​

Status

🟢 Specification approved 2026-08-10. ⚠ SUPERSEDED IN PART, 2026-08-20: the screens NOW EXIST. The Claude Design prototype project carries prototype/marketplace/{Discover,Browse,Item}.dc.html (rounds 20, 29 and 30), so the sentence below is no longer true and the two prompts are no longer send-ready. Round 30 also added ratings and a photograph-dominant grid, neither of which the schema can supply - see Desktop journey readiness for the measured delta and the corrected prompt. Read the sections below as the approved REASONING, not as current status.

Original banner: Screens do not exist yet in the Claude Design project. The two prompts in §7 and §8 are send-ready. Findings and decisions: QRS-490 … QRS-507.

1 · Purpose and the user category it serves ​

The Marketplace is the consumer-side half of QRSETU. Everything designed until now is the merchant side, and this is a different person: category 3, an individual consumer who owns no business. Zero workspaces, no store, no catalogue, no dashboard metrics. They arrive either by scanning a vendor's QR code or by opening the app to find local businesses.

Why it exists, and the honest version of the argument (QRS-490): it is what makes a vendor's Setu Card worth more than a page they already had. But on day one there are zero registered consumers, so the promise is "you will be found in searches for your area" (true from the first crawl, delivered by the public web twin) and not "our consumers will find you" (false until they exist). Both surfaces are needed and they are not alternatives: the public web directory is acquisition, the in-app Marketplace is engagement and retention.

2 · The information architecture, and the decision behind it ​

Discovery mode is a property of the INDUSTRY, not of the archetype (QRS-505). Archetype determines the action verb; it does not determine what the consumer forms an intent about. goods is item-first, time is vendor-first, and expertisesplits (a property is item-first, a tutor is vendor-first), so a single industries.discovery_mode config column carries it and no screen branches on an industry name (ADR-0021 D4).

The unfiltered landing is CATEGORY-first, which is neither vendor nor item. A mixed grid of idols, haircuts, properties and gold chains is not a product; a category grid is. Choosing a category enters that category's declared discovery mode.

LANDING       location + search + CATEGORY tiles          (never mixed results)
   |
   v  choose a category
CATEGORY      discovery_mode = 'item'    -> faceted ITEM feed
              discovery_mode = 'vendor'  -> VENDOR tiles
   |
   v
ITEM DETAIL  <->  VENDOR VIEW  ->  "View full card" (real branded card, in-app browser)
   |
   v
ORDER / ENQUIRE

Search cuts across both and groups results by type ("12 idols · 3 stalls").

Launch shortcut is config, not a second design

With one live industry the category grid is a single tile, which looks broken. So at launch the app opens directly into the festival-stall item feed via a featured-category flag. Same screens, different entry point. The scalable architecture is designed once and the launch takes a shortcut through it.

The transition rule (QRS-505): item detail is terminal and transactional; the vendor view is a browse destination, never a gate. Three hops before a purchase loses buyers, so where the item is the decision the item page carries vendor trust inline (name, area, verification, hours, collection point) and the buyer can act without leaving it.

3 · Entry points ​

PathContainerRenderer
Physical QR scanned with any cameramobile browserthe real branded Setu Card, server-rendered (apps/web)
App → Marketplace → vendornative appthe in-app vendor view, native components (QRS-501)
Search engine → area pagemobile browserthe public directory twin, server-rendered

4 · Data contract ​

Reads go through two separate projection functions, never one with a mode flag (QRS-506) — a vendor feed is ~one row per vendor per area, an item feed is ~1,500 rows per vendor across every vendor in the area:

  • get_marketplace_vendors(pin_code, industry_key, …)
  • get_marketplace_items(pin_code, industry_key, facets, sort, page, …)

Both are security definer projections, matching the two existing public reads. No policy may be widened to TO authenticated: consumer isolation is structural because my_workspace_ids() returns empty for a consumer, and one using (true) would hand the logged-in public every draft card (QRS-491).

Location is pincode-first (QRS-492): pincode is the canonical key, city and area are derived labels, and coordinates sort but never filter. expo-location is not a dependency, so "near me" is a new permission and a new divergence seam with a mandatory decline path (QRS-500).

Freshness splits by surface (QRS-506): the in-app item feed is a live query (short staleTime) because an item disappears the moment it sells; the public web pages stay server-rendered and purge-on-write.

5 · Permissions and the registration wall ​

Browsing, searching, filtering, opening a vendor and viewing a catalogue all work with no account. Registration is demanded only where identity is genuinely required: placing an order, sending an enquiry, saving a business, paying. It is an inline step in a flow the consumer already started, never a wall in front of browsing. orders.buyer_user_id is a nullable account reference, so anonymous-until-needed is structural rather than a rule someone must remember.

6 · R1 action set ​

Only orders exists. chat, messages, bookings, appointments, enquiries and parties are all absent from the schema, and notification transport is broken on every channel (QRS-504).

ActionR1
Order✅ in
Enquire✅ in (table owed before implementation)
Payafter payout_accounts lands
Chat, Book❌ absent from the designs, not disabled

A control that dead-ends teaches a non-technical user that the app is broken. This is the same rule already recorded for the merchant action launcher.

7 · Prompt A: consumer home and discovery ​

Copy the block below verbatim

Send to the prototype project 633dc069-6df8-4408-b625-068907c60c33. Tokens and component contracts come from the design-system project 37245d93-4fa1-42d0-b765-53a7664d5129.

text
Use the claude_design MCP to work in project 633dc069-6df8-4408-b625-068907c60c33.

Design the CONSUMER side of QR Setu. Every screen in this project so far is the merchant side.
This is a different user and a new surface.

WHO THIS IS FOR
QR Setu serves three user categories. This is CATEGORY 3: an individual consumer who owns no
business. Zero workspaces, no store, no catalogue, no metrics. They arrive by scanning a vendor
QR code, or by opening the app to find local businesses.
Do NOT reuse the merchant Dashboard's information architecture. The merchant Dashboard answers
"what is the state of my business" and is metric led. This surface answers "help me find
something" and is search led and image led. Use the merchant Dashboard ONLY as a design system
reference: tokens, card shells, radius, type scale, sheets, motion.

THE INFORMATION ARCHITECTURE IS FIXED. DESIGN TO IT, DO NOT REDESIGN IT.
  LANDING        location + search + CATEGORY tiles. Never mixed results.
  CATEGORY       an industry whose discovery mode is "item" opens a faceted ITEM feed.
                 An industry whose discovery mode is "vendor" opens VENDOR tiles.
  ITEM DETAIL    reachable from the item feed. Transactional and terminal.
  VENDOR VIEW    reachable from a vendor tile or from an item. A browse destination.
Discovery mode is per industry configuration, not per screen logic. Ganapati idols, jewellery,
properties and cars are item first. Salons, restaurants and yoga are vendor first.

SCREEN 1: CONSUMER HOME
Four states, all designed:
  a) First run, no location set, anonymous. The single primary action is choosing an area. Do not
     show an empty dashboard and do not show zero states for things the consumer has never done.
  b) Location set, anonymous. Category tiles, one prominent search entry, and a small strip of
     nearby businesses or featured items.
  c) Registered, no activity. As (b), plus a "saved" surface that is empty and says what saving
     is for.
  d) Registered, with activity. Timely, dismissible action items derived from real stored state,
     for example "your order is ready for collection", "a business you saved added new items".
     These must never be fabricated: with no data the surface is simply absent, not a placeholder.
ALSO design the LAUNCH VARIANT of this screen: when only one industry is live, the category grid
is skipped and the home opens directly into that industry's item feed. Same components, one
featured category, different entry.

SCREEN 2: ITEM FEED (the festival stall case, and the pattern for every item first industry)
  - A real Ganapati stall carries 1400 to 1500 idols in a four week season, priced from about
    1,000 to 40,000 rupees. The vendor's single biggest complaint was browsing: "idols are too
    much, so the end user should have very flexible filters and sections, and not the same size
    of grids. Small, medium, large grids with placements in various zigzag patterns."
  - So design a MIXED SIZE MASONRY grid, not a uniform two column one. Large clear images in
    detail: buyers are emotional and choose on the photograph.
  - Filters as chips that open a bottom sheet. For this industry the real filters are HEIGHT,
    MATERIAL, STYLE and PRICE BAND. Design the sheet so the filter SET is data driven and varies
    by industry, never hardcoded per screen.
  - Sorting: nearest first, then most recent. Design the control, keep it boring.
  - Reserve ONE clearly LABELLED promoted slot position in the feed and render nothing in it.
    Do not design a sponsored card treatment beyond the label.
  - An item that sells DISAPPEARS from the feed. There is no restock and no "sold out" tile.
  - Every item tile carries the VENDOR NAME and AREA. This is not a footnote: it is how a buyer
    knows who they are buying from, and it is legally required seller identification.
  - Price states: a price, a "from" price, and "price on enquiry" as a first class state rather
    than an empty field.

SCREEN 3: VENDOR FEED (for vendor first industries such as salons)
  Minimal vendor tiles: business name, area, industry or category, image or logo, and a short
  availability or summary line. Primary action opens the vendor view.

TILE ACTIONS COME FROM THE ARCHETYPE, NOT THE INDUSTRY. There are exactly three archetypes and
therefore exactly three tile variants. Do not design per industry tiles: fourteen industries map
onto these three.
  GOODS      idols, jewellery, cars       primary action ORDER
  TIME       salon, yoga, restaurant      primary action BOOK
  EXPERTISE  real estate, tutors          primary action ENQUIRE

R1 ACTION SET, A HARD CONSTRAINT
Only ORDER and ENQUIRE exist. CHAT and BOOK must be ABSENT from these designs. Not present and
disabled, not "coming soon". A control that dead ends teaches a non technical user that the app
is broken. For the TIME tile use ENQUIRE for now and note where BOOK will slot in later.

ANONYMOUS FIRST, NON NEGOTIABLE
Browsing, searching, filtering, opening a vendor and viewing a catalogue all work with no
account. Registration is required only at ordering, enquiring, saving and paying. Design that
moment as an inline step inside the flow the consumer already started, never as a wall in front
of browsing.

LOCATION
Pincode or area chosen from a LIST is the default and primary path. Do NOT design a map view and
do not make a map the browse surface. "Use my current location" is an optional secondary
affordance that must degrade gracefully when the permission is declined, so the pincode path is
never a fallback.

STATES: loading, empty, error and partial data for every screen. Empty states propose the next
action rather than describing the screen. The most important one is "no businesses in this area
yet", which will be common at launch and must not read as a broken app.

CONSTRAINTS
  - Native app screens for Android, iOS and a responsive web build from the same code. Must work
    at 360px wide.
  - Light AND dark themes are both mandatory.
  - Zero hardcoded colours. Use the QR Setu semantic tokens only.
  - Apple style soft corners: rounded-3xl outer shells, rounded-2xl inner panels.
  - The wordmark renders lowercase "QR setu" with "QR" gradient filled, in the Akaya face. One
    brand gradient only, for brand identity and emphasis, never as a flat accent.
  - DO NOT USE EM DASHES OR EN DASHES in any copy, label or example. Use a comma, a colon,
    parentheses, or two short sentences.
  - No in-app purchase or upgrade CTA anywhere on the consumer surface.
  - No WhatsApp CTA. QR Setu has its own ordering and enquiry flows.
  - No UPI promotion, no vendor UPI ID, no "Pay via UPI" anywhere.

DELIVERABLES: the three screens with every state above, the launch variant of the home, the three
tile variants, the filter sheet, the sort control, and the registration moment. Follow the
project's existing component vocabulary and the .prompt.md spec convention.

8 · Prompt B: item detail and the in-app vendor view ​

Send this only after Prompt A returns

Prompt B depends on Prompt A's tile and token decisions. Keeping them separate is deliberate: a single prompt covering five screens cannot be partially rejected, which is exactly how the previous card round had to be regenerated in full (§9 of the Setu Card spec).

text
Use the claude_design MCP to work in project 633dc069-6df8-4408-b625-068907c60c33.

Design the two screens a consumer reaches after discovery. Read the Marketplace screens already
in this project and match their vocabulary exactly.

SCREEN 4: ITEM DETAIL (a single Ganapati idol)
This screen is TERMINAL AND TRANSACTIONAL. The buyer must be able to order from here without
visiting the vendor first. It therefore carries vendor trust inline: business name, area,
verification state, stall hours, and where collection happens.
  - Large detailed imagery is the product. A swipeable gallery with momentum, plus video where
    the vendor has posted reels. Vertical short video, stall and idol footage, not craft
    documentary.
  - Specifications as the four attributes buyers actually choose on: height, material, style,
    price. Show them as structured facts, not prose.
  - Availability is a single unambiguous statement. Sold means gone, with no restock.
  - Booking an idol takes a minimum 10 percent advance and the advance is NOT REFUNDABLE if the
    buyer never collects. That term must be visible AT THE POINT OF PAYMENT, in the vendor's own
    words, not buried in a terms page. This is a legal disclosure requirement, so design it as a
    calm, readable, unmissable part of the flow rather than fine print.
  - Primary action ORDER. Secondary action: open the vendor.
  - Do NOT design a "compare sellers", "other sellers" or price comparison element. Every idol is
    a unique piece; there is no equivalent item at another stall.
  - No WhatsApp CTA. No UPI. No em dashes.

SCREEN 5: IN-APP VENDOR VIEW
This is NOT the vendor's branded Setu Card and must not try to be. The branded card is a web page
rendered from the vendor's chosen template. This screen is QR Setu's own consistent presentation
of the same vendor data, so that a consumer comparing twenty vendors gets consistent navigation
and so the transactional flows can be native.
  - It honours COMPOSITION and BRAND: which sections the vendor has and in what order, plus their
    logo, cover image and palette accent colour.
  - It does NOT honour fine presentation: no per template layout variants, no decorative motifs,
    no bespoke type treatments.
  - Design ONE canonical native presentation for each of these section types, and design each so
    it simply does not render when the vendor has no content for it:
      header (logo, cover, business name, tagline, area, verification)
      catalogue (the vendor's items, reusing the masonry grid from the item feed)
      gallery (photos and reels)
      about
      hours
      contact (call, directions, save contact)
      links (social links, small, below the address details, in original brand colours)
  - A section type this screen does not recognise is SKIPPED silently.
  - There is a persistent, clearly secondary action: "View full card", which opens the vendor's
    real branded Setu Card in an in-app browser. Design what that affordance looks like so it
    reads as "see their full page" and not as an error or an exit.
  - Primary action follows the vendor's archetype: ORDER for goods, ENQUIRE for expertise. CHAT
    and BOOK are ABSENT.
  - States: loading, a vendor with only a header and nothing else, and a vendor whose catalogue
    is empty.

CONSTRAINTS: identical to the Marketplace prompt. 360px wide, light AND dark, zero hardcoded
colours, rounded-3xl and rounded-2xl, Akaya wordmark, one brand gradient, no em dashes, no
in-app purchase CTA, no WhatsApp CTA, no UPI anywhere.

9 · Proactive-value answer ​

What action it prompts. For a consumer, the returning-visit surface is state they already own: an order ready for collection, a saved business that added items, a booking tomorrow. What makes it timely is that all three are dated facts, not scores. Where the intelligence comes from: stored rows only. With no data the surface is absent rather than a placeholder, because a recommendation with nothing behind it is worse than silence.

And the merchant-side payoff, which is the vendor's reason to care: appearing in area searches is measurable, so "you appeared in 40 area searches this week" becomes a merchant-app insight reading the same event stream. That is the vendor pitch made checkable instead of rhetorical, and it needs the analytics that do not exist yet (QRS-349).

Parity status ​

Not implemented, so nothing is verified. When built, this is apps/mobile and therefore ships to Android native · iOS native · Web PWA together, with no exception path. Divergence seams to declare at G0 (QRS-297): location permission (expo-location is not currently a dependency, and navigator.geolocation on web needs HTTPS and is refused by some browsers), the in-app browser for "View full card" (Custom Tabs vs SFSafariViewController vs window.open), and share. The public web twin is apps/web and inherits Stack 1's structural parity.