Appearance
Consumer context prompt — Claude Design, round 1
Purpose: establish product direction before any screen is designed. This is deliberately not a screen-by-screen brief. It gives Claude Design the vision, the persona, the architecture and the constraints, so that when the detailed feature requirements arrive in round 2 the design lands inside a frame it already understands rather than being reverse-engineered from a screen list.
Why context first, then screens
The prototype acquired an Ad Manager and an in-house billing engine because feature prompts arrived without an architectural frame around them. A design brief that opens with "design the biodata creation screen" invites invention at exactly the points where QRSETU has already decided something. Round 1 buys the frame; round 2 spends it.
Read alongside: Consumer decisions (the SSOT for everything asserted here) · PDPR master brief (the global design rules this inherits) · Screen Coverage Mandate · Foundational Screens.
⚠ This is the CONSUMER half of the platform. The PDPR master brief is written about the merchant product. Everything in it about tokens, radius, theming, Apple HIG influence and handoff structure still governs. What changes is the audience, and Section 0 below states where the two diverge.
The prompt
Paste everything between the rules into Claude Design as a single message.
text
QR SETU: CONSUMER PLATFORM AND MARRIAGE BIODATA
ROUND 1 OF 2 - PRODUCT CONTEXT AND DESIGN DIRECTION. DO NOT DESIGN SCREENS YET.
You are a Principal Product Designer working on QR Setu. This message establishes product
context, architecture and constraints. Your task in this round is to understand the product
and propose a DESIGN DIRECTION, not to produce screens. Detailed feature requirements and
screen-by-screen briefs follow in round 2.
=====================================================================
SECTION 0: NON-NEGOTIABLE RULES, AND WHERE THE CONSUMER SIDE DIVERGES
=====================================================================
Every rule in the QR Setu MASTER GENERATION BRIEF (PDPR) still applies: no em dashes in any
copy you produce, no hardcoded colors, Apple Human Interface influence, the 3XL half-rounded
corner signature, mandatory light and dark themes through tokens, and native mobile patterns
rather than a shrunken website.
Five rules are specific to the consumer side, and each one reverses something that is true of
the merchant product:
1. CONSUMER DATA IS PRIVATE AND IS NEVER INDEXED. The merchant Setu Card is an SEO surface and
is designed to be found. A consumer profile is the opposite: it is personal data, it carries
noindex, and it is reachable only by a link its owner chose to share. Never design discovery,
search, browse, listing, recommendation or "people near you" surfaces for consumer profiles.
2. CONSUMER FEATURES ARE NEVER PART OF THE MARKETPLACE. A marriage biodata must never appear in
any marketplace listing, feed, category or search result. The consumer can BROWSE the
marketplace as a customer. Their own content never enters it. These are two different
directions and only one of them is allowed.
3. THE RECIPIENT MUST NEVER BE ASKED TO REGISTER TO VIEW. Someone who receives a shared link
opens it in a mobile browser and sees the profile immediately. A signup wall in front of a
shared link destroys the entire growth mechanic. Authenticate intent, never curiosity.
4. NO PURCHASE OR UPGRADE BUTTON INSIDE THE NATIVE APPS. QR Setu ships as a free companion app
on iOS and Android. Paid capabilities are shown and explained everywhere, always, with a lock
affordance and a clear statement of value, but the ACTION differs by surface: on web, a real
upgrade path; in the native apps, state that plans are managed on the web and stop. Never
design an in-app checkout or a deep link into one.
5. A FEATURE BEING UNAVAILABLE DOES NOT MEAN HIDING IT. If a capability exists but is not
included on the user's plan, it stays visible and discoverable with a lock and a plain
description of what it does. A merchant or consumer who never sees a capability can never
want it. The only things that stay absent are capabilities that do not APPLY to that person
at all, because an upgrade prompt for something no plan unlocks is a lie.
=====================================================================
SECTION 1: WHAT QR SETU IS
=====================================================================
QR Setu is one unified platform for small businesses and the people who buy from them. It is
not a collection of separate tools.
Its governing product principle is that it is a PROACTIVE ASSISTANT, not a passive record. It
does not merely store and display information. It continuously surfaces the next useful action.
A screen that only renders state is not finished. This principle applies to the consumer side
exactly as it does to the merchant side, and Section 9 is about what that means here.
The platform serves three fundamentally different kinds of user. They differ in goals,
authentication, onboarding, navigation and feature set, so they differ in architecture:
1. BUSINESS OWNER. A solo merchant: a stall vendor, a boutique, a tutor, an electrician, a
consultant. Owns a public Setu Card, a catalogue, orders, payments and analytics.
2. ENTERPRISE ORGANIZATION. Many users under one centrally administered account, with seats,
roles and an org admin who governs what employees can do.
3. CONSUMER. A person who does not run a business on QR Setu. This round is about them.
=====================================================================
SECTION 2: WHO THE CONSUMER IS
=====================================================================
A Consumer is a person in QR Setu's target audience who has BOTH of these, always:
a. their own personal digital identity on the platform, and
b. a relationship with QR Setu merchants as a customer.
Both halves matter. A definition that describes a consumer only as "someone who buys from a
merchant" cannot hold a personal identity, and a definition that describes them only as
"someone with a profile" loses the reason they are on a commerce platform at all.
A Consumer does not own a business, a storefront, a catalogue or a team. They are not a
merchant with fewer features. They are a different person with a different product.
Design implication: the consumer app is not the merchant app with modules removed. Its home
screen, its navigation, its empty states and its tone are its own.
=====================================================================
SECTION 3: MY QR SETU, THE CONSUMER IDENTITY
=====================================================================
MY QR SETU is the Consumer's permanent personal identity on the platform. It is the single most
important idea in this brief.
- Every Consumer claims a personal address at onboarding, seeded from their name and editable
before they commit to it, exactly as a merchant claims theirs.
- That address belongs to the IDENTITY, never to any one feature. It is a namespace root, not
a page.
- The address is permanent and is never transferable to anyone else, ever, even if the person
leaves. If they return with the same phone number or email, they get their identity back.
- Today the address itself renders only a quiet QR Setu greeting. Real capability arrives later.
CONSUMER FEATURES ACTIVATE UNDER MY QR SETU. Marriage Biodata is the first one. Others will
follow: engagement and wedding cards, event invitations, personal QR experiences. Each is a
capability the person switches on inside one identity. None of them is a separate account, a
separate login or a separate product.
Design implication: there must be a coherent visual and structural home for "my identity and
the things I have activated under it", and it has to feel correct when it holds one feature and
still feel correct when it holds five. Do not design Marriage Biodata as though it were the
whole product, and do not build a generic container for features that do not exist yet. Design
the first one well and make the seam for the second one obvious.
=====================================================================
SECTION 4: WHY MARRIAGE BIODATA, AND THE PROBLEM IT SOLVES
=====================================================================
In India, arranged-marriage introductions run on a document called a biodata: a one or two page
profile of a prospective bride or groom carrying name, age, date of birth, height, education,
profession, income, family details, community details, expectations and photographs.
HOW IT WORKS TODAY. A family writes the biodata in Word or Canva, exports it to PDF or a JPEG,
and sends it over WhatsApp to relatives, family friends, marriage bureaus and prospective
families. Those recipients forward it onward. A single biodata is often forwarded dozens of
times across hundreds of people over many months.
The document is the product. And the document is the problem:
1. IT IS FROZEN THE MOMENT IT IS SENT. A new job, a new photograph, a corrected detail: none
of it reaches anyone who already has the file. Families end up circulating three different
versions of the same person.
2. IT CANNOT BE RECALLED. Once sent, it is in hundreds of phones permanently. There is no
delete, no expiry, no way to stop it.
3. EVERYTHING IS DISCLOSED TO EVERYONE. A phone number, an exact date of birth, an income
figure and a home address sit in the same file as the name and the photograph, and they go
to every recipient equally, including strangers three forwards away.
4. PHOTOGRAPHS TRAVEL FURTHEST AND ARE CONTROLLED LEAST. A young woman's photographs end up in
unknown hands with no attribution and no recourse. This is the single most acute anxiety
families express, and it is the one the current process handles worst.
5. NOBODY KNOWS WHAT HAPPENED. Who opened it, who forwarded it, whether anyone looked at all:
the sender has no idea. The process is silent.
6. IT DOES NOT KNOW WHEN IT IS OVER. When the match is fixed, calls keep arriving for months
because the file is still circulating and nothing in it says the search has ended. This is
a real and specific pain that families describe unprompted.
7. MEETINGS ARE COORDINATED ENTIRELY OUTSIDE IT. Availability, calls and first meetings happen
over separate phone calls with no thread.
Be clear-eyed about the severity. Families are not miserable sending PDFs, and any design that
treats this as an agonising process will feel wrong to them. The acute pains are narrow and
specific: staleness after sending, photograph control, and calls continuing after the match is
fixed. Everything else is comfort. Design for the three, and let the rest be quiet convenience.
=====================================================================
SECTION 5: THE VISION - A DIGITAL MARRIAGE BIODATA IDENTITY
=====================================================================
Replace the file with a living, owned, controlled profile.
LIVING. Created once and edited forever. Every person who already has the link sees the
current version. There is never a version two.
CONTROLLED. The creator decides what each recipient sees. A basic tier for anyone with the
link: first name, age, city, education, profession, one photograph. A fuller tier released
to people the creator approves: full name, family details, more photographs, community
details. And a private tier that is never public at all: exact date of birth, contact number,
income, address.
REVOCABLE. Access can be withdrawn. A link can expire. Photographs are served small and
cropped until the creator approves someone, so a leaked image is worth little.
TRACEABLE. The creator can see that a profile was viewed and by roughly whom, which is
information they have never had before and consistently want.
ALIVE TO ITS OWN LIFECYCLE. The profile knows whether the search is open, in discussion, or
concluded, and it says so to everyone holding the link. Closing a proposal is a first-class,
celebrated moment, not a delete button.
BEAUTIFUL. This is a document families show to other families as a first impression of their
son or daughter. It must look markedly better than a compressed PDF. Presentation is not
decoration here, it is most of the perceived value.
Two things it must never become: a matchmaking service that suggests matches, and a public
directory of people. QR Setu hosts the profile and controls its distribution. It does not
introduce anyone to anyone.
=====================================================================
SECTION 6: THE OWNER AND THE SUBJECT ARE DIFFERENT PEOPLE
=====================================================================
This is the structural point most likely to be missed, and it changes many screens.
The person who holds the QR Setu account is very often NOT the person the biodata describes. A
father creates and manages the profile of his daughter. A brother manages his sister's. The
subject may have no QR Setu account, no app, and little involvement in the mechanics.
- The interface must never assume "this profile is about you". Copy, empty states and
confirmations have to work for "your profile" and "your daughter's profile" equally.
- The subject is told, once, over WhatsApp, that a profile about them exists, with a link to
view it and a way to ask for it to be removed. This is a courtesy and a safeguard. It is
NOT an approval gate and must never block or delay the person creating the profile.
- When the subject IS the account holder, that message is skipped entirely.
One QR Setu account holds one active Marriage Biodata. The account is the person's permanent
identity, and keeping it to one keeps that identity meaningful.
=====================================================================
SECTION 7: THE RECIPIENT, AND HOW SHARING BECOMES GROWTH
=====================================================================
The recipient experience is where this product either grows or does not.
A recipient receives a link over WhatsApp and taps it. They are in a mobile browser, on a
phone, with no app installed and no account. They see the profile immediately. That is the
whole requirement, and nothing may be placed in front of it.
The link preview matters enormously, because it is what a person actually sees in the chat
before deciding to tap. It should look considered and trustworthy, and it must never expose a
photograph or a private detail in the preview itself.
From that page, conversion to a QR Setu Consumer should feel useful rather than advertised:
- "View in the QR Setu app" for a richer experience
- "Create one for yourself or a loved one"
- "Create your own digital marriage profile"
Design these as calm, contextual invitations, never as banners, interstitials or anything that
interrupts reading. A recipient who is only looking at a profile should be able to ignore every
one of them without effort.
BE REALISTIC ABOUT WHO CAN CONVERT. Most people who receive a biodata are parents, relatives
and family friends who will never create one. The two moments where the invitation genuinely
lands are: a prospective family who are themselves searching for someone, and the closed
proposal page, where a viewer arrives to find the search concluded. That second one turns the
product's success state into its best acquisition surface, and it deserves real design
attention rather than an error page.
A closed proposal must never show a dead link or a 404. It should say warmly that the search
has concluded, thank the viewer, and offer them the option to begin their own.
=====================================================================
SECTION 8: ONBOARDING
=====================================================================
The flow is: WhatsApp OTP, then set a PIN or Face ID, then arrive.
- Sign-up is by WhatsApp one-time code. Not email, not a password, not a social login.
Families in this market trust WhatsApp and use it constantly, and email is a barrier.
- A PIN or biometric lock follows, protecting a personal profile on a shared family phone,
which is common. It must be recoverable, because a forgotten PIN on a phone-number account
is otherwise a locked door.
- Before anything else, the person says how they intend to use QR Setu: for a business, or as
a consumer. That single choice routes them into entirely different journeys. A consumer must
never be walked through business setup steps such as brand, industry or catalogue.
- The consumer path is deliberately short: verify, secure, claim a personal address, arrive.
=====================================================================
SECTION 9: THE PROACTIVE PRINCIPLE, APPLIED HONESTLY
=====================================================================
QR Setu should feel alive rather than like a filing cabinet. On the consumer side that means
the product notices things and offers useful next steps: a profile that has not been updated
in months, a photograph that could be added, an approval request waiting, a proposal that has
been open a long time.
Three hard limits, and they matter more here than on the merchant side:
1. NEVER FABRICATE AN INSIGHT. Only surface something the product actually knows and the
person can verify. A recommendation with nothing behind it destroys trust in every real one.
2. NEVER INFER SOMETHING SENSITIVE. Do not suggest wedding vendors, photographers or venues on
the basis of a biodata. Inferring that a marriage is approaching, and acting on it
commercially, is a serious overreach and is explicitly out of bounds.
3. EARN EVERY INTERRUPTION. Prefer a quiet in-app prompt to a notification. A nudge a person
learns to ignore does not become neutral, it spends the mechanism permanently.
=====================================================================
SECTION 10: WHERE THE MARKETPLACE FITS, EVENTUALLY
=====================================================================
The same QR Setu account that holds a person's identity also lets them browse and buy from QR
Setu merchants. Over time a consumer is a customer: they order, they save vendors they like,
they reorder.
That is navigation between two parts of one account, not a merging of data. The biodata is
never marketplace content, is never listed, and is never used to target anything. Keep the
relationship in mind as a reason the identity is worth having, and design nothing for it in
this round.
=====================================================================
SECTION 11: PLATFORMS AND LANGUAGES
=====================================================================
- Native Android and native iOS, from one React Native and Expo codebase, plus the same
product reachable on the web. All are first-class and ship together.
- The recipient page is a separate web surface, because it must open instantly for someone
with no app, and it must produce a proper link preview.
- Three languages are mandatory and equal: English, Hindi and Marathi. Marathi is not an
afterthought here, it is the primary language of the first market. Design layouts that
survive Devanagari, which sets taller and longer than Latin, and never rely on a label
fitting in a fixed width.
=====================================================================
SECTION 12: WHAT TO PRODUCE IN THIS ROUND
=====================================================================
Do not design screens. Produce:
1. A short statement of the DESIGN DIRECTION for the consumer side: how it should feel, and
how that differs from the merchant product, in your own words.
2. The INFORMATION ARCHITECTURE for the consumer app: the primary surfaces, what lives under
My QR Setu, and how a second consumer feature would slot in later without a restructure.
3. The NAVIGATION MODEL for a consumer, and your reasoning.
4. A view on how the RECIPIENT PAGE should relate visually to the app: same system, different
context, and where it should deliberately differ.
5. The DISCLOSURE MODEL as an interaction concept: how a person understands and controls what
each recipient can see, without it feeling like a permissions console.
6. OPEN QUESTIONS. Anything ambiguous or missing above. Flag it rather than assuming it. This
list is a required deliverable, not an optional one.
Round 2 will bring the detailed feature requirements and the screen list.Round 2 — answers and the first screens
Round 1 delivered prototype/my-qrsetu/Direction.dc.html: direction, IA, navigation, recipient page, disclosure, lifecycle, proactive, and 14 open questions each carrying a default. What it settled, what it corrected in round 1's prompt, and the two defaults taken rather than decided are recorded in Consumer decisions §6.
Round 2 answers all 14 and asks for the first five screens, in the order round 1 itself proposed.
text
QR SETU: CONSUMER MARRIAGE BIODATA
ROUND 2 OF 2 - ANSWERS, THEN THE FIRST SCREENS.
Round 1 is accepted. The direction, the information architecture, the navigation model, the
recipient page genre, the disclosure model and the lifecycle all stand as you proposed them.
Three things you reached independently match decisions already taken on the engineering
side: the single reservation table for people and businesses, one profile per SUBJECT with an
identity holding more than one, and consent as a logged declaration plus an honoured removal
path rather than a gate. Build on all of it.
Two corrections you made to round 1 are accepted, and both were right:
- The consumer home must not report a person's creations in merchant language. Scans this
week, total scans and shares are wrong on a biodata. Those numbers become access facts:
who is waiting, who was released, what is still private.
- The onboarding intent fork chooses a STARTING JOURNEY, not a permanent type. One account,
one address, both halves available. Adding the other half later is a normal action.
=====================================================================
SECTION A: ANSWERS TO ALL FOURTEEN OPEN QUESTIONS
=====================================================================
Q1 LAWFUL BASIS AND PHOTO CONSENT. Your default, with one addition.
The account holder makes an explicit declaration at publish that they have the subject's
agreement. It is logged with a timestamp. The subject receives one WhatsApp message with a
view link and a removal link. ADDITION: a removal request is honoured within 72 hours and
is NOT subject to the account holder's approval. The owner is told it happened; they cannot
refuse it. Design the removal confirmation for the subject, and the notice the owner sees.
Q2 DOES BASIC CARRY A PHOTOGRAPH. YES, ONE, and this overrides your recommendation.
You were right that round 1 contradicted itself, and right to flag it. The resolution goes
the other way for a product reason you could not have weighed: a matrimonial biodata with no
photograph does not get opened or forwarded, and the entire growth loop depends on a
recipient finding the page worth passing on. A text first impression is a worse artefact
than the PDF it replaces.
THE MECHANISM YOU ALREADY SPECIFIED IS WHAT MAKES THIS SAFE, so this is a smaller change
than it looks. Basic carries ONE photograph served exactly as you described the pre approval
case: small, cropped, quiet attribution, short lived address, no direct file link. Full
resolution stays behind approval, still with no download control. A leaked basic image is a
400px crop tied to the release that produced it, which was the point of the gating.
Two things do not move:
- THE WHATSAPP LINK PREVIEW CARRIES NO PHOTOGRAPH. This is not a disclosure tier decision,
it is a cache permanence one: WhatsApp caches a preview and revocation can never reach
it. Your round 1 proposal for the preview stands exactly as written.
- The family can remove the basic photograph in one tap and publish a text only profile.
The default is one photograph; the choice remains theirs.
Q3 PROVING IDENTITY WITHOUT A REGISTRATION WALL. Your default, unchanged.
Viewing needs nothing, ever. Requesting the fuller tier asks for a name, a relationship and
a WhatsApp number confirmed by one code. Authenticate intent, never curiosity.
Q4 MARRIAGE BUREAUS. Your default. Out of scope as a TYPE.
A bureau is a normal released person with a longer expiry. No bureau account, no shelf, no
listing, no directory. Design the release list so a bureau reads clearly as one.
Q5 ONE ACTIVE BIODATA PER ACCOUNT. Your default, and it matches the schema.
One profile per SUBJECT. An identity may hold more than one subject. The free plan caps
subjects at one, and that cap is a plan setting rather than a structural limit, so a family
plan is a configuration change later and never a migration.
Q6 IS IT FREE. Your default, provisionally, and it does not gate these screens.
Free to create, share and conclude. Paid covers what costs us or scales with use: per person
links beyond a handful, activity detail, extra photographs, additional subjects. NEVER the
ending, and NEVER the privacy. Locked states come after the five screens below.
Q7 PDF EXPORT. Yes, deliberately limited, exactly as you proposed.
One page, basic tier only, watermarked with the link and the date, no private fields, no
full photographs. It exists to be the polite answer to a request we cannot refuse.
Q8 LANGUAGES. Your default.
UI in English, Marathi and Hindi, all three equal. Profile CONTENT is authored in one
language the family chooses, with an optional second they write themselves. We never machine
translate a person's own sentences. The page states which language it is in.
Q9 BOTH HALVES ON ONE NUMBER. Your default, and this corrects round 1.
One account, one address, both halves available. Onboarding chooses where a person starts.
Q10 SHARED NAMESPACE. Your default, and it is already the engineering decision.
One reservation table for people and businesses. Permanent, never transferable, and the same
word for it in both journeys. A released address is never re-claimable by anyone.
Q11 WHAT TRACEABILITY SHOWS. Your default.
For a released person: name, when, how many times. For the basic link: a count, a city where
the network offers one, and a plainly stated limit that we cannot know who they were. Never
imply more resolution than we have.
Q12 RELEASE LIFE AND REOPENING. Your default, and the second half matters most.
Ninety days, extendable in one tap, lapsing quietly rather than mid conversation. Reopening
a concluded search is allowed and STARTS WITH ZERO RELEASES, always. Nothing old comes back.
Q13 WHATSAPP FOR URGENT NOTIFICATIONS. Your default.
In app for everything. WhatsApp for exactly two events, access requested and removal
requested, on a template the family sees before it is ever sent.
Q14 THE FOUR SEEDED PERSONAL KINDS. Your default.
Contact card folds into the identity itself. Invitation, birthday card and intro card become
Available capabilities: visible, described, locked. Nothing is hidden and nothing is deleted.
=====================================================================
SECTION B: ONE PLATFORM CONSTRAINT THAT CHANGED SINCE ROUND 1
=====================================================================
There is no app store listing on day one. The company is registering organisation developer
accounts and the D-U-N-S verification has not completed, so neither store carries the app yet.
Android ships as a signed APK downloaded from qrsetu.com, and the same product is reachable on
the web.
DESIGN CONSEQUENCE, and it is small but it must not be missed: any "View in the QR setu app"
control must lead to the web app or the download, NEVER to a store page. A dead store link in
the highest intent position on the recipient page is worse than no control at all.
=====================================================================
SECTION C: THE FIVE SCREENS, IN YOUR ORDER
=====================================================================
Design mobile and desktop for each. Every state named below is required, not optional. Where a
state is missing from the design it must be flagged rather than assumed.
1. IDENTITY HOME (My QR setu, on the centre button)
Identity header with the address and its QR, then the activated capability card, then what
is Available, then identity settings.
States: one activated capability, in each lifecycle status (open, in discussion, concluded)
· nothing activated yet, which is the true first run · address just claimed and nothing
published · loading · error.
2. BIODATA CONTENT EDITOR, with tier markers
The profile itself, edited field by field, each field showing which of the three circles it
sits in. The field level control is reached from one quiet line, never from the top.
States: empty and starting · partly complete · complete · editing a live profile that people
already hold, which must make the consequence visible · validation on a required field ·
saving and saved.
Copy must work for owner-is-subject and owner-is-not-subject. Address the person holding the
phone, name the subject explicitly, and never use the second person for the subject.
3. PEOPLE AND ACCESS, with a request arriving
Who holds a link, who was released, what expires when.
States: nobody yet · a basic link shared and opened · a request waiting, which is the state
to design most carefully · released people with expiry dates · an expiry approaching · a
release withdrawn · a subject removal request, which the owner cannot refuse.
4. RECIPIENT PAGE, basic and released
The document genre: one column, generous margins, real typographic hierarchy, no chrome
competing with the person. Read like good stationery.
States: basic tier with NO photograph · released tier with photographs · a request submitted
and pending · a link that has expired · a link that was withdrawn · loading.
Also design the WhatsApp link preview card itself: first name only, a neutral line naming
what it is, the wordmark. No surname, no age, no city, no face, no count of anything.
5. THE CONCLUDED PAGE
The celebrated ending, and the product's single best acquisition surface, because the viewer
who reaches it is often a family still searching.
A warm line that the search has ended, thanks for their part in it, and one calm invitation
to begin their own. Never a dead link, never a 404, never a photograph.
=====================================================================
SECTION D: WHAT TO FLAG RATHER THAN ASSUME
=====================================================================
Any state above that you believe should not exist, any field that needs a decision we have not
made, and anything in Section A that conflicts with what you found in the prototype. Round 1's
open questions list was the most useful thing it produced. Keep the habit.Round 2R — the reset, and why it was needed
⚠ ROUND 2 PRODUCED A PARALLEL MINI-APP, AND THE PROMPT CAUSED IT
Round 2 created prototype/my-qrsetu/ holding Identity · BiodataEditor · PeopleAccess · BiodataPage · Concluded, plus its own ds-base.js, icons.js, image-slot.js, support.js and a new biodata-core.js — none importing consumer-data.js, and with no entry added to qr-registry.js.
The prompt is the cause. Round 1 had understood the integration perfectly: "This prototype already carries a consumer app, and it already carries the seam this brief needs" and "One account, two halves. The buying half already exists and does not move." Round 2 opened with "Round 1 is accepted" and then replaced that frame with a screen list — "THE FIVE SCREENS, IN YOUR ORDER. Design mobile and desktop for each." It asked "what screens can I design" and got exactly that.
What round 2 never said, in full: it never named prototype/consumer/, never named a single reusable module, never mentioned the design system, the existing onboarding, the consumer lifecycle, the feature-activation model, or the screen-to-screen journey — and never once said "extend the existing app rather than build a new one", in either round.
⚠ Folder-local ds-base.js is NOT the defect — every folder in this project has its own (admin-panel, marketplace, mobile-console, desktop-console, setu-card, dealership). The defect is that My QR Setu was built as a sibling product when round 1 had established it is one of two halves of a single consumer account.
The standing rule this establishes for every future consumer feature: a design prompt must carry the existing product's structure, not only the new feature's requirements. Feature context without product context produces a parallel product every time.
text
QR SETU: CONSUMER MARRIAGE BIODATA
ROUND 2R - RESET. STOP DESIGNING SCREENS. STUDY THE EXISTING APP FIRST.
Round 2 went wrong and the fault is in the prompt you were given, not in your work. You were
asked for five screens and you produced five good screens. You were not told the thing that
mattered most: QR setu already HAS a consumer application, and Marriage Biodata is a feature
being added to it, not a product being built beside it.
WHAT WENT WRONG, CONCRETELY
`prototype/my-qrsetu/` is now a parallel mini application. It carries its own ds-base.js,
icons.js, image-slot.js and support.js, and a new biodata-core.js that does not import
`prototype/consumer/consumer-data.js`. Its five screens have no navigation relationship to
`ConsumerHome.dc.html`, and no code type was added to `prototype/consumer/qr-registry.js`,
whose own header says a new code type is a DATA ENTRY there rather than a change to any screen.
Your round 1 direction had this right and we lost it in round 2. You wrote: "This prototype
already carries a consumer app, and it already carries the seam this brief needs", and "One
account, two halves. The buying half already exists and does not move." Return to that.
=====================================================================
THE GOVERNING PRINCIPLE
=====================================================================
EVERY MARRIAGE BIODATA SCREEN MUST EXIST BECAUSE OF A USER JOURNEY, NOT BECAUSE WE NEED
ANOTHER SCREEN.
The feature must feel as though it was ALWAYS part of QR setu. A person using the consumer app
should not be able to tell where the existing product ends and this feature begins.
Ask "where does this feature naturally belong in the existing QR setu consumer experience",
never "what screens can I design for Marriage Biodata".
=====================================================================
STEP 1: STUDY. DO NOT DESIGN ANYTHING IN THIS STEP.
=====================================================================
Read these before proposing anything. They are the product you are extending.
prototype/consumer/consumer.prompt.md the persistent consumer context
prototype/consumer/ConsumerHome.dc.html the home section stack and the tab bar
prototype/consumer/Account.dc.html the account and profile structure
prototype/consumer/consumer-data.js the seed module, the personal kinds, HOME_SECTIONS,
CONSUMER_TABS, and the pure functions screens use
prototype/consumer/qr-registry.js the QR type registry and its RESERVED list
prototype/consumer/ds-base.js the shared base every consumer screen imports
prototype/consumer/icons.js the icon set actually in use
prototype/consumer/image-slot.js the image component and its geometry contract
prototype/consumer/qr-toast.js the toast pattern
prototype/consumer/confirm-delete.js the destructive confirmation pattern
prototype/consumer/Notifications.dc.html how the app already returns a person to a thing
prototype/consumer/OrderCode.dc.html an existing personal code surface, the closest prior art
prototype/chat-core.js chat, shared with the merchant side
prototype/my-qrsetu/Direction.dc.html your own round 1 direction, which stands
_ds/qr-setu-design-system-37245d93-4fa1-42d0-b765-53a7664d5129/ tokens, styles, the bundle
ONE CONTRADICTION TO RESOLVE FROM THE CODE, NOT FROM EITHER DOCUMENT. consumer.prompt.md
describes five tabs, Home, Chats, Saved, Orders and Account, with Scan as a floating action.
Your round 1 direction describes four tabs around a centre button whose slot is reserved for
new capability. Read CONSUMER_TABS in consumer-data.js and tell us which is true today. Do not
assume either. If the centre slot does not exist yet, say so, because the navigation
recommendation depends on it.
=====================================================================
STEP 2: MAP THE JOURNEY. STILL NO SCREENS.
=====================================================================
Produce a journey map in this shape:
EXISTING CONSUMER JOURNEY -> ENTRY POINT -> MARRIAGE BIODATA -> USER ACTIONS -> STATES
-> EXIT AND RETURN PATH -> EXISTING CONSUMER EXPERIENCE
Answer all twelve, each naming the EXISTING screen or module involved:
1. Where does a consumer DISCOVER Marriage Biodata? Which existing surface introduces it?
2. How do they CREATE it, and from which existing entry point?
3. How do they MANAGE it afterwards, and from where?
4. How does it APPEAR within My QR setu?
5. How do they PREVIEW it before anyone sees it?
6. How do they PUBLISH it?
7. How does SHARING work, and which existing share pattern does it reuse?
8. How do RECIPIENTS access it, and how does that route resolve through qr-registry.js?
9. How do RECIPIENT ACTIONS come back to the consumer, through which existing surface?
10. How do NOTIFICATIONS return the person to the app, using the existing Notifications list?
11. How is the feature CLOSED or archived, and where does the person land afterwards?
12. How would a SECOND consumer feature follow the same path with no restructure?
=====================================================================
STEP 3: THE INTEGRATION INVENTORY
=====================================================================
Before any screen, produce two lists.
REUSED. Every existing component, module, pattern, token, layout rule and interaction you will
use unchanged. Name the file. Cover at minimum: the tab bar and where this feature sits in it,
the card contract and its fixed meta block, image geometry and tileGeometry, the section stack
and its self hiding rule, the bottom sheet pattern, the registration sheet, toasts, destructive
confirmation, the notification list, and the icon set.
NEW, WITH JUSTIFICATION. Anything you must introduce, each with one sentence saying why the
existing pattern genuinely cannot carry it. A new pattern with no justification is a defect.
The bar is high: this feature should mostly be composition.
Also state explicitly WHERE THE FILES BELONG and why. My QR setu is a half of the consumer
account rather than a separate product, so make the case for the folder you choose rather than
inheriting the one round 2 created. If files should move, say which and where.
=====================================================================
STEP 4: WHAT TO DO WITH THE EXISTING ROUND 2 OUTPUT
=====================================================================
Do not delete anything yet. Assess each of the five screens against the journey map and tell us,
per screen, whether it survives as designed, survives with rework, or should be replaced by an
extension of an existing screen. Some of that work is good and should be carried forward into
the right place rather than thrown away.
=====================================================================
DELIVERABLE FOR THIS ROUND
=====================================================================
A document, not screens: the corrected navigation fact from step 1, the twelve journey answers,
the two inventory lists, the file placement recommendation, and the per screen verdict on round
2. Plus open questions, which were the most useful thing round 1 produced.
DESIGN NOTHING UNTIL THIS MAP IS AGREED. The screens come after, and they will be faster and
better because the vocabulary will already be fixed.Round 3 — build, inside the existing app
Round 2R returned prototype/my-qrsetu/Integration.dc.html: an integration map, no screens. It is accepted. Verified independently against consumer-data.js, which confirms its three load-bearing claims — the three existing entry points, PERSONAL_KINDS[0] already being Marriage biodata, and the centre button already being occupied by CONSUMER_MORE_TOOLS.
What the foundation already provides, measured
prototype/consumer/consumer-data.js already models this feature's spine, and the round-2 design reinvented most of it:
| Already exists | Line |
|---|---|
PERSONAL_KINDS[0] = { id: 'biodata', label: 'Marriage biodata' } | :817 |
| A live demo record with slug, status, scans, shares | DEMO_CREATIONS :825 |
CREATION_STATUS = live · draft · ended | :830 |
HOME_SECTIONS.yourCards — "Your QR setu" | :736 |
HOME_SECTIONS.create — "Make something of your own" | :741 |
CONSUMER_MORE_TOOLS.create → ?sheet=create | :966 |
ACCOUNT_GROUPS — "a new destination is one entry" | :980 |
And the module's own doctrine: "Each is ONE record with a slug, a status and its own scan count, so create → share → track is a single loop rather than three features… A new kind is an entry here and nothing else."
text
QR SETU: MARRIAGE BIODATA
ROUND 3 - BUILD, INSIDE THE EXISTING CONSUMER APP.
Your integration map is accepted in full. Build from it. Two questions it left for us are
answered below, one correction is added that the map did not catch, and everything else
stands as you specified it.
=====================================================================
THE TWO QUESTIONS YOU LEFT
=====================================================================
Q1 DOES THE CENTRE BUTTON STAY THE MORE SHEET. YES, unchanged.
Promoting My QR setu into the centre while the identity holds ONE capability is premature,
and you said so yourself. Revisit when it holds three. The centre button renders as a
gradient plus, so it already reads as MAKE SOMETHING, and CONSUMER_MORE_TOOLS.create is
the natural door. Do not move scan or the order tools.
Q2 WHAT STOPS AN IDENTITY SLUG RESOLVING AS A SHOP.
Your registry finding is correct and it is a live defect, not a gap in this feature: the
setu_card matcher claims any first segment not in RESERVED and never asks what kind of
owner holds the slug, so qrsetu.com/vedaa-lahade opens VendorView today.
The two ordered data entries you propose are approved: biodata_share and biodata BEFORE
setu_card, since TYPES.find returns the first match.
The third case needs a server lookup and the answer already exists on the engineering
side: ONE reservation table for people and businesses, carrying the owner kind. Design the
identity matcher assuming that lookup exists and returns person or business. You do not
need to solve it in a matcher.
=====================================================================
ONE CORRECTION THE MAP DID NOT CATCH
=====================================================================
A STATUS VOCABULARY COLLISION. consumer-data.js already defines CREATION_STATUS as
live / draft / ended, and every creation renders that chip. Round 1 proposed a lifecycle of
open / in discussion / concluded. Two vocabularies for one concept is a duplicate source of
truth and it would land in creationStatus() and the biodata module at the same time.
THE RULE: the proposal lifecycle is a SUB STATE OF live, never a replacement for it.
A biodata is draft, then live, then ended, exactly like every other creation and using the
existing chip. While it is live it additionally carries open / in discussion / concluded.
Concluding sets the creation to ended. That keeps the shared card, the shared chip and
creationSummary() working with no change.
=====================================================================
WHAT TO BUILD, IN YOUR OWN ORDER
=====================================================================
1. THE DATA EDITS FIRST, each ending with the app still working.
qr-registry.js two type entries, placed before setu_card
consumer-data.js personal kind wiring, a notification kind, an action strip entry,
one ACCOUNT_GROUPS row
ConsumerHome.dc.html the creations meta becomes ACCESS FACTS rather than scan counts:
who is waiting, who was released, what is still private. A family is
not running a campaign and a scan count is not a result.
The create sheet hands off to the editor.
2. MyQRSetu.dc.html in prototype/consumer/, in the phone frame, reached from the three
entry points that already exist. Not a new tab, not a new floating action.
3. Biodata.dc.html in prototype/consumer/, content and people as sub views on ?view=,
following the Account.dc.html pattern.
4. BiodataPage.dc.html in prototype/setu-card/, the public document: all tiers, the closed
states, the concluded page and the link preview. Note in its header that everything else
in that folder is indexed and this page is noindex, so the folder holds two opposite
policies and each page states its own.
STUDY THESE FIRST. The recipient page is a sibling of the Setu Card in the same owner
namespace and it wears that folder's public chrome, so it should be composed from what is
already there rather than styled fresh:
prototype/setu-card/SetuCard.dc.html the public page shell, one column, the
identity block, the wordmark footer
prototype/setu-card/ds-base.js the shared base for public pages
prototype/setu-card/image-slot.js image geometry, the same contract the app uses
prototype/setu-card/open-in-app.js THE EXISTING "open in the app" affordance.
Use it rather than inventing a CTA. Note its
store links are stale, see below.
prototype/setu-card/card-composition.js how a public page assembles its blocks
⚠ open-in-app.js and qr-registry.js STORES both point at App Store and Play listings that
do not exist yet, because the apps are not published. On this page the affordance must
lead to the web app or the download, never to a store page. A dead store link in the
highest intent position on the recipient page is worse than no control at all.
5. biodata-core.js MOVED into prototype/consumer/ and importing consumer-data.js.
Then delete prototype/my-qrsetu/ds-base.js, icons.js, image-slot.js, support.js and the five
round-2 screens, once their content has been carried across. my-qrsetu keeps Direction,
Integration and the spec: documents only.
=====================================================================
REUSE, AND THE FOUR PATTERN BREAKS
=====================================================================
Your reuse list stands. Fix the four pattern breaks you named, and the loudest first: no
dark pill toasts, because qr-toast.js rules them out in its own first paragraph, and no
fifth copy of the shared base files.
ONE MORE REUSE THE MAP DID NOT NAME, and it removes work rather than adding it. The TODAY
section on the consumer home is already the proactive surface, and its row is a tinted icon
circle, a bold title, a secondary line and a right aligned action verb. Every biodata nudge
uses that row: a request waiting, a release expiring, a subject asking for removal. Do not
design a separate prompt surface on the biodata card.
=====================================================================
WHAT NOT TO DO
=====================================================================
No new navigation structure. No parallel consumer experience. No screen that exists only to
represent a feature. No intermediate step that does not carry a decision. No new pattern
without a written reason. If an existing component already answers a requirement, use it and
say which one.
If anything here is unclear or conflicts with what you find in the code, ASK rather than
assume. Every wrong assumption at this stage is expensive later, and the code wins over
either document.Round 7 — the fields the market expects and our registry lacks
Measured 2026-08-30 by fetching marathibiodatamaker.com, a static Marathi biodata generator doing ~18K organic clicks/month from a Domain-Trust-7 domain, zero paid traffic. Its field list is the market's own definition of a complete Marathi biodata, and ours is missing a whole cluster.
The finding: eight of its fields are the kundli-matching inputs (gotra, devak, rashi, nakshatra, charan, nadi, gan, manglik) and our spec had deferred horoscope as "a file, not a field." That deferral is wrong for this market: these are what a family screens on before it ever calls. Plus mama and soyare, both culturally load-bearing and both absent.
text
QR SETU: MARRIAGE BIODATA
ROUND 7 - THE MISSING FIELDS. EXTEND THE REGISTRY, DO NOT REDESIGN ANYTHING.
This is an additive round inside prototype/consumer. No new screen, no new navigation, no new
pattern. Everything below is entries in the existing field registry plus the rendering they
already imply.
WHERE THIS COMES FROM. We fetched marathibiodatamaker.com, a static Marathi biodata generator
carrying about 18 thousand organic clicks a month from a domain with almost no authority. Its
field list is the market's own definition of a complete Marathi biodata. Ours is missing a
cluster of it, and the gap is not cosmetic: these are the fields a family reads to decide
whether to make contact at all.
WHAT TO EXTEND, AND READ THESE FIRST
prototype/consumer/biodata-core.js the field registry, tiers, groups, the copy resolver
prototype/consumer/Biodata.dc.html the editor, where a new group needs its section
prototype/setu-card/BiodataPage.dc.html the public page, where a new group needs a pattern
prototype/consumer/consumer-data.js the seed module, for the two demo subjects
prototype/my-qrsetu/biodata.spec.md the spec, which this round amends
=====================================================================
1. A NEW GROUP: kundli
=====================================================================
Eight fields, all at the RELEASED tier, in this order:
gotra Gotra
devak Devak, the family totem. Maharashtrian specific and asked for by name.
rashi Rashi, the moon sign
nakshatra Nakshatra
charan Charan, the quarter of the nakshatra
gan Gan
nadi Nadi
manglik ALREADY EXISTS. Move it into this group so the cluster reads as one thing.
WHY RELEASED AND NOT BASIC, AND THIS IS THE NON OBVIOUS PART. Nakshatra plus charan narrows a
birth time to roughly a six hour window inside a repeating monthly cycle, and combined with the
published age that reconstructs an approximate date of birth. The exact date of birth is a
private field on purpose. Publishing the full cluster openly would leak, by inference, the one
thing we hold back. At released tier the family has already approved that recipient, which is
the same judgement they make when releasing a phone number.
ACCEPT THE COST RATHER THAN HIDING IT: this will generate more access requests, because a
family screening on kundli must ask first. That is the correct trade and the people and access
view already handles a request well.
PRESENTATION. The public page already renders community and horoscope as a divided key value
panel. The kundli group joins that panel rather than getting a new pattern. Any field the
creator left empty is absent, with no label and no placeholder, exactly as every other optional
field behaves.
=====================================================================
2. TWO FAMILY FIELDS, BOTH RELEASED
=====================================================================
mama Maternal uncle. Name and place. In a Marathi biodata the mama is named as a
matter of course, and its absence reads as an omission rather than a choice.
soyare Related surnames. The families already connected by marriage.
WHY IT MATTERS, because it is not obvious to anyone outside the practice:
families read this to check for gotra and kul conflicts before proceeding. It is
a screening field, not a courtesy list.
Names and surnames only. Never a phone number, never an address.
FATHER AND MOTHER OCCUPATION NEED NO NEW FIELD. The family person model already carries a
detail line per person, so an occupation is what the family writes there. Make the editor hint
say so rather than adding two more inputs.
=====================================================================
3. RELIGION AND CASTE, AND TWO SMALL ADDITIONS
=====================================================================
religion BASIC tier. Free text.
caste BASIC tier. Free text.
placeOfBirth released. Part of the horoscope cluster in practice, and harmless alone.
bloodGroup released. Conventional in Indian biodata and low sensitivity.
RELIGION AND CASTE ARE BASIC, WHICH IS THE OPPOSITE OF THE KUNDLI DECISION ABOVE, AND THE
DIFFERENCE IS THE POINT. The kundli cluster is released because it leaks a birth date by
inference. Religion and caste leak nothing inferential: they are categorical, they are the
first thing a family screens on, and holding them behind a request would generate an access
request for every single viewer while answering the question they came with. Put them where
they do their job.
THEY ARE FREE TEXT, NOT A PICKER, AND THIS IS A HARD REQUIREMENT.
A picker is a controlled vocabulary, a controlled vocabulary is a filterable axis, and a
filterable axis is one step from a searchable directory of people by caste. QR setu does not
build that, ever. Free text also means we never maintain a caste taxonomy, which would force us
to decide whose list, which spellings and which hierarchy, none of which we have any business
deciding.
So: no dropdown, no autocomplete, no suggestions list, no normalisation, no grouping, no count,
no filter and no sort on either field, on any surface, now or later. The creator writes what
their family writes on paper. They sit in the community group beside the community line that
already exists.
THE INTRO FIELD IS NOT A REPLACEMENT. Families expect these as labelled lines, in the standard
place, because a recipient reading their fortieth biodata knows where to look.
=====================================================================
4. WHAT WE ARE DELIBERATELY NOT ADDING, AND WHY
=====================================================================
Do not add these even though the reference site has them. If a later round proposes any of
them, this section is the reason to point at.
COMPLEXION. It is on almost every traditional biodata and we are still not building an input
for it. A labelled field makes the product the vehicle for colourism, and "the market expects
it" is exactly the reasoning that keeps it alive. A family who wants to say something about
appearance can write it in the intro field. We will not give it a label, a dropdown or a place
in the template.
A PICKER, A FILTER OR A BROWSE SURFACE FOR RELIGION OR CASTE. The fields themselves are in
scope and specified in section 3. What stays out is every mechanism that would turn them into a
taxonomy: no dropdown, no autocomplete, no normalisation, no counts, no filter, no sort, and
above all no browse or search over people. The reference site organises its entire navigation
around religion. We do not, because consumer content is never discoverable in QR setu.
INCOME. Stays private and unreleasable. A number invites filtering on the wrong axis.
EXACT DATE AND TIME OF BIRTH. Stays private. See the reasoning in section 1: the kundli cluster
is at released tier precisely so it does not reconstruct this.
=====================================================================
5. THE DEMO SUBJECTS
=====================================================================
Fill the new fields for one subject and leave them empty on the other, as you already do with
LinkedIn. That is what makes the conditional rendering visible: a page with a full kundli panel
and a page with no panel at all, neither of which shows an empty frame.
=====================================================================
6. WHAT NOT TO DO
=====================================================================
No new screen. No new group in the editor beyond the kundli section. No new presentation
pattern on the public page. No change to the tier model, the share model or the lifecycle. If
any field here seems to need something the existing patterns cannot carry, say so rather than
inventing it.Round 8 — the opening block
⚠ This round also CORRECTS round 7's kundli tier split. Send both together, or send this after.
Round 7 put all eight kundli fields at released on a blanket privacy argument. That was too coarse, and measuring the market's own section order showed why: the spiritual block LEADS the page, so a basic tier with a gap where it should be is wrong.
Split on what actually leaks birth time:
| Field | Tier | Reason |
|---|---|---|
religion · caste · gotra · devak · kuldaivat | basic | Lineage and clan facts, derived from no birth data |
manglik · rashi | basic | Low cardinality. Manglik is the most-screened field after religion |
nakshatra · charan | released | The actual leak. 27 × 4 = 108 combinations ≈ a six-hour window |
gan · nadi | released | Each derives from nakshatra, so together they narrow it to ~3 |
placeOfBirth | released |
text
QR SETU: MARRIAGE BIODATA
ROUND 8 - THE OPENING BLOCK. THE MOST PERSONAL PART OF THE PAGE.
Every traditional Marathi biodata opens with a blessing: a deity, a saint, a symbol, or a line
of text. Families choose it deliberately and it carries real meaning. This round designs that
opening properly. It is optional, it sits above everything else, and it should be the warmest
thing on the page.
READ THESE FIRST
prototype/consumer/biodata-core.js the field registry, tiers, groups
prototype/consumer/Biodata.dc.html the editor
prototype/setu-card/BiodataPage.dc.html the public page, where this block leads
prototype/consumer/image-slot.js the image component and its geometry contract
prototype/consumer/consumer-data.js the seed module
=====================================================================
1. THE NEUTRALITY REQUIREMENT, AND IT IS ARCHITECTURAL
=====================================================================
DO NOT MODEL THIS AS "RELIGION -> LIST OF GODS". That shape bakes in assumptions we have no
business making, and it is the same reason religion and caste are free text in this product.
Three things make the naive model wrong, and all three are visible in the market:
a. IT IS NOT ONLY DEITIES. Reference collections carry Ganesha AND Shivaji Maharaj, Swami
Samarth and Gajanan Maharaj, the Om symbol, and shlokas set as text. Deities, saints,
historical figures, symbols and words are four different kinds of thing.
b. A RELIGION TAB LIST IS A TAXONOMY, and any list we ship is a statement about who counts.
Six tabs excludes somebody, always. Whoever is missing reads it as a decision about them.
c. A FAMILY DEITY IS OFTEN NOT IN ANY LIST. A kuldaivat can be a specific local temple form
that no stock collection will ever carry. That family is the one who cares most.
SO THE MODEL IS: a creator composes an OPENING from one or more EMBLEMS. An emblem is an image,
or a piece of text, or both, with an optional name. Where it came from is metadata for
searching, never structure. Call it the opening or the invocation, never "god" or "religion" in
any identifier, table, field or component name.
Tradition tags exist ONLY to help someone find something quickly, they are FLAT and additive,
nothing is keyed off them, and no part of the product ever infers anything about a person from
one. Adding a tradition must be a data entry, exactly like adding a personal kind.
=====================================================================
2. WHAT TO DESIGN
=====================================================================
ASK THE RIGHT QUESTION. Not "choose a god image". Something closer to how families actually
think: whose blessing does this biodata begin with. The question sets the tone for the whole
feature and a generic one makes it feel like an icon picker.
FOUR WAYS TO COMPOSE AN OPENING, all first class, none secondary:
a. FROM THE COLLECTION. Browse or search. Tradition chips filter, they do not gate: the whole
collection is reachable without choosing one, and there is no step that asks a person to
declare a religion before they can look.
b. TEXT ONLY, AND MAKE IT BEAUTIFUL. A line like the Ganesh invocation, set in real type
rather than pasted as a clip art image, is what a printed biodata actually does and it
will look better than any stock graphic. Devanagari is a first class case here, not an
afterthought. Offer a few well set presets and let the family write their own line.
c. THEIR OWN IMAGE. The murti from their home, their kuldaivat's temple, a photograph they
already treasure. This is the option that matters most to the family a collection cannot
serve, and it must not feel like a fallback.
d. NOTHING. Absent, with no empty frame and no placeholder, exactly like every other optional
part of this page.
USE THE KULDAIVAT WE ALREADY HAVE. The registry carries `kuldaivat`, the family deity. If the
creator has filled it, offer it first when they open this: "you named <kuldaivat> as your family
deity, start with that?" Nobody else does this and it is the difference between a picker and
something that pays attention.
MORE THAN ONE, AND ORDER MATTERS. A family may open with Ganesha and then their kuldaivat,
because Ganesha is traditionally invoked first. Allow a small number, let them be reordered, and
make the order visible in the preview rather than implicit.
EACH EMBLEM CAN CARRY WORDS. An optional name and an optional line of text beneath it. Some
families want the image alone, some want the shloka, some want both. Support all three.
PREVIEW IT WHERE IT LIVES. Not a grid in a modal. Show the opening rendered at the head of the
actual biodata as they compose it, because that is the only view that tells them whether it
feels right.
=====================================================================
3. CONTROL, AND ONE HARD RULE
=====================================================================
The whole block is optional and independently switchable. Turning it off leaves nothing behind:
no header, no divider, no gap.
HARD RULE: the opening is at the BASIC tier when it is shown at all, because it is the head of
the page and everyone with the link sees it. That is not a reason to make it compulsory. A
family who wants a private biodata with no opening simply switches it off, and that must be as
easy as choosing one.
=====================================================================
4. WHERE IT SITS
=====================================================================
At the very top of the public page, above the photograph hero. Measured against how the market
orders a biodata, the spiritual block leads and ours currently does not. This round fixes that
order as well as adding the block.
=====================================================================
5. FLAG THESE BACK RATHER THAN SOLVING THEM
=====================================================================
a. WHERE DOES THE ARTWORK COME FROM. A shipped collection is licensed artwork and we have not
sourced any. Stock images pulled from the web are a copyright problem on a real product.
Tell us how many emblems a good first collection needs and we will commission or license
them. Do not design around imaginary assets without saying so.
b. AN UPLOADED IMAGE IS USER CONTENT ON A PUBLIC PAGE, so it is a moderation surface. Say what
the page needs for that, and assume a report path exists.
c. IF A TEXT PRESET NEEDS A SCRIPT WE HAVE NO FONT FOR, name it. We ship Devanagari and Latin.Round 9 — the language pass, the person model, and seeding the artwork
⚠ SECTION 3 OF THIS ROUND IS SUPERSEDED BY ROUND 10
Round 9 proposed seeding the emblem collection from public-domain scans. The owner rejected that on 2026-08-31: no third-party dependency, and the artwork itself was not liked. Round 10 commissions original SVG instead, which is better on coherence, theming, print and storage.
Sections 1 and 2 of round 9 stand — the language pass and the person model are unaffected. Do not paste section 3. It is kept because this page records what was sent, and editing a sent prompt destroys that record.
⚠ A PROCESS ERROR IN ROUND 8, RECORDED BECAUSE IT IS GENERALISABLE
Round 8's tier correction for the kundli cluster was written in a :::warning block in this page's prose, outside every ```text fence. The gate validates prompt blocks; prose around them is commentary. So the correction was never in anything pasteable and Claude Design never saw it.
A decision that is not inside the prompt block does not exist. Every decision in round 9 is inside the block, including the ones that correct earlier rounds.
text
QR SETU: MARRIAGE BIODATA
ROUND 9 - THE LANGUAGE PASS, THE PERSON MODEL, AND SEEDING THE ARTWORK.
Three things, in priority order. The first is the largest remaining gap in the whole feature: this
is a Marathi-first product and nothing renders in Marathi yet.
READ THESE FIRST
prototype/consumer/biodata-core.js the field registry, tiers, groups, EMBLEMS, FAMILY_LAYOUTS
prototype/consumer/Biodata.dc.html the editor
prototype/consumer/biodata-family.js the family layouts and the person parse
prototype/setu-card/BiodataPage.dc.html the public page
prototype/consumer/consumer-data.js the seed module
=====================================================================
1. THE LANGUAGE PASS. THIS IS THE PRIORITY.
=====================================================================
Your own flag 5 says every surface states its content language and the layouts were written for
Devanagari lengths, but nothing renders in Marathi or Hindi. That is the largest gap left, and
it is larger than any remaining field.
THE DISTINCTION THAT MATTERS MOST, AND IT IS EASY TO MISS: a Marathi UI is not a Marathi
biodata. Translating our English labels produces a page that is grammatically Marathi and
culturally foreign. The labels must be THE ONES FAMILIES ALREADY USE on paper.
Where a conventional Marathi label exists, use it rather than a translation. Some are not
translations at all: the conventional label for the maternal uncle line, for the related
surnames, for the clan totem and for the family deity are words families say, and a literal
rendering of our English will read as a form written by somebody outside the practice.
Render three languages: Marathi, Hindi, English. Marathi is the reference, not the afterthought.
WHAT TO CHECK RATHER THAN ASSUME, because Devanagari behaves differently:
a. LINE LENGTH. Devanagari runs longer than Latin for the same meaning and sets taller. Every
label, chip, tile, tab and button must be checked at its longest Marathi string, not its
English one. Say which ones break.
b. THE SHIROREKHA AND DESCENDERS. Conjuncts and matras extend above and below the baseline, so
tight line heights that look correct in Latin clip in Devanagari. The portal hit exactly
this: a fixed line height cut multi-line Devanagari labels.
c. THE FAMILY DRAWING. The tree and vine layouts wrap text inside an SVG. Devanagari names and
detail lines will be longer. Confirm the wrapper handles them or say it does not.
d. NUMERALS. Ask rather than decide: Marathi biodatas are inconsistent about Devanagari
numerals versus Latin for height, age and dates. Tell us what the reference material does
and what you recommend, and flag it as a question.
e. MIXED SCRIPT. A Marathi page will carry Latin inside it: a LinkedIn URL, an English degree
abbreviation, a company name. Check that mixed runs do not break alignment.
THE OPENING PRESETS ARE ALREADY DEVANAGARI, so they are the one part already right. Use them as
the type reference for everything else.
CONTENT LANGUAGE IS THE FAMILY'S CHOICE AND IS NOT TRANSLATED. We never machine translate a
person's own sentences: the UI is in three languages, the content is in the one the family
wrote. The page already states which. That rule does not change.
=====================================================================
2. THE PERSON MODEL: STOP ENCODING PEOPLE IN A DELIMITED STRING
=====================================================================
Round 5 made `siblings` a `·` separated string parsed into people, and round 7 confirmed the
same string carries a parent's occupation on the detail line. Three layouts and the vouching
list all parse it.
CHANGE IT TO STRUCTURED DATA. An array of people, each with a relation, a name, a detail line
and an order. The editor writes objects; nothing splits on a delimiter.
WHY, AND IT IS NOT STYLE:
- It breaks the first time a family writes a name containing a comma, and the parse takes the
text before the first comma as the person.
- It cannot be validated, so nothing can tell a family their entry did not parse the way they
meant.
- Every consumer re-implements the split, so the four readers can disagree.
- It is a typed structure encoded as text, which is the cheapest kind of debt to avoid now and
the most expensive to unpick after real families have typed into it.
The rendering does not change. Same three layouts, same tiers, same vouching list, same
degradation from fan to vine. This is the model underneath them.
=====================================================================
3. SEED THE EMBLEM COLLECTION. THE ARTWORK QUESTION IS ANSWERED.
=====================================================================
Your flag 1 asked for a decision before launch. Here it is.
SEED FROM PUBLIC DOMAIN NOW, COMMISSION LATER. The emblem model already makes that swap free:
every entry carries `art`, so replacing a public domain scan with commissioned line art is a
data change with no structural impact. Design for the swap, not around it.
WHAT IS USABLE, VERIFIED RATHER THAN ASSUMED:
- RAJA RAVI VARMA, died 1906, is public domain. Wikimedia Commons carries a dedicated
category of his Hindu deity paintings, and his oleographs are the visual grammar of Hindu
devotional print, so families already recognise them. This covers the pan Hindu deities
well: Lakshmi, Saraswati, Durga, Krishna, Rama, Ganesha.
- COVERAGE IS UNEVEN EXACTLY WHERE IT MATTERS MOST. Swami Samarth, Gajanan Maharaj and
Vitthal are the three you named as carrying most usage in Maharashtra and none is in that
corpus. Treat them as needing their own sourcing and say so on the tile rather than
silently shipping a weaker image.
FOUR RULES THAT ARE NOT NEGOTIABLE:
a. NEVER take images from the reference sites. Their gallery is their asset and copying it is
infringement. We are building the same kind of thing, not taking theirs.
b. ONLY public domain or CC0. Share alike licences are not usable in a bundled product
collection. Licensing is per file and never per category.
c. A PHOTOGRAPH OF A MURTI CAN CARRY ITS OWN COPYRIGHT even when the murti is ancient.
Paintings and lithographs are safer than photographs of sculpture.
d. EVERY EMBLEM CARRIES ITS SOURCE AND LICENCE in the data, next to the artwork. An asset
whose provenance is not recorded is one nobody can defend later.
AND ONE THING TO DESIGN FOR HONESTLY: a public domain seed will NOT be visually coherent.
Nineteenth century oils beside period photographs beside symbols is a mixed collection, and your
own point stands that line art in one visual family survives a 56px plate and prints. So design
the tile so a mixed collection still reads as deliberate, and tell us what the collection needs
to look coherent once commissioned.
PLATFORM ARTWORK IS NOT USER MEDIA. These are static, versioned platform assets on a public
path, not rows in the media table, which is owned per workspace, conversation or user. A user's
own uploaded emblem is user media and follows the normal path. Keep the two apart.
=====================================================================
4. WHAT NOT TO DO
=====================================================================
No new screen, no new navigation, no new pattern. No new fields in this round: it is a language
pass, a model correction and a data seed. If the language work reveals that a layout genuinely
cannot hold Marathi, say so and propose the smallest change rather than redesigning around it.Round 9 supplement — a real Marathi template, transcribed
A printable Marathi biodata template was obtained on 2026-08-31 and read directly. It answers round 9's own open question about numerals, gives the conventional label for every field, and disagrees with two fields we added. Paste this after round 9's block.
text
QR SETU: MARRIAGE BIODATA
ROUND 9 SUPPLEMENT - A REAL MARATHI TEMPLATE, TRANSCRIBED.
We obtained a printable Marathi biodata template and read it directly rather than describing it.
Use this as the reference for the language pass. It answers one question round 9 told you to
ask, and it disagrees with us on two fields.
=====================================================================
1. NUMERALS: ANSWERED. LATIN DIGITS, DEVANAGARI UNITS.
=====================================================================
Round 9 asked you to flag this rather than decide it. The template decides it:
उंची : 5 फूट 4 इंच Latin digits, Devanagari units
रक्तगट : एबी+ the blood group is TRANSLITERATED, not Latin
So: digits stay Latin everywhere (height, age, dates, year), units and words are Devanagari, and
a value that is an abbreviation rather than a number gets transliterated. Do not render
Devanagari numerals.
=====================================================================
2. THE CONVENTIONAL LABELS, VERBATIM
=====================================================================
These are the labels on the template, in its order. Use these words rather than translating
ours. Section headings are centred; labels sit left with the colons in one aligned column and
values after, which is the print pattern families recognise.
वैयक्तिक माहिती Personal information
नाव name
जन्म तारीख date of birth
जन्म वेळ time of birth
जन्म स्थळ place of birth
धर्म religion (the template prefills हिंदू)
जात caste
कुलदेवत family deity
गोत्र gotra
राशी rashi
नक्षत्र nakshatra
गण gan
नाडी nadi
मांगलिक manglik (a sample value is अंशिक (सौम्य), so this is not a yes/no)
उंची height
वर्ण complexion
रक्तगट blood group
शिक्षण education
नोकरी/व्यवसाय job or business
वेतन/उत्पन्न salary or income
कौटुंबिक माहिती Family information
वडिलांचे नाव father's name
वडिलांचा व्यवसाय father's occupation
आईचे नाव mother's name
आईचा व्यवसाय mother's occupation
बहीण sister
भाऊ brother
मामा maternal uncle
नातेसंबंध relations
संपर्क Contact
पत्ता address
मोबाईल नंबर mobile number
TWO LABEL NOTES THAT MATTER:
a. नातेसंबंध IS THE CONVENTIONAL LABEL FOR WHAT WE CALLED soyare, and it is broader than
"related surnames": it means relations. Use नातेसंबंध.
b. मांगलिक CARRIES A GRADED VALUE, not a yes or no. The template's own sample is
अंशिक (सौम्य), partial and mild. Our field must not be a boolean.
=====================================================================
3. THE OPENING IS CONFIRMED, AND ITS STRUCTURE IS SPECIFIC
=====================================================================
The template opens exactly as round 8 designed it, which is worth knowing because it validates
the block rather than merely permitting it:
an ornamental border
a Ganesha IMAGE, centred
॥ श्री गणेशाय नमः ॥ in words, centred, directly beneath the image
then the first section heading
So an emblem is an image AND a line of words together, stacked and centred, above everything.
That is one of the compositions round 8 already supports. Match that stacking rather than
placing them side by side.
=====================================================================
4. TWO FIELDS THE TEMPLATE DOES NOT HAVE, AND WE DO
=====================================================================
Report back rather than removing anything yet.
चरण ABSENT. The template carries राशी, नक्षत्र, गण, नाडी and मांगलिक but no charan.
देवक ABSENT. We added it as Maharashtrian specific, and this Maharashtrian template omits it.
Both may still be right, since one template is not the market. But check them against other
reference material and tell us whether either is genuinely optional or genuinely uncommon,
because a field nobody fills is a field that makes the editor longer for nothing.
=====================================================================
5. TWO FIELDS THE TEMPLATE HAS, AND WE REFUSE
=====================================================================
Stated so you do not re-propose them:
वर्ण complexion. On the template, and we still refuse it. This is now an evidenced
choice rather than an oversight: we know it is conventional and we are not
building an input for colourism.
वेतन/उत्पन्न income. On the template. Ours stays private and unreleasable.Round 10 — commission the emblem artwork as SVG
Decided 2026-08-31, and it reverses my earlier recommendation. I had proposed seeding the collection from public-domain scans. The owner's constraint — no third-party dependency — makes commissioned SVG better on every axis that matters:
| Public-domain scans | Commissioned SVG | |
|---|---|---|
| Third-party dependency | Yes | None. We own it |
| Visual coherence | ❌ mixed eras and media | ✅ one family |
| 56px plate, and print | ❌ raster | ✅ vector |
| Light and dark | ❌ baked in | ✅ takes our tokens |
| Storage | R2 assets, CDN path, provenance records | ✅ ships in the bundle |
⚠ This deletes plan task 1.13 entirely — there is no platform asset path to build if the emblems are SVG components. A family's own uploaded emblem is still user media and still follows media.
text
QR SETU: MARRIAGE BIODATA
ROUND 10 - COMMISSION THE EMBLEM ARTWORK AS SVG.
Round 8 shipped the opening block with every EMBLEMS entry carrying art: 'unsourced', and asked
how many a first collection needs. The answer is below, and the artwork is yours to draw rather
than ours to license.
READ THESE FIRST
prototype/consumer/biodata-core.js EMBLEMS, TRADITIONS, the opening model
prototype/consumer/Biodata.dc.html the composer, where a plate becomes a picture
prototype/setu-card/BiodataPage.dc.html the public page, where the opening leads
prototype/consumer/icons.js the existing icon set and its drawing conventions
_ds/qr-setu-design-system-37245d93-4fa1-42d0-b765-53a7664d5129/styles.css tokens
=====================================================================
1. START WITH THREE, NOT TWENTY FOUR
=====================================================================
Draw three first and stop. They are deliberately three different difficulty classes, and if the
hardest one does not work we want to know that before twenty more exist:
GANESHA figurative, seated, the most recognised and the least forgiving
OM pure symbol, the easiest, and the type reference for the rest
SWAMI SAMARTH a portrait of a specific person, the hardest of the three
Show all three at 56px, at hero size, in light and dark, and on the opening block's own wash.
Then wait. The rest of the list is below so you can see where it is going, not so you can draw
it now.
=====================================================================
2. HOW TO USE ANY REFERENCE IMAGES WE SEND, AND THIS IS A HARD RULE
=====================================================================
We may paste reference images. Use them for TWO things only:
a. ICONOGRAPHIC CORRECTNESS. Which attributes, which posture, which vahana, which weapon.
This is traditional and ancient and belongs to nobody.
b. STYLE DIRECTION, described in words before you draw. Tell us what you are taking:
"flat, two tone, front facing, heavy outline" is a direction. A composition is not.
NEVER reproduce, trace or closely follow a specific image. Iconography is public domain and
fixed by tradition, so any correct Khandoba resembles any other correct Khandoba, and that
similarity is the subject rather than copying. What is protected is a particular artist's
expression: their linework, their palette, their composition. Stay on the first side of that.
If a reference is the only place you can find an attribute, take the ATTRIBUTE and draw it your
own way.
=====================================================================
3. THE STYLE
=====================================================================
One visual family across all of them, because a mixed collection is what we are avoiding.
- SVG, drawn as components, not raster and not traced.
- Legible at 56px and dignified at hero size. If a detail disappears at 56px it should not be
in the drawing.
- Colour through TOKENS, never hardcoded, so light and dark both work and the collection
re-themes with the product. Saffron is available and should not be the only note.
- Reverent rather than cute. These sit at the head of a page about somebody's daughter. No
caricature, no rounded-mascot styling, no winking.
- Consistent weight, consistent level of detail, consistent framing. A viewer scanning the
grid should see one collection.
=====================================================================
4. CORRECTNESS IS NOT A STYLE QUESTION
=====================================================================
A wrong attribute count, a wrong vahana or a wrong posture is not a stylistic liberty. Families
notice instantly and read it as carelessness about their faith. If you are unsure of an
attribute, SAY SO and leave it out rather than guessing. We will get it checked.
Where a form is regionally specific, draw the regional one: Khandoba is the Jejuri form, Vitthal
is the Pandharpur form standing on the brick, Mahalakshmi is Kolhapur's Ambabai rather than a
generic Lakshmi.
=====================================================================
5. THE FULL LIST, 24, WITH THE ATTRIBUTES THAT MUST BE RIGHT
=====================================================================
DEITIES, PAN INDIAN
Ganesha elephant head, broken tusk, modak, mouse. Seated. Invoked first, always.
Tirupati Balaji standing, conch and chakra, the distinctive forehead namam, tall crown.
Krishna flute, peacock feather.
Shiva trishul, crescent, serpent, third eye.
Hanuman mace, mountain, kneeling or flying.
Lakshmi lotus, seated or standing, coins.
Saraswati veena, white, swan.
Dattatreya three heads, six arms, four dogs and a cow. Deeply Maharashtrian.
DEITIES, MAHARASHTRA, AND THESE CARRY THE MOST KULDAIVAT USAGE
Khandoba Jejuri form. Warrior on horseback, sword, Mhalsa beside him, a dog,
turmeric. This is the single most requested family deity in the market.
Vitthal Pandharpur form. STANDING ON A BRICK, hands on hips, conical crown, tulsi
mala. The hands on hips are the whole silhouette; get them wrong and it is
not Vitthal.
Tuljabhavani Tuljapur. Weapons, lion, the Mahishasura-slaying form.
Mahalakshmi Kolhapur's Ambabai specifically, not generic Lakshmi.
Renuka or Ekvira Mahur and Karla. A major kuldaivat across Maharashtra.
SANTS, THE VARKARI AND DATTA TRADITIONS
Swami Samarth Akkalkot. Seated, bearded, hand raised in blessing.
Gajanan Maharaj Shegaon. Seated, bare bodied.
Sai Baba Shirdi. Head cloth, robe, one knee raised.
Dnyaneshwar young, seated, a manuscript.
Tukaram veena or cymbals, standing.
HISTORICAL AND SOCIAL FIGURES
Shivaji Maharaj the jewelled turban, the beard, the sword.
Dr. B. R. Ambedkar suit, spectacles, a book. ⚠ READ SECTION 6 BEFORE TREATING THIS AS
OPTIONAL: he is the emblem an enormous number of Maharashtrian Buddhist
families would choose, and leaving him out has a meaning.
SYMBOLS
Om
Kalash the pot with coconut and mango leaves.
Samai the Maharashtrian standing oil lamp. Quietly the most secular of these.
Swastika the traditional Indian form.
=====================================================================
6. THE COLLECTION MUST NOT BE ONLY HINDU, AND THE REASON IS YOUR OWN
=====================================================================
In round 8 you wrote that on the reference site "four of the six tabs are visibly almost empty,
so the person behind them learns exactly what the product thinks of them." A collection of
twenty four Hindu emblems and nothing else reproduces that failure exactly, whatever the
tradition chips say.
So the first collection also carries, and these are NOT a second phase:
Ik Onkar (ੴ) Sikh
A cross Christian
Bismillah in calligraphy Muslim, if you can set it respectfully. If our fonts cannot, say so
rather than approximating it, and we will source the face.
Dhamma chakra Buddhist, alongside Ambedkar
Ahimsa hand Jain
Five is not parity with nineteen and we are not pretending otherwise. It is the difference
between a collection that is Hindu-majority because its market is, and one that says nothing
else exists.
=====================================================================
7. WHAT TO REPORT BACK
=====================================================================
The three trial emblems, at both sizes, in both themes. The style direction in your own words.
Any attribute you were unsure of and left out. Any script or glyph our fonts cannot set. And
your estimate of how many of the twenty four are genuinely drawable to this standard, because
we would rather ship twelve good ones than twenty four uneven ones.Maintenance
Anything Claude Design flags that turns out to be architecture rather than design goes to a QRS-### row first and reaches the design project only once decided, per the process in Screen Reviews. The two defaults taken rather than decided (Q2, Q6) are marked as such in Consumer decisions §6 and are reversible at no cost until screens are built against them.
⚠ And per round 9's own preamble: put decisions INSIDE the prompt block. Prose on this page is commentary the model never sees.
Round 11 — the WhatsApp OTP onboarding
This round leaves the Marriage Biodata feature and designs the door in front of it. Ten rounds built an identity, a profile, an access model and a public page, and every one of them assumes a person who is already signed in. The way they sign in is now decided — WhatsApp OTP, then a PIN, then the consumer landing — and not one screen of it exists.
⚠ THE TARGET IS prototype/onboarding/, WHICH ALREADY EXISTS AND ALREADY WORKS
Onboarding.dc.html and WelcomeStory.dc.html are built, and the repo's wizard is written for exactly this shape: stepsFor(type, authed) holds a per-account-type step list, so a consumer step order is a one-line change rather than a second wizard. Round 2's parallel-product failure (QRS-913) came from a prompt that named zero existing files. This one names them and says extend.
Three decisions inside the block are corrections rather than requirements, so they are stated in full there rather than referenced:
- The PIN is a device gate, not an onboarding step. Reasoning and the measurement behind it: Consumer onboarding assessment. Adding
'pin'to the step list is the obvious move and it is wrong, because a PIN is per device and an onboarding step runs once per account. - The copy must survive a channel swap. QRS-919: Meta's template approval is a queue we do not control, so the feature may launch on SMS and move to WhatsApp later. A screen that hardcodes the word WhatsApp becomes a lie on the fallback.
- Language is chosen before the number, not after. Round 9 made the product Marathi-first, and at the door there is no content language to infer one from yet.
⚠ PASTE ONLY THE BLOCK BELOW
Everything outside it is for the human reader and never reaches the model (the round-8 lesson). Every decision that must land is inside the fence.
text
ROUND 11 — CONSUMER ONBOARDING: WHATSAPP OTP, THEN A DEVICE PIN
WHAT THIS ROUND IS
Design the way a consumer gets INTO the app. Every screen you have built for My QR setu and
Marriage Biodata assumes a signed-in person. This is the door in front of all of it, and it does
not exist yet.
EXTEND THE EXISTING ONBOARDING FOLDER. DO NOT CREATE A PARALLEL ONE.
`prototype/onboarding/` already exists and already works. Read these before designing anything:
prototype/onboarding/Onboarding.dc.html the existing setup wizard
prototype/onboarding/WelcomeStory.dc.html the first-run story and the business/individual fork
prototype/onboarding/BrandSplash.dc.html the launch splash
prototype/onboarding/console-kit.js the folder's own kit
prototype/onboarding/ds-base.js the folder's design-system base
And read where the person LANDS, so the door opens onto the right room:
prototype/consumer/ConsumerHome.dc.html where a consumer arrives
prototype/consumer/MyQRSetu.dc.html the identity home
prototype/consumer/consumer-data.js the consumer domain module
prototype/consumer/biodata-core.js LANGUAGES, LABELS.ui, formatValue, langForContent
The engineering side mirrors this exactly: one wizard shell holds a per-account-type step list, so
a consumer flow is a different STEP ORDER through the same machine, never a second wizard. Design
it the same way. New screens belong in `prototype/onboarding/`, using that folder's kit.
THE FLOW, END TO END
language -> phone number -> 6-digit code -> name -> set a PIN -> consumer landing
Five steps before the landing. Each one has to earn its place, and one of them is not where you
would expect it. Read the whole brief before drawing.
STEP 0 — LANGUAGE, AND IT COMES FIRST
The product is Marathi-first. Round 9 established that the UI opens in the language the family
already writes in, via `langForContent(subject.contentLanguage)`. At the door there is no content
yet, so nothing can be inferred, and the device locale is NOT the answer: a Marathi-speaking family
very often holds a phone set to English.
So the first thing the app asks is the language, as a choice on the screen rather than a setting
somebody has to find. Three: मराठी, हिंदी, English. Every screen after it, including every error
and every hint, renders in that choice. It is changeable later from Account.
Design it as one quiet screen, or as the top of the number screen if that reads better. Show us
which you chose and why. It must not feel like a form.
STEP 1 — THE PHONE NUMBER
The number IS the account. There is no email, no password and no social sign-in on this path.
- India first: +91 preselected, but the country selector is present and works. Do not build an
India-only control.
- The number is typed once. There is no confirm-your-number second field.
- Validate on shape only, gently, and never block a legitimate number to satisfy a regex.
- Say what the number is FOR, in one line, before it is typed. A person handing over a phone
number wants to know who will use it. Ours is: to sign in, and to reach you when somebody asks
to see a profile. It is never shown to anybody who views a biodata.
- Do NOT write a privacy reassurance about what we will not do with it. State the use, not the
restraint. A denial introduces the worry it denies.
STEP 2 — THE CODE
A 6-digit code. Same OTP shape the product already uses.
** THE COPY MUST SURVIVE A CHANNEL SWAP. THIS IS A HARD REQUIREMENT, NOT A PREFERENCE. **
The code is delivered over WhatsApp. But WhatsApp business-template approval is an external
queue with no guaranteed date, so this feature may launch delivering the same code over SMS and
move to WhatsApp when approval lands. A screen that hardcodes "Check WhatsApp" becomes false the
day we fall back.
So: the delivery channel is a PROP with two values, `whatsapp` and `sms`, and every string that
mentions it reads from that prop. Draw both. The channel icon, the "sent to" line, the resend
copy and the "did not arrive" help all change; the layout does not.
States, all of them:
- sending
- sent, waiting for the code, with the number shown and an edit affordance back to step 1
- resend on a cooldown, with the remaining time visible rather than a dead button
- wrong code, with attempts remaining if there is a limit
- expired code
- too many attempts / rate limited, with what to do next and when
- verifying
- verified
** THE FAILURE NOBODY DRAWS AND EVERYBODY HITS: THE NUMBER HAS NO WHATSAPP ACCOUNT. **
On the WhatsApp channel this is a real and common outcome, and it is not "try again" — trying
again produces the same nothing. It needs its own state that says what happened and offers the
other channel. Design it.
STEP 3 — THE NAME
One field. `handle_new_user` fills nothing from a phone signup, so without this the account has no
name to address anybody by. Keep it to a single screen and make it skippable only if you can argue
why.
STEP 4 — THE PIN, AND IT IS NOT AN ONBOARDING STEP
Read this part carefully, because the obvious design is the wrong one.
A PIN is PER DEVICE, not per account. The same person on a second phone sets a new one. Onboarding
runs once per account. So a PIN cannot be an onboarding step without the two disagreeing the first
time somebody installs the app twice, and it is checked at every app open rather than once at
signup, which is an app-shell concern rather than a wizard concern.
** SO: DESIGN THE PIN AS A CONSUMER-TIER GATE, NOT AS A WIZARD STEP. **
- set-a-PIN, offered on first entry to the consumer surface, immediately after the wizard hands
off. It is a strong default and it is skippable, with a way back to it from Account.
- confirm-PIN
- enter-PIN, which is what a returning person sees when they open or resume the app
- forgot-PIN, which falls back to the OTP they already have
- biometric opt-in, offered AFTER a PIN exists and never instead of one. Face ID and fingerprint
unlock the same stored secret; they do not replace it.
** SAY WHAT THE PIN DOES, EXACTLY, AND NOTHING MORE. **
It protects the biodata from somebody holding the unlocked phone, which is a real and everyday
situation in a shared family device. It is not encryption and it is not account security. Do not
imply either. One honest line beats a reassuring one.
WHAT IS SETTLED AND MUST NOT BE REDESIGNED
- No email, no password, no Google, no Apple on the consumer path. The number is the account.
(Google remains on the MERCHANT path. Do not remove it there, and do not design a merchant
change in this round at all.)
- No slug step. A consumer's public address is claimed later, from My QR setu, deliberately.
Asking a person to name a public URL before they have seen the product is a wall.
- ANONYMOUS FIRST, AND THIS ONE IS NON-NEGOTIABLE. A person who scans a vendor's card must be
able to browse with NO account at all. Onboarding is reachable, never compulsory, and the
welcome story must not become a signup wall. Registration is demanded only when identity is
genuinely required: creating a biodata, chatting, ordering, tracking.
- The existing business/individual fork stays. It is what the routing reads.
- There is no App Store and no Play listing yet, so nothing anywhere may link to one. Any
"get the app" affordance leads to the web app or the APK download. A dead store link in a
high-intent position is worse than no control.
- No em dashes anywhere in any copy, label or example. Use a comma, a colon, parentheses, or two
short sentences.
WHAT THE STORY NEEDS
`WelcomeStory.dc.html` sells a shop: its scenes build a card and run a business. A person arriving
to make a marriage biodata is being shown the wrong product before they have chosen anything.
Design the consumer-side story. Same structure, same length, same progress dots, different reason
to be here. It ends at the same fork.
STATES, FOR EVERY SCREEN
Loading, empty, error, offline, and the in-between states named per step above. A screen without
its error state is half a screen. If a state cannot happen, say so rather than leaving it out.
REPORT BACK, RATHER THAN SOLVING SILENTLY
1. Does the PIN-as-device-gate model create any state the existing wizard cannot express? If it
does, name it precisely rather than working around it.
2. Where does the language choice belong: its own screen, or the top of the number screen? You
have both surfaces in front of you and we do not.
3. What does a person see if they close the app between the code and the name? They have an
account at that point and no name. Is that a resumable wizard, or does the landing handle it?
4. Anything in the existing onboarding folder that this round makes stale, or that already
answers a question above better than a new screen would.Round 12 — make the consumer flow reachable, and move the merchant onto the same spine
⚠ READ THIS BEFORE ASSUMING ROUND 11 FELL SHORT. IT DID NOT.
Opening Onboarding.dc.html shows Create your account · Continue with Google · Email, which reads like the WhatsApp work never landed. It landed. Measured in the file on 2026-08-31:
js
buildFlow(type) {
if (type === 'individual') return ['language', 'phone', 'otp', 'name'];
return ['auth', 'name', 'brand', 'industry', 'location', 'slug', ...];
}The consumer path is complete — a language step, a +91 phone step with a country picker, trilingual PHONE_COPY / OTP_COPY in mr / hi / en, effectiveChannel() driving every string off the otpChannel prop, OTP stages sending · sent · ratelimited · nowhatsapp · offline, a visible resend cooldown, three attempts, an edit-number affordance, a one-tap SMS fallback, and a handoff to PinGate.dc.html, which itself carries offer · set · confirm · biometric · enter · forgot.
type is internal state that defaults to 'business', and no prop exposes it. So the toolbar cannot reach any of it. The screen you see is the merchant auth step, which round 11 explicitly told Claude Design not to touch.
⚠ This is the same defect class as QRS-730 — nine consumer routes shipped in apps/mobile with zero inbound navigation, reachable only by typing the URL. Built and unreachable reads exactly like not built, and it costs a review pass every time. The first item in round 12 is a prop, not a screen.
The second item is a genuine product change rather than a correction: the merchant signs in with email or Google today, and email OTP is dead in production — Supabase returns a 535 SMTP authentication failure (QRS-285), so that field is a control that cannot work. The merchant moves onto the same phone-OTP spine the consumer now has.
⚠ The consequence, stated because it is not obvious from the screen: all seven existing Dev accounts are Google-only, with zero phone identities and zero passwords (QRS-910). Google therefore stays visible as a legacy path until every account has a phone identity. Removing it is a later, measurable step, not this one.
⚠ PASTE ONLY THE BLOCK BELOW
text
ROUND 12 — REACHABILITY, AND THE MERCHANT MOVES TO PHONE OTP
FIRST, WHAT NOT TO CHANGE
Round 11 is good work and most of it must survive this round untouched. Do not rebuild, do not
"improve", do not regress any of the following in prototype/onboarding/Onboarding.dc.html:
- buildFlow('individual') = ['language','phone','otp','name'] and the handoff to PinGate
- PHONE_COPY and OTP_COPY, trilingual mr / hi / en, read through pt() and ot()
- effectiveChannel() and channelOverride, and every string reading the channel off the prop
- the otpStage machine: idle, sending, sent, ratelimited, nowhatsapp, offline
- attemptsLeft, the resend cooldown with its visible timer, editPhoneNum, the SMS fallback tap
- the +91 default and the country picker
- the otpDemo and network props and their scenarios
- prototype/onboarding/PinGate.dc.html: offer, set, confirm, biometric, enter, forgot, the
attempt lockout, and its copy. The honesty of that copy is deliberate and stays exactly as
written: "It does not encrypt anything, and it is not account security, just this screen on
this device."
Everything below is additive or a swap inside the existing machine.
1. THE CONSUMER FLOW IS BUILT AND UNREACHABLE. FIX THAT FIRST.
`type` is internal state defaulting to 'business', and no prop exposes it. So opening the file
always lands on the merchant auth screen and there is no way to see the consumer sign-in at all.
The product owner reviewed round 11 and reported the WhatsApp work as missing, because from the
toolbar it is.
Add a prop:
audience: enum ['Consumer', 'Business'], default 'Consumer', section 'Scenario'
It seeds `type` on mount ('Consumer' -> 'individual', 'Business' -> 'business'). Default Consumer,
because that is the launch feature and the default view should show the work under review.
The general rule, worth carrying beyond this round: IF A FLOW HAS A BRANCH, THE BRANCH NEEDS A
CONTROL. A path with no way in is indistinguishable from a path that was never built.
2. THE MERCHANT MOVES TO PHONE OTP
The merchant currently starts at an `auth` step offering Continue with Google, an email field, and
"We will email you a 6-digit code". Replace that step with the SAME phone and otp steps the
consumer path uses. Same components, same copy tables, same channel-agnostic behaviour, same
states. One sign-in spine for the whole product.
buildFlow('business') becomes:
['language', 'phone', 'otp', 'name', 'brand', 'industry', 'location', 'slug',
'permissions', 'highlights', 'celebrate', 'dashboard']
- REMOVE the email field and its "we will email you a 6-digit code" line entirely. Not hidden
behind a toggle, not demoted: removed. Email delivery is broken in production and returns an
SMTP authentication failure, so it is a control that cannot work, and a control that cannot
work is worse than one that is absent.
- KEEP "Continue with Google", demoted to a quiet secondary below the phone step, labelled for
what it now is: a way back in for people who already made an account that way. Something like
"Signed up with Google before? Continue with Google". It is not the primary path any more and
must not be styled as one. Reason: every existing account was created with Google and has no
phone number attached, so removing it would lock all of them out. It comes out later, once
those accounts carry a phone identity.
- The language step now runs for merchants too. The launch market is Maharashtra on both sides
of the product, and a merchant whose phone is set to English may still want a Marathi console.
If you think the merchant should skip it, say so and why rather than deciding silently.
- The merchant copy stays the merchant copy. "One card for everything your business needs" is
right for a shop and wrong for a family, so the phone and otp steps need their existing
consumer copy PLUS a merchant reading, the same way every other surface in this prototype
already carries both readings. The purpose line especially: a merchant is told the number is
how customers reach them, a consumer is told it is how somebody asking to see a profile
reaches them. Those are different sentences and both are true.
3. PINGATE NEEDS THE LANGUAGE PASS, AND A THEME
Three gaps, all small, all worth closing now because this is the most repeated screen in the whole
product: a returning person sees it every single time they open the app.
- IT IS ENGLISH ONLY. Round 9 made this product Marathi-first and round 11 carried that through
the phone and otp screens, then stopped at the device gate. "Enter your PIN", "PINs didn't
match", "Too many attempts", "Forgot PIN?", the offer copy and the biometric copy all need
mr / hi / en, in the same shape as PHONE_COPY. It should open in the language chosen at the
language step.
- IT HARDCODES LIGHT. componentDidMount sets data-theme to 'light' unconditionally and there is
no theme prop, so the dark scheme cannot be reviewed at all. Every other screen in this folder
has one. Add it.
- THE AVATAR IS LATIN INITIALS ("VL"). Round 9 established, with a reason, that two Devanagari
letters read as noise inside a small disc and replaced initials with a person glyph everywhere
else. A person whose name is सानिका gets noise here. Use the same glyph treatment round 9
landed rather than a second answer to a question already decided.
4. STATES
Every new or swapped screen carries loading, empty, error and offline where they can occur. The
merchant phone and otp steps inherit the consumer ones, so this is mostly about making sure nothing
was lost in the swap: the merchant must reach ratelimited, nowhatsapp and offline exactly as the
consumer does.
5. REPORT BACK RATHER THAN SOLVING SILENTLY
1. Anything else in this prototype that is BUILT AND UNREACHABLE from its own controls. Item 1
is almost certainly not the only one, and it is the cheapest class of defect to find and the
most expensive to leave, because it reads as missing work.
2. Does the merchant flow lose anything real by dropping email? Name it rather than assuming not.
3. Should the language step run before or after the phone step for a merchant? You have both in
front of you.
4. Anything in WelcomeStory.dc.html that now contradicts a phone-first sign-in, given its scenes
were written for an email and Google world.Round 13 — the fork moves to the front, and the consumer story gains its vision
Round 12 was implemented correctly and completely. Verified in the files on 2026-08-31, not read off a changelog:
| Asked | Delivered |
|---|---|
an audience prop so the built flow is reachable | audience: Consumer | Business, default Consumer, seeding type on mount, with a ?type= override kept |
| merchant onto the phone-OTP spine | buildFlow('business') is now ['language','phone','otp','name','brand',…] |
| email removed | zero occurrences of "email" in the file |
| Google kept, demoted | showGoogleFallback, a bordered secondary at margin-top:auto, 44px target |
| PinGate trilingual | a full COPY table in mr/hi/en, lang() reading ?lang= then the prop, default मराठी |
| PinGate theme prop | theme prop, applyTheme() on mount and update |
| PinGate person glyph | done, and the round-9 reasoning is quoted in the code: "two Devanagari letters read as noise inside a small disc, so सानिका would get noise where VL got initials" |
⚠ TWO DEFECTS IN WelcomeStory.dc.html THAT NOBODY HAS REPORTED, FOUND WHILE READING IT FOR THIS ROUND
Scenes 1 and 3 are not variant-aware. The six scenes branch on biz at positions 2, 4 and 5 only, so a consumer reads, as the very first line of the product:
"Every business deserves a digital identity."
and then at scene 3:
"Like Aadhaar for you, QR setu is your business identity."
A family opening the app to make a marriage biodata is told twice that this is for businesses, once in the opening line. That is the same "wrong product before they have chosen anything" problem raised for item 3, already live inside the consumer variant.
And the fork being last makes variant unreachable for a real user. It defaults to Business, so a genuine first run plays the business story and only then asks which one you are. The consumer scenes exist and no first-time consumer can ever see them. This is QRS-925 again — built and unreachable — which is a second, independent argument for item 3 beyond the product one.
The recommendation for item 4, and it makes onboarding shorter rather than longer. Do not add a seventh scene. Scene 3 is already the identity beat and is currently showing business copy to consumers, so the vision screen is a repair of a scene that is wrong, not an addition. And moving the fork out frees bharatArt() — the radial hub of profession tiles orbiting the wordmark, which already carries an Individual node — so the vision scene reuses an existing, finished piece of art with a data swap. Net: the consumer story goes from six scenes to five.
⚠ PASTE ONLY THE BLOCK BELOW
text
ROUND 13 — THE FORK MOVES TO THE FRONT, AND THE CONSUMER STORY GAINS ITS VISION
Round 12 is correct and complete. Nothing in it is reopened. This round changes WHERE the audience
is chosen, fixes two scenes that were never made variant-aware, and gives the consumer story the
one thing it is missing.
Files: prototype/onboarding/WelcomeStory.dc.html (most of the work),
prototype/onboarding/BrandSplash.dc.html (what precedes it),
prototype/onboarding/Onboarding.dc.html (the sign-in it hands off to),
prototype/consumer/consumer-data.js (read PERSONAL_KINDS, see item 4).
1. AUTHENTICATION IS FINAL. GOOGLE IS A PERMANENT FALLBACK, NOT A LEGACY DOOR.
The decision, settled by the product owner:
- WhatsApp OTP is the PRIMARY and PREFERRED option, on both audiences. The reason is not
convenience: it captures the mobile number at the start, which is what later makes
communication, engagement and support possible at all.
- Google is the FALLBACK, offered permanently and to new people too, for when WhatsApp cannot
deliver: an unapproved template, an outage, a number with no WhatsApp account, a person who
simply prefers it.
- THERE IS NO EMAIL OPTION. No email OTP, no magic link, not now and not later. Round 12 removed
it and it does not come back.
Round 12 wrote the Google affordance as "Signed up with Google before?", which reads as a door for
old accounts only. That framing is now wrong. Re-copy it as a genuine second option, quieter than
the primary but not apologetic. Something in the register of "Or continue with Google". It stays
visually secondary; it stops being historical.
** THE CONSEQUENCE TO DESIGN FOR, WHICH IS EASY TO MISS: GOOGLE DOES NOT GIVE US THE NUMBER. **
The entire stated reason for preferring WhatsApp is capturing the mobile number. A Google
fallback that skips it silently discards the exact thing the primary path exists to collect.
So after a Google sign-in, the mobile number is still asked for, as its own step, before the
person reaches their landing. Design that step. Two readings needed:
- the ordinary one: they chose Google, we still need a number, say why in one line
- the honest one: if the reason they are on Google is that the code could not be delivered,
the number cannot be verified right now either. Show the step, accept the number, and say
plainly that it will be confirmed later. Do not pretend it was verified.
Say which of those two you think should be the default and why.
2. THE AUDIENCE IS CHOSEN FIRST, NOT LAST
Today the choice is scene 6 of 6, marked { final: true }. Move it out of the story entirely and put
it immediately after the splash:
Splash -> Choose how you want to use QR setu -> the story for THAT audience -> sign-in
- It is its own screen, not a scene. No progress dots, no autoplay, no skip: nothing about it is
a story beat, and a person cannot be advanced past it on a timer.
- Two choices, and keep the existing tile treatment from the final scene: Business in saffron,
Consumer in coral, each with a title and one line underneath. Those tiles are good; they are
being relocated, not redesigned.
- The consumer tile must not say "Marriage Biodata". This is a choice between two ways of using
the product, and naming one feature there would make the other capabilities look like
afterthoughts. Say what the audience is, not what the first feature is.
- The choice sets `variant`, and the story then plays LOCKED to it. Remove the sixth scene. The
business story keeps five scenes; the consumer story has five (see item 4).
- Back from the story returns to this screen. Choosing again is free and nothing is lost.
- Keep the `variant` prop and the `?variant=` override exactly as they are, for review.
** WHY THIS IS NOT ONLY A SEQUENCING PREFERENCE. ** `variant` defaults to 'Business', so a real
first-time consumer today watches the BUSINESS story and is only then asked who they are. The
consumer scenes are built and no first-time consumer can reach them. A branch with no control in
front of it is a branch nobody takes.
3. TWO SCENES WERE NEVER MADE VARIANT-AWARE. FIX THEM.
`scenes()` branches on `biz` at positions 2, 4 and 5. Positions 1 and 3 do not, so the consumer
variant currently shows business copy in both:
- SCENE 1, the opening line of the entire product: "Every business deserves a digital identity."
A family opening the app to make a biodata reads that first. It needs a consumer reading in all
three languages, in the same register: the promise is a personal digital identity that is
theirs, permanent, and theirs to share.
- SCENE 3 is the Aadhaar analogy: "Like Aadhaar for you, QR setu is your business identity."
This scene becomes the vision scene for consumers, item 4 below.
** DO NOT REUSE THE AADHAAR ANALOGY ON THE CONSUMER SIDE. ** For a business it is a metaphor
about business identity and it works. Applied to a PERSON it edges toward claiming we are a form
of identity document, which we are not, and Aadhaar is a sensitive comparison to make loosely
about an individual. The business scene keeps it. The consumer scene gets the hub instead.
4. THE CONSUMER VISION SCENE
The problem to solve, in the owner's words: the consumer story reads as a marriage-biodata app.
Scenes 2, 4 and 5 are all biodata. A person should finish this story understanding:
QR setu is my digital identity, and a growing set of useful personal QR things live inside it.
** IT IS SCENE 3, NOT A NEW SCENE 7. ** Scene 3 is already the identity beat in the narrative,
and on the consumer side it is currently showing the wrong copy anyway. Replacing it costs no
extra length: with the fork gone, the consumer story is FIVE scenes, one fewer than today.
** THE ART ALREADY EXISTS: REUSE bharatArt(). ** Moving the fork out frees it. It is the radial
hub of tiles orbiting the QR setu wordmark, with a glow at the centre, and it already carries an
'Individual' node. That visual grammar IS the message: one identity at the centre, many uses
around it. A ring of icons reads as a family; a list reads as a menu. No new artwork.
** THE NODES COME FROM THE DATA, NOT FROM A HARDCODED LIST. ** consumer-data.js has
PERSONAL_KINDS, whose own doctrine is that a new kind is a data entry and nothing else. Read the
ring from it so that adding a card type later updates this screen for free. Today that means
Marriage Biodata is one node among several, which is exactly the point being made.
Around the ring: My QR setu identity at or near the centre, personal QR tools, Marriage Biodata,
Engagement cards, Birthday cards, and one or two tiles that are deliberately UNLABELLED and
dimmed. The dimmed tiles are the curiosity: they say more is coming without promising a date or
naming a feature we have not built. Do not label them "coming soon".
** THE COPY DOES THE WORK, AND IT IS ONE LINE. ** Not a feature list. Something that says: one
identity, many things inside it. Write it in all three languages, and write it so that a person
who reads only this line still understands the product is bigger than the biodata they came for.
Marriage Biodata may be named in the art as a node; it must not be the subject of the sentence.
Concise beats complete. If a node makes the ring crowded at 390px, drop the node rather than
shrinking the type.
5. STATES AND CONSISTENCY
- The choose screen: default, both tiles pressed, and whatever it looks like on a narrow phone.
It has no loading or error state, and if you agree, say so rather than inventing one.
- Light and dark for everything new.
- All three languages for every new string. No screen writes its own Marathi.
- Reduced motion: the hub already respects it. Keep that.
- No em dashes anywhere in any copy, label or example.
6. REPORT BACK RATHER THAN SOLVING SILENTLY
1. Does the business story still read correctly at five scenes with the choice pulled out, or did
the final scene carry a closing beat that is now missing?
2. Where exactly does BrandSplash hand off, and does the choose screen belong inside it or as its
own file? You can see both and we cannot.
3. Your two readings for the Google number step in item 1, and which you recommend.
4. Any other scene, screen or branch in this folder that is reachable only by a prop and not by a
control. Item 2 is the second instance we have found this week and it will not be the last.Round 14 — the second visit, and one language choice instead of two
Round 13 landed correctly, including two improvements nobody asked for: final moved off the per-branch reading onto the last scene (their comment: marking it per branch "let one story dead end without a closing CTA"), and the Google path swaps the verification step rather than skipping verification. Full trace and the verified-correct list: Journey validation.
What this round closes is the two blockers and the top gap from that validation, and they turn out to be one question and one consolidation:
- QRS-929 + QRS-930 are the same missing question — is this account new, and is it new on this device? — asked at the OTP step and again at the PIN gate. Answer it once and both close.
- QRS-931 removes a step: one language control on the choose screen, carried forward as
?lang=, and thelanguagestep deleted from both flows.
⚠ The recurring shape, now stated as a standing rule in the block below. Four times in this feature a branch has existed in one layer and not the other — QRS-730 routing, QRS-918 AuthStep, QRS-925 the audience prop, QRS-929 the returning user. The question that would have caught all four is "what does the second visit look like?", and the control that makes it reviewable is a prop.
⚠ PASTE ONLY THE BLOCK BELOW
text
ROUND 14 — THE SECOND VISIT, AND ONE LANGUAGE CHOICE INSTEAD OF TWO
Round 13 is correct and nothing in it is reopened. The choose-first flow, the variant-aware scenes,
the consumer hub reading PERSONAL_KINDS, the Google fallback, the gnumber step with its unverified
warning, the trilingual PinGate: all of it stays. Two additions and one consolidation.
Files: prototype/onboarding/Onboarding.dc.html, prototype/onboarding/PinGate.dc.html,
prototype/onboarding/WelcomeStory.dc.html.
1. THE FLOW HAS NO SECOND VISIT, AND THAT IS THE BIGGEST GAP IN IT
Measured in Onboarding.dc.html: `existing` 0, `returning` 0, `accountExists` 0, `isNewAccount` 0,
`skipSetup` 0. `buildFlow` always appends 'name' after verification, and the business flow always
continues into brand, industry, location and slug.
So a person who reinstalls the app, or signs in on a second phone, is walked through the ENTIRE
setup again. A returning merchant is asked to create a slug they already have, which is write-once
and already printed on their QR codes.
** WITH PHONE OTP, SIGN UP AND SIGN IN ARE THE SAME GESTURE. ** Enter a number, enter a code. The
difference is not a screen the person chooses; it is an ANSWER THAT ARRIVES AFTER VERIFICATION.
So do not add a "Sign in" tab or a second entry point. Add the branch that follows the code.
THREE OUTCOMES, NOT TWO. After a code is verified the server says one of:
a. NO ACCOUNT for this number
-> the flow exactly as it is today: name, then the business steps if business.
b. ACCOUNT EXISTS AND SETUP IS COMPLETE
-> skip every setup step. Do not ask for name, brand, industry, location or slug again.
Go to the PIN gate, then the landing.
c. ACCOUNT EXISTS BUT SETUP WAS NEVER FINISHED
-> RESUME at the step they abandoned, with what they already gave still filled in.
This is the case `resume: On` already demonstrates for business. Make it a real branch
rather than a review fixture, and make it reachable for consumers too.
** WHAT A RETURNING PERSON SEES. ** They need to know they were recognised and which account they
are back in. Design that moment: it can be its own brief screen or a state inside the OTP success,
and you can see both surfaces so you decide. Whichever you choose, name the account (the person's
own name, or their business name for a merchant) rather than only saying "Welcome back", because
the useful information is WHICH account, not THAT there is one.
** THE SERVER'S ANSWER BEATS THE TILE THEY TAPPED, ALWAYS. ** A returning consumer may tap "For my
business" on the choose screen, or the reverse. The account already has a category and it wins.
Design what that looks like: it should be quiet, not an error, and it must not read as a failure.
They tapped a tile; we know better; we take them to their actual account.
(This is a real defect we already fixed once on the engineering side, where a returning consumer
was sent to the merchant console because the code trusted a device-local choice over the server.)
2. THE PIN GATE CANNOT TELL A NEW DEVICE FROM A RETURNING ONE
All five stages exist and are good. But `startStage` is a REVIEW PROP and there is no runtime
branch, so nothing decides which stage a real person lands on. A PIN is PER DEVICE, which is the
whole reason it was moved out of onboarding, so the cases are opposite:
just signed in, no PIN on THIS device -> offer, then set
(this covers a brand new account AND a returning person on a new phone or a reinstall.
The PIN they set on their old phone does not exist here.)
opening the app, session alive, PIN on this device -> enter
enter, and they cannot remember it -> forgot
** SO THE GATE HAS TWO DIFFERENT ENTRY POINTS AND THEY MUST NOT BE CONFLATED: **
- after sign-in, it is always offer/set
- on app open with a live session, it is always enter
`forgot` belongs only to the second. Make that split explicit in the screen rather than leaving it
to `startStage`.
The failure this prevents is specific and bad: a returning person on a new phone shown "Enter your
PIN" for a PIN that was never created on that device has exactly one way out, Forgot PIN, which
sends them through an OTP they completed sixty seconds ago.
3. EVERY NEW BRANCH NEEDS A CONTROL. THIS IS NOW A STANDING RULE.
Add the outcomes above to the scenario props so all of them are reviewable:
accountState: enum ['New', 'Existing, setup complete', 'Existing, setup unfinished'],
default 'New', section 'Scenario'
and let `resume` fold into it rather than standing separately.
** WHY THIS IS A RULE AND NOT A NICETY. ** Four times in this feature a branch has existed in the
code and been unreachable from the controls, and every single time it read as "not built" and cost
a review pass: the consumer sign-in flow before the `audience` prop, and now three account states
with no way to see any of them. A branch nobody can reach is indistinguishable from a branch
nobody wrote.
** ASK IT OF EVERY FLOW FROM NOW ON: WHAT DOES THE SECOND VISIT LOOK LIKE, AND CAN I SEE IT? **
4. ONE LANGUAGE CHOICE, NOT TWO, AND IT MAKES THE FLOW SHORTER
Today the story picks its language from `navigator.language`, and the only control is a 28px pill in
the header beside play/pause and theme. Most Indian Android phones report en-IN, so a Marathi family
reads the whole five scene story in English before the product ever offers them Marathi. That is the
first impression, in the launch market, in the wrong language. Then the story's exit CTA carries
?type= and ?ref= but no lang, and Onboarding's step 0 is the language step, so the choice is thrown
away and the question is asked again.
Do all four of these together:
- Put a REAL language control at the TOP OF THE CHOOSE SCREEN, as a proper segmented control,
not the review pill. Minimum 44px touch target. मराठी | हिंदी | English. It is the first thing
on the first interactive screen, which is what several large Indian apps already do, and it is
the right place because everything after it is language dependent.
- The choose screen may still use the device locale as its INITIAL GUESS. That is fine now,
because the control is right there and changing it re-renders immediately. What is not fine is
a guess with no visible control, which is what exists today.
- Carry it forward: the story CTA becomes Onboarding.dc.html?type=...&lang=...&ref=..., and
PinGate's landing link carries it into ../consumer/ConsumerHome.dc.html too. PinGate already
proves the pattern by reading ?lang=.
- DELETE the 'language' step from both buildFlow lists. Asked once, carried to the end.
5. FIVE SMALLER THINGS FROM THE SAME VALIDATION
a. THE GOOGLE NUMBER STEP IS SILENTLY SKIPPABLE. `skipGoogleNumber` goes straight to 'name'. The
entire reason WhatsApp is the preferred option is that it captures the mobile number, so a skip
with no consequence defeats it. Make the number REQUIRED on the Google path, with one
exception: if `deliveryFailed` is what pushed them to Google, accept it unverified (that state
is already built) rather than blocking them behind a channel that is not working.
b. THE HUB'S DIMMED TILES NEVER RENDER. In hubArtConsumer, `dim: !n[0]` is never true because
every node has an icon, so the opacity and dashed-line treatment fires for nothing. Round 13
asked for one or two deliberately unlabelled dimmed tiles as the curiosity device: more is
coming, without naming or dating anything. Add them as real nodes that set dim, or remove the
dim machinery. A mechanism that cannot trigger is worse than no mechanism, because it reads as
covered.
c. THE LANGUAGE PILL IS 28px, below the 44px minimum, on what is now the first interactive screen.
Item 4 replaces it, so this is closed by that, but do not reintroduce a sub-44px control.
d. `resume: On` HARDCODES `type: 'business'`, silently overriding the `audience` prop. Item 3
folds resume into `accountState`, which fixes it; make sure the new prop respects `audience`
rather than replacing it.
e. BrandSplash.dc.html HAS NO LINK OUT, so the clickable journey has no first step. Its own notes
correctly say it is a timed screen and app config, so this is not an implementation problem.
One link to the choose screen would make the whole flow walkable in review, which is worth more
than it costs.
6. REPORT BACK RATHER THAN SOLVING SILENTLY
1. Your call on the returning-person moment in item 1: its own screen, or a state inside the OTP
success? You can see both and we cannot.
2. For outcome (c), resume, is there any step in the business flow that is unsafe to resume into
partially filled? The slug step is the one we would worry about.
3. Anything in the business flow that should ALSO be skipped for a returning merchant beyond the
setup steps, or anything that must still run.
4. Any other branch in this folder reachable only by a prop and not by a control, now that you are
looking for them.