@incodetech/prizma-core-screens 0.1.0

package/src/EmailInputOtpScreen.tsx

@@ -0,0 +1,169 @@
+import React, { forwardRef, type ReactNode } from 'react';
+import { PrizmaOtp } from '@incodetech/prizma-core-web/otp';
+import { PrizmaFormScreen, type PrizmaFormScreenProps } from './FormScreen';
+import type { PrizmaScreenActionHandler, PrizmaScreenOverrides } from './types';
+import type { EmailInputOtpState, EmailInputStrings } from './EmailInputStrings';
+import './ScreenLayout.css';
+
+export interface EmailInputOtpScreenProps
+  extends Omit<
+    PrizmaFormScreenProps,
+    'title' | 'subtitle' | 'ctaLabel' | 'verifiedLabel' | 'children' | 'navLabel'
+  > {
+  /** Module copy — this screen reads the `otp` slice. */
+  strings: EmailInputStrings;
+  /** Which purple `email.OTP.*` section to render. Default `typing`. */
+  state?: EmailInputOtpState;
+  /** The code as typed. Figma's sample is the alphanumeric `A1B2C3`. */
+  value?: string;
+  /** How many characters the code carries. Default 6. */
+  length?: number;
+  screenId?: string;
+  overrides?: PrizmaScreenOverrides;
+  onAction?: PrizmaScreenActionHandler;
+}
+
+/**
+ * Email Input — the one-time-code screen, built on the Form archetype
+ * (GUIDELINES.md §6-E, `PrizmaFormScreen`).
+ *
+ * ONE screen for all five purple `email.OTP.*` sections (`typing` / `filled` /
+ * `processing` and the module's TWO error sections) — identical layout,
+ * differing in the state of the code field, the CTA, and the line under it.
+ *
+ * The code field is Core's `PrizmaOtp`, which is a single centred, letter-spaced
+ * field rather than a segmented box row — exactly what the Figma sections draw
+ * ("A1B2C3" as one line of type inside one 56px field).
+ *
+ * `processing` deliberately does NOT use Core's `PrizmaOtp.loading`. That prop
+ * centres the spinner INSIDE the code field (owner definition 2026-07-12), but
+ * the purple section draws the field simply DISABLED with the code still
+ * legible and puts the spinner in the CTA — the same treatment as
+ * `verify.loading`, which is what makes the module read consistently.
+ * DEVIATIONS #PI-5.
+ *
+ * DEVIATIONS #EI-3 — the band under the CTA is NOT one treatment for all five
+ * sections, which is this module's own finding rather than anything inherited
+ * from Phone Input. Measured on the 390 frames, three different treatments:
+ * - `typing` (146:37111) draws a re-send COUNTDOWN ("Resend code in 30s") —
+ *   plain secondary copy, NO links, because the code has only just been sent
+ *   and re-sending it immediately is meaningless
+ * - `filled` (150:38395) and both error sections (150:63411 generic,
+ *   150:70717 invalid-code) draw the two-link sentence
+ * - `processing` (150:63409) draws that same sentence INERT — every word in
+ *   the secondary ink, no underline, nothing clickable, because the request is
+ *   in flight. Rendering the labels as plain text is what produces that, so
+ *   `processing` reads differently from `filled` in the band as well as in the
+ *   field.
+ * The consequence for a host: `resendCountdown` and `resendPrompt` are not
+ * alternatives it may choose between — which one is drawn is decided by
+ * `state`, so both must be supplied for the five sections to render as drawn.
+ */
+export const EmailInputOtpScreen = forwardRef<HTMLDivElement, EmailInputOtpScreenProps>(
+  (
+    {
+      strings,
+      state = 'typing',
+      value,
+      length = 6,
+      screenId = `email-input-otp-${state}`,
+      overrides,
+      onAction,
+      ...shell
+    },
+    ref,
+  ) => {
+    const busy = state === 'processing';
+    const invalid = state === 'error' || state === 'errorGeneric';
+    const focused = state === 'typing';
+
+    const errorText =
+      state === 'error'
+        ? strings.otp.errorText
+        : state === 'errorGeneric'
+          ? strings.otp.genericErrorText
+          : undefined;
+
+    /* `typing` shows the countdown; every other section shows the sentence. */
+    const countdown = focused ? strings.otp.resendCountdown : undefined;
+
+    /* Both links are wrapped by the same helper so the inert (`processing`)
+       rendering cannot drift from the actionable one — only the element type
+       changes. Each link emits a DISTINCT action: re-sending the code and
+       returning to email entry are different flows a host must tell apart
+       (DEVIATIONS #PI-10). */
+    const link = (label: string, type: 'secondary' | 'tertiary'): ReactNode =>
+      busy ? (
+        label
+      ) : (
+        <button
+          type="button"
+          className="prizma-screen-layout__inline-link"
+          onClick={() => onAction?.({ type, screenId })}
+        >
+          {label}
+        </button>
+      );
+
+    const resendLine: ReactNode = countdown ? (
+      <p className="prizma-screen-layout__inline-prompt">{countdown}</p>
+    ) : strings.otp.resendPrompt ? (
+      <p className="prizma-screen-layout__inline-prompt">
+        {strings.otp.resendPrompt}{' '}
+        {strings.otp.resendLabel ? link(strings.otp.resendLabel, 'secondary') : null}
+        {strings.otp.changeEmailLabel ? (
+          <>
+            {' '}
+            {strings.otp.resendSeparator}{' '}
+            {link(strings.otp.changeEmailLabel, 'tertiary')}
+          </>
+        ) : null}
+      </p>
+    ) : undefined;
+
+    return (
+      <PrizmaFormScreen
+        ref={ref}
+        title={strings.otp.title}
+        subtitle={strings.otp.subtitle}
+        ctaLabel={strings.otp.ctaLabel}
+        /* Figma greys the CTA on both error sections; `typing` keeps it live. */
+        ctaDisabled={invalid}
+        /* The spinner rides the CTA, not the field (see the note above). */
+        ctaLoading={busy}
+        ctaLoadingLabel={strings.otp.ctaLoadingLabel}
+        linkContent={resendLine}
+        verifiedLabel={strings.verifiedLabel}
+        navLabel={strings.navLabel}
+        screenId={screenId}
+        overrides={overrides}
+        onAction={onAction}
+        {...shell}
+      >
+        <PrizmaOtp
+          length={length}
+          /* Core's own static-focus modifier, the same mechanism the verify
+             field uses: `typing` is the one section Figma draws focused, and
+             `filled` sits on the resting border. DEVIATIONS #PI-7. */
+          className={focused ? 'prizma-input-otp--focused' : undefined}
+          aria-label={strings.otp.fieldLabel}
+          /* Uncontrolled, for the same reason as the email field: `readOnly`
+             would paint Core's DISABLED surface on the resting states, which is
+             grey Figma does not draw there (DEVIATIONS #PI-6). */
+          defaultValue={value ?? ''}
+          /* Figma's code is alphanumeric ("A1B2C3"), so the field must not
+             advertise a numeric keypad the way Core's OTP default does. */
+          inputMode="text"
+          /* `processing` is the one section Figma greys — the code stays
+             legible while the check runs. */
+          disabled={busy}
+          error={invalid}
+          errorText={errorText}
+        />
+      </PrizmaFormScreen>
+    );
+  },
+);
+EmailInputOtpScreen.displayName = 'EmailInputOtpScreen';
+
+export default EmailInputOtpScreen;

