/* ============================================================
   EveryChat — layout.css
   ------------------------------------------------------------
   App shell, page-group sidebars, page containers, and grid /
   section patterns. Visual primitives (buttons, inputs, chips,
   modals, etc.) live in components.css and are not redefined
   here.

   All values reference tokens from tokens.css. No hardcoded
   colors / sizes / spacings — if a value can't come from a
   token, it's flagged in the summary at the bottom of this
   file.

   BEM throughout. State classes use the `is-` prefix
   (.is-open, .is-active, .is-collapsed, etc.).

   ------------------------------------------------------------
   RESPONSIVE BREAKPOINTS
   ------------------------------------------------------------
   The canonical breakpoint scale lives in tokens.css as
   --bp-wide / --bp-tablet / --bp-mobile. Important caveat:
   CSS custom properties cannot be used inside @media queries,
   so the @media rules below must use literal pixel values.
   Keep these in sync with tokens.css manually.

     --bp-wide     1280px  multi-column collapses to 2-col
     --bp-tablet   1000px  shell collapses, sidebars hide /
                           become drawer-style
     --bp-mobile    640px  single-column form rows, stacked
                           card heads

   ------------------------------------------------------------
   SECTION INDEX
   ------------------------------------------------------------
   1. Base reset (page-level only — no element styling)
   2. App shell — .app, .app__topbar, .app__main, .app__footer
   3. Page-group sidebar layout positioning
        Width, flex-shrink, and scroll behavior for the four
        canonical sidebars. Visual chrome (background, padding,
        item styling, hover/focus/active states, etc.) lives in
        components.css under the same class names.
   4. Page containers
        4a. .page (base)
        4b. .page--narrow      (centered narrow — Settings)
        4c. .page--full        (full-width — dashboards, lists)
        4d. .page--with-rail   (two-column with right rail)
        4e. .page--inbox-shell (three-column — Inbox)
   5. Page chrome — .page__header, .page__toolbar, .page__body,
        .page__footer
   6. Section / grid patterns
        6a. .grid--cards
        6b. .split (master-detail)
        6c. .form-grid
   7. Responsive overrides
   ============================================================ */


/* ============================================================
   1. BASE RESET (page-level only)
   ============================================================
   These rules govern the html/body chrome the shell relies on:
   full viewport height, no scroll on the body itself (the
   shell's main region scrolls instead), and the app surface
   color. Element-level resets (typography, button defaults,
   etc.) live in tokens.css / global typography rules and are
   intentionally not duplicated here.
   ============================================================ */

html,
body {
  height: 100%;
  margin: 0;
  padding: 0;
}

body {
  background: var(--color-bg-off);
  color: var(--color-text);
  font-family: var(--font-body);
  font-size: var(--font-size-body);
  line-height: var(--line-height-body);
  -webkit-font-smoothing: antialiased;

  /* The shell owns the viewport; main content scrolls inside
     the .app__main region rather than on the body. Pages that
     need body-level scroll (rare — long settings pages with
     no fixed shell) override this with .body--scrollable. */
  overflow: hidden;
}

/* Opt-in escape hatch: pages whose shell does NOT need to fit
   the viewport (e.g. the standalone marketing/auth screens)
   add `.body--scrollable` to body to restore native scroll. */
.body--scrollable {
  overflow: auto;
}


/* ============================================================
   2. APP SHELL
   ============================================================
   Top-level grid:
     - 56px topbar across the full width
     - Below the topbar: main region (which itself houses the
       page-group sidebar + page content for pages that have
       one). Pages without a page-group sidebar place their
       .page directly into .app__main.

   The Inbox is the one exception: it has both an .inbox-rail
   (the dark icon strip) AND a folder list, so its shell uses
   the .page--inbox-shell layout to express three columns.
   ============================================================ */

.app {
  display: grid;
  grid-template-rows: var(--topbar-height) 1fr;
  height: 100vh;
  /* Clamp the grid to the viewport so child rows can't overflow
     past their allotted track. Without this, a tall .app__main
     can push past its 1fr row and slide visually behind the
     footer row, depending on browser. */
  overflow: hidden;
  background: var(--color-bg-off);
}

/* ----- Topbar ----- */
.app__topbar {
  /* Full-width row 1 of the shell grid. */
  grid-row: 1;
  /* display: flex; */
  /* align-items: center; */
  gap: var(--space-4);
  background: var(--color-bg);
  border-bottom: 1px solid var(--color-border);
  z-index: var(--z-sticky);
}

