Appearance
Jewellery: daily rates & savings schemes
Status: ready to send · Target: project 633dc069… "QR setu prototype" · QRS-466 · covers both sides (vendor console + public card) in one document, deliberately
WHY THIS IS A SEPARATE SPEC AND COVERS BOTH SIDES
The owner's instruction: "I don't want us to design only the vendor/store side and assume the public Setu Card will naturally work." That instruction exists because we already made that mistake once — store-catalogue-spec.md specified the merchant surface and the public half went unspecified for a week (QRS-457). This document is organised by capability, both sides together, so the vendor screen and the customer screen are impossible to design apart.
1 · The pain point, in the vendor's words
A jeweller posts today's gold and silver rates to WhatsApp Status every morning. It expires in 24 hours, it is unsearchable, customers who missed it phone the shop to ask, and there is no history.
This is the strongest "why would I pay for this" story in the product so far, and it is nothing to do with cataloguing. It is a recurring daily reason for a customer to open the vendor's card, which is the one thing a digital catalogue does not give you.
And schemes are the second half. Malabar, Tanishq, Kalyan and Ranka all run monthly-instalment gold savings plans; a customer mid-scheme has no way to see where they stand without asking.
2 · ⚠ THE REGULATORY FINDING THAT SHAPES THE WHOLE DESIGN
The owner observed that these schemes run "half yearly or 11 months max". That ceiling is not a marketing choice. It is almost certainly a compliance artifact, and recognising it changes what we build.
Money a company takes in advance for the supply of goods is exempt from being treated as a deposit under the Companies Act 2013 and the Companies (Acceptance of Deposits) Rules only if it is appropriated against that supply within 365 days. Run a scheme past twelve months, or fail to adjust the advance, and it becomes a deposit — which brings deposit-acceptance compliance a private company generally cannot satisfy. Ten and eleven-month schemes exist to stay inside that window, and Tanishq restructured Golden Harvest in that era for related reasons.
⚠ Confidence: high on the pattern, and the legal detail must be confirmed by counsel before anything ships. It is recorded here because of what it implies architecturally, not as legal advice.
Three consequences that follow immediately:
- Scheme duration is a platform-enforced constraint, not a vendor free-text field. A
CHECKon months, not a text input. A vendor who types "18 months" must be refused, because the platform would otherwise be the surface on which a non-compliant scheme is advertised. - QRSETU must not take, hold or track the money in R1. Recording a customer's accumulated instalment balance means recording a financial obligation between two parties — the same exposure as the co-broking commission (QRS-454 R1), and it creates a dispute surface with no adjudication behind it. R1 displays the scheme; it does not run it.
- A guaranteed-return promise is the line not to cross. "Pay 11, get 12" framed as a return rather than a discount on goods is what attracts deposit-scheme scrutiny. The design must present the benefit as a discount or bonus against a purchase, never as interest or a yield.
3 · Architecture assessment — what fits, what is new
Schemes need NO new primitive. Three existing features compose
| The scheme's shape | Existing feature |
|---|---|
| A monthly instalment commitment over N months | subscriptions — "recurring customer commitments with pause and skip", on the recurrence primitive |
| The customer's accumulated position | khata — "running credit account per customer", on the balance primitive |
| The customer themselves | customers — on the party primitive |
So jewellery's composition becomes ['catalogue','party','ledger','balance','recurrence']. That is a data change to one industries row. ⚠ But note only the DISPLAY of a scheme is R1 (§2.2); the enrolment and balance-tracking those features would provide are exactly what must wait.
Daily rates ARE new — and deliberately NOT a primitive
A per-workspace, per-day, per-metal, per-purity published rate. Roughly (workspace_id, effective_on, metal, purity, rate_per_gram_minor), append-only, one row per metal and purity per day: two metals × three purities × 365 ≈ 2,200 rows per vendor per year. Negligible.
⚠ Applying our own gate honestly: ADR-0020 requires a new primitive to serve ≥3 industries. A daily published reference rate with history would plausibly serve a scrap-metal dealer, an agricultural commodity trader and a currency exchange — but none of those three exists among our 14 industries, so the justification is speculative and the gate correctly refuses it.
Therefore: a jewellery-scoped FEATURE with its own table, promoted to a primitive only when a second real industry needs it. This is the gate doing its job rather than being worked around.
⚠ THE CACHE PRESSURE IS NOW A PATTERN, NOT AN INCIDENT — THIRD INSTANCE
| # | Requirement | Wants |
|---|---|---|
| 1 | Scheduled launch offers (ADR-0025 D2) | A time boundary to change what renders |
| 2 | Metal-rate item pricing (QRS-465) | A mutable input to change what renders |
| 3 | Today's published rate (this spec) | A mutable input to change what renders |
Three independent requirements now push render-time dynamism onto a surface deliberately built to be static and edge-cached. That is a pattern deserving one answer rather than three special cases — and the good news is that two of the three are triggered by an explicit vendor action, which is strictly easier than a clock: the jeweller saves the morning rate → outbox → purge → re-render. One purge per day, at a moment a human chose. Recorded as QRS-467 for an ADR-0019/0025 amendment, because "the card is static" is now under pressure from three directions and should be restated deliberately rather than eroded.
⚠ A liability the vendor does not currently have, and we would be creating it
A WhatsApp Status rate is ephemeral and deniable. A dated, structured, historical record on a platform is evidence. A customer who screenshots this morning's published rate and is then quoted higher at the counter has a grievance that the vendor's current workflow simply does not generate.
So the rate must be presented as indicative and time-stamped, never as a quotation — visibly "as of 09:15 today, indicative, subject to confirmation at the counter" — and the design must carry that, not bolt it on as fine print. This is a genuine new exposure for the vendor and it is created by the feature, so it belongs in the design rather than in a terms page.
Charting under Tier 0
ADR-0019 D11 fixes Tier 0 at 0 KB — the card renders and looks finished with JavaScript disabled. So a price-history chart must be a server-rendered inline SVG, not a JS charting library. That is a constraint worth welcoming: an inline SVG sparkline is a few hundred bytes, edge-cacheable, and works on every device.
4 · The prompt to paste into Claude Design
Design a jewellery daily-rates and savings-schemes capability for QRSETU, covering both sides: the vendor's mobile console and the customer-facing public Setu Card. Add new screens under
prototype/mobile-console/for the vendor side andprototype/service-card/for the customer side, matching each folder's existing structure. Do not modify any existing file.The pain point, which is the whole reason this exists. An Indian jewellery shop owner posts today's gold and silver rates to WhatsApp Status every single morning. It disappears in 24 hours, it cannot be searched, customers who missed it telephone the shop to ask, and no history is kept. If a jeweller can publish the rate once on their Setu Card and their customers can see today's rate and the trend over time, that is a daily reason for a customer to open the card. It is a far stronger reason to adopt than a digital catalogue.
VENDOR SIDE — publishing the rate must take under 15 seconds, once a day, one-handed. This is a morning ritual competing with typing a WhatsApp message, so it has to be faster than that or it will not be used.
- Today's rates entry for gold at 24K, 22K and 18K, and silver, per gram. Rupees, Indian digit grouping.
- Pre-fill yesterday's values so the vendor edits two digits rather than typing four numbers.
- Show what changed since yesterday, per metal, as the vendor types, so a mistyped rate is obvious before saving.
- A clear "published at HH:MM" confirmation, because the vendor needs to know their customers are now seeing it.
- A history list they can correct. Fat-fingering a rate is inevitable and it will be publicly visible.
- Do NOT design an automatic market-rate feed. The rate published is the vendor's own retail rate, which is their commercial decision, not a market price.
VENDOR SIDE — schemes. A jeweller runs monthly-instalment gold savings plans. Design the screen where they define one: a name, a monthly instalment amount, a duration in months, the benefit at maturity, and terms. ⚠ Duration is constrained to a maximum of 11 months and the UI must enforce it, not merely suggest it. This is a legal constraint on this kind of scheme in India, not a preference, so a vendor attempting a longer duration must be refused with a plain-language explanation. ⚠ The benefit must be expressed as a discount or bonus against a jewellery purchase — never as interest, a return, or a yield. Design the copy accordingly. ⚠ The vendor does NOT enrol customers or track their balances in this design. The scheme is published so customers can see it and get in touch. Do not design enrolment, instalment tracking, payment collection or a customer balance.
CUSTOMER SIDE — the public Setu Card. This is a server-rendered browser page reached by scanning a QR code or tapping a WhatsApp link. The visitor has no account and must never be asked for one. Mobile-first at 360x740, light theme.
- Today's rates, prominent and above the catalogue. For a jewellery card this is the single most visited element on the page and it should be treated as the headline, not a footnote.
- A timestamp and an explicit "indicative" qualifier. The rate must read as "as of 09:15 today, indicative, please confirm at the store" — a published rate a customer can screenshot must not read as a firm quotation. Design this as part of the component, not as fine print.
- The change since yesterday, up or down, with the direction unmistakable without relying on colour alone.
- History and trend: a compact 7-day view and a 1-month view, plus the ability to see the underlying daily values. A simple line or sparkline is right; do not design a trading-style chart with candlesticks, zoom or crosshairs — the audience is a retail customer deciding whether to visit a shop this week. ⚠ The chart must be a static image, drawn on the server. It has to render with JavaScript completely disabled, so no interactive tooltips, no hover states, no client-side chart library. Design within that constraint.
- A share action for today's rate specifically, because forwarding the rate to WhatsApp is exactly what the customer will want to do, and it is how the card spreads.
- The scheme, presented so a customer understands it in one read: the monthly amount, the duration, what they get at the end, and a single "I'm interested" contact action. No signup, no enrolment form, no payment.
- Design the empty and sparse states, which will be common: a jeweller who has published no rate yet, a jeweller with only three days of history and therefore no meaningful trend, and a jeweller with no scheme at all. In each case the section must be absent or self-explanatory, never a broken-looking chart.
Also show the jewellery catalogue itself on the customer side, since the rates sit above it: collections rather than plain categories (Bridal, Daily wear), one-of-one pieces, a weight-and-purity specification block, and every item priced on enquiry — a jeweller's item price is computed each morning from the metal rate, so it is never a stored figure.
Visual direction: follow the existing QR setu design system and its tokens. Apple-style soft corners, 3xl radius on outer shells and 2xl on inner panels. Plus Jakarta Sans for UI, Baloo 2 for display. The QR monogram gradient is reserved for brand emphasis only. Semantic colour tokens only, zero hard-coded colours. This is a jeweller's shop window and a financial figure at the same time: it must feel trustworthy and precise rather than decorative.
Constraints: touch targets at least 44px; WCAG AA contrast on every text pair; rate direction must never be conveyed by colour alone; no em dashes or en dashes in any copy; all copy must work in English, Hindi and Marathi without clipping; no login or signup prompt anywhere on the customer side.
Return, primary artboard 360x740: vendor daily-rate entry with yesterday's values pre-filled · vendor rate history with a correction affordance · vendor scheme definition including the refusal state when a duration over 11 months is attempted · customer card showing today's rates as the headline · customer 7-day trend · customer 1-month trend · customer scheme presentation · and the three sparse states (no rate published, three days of history, no scheme). Vendor screens in light and dark; customer screens light only.
Judge your own output against: could a shop owner publish the morning rate in under 15 seconds, one-handed, faster than typing a WhatsApp message; would a customer come back tomorrow to look; does the rate read as indicative rather than as a quotation; does the trend render as a static server-drawn image with no JavaScript; does the scheme read as a discount on jewellery rather than as a financial return; and does a jeweller with three days of history look deliberate rather than broken.
Parity status
Vendor screens are Stack 2 (Expo/RN, three surfaces: Android native · iOS native · Web PWA). Customer screens are Stack 1 (DOM web, SSR), so their desktop/mobile parity holds by construction (ADR-0011). Divergence seams to name at G0 per QRS-297: none new — rate entry is plain numeric input, and the share action reuses the existing navigator.share / native share seam already inventoried.
Proactive-value answer
This is the clearest proactive-value case in the product, and unusually it runs in both directions. For the vendor, the daily rate is a standing prompt tied to a ritual they already perform, so the nudge does not have to manufacture relevance. For the customer, the rate is a recurring reason to return to a merchant's card, which nothing else in the catalogue provides — a digital catalogue is visited once, a daily rate is visited weekly. And every number displayed is data the vendor themselves published, so no insight is fabricated: the trend is arithmetic over their own entries.
⚠ The anti-noise ceiling still applies. A rate change is not a reason to push a notification to a customer; it is a reason for the card to be worth opening. In-app and on-card surfacing only.