System Requirements Document for jarvis-mhb

1. Introduction

JARVIS × MHB is a Phase 1 salon reception and owner-access application for MHB Professional Hair & Beauty Salon, owned by Annangi Mahesh (Maahi).

The product provides a premium, multilingual reception experience for salon clients and a private owner experience for Maahi. The public reception experience is centered on JARVIS RECEPTION, an original contained Jarvis Core, clear guest pathways, and microphone/text interaction. Owner-only experiences are separated from public reception and require secure access.

The JARVIS × MHB Master Build Specification v1.1 describes the application to build. It is not content for salon clients or an application feature. The product must not be presented as a specification authoring, blueprint-intake, planning, or generic landing application.

Current delivery is restricted to the named Phase 1 application screens. The first screen to design is MHB RECEPTION IDLE. UI generation remains deferred under the current instruction, and Phase 2 must not be started.

2. System Overview

Current Delivery

The current application consists of five application-owned Phase 1 screens:

1. MHB RECEPTION IDLE
2. RECEPTION CONVERSATION
3. MAAHI SECURE LOGIN
4. MAAHI PERSONAL / OWNER MODE
5. MHB OWNER DASHBOARD

The application supports two active human personas:

• Salon Client (Reception Visitor), who uses the anonymous public reception experience.
• Maahi (Owner — Annangi Mahesh), who securely accesses owner-only surfaces.

Accepted Current Behavior

The public reception experience must:

• Present MHB Professional Hair & Beauty Salon branding.
• Present JARVIS RECEPTION.
• Present an original contained Jarvis Core.
• Present a premium welcome message.
• Offer the guest pathways:
  • I HAVE AN APPOINTMENT
  • I NEED A SERVICE
  • TALK TO STAFF
• Offer language options:
  • AUTO
  • EN
  • తెలుగు
  • हिंदी
• Provide microphone and text interaction controls.
• Allow reception visitors to continue into RECEPTION CONVERSATION.
• Keep public administrative settings unavailable.

The owner experience must:

• Keep MAAHI PERSONAL / OWNER MODE and MHB OWNER DASHBOARD out of the public reception experience.
• Require Maahi to establish first-use owner access through MAAHI SECURE LOGIN before owner-only surfaces become available.
• Require Maahi to complete returning verification through MAAHI SECURE LOGIN before resuming owner mode or dashboard state.
• Provide Maahi with a personal owner mode and an owner-level view of salon operations.

Data and Privacy Boundary

All current surfaces must use SAMPLE/FAKE DATA ONLY.

The application must not request conversationally:

• Real customer data.
• PINs through public reception or RECEPTION CONVERSATION interactions.
• API keys.

MAAHI SECURE LOGIN must provide a secure, non-conversational PIN-entry UI for owner authentication. PIN entry must be masked and must never be exposed, logged, or stored in plaintext. Development agents must never ask Maahi to provide a real PIN in chat.

No real client names, phone numbers, appointments, owner credentials, plaintext PINs, or other non-sample data may be represented in the current delivery.

Narrow Exclusions

The current scope excludes:

• Specification Author, Blueprint Intake, Generic Landing page, and Phase 1 as user-facing pages.
• Public administrative settings.
• Public owner dashboard entry points.
• Public account menus.
• Staff administration.
• Public operational metrics.
• Generic chatbot, message-feed-first, assistant-avatar, or large-composer-first reception interfaces.
• Gaming HUD, cockpit, radar, scanner, crosshair, neon-cyan, Marvel, or Iron-Man visual language.
• Phase 2 delivery or Phase 2 implementation.

2a. Product Interpretation and Delivery Boundary

JARVIS × MHB is a premium in-salon reception and private salon-owner application. It is not a planning tool, requirements tool, master-specification intake interface, or generic landing product.

Reception visitors use MHB RECEPTION IDLE and RECEPTION CONVERSATION anonymously. They may choose an appointment-related, service-related, or staff-contact pathway and interact using text or microphone controls in AUTO, English, Telugu, or Hindi. The current requirement does not define appointment booking, salon-service catalog management, customer records, staff assignment, or other adjacent salon-management functions. Reception behavior is therefore limited to receiving and handling or routing the stated guest need to staff using sample/fake data only.

Maahi privately accesses MAAHI PERSONAL / OWNER MODE and MHB OWNER DASHBOARD through MAAHI SECURE LOGIN. Owner-only surfaces are role-restricted and must not be discoverable or available from public reception surfaces.

