Sign In

Log in to Global Clinic as a patient or a clinic and land in the right console.

<!-- GENERATED FILE. Do not edit by hand. Source: components/help/content/. Run npm run gen:docs. -->

Purpose & Business Context

Sign In is the front door to the signed-in product. A cross-border medical case is a long, high-trust relationship, so this screen has one job: get a returning patient or clinic back into their own workspace quickly and without friction, then route them to exactly the console that matches who they are.

Commercially it is the gateway to every revenue-bearing surface (escrow, scheduling, clinic onboarding), so it is deliberately reassuring rather than gatekeeping. In this reference build the credentials are mocked, and the two demo accounts are pre-filled so anyone can step inside in one tap.

Screen Overview

The shared split-screen auth layout: a branded marketing panel on the left (trust signals like escrow protection and accredited clinics, hidden on mobile) and the sign-in card on the right.

The card stacks a Patient / Clinic role toggle, an Email field, a Password field with a show/hide eye, a Remember me checkbox paired with a Forgot password? link, the Sign in button, a Demo accounts hint box, and a footer link to create an account.

Controls & Components

• Role toggle: two buttons, Patient (Manage your care) and Clinic (Manage your clinic). Choosing one pre-fills that account's demo email and password.
• Email field: an email input with a mail icon, pre-filled from the selected role's demo account.
• Password field: a password input with a lock icon and an eye button that toggles plain-text visibility.
• Remember me: a checkbox, checked by default (presentational in this prototype).
• Forgot password?: a link to /forgot.
• Sign in button: the primary submit; validates the credentials and redirects on success.
• Demo accounts box: a teal hint listing the patient and clinic demo emails and the shared password.
• Footer link: 'New to Global Clinic? Create an account', routing to /register.

Field Definitions

• Account type (role): Patient or Clinic. Controlled toggle, defaults to Patient. Selecting a role overwrites the Email and Password fields with that role's demo credentials and clears any error.
• Email: Required email input (type=email). Default value is the patient demo email; it changes when you switch role, but you can type any address. Compared case-insensitively and trimmed against the demo accounts on submit.
• Password: Required input, masked by default. Default value is the demo password (demo1234). The eye button toggles between password and text type. Compared exactly (case-sensitive) against the demo account.
• Remember me: Checkbox, defaultChecked. Cosmetic in this build: the session is always persisted to localStorage regardless of its state.

User Actions & Workflows

1. Choose Patient or Clinic on the role toggle; the email and password fields pre-fill with that account's demo credentials.
2. Optionally edit the email or password, or reveal the password with the eye button to check it.
3. Press Sign in to submit. Correct credentials sign you in and redirect; wrong credentials show an inline error.
4. Patients land on /portal (the Journey dashboard); clinics land on /clinic (the clinic console).
5. If you have no account yet, follow 'Create an account'; if you forgot your password, follow 'Forgot password?'.

Navigation & Relationships

Reached from: the public site's sign-in call to action, the brand logo link in the auth panel (to /), the Register footer ('Already have an account? Sign in'), and the 'Back to sign in' links on Verify, Forgot and Reset.

Leads to: /portal on a successful patient sign-in, /clinic on a successful clinic sign-in, /register via the footer, and /forgot via the Forgot password link.

Backed by: the mock auth in lib/auth.tsx. Its signIn() validates against DEMO_ACCOUNTS and persists the session, which RequireAuth then reads to gate the portal and clinic consoles.

Business Rules & Constraints

• Only the two seeded demo accounts authenticate: patient@globalclinic.app and clinic@globalclinic.app, both with password demo1234.
• Email matching is case-insensitive and whitespace-trimmed; the password must match exactly.
• The role toggle does not by itself decide the destination: the destination follows the account that actually authenticates (clinic email goes to /clinic, patient email to /portal), so a mismatched role plus the other account's credentials still routes by the credentials.
• On success the user is written to localStorage under the gc_auth key, so the session survives a page reload.
• Email and password are both required; the browser blocks submission of an empty field.

Data Dependencies

Driven entirely by lib/auth.tsx. The form seeds its defaults from DEMO_ACCOUNTS and calls useAuth().signIn(email, password); on success it routes by the returned role. No network or external data source is involved in this prototype.

• DEMO_ACCOUNTS: seeds the pre-filled email/password and the demo hint box
• useAuth().signIn(): validates and, on success, persists the session
• gc_auth (localStorage): where the resulting session is stored

Error Handling & Edge Cases

• Wrong email or password shows an inline rose alert reading 'Incorrect email or password.' just above the Remember me row.
• Editing either field, or switching role, clears the error immediately so the message never goes stale.
• Empty fields are caught by native HTML required validation before signIn runs.
• Revealing the password (eye button) is local only and never leaves the device.
• Mobile: the left marketing panel is hidden and the card fills the screen; the floating Help button stays in the top-right.

User Roles & Permissions

• Public (no sign-in required): Anyone can reach /signin. The screen is the boundary between public and authenticated areas.
• Patient (after sign-in): Authenticating with the patient demo account redirects to /portal, the patient Journey dashboard.
• Clinic (after sign-in): Authenticating with the clinic demo account redirects to /clinic, the clinic console.

Related Features & Functionalities

Register (/register) for new accounts, Verify (/verify) which signs a user in via signInAs after registration, Forgot (/forgot) and Reset (/reset) for password recovery, and the RequireAuth guard that consumes the session this screen creates. The shared AuthShell and floating Help button appear on every auth screen.

Flow & Screenshots

flowchart LR
  SignIn[Sign In] -->|role toggle| Prefill[Demo credentials pre-filled]
  Prefill --> Submit[Sign in]
  Submit -->|patient ok| Portal[/portal Journey/]
  Submit -->|clinic ok| Clinic[/clinic console/]
  Submit -->|bad creds| Err[Inline error]
  SignIn -->|Create an account| Register[/register/]
  SignIn -->|Forgot password| Forgot[/forgot/]

Guided Walkthrough Steps

The in-app walkthrough for this screen has 6 steps (auto-advances every 5 seconds; Prev / Pause / Next; click outside to exit):

1. Pick your account type ([data-tour="signin.role"])

Choose Patient or Clinic. Whichever you pick pre-fills its demo email and password, so you can sign in with a single tap.

1. Your email ([data-tour="signin.email"])

This is pre-filled from the account type you chose. You can edit it, but only the two demo accounts will sign in.

1. Your password ([data-tour="signin.password"])

Masked by default. Tap the eye to reveal it and confirm what you typed. The demo password is demo1234.

1. Sign in ([data-tour="signin.submit"])

Submit to log in. A patient lands on the Journey dashboard, a clinic lands on the clinic console. Wrong details show an inline error.

1. Demo accounts ([data-tour="signin.demo"])

A reminder of the demo emails and shared password, so you never have to guess what to enter in this reference build.

1. Help is always here ([data-tour="topbar.help"])

Open this Help button on any screen for documentation, and press Play to replay a walkthrough like this one.