/* The topbar's z-index (--z-sticky, 100) creates a stacking context that
   confines its descendants — including the profile dropdown, which composes
   .dropdown at --z-popover (1000). That internal 1000 only competes *within*
   the topbar, so any root-level fixed overlay above 100 (side panels at
   --z-dropdown 500, info-panel scrims ~999, the automation builder drawer at
   1990/1991) renders on top of the open dropdown.

   While the dropdown is open, lift the whole topbar stacking context above
   those overlays so the dropdown wins. Kept just below --z-modal (2000) so
   genuine modal dialogs and their backdrops still cover the nav. Reverts to
   --z-sticky when the menu closes. */
.app__topbar:has(.topbar__profile.is-open) {
  z-index: calc(var(--z-modal) - 1);
}

/* ----- Main region ----- */
.app__main {
  /* Row 2 — owns the rest of the viewport. min-height: 0 lets
     nested grid/flex children scroll properly. */
  grid-row: 2;
  display: flex;
  min-height: 0;
  overflow: hidden;
}

/* When the main region needs a horizontal split (sidebar +
   content), pages set the layout via a .page-- modifier on
   the .page element rather than on .app__main itself. This
   keeps .app__main a single, predictable container. */

/* ----- Footer ----- */
.app__footer {
  /* Persistent footer below the main region. Rendered on
     every page EXCEPT the customer-facing online scheduling
     pages and review survey pages (where chrome is stripped
     to keep the focus on the booking / review action).
     Injected via a Handlebars partial; pages that include
     the partial also need .app--has-footer on .app to
     allocate the third grid row.

     Surface: dark navy (rail bg) with light text. Same
     surface family as the dark sidebars, so the contrast
     against the page above handles separation — no top
     border needed.

     Currently hidden product-wide pending a layout-mode
     decision (viewport-clamped shell vs. document-flow
     shell). The rules below are kept so the footer can be
     re-enabled later by removing this `display: none`.
     See the conversation history for context. */
  display: none;
  grid-row: 3;
  align-items: center;
  justify-content: center;
  padding: var(--space-7) var(--space-9);
  background: var(--color-rail-bg);
  color: var(--color-rail-fg);
  font-size: var(--font-size-small);
  text-align: center;
}

/* Shell modifier: if a footer is rendered, the .app grid
   needs a third row. Apply this on .app to get the right
   template. */
.app--has-footer {
  grid-template-rows: var(--topbar-height) 1fr auto;
}


/* ============================================================
   3. PAGE-GROUP SIDEBAR LAYOUT POSITIONING
   ------------------------------------------------------------
   Four canonical sidebars, per component-decisions.md.
   IMPORTANT: components.css owns the visual chrome for these
   sidebars (background, padding, item styling, hover/focus/
   active states, eyebrow + title typography, etc.). This
   section adds ONLY the layout concerns components.css can't
   own without making rigid assumptions about the page shell:

     - Outer width
     - flex-shrink (so they don't compress when main content
       grows)
     - Anything related to fitting inside .app__main's flex
       row

   Adding visual styling here would create cascade conflicts
   with components.css. If a sidebar needs surface tweaks,
   change components.css.

   The four canonical sidebars:
     .inbox-rail              — 64px dark icon strip
     .profile-sidebar         — 260px dark nav (Settings)
     .scheduling-sidebar      — 260px white nav (editor flow)
     .form-builder-sidebar    — 320px dark settings panel
   ============================================================ */

.inbox-rail {
  flex-shrink: 0;
  width: var(--inbox-rail-width);
}

.profile-sidebar {
  flex-shrink: 0;
  width: 260px;       /* No --width-profile-sidebar token yet;
                         flagged in summary. */
}

.scheduling-sidebar {
  flex-shrink: 0;
  width: 260px;       /* Same width as .profile-sidebar — both
                         are page-group nav. Could share a token
                         (e.g. --width-page-nav-sidebar). */
}

.form-builder-sidebar {
  flex-shrink: 0;
  width: 320px;       /* Wider than the nav sidebars because it
                         holds form controls, not just nav items. */
  min-height: 0;      /* Allows the inner __body region to scroll
                         while __top and __foot stay pinned. */
}


