Direct seller vertical — specification for Claude Design

The design specification for the second QRSETU vertical, to be worked in the prototype project (633dc069-6df8-4408-b625-068907c60c33) in parallel with the Ganapati client implementation.

Read this beside the discovery brief, which holds the reasoning and the evidence. This page is the design contract: what to reuse, what to adapt, what is genuinely new, and what not to design.

Status — rewritten 2026-08-14 after the owner's workflow brief; all decisions confirmed the same day

🟢 Both prompts are send-ready. Prompt A (the decided delta: industry row, Home widgets, the leaner card, the compliance envelope) goes first. Prompt B (the Meetings module, the lead pipeline, the media library, team and group chat, My Progress, daily sales lite, the engagement layer) is also SEND-READY as of 2026-08-14 — every decision it embeds is confirmed (§6); send it after Prompt A completes, since B extends the industry row and journey file A creates. Mobile native first; the desktop adaptation follows only after the mobile journey is approved (owner instruction, 2026-08-14).

⚠ The first version of this page said the whole vertical was "one industry row, two widget registry entries, and one card block". That undercounted: it was written before the owner's workflow brief surfaced the daily session cadence and the ad-driven lead funnel (QRS-667 · QRS-668). The card-and-store delta really is that small; the vertical also needs one new platform module and one new pipeline surface, both reusable far beyond it.

0 · Standing constraints (unchanged, restated because a prompt is read in isolation)

• vendor-core.js is the domain core and is shared. A direct seller is an industry ROW in INDUSTRIES with its own caps, nouns and (absent) context. It inherits every widget, every status vocabulary and every derivation. Do not fork the core, and do not add a second dataset shape.
• Industry customisation changes CONTENT, never CHROME. Same tab bar, same centre button, same Quick tools grid, same radii, same motion. The centre grid resolves from CENTRE_NAV against this industry's caps and so changes by itself.
• New screens are SHARED, parameterised screens gated on capability — never industry screens. The Meetings module and the lead pipeline in Prompt B must work unchanged for a yoga studio or a tutor the day their caps turn on. A screen that only makes sense for a distributor has been designed wrong.
• No em dash anywhere in generated copy, labels, documentation or examples. Comma, colon, parentheses, or two sentences.
• Never volunteer a privacy reassurance at the point of use — state what the product does, not what it refrains from doing (QRS-549).
• Both themes, every screen. Light and dark, plus loading, error, empty and the screen's own edge cases.
• Copy is authored in English only; hi/mr are added on the implementation side through @qrsetu/i18n.

1 · The industry row

direct_seller: {
  id: 'direct_seller',
  label: 'Independent distributor',   // the neutral, brand-free description
  business: '<a fictional distributor name>',
  archetype: 'expertise',             // matches the seeded taxonomy; the card generates the
                                      // conversation, the sale completes off-platform
  // NO `context` key: this industry has no season. See §3.1.
  caps: [...UNIVERSAL_CAPS, 'store', 'store.media', 'daily_sales', 'chat',
         'meetings', 'leads', 'assets', 'team'],   // the last four are Prompt B's modules
  nouns: { item: 'product', items: 'products', listed: 'products listed',
           add: 'Add product', person: 'customer', people: 'customers',
           meeting: 'session', meetings: 'sessions' },
}

⚠ orders and payments are deliberately ABSENT from the caps. The commerce leg completes through the brand's official purchasing channel (discovery §1.2); QRSETU complements that ecosystem and never replaces it. Collections, OrderDetail, Payments and Banking therefore resolve away for this industry — that is the capability system working, not screens to adapt. The volume record that feeds reorder intelligence is the daily_sales manual record.

⚠ DO NOT NAME A REAL BRAND ANYWHERE — not in the industry key, the label, the demo business name, the product names, or the imagery. "Herbal Life" is how the owner described the vertical; it is a third-party trademark and must not enter the schema, the picker, a URL or a screenshot. Use an invented distributor and invented product names. The distributor's own brand affiliation is content they type, and on the public card it travels with the disclaimer in §5.

Suggested demo workspace: a part-time distributor working from home, twelve to twenty products across three or four categories (shakes, teas, protein, skincare), thirty to forty repeat customers, one daily online batch and two weekly wellness sessions run with their coach, a realistic reorder spread, and eight to ten tagged promo images.

2 · What is REUSED WITH NO CHANGE — do not redesign these

Present them in the journey so the prototype hub can walk it end to end, but change nothing. Each already resolves correctly from the industry row above.

Screen	Why it needs no change
Onboarding · BrandSplash · Auth	Industry-agnostic; the industry picker gains one row
Catalogue (Store)	Same countable-stock editor, simpler than Ganapati: no is_unique, no height/material facets. pricing_mode: on_enquiry already exists for price-on-conversation products
Messages · Thread	Unchanged. The away reply matters MORE here: a part-timer has a day job
Notifications · Settings · Profile	Unchanged
QRTools	Unchanged, though a printed QR matters less than for a stall
CardEditor	Unchanged mechanics; §5 adds one non-removable block state
PlanBilling · Analytics	Unchanged
Consumer ConsumerHome · ItemFeed · VendorFeed · ItemView · Chats · Account · Notifications	Correct as they are; ItemView's price-on-enquiry and absent-pay-CTA states are exactly this vertical's shape

3 · What is ADAPTED — Home and the card, and the adaptations are small

3.1 Home — replace the season strip with the MONTH CYCLE