package/src/EmailInputProcessingScreen.tsx

@@ -0,0 +1,67 @@
+import React, { forwardRef } from 'react';
+import {
+  PrizmaProcessingScreen,
+  type PrizmaProcessingScreenProps,
+} from './ProcessingScreen';
+import type { PrizmaScreenActionHandler, PrizmaScreenOverrides } from './types';
+import type { EmailInputStrings } from './EmailInputStrings';
+import './ScreenLayout.css';
+
+export interface EmailInputProcessingScreenProps
+  extends Omit<
+    PrizmaProcessingScreenProps,
+    'status' | 'title' | 'subtitle' | 'verifiedLabel' | 'navLabel'
+  > {
+  /** Module copy — this screen reads the `processing` slice. */
+  strings: EmailInputStrings;
+  screenId?: string;
+  overrides?: PrizmaScreenOverrides;
+  onAction?: PrizmaScreenActionHandler;
+}
+
+/**
+ * Email Input — the code is being checked, built on the Processing archetype
+ * (GUIDELINES.md §6-C, `PrizmaProcessingScreen`).
+ *
+ * Figma: the purple `email.OTP.processing` section holding `email.processing`
+ * — a separate SCREEN from the in-form `email.OTP.processing` state, which
+ * keeps the code field and only swaps the CTA. This one is a pure spinner + H2
+ * with no button, which is exactly the case §6-F reserves for C rather than the
+ * Result archetype.
+ *
+ * Figma draws this section with a close ✕ in the nav and no verified tag; both
+ * are owner-settled and neither is reproduced — GUIDELINES §3 forbids the ✕
+ * (DEVIATIONS #PI-9, a standing Wave-3 ruling) and the chrome stays constant
+ * across the module's screens (#F-30, #F-34, #PI-8).
+ */
+export const EmailInputProcessingScreen = forwardRef<
+  HTMLDivElement,
+  EmailInputProcessingScreenProps
+>(
+  (
+    {
+      strings,
+      screenId = 'email-input-processing',
+      overrides,
+      onAction,
+      ...shell
+    },
+    ref,
+  ) => (
+    <PrizmaProcessingScreen
+      ref={ref}
+      status="loading"
+      title={strings.processing.title}
+      subtitle={strings.processing.subtitle}
+      verifiedLabel={strings.verifiedLabel}
+      navLabel={strings.navLabel}
+      screenId={screenId}
+      overrides={overrides}
+      onAction={onAction}
+      {...shell}
+    />
+  ),
+);
+EmailInputProcessingScreen.displayName = 'EmailInputProcessingScreen';
+
+export default EmailInputProcessingScreen;