Phase 2 must not be started. The current Phase 1 scope is limited to the five named screens and their accepted journeys.

2b. Source Content Inventory

The authoritative content source is JARVIS × MHB Master Build Specification v1.1. The source is a description of the application to build and is not application content for product users.

Verified source-backed product facts currently available are:

• Product name: JARVIS × MHB
• Salon: MHB Professional Hair & Beauty Salon
• Owner: Annangi Mahesh (Maahi)
• Current Phase 1 screens:
  1. MHB RECEPTION IDLE
  2. RECEPTION CONVERSATION
  3. MAAHI SECURE LOGIN
  4. MAAHI PERSONAL / OWNER MODE
  5. MHB OWNER DASHBOARD
• Public reception label: JARVIS RECEPTION
• Required public guest pathways:
  • I HAVE AN APPOINTMENT
  • I NEED A SERVICE
  • TALK TO STAFF
• Required language options:
  • AUTO
  • EN
  • తెలుగు
  • हिंदी
• Required public interaction modalities:
  • Microphone controls
  • Text controls
• Required presentation object:
  • Original contained Jarvis Core
• Required data rule:
  • SAMPLE/FAKE DATA ONLY
• Prohibited conversationally requested data:
  • Real customer data
  • PINs
  • API keys
• Required owner-authentication boundary:
  • MAAHI SECURE LOGIN provides secure masked PIN entry only; plaintext PINs must never be exposed, logged, or stored.

No real salon client records, appointment details, owner credentials, contact records, media, service lists, prices, salon schedules, or API configuration values have been supplied.

2c. Page Content and Component Coverage

MHB RECEPTION IDLE

• Information and state

  • Anonymous public reception entry surface.
  • MHB Professional Hair & Beauty Salon branding.
  • JARVIS RECEPTION designation.
  • Original contained Jarvis Core.
  • Premium welcome message.
  • Current language selection: AUTO, EN, తెలుగు, or हिंदी.
  • Idle microphone and text-entry state.
  • No public administrative, owner, account, dashboard, or staff-management settings.

• Primary actions

  • Select I HAVE AN APPOINTMENT.
  • Select I NEED A SERVICE.
  • Select TALK TO STAFF.
  • Select AUTO, EN, తెలుగు, or हिंदी.
  • Begin text interaction.
  • Begin microphone interaction.

• Supporting actions

  • Review the premium welcome message.
  • Return to the idle state after an inactive, cancelled, or failed reception interaction.

• Domain entities

  • Reception visitor.
  • Selected guest pathway.
  • Language preference for the active reception interaction.
  • Text input.
  • Microphone input.
  • Sample/fake reception request.

• Component responsibilities

  • Establish the salon’s premium public reception experience.
  • Make guest pathways obvious without presenting a generic chatbot interface.
  • Pass the selected guest pathway and active language to RECEPTION CONVERSATION.
  • Start microphone or text interaction without requesting prohibited data.
  • Keep public reception separate from owner-only access and operational controls.

• States

  • Default idle state.
  • Language-selected state.
  • Guest-pathway-selected transition state.
  • Microphone-ready state.
  • Microphone-active state.
  • Text-entry-ready state.
  • Input unavailable or failed state, with retry and continuation through another available input method.
  • Return-to-idle state after a cancelled or completed conversation.

RECEPTION CONVERSATION

• Information and state

  • Anonymous reception conversation surface.
  • Active guest pathway: appointment, service need, or staff request.
  • Active language selection.
  • JARVIS RECEPTION conversation activity.
  • Text and microphone controls.
  • Visible reception response or routing outcome based on sample/fake interaction data.
  • No public administrative settings or owner controls.

• Primary actions

  • Provide a text message.
  • Provide microphone input.
  • Continue the selected guest pathway.
  • Request to talk to staff.
  • Return to MHB RECEPTION IDLE when the visitor chooses to end or restart the interaction.

• Supporting actions

  • Change the conversation language using AUTO, EN, తెలుగు, or हिंदी.
  • Retry a failed text or microphone interaction.
  • Continue with text when microphone input is unavailable.
  • Continue with microphone input when text entry is not used.

• Domain entities

  • Reception visitor.
  • Guest pathway.
  • Reception conversation.
  • Text input.
  • Microphone input.
  • Conversation response.
  • Staff-routing outcome.
  • Sample/fake appointment or service context.

