/* ===================================================================
TableTap brand theme - single source of truth for the brand color.
Matches the pattern already used in the LuxeTemplate module's
main.css (CSS custom properties, referenced everywhere via var()),
applied here to the Argon-based auth/dashboard side of the app.

To change the brand color app-wide in the future: edit the two
--brand-primary values below. Nothing else needs to change.

Updated from green (#2dce89) to the orange-red gradient brand accent
(#e54750) per explicit request, applied globally this time - including
the restaurant-owner/admin dashboard side. .btn-primary specifically
also gets a two-tone gradient background (see below) rather than a
flat color, to match the "Order Summary" total block treatment used
elsewhere on the customer-facing side. This change cascades everywhere
var(--brand-primary) is used: buttons, pagination, etc. Two hardcoded
(non-variable) instances of the old green still needed manual updates
too - see app.blade.php.
=================================================================== */

:root {
  --brand-primary: #e54750;
  --brand-primary-hover: #d43d46;
  --brand-dark: #2d2a26;
  --brand-cream: #fff7ed;
}

/* Profile picture (and any other Argon .avatar) rendered as an oval,
   not a circle - the parent .avatar container is a correct square,
   but the inner <img> used width:100%/height:auto, so it scaled based
   on the uploaded image's own aspect ratio rather than evenly filling
   the square. object-fit:cover with matched width/height fixes it
   regardless of the source image's proportions. */
.avatar img {
  width: 100% !important;
  height: 100% !important;
  object-fit: cover !important;
}

/* .btn-primary is the semantically correct "primary brand action" class
   in Bootstrap/Argon - safe to rebrand everywhere it appears, unlike
   .btn-danger/.btn-success which carry real meaning elsewhere in the
   app (delete actions, success confirmations) and are deliberately
   left untouched here. Background uses the two-tone gradient directly
   (rather than the --brand-primary variable, which stays a flat color
   since it's also used for border-color/color elsewhere where a
   gradient value wouldn't apply) to match the "Order Summary" accent
   used on the customer-facing side. */