The Ganapati dashboard's most prominent piece of chrome is the season banner counting down to Ganesh Chaturthi. A direct seller has no season. They have a month that resets.

• The industry row carries no context, so hasSeason is false and the strip renders nothing — correct, and no change needed to make that happen.
• In its place, inside the Money group as a widget rather than as chrome: progress against the current calendar month, with days remaining in the month as the urgency. Reuse the ring widget kind exactly as season_progress uses it — same 54px arc, same centre figure, same label line. This is a config variant of an existing widget, not a new kind.
• ⚠ Do NOT draw a compensation "level", "band", "rank" or "target". We do not know the brand's plan, those plans vary, and rendering a target we invented is a fabricated number on a merchant's own home screen. Show their own volume this month against their own last month — data we genuinely have.

3.2 Home — the reorder rail

A rows widget in a horizontal rail, identical in shape to low_stock / media_gaps, so it needs no new kind:

• Title: Due to reorder
• Each row: customer name · what they last bought · how long ago · and the money
• Sort: most overdue first
• Empty: the rail disappears (widgetIsEmpty's existing rule for rows)
• ⚠ The action on a row is Message, never Create order. The distributor has not been asked for one yet; presuming the order is the pushy behaviour their customers churn over.

And design the ANTI-NOISE state explicitly, because it is the failure mode: a distributor with thirty due customers must not be handed thirty separate nudges. Show the rail with a count, cap the visible rows, and let View all carry the rest. One batched in-app surface, never a push per customer.

3.3 Home — attention items

N customers are due to reorder, and the month closes in D days. Severity accent. One card, not N cards — the same grouping rule that makes three missing photos one card. Prompt B adds the session-day items (§8, widget block) under the same one-card rule.

3.4 SetuCard — a leaner card

• No height/material filter set — this catalogue is a dozen products, not fifteen hundred idols, so the filter row and the FILTER_THRESHOLD behaviour should simply not trigger. Verify it does not.
• Category grouping instead (shakes / teas / skincare), which the existing catalogue section already does.
• The About block carries more weight here — the distributor's own story is the trust mechanism, because the channel is warm.
• §5's disclaimer block is mandatory and non-removable.
• ⚠ Two card blocks this vertical wants — upcoming sessions and video/education links — are recorded with their ≥2-industry cases in the discovery brief §2 and stay with the Public Setu Card Spec's section-floor work. Do not design them here.

4 · What is genuinely NEW — two modules and a library, all shared, all capability-gated

The owner's workflow brief (discovery §1) and the 2026-08-14 correction rounds surfaced five needs the first version of this page did not know about. Each is a platform module, not a distributor feature — the ≥3-industry case is in the discovery brief §8:

Module	One line	First siblings
Meetings (meetings cap; noun resolves per industry: sessions, classes, batches)	One-off and recurring group sessions with a join link, participants drawn from groups or customers, invite states, reminders, a fetch-on-open join screen, and an in-app calendar on both halves (owner correction 2026-08-14: the user is never handed off to an OS calendar)	yoga_fitness (seeded with schedule), tutor, coaching and consultants
Leads (leads cap)	A six-stage pipeline over customers: capture, stage, next follow-up date, activity timeline	real_estate, car_sales, photographer
Media library (assets cap, feature key already seeded)	The merchant's reusable promo images, tagged, searchable, shareable out	every industry
Team & group chat (team cap — owner decision 2026-08-14: along the way, not later)	A team roster (upline, peers, downline as CONTACTS), unified Groups that serve both session audiences and chat rooms, group conversations with an admins-only-post mode, and share-down of sessions, media and links. ⚠ Scope boundary that survives the decision: this is communication, never oversight — a team member's own business data (their customers, chats, numbers) is never visible here; the oversight console and seat licensing stay with ADR-0022's tree (26.1.0+)	any business with staff or a network: salon, kirana, coaching institute
My Progress (consumer-side — owner decision 2026-08-14)	Consumer-owned progress tracking: the customer records their own weight, measurements and private photos, sees their chart and streak, and shares with their coach through a revocable grant; the coach's view is read-only and vanishes on revoke. The category-3 stickiness engine — a standing personal reason to keep QR Setu installed	yoga_fitness, dietitians and fitness coaches, tutors (progress of a different kind)
Daily sales lite (daily_sales cap without payments — accepted 2026-08-14 from the design round's own report-back)	A record-a-sale sheet plus a day-grouped sales list, giving daily_sales a home that is not the Payments passbook. Without it, sale entry has nowhere to go for a payments-less business and the reorder rail starves	kirana (cash over the counter), tiffin (billed outside the app) — the design round's own ≥2 case

Naming note (feature-scoped naming rule): the module key is meetings, never sessions — session is already owned by auth (session store, session vault) and a second meaning would be the exact collision the naming gate exists to prevent. The user-facing noun still resolves per industry through nouns ("session" for this vertical).

And the boundary list, reworded 2026-08-14 after owner pushback — the first version compressed three different verdicts ("design now, build later" / "sequenced behind a named prerequisite" / "blocked pending legal") into one word, which misread as discarding value. Nothing below is discarded; every hold names its unlock:

Candidate	Verdict
A Zoom OAuth "Connect" flow	✅ DESIGN NOW, BUILD LATER (owner pushback 2026-08-14). Prompt B now includes the connected-meeting-account states and the auto-created-link option on Meeting create, ledgered as designed-for-later. The build stays phased: Zoom Marketplace app review plus server-side token custody and refresh are real backend work, and for this persona the agent mostly FORWARDS the coach's link, so slice-1 value is intact with bring-your-own-link. The seam is provider-agnostic ("connected meeting account") so Google Meet arrives as config. No meeting SDK in the app, ever: join stays a deep link out
Device-calendar sync UI	✅ CORRECTED BY THE OWNER 2026-08-14: THE CALENDAR IS IN-APP, FULL STOP. The user is never handed off to an OS calendar — no sync module, and the earlier calendar-file-share concession is REMOVED too. The feature is the in-app calendar on both halves: the merchant's month + day view of sessions and follow-ups, and the consumer's My Sessions calendar. Local notifications remain the reminder path, and they reopen QR Setu, which is exactly the keep-them-inside behaviour the owner wants. The one unavoidable outside hop is the meeting itself (the Join deep link into Zoom/Meet at start time)
An attendance analytics dashboard	❌ NO. Attendance is join-tap counts, honestly labelled "joined via QR Setu". There is no measurement substrate for more, and fabricated precision is worse than none
A "reorder" block on the public card	❌ NO. Per-visitor, breaks the edge cache (ADR-0027). It belongs in the app, to the merchant
A "my team" / downline screen, team chat	✅ IN SCOPE ALONG THE WAY — owner decision 2026-08-14, implemented as the Team & group chat module above. What is in: the roster, unified Groups, group conversations with admins-only-post mode, share-down of sessions, media and links — communication and coordination, which is what the workflow brief actually describes, and none of it needs ADR-0022's tree. ⚠ What stays tree-gated, recorded as the standing constraint rather than re-argued: OVERSIGHT. A team member is an independent member_owned business, so their customers, their chats and their volume are never visible to an upline through this module — the team CONSOLE (volume roll-ups, seat licensing, the paid enterprise motion of discovery §4.4) arrives with the tree in 26.1.0+. Requires a chat-schema extension (group rooms — today's conversations are strictly business-to-consumer pairs), logged as QRS-672
A customer progress / weight tracker	✅ IN — REDESIGNED AS CONSUMER-OWNED "MY PROGRESS" (owner decision 2026-08-14, Prompt B Module 5). The shape IS the compliance: the CUSTOMER records their own weight/measurements/private photos, owns them, and shares them with their coach through an explicit, revocable grant; the coach's view is read-only and exists only while shared. Agent-entered health fields remain out everywhere — that version made us a fiduciary for data its subject never consented to. Consent, control and delete-all are designed in with [legal copy pending review] placeholders (the disclaimer-block precedent). ⚠ The owner's "a consent notification sorts the legal problem" is half-right and the half matters: under DPDP consent is necessary but not sufficient — security-safeguard duties, breach notification, erasure on withdrawal, grievance handling and minors' provisions all survive a consent tap — so the legal read stays on the path to BUILD while design proceeds now (QRS-673)
Before/after transformation gallery	✅/🔴 SPLIT (owner decision 2026-08-14). ✅ PRIVATE before/after is IN: inside My Progress, the consumer views their own two photos side by side and shares them only within their grant — their content, their choice, no publication. 🔴 The PUBLIC gallery on the card stays blocked, and consent cannot unlock it: the public form is an advertising-law exposure (the efficacy claim the image makes to VIEWERS under FSSAI / CP(DS) Rules / ASCI), not a privacy one, so the photographed person's consent changes nothing. Unlock unchanged: the legal read + a moderation/takedown path (release plan R2)
Any new primitive	❌ None is proposed; schedule, party and asset are already seeded
Any new card block type	❌ None in this slice; two candidates deferred to the card spec

The engagement layer — MVP additions from the 2026-08-14 owner reassessment

The owner asked for a product-owner pass over the whole scope: low-effort, high-value, daily-engagement features, evaluated on Effort → Value → Frequency → Stickiness → Reusability → Compliance, with feature bloat explicitly rejected. The result is nine MVP additions, every one a composition over the five modules' own data — zero new systems — now embedded in Prompt B's ENGAGEMENT LAYER block, plus a recorded follow-up/future/avoid split (QRS-674). ✅ Owner-approved 2026-08-14 ("without any second thought") — the full four-bucket record, the scoring and the delivery split now live at Direct Seller — engagement layer.

• Consumer daily loop: a "Today" section on the consumer home (next session · check-in due · coach's latest announcement) · a daily check-in in My Progress (up to three self-chosen lifestyle habits, one tap, streaks that encourage and never shame) · a post-session acknowledgment moment · a weekly recap card.
• Merchant daily loop: ONE daily digest as a local notification (content knowable in advance: tomorrow's sessions, follow-ups due) · a "leads going cold" attention item · a weekly business snapshot widget (insights group) · quick replies in the chat composer (the storage table already exists in the live schema) · share shortcuts in Quick tools.
• ⚠ The honest infrastructure constraint, stated rather than papered over: remote push does not exist in R1 (deliberately stripped, QRS-234). Real-time "new enquiry" and "session link changed" alerts are in-app and badge only until the push decision is revisited — recommended for the 26.0.2 architecture agenda, since a lead-gen vertical without new-lead alerts is running at reduced power. Everything above is designed to work WITHOUT push, so nothing here is blocked on it.
• Explicitly avoided, with reasons on the tracker row: platform-authored motivational quotes (unfalsifiable filler that trains users to ignore real nudges), weight-loss challenges and leaderboards (competition on health outcomes), any diet/calorie advice (medical-adjacent), a community feed before moderation exists, points/rewards schemes, and any engagement-bait notification.

5 · ⚠ THE COMPLIANCE CONSTRAINT — read this before drawing anything

This is the highest-risk vertical evaluated so far, and two content classes are blocked rather than deferred:

1. Income and earnings claims. India's Consumer Protection (Direct Selling) Rules 2021 restrict income representations. A card reading "earn ₹50,000 a month from home" makes QRSETU the publisher of that claim.
2. Health and therapeutic claims. These are FSSAI-regulated supplements. "Cures diabetes", "lose 10kg in a month", and before/after transformation imagery, which is the visual form of the same claim.

What this means for the design work:

• Draw no earnings figure, no income example, no "opportunity" or "join my team" recruitment surface, and no PUBLIC before/after gallery anywhere. Not as a placeholder, not as sample data, not greyed out. (The one sanctioned home for before/after photos is the consumer's own private My Progress — Prompt B Module 5 — shared only inside their revocable grant, never published.)
• Every product description in the sample data must be descriptive, never therapeutic. "Vanilla protein shake, 500g, 30 servings" — not "supports weight loss".
• The same bar applies to session titles and descriptions (new 2026-08-14): sessions are run by coaches with medical framing, and a hosted session titled "diabetes reversal workshop" is the same claim class on a new surface. Demo sessions are "Morning yoga", "Nutrition basics", "Product usage Q&A" — never a condition, never an outcome.
• Include a disclaimer block on the card, positioned but with the wording left as a placeholder: [legal copy pending review]. ⚠ Do not write the disclaimer text. It needs a legal read, and CLAUDE.md is explicit that an architecture-or-legal-gated question is resolved as a decision first and never sent to Claude Design as a prompt.
• Show the block as non-removable in CardEditor — visibly present, with no delete affordance. That is a new editor state worth designing: a block the merchant may reorder but not remove.

6 · The five decisions Prompt B embeds

Prompt B is written against the recommendations below. Confirm or overturn each before sending it — every one is recorded with its full argument in the discovery brief §9 and the tracker:

#	Decision	Embedded recommendation	Where argued
D1	The discovery brief itself	Approve (flip its Status row)	the brief
D2	Enquiry capture — ✅ DECIDED by the owner 2026-08-14	Form block, scoped and fail-closed: an enquiry lands as a lead with a source, never a separate inbox. Partially reverses QRS-650 for expertise cards only	brief §3.1a · QRS-668
D3	Meetings module scope + adding schedule to direct_seller.enabled_primitives — ✅ decided in substance by the owner's 2026-08-14 correction rounds (team, calendar and engagement decisions all presuppose it)	Build as the shared module above; one-row composition migration	brief §8 · QRS-667
D4	Lead stage vocabulary — ✅ DECIDED by the owner 2026-08-14	Six stages: new · contacted · interested · session · converted · inactive, with next follow-up as a date on the lead, not a stage. The owner's nine-step list folds in: "invited to session" and "attended" are session facts on the timeline, "product interest" is a note, "follow-up required" is the date	brief §9
D5	Zoom phasing — ✅ settled by the owner's 2026-08-14 pushback round	Slice 1 builds bring-your-own-link (any platform); the Connect flow and auto-created links are designed in Prompt B now and build in a later release; attendance webhooks later still. No meeting SDK in the app, ever: join is a deep link out	brief §6 · QRS-667
D6	Team along the way — ✅ DECIDED by the owner 2026-08-14, listed for completeness	Scope is roster + Groups + group chat + share-down (communication); oversight, volume roll-ups and seat licensing stay with ADR-0022's tree. Requires the group-rooms chat-schema extension	QRS-672
D7	My Progress — ✅ DECIDED by the owner 2026-08-14, listed for completeness	Consumer-owned tracking shared by revocable grant; agent-entered health fields stay out; private before/after in, public gallery still blocked (advertising law, not privacy). Legal read validates before BUILD; design proceeds with [legal copy pending review] placeholders	QRS-673

✅ All gating decisions are confirmed as of 2026-08-14 ("aligned with both the points": D2 form block · D4 six stages). Prompt B is SEND-READY. D1 (flipping the discovery brief's Status row) remains an owner action, and it gates the release scope-freeze, never the design prompt.

7 · Prompt A — the decided delta (send-ready)

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.

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

Add the second industry to the QR setu prototype: the DIRECT SELLER (independent distributor).
This is Prompt A of two: the decided delta only. A second prompt will follow for the Meetings,
Leads and Media Library modules once their contracts are confirmed. Do not anticipate them here.

WHO THIS SERVES
Category 1, a solo business owner: a part-time independent distributor working from home, no
premises, no staff, phone-first. They resell a wellness brand's products to a warm network and
educate prospects through sessions their coach runs. The sale itself completes through the
brand's official channel, so this vertical has NO orders and NO payments capability in QR setu.
Their operational record of a sale is the daily sales (counter sale) entry.

THE SHAPE OF THE ASK
This is a DELTA over the shared, parameterised screens, not a new product. One industry row in
vendor-core, a Home that resolves differently through existing widget kinds, a leaner Setu Card,
one new CardEditor state, one vendor journey reading map. If the output looks like a new app,
the prompt was misread.

1. THE INDUSTRY ROW
Add direct_seller to INDUSTRIES in prototype/mobile-console/vendor-core.js and to
INDUSTRY_OPTIONS (with its own promise and tone), following the existing row shape:
  id direct_seller, label Independent distributor, archetype expertise, no context key
  (this industry has no season), caps: the universal set plus store, store.media,
  daily_sales, chat. Orders and payments are deliberately absent: Collections, OrderDetail,
  Payments and Banking must resolve away for this industry. Nouns: item product, items
  products, person customer, people customers.
NEVER name a real brand: not in the key, the label, the demo business name, the product names,
or any imagery. Invent a distributor name and invented product names. The distributor's brand
affiliation is content they type, and it travels with the disclaimer block below.

2. THE DEMO DATASET
Twelve to twenty products across three or four categories (shakes, teas, protein, skincare),
thirty to forty repeat customers, a realistic reorder spread (some customers 20 days since last
purchase, some 35), daily sales entries. Every product description is descriptive, never
therapeutic: "Vanilla protein shake, 500g, 30 servings", never "supports weight loss". Some
products use price on enquiry instead of a listed price.

3. HOME (Home.dc.html), resolved for ?industry=direct_seller
- Month cycle ring, in the Money group, as a widget (never chrome): this industry has no season
  strip. Reuse the existing ring widget kind exactly as season_progress uses it (same 54px arc,
  same centre figure, same label line). It shows their own volume this month against their own
  last month, with days remaining in the month as the urgency line. Do NOT draw a compensation
  level, band, rank or invented target: we do not know the brand's plan, and a fabricated number
  on a merchant's home screen is worse than none.
- Reorder rail: a rows widget in a horizontal rail (same shape as low_stock), titled "Due to
  reorder". Each row: customer name, what they last bought, how long ago, and the money. Sorted
  most overdue first. Empty rail disappears. The action on a row is Message, never Create order.
  Design the anti-noise state explicitly: thirty due customers is ONE rail with a count and a
  View all, never thirty nudges.
- Attention item: "N customers are due to reorder, and the month closes in D days." Severity
  accent. One card, not N cards.

4. SETU CARD (SetuCard.dc.html), resolved for ?industry=direct_seller
- A dozen products means the filter row and FILTER_THRESHOLD behaviour must not trigger; verify.
- Category grouping (shakes, teas, skincare) via the existing catalogue section.
- The About block carries the trust load: the distributor's own story, prominent.
- A disclaimer block, mandatory and non-removable, positioned near the footer, with its wording
  as the literal placeholder text "[legal copy pending review]". Do not write disclaimer copy.

5. CARD EDITOR (CardEditor.dc.html)
Design the non-removable block state: the disclaimer block is visibly present in the block list,
reorderable, with no delete affordance, and a quiet explanation of why it stays.

6. VENDOR JOURNEY
Add prototype/vendor-journeys/direct-seller.dc.html reading the shared JOURNEY array, matching
ganapati.dc.html: each step with its SHARED / CONFIGURED / SPECIFIC reuse badge, what varies
where configured, and a closing implementation-readiness list. Register the new file and the
industry in SCREENS.md so the prototype hub sees them.

7. COMPLIANCE ENVELOPE (blocked, not deferred)
Draw no earnings figure, no income example, no "opportunity" or recruitment surface, and no
before/after imagery anywhere: not as placeholder, not as sample data, not greyed out. India's
direct-selling rules and FSSAI make QR setu the publisher of such claims.

8. GLOBAL RULES
Both themes on every screen. Loading, empty, error and edge states. No em dashes anywhere in any
generated copy, labels or examples. Never volunteer a privacy reassurance at the point of use.
Copy in English only. Industry customisation changes content, never chrome: same tab bar, same
centre button, same radii, same motion.

9. REPORT BACK, DO NOT BUILD AROUND
Close with a short note listing anything you believe genuinely needs a new screen or a new card
block for this industry, each with the case that at least two other industries would use it. If
the answer is nothing, say that: it is the expected answer for this prompt.

8 · Prompt B — Meetings, Leads and the Media Library (gated)

SEND-READY — every embedded decision confirmed by the owner 2026-08-14

Send after Prompt A completes (this prompt extends the industry row and journey file A creates), to the prototype project 633dc069-6df8-4408-b625-068907c60c33.

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

Design six shared, capability-gated modules for the QR setu console, mobile native first,
spanning both the merchant and consumer halves. The reference industry is direct_seller (added in
the previous prompt), but every screen here must work unchanged for a yoga studio, a tutor or a
consultant the day their capabilities turn on: gate on capability, resolve nouns per industry
(a distributor's "session", a tutor's "batch", a studio's "class"), and never branch on the
industry itself. Same chrome everywhere: same tab bar, same centre button, same radii, same
motion. Entry points are the existing resolution mechanisms only: Home widgets, the Quick tools
grid (resolves from caps), and the More directory. Do not invent a new tab.

CONTEXT YOU NEED
The merchant runs group sessions online (mostly Zoom) and offline: one-off wellness sessions and
recurring daily batches (for example yoga at 7am). Today the join link is forwarded by hand over
WhatsApp 10 to 15 minutes before start, invitees are tracked from memory, and no-shows are chased
manually. Leads arrive from paid social ads and personal referrals into WhatsApp and get buried.
Promotional images are re-hunted daily. These three modules replace that manual layer.

FIRST, EXTEND THE INDUSTRY ROW FROM THE PREVIOUS PROMPT
The direct_seller row's caps gain: meetings, leads, assets, team (the four modules below), and
its nouns gain: meeting session, meetings sessions. Yoga and tutor industries would render the
same screens with their own nouns; do not fork anything.

DECIDED CONTRACTS (design to these, do not re-open them)
- The whole experience stays INSIDE QR setu (owner instruction). The calendar is in-app on both
  halves; there is no hand-off to an OS calendar, no calendar-file export, no sync. The one
  outside hop is the meeting itself: Join deep-links into the meeting app at start time, and
  local notifications reopen QR setu.
- A GROUP is one concept serving two jobs: a named set of people (customers, leads, team
  members) that a session can be scheduled FOR and that can carry a group chat. A yoga batch,
  a tutor's batch and a coach's team are all groups; the noun renders per industry.
- A recurring session is a RULE plus per-occurrence exceptions (cancel one, move one), never an
  expanded series of rows. Editing offers "this occurrence" or "the whole series".
- The join link is pasted by the merchant (any platform: Zoom, Meet, anything). That is the
  FIRST BUILD SLICE. The connected-meeting-account states below are designed now and built in a
  later release; mark them designed-for-later in SCREENS.md. There is no in-app meeting SDK in
  any phase. Joining is a deep link out to the meeting app or browser.
- The participant's join screen fetches the CURRENT link when opened, so a rescheduled meeting
  never strands anyone on a stale link. Design the stale-state honestly: if the device is
  offline it shows the last stored link with the offline banner.
- Session reminders are local notifications scheduled when a participant accepts, with a short
  scheduling horizon (the app tops up on open). Default reminder: 15 minutes before start.
- Attendance is join-tap based and labelled honestly: "joined via QR setu" counts, plus a manual
  "mark attended" affordance for the merchant. Never present it as verified attendance.
- Lead stages are exactly six: new, contacted, interested, session, converted, inactive. Next
  follow-up is a DATE on the lead, not a stage. Session invitations and attendance are timeline
  facts, not stages.
- An enquiry submitted from the public card lands as a lead with source "card enquiry". Other
  sources: referral, ad, added manually.

MODULE 1: MEETINGS (merchant side)
Screens, each with loading, empty, error and edge states, both themes:
1. Meetings list: segmented Today, Upcoming, Past. Each row: title, batch or ad-hoc label, time,
   recurring badge, confirmed count, a Join affordance when live or imminent. The empty state
   proposes creating the first session and says what a session gives them.
2. Meeting create and edit: title and description (descriptive copy only, never a health outcome
   or condition), one-off or recurring (daily or weekly, time), group selection or ad-hoc
   participant picking from customers, join link paste field with validation, reminder policy
   (default 15 minutes before), and for edits of a recurring rule the "this occurrence or whole
   series" choice.
3. Meeting detail: participant list with invite states (invited, confirmed, declined), share
   invite (the share sheet is the primary spread mechanism), copy link, join, cancel this
   occurrence versus delete series (destructive confirmations state the consequence plainly),
   and the post-session state: who joined via QR setu, manual mark-attended, and ONE follow-up
   action for the no-shows ("Message the 3 who missed"), never one nudge per person.
4. Groups: list and detail. A group is a named set of people (customers, leads, team members)
   with an optional default schedule line; the noun renders per industry (batch, class, team).
   Group detail shows members, its upcoming sessions, and its chat room (Module 4). Members who
   are not on QR setu yet show as invited, with a share-invite link: joining is how they start
   receiving sessions and messages, which is the adoption loop working as intended.
5. Calendar: a month view plus a day list of sessions and follow-ups due, inside the app. Reuse
   the existing calendar primitive vocabulary. This is a view over the same data, not a fifth
   concept. There is no hand-off to the OS calendar anywhere.
6. Connected meeting account (DESIGNED FOR A LATER BUILD SLICE, mark it so in SCREENS.md): a
   "Meeting account" row reachable from the meetings surface with two states: disconnected
   (a Connect Zoom action that explains what connecting unlocks: links created for you when you
   schedule) and connected (account label, disconnect with the consequence stated). On Meeting
   create, when an account is connected, a "Create the meeting link for me" option that fills
   the join link on save, with an error state for a failed creation that falls back to pasting
   a link. The seam is provider-agnostic: Zoom is the first provider, not the concept.
7. (Removed 2026-08-14 by owner correction: there is no add-to-OS-calendar affordance. The
   in-app calendar and local notifications are the whole scheduling experience.)

MODULE 2: LEADS (merchant side)
1. Leads pipeline: list grouped by the six stages with counts, filter by stage and source,
   search. Each row: name, source, days since last activity, next follow-up date if set. The
   empty state explains where leads come from (card enquiries, referrals, added manually) and
   offers Add lead.
2. Lead detail: identity (name, phone), source, stage control (the six stages as a stepper or
   segmented control), next follow-up date picker, activity timeline (enquiry text, session
   invitations and attendance, notes, stage changes), and quick actions: Message, Invite to
   session, Set follow-up. Converting marks the stage and offers to add them to customers.
3. Add lead: name, phone, source, one note. Two taps from the pipeline. Built for the moment a
   WhatsApp enquiry arrives: fast manual capture is the primary path.
4. Enquiries are NOT a separate inbox: a card enquiry is a lead in stage "new" with its message
   on the timeline. Design the "new enquiry" state of the pipeline and the notification entry
   that leads there.

MODULE 3: MEDIA LIBRARY (merchant side)
1. Library grid: the merchant's reusable promotional images with tag chips, multi-tag filter,
   search, and upload. Each item: preview, tags, quick actions (share out, copy to chat, edit
   tags, delete with consequence stated). The empty state proposes the first upload and example
   tags. Tags are the merchant's own vocabulary, freeform with suggestions from existing tags.
2. Share-out is the point: one tap from library item to the system share sheet.

MODULE 4: TEAM AND GROUP CHAT (merchant side; owner decision 2026-08-14, in scope now)
1. Team roster: the merchant's team members as CONTACTS (their coach, peers, downline), each
   with name, an optional relationship label, and their QR setu status: on QR setu, or invited
   with a pending share-invite link. Adding a member: from contacts, by phone number, or by a
   shareable invite link and QR. Row actions: message, add to group, invite to session. The
   empty state explains what a team gives them and offers the invite link.
2. Group chat room: every group (Module 1) can carry one conversation. Design the room: group
   name and member count in the header, sender attribution on messages, membership managed by
   the group owner, and an "only admins can post" announcement mode (this replaces the WhatsApp
   broadcast the coach uses today for session links). Sharing INTO the room: a session invite
   card, a media library image, a catalogue product, a link. A session shared into its own
   group's room renders as a tappable invite card, not a pasted URL.
3. THE BOUNDARY, stated because it is load-bearing: this module is communication, never
   oversight. A team member's own business data (their customers, their conversations, their
   numbers) is never visible to anyone else through this module. Do not design any team
   volume, earnings, activity or performance surface: that console belongs to a later release
   on a different substrate.
4. Consumer-side note: a team member without a business participates through the consumer
   identity (My sessions, chats, notifications). Nothing new is needed on that side for teams.

MODULE 5: MY PROGRESS (consumer side; owner decision 2026-08-14)
The retention surface for category 3, and its shape IS its compliance: the consumer records
their OWN progress, owns it, and shares it by choice. Never design an agent-entered health
field anywhere in the product.
1. My Progress home: the consumer's entries over time as a simple chart (weight, optional
   simple measurements), last-entry and streak encouragement, add entry, and the consumer's
   own optional goal line (the app never sets or judges a target). The header states what the
   product does: "Only you can see your progress. Share it with your coach when you choose."
2. Add entry: weight, optional note, optional PRIVATE photo, date (defaults to today, backfill
   allowed). Two taps from open to saved.
3. Consent and control: a first-use notice screen stating purpose in plain words, with the
   formal wording as the literal placeholder "[legal copy pending review]"; a settings row
   where sharing and the data itself are each removable in one clear action ("Delete all my
   progress data", consequence stated plainly).
4. Sharing: an explicit, revocable grant to ONE business ("Share my progress with <business>"),
   showing exactly what the grant includes before confirming. Revoking removes the coach's
   view immediately. Private photos travel only if the consumer includes them in the grant.
5. Private before and after: the consumer can view two of their own photos side by side,
   privately, and share that view only inside the grant. There is NO route from here to any
   public surface, any card, or any group room; do not design one.
6. Coach's view (merchant side): on the customer or lead detail, a read-only "Progress, shared
   by them" section that exists only while the grant stands. No edit, no export, and no advice
   or judgment: the app never labels a value good or bad. If revoked, the section disappears.
7. The nudge: a consumer-controlled reminder to log progress (off by default, quiet-hours
   aware). One gentle nudge; never a streak-shame pattern.

MODULE 6: DAILY SALES LITE (merchant side; accepted from your own Prompt A report-back)
Your report named it and the case clears the two-industry bar: daily sales entry today lives on
the Payments passbook, gated on the payments capability, so a business that records sales but
takes no money inside QR setu (this distributor, a kirana taking cash over the counter, a
tiffin service billing outside the app) has entry with nowhere to go, and the reorder rail
starves without sale records.
1. Record a sale: a sheet, two taps from Home and from Quick tools: optional customer pick (or
   quick add), item pick or a free amount, date defaults to today. Recording against a customer
   is what feeds the reorder cycle; the empty state says so quietly.
2. Sales, the screen: a day-grouped list of recorded sales with a month total, serving as the
   daily_sales home when the payments capability is absent. When payments IS present the
   passbook remains the home; this screen never appears twice for one business.
3. Point the month cycle ring and the counter sales widget hrefs here for payments-less
   businesses, replacing the stated-gap undesigned string from the previous round.

ONE CONFIRMATION FROM THE PREVIOUS ROUND
State the filter row's comparison against FILTER_THRESHOLD explicitly. The demo dataset has
exactly 14 products and the threshold is 14; if the comparison is "at or above", either the
operator or the dataset must move so the direct seller card provably renders without the
filter row.

HOME ADDITIONS (config over existing widget kinds, no new kinds)
- Sessions today: a rows widget listing today's sessions with confirmed counts, in the Bookings
  group. Empty disappears.
- Pipeline summary: a stats or chips widget with stage counts and follow-ups due today, in the
  People group.
- Attention items, one card each, never per-person: "Tonight's session has 5 unanswered
  invites", "3 follow-ups are due today", "2 people missed yesterday's session".

ENGAGEMENT LAYER (owner reassessment 2026-08-14: both halves must feel alive daily; every item
here is a composition over the five modules' own data, never a new system)
Consumer:
1. A "Today" section at the top of the consumer home: the next accepted session (with its join
   state), the daily check-in if due, and the coach's latest group announcement if unread.
   Sections hide when empty, per the existing consumer-home rule.
2. My Progress daily check-in: up to three self-chosen simple routine habits (suggested
   defaults are lifestyle-neutral: water, a walk, stretching), one tap to mark done, and a
   streak that encourages and never shames: no guilt copy, no red broken state, a quiet
   "start again today" instead. This is the daily hook; weight stays weekly.
3. Post-session moment: when a session the consumer joined has ended, the next app open shows
   a small acknowledgment (session name, their attendance count this month, streak if any).
4. Weekly recap card (consumer, in-app only, no push): sessions attended, check-ins done,
   progress entries, computed from stored rows only. Absent when there is nothing to say.
Merchant:
5. Daily digest: ONE local notification per day, its content limited to what is knowable at
   schedule time (tomorrow's sessions, follow-ups due, reorder-due count), with a first-run
   explainer and a one-tap off. Never a push per customer, never engagement bait.
6. A "leads going cold" attention item (no activity in N days: one card with a count, never N
   cards) and a weekly business snapshot widget in the insights group (sessions held, people
   joined, new leads, conversions, messages answered), derived from module data only.
7. Quick replies in the chat composer: saved reusable answers (product list, session details,
   directions) inserted in one tap, with a small management sheet. The storage for this
   already exists in the schema; design the affordance if the current Thread design lacks it.
8. Share shortcuts in Quick tools: share my card, share the next session invite, share a media
   library image, each one tap into the system share sheet.
Global engagement rules: every nudge is dismissible, quiet-hours aware and individually
mutable; nothing renders without data behind it; a surface with nothing to say is absent, not
a placeholder; and all scheduled notifications stay inside the shared short-horizon budget.

CONSUMER SIDE (category 3, in the consumer prototype section)
1. My sessions: the participant's accepted and invited sessions, as a list AND an in-app
   calendar view (month plus agenda). This calendar lives inside QR setu; there is no add-to-
   OS-calendar affordance anywhere (owner instruction). Accepting an invite schedules the local
   reminders. Declining is one tap and final on that occurrence.
2. Session join screen: opened from a notification, an invite, or My sessions. Shows title,
   host business, time, a countdown when imminent, and the Join button that deep-links out.
   It fetches the current link on open; design the offline fallback (last stored link plus the
   offline banner) and the ended state. Registration note: viewing a public session line on a
   vendor card is anonymous; ACCEPTING an invite requires the existing consumer sign-in, the
   same identity bar chat already sets.
3. Vendor view addition: an upcoming-sessions row on the in-app vendor screen, positioned like
   the Featured block (below identity, above the list), showing the vendor's public session
   RULES ("Daily, 7:00 am, Yoga"), never a live countdown.
4. Enquiry form (decided, expertise-archetype cards only): on the public card and its in-app
   twin, a short form (name, phone, message) with explicit purpose copy and consent, submitting
   into the merchant's leads as source "card enquiry". Anonymous, no account required, one per submit with abuse-safe
   affordances (a quiet cooldown message state). Do not add any tracking or identifier beyond
   what the visitor types.

COMPLIANCE ENVELOPE (same as Prompt A, extended to sessions and progress)
No earnings figures, no recruitment surfaces, and session titles and descriptions are
descriptive, never therapeutic: "Morning yoga", "Nutrition basics", "Product usage Q&A", never
a condition or an outcome. Before/after imagery exists in exactly one place: the consumer's
own private My Progress (Module 5), shared only inside their grant. It never appears on a
card, in a group room, on any merchant marketing surface, or in any sample data.

GLOBAL RULES
Both themes on every screen. Loading, empty, error, offline and edge states everywhere. No em
dashes anywhere in any generated copy, labels or examples. Never volunteer a privacy reassurance
at the point of use. Copy in English only. Update SCREENS.md and the prototype hub with every
new screen, and extend the direct-seller vendor journey with the session, lead, group, media
library and progress steps.

REPORT BACK, DO NOT BUILD AROUND
Close with a short note listing anything you believe genuinely needs a new screen, a new widget
kind or a new card block beyond the above, each with the case that at least two other industries
would use it, plus any state you believe the contracts above cannot express.

9 · Proactive-value answer

• What action it prompts: message the customer whose reorder window is open; follow up the three people who missed yesterday's session; act on today's follow-ups; answer the new enquiry before it goes cold.
• What makes it timely: all four are dated facts (a last-purchase date against a consumable cycle, a session start time, a follow-up date the merchant set, an enquiry timestamp), and the month-reset compensation cycle gives the reorder nudge a real deadline.
• Where the intelligence comes from: stored rows only — sale records against the recurrence engine (ADR-0016), the session schedule, participation records, and the lead's own follow-up date. No scores, no fabricated insight; with no data the surface is absent, not a placeholder.
• The anti-noise ceiling: batched in-app surfaces, one card per situation, never a push per customer or per participant.
• The category-3 engine: the consumer's own progress log (Module 5) gives a buyer a standing personal reason to keep QR Setu installed — their data, their chart, their choice to share — with one consumer-controlled log reminder, off by default, and never a judgment attached.

Parity status

Design-phase document: no implementation surfaces to verify yet. The modules in Prompt B are mobile-native-first by owner instruction (2026-08-14); the desktop adaptation is a second phase after the mobile journey is approved, with feature and workflow parity but desktop-native information architecture. Implementation, when it comes, inherits the full three-surface parity Definition of Done unchanged — the join-link deep link, the local notification budget and the share sheet are the divergence seams already named in the discovery brief §6.

Related

• Discovery brief — the evidence and the reasoning
• Public Setu Card Spec — owns the card's future sessions and video blocks
• Consumer Marketplace Spec — this vertical is deliberately absent from the marketplace
• Tracker: QRS-665 · QRS-667 · QRS-668 · QRS-669 · QRS-670 · QRS-671