• Component responsibilities

  • Receive the visitor’s stated appointment, service, or staff-contact need.
  • Present a conversation response appropriate to the selected pathway.
  • Handle or route the accepted visitor need to staff without inventing booking, customer-record, or administrative workflows.
  • Preserve the visitor’s selected language during the active conversation.
  • Make the visitor’s continuation or failure-recovery options observable.

• States

  • Conversation started from appointment pathway.
  • Conversation started from service-need pathway.
  • Conversation started from staff-request pathway.
  • Text-entry state.
  • Microphone listening state.
  • Response-presented state.
  • Staff-routing outcome state.
  • Input failure state with retry or alternate-input recovery.
  • Conversation unavailable state with return-to-idle recovery.
  • Completed or ended conversation state returning to MHB RECEPTION IDLE.

MAAHI SECURE LOGIN

• Information and state

  • Anonymous access boundary for Maahi.
  • First-use owner-access establishment state.
  • Returning owner-verification state.
  • Secure masked PIN-entry UI state for owner authentication.
  • Successful secure-access state.
  • Failed verification state.
  • No public salon-client reception conversation content.

• Primary actions

  • Establish first-use owner access through secure masked PIN entry.
  • Complete returning owner verification through secure masked PIN entry.
  • Continue to MAAHI PERSONAL / OWNER MODE after successful access.
  • Continue to MHB OWNER DASHBOARD after successful access where dashboard state is the intended destination.

• Supporting actions

  • Retry failed access establishment or verification.
  • Return to the appropriate private-entry context without exposing owner state publicly.

• Domain entities

  • Maahi owner identity.
  • Owner access state.
  • Authenticated owner session.
  • Masked secure PIN-entry state.
  • Owner mode state.
  • Owner dashboard state.

• Component responsibilities

  • Establish identity continuity for Maahi’s private owner state.
  • Verify returning access before owner-only pages become available.
  • Prevent public users from accessing owner mode or dashboard content.
  • Provide a secure, non-conversational masked PIN-entry UI for first-use establishment and returning verification.
  • Never request PINs through reception conversation, expose PIN values, log PIN values, or store plaintext PINs.
  • Avoid requesting API keys, real customer data, or other prohibited information.

• States

  • Anonymous owner-login entry state.
  • First-use establishment state.
  • Returning verification state.
  • Secure masked PIN-entry state.
  • Verified owner session state.
  • Verification or establishment failure state with retry.
  • Protected-destination blocked state when owner verification has not succeeded.

MAAHI PERSONAL / OWNER MODE

• Information and state

  • Private, role-restricted Maahi personal owner mode.
  • Owner session state.
  • Owner-specific personal mode context.
  • Navigation or continuation to MHB OWNER DASHBOARD.
  • No public reception content.

• Primary actions

  • Enter or resume Maahi’s personal owner mode after secure login.
  • Continue to MHB OWNER DASHBOARD.
  • Return to the relevant owner context after dashboard review.

• Supporting actions

  • Resume the preserved owner mode after returning verification.
  • Recover by returning to MAAHI SECURE LOGIN if secure owner access expires or is unavailable.

• Domain entities

  • Maahi owner identity.
  • Owner session.
  • Personal owner mode state.
  • Dashboard destination.

• Component responsibilities

  • Provide a private owner context distinct from public reception.
  • Preserve owner continuity across successful returning verification.
  • Restrict content and actions to the accepted owner persona.
  • Avoid inventing account management, staff administration, or other owner capabilities not specified by the source.

• States

  • Secure owner mode available.
  • Active owner mode.
  • Returning owner mode resumed.
  • Session unavailable or expired state with secure-login recovery.
  • Dashboard transition state.

MHB OWNER DASHBOARD

• Information and state

  • Private, role-restricted owner-level view of salon operations.
  • Owner session state.
  • Sample/fake salon operational view.
  • Dashboard availability after MAAHI SECURE LOGIN.
  • No public reception controls.

• Primary actions

  • View the owner-level salon operations context.
  • Return to MAAHI PERSONAL / OWNER MODE.

• Supporting actions

  • Resume the dashboard after successful returning verification.
  • Recover by returning to MAAHI SECURE LOGIN when owner verification is unavailable.

• Domain entities

  • Maahi owner identity.
  • Owner session.
  • Sample/fake salon operations context.
  • Dashboard state.

