/* Denizen Blu: remove LibreChat's default circular icon-frame
   (background fill + inset ring) around endpoint/model logos —
   our logo already reads fine on its own without a badge frame. */
.shadow-stroke {
  background-color: transparent !important;
}
.shadow-stroke::after {
  box-shadow: none !important;
}

/* Denizen Blu brand accent, continuing the same palette
   bluroute/models_ui/static/models.html uses (--blu-bright: #5b9bff,
   --blu-glow: #2563eb) — LibreChat ships OpenAI's teal-green (#10a37f)
   as its default accent throughout, e.g. its own dark:peer-focus:text-
   green-500 / focus:border-green-500 login-input classes and bg-green-*
   submit buttons.

   --surface-submit/--surface-submit-hover/--brand-purple/--ring are
   LibreChat's own themeable CSS custom properties (confirmed live
   2026-08-14 via the running container's built assets: index.*.css sets
   them on :root/.dark, and hooks.*.js reads the same var names as a
   per-user "custom theme" override via themeRGB/setThemeRGB -- setting
   them here as defaults doesn't conflict with that per-user feature,
   it just supplies the default before any personal override applies)
   are enough to recolor the primary submit button (bg-surface-submit)
   and shadcn-driven focus rings (focus-visible:ring-ring) app-wide.

   The auth-page email/password inputs' focus border and floating label,
   confirmed live via computed-style inspection, are NOT var-driven —
   they're LibreChat's own hardcoded Tailwind utility classes
   (focus:border-green-500, peer-focus:text-green-600/500) baked in at
   build time, so those need direct selector overrides below instead.

   !important on the custom properties themselves (not just the rules
   below that consume them) is required here, confirmed live 2026-08-14:
   this file's <link> loads before index.*.css in <head> (Dockerfile's
   patch inserts it right after <head>, the bundle's own <link> comes
   later in the built index.html), and index.*.css's own .dark{...}
   block -- equal specificity, later in source order -- would otherwise
   win the cascade and silently override these on ties. */
:root,
.dark {
  --brand-purple: #5b9bff !important;
  --surface-submit: #2563eb !important;
  --surface-submit-hover: #1d4ed8 !important;
  --ring: 217 91% 65% !important;
}

.focus\:border-green-500:focus,
.focus-visible\:border-green-500:focus-visible {
  border-color: #5b9bff !important;
}
.ring-green-500 {
  --tw-ring-color: #5b9bff !important;
}
.peer:focus ~ .peer-focus\:text-green-600 {
  color: #5b9bff !important;
}
.dark .peer:focus ~ .dark\:peer-focus\:text-green-500 {
  color: #5b9bff !important;
}

/* Denizen Blu: lets custom.js's animated particle background (the same
   .net-fx effect as denizenblu.com's hero and bluroute/models_ui's
   #netFx) show through on the auth screens (login/register/forgot-
   password/reset-password/verify) -- confirmed live 2026-08-14, the
   opaque bg-white/dark:bg-gray-900 pair is LibreChat's own auth-layout
   wrapper (React component, not something we can edit directly the way
   models.html is a plain file we own). This specific class combination
   is only ever used by that one wrapper, so scoping to it doesn't touch
   any other bg-white/dark:bg-gray-900 usage elsewhere in the app.

   z-index:1 is required alongside the wrapper's own already-present
   `relative` class -- custom.js's canvas is `position:fixed;z-index:0`
   appended directly to <body>, and confirmed live that without an
   explicit z-index here the canvas painted OVER the login form instead
   of behind it (a position:relative element with z-index:auto doesn't
   automatically outrank a later fixed z-index:0 sibling in the same
   stacking context -- same reasoning models.html's own `header, main {
   position: relative; z-index: 1; }` rule exists for). */
.relative.flex.min-h-screen.flex-col.bg-white.dark\:bg-gray-900 {
  background-color: transparent !important;
  z-index: 1;
}

/* Denizen Blu: the actual visible auth-form card (.w-authPageWidth --
   confirmed live 2026-08-14 via DOM-chain inspection from the "Welcome
   back" heading up) is a SEPARATE, nested opaque bg-gray-900 element
   from the full-page wrapper above. First attempt matched it flat to the
   canvas's own #06080f, but that still read as "floating" -- an opaque
   rectangle blocks the particles/lines behind it regardless of color
   match, so its edge stays visible as a dead patch in the animation no
   matter how close the fill color is.

   bluroute/models_ui/static/login.html's own reference card (the design
   this is meant to match) doesn't fight that at all -- it's a
   deliberately *elevated* panel: a two-tone gradient (--panel #0e1424 ->
   --bg-2 #0a0e1a), a faint border (--line-strong,
   rgba(120,150,220,0.28)), and a soft drop shadow (0 40px 90px
   rgba(0,0,0,0.45)), not an attempt to disappear into the background.
   Ported those exact values here instead. */
.w-authPageWidth.bg-white.dark\:bg-gray-900 {
  background: linear-gradient(180deg, #0e1424, #0a0e1a) !important;
  border: 1px solid rgba(120, 150, 220, 0.28) !important;
  box-shadow: 0 40px 90px rgba(0, 0, 0, 0.45) !important;
}

/* Denizen Blu: the auth-page heading ("Welcome back" / "Create your
   account" / etc.) is text-black, dark:text-white -- unlike the card
   background above, this class's color depends on LibreChat's LIVE theme
   state (whether .dark is actually on an ancestor at render time), not a
   literal class-attribute match. The card background override above is
   unconditional (forces dark regardless of live theme), but this heading
   isn't, so a session whose resolved theme is light renders text-black
   against our always-dark card -- invisible. Confirmed live 2026-08-14
   via screenshot on a light-theme session: black heading text on the
   forced-dark #0e1424->#0a0e1a card. Since the card is always dark now,
   the heading needs to always be light too, same --ink value login.html
   uses. */
.mb-4.text-center.text-3xl.font-semibold.text-black.dark\:text-white {
  color: #eaf0ff !important;
}

/* Denizen Blu: the two static glow/grid layers custom.js creates
   (.blu-auth-bg-fx/.blu-auth-grid-fx) alongside its animated canvas --
   values ported verbatim from bluroute/models_ui/static/models.html's
   own .bg-fx/.grid-fx (login.html's copy is identical). .bg-fx is the
   soft colored "bright spot" glow in the corner that models.html/
   login.html both have and the canvas alone doesn't reproduce -- the
   canvas only draws particles/lines, no ambient color wash. */
.blu-auth-bg-fx {
  position: fixed;
  inset: 0;
  z-index: 0;
  pointer-events: none;
  background:
    radial-gradient(60vw 60vw at 78% -8%, rgba(37, 99, 235, 0.2), transparent 60%),
    radial-gradient(48vw 48vw at 8% 12%, rgba(34, 211, 238, 0.1), transparent 60%),
    radial-gradient(50vw 50vw at 50% 108%, rgba(139, 123, 255, 0.12), transparent 60%);
}
.blu-auth-grid-fx {
  position: fixed;
  inset: 0;
  z-index: 0;
  pointer-events: none;
  opacity: 0.35;
  background-image:
    linear-gradient(to right, rgba(120, 150, 220, 0.05) 1px, transparent 1px),
    linear-gradient(to bottom, rgba(120, 150, 220, 0.05) 1px, transparent 1px);
  background-size: 54px 54px;
  -webkit-mask-image: radial-gradient(70% 55% at 50% 0%, #000 40%, transparent 100%);
  mask-image: radial-gradient(70% 55% at 50% 0%, #000 40%, transparent 100%);
}