.btn-primary {
  background: linear-gradient(135deg, #ff8a3d, #e54750) !important;
  border-color: var(--brand-primary) !important;
}
.btn-primary:hover,
.btn-primary:focus {
  background-color: var(--brand-primary-hover) !important;
  border-color: var(--brand-primary-hover) !important;
}
/* Outline variant of the same semantically-correct primary class. */
.btn-outline-primary {
  color: var(--brand-primary) !important;
  border-color: var(--brand-primary) !important;
}
.btn-outline-primary:hover,
.btn-outline-primary:focus {
  background-color: var(--brand-primary) !important;
  border-color: var(--brand-primary) !important;
  color: #fff !important;
}

/* Secondary brand action - outline style, for buttons that are a real
   action but shouldn't compete visually with the main .btn-primary
   action on the same page (e.g. "Create new account" next to "Sign in"). */
.btn-brand-outline {
  background: transparent !important;
  border: 2px solid var(--brand-primary) !important;
  color: var(--brand-primary) !important;
}
.btn-brand-outline:hover,
.btn-brand-outline:focus {
  background: var(--brand-primary) !important;
  color: #fff !important;
}

/* The site-wide "Register" / "Login" links in the guest header use
   Argon's .btn-neutral class - safe to rebrand globally since nothing
   else in the app uses .btn-neutral for anything but these brand
   navigation links. */
.btn-neutral {
  color: var(--brand-primary) !important;
}
.btn-neutral:hover,
.btn-neutral:focus {
  background: var(--brand-primary) !important;
  color: #fff !important;
  border-color: var(--brand-primary) !important;
}

/* Secondary text links (Forgot password?, Back to login) - Argon's
   .text-light is meant for dark backgrounds and is unreadable against
   the cream backgrounds these pages now use. */
.auth-page .text-light {
  color: var(--brand-primary) !important;
  font-weight: 700 !important;
}
.auth-page .text-light:hover {
  text-decoration: underline !important;
}

/* Auth page backgrounds and logo sizing - scoped to pages carrying the
   auth-page class (added to login/register/restaurant-register below)
   rather than applied globally, since other pages (dashboard, order
   flows) have their own intentional backgrounds. */
.auth-page.bg,
.auth-page.bg-default {
  background: var(--brand-cream) !important;
}
.auth-page .navbar-brand img,
.auth-page .navbar-brand .thumbnail {
  max-width: 90px !important;
  width: 90px !important;
  height: auto !important;
}
@media (max-width: 576px) {
  .auth-page .navbar-brand img,
  .auth-page .navbar-brand .thumbnail {
    max-width: 64px !important;
    width: 64px !important;
  }
}

/* The desktop mt--6/mt--8 negative margins assume a tall header with a
   full logo. On mobile, layouts/headers/guest.blade.php swaps in a much
   shorter "empty space" placeholder instead - the same large negative
   margin then pulls the form up too far, under the fixed nav bar. Only
   applies on auth pages (login/register), scoped by viewport width. */
@media (max-width: 768px) {
  .auth-page .mt--6,
  .auth-page .mt--7,
  .auth-page .mt--8 {
    margin-top: 20px !important;
  }
}

/* ===================================================================
Dashboard brand colors - the logged-in admin/restaurant-owner area
uses Argon's default purple theme, which doesn't match the site's
orange brand used everywhere else (landing page, login, register).
=================================================================== */

/* Page background behind the cards - was pure white, which felt too
   bright/flat once "New Restaurants"/"New Subscribers" also switched
   to white cards. Tested three tones directly (neutral gray, warm
   cream, cool gray-blue); neutral gray was the pick. Sidebar stays
   white - this is now an intentional sidebar-vs-content color
   distinction (a common, deliberate dashboard pattern), not the kind
   of accidental two-shades-of-white mismatch fixed earlier. */
body, .main-content {
  background: #f1f2f6 !important;
}
/* The main dashboard header - previously a bold purple gradient, which
   felt heavy for this much screen real estate. Dropped the distinct
   header color entirely, matching the page background above rather
   than standing out as its own block. This follows the same
   no-separate-header-color approach used in most modern dashboards
   (Stripe, Linear, Notion, and MenuRite's own). */
.header.bg-gradient-primary {
  background: #f1f2f6 !important;
  border-bottom: none;
}
.header.bg-gradient-primary * {
  color: var(--brand-dark) !important;
}
/* The time-range toggle (1M/3M/6M/1Y) used a semi-transparent white
   background designed to sit on the old dark gradient - invisible
   against the new light background. */
.header .range-toggle-group {
  background: rgba(45,42,38,.06) !important;
}
/* The "Dashboard" breadcrumb link and the profile name ("Admin"/
   "Fuego", top right) both live in a separate <nav> element (not
   nested inside .header itself) that assumes a dark background
   behind it via Bootstrap's navbar-dark convention. The profile name
   specifically uses navbar-dark's default cascading text color rather
   than an explicit .text-white class, so an earlier narrower fix
   scoped to just .text-white missed it - broadened to cover all text
   in this nav. Previously scoped by sibling relationship to the
   specific header being rebranded (first with + immediate sibling,
   then ~ general sibling after that broke on a page with a <style>
   tag in between) - dropped that scoping entirely after finding a
   third page (Insights, restaurant-owner side) where .header is
   nested inside a sibling rather than being a sibling itself, which
   no sibling combinator can structurally reach. Since every page's
   header is now consistently light-themed, applying this
   unconditionally is simpler and more robust than chasing every DOM
   variation. */
.navbar-top.navbar-dark * {
  color: var(--brand-dark) !important;
}
/* The light-mode fix above forces dark text unconditionally, which
   breaks in night mode once the header background flips dark -
   dark-on-dark, invisible. Confirmed via direct testing: this needs
   its own night-mode override to restore light text there. */
body.dash-night .navbar-top.navbar-dark * {
  color: #e4e4e7 !important;
}
/* .bg-gradient-info is a different Argon header variant (cyan-to-blue)
   found via direct testing on /restaurants/{id}/edit - the earlier
   .bg-gradient-primary rebrand never touched it since it's a
   different class entirely. Same treatment for visual consistency
   across the app. */
.header.bg-gradient-info {
  background: #f1f2f6 !important;
  border-bottom: none;
}
.header.bg-gradient-info * {
  color: var(--brand-dark) !important;
}
/* Some pages (e.g. /profile) use a fixed, always-dark photo header
   (background-image, no bg-gradient-primary/bg-gradient-info class)
   instead of the light-themed gradient other pages use - confirmed
   via direct testing that its background never changes with the
   site's light/dark toggle. The unconditional light-mode rule above
   was forcing dark text onto this permanently-dark background,
   making the profile name unreadable specifically in light mode.
   Detected via :not(.bg-gradient-primary):not(.bg-gradient-info) on
   the immediately following .header (both classes are now
   light-themed, so both need excluding here), and forces light text
   there regardless of site-wide mode. */
.navbar-top.navbar-dark:has(~ .header:not(.bg-gradient-primary):not(.bg-gradient-info)) * {
  color: #fff !important;
}
/* Fixed a live-confirmed bug: the rule above's broad "*" selector was
   also catching the profile dropdown popup's own content (a white
   popup, not the dark navbar itself, even though it's a DOM descendant
   of it), forcing its text white-on-white and making it invisible.
   This restores normal dark text specifically inside that dropdown. */
.navbar-top.navbar-dark:has(~ .header:not(.bg-gradient-primary):not(.bg-gradient-info)) .dropdown-menu * {
  color: #32325d !important;
}
.navbar-top.navbar-dark:has(~ .header:not(.bg-gradient-primary):not(.bg-gradient-info)) .dropdown-menu .text-warning {
  color: #fb6340 !important;
}
/* The four top stat icons (Users, Paying Clients, Monthly Recurring
   Revenue, Annual Recurring Revenue) redesigned to match a reference
   dashboard - rounded square (not circle), pastel background with a
   darker-shade icon color, rather than a vibrant gradient circle.
   Since these are real SVG icons using currentColor (not an icon
   font), setting color here is enough - no separate icon replacement
   needed. Scoped to the admin dashboard specifically via
   body:has(.growth-card-purple) (a marker confirmed unique to that
   page) - found via direct testing that without this guard, this
   rule's specificity was silently beating the restaurant-owner
   dashboard's own icon color rules, since that page shares the exact
   same .header-body > .row > div structure and was never meant to be
   affected by this admin-only styling. */
body:has(.growth-card-purple) .header-body > .row > div:nth-child(1) .icon-shape {
  background: #ede9fe !important;
  color: #8b5cf6 !important;
  border-radius: 14px !important;
  box-shadow: none !important;
}
body:has(.growth-card-purple) .header-body > .row > div:nth-child(2) .icon-shape {
  background: #ccfbf1 !important;
  color: #0f9d58 !important;
  border-radius: 14px !important;
  box-shadow: none !important;
}
body:has(.growth-card-purple) .header-body > .row > div:nth-child(3) .icon-shape {
  background: #ede9fe !important;
  color: #7c3aed !important;
  border-radius: 14px !important;
  box-shadow: none !important;
}
body:has(.growth-card-purple) .header-body > .row > div:nth-child(4) .icon-shape {
  background: #ffedd5 !important;
  color: #ff641f !important;
  border-radius: 14px !important;
  box-shadow: none !important;
}

/* "New Restaurants" / "New Subscribers" - after the navy attempt, the
   actual feedback was that these bold gradient cards clash with the
   calmer, minimal white/pastel style used everywhere else on the
   dashboard (the two rows read as two different design languages
   stitched together). Redesigned to match the top stat cards exactly
   instead: white card, pastel icon square, dark text. Left untouched
   in night mode, where the bold gradient still works as an intentional
   accent against an otherwise all-dark page. */
.growth-card-purple,
.growth-card-teal {
  background: #ffffff !important;
  border: 1px solid #f0ede5 !important;
}
.header .growth-card-purple,
.header .growth-card-teal,
.header .growth-card-purple *,
.header .growth-card-teal * {
  color: var(--brand-dark) !important;
}
.growth-card-purple .growth-card-sub,
.growth-card-teal .growth-card-sub {
  color: #887d74 !important;
}
.growth-card-purple .growth-card-icon {
  background: #ffedd5 !important;
  color: var(--brand-primary) !important;
  border-radius: 12px !important;
}
.growth-card-teal .growth-card-icon {
  background: #ccfbf1 !important;
  color: #0f9d58 !important;
  border-radius: 12px !important;
}
/* The sparkline's line color used to be hidden here (display:none) as
   a stopgap - the module file rendering it (Modules/Pureadmindash's
   dashboard partial) was hard to track down, so the color couldn't be
   fixed at the source. Now that it's been located, the sparkline is
   properly recolored there instead (orange/green on the white
   light-mode card, white on the vibrant night-mode gradient) and is
   visible again - this hiding rule is no longer needed.
*/

/* Analytics page stat icons - replaced Argon's default Nucleo icon
   font glyphs with clean, contemporary line-style SVGs via CSS
   mask-image. Two real bugs found and fixed via direct testing
   before this version: (1) the SVGs needed explicit width/height
   attributes, not just viewBox, for mask-size:contain to render
   the full shape rather than a cropped fragment; (2) the icon
   circles here have a white background (bg-white), not colored
   like the main dashboard's icons, so a white icon was invisible
   against it - each icon now uses its card's own accent color
   instead. No Blade file edit needed - pure CSS technique. */
.analytics-stat-card .ni-single-02 {
  display: inline-block;
  width: 22px;
  height: 22px;
  background-color: #8b5cf6;
  -webkit-mask-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0naHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmcnIHdpZHRoPScyNCcgaGVpZ2h0PScyNCcgdmlld0JveD0nMCAwIDI0IDI0JyBmaWxsPSdub25lJyBzdHJva2U9JyM4YjVjZjYnIHN0cm9rZS13aWR0aD0nMicgc3Ryb2tlLWxpbmVjYXA9J3JvdW5kJyBzdHJva2UtbGluZWpvaW49J3JvdW5kJz48Y2lyY2xlIGN4PScxMicgY3k9JzgnIHI9JzQnLz48cGF0aCBkPSdNNCAyMWMwLTQgMy42LTcgOC03czggMyA4IDcnLz48L3N2Zz4=");
  mask-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0naHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmcnIHdpZHRoPScyNCcgaGVpZ2h0PScyNCcgdmlld0JveD0nMCAwIDI0IDI0JyBmaWxsPSdub25lJyBzdHJva2U9JyM4YjVjZjYnIHN0cm9rZS13aWR0aD0nMicgc3Ryb2tlLWxpbmVjYXA9J3JvdW5kJyBzdHJva2UtbGluZWpvaW49J3JvdW5kJz48Y2lyY2xlIGN4PScxMicgY3k9JzgnIHI9JzQnLz48cGF0aCBkPSdNNCAyMWMwLTQgMy42LTcgOC03czggMyA4IDcnLz48L3N2Zz4=");
  -webkit-mask-size: contain;
  mask-size: contain;
  -webkit-mask-repeat: no-repeat;
  mask-repeat: no-repeat;
  -webkit-mask-position: center;
  mask-position: center;
}
.analytics-stat-card .ni-collection {
  display: inline-block;
  width: 22px;
  height: 22px;
  background-color: #14b8a6;
  -webkit-mask-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0naHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmcnIHdpZHRoPScyNCcgaGVpZ2h0PScyNCcgdmlld0JveD0nMCAwIDI0IDI0JyBmaWxsPSdub25lJyBzdHJva2U9JyMxNGI4YTYnIHN0cm9rZS13aWR0aD0nMicgc3Ryb2tlLWxpbmVjYXA9J3JvdW5kJyBzdHJva2UtbGluZWpvaW49J3JvdW5kJz48cGF0aCBkPSdNMiAxMnMzLjUtNyAxMC03IDEwIDcgMTAgNy0zLjUgNy0xMCA3LTEwLTctMTAtN3onLz48Y2lyY2xlIGN4PScxMicgY3k9JzEyJyByPSczJy8+PC9zdmc+");
  mask-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0naHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmcnIHdpZHRoPScyNCcgaGVpZ2h0PScyNCcgdmlld0JveD0nMCAwIDI0IDI0JyBmaWxsPSdub25lJyBzdHJva2U9JyMxNGI4YTYnIHN0cm9rZS13aWR0aD0nMicgc3Ryb2tlLWxpbmVjYXA9J3JvdW5kJyBzdHJva2UtbGluZWpvaW49J3JvdW5kJz48cGF0aCBkPSdNMiAxMnMzLjUtNyAxMC03IDEwIDcgMTAgNy0zLjUgNy0xMCA3LTEwLTctMTAtN3onLz48Y2lyY2xlIGN4PScxMicgY3k9JzEyJyByPSczJy8+PC9zdmc+");
  -webkit-mask-size: contain;
  mask-size: contain;
  -webkit-mask-repeat: no-repeat;
  mask-repeat: no-repeat;
  -webkit-mask-position: center;
  mask-position: center;
}
.analytics-stat-card .ni-chart-bar-32 {
  display: inline-block;
  width: 22px;
  height: 22px;
  background-color: #3b82f6;
  -webkit-mask-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0naHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmcnIHdpZHRoPScyNCcgaGVpZ2h0PScyNCcgdmlld0JveD0nMCAwIDI0IDI0JyBmaWxsPSdub25lJyBzdHJva2U9JyMzYjgyZjYnIHN0cm9rZS13aWR0aD0nMicgc3Ryb2tlLWxpbmVjYXA9J3JvdW5kJyBzdHJva2UtbGluZWpvaW49J3JvdW5kJz48cGF0aCBkPSdNNCAyMFYxME0xMCAyMFY0TTE2IDIwdi03TTIyIDIwSDInLz48L3N2Zz4=");
  mask-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0naHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmcnIHdpZHRoPScyNCcgaGVpZ2h0PScyNCcgdmlld0JveD0nMCAwIDI0IDI0JyBmaWxsPSdub25lJyBzdHJva2U9JyMzYjgyZjYnIHN0cm9rZS13aWR0aD0nMicgc3Ryb2tlLWxpbmVjYXA9J3JvdW5kJyBzdHJva2UtbGluZWpvaW49J3JvdW5kJz48cGF0aCBkPSdNNCAyMFYxME0xMCAyMFY0TTE2IDIwdi03TTIyIDIwSDInLz48L3N2Zz4=");
  -webkit-mask-size: contain;
  mask-size: contain;
  -webkit-mask-repeat: no-repeat;
  mask-repeat: no-repeat;
  -webkit-mask-position: center;
  mask-position: center;
}
.analytics-stat-card .ni-watch-time {
  display: inline-block;
  width: 22px;
  height: 22px;
  background-color: #f97316;
  -webkit-mask-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0naHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmcnIHdpZHRoPScyNCcgaGVpZ2h0PScyNCcgdmlld0JveD0nMCAwIDI0IDI0JyBmaWxsPSdub25lJyBzdHJva2U9JyNmOTczMTYnIHN0cm9rZS13aWR0aD0nMicgc3Ryb2tlLWxpbmVjYXA9J3JvdW5kJyBzdHJva2UtbGluZWpvaW49J3JvdW5kJz48Y2lyY2xlIGN4PScxMicgY3k9JzEzJyByPSc4Jy8+PHBhdGggZD0nTTEyIDl2NGwzIDJNOSAyaDYnLz48L3N2Zz4=");
  mask-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0naHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmcnIHdpZHRoPScyNCcgaGVpZ2h0PScyNCcgdmlld0JveD0nMCAwIDI0IDI0JyBmaWxsPSdub25lJyBzdHJva2U9JyNmOTczMTYnIHN0cm9rZS13aWR0aD0nMicgc3Ryb2tlLWxpbmVjYXA9J3JvdW5kJyBzdHJva2UtbGluZWpvaW49J3JvdW5kJz48Y2lyY2xlIGN4PScxMicgY3k9JzEzJyByPSc4Jy8+PHBhdGggZD0nTTEyIDl2NGwzIDJNOSAyaDYnLz48L3N2Zz4=");
  -webkit-mask-size: contain;
  mask-size: contain;
  -webkit-mask-repeat: no-repeat;
  mask-repeat: no-repeat;
  -webkit-mask-position: center;
  mask-position: center;
}

/* ===================================================================
Night mode form inputs - found on the Orders page while extending
brand/design work beyond the main dashboard. Text inputs and Select2
dropdowns (used across many admin pages, not just Orders) stayed
light-mode styled even after toggling night mode, since night mode's
CSS lives in layouts/app.blade.php and hadn't covered these generic
form elements yet. Adding here since these selectors apply globally
regardless of which stylesheet defines them - body.dash-night is set
by the shared toggle script either way.
=================================================================== */
body.dash-night .form-control,
body.dash-night select.form-control,
body.dash-night .form-control-alternative {
  background: #18181b !important;
  color: #e4e4e7 !important;
  border-color: #3a3a3f !important;
}
body.dash-night .form-control::placeholder {
  color: #71717a !important;
}
body.dash-night label {
  color: #e4e4e7 !important;
}
body.dash-night .select2-selection {
  background: #18181b !important;
  border-color: #3a3a3f !important;
  color: #e4e4e7 !important;
}
body.dash-night .select2-selection__rendered {
  color: #e4e4e7 !important;
}
body.dash-night .select2-selection__arrow b {
  border-color: #71717a transparent transparent transparent !important;
}
/* The calendar icon on date-picker inputs (and any other
   .input-group-text icon) had a stark white background in night
   mode, unrelated to the text-input fix above since it's a separate
   prepended element - found on the Orders page filter fields. Soft
   green tint (matching the current brand color) rather than generic
   gray, for a more deliberate, polished look. */
body.dash-night .input-group-text {
  background: #24242a !important;
  color: #6ee7b7 !important;
  border-color: #3a3a3f !important;
}
/* Table row-divider lines were still using Bootstrap's default light
   gray cell border, standing out sharply against the dark table -
   found on the Orders page, but this is a generic table style so it
   likely affects any other page with a data table too. */
body.dash-night .table td,
body.dash-night .table th {
  border-color: #27272a !important;
}
/* The restaurants_apps settings page's vertical nav menu (Coupons, Tax
   config, Delivery Areas, etc.) had a white background with
   light-gray text on non-active items - nearly invisible. An earlier
   attempt at this fix used a selector (.nav-wrapper) that didn't
   match the actual DOM (confirmed via direct testing: the real parent
   class is nav-pills), so it was silently never applying - replaced
   with the confirmed-correct selector. The active item's own
   highlight color is also normalized to the current brand color
   rather than the leftover blue default. */
body.dash-night .nav-pills .nav-link {
  background: #18181b !important;
  color: #e4e4e7 !important;
}
body.dash-night .nav-pills .nav-link.active {
  background: var(--brand-primary) !important;
  color: #fff !important;
}
/* Bootstrap dropdown menus (e.g. the "Edit"/"Login as"/"Clone it"/etc.
   options menu on the Restaurants list page) had a white background
   with barely-visible light-gray text. Generic Bootstrap component,
   likely affects any dropdown across the admin area, not just this
   one page. */
body.dash-night .dropdown-menu {
  background: #18181b !important;
  border-color: #27272a !important;
}
body.dash-night .dropdown-item {
  color: #e4e4e7 !important;
}
body.dash-night .dropdown-item:hover,
body.dash-night .dropdown-item:focus {
  background: #24242a !important;
  color: #fff !important;
}
/* Pagination (Orders page and likely others using standard Bootstrap
   pagination) had white .page-link buttons regardless of night mode. */
body.dash-night .page-link {
  background: #18181b !important;
  color: #e4e4e7 !important;
  border-color: #3a3a3f !important;
}
body.dash-night .pagination .page-item.active .page-link {
  background-color: var(--brand-primary) !important;
  border-color: var(--brand-primary) !important;
  color: #fff !important;
}
body.dash-night .page-item.disabled .page-link {
  color: #52525b !important;
  background: #0e0e10 !important;
}
/* Found on the Clients page - a card's own .card-footer (used for
   pagination/actions at the bottom of many list pages) stayed white
   even though the card itself was correctly dark, and the site-wide
   <footer> at the very bottom of the page was untouched entirely. */
body.dash-night .card-footer {
  background: #18181b !important;
  border-color: #27272a !important;
}
body.dash-night footer.footer {
  background: #0e0e10 !important;
  color: #a1a1aa !important;
}
/* The Insights page uses its own custom .insights-card class rather
   than the standard .card, so it was entirely untouched by night mode
   until now - confirmed via direct inspection. */
body.dash-night .insights-card {
  background: #18181b !important;
  border-color: #27272a !important;
  color: #e4e4e7 !important;
}
body.dash-night .insights-card * {
  color: #e4e4e7 !important;
}
/* The restaurant-owner dashboard's own custom .dashboard-card class
   (Expenses "By category"/"By vendor" cards, found via direct
   testing) was stark white while the surrounding .card elements were
   already correctly dark - different custom class, not covered by
   the standard .card fix elsewhere. */
body.dash-night .dashboard-card {
  background: #18181b !important;
  border-color: #27272a !important;
}
body.dash-night .dashboard-card * {
  color: #e4e4e7 !important;
}
/* Same pattern as the .insights-page wrapper bug found earlier - this
   dashboard has its own page-wrapper class with a light background,
   visible as a thin light strip between the banner and the cards
   below it, even though everything else on the page was already
   correctly dark. */
body.dash-night .dashboard-page-bg {
  background: #0e0e10 !important;
}
/* The custom date range picker's inputs/button are deliberately white
   regardless of dashboard mode, so their text needs to stay dark -
   but the broader "make all header text light for readability" rule
   above was overriding that, leaving the text nearly invisible
   against the white background. Uses the picker's own id for
   guaranteed specificity over that broader rule. */
body.dash-night #dashboardCustomRange input[type="date"] {
  color: #32325d !important;
}
body.dash-night #dashboardCustomRange button {
  color: #5e72e4 !important;
}
/* This page has its own .insights-page wrapper div with a light
   background, sitting between the (correctly dark) .main-content and
   the (correctly dark) individual cards - creating visible light gaps
   between card rows that neither of those fixes touched. */