• Component responsibilities

  • Present the accepted owner-level salon operations view.
  • Keep all dashboard content private to Maahi.
  • Preserve or restore dashboard state after secure returning verification where state exists.
  • Avoid creating unapproved administrative functions, staff-management functions, customer-management functions, or operational modules beyond the stated owner-level view.

• States

  • Dashboard loading state.
  • Dashboard available state with sample/fake information only.
  • Empty or unavailable sample-data state.
  • Dashboard error state with retry or return-to-owner-mode recovery.
  • Session-expired or access-blocked state with secure-login recovery.

3. Functional Requirements

FR-01 — Product Identity and Salon Context

As a Salon Client (Reception Visitor), I should encounter JARVIS × MHB as the reception experience for MHB Professional Hair & Beauty Salon so that I understand I am engaging with the salon’s reception service.

• Provenance: explicit
• Trigger/input: The visitor opens MHB RECEPTION IDLE.
• Access state: Anonymous public reception access.
• Observable result: The surface presents MHB Professional Hair & Beauty Salon branding and JARVIS RECEPTION.
• Failure and recovery: If required public identity content cannot load, the system must present an unavailable state and provide a retry path without exposing owner or administrative content.
• Continuation: The visitor selects a guest pathway, language option, or text/microphone control.

FR-02 — Premium Reception Idle Experience

As a Salon Client (Reception Visitor), I should see a premium reception idle experience with an original contained Jarvis Core and welcome message so that I receive immediate reassurance and clear high-end salon guidance.

• Provenance: explicit
• Trigger/input: The visitor reaches MHB RECEPTION IDLE.
• Access state: Anonymous public reception access.
• Observable result: The page presents the original contained Jarvis Core and premium welcome message as the dominant reception experience.
• Failure and recovery: If the Core’s ambient presentation is unavailable, the reception surface must retain the welcome message and guest pathways in a usable static state.
• Continuation: The visitor selects an appointment, service, or staff pathway.

FR-03 — Appointment Pathway Selection

As a Salon Client (Reception Visitor), I should be able to select I HAVE AN APPOINTMENT so that I can continue my appointment-related reception interaction.

• Provenance: explicit
• Trigger/input: The visitor selects I HAVE AN APPOINTMENT on MHB RECEPTION IDLE.
• Access state: Anonymous public reception access.
• Observable result: RECEPTION CONVERSATION opens with the appointment pathway as the active context.
• Failure and recovery: If the conversation surface cannot open, the visitor receives an error state and may retry or return to MHB RECEPTION IDLE.
• Continuation: The visitor provides text or microphone input to state the appointment-related need.

FR-04 — Service-Need Pathway Selection

As a Salon Client (Reception Visitor), I should be able to select I NEED A SERVICE so that I can continue my service-related reception interaction.

• Provenance: explicit
• Trigger/input: The visitor selects I NEED A SERVICE on MHB RECEPTION IDLE.
• Access state: Anonymous public reception access.
• Observable result: RECEPTION CONVERSATION opens with the service-need pathway as the active context.
• Failure and recovery: If the conversation surface cannot open, the visitor receives an error state and may retry or return to MHB RECEPTION IDLE.
• Continuation: The visitor provides text or microphone input to state the service need.

FR-05 — Staff-Contact Pathway Selection

As a Salon Client (Reception Visitor), I should be able to select TALK TO STAFF so that I can request staff contact through reception.

• Provenance: explicit
• Trigger/input: The visitor selects TALK TO STAFF on MHB RECEPTION IDLE or during RECEPTION CONVERSATION.
• Access state: Anonymous public reception access.
• Observable result: RECEPTION CONVERSATION presents a staff-contact or staff-routing outcome using sample/fake data only.
• Failure and recovery: If a staff-routing outcome cannot be presented, the visitor is informed that the request could not be completed and may retry, use another input method, or return to MHB RECEPTION IDLE.
• Continuation: The visitor may complete the conversation or return to the reception idle state.

FR-06 — Multilingual Reception Selection

As a Salon Client (Reception Visitor), I should be able to select AUTO, EN, తెలుగు, or हिंदी so that I can use the public reception experience in the supported language context.

• Provenance: explicit
• Trigger/input: The visitor selects a language option on MHB RECEPTION IDLE or RECEPTION CONVERSATION.
• Access state: Anonymous public reception access.
• Observable result: The selected language context is visibly active and is used for the current reception interaction.
• Failure and recovery: If a selected language cannot be applied, the system must preserve the existing language state, explain that the change was unavailable, and allow another option to be selected.
• Continuation: The visitor continues with a guest pathway, text input, or microphone input.