package/src/EmailInputStrings.ts

@@ -0,0 +1,166 @@
+// Email Input — copy contract.
+//
+// Figma: `📨 Email - Screens specs + Localization` (IovIhDAPjR7zxjC4NKZzfq,
+// page 5:13191). Four purple parent sections:
+//   email.verifyEmail — default / typing / filled / error / loading
+//   email.OTP         — typing / filled / processing / error(×2) + email.processing
+//   email.error       — somethingWentWrong
+//   email.success     — success
+//
+// Sibling of Phone Input (`PhoneInputStrings.ts`) and deliberately shaped the
+// same way: same archetypes, same state axes, same inline-link split. The two
+// real differences are that the entry field is a single email TextField (no
+// dial-code pairing, so no `Input / Combined` and no country list) and that the
+// module draws no Silent-Network-Auth and no connectivity section.
+//
+// No hardcoded English anywhere in a screen: every visible string arrives here,
+// so the host's locale pack drives the module (the Figma file ships ES + PT
+// columns alongside EN).
+
+/**
+ * The `email.verifyEmail.*` sections. All five draw the SAME layout — nav →
+ * Title (H2 + H5) → Spacing/32 → a single email field → CTA → tag — and differ
+ * only in field content and CTA state, which is what GUIDELINES §6-E means by
+ * "states are separate screens sharing the identical layout":
+ * - `default` — empty field showing the placeholder, CTA enabled
+ * - `typing`  — focused field with a partial address
+ * - `filled`  — focused field with a complete address
+ * - `error`   — negative field + clear ✕ + the invalid-format row
+ * - `loading` — field greyed while the code is requested, spinner in the CTA
+ */
+export type EmailInputVerifyState =
+  | 'default'
+  | 'typing'
+  | 'filled'
+  | 'error'
+  | 'loading';
+
+/**
+ * The `email.OTP.*` sections — same layout, different code-field state:
+ * - `typing`       — focused field, partial code, CTA enabled, and the line
+ *                    under the CTA is the RE-SEND COUNTDOWN, not the two links
+ * - `filled`       — resting field, complete code, the two-link line
+ * - `processing`   — code submitted: field greyed, spinner in the CTA, and the
+ *                    same sentence rendered INERT (no links)
+ * - `error`        — wrong code: negative field + "Invalid code…", CTA disabled
+ * - `errorGeneric` — the second purple error section, same treatment carrying
+ *                    the generic "Something went wrong" row instead
+ */
+export type EmailInputOtpState =
+  | 'typing'
+  | 'filled'
+  | 'processing'
+  | 'error'
+  | 'errorGeneric';
+
+export interface EmailInputStrings {
+  /** "verified by" attribution in the footer tag. */
+  verifiedLabel: string;
+  /** Accessible name for the logo nav row. */
+  navLabel?: string;
+
+  /** email.verifyEmail.* */
+  verify: {
+    /** H2 ("Verify your email"). */
+    title: string;
+    /** H5 ("We'll send you a code to ensure it's yours"). */
+    subtitle: string;
+    /** Field placeholder ("Email"). */
+    placeholder: string;
+    /**
+     * Accessible label for the email field.
+     *
+     * DEVIATIONS #EI-2 — Figma draws NO visible label row above the field: the
+     * placeholder ("Email") carries the whole meaning, measured on
+     * `email.verifyYourEmail.default` (28:13802) and unchanged across all five
+     * purple sections. A screen reader would therefore reach an unnamed input,
+     * so the copy rides `aria-label` instead of a drawn row — Core wins over
+     * Figma on the accessible name, and nothing new is painted. This is the
+     * #PI-4 precedent applied unchanged; Phone Input resolved the identical
+     * conflict the same way.
+     */
+    fieldLabel?: string;
+    /** Accessible name for the clear ✕ affordance. Core ships no English
+     *  default, so the row is only drawn when this is supplied. */
+    clearLabel?: string;
+    /** Error row on the `error` state ("Invalid email format"). */
+    errorText: string;
+    /** Primary CTA ("Continue"). */
+    ctaLabel: string;
+    /** Accessible busy label while the code is requested (`loading`). */
+    ctaLoadingLabel?: string;
+  };
+
+  /** email.OTP.* */
+  otp: {
+    /** H2 ("Enter the code we've sent to your email"). */
+    title: string;
+    /** H5 — carries the masked destination address, when a section shows one. */
+    subtitle?: string;
+    /** Accessible label for the code field (no visible label row in Figma). */
+    fieldLabel?: string;
+    /** Error row on `error` ("Invalid code. Please try again."). */
+    errorText: string;
+    /** Error row on `errorGeneric` ("Something went wrong"). */
+    genericErrorText: string;
+    /**
+     * The `typing` section draws a COUNTDOWN instead of the two links —
+     * "Resend code in 30s". Pre-formatted by the host, which owns the clock
+     * (a screen is one static spec state and runs no timer).
+     */
+    resendCountdown?: string;
+    /**
+     * The line under the CTA on `filled` / `processing` / both error sections
+     * is ONE sentence carrying TWO separate links:
+     * "Didn't receive the code? [Resend code] or [Change email]".
+     * Split into four strings because the links are independently actionable —
+     * the host must tell a re-send from a return to email entry — and because a
+     * locale needs to order the fragments itself. Omit `resendPrompt` to render
+     * no line at all. DEVIATIONS #PI-10.
+     */
+    resendPrompt?: string;
+    /** First link — re-sends the code. Emits `secondary`. */
+    resendLabel?: string;
+    /** The conjunction between the two links ("or"). */
+    resendSeparator?: string;
+    /** Second link — returns to email entry. Emits `tertiary`. */
+    changeEmailLabel?: string;
+    /** Primary CTA. */
+    ctaLabel: string;
+    /** Accessible / visible busy copy while the code is checked (`processing`). */
+    ctaLoadingLabel?: string;
+  };
+
+  /** email.OTP → `email.processing`: the post-submit spinner screen. */
+  processing: {
+    /** H2 shown under the spinner ("Processing…"). */
+    title: string;
+    subtitle?: string;
+  };
+
+  /** email.success */
+  success: {
+    /** H2 ("Email verified!"). */
+    title: string;
+    subtitle?: string;
+  };
+
+  /**
+   * email.error.somethingWentWrong.
+   *
+   * DEVIATIONS #EI-5 — this is the module's ONLY error verdict. The purple
+   * `email.error` section (3058:103116) holds exactly one screen, and the file
+   * draws no connectivity section anywhere. Phone Input's error screen carries
+   * a `variant` axis precisely because its Figma splits `somethingWentWrong`
+   * from a no-connection screen with a Wi-Fi glyph; this module has nothing to
+   * switch between, so `EmailInputErrorScreen` ships NO `variant` prop and no
+   * Wi-Fi glyph. Adding either would be inventing a state the spec does not
+   * have. If a connectivity section is added upstream, this row is where the
+   * axis gets reinstated.
+   */
+  error: {
+    title: string;
+    subtitle?: string;
+    ctaLabel: string;
+  };
+}