body.dash-night .insights-page {
  background: #0e0e10 !important;
}
/* Plan Distribution bars all shared one muted tan color regardless of
   plan - given distinct colors instead, matched by position since all
   bars share the same .insights-bar-fill class. */
.insights-item-row:nth-of-type(1) .insights-bar-fill { background: #3b82f6 !important; }
.insights-item-row:nth-of-type(2) .insights-bar-fill { background: #8b5cf6 !important; }
.insights-item-row:nth-of-type(3) .insights-bar-fill { background: #0f9d58 !important; }
.insights-item-row:nth-of-type(4) .insights-bar-fill { background: #ff641f !important; }
/* The GMV Trend chart's line color and gridline colors (including
   proper night-mode-aware gridlines) are now fixed at the source in
   resources/views/insights/admin.blade.php's Chart.js config, once
   that file was obtained - a cleaner fix than the CSS filter
   workaround used here previously, which is no longer needed. */

/* ===================================================================
Terms and Privacy pages (and any other CMS "page" sharing the same
.container-pages/header.masthead structure) - the header used the
same generic food-photo placeholder (default/cover.jpg) already fixed
elsewhere on the guest-facing side, and the legal text body ran the
full width of the page edge-to-edge with no reading-width constraint,
making long sections hard to read. Confirmed live before applying.
=================================================================== */
header.masthead {
  background: linear-gradient(135deg, #ff8a3d, #e54750) !important;
}
.container-pages {
  max-width: 760px !important;
  padding: 2.5rem 1.5rem 4rem !important;
}
.container-pages h1 {
  font-size: 1.9rem !important;
  margin-bottom: 0.5rem !important;
}
.container-pages h2 {
  font-size: 1.5rem !important;
  color: var(--brand-primary) !important;
  margin-top: 2.5rem !important;
  margin-bottom: 1rem !important;
  padding-bottom: 0.5rem !important;
  border-bottom: 2px solid #ffe3d9 !important;
}
.container-pages p {
  line-height: 1.7 !important;
  color: #444 !important;
  margin-bottom: 1.1rem !important;
}