/* ============================================================
   4. PAGE CONTAINERS
   ------------------------------------------------------------
   Every page mounts a .page (or one of its modifiers) inside
   .app__main. The modifier picks the layout shape for that
   page; the chrome elements (header, toolbar, body, footer)
   in section 5 plug into all variants identically.

   Pages that pair with a page-group sidebar render the
   sidebar element FIRST inside .app__main, then the .page
   second:

     <main class="app__main">
       <aside class="profile-sidebar">…</aside>
       <section class="page page--narrow">…</section>
     </main>
   ============================================================ */


/* ----- 4a. .page (base) ----- */
.page {
  flex: 1;
  display: flex;
  flex-direction: column;
  min-width: 0;
  min-height: 0;
  background: var(--color-bg);
  overflow: hidden;
}


/* ----- 4b. .page--narrow -----
   Centered narrow content column for forms-heavy pages
   (Profile Settings, Scheduling Settings forms, Billing).
   Inner content is capped at 820px and centered with a
   generous gutter. */

.page--narrow {
  background: var(--color-bg-off);
  overflow-y: auto;
  padding: var(--space-14) var(--space-16) var(--space-24);
}

.page--narrow .page__header {
  width: 100%;
  /* max-width: 1280px; */
  margin-inline: auto;
}

/* Inner wrapper that does the actual centering. Pages put
   their content inside this. */
.page--narrow > .page__inner {
  width: 100%;
  max-width: var(--max-width-narrow);
  margin: 0 auto;
}


/* ----- 4c. .page--full -----
   Full-width page that fills the area under the topbar.
   Used for dashboards, list views (Contact List, Task List,
   Campaign list, etc.). The .page__body inside scrolls; the
   header/toolbar/footer stay pinned. */

.page--full {
    overflow-y: auto;
    padding: var(--space-10) var(--space-16) var(--space-16);
}

.page--full.page--edge-to-edge {
  padding: var(--space-10) 0 0;
}

.page--edge-to-edge .page__header {
  padding: var(--space-8) var(--space-8) var(--space-7);
  margin-bottom: 0px;
}

/* Cap direct content regions at 1280px and center them, so full-width
   pages stay readable on very wide screens without page-level CSS
   duplicating this constraint on every page. */
.page--full > .page__header,
.page--full > .page__body {
  width: 100%;
  /* max-width: 1280px; */
  margin-inline: auto;
}


/* ----- 4d. .page--with-rail -----
   Two-column layout: main content on the left, persistent
   right rail (a `.side-panel`, see components.css component
   #25) on the right. Used for detail pages that want a
   contextual side panel (Contact Detail with contact info,
   Task Detail with helpful videos, etc.).

   The .side-panel itself comes from components.css; this
   modifier just provides the row/column shape. */

.page--with-rail {
  flex-direction: row;
}

.page--with-rail > .page__main {
  flex: 1;
  display: flex;
  flex-direction: column;
  min-width: 0;
  min-height: 0;
  overflow: hidden;
}

.page--with-rail > .side-panel {
  flex-shrink: 0;
  width: var(--width-side-panel);
  border-left: 1px solid var(--color-border);
  background: var(--color-bg);
  overflow-y: auto;
}


/* ----- 4e. .page--inbox-shell -----
   Three-column layout for the Inbox: the .inbox-rail on the
   left (icon strip), a folder/account sidebar in the middle,
   and the email/SMS list on the right. The .inbox-rail itself
   is rendered as a sibling of .page (in .app__main), so this
   modifier expresses the remaining two columns: inner
   sidebar + content. */

.page--inbox-shell {
  display: grid;
  grid-template-columns: 256px 1fr;
  min-height: 0;
  overflow: hidden;
}

/* The inner sidebar (account selector, folder list, labels).
   This is a page-local surface — distinct from the four
   canonical sidebars in section 3. Pages compose what they
   need from existing primitives inside it. */
.page--inbox-shell > .page__sidebar {
  display: flex;
  flex-direction: column;
  min-height: 0;
  background: var(--color-bg);
  border-right: 1px solid var(--color-border);
}

/* The right column — the actual list/thread content. */
.page--inbox-shell > .page__main {
  display: flex;
  flex-direction: column;
  min-width: 0;
  min-height: 0;
  background: var(--color-bg);
}


/* ============================================================
   5. PAGE CHROME
   ------------------------------------------------------------
   The header / toolbar / body / footer that compose inside
   any .page variant. They are stacked vertically; only
   .page__body scrolls.
   ============================================================ */