package/src/EmailInputSuccessScreen.tsx

@@ -0,0 +1,72 @@
+import React, { forwardRef } from 'react';
+import {
+  PrizmaProcessingScreen,
+  type PrizmaProcessingScreenProps,
+} from './ProcessingScreen';
+import type { PrizmaScreenActionHandler, PrizmaScreenOverrides } from './types';
+import type { EmailInputStrings } from './EmailInputStrings';
+import './ScreenLayout.css';
+
+export interface EmailInputSuccessScreenProps
+  extends Omit<
+    PrizmaProcessingScreenProps,
+    'status' | 'title' | 'subtitle' | 'verifiedLabel' | 'navLabel'
+  > {
+  /** Module copy — this screen reads the `success` slice. */
+  strings: EmailInputStrings;
+  screenId?: string;
+  overrides?: PrizmaScreenOverrides;
+  onAction?: PrizmaScreenActionHandler;
+}
+
+/**
+ * Email Input — the verified verdict, built on the Processing archetype
+ * (GUIDELINES.md §6-C, `PrizmaProcessingScreen`).
+ *
+ * Figma: the purple `email.success` section. A centred status mark over a bare
+ * H2 ("Email verified!") with **no CTA and no subtitle** — the module hands
+ * control straight back to the flow.
+ *
+ * DEVIATIONS #EI-4 — this screen sits on archetype C while its Phone Input
+ * sibling sits on F, and that split is deliberate, not an oversight. Measured
+ * on `email.success` (31:19307): mark + H2 and then nothing — the CTA band is
+ * empty all the way down to the browser chrome, where the error verdict
+ * (40:33375) does draw "Try again" in the same slot. `phoneNumber.success`
+ * draws a button; `email.success` does not. §6-F reserves the Result archetype
+ * for "every verdict screen that needs a button" and keeps C as the pure
+ * no-button case, so following the archetype rule across two modules whose
+ * Figma disagrees is what produces two different archetypes here. Putting this
+ * screen on F to match its sibling would draw a button the spec omits.
+ *
+ * The mark is Core's outline status icon via `PrizmaTitle`'s icon slot — the
+ * module Figma still draws the two-tone filled disc, one icon sweep behind
+ * (DEVIATIONS #15, unchanged here).
+ */
+export const EmailInputSuccessScreen = forwardRef<HTMLDivElement, EmailInputSuccessScreenProps>(
+  (
+    {
+      strings,
+      screenId = 'email-input-success',
+      overrides,
+      onAction,
+      ...shell
+    },
+    ref,
+  ) => (
+    <PrizmaProcessingScreen
+      ref={ref}
+      status="success"
+      title={strings.success.title}
+      subtitle={strings.success.subtitle}
+      verifiedLabel={strings.verifiedLabel}
+      navLabel={strings.navLabel}
+      screenId={screenId}
+      overrides={overrides}
+      onAction={onAction}
+      {...shell}
+    />
+  ),
+);
+EmailInputSuccessScreen.displayName = 'EmailInputSuccessScreen';
+
+export default EmailInputSuccessScreen;