FR-07 — Text Reception Interaction

As a Salon Client (Reception Visitor), I should be able to use text controls so that I can communicate my appointment, service, or staff-contact need to JARVIS RECEPTION.

• Provenance: explicit
• Trigger/input: The visitor enters text on MHB RECEPTION IDLE or RECEPTION CONVERSATION.
• Access state: Anonymous public reception access.
• Observable result: RECEPTION CONVERSATION receives the text input and presents a relevant reception response, handling outcome, or staff-routing outcome.
• Failure and recovery: If text cannot be submitted or processed, the visitor sees an error state and may retry, use the microphone control, or return to MHB RECEPTION IDLE.
• Continuation: The visitor continues the conversation, requests staff contact, or ends the interaction.

FR-08 — Microphone Reception Interaction

As a Salon Client (Reception Visitor), I should be able to use microphone controls so that I can communicate my appointment, service, or staff-contact need by voice.

• Provenance: explicit
• Trigger/input: The visitor activates the microphone control.
• Access state: Anonymous public reception access.
• Observable result: The microphone listening state is visible, and the reception conversation receives voice input for the active guest pathway.
• Failure and recovery: If microphone access, listening, or processing is unavailable, the visitor sees a failure state and may retry, use text controls, or return to MHB RECEPTION IDLE.
• Continuation: The visitor receives a conversation response, staff-routing outcome, or another appropriate reception continuation.

FR-09 — Reception Conversation Handling and Routing

As a Salon Client (Reception Visitor), I should receive a reception response or staff-routing outcome for my selected appointment, service, or staff-contact pathway so that my immediate salon need is handled or routed without public administrative settings.

• Provenance: required_inference
• Trigger/input: The visitor provides text or microphone input after selecting an appointment, service, or staff-contact pathway.
• Access state: Anonymous public reception access.
• Observable result: RECEPTION CONVERSATION presents a response, an observable handling result, or an observable staff-routing outcome using sample/fake data only.
• Indispensable participant handoff: Where the visitor requests staff contact, the outcome must communicate that the visitor’s request has been routed or could not be routed; staff are not an accepted active human persona and do not receive a first-party application journey in current scope.
• Failure and recovery: If the need cannot be handled or routed, the visitor can retry, use the alternate input method, select TALK TO STAFF, or return to MHB RECEPTION IDLE.
• Continuation: The visitor may continue the conversation or conclude and return to MHB RECEPTION IDLE.

FR-10 — No Public Administrative Settings

As a Salon Client (Reception Visitor), I should not encounter public administrative settings so that the reception experience remains focused on salon hospitality and guest assistance.

• Provenance: explicit
• Trigger/input: The visitor uses MHB RECEPTION IDLE or RECEPTION CONVERSATION.
• Access state: Anonymous public reception access.
• Observable result: No public administrative settings, owner controls, owner dashboard entry points, account menus, staff administration, or operational metrics are exposed.
• Failure and recovery: If a protected or administrative destination is requested through a public path, access remains blocked and the visitor remains within the public reception experience.
• Continuation: The visitor continues an accepted guest pathway or returns to idle reception.

FR-11 — First-Use Owner Access Establishment

As Maahi (Owner — Annangi Mahesh), I should be able to establish first-use owner access through MAAHI SECURE LOGIN so that MAAHI PERSONAL / OWNER MODE and MHB OWNER DASHBOARD become available only to me.

• Provenance: required_inference
• Trigger/input: Maahi reaches MAAHI SECURE LOGIN without existing verified owner access.
• Access state: Anonymous before owner access is established.
• Observable result: MAAHI SECURE LOGIN provides a secure masked PIN-entry UI that establishes Maahi’s owner access and creates an authenticated owner session without exposing, logging, or storing a plaintext PIN.
• Failure and recovery: If owner access cannot be established, owner-only surfaces remain unavailable, and Maahi can retry through MAAHI SECURE LOGIN.
• Continuation: Maahi enters MAAHI PERSONAL / OWNER MODE or MHB OWNER DASHBOARD.
• Constraint: The system must not request PINs conversationally, API keys, real customer data, or non-sample data. Development agents must never ask Maahi to provide a real PIN in chat.

FR-12 — Returning Owner Verification

