Profile & Settings — Screen Review

Status: 🟢 Validated — meets the brief · Last reviewed: 2026-07-19

Validation of the reworked prototype/mobile-console/Profile.dc.html (prior version archived as Profile_v1.dc.html) and the new prototype/mobile-console/Settings.dc.html, against the Profile/Settings/Onboarding field brief Parts 0/2/3. Both files were fetched and read in full via DesignSync.

Profile — meets Part 2

• Account-type fork works (biz = accountType !== 'Individual', a demoState toggle): business tabs = Basic / Business / Hours / Social; individual tabs = Basic / Location / Social (Hours and the brand/industry/GSTIN block are dropped). Matches the dual-audience decision + ADR-0001 D3.
• Uses the real DB column names verbatim — the state object keys are full_name, mobile_number, brand_name, business_domain_id, gstin, country, city, pin_code, social_media_links (with all eight real keys). Better than the onboarding prototype's camelCase; near-zero mapping needed at implementation.

Tab	Fields	Notes
Basic (both)	full_name (label "Owner name" business / "Your name" individual), mobile_number (+91, 10-digit), email (read-only → Settings)	✓
Business (business only)	brand_name, business industry dropdown (business_domain_id), gstin with live 15-char GSTIN validation	✓
Location (both)	country (dropdown), state, city, pin_code	✓
Hours (business only)	business_hours per-day open/close/closed toggles + planned_holidays_ooo add/remove	✓
Social (both)	all 8 social_media_links keys (whatsapp, instagram, facebook, youtube, twitter, linkedin, telegram, google_business)	✓

Header: avatar with camera-upload, name (brand_name business / full_name individual), tier badge, read-only email, "View public card" → ServiceCard. Save → toast (mock).

Settings — meets Part 3

• General: default_currency (INR/USD/EUR/GBP), language (English / मराठी / हिंदी), and the show_ads toggle ("Show partner offers") the brief asked for. Auto-saves ("Changes here save automatically").
• Security: change email (validated, "Send verification") and change password (current + new ≥8), both as bottom sheets.
• Danger Zone: delete account with a plain-language consequence explanation and a type-DELETE-to-confirm guard (button disabled until match) — stronger than the brief required.
• Plus a Plan card (→ subscription) and Sign out. Reasonable additions, in scope.

Design-language compliance — clean (both screens)

• 0 native <select> (custom token-styled dropdowns), 0 em dashes, prefers-reduced-motion guard, light + dark via a theme toggle.
• Tokens throughout; the only raw hex are #fff (foreground-on-accent, house style) and var(--…, #hex) fallbacks (--danger-soft, --overlay). No bespoke hardcoded colours.
• "What not to invent" respected: no business_name/display_name (uses brand_name/full_name), country_code kept display-only (+91), no bio/tagline/website, and role/permissions/is_demo_account are not surfaced.

Notes (minor, not blockers)

1. Bottom sheets lack role="dialog" / aria-modal — the change-email/password/delete sheets are visually modal but not announced as such. Minor a11y gap, same class flagged on other screens; worth a follow-up prompt if a11y is being swept, not urgent.
2. Settings stores display strings (language: 'English', currency: 'INR (₹)') — implementation maps these to the real column values (language='en', default_currency='INR'). Expected for a prototype.
3. Backend allow-list dependency — now more urgent. Profile makes gstin a first-class validated field and Settings makes language a first-class control — but both are still silently dropped by the manage-profile / manage-settings Edge-Function allow-lists (tracked here). The designs are correct; these two fields will look editable and save "successfully" while persisting nothing until the allow-lists are widened. That backend fix should land with implementation.

Verdict

Both screens meet the field brief across every field, the account-type fork, and the design-language rules, with a stronger-than-required delete confirmation. No design-fixable findings. Outstanding items are the pre-existing backend allow-list fixes (now more pressing) and an optional a11y pass on the modal sheets.