package/src/EmailInputVerifyScreen.tsx

@@ -0,0 +1,117 @@
+import React, { forwardRef } from 'react';
+import { PrizmaTextField } from '@incodetech/prizma-core-web/text-field';
+import { PrizmaFormScreen, type PrizmaFormScreenProps } from './FormScreen';
+import type { PrizmaScreenActionHandler, PrizmaScreenOverrides } from './types';
+import type { EmailInputStrings, EmailInputVerifyState } from './EmailInputStrings';
+import './ScreenLayout.css';
+
+export interface EmailInputVerifyScreenProps
+  extends Omit<
+    PrizmaFormScreenProps,
+    'title' | 'subtitle' | 'ctaLabel' | 'verifiedLabel' | 'children' | 'navLabel'
+  > {
+  /** Module copy — this screen reads the `verify` slice. */
+  strings: EmailInputStrings;
+  /** Which purple `email.verifyEmail.*` section to render. Default `default`. */
+  state?: EmailInputVerifyState;
+  /** The address as typed. Empty renders the placeholder (`default`). */
+  value?: string;
+  screenId?: string;
+  overrides?: PrizmaScreenOverrides;
+  onAction?: PrizmaScreenActionHandler;
+}
+
+/**
+ * Email Input — the address-entry screen, built on the Form archetype
+ * (GUIDELINES.md §6-E, `PrizmaFormScreen`).
+ *
+ * ONE screen for all five purple `email.verifyEmail.*` sections
+ * (`default` / `typing` / `filled` / `error` / `loading`): measured against the
+ * 390 frames they share an identical layout — nav → Title (H2 + H5) →
+ * Spacing/32 → the email field → CTA → tag — and differ ONLY in field content
+ * and CTA state.
+ *
+ * Where this parts company with its Phone Input sibling: there is no dial-code
+ * pairing here, so no `Input / Combined` row and no module CSS at all — a bare
+ * `PrizmaTextField` is the whole field stack, and every offset stays the
+ * archetype's.
+ *
+ * Field treatments, one per Figma frame rather than one for all:
+ * - `default` — resting field, placeholder only
+ * - `typing` / `filled` — Figma draws BOTH with the focused blue border and a
+ *   caret, differing only in how much of the address is typed
+ * - `error` — Core's negative treatment plus the clear ✕ Figma draws on this
+ *   section alone
+ * - `loading` — the one section Figma greys, with the spinner in the CTA
+ *
+ * Core's `readOnly` is deliberately NOT used to make the field static: it
+ * paints the DISABLED surface (owner definition 2026-07-12), which would grey
+ * the four resting states Figma draws white. The field is uncontrolled instead
+ * (DEVIATIONS #PI-6).
+ */
+export const EmailInputVerifyScreen = forwardRef<HTMLDivElement, EmailInputVerifyScreenProps>(
+  (
+    {
+      strings,
+      state = 'default',
+      value,
+      screenId = `email-input-verify-${state}`,
+      overrides,
+      onAction,
+      ...shell
+    },
+    ref,
+  ) => {
+    const busy = state === 'loading';
+    const invalid = state === 'error';
+    const focused = state === 'typing' || state === 'filled';
+
+    return (
+      <PrizmaFormScreen
+        ref={ref}
+        title={strings.verify.title}
+        subtitle={strings.verify.subtitle}
+        ctaLabel={strings.verify.ctaLabel}
+        /* Figma's `loading` section swaps the CTA label for Core's spinner. */
+        ctaLoading={busy}
+        ctaLoadingLabel={strings.verify.ctaLoadingLabel}
+        verifiedLabel={strings.verifiedLabel}
+        navLabel={strings.navLabel}
+        screenId={screenId}
+        overrides={overrides}
+        onAction={onAction}
+        {...shell}
+      >
+        <PrizmaTextField
+          className={
+            /* Core's OWN static-focus modifier — the class its CSS already
+               implements beside `:focus-within`. `PrizmaTextField` has no
+               `forceState` prop the way `PrizmaDropdown` does, so this is how a
+               static spec state draws the focus ring without redeclaring any
+               styling (DEVIATIONS #PI-7). */
+            focused ? 'prizma-input-textfield--focused' : undefined
+          }
+          type="email"
+          inputMode="email"
+          autoComplete="email"
+          /* Figma's field has no visible label row — the placeholder carries
+             the meaning — so the copy rides `aria-label` (DEVIATIONS #PI-4). */
+          aria-label={strings.verify.fieldLabel}
+          placeholder={strings.verify.placeholder}
+          /* Uncontrolled: a screen is one static spec state, so no `onChange`
+             is needed and no warning is raised. */
+          defaultValue={value ?? ''}
+          disabled={busy}
+          error={invalid}
+          errorText={invalid ? strings.verify.errorText : undefined}
+          /* The clear ✕ is drawn on the `error` section only. */
+          clearable={invalid}
+          clearLabel={strings.verify.clearLabel}
+        />
+      </PrizmaFormScreen>
+    );
+  },
+);
+EmailInputVerifyScreen.displayName = 'EmailInputVerifyScreen';
+
+export default EmailInputVerifyScreen;