As Maahi (Owner — Annangi Mahesh), I should be able to complete returning verification through MAAHI SECURE LOGIN so that I can resume the correct private owner mode or dashboard state.

• Provenance: required_inference
• Trigger/input: Maahi returns to MAAHI SECURE LOGIN after owner access has previously been established.
• Access state: Anonymous before verification.
• Observable result: Successful verification through the secure masked PIN-entry UI restores access to Maahi’s private owner context without exposing, logging, or storing a plaintext PIN.
• Failure and recovery: Failed verification does not expose owner-only content; Maahi may retry through MAAHI SECURE LOGIN.
• Continuation: Maahi resumes MAAHI PERSONAL / OWNER MODE or MHB OWNER DASHBOARD.

FR-13 — Private Personal Owner Mode

As Maahi (Owner — Annangi Mahesh), I should be able to enter MAAHI PERSONAL / OWNER MODE after secure login so that I have a private personal owner context separate from public reception.

• Provenance: explicit
• Trigger/input: Maahi completes secure login and enters MAAHI PERSONAL / OWNER MODE.
• Access state: Role-restricted; verified Maahi owner session required.
• Observable result: A private owner-mode surface becomes available and is not exposed in the public reception experience.
• Failure and recovery: If the owner session is unavailable or expired, the page blocks private content and directs Maahi to MAAHI SECURE LOGIN for returning verification.
• Continuation: Maahi continues to MHB OWNER DASHBOARD or resumes the personal owner mode later through secure verification.

FR-14 — Owner-Level Salon Operations View

As Maahi (Owner — Annangi Mahesh), I should be able to view MHB OWNER DASHBOARD after secure login so that I can access the owner-level view of salon operations.

• Provenance: explicit
• Trigger/input: Maahi opens MHB OWNER DASHBOARD after secure login.
• Access state: Role-restricted; verified Maahi owner session required.
• Observable result: The dashboard presents an owner-level salon operations view using sample/fake data only.
• Failure and recovery: If dashboard information is unavailable, the application presents loading, empty, or error state as applicable and allows retry or return to MAAHI PERSONAL / OWNER MODE. If the session is unavailable, Maahi must return to MAAHI SECURE LOGIN.
• Continuation: Maahi returns to MAAHI PERSONAL / OWNER MODE or resumes the dashboard through returning verification.

FR-15 — Sample/Fake Data Restriction

As a Salon Client (Reception Visitor) or Maahi (Owner — Annangi Mahesh), I should interact only with sample/fake data so that current product delivery does not use real customer, appointment, credential, or operational data while owner authentication remains protected through secure masked PIN entry.

• Provenance: explicit
• Trigger/input: Any accepted interaction across the five current Phase 1 screens.
• Access state: Applicable to anonymous reception and owner-restricted experiences.
• Observable result: All displayed, entered, processed, and retained current-scope data is sample/fake data only; any owner PIN entry is confined to MAAHI SECURE LOGIN, masked, and never retained in plaintext.
• Failure and recovery: The application must reject, avoid requesting, or avoid presenting real customer data, conversational PINs, API keys, real appointments, real owner credentials, or other non-sample data. The user remains able to continue the accepted workflow with sample/fake data.
• Continuation: The user continues the relevant reception or owner journey.

FR-16 — Phase 2 Exclusion

As Maahi (Owner — Annangi Mahesh), I should have the current application remain within Phase 1 so that Phase 2 is not started.

• Provenance: explicit
• Trigger/input: Any attempt to initiate or enter Phase 2 work.
• Access state: Applicable across the current application.
• Observable result: No Phase 2 page, capability, workflow, or implementation activity is available.
• Failure and recovery: Any Phase 2 request remains outside the current product delivery and does not alter current Phase 1 state.
• Continuation: The user remains within the accepted Phase 1 screens and journeys.

4. User Personas

Salon Client (Reception Visitor)

Product context:
The Salon Client is a walk-in or arriving client at MHB Professional Hair & Beauty Salon. They interact anonymously with JARVIS RECEPTION through the public reception surfaces and must not encounter owner or administrative controls.

Primary goal:
Receive a polished, reassuring reception interaction that helps them state an appointment-related need, a service need, or a request to talk to staff.

Distinct accepted responsibilities:

• Select I HAVE AN APPOINTMENT, I NEED A SERVICE, or TALK TO STAFF.
• Select AUTO, EN, తెలుగు, or हिंदी for the active reception interaction.
• Provide a reception