.page__header {
    display: flex;
    align-items: center;
    justify-content: space-between;
    gap: var(--space-5);
    border-bottom: 1px solid var(--color-border-light);
    flex-shrink: 0;
    margin-bottom: var(--space-12);
    padding-bottom: var(--space-8);
}

/* Title + meta cluster on the left side of the header. */
.page__title {
  display: flex;
  align-items: baseline;
  gap: var(--space-5);
  min-width: 0;
}

/* Pushes header actions to the right side. */
.page__header-grow {
  flex: 1;
}

.page__eyebrow {
  font: 600 11px / 1 var(--font-body);
  letter-spacing: 0.08em;
  text-transform: uppercase;
  color: var(--color-text-dim);
  margin: 0 0 var(--space-2) 0;
}

.page__heading {
  font-family: var(--font-display);
  font-size: var(--font-size-h2);
  font-weight: var(--font-weight-bold);
  color: var(--color-text);
  line-height: 1.15;
  margin: 0 0 var(--space-3) 0;
}

/* ── HOW WIDE A LINE OF EXPLANATION GETS ──────────────────────────────
   **450px** (JP, 2026-10-14: *"We would like to take all of them down to 450
   wide... I want that to be consistent across all the settings screens."*).

   THE HISTORY, BECAUSE THIS IS THE SECOND ANSWER AND NOT THE FIRST. It was
   445px on twenty-six screens and 720px on the five estimates screens and
   Custom Fields, under a separate "one reading width" decision — the product
   had two answers and nobody had picked. On 2026-10-11 JP picked 720 and the
   twenty-six moved. Seeing it, he has picked 450, which is within five pixels
   of where the twenty-six started.

   **IT IS THE SHARED RULE, SO IT REACHES ELEVEN SCREENS OUTSIDE THE SETTINGS
   MENU TOO** — the autoresponders, forms, message templates, scheduled
   messages, surveys, appointment types and webchat. That is deliberate rather
   than overlooked: every one of them was 445px until three days ago, so this
   puts them back roughly where they were rather than leaving the product with
   two answers again, which is the thing the 11th was meant to end.

   450px is about 47 characters at 13px, so a sentence explaining a screen
   wraps onto two or three lines instead of running wide.

   One page overrides this to `none` because its layout is wider still
   (`pages/compliance/campaign-registration.css`). */
.page__subtitle {
  font-size: var(--text-sm);
  color: var(--color-text-secondary);
  line-height: 1.5;
  margin: 0;
  max-width: 450px;
}

.page__button-flex {
  display: flex;
  gap: 5px;
}

/* Optional toolbar row below the header — search bars,
   filter chips, view toggles. */
.page__toolbar {
  display: flex;
  align-items: center;
  gap: var(--space-5);
  padding: var(--space-6) var(--space-8);
  background: var(--color-bg);
  border-bottom: 1px solid var(--color-border-light);
  flex-shrink: 0;
}

.page__toolbar-grow {
  flex: 1;
}

/* The scrollable body region. */
.page__body {
  flex: 1;
  min-height: 0;
  overflow-y: auto;
  /* background: var(--color-bg); */
}

/* Optional sticky footer for paginators / status bars. */
.page__footer {
  display: flex;
  align-items: center;
  justify-content: space-between;
  gap: var(--space-5);
  padding: var(--space-7) var(--space-10);
  background: var(--color-bg);
  border-top: 1px solid var(--color-border);
  font-size: var(--font-size-caption);
  color: var(--color-text-dim);
  flex-shrink: 0;
}


/* ============================================================
   6. SECTION / GRID PATTERNS
   ------------------------------------------------------------
   Repeated layout structures inside pages. These are
   structural only — the visual treatment of the things
   inside (cards, list rows, form fields) comes from
   components.css.
   ============================================================ */


/* ----- 6a. .grid--cards -----
   Auto-fit grid for collections of cards / dashboard tiles /
   empty-state action cards. Cards never go below 280px wide;
   beyond that, columns multiply automatically. */

.grid--cards {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(280px, 1fr));
  gap: var(--space-9);
}

/* Tighter variant used in dense contexts (e.g. tile grids
   inside a settings card). */
.grid--cards.grid--cards-tight {
  gap: var(--space-6);
  grid-template-columns: repeat(auto-fit, minmax(220px, 1fr));
}


/* ----- 6b. .split (master-detail) -----
   Two-pane horizontal split: a list on the left, the detail
   for the selected item on the right. Used inside .page__body
   wherever a master/detail pattern is needed (e.g. a thread
   view: thread list + thread content).

   Modifiers:
     .split--narrow-list   200px master  (compact lists)
     default               300px master  (richer list rows)
     .split--wide-list     400px master  (preview columns) */

.split {
  display: grid;
  grid-template-columns: 300px 1fr;
  height: 100%;
  min-height: 0;
}

.split--narrow-list {
  grid-template-columns: 200px 1fr;
}

.split--wide-list {
  grid-template-columns: 400px 1fr;
}

.split__master {
  display: flex;
  flex-direction: column;
  min-height: 0;
  border-right: 1px solid var(--color-border);
  background: var(--color-bg);
  overflow: hidden;
}

.split__detail {
  display: flex;
  flex-direction: column;
  min-width: 0;
  min-height: 0;
  background: var(--color-bg);
  overflow: hidden;
}


/* ----- 6c. .form-grid -----
   Two-column grid of form fields, with single-column rows
   spanning both columns when needed. Used inside settings
   cards and modals. The visual styling of each field comes
   from .field / .input in components.css.

   Modifiers:
     default        2-col
     .form-grid--3  3-col (used by Profile Settings .ps-row-3)

   Sub-element:
     .form-grid__full   row that spans every column */

.form-grid {
  display: grid;
  grid-template-columns: 1fr 1fr;
  gap: var(--space-8);
}

.form-grid--3 {
  grid-template-columns: 1fr 1fr 1fr;
}

.form-grid__full {
  grid-column: 1 / -1;
}


/* ============================================================
   7. RESPONSIVE OVERRIDES
   ------------------------------------------------------------
   Two breakpoints used: 1055px (shell collapse) and 835px
   (single-column form rows). Canonical scale is in tokens.css
   (--bp-tablet, --bp-mobile). @media queries must use literal
   values — see breakpoints comment at the top of this file.

   Note: .inbox-rail and .form-builder-sidebar are NOT
   collapsed in this rewrite — they are essential to those
   pages. If they need to be hidden on small screens, that
   is a JS-driven mobile-drawer behavior the pages opt into
   per-route, and is flagged for design clarification in the
   summary.
   ============================================================ */


@media (max-width: 1055px) {
  .page--full {
    padding: var(--space-12) var(--space-8) var(--space-16);
  }

  /* Shell — page-group sidebars hide on tablet so the page
     content gets the full width. The four sidebars all
     accept a `.is-hidden` state for explicit JS control;
     this rule is the default-collapse fallback. */
  .profile-sidebar,
  .scheduling-sidebar {
    display: none;
  }

  .profile-sidebar.is-open,
  .scheduling-sidebar.is-open {
    display: flex;
  }

  /* Page containers — the centered-narrow page tightens its
     gutter so it fits comfortably on tablet. */
  .page--narrow {
    padding: var(--space-12) var(--space-9) var(--space-20);
  }

  /* Three-column inbox collapses to two: the inbox-rail stays
     (it's essential to the inbox), the inner sidebar
     collapses behind a JS toggle. */
  .page--inbox-shell {
    grid-template-columns: 1fr;
  }

  .page--inbox-shell > .page__sidebar {
    display: none;
  }

  .page--inbox-shell > .page__sidebar.is-open {
    display: flex;
  }

  /* Two-column with right rail — rail collapses behind toggle. */
  .page--with-rail {
    flex-direction: column;
  }

  .page--with-rail > .side-panel {
    width: 100%;
    border-left: 0;
    border-top: 1px solid var(--color-border);
  }

  /* Page heading scales down at tablet so it doesn't dominate
     the layout when the sidebar is hidden and the heading
     is the widest element on screen. */
  .page__heading {
    font-size: var(--font-size-h3); /* 30px → 22px */
    margin: 0;
  }

  .page__title {
    font-size: 30px;
  }
}


@media (max-width: 835px) {
  /* Form grid collapses to a single column on phones. */
  .form-grid, .form-grid--3 {
    grid-template-columns: 1fr;
    gap: 0px;
    margin-bottom: var(--space-8);
  }

  /* Card grid: minimum item width relaxes a bit so single-column
     cards don't overflow on the narrowest phones. */
  .grid--cards {
    grid-template-columns: 1fr;
    gap: var(--space-6);
  }

  /* Page chrome tightens its horizontal padding. */
  /* .page__header, */
  .page__toolbar {
    padding-left: var(--space-7);
    padding-right: var(--space-7);
  }

  /* Header stacks vertically on phones — action buttons move
     below the text block instead of squeezing beside it. */
  .page__header {
    /* flex-direction: column;
    align-items: flex-start; */
    gap: var(--space-9);
  }

  /* Spacer is meaningless in a column layout — hide it so it
     doesn't push buttons to the bottom of the header. */
  .page__header-grow {
    display: none;
  }

  .page--narrow {
    padding: var(--space-10) var(--space-7) var(--space-16);
  }
}


/* ============================================================
   8. AUTH LAYOUT
   ------------------------------------------------------------
   Shared shell for public-facing authentication pages:
   login, forgot password, verification code, new password.
   These pages live outside the app shell — no topbar, no
   sidebar, no .app wrapper. The body uses .body--scrollable
   (defined in §1 above) to restore native scroll.

   Class hierarchy:
     .auth-root                  full-viewport centered wrapper
       .auth-form-col            single flex column, full height
         .auth-topbar            logo header row
           .auth-logo            logo link
         .auth-form-wrap         vertically-centered content area
           .auth-card            white card surface
             .auth-title         h1 display heading
             .auth-sub           subtitle paragraph
             .login-sso          SSO button stack (Google/Outlook)
               .login-sso__btn   individual SSO button
               .login-sso__icon  leading provider icon
             .auth-form          flex column form
               .auth-input-wrap  icon-prefixed input wrapper
                 .auth-input-icon  leading icon slot
         .auth-prompt            below-card text / link line
         .auth-footer            footer link row
           .auth-footer__dot     separator dot
     .auth-error-toast           fixed error toast (shown via JS)
   ============================================================ */


/* =================== Root layout =================== */

.auth-root {
  min-height: 100vh;
  display: flex;
  align-items: flex-start;
  justify-content: center;
  background:
    radial-gradient(circle, rgba(37, 99, 235, 0.04) 1px, transparent 1px) 0 0 / 22px 22px,
    var(--color-bg-off);
}


/* =================== Form column =================== */

.auth-form-col {
  width: 100%;
  display: flex;
  flex-direction: column;
  align-items: center;
  padding: 36px 24px 48px;
  min-height: 100vh;
}

.auth-topbar {
  width: 100%;
  max-width: 1100px;
  display: flex;
  align-items: center;
  justify-content: center;
  margin-bottom: auto;
}

.auth-logo {
  display: inline-flex;
  align-items: center;
}

.auth-logo img {
  height: 26px;
  display: block;
}

.auth-form-wrap {
  width: 100%;
  display: flex;
  flex-direction: column;
  align-items: center;
  gap: 22px;
  padding: 32px 0;
  flex: 1;
  justify-content: center;
}

.auth-card {
  width: 100%;
  max-width: 420px;
  background: var(--color-bg);
  border: 1px solid var(--color-border);
  border-radius: var(--radius-lg);
  padding: 40px 36px 32px;
  box-shadow: var(--shadow-lg);
}

.auth-title {
  font-family: var(--font-display);
  font-size: 32px;
  font-weight: var(--font-weight-bold);
  letter-spacing: -0.015em;
  color: var(--color-text);
  margin: 0 0 6px;
  line-height: 1.15;
}

.auth-sub {
  font-size: var(--font-size-body);
  color: var(--color-text-secondary);
  margin: 0 0 28px;
}


/* =================== SSO buttons =================== */

.login-sso {
  display: flex;
  flex-direction: column;
  gap: 10px;
  margin-bottom: 22px;
}

.login-sso form {
  width: 100%;
}

/* Composing on top of .btn--secondary — adds icon gap and adjusts height */
.login-sso__btn {
  gap: 9px;
  padding: 11px 14px;
  height: auto;
  font-size: var(--font-size-small);
}

.login-sso__btn:hover {
  transform: translateY(-1px);
}

.login-sso__btn:active {
  transform: translateY(0);
}

.login-sso__icon {
  width: 18px;
  height: 18px;
  flex-shrink: 0;
}


/* =================== Divider =================== */

.auth-divider {
  display: flex;
  align-items: center;
  gap: 12px;
  margin-bottom: 22px;
  font-size: var(--font-size-micro);
  font-weight: var(--font-weight-semibold);
  letter-spacing: var(--letter-spacing-micro);
  text-transform: uppercase;
  color: var(--color-text-dim);
}

.auth-divider::before,
.auth-divider::after {
  content: '';
  flex: 1;
  height: 1px;
  background: var(--color-border);
}


/* =================== Form =================== */

.auth-form {
  display: flex;
  flex-direction: column;
  gap: 10px;
}

/* Icon-prefixed input wrapper — the wrap owns the border/focus
   ring so the icon and input appear as a single unit. */
.auth-input-wrap {
  display: flex;
  align-items: center;
  background: var(--color-bg);
  border: 1px solid var(--color-border);
  border-radius: var(--radius-sm);
  padding: 0 14px;
  transition: border-color var(--duration-base), box-shadow var(--duration-base);
}

.auth-input-wrap:hover {
  border-color: var(--color-border-hover);
}

.auth-input-wrap:focus-within {
  border-color: var(--color-blue);
  box-shadow: 0 0 0 3px var(--color-focus-ring);
}

/* Strip .input's own border/shadow so the wrap controls chrome */
.auth-input-wrap .input {
  border: 0;
  background: transparent;
  box-shadow: none;
  padding: 11px 0;
  flex: 1;
  min-width: 0;
  font-size: var(--font-size-body);
  color: var(--color-text);
}

.auth-input-wrap .input:focus {
  border: 0;
  box-shadow: none;
  outline: 0;
}

.auth-input-icon {
  color: var(--color-text-dim);
  margin-right: 10px;
  display: inline-flex;
  flex-shrink: 0;
}

.auth-input-icon svg {
  width: 16px;
  height: 16px;
}


/* =================== Below-card elements =================== */

.auth-prompt {
  margin: 0;
  font-size: var(--font-size-small);
  color: var(--color-text-secondary);
  text-align: center;
}

.auth-prompt a {
  margin-left: 6px;
  font-weight: var(--font-weight-semibold);
  color: var(--color-blue);
}

.auth-prompt a:hover {
  color: var(--color-blue-dark);
}

.auth-footer {
  display: flex;
  align-items: center;
  justify-content: center;
  gap: 4px;
  font-size: var(--font-size-caption);
  color: var(--color-text-dim);
  padding-top: 8px;
  margin-top: auto;
}

.auth-footer a {
  color: var(--color-text-secondary);
  font-weight: var(--font-weight-medium);
  text-decoration: none;
  transition: color var(--duration-fast);
}

.auth-footer a:hover {
  color: var(--color-text);
}

.auth-footer__dot {
  margin: 0 4px;
}


/* =================== Error toast & server banners =================== */

#application_error_message,
#application_alert_message,
#application_success_message {
  position: fixed;
  top: var(--space-8);
  left: 50%;
  transform: translateX(-50%);
  z-index: var(--z-toast);
}

.auth-server-banner {
  position: fixed;
  top: 20px;
  left: 50%;
  transform: translateX(-50%);
  background: var(--color-red);
  color: #fff;
  font-size: var(--font-size-small);
  font-weight: var(--font-weight-medium);
  padding: 10px 20px;
  border-radius: var(--radius-sm);
  box-shadow: var(--shadow-md);
  z-index: var(--z-toast);
  white-space: nowrap;
}

/* Neutral variant for non-error context (e.g. "log in to continue connecting
   Jobber") — same shape as the default red error banner, action-blue instead. */
.auth-server-banner--info {
  background: var(--color-action);
  white-space: normal;
  max-width: 90vw;
  text-align: center;
}

.auth-error-toast {
  position: fixed;
  top: 20px;
  left: 50%;
  transform: translateX(-50%);
  background: var(--color-red);
  color: #fff;
  font-size: var(--font-size-small);
  font-weight: var(--font-weight-medium);
  padding: 10px 20px;
  border-radius: var(--radius-sm);
  box-shadow: var(--shadow-md);
  z-index: var(--z-toast);
  pointer-events: none;
  white-space: nowrap;
}

.auth-error-toast p {
  margin: 0;
}


/* =================== Responsive =================== */


@media (max-width: 835px) {
  .auth-form-col {
    padding: 24px 16px 40px;
  }

  .auth-card {
    padding: 32px 24px 28px;
    border-radius: var(--radius);
  }
}



/* ============================================================
   SUMMARY
   ============================================================

   Sections covered
   ----------------
   1. Base reset (page-level only — no element styling)
   2. App shell — .app, .app__topbar, .app__main, .app__footer
        + .app--has-footer modifier
   3. Page-group sidebar layout positioning — width and
        flex-shrink for .inbox-rail, .profile-sidebar,
        .scheduling-sidebar, .form-builder-sidebar.
        Visual chrome lives in components.css.
   4. Page containers — .page base + 4 modifiers
        --narrow, --full, --with-rail, --inbox-shell
   5. Page chrome — __header, __title, __header-grow, __toolbar,
        __toolbar-grow, __body, __footer
   6. Section / grid patterns — .grid--cards, .split, .form-grid
   7. Responsive overrides at 1000px and 640px

   Top-level class hierarchy (for confirmation before propagation)
   ---------------------------------------------------------------
   App shell:
     .app
       .app--has-footer                   modifier
       .app__topbar
       .app__main
       .app__footer

   Page-group sidebars (layout positioning only — full anatomy
   in components.css):
     .inbox-rail
     .profile-sidebar
     .scheduling-sidebar
     .form-builder-sidebar

   Page containers:
     .page                                base
       .page--narrow                      modifier
       .page--full                        modifier
       .page--with-rail                   modifier
       .page--inbox-shell                 modifier
       .page__inner                       (used inside --narrow
                                            for centering)
       .page__sidebar                     (used inside --inbox-shell)
       .page__main                        (used inside --with-rail
                                            and --inbox-shell)
       .page__header
       .page__title
       .page__header-grow
       .page__toolbar
       .page__toolbar-grow
       .page__body
       .page__footer

   Patterns:
     .grid--cards
       .grid--cards-tight                 modifier
     .split
       .split--narrow-list                modifier
       .split--wide-list                  modifier
       .split__master
       .split__detail
     .form-grid
       .form-grid--3                      modifier
       .form-grid__full                   sub-element

   Responsive behavior needing design clarification
   ------------------------------------------------
   1. .inbox-rail and .form-builder-sidebar do NOT auto-hide
      at the 1000px breakpoint. The inbox rail is the page's
      primary nav (channels) and the form-builder sidebar IS
      the editor's settings UI — both arguably need to stay
      visible on tablet. Confirm: do these get a JS-driven
      mobile drawer pattern, or do they stay in place?

   2. .page--with-rail collapse on tablet stacks the side
      panel BELOW the main content. Confirm that's the
      intended collapse behavior — the alternative is to
      hide the side panel and let the user open it as a
      drawer/modal. The decisions doc says .side-panel has
      no backdrop and is a layout region, which suggests
      stacking is correct, but worth verifying.

   3. The .scheduling-sidebar collapses at 1000px the same
      way as .profile-sidebar. The Scheduling editor flow
      may want a different mobile pattern (e.g. a top-of-page
      step indicator instead of a hidden side nav). Confirm.

   Places where the designs implied a layout pattern that
   wasn't fully clear
   --------------------------------------------------------
   1. Inbox three-column shell — the inner sidebar (folder
      list / account picker) is positioned as `.page__sidebar`
      INSIDE `.page--inbox-shell`. The decisions doc lists
      this surface in the "page-local" bucket (not one of the
      four canonical sidebars), so it lives here as a generic
      page-shell column rather than a named component. Confirm
      that's the right home for it.

   Tokens needed but not in tokens.css
   -----------------------------------
   1. .profile-sidebar and .scheduling-sidebar both use a
      hardcoded 260px width here. tokens.css doesn't yet have
      a width token for the page-group nav sidebars. Worth
      adding either:
        a) --width-page-nav-sidebar (shared by both), or
        b) --width-profile-sidebar + --width-scheduling-sidebar
           (separate, in case they diverge).
      The scheduling-sidebar's 260px matches the profile-sidebar's
      260px today, so option (a) is simpler.

   Otherwise, all previously-flagged tokens have been added to
   tokens.css (--font-size-rail-label, --font-size-sidebar-title,
   --color-on-action-subtle, --topbar-height, --inbox-rail-width,
   --max-width-narrow, --width-side-panel, plus the breakpoint
   scale --bp-wide / --bp-tablet / --bp-mobile).

   One outstanding note: CSS custom properties cannot be used
   inside @media queries, so the @media rules in section 7
   still use literal pixel values. Keep them in sync with the
   breakpoint tokens manually until the project adopts
   container queries or a CSS preprocessing step.

   ============================================================ */