/* Design tokens + dark-mode overrides for AW-502 Phase 1 (CoilZone legacy
   Pongo2/Twig stack, prefers-color-scheme only). Linked conditionally from
   views/coilzone/layouts/{coilzone-master,coilzone-logged-out}.twig, gated
   behind DarkModeEnabled (system/request/coilzone-req.go), which reads the
   same Config.Theme.Dark_Mode_Enabled flag Phase 0 introduced.

   Load order matters: this file loads AFTER assets/css/shared/_min/pcm.min.css
   (linked in the shared parent layout, views/shared/layouts/precoat-master.twig)
   and AFTER coilzone_v2.css (linked earlier in the same webAppCss block), so
   same-specificity re-declarations here win the cascade -- this is how the
   component overrides below reach into shared/vendor CSS (055_pcm-table.css,
   050_pcm-form.css, 035_pcm-menu-nav.css, all inside the fragile, manual,
   Windows-only minify pipeline) WITHOUT editing those files in place. */

:root {
    /* Light-mode defaults match CoilZone's current actual look (Bootstrap
       3.3.5's own conventions) -- these are NOT copied from Phase 0's
       Bootstrap-5-derived light values, only the dark values below are. */
    --pcm-bg: #fff;
    --pcm-surface: #fff;
    --pcm-surface-muted: #e9ecef; /* consolidates today's inconsistent #e0e0e0/#F6F6F6/#f4f4f4 cluster */
    --pcm-text: #333; /* Bootstrap 3.3.5's own default body color */
    --pcm-text-muted: #555;
    --pcm-border: #ccc; /* Bootstrap 3.3.5's own default form-control border */
    /* Dedicated token for the .sticky-row divider pattern (paint-vendor/color-trending.css) --
       #eaeaea is a 30/255-per-channel delta from --pcm-border's own #ccc, too far to safely
       reuse via fallback, so it gets its own token rather than repeating the mismatched-
       fallback mistake that shipped on Portal's identical pattern and had to be reverted. */
    --pcm-divider: #eaeaea;
    --pcm-focus-shadow: rgba(102, 175, 233, .6); /* Bootstrap 3.3.5's own native focus glow, verbatim */
    --pcm-link: #0000FF; /* CoilZone's current bare `a, a:visited` color */
    --pcm-text-danger: #990000; /* matches the hardcoded inline-style red used for page warning notes (e.g. inquiries) */
    --pcm-text-brand: #00457C; /* CoilZone's brand blue (page-title, phone-directory location labels) -- distinct from --pcm-link's #0000FF bare-anchor blue, must not be conflated with it */
    --pcm-login-link: #003168; /* login_v1.css's own link color -- a THIRD distinct brand blue, do not reuse --pcm-link/--pcm-text-brand here or their different canonical values would silently change these links even in light mode once the flag is on */
    --pcm-brand-blue: #1E639A; /* div.pcm-blue's ag-Grid header skin (065_ag-theme-balham.css) -- a FOURTH distinct blue, genuinely different from --pcm-link/--pcm-text-brand/--pcm-login-link, same Hard Lesson (never conflate visually-similar brand blues). Same value as Portal's own --pcm-brand-blue -- confirmed by direct comparison of the shared vendor CSS, not assumed from the name. */
}

@media (prefers-color-scheme: dark) {
    :root {
        color-scheme: dark;
        /* Copied verbatim from Phase 0's theme.css (assets/tmpl/css/shared/theme.css)
           for product-wide dark-mode visual consistency across stacks. */
        --pcm-bg: #212529;
        --pcm-surface: #2b3035;
        --pcm-surface-muted: #343a40;
        --pcm-text: #dee2e6;
        --pcm-text-muted: rgba(222, 226, 230, .75);
        --pcm-border: #495057;
        /* Converges with --pcm-border's dark value once it's no longer literally #eaeaea,
           same reasoning as Portal's identical token. */
        --pcm-divider: #495057;
        --pcm-focus-shadow: rgba(102, 175, 233, .4);
        --pcm-link: #6ea8fe;
        /* Reused verbatim from Bootstrap 5.3's own dark --bs-danger-text-emphasis
           (assets/tmpl/css/shared/theme.css) -- same cross-stack-consistency
           call as .alert-warning below; plain #990000 on a dark page is a
           near-unreadable dark-red-on-dark-gray combination. */
        --pcm-text-danger: #ea868f;
        /* Same dark blue as --pcm-link/Bootstrap 5.3's own dark-mode
           --bs-primary-text-emphasis -- #00457C reads as near-navy-on-navy
           against the dark page background otherwise. */
        --pcm-text-brand: #6ea8fe;
        /* Same converged dark blue as --pcm-link/--pcm-text-brand -- #003168 is
           near-illegible against the dark login card background. */
        --pcm-login-link: #6ea8fe;
        /* Same converged dark blue as the other three brand-blue tokens above --
           Portal's own --pcm-brand-blue dark value, reused verbatim since it's
           driven by the same shared vendor ag-Grid CSS. */
        --pcm-brand-blue: #6ea8fe;
        /* Disabled input/select background -- see input:disabled's own
           comment below for why this can't reuse --pcm-surface-muted. Same
           value used identically across all four rendering stacks in this
           rollout. */
        --pcm-disabled-bg: #161a1e;
    }

    /* Page-level chrome. Bootstrap 3.3.5 has no reactive body background/text
       (unlike Bootstrap 5.3 in Phase 0, whose own CSS already expresses body
       bg/color via --bs-* custom properties we could just override) -- its
       body styling is plain hardcoded CSS, so without this rule nothing
       above the component level (headings, labels, page background) ever
       goes dark, only the specific selectors overridden below. */
    body {
        background-color: var(--pcm-bg);
        color: var(--pcm-text);
    }

    /* select#change-developer (045_pcm-navbar.css, the dev-slot picker in the
       top navbar) hardcodes color:#000000 with no background-color of its
       own. Because color-scheme:dark is set above, the browser renders this
       native <select>'s closed-state chrome with its own dark background
       automatically -- but the hardcoded black text still wins (author
       styles always beat the browser's automatic color-scheme styling),
       leaving black-on-near-black. High specificity (ID selector) needed to
       match/beat the vendor rule. */
    select#change-developer {
        color: var(--pcm-text);
    }

    /* table.pcm-table (assets/css/shared/_full/055_pcm-table.css) -- CoilZone's
       actual grid/table component (59 CoilZone + 74 Portal files). Header
       (#1E639A blue), row-header grays/orange, .blue/.yellow/.green highlight
       rows, .pcm-table-color-{1,2,3}, and the tablesorter sort-arrow GIFs are
       deliberately left alone -- self-contained brand/signal colors or small
       sprite images, same judgment call as Phase 0's ag-grid header. */
    table.pcm-table { border-color: var(--pcm-border); }
    table.pcm-table td { border-color: var(--pcm-border); }
    /* --pcm-surface vs --pcm-surface-muted (originally used for both stripes)
       are only ~10-12 RGB units apart -- a fine gap for a subtle "elevated
       panel" distinction elsewhere in this file, but the human eye is
       markedly less sensitive to small luminance steps at low brightness, so
       the zebra banding would read as flat/removed once the whole page went
       dark even if the rest of this rule were correct. --pcm-bg vs
       --pcm-surface-muted are ~19-23 units apart -- both already-existing
       tokens, no new value invented -- reusing them here roughly matches the
       light-mode stripe's own #fff/#ececec gap (~19 units) in relative size.

       Deliberately :nth-child ONLY -- no .odd/.even class selectors. Two
       different parts of this codebase assign those class names with
       OPPOSITE meaning relative to visual row position:
       035_pcm-table-filter.js's recolorRows() uses jQuery's 0-indexed
       :odd/:even (row 1 gets class="even"), while e.g.
       apps/coilzone/queue/prodOrdProductionQHtml.go uses a plain `i%2==0 ->
       "odd"` Go loop (row 1, i=0, gets class="odd") -- the same class name
       means the opposite physical row in each system. Any single rule that
       pairs a class selector with an :nth-child selector will therefore be
       correct for one of these mechanisms and wrong for the other -- both
       were tried (first "same label", then swapped to compensate for
       recolorRows) and each one flattened a DIFFERENT table to a single
       solid color, confirmed via color-picker on In Stock - Bare and
       Production Q respectively. :nth-child alone sidesteps the conflict
       entirely: it's purely structural (ignores class names altogether) and
       still beats the vendor's own competing .odd/.even rules in
       055_pcm-table.css regardless, since this file loads later. */
    table.pcm-table tbody tr:nth-child(odd) { background-color: var(--pcm-bg); }
    table.pcm-table tbody tr:nth-child(even) { background-color: var(--pcm-surface-muted); }

    /* .flt-s (035_pcm-table-filter.js) is a separate, standalone class used
       for the plain free-text filter inputs (e.g. Process Weight/Hold
       Weight/RTS Weight's "*ALL" fields) -- generated without the base .flt
       class alongside it, so it needs its own rule; the numeric min/max
       range filters (Gauge, Width) are actually <select> elements carrying
       flt-min-max, already covered below. */
    .flt, .flt-s, select.flt, select.flt-min-max, select.flt-multi {
        background-color: var(--pcm-surface);
        border-color: var(--pcm-border);
        color: var(--pcm-text);
    }

    .loader {
        background: var(--pcm-surface-muted);
        border-color: var(--pcm-border);
    }

    /* ag-theme-balham (assets/css/shared/_full/065_ag-theme-balham.css /
       060_ag-grid.css) -- the SAME shared vendor CSS Portal's theme-dark.css
       already tokenizes in full. CoilZone only has 3 ag-Grid pages
       (views/coilzone/paint-vendor/color-trending/*.twig) vs. Portal's 56+,
       which is why this got skipped in Phase 1 -- confirmed zero ag-Grid
       rules existed here before this block, live QA on
       /vendor/trending/color found the grid still fully light. Ported
       verbatim from Portal's already-verified equivalent (same vendor file,
       same --pcm-* token names, same div.pcm-blue header skin) rather than
       re-derived from scratch -- see that file's own history for the
       investigation behind each selector/quirk below.

       Every rule carries !important for the same reason Portal's does:
       ag-Grid Enterprise's own JS bundle injects a wholesale re-copy of this
       entire theme as an inline <style> tag at runtime, landing in the DOM
       after this stylesheet's <link> -- at matching specificity, later
       document order wins regardless of !important's absence, so only
       !important reliably reaches the actual rendered grid. */
    div.pcm-blue .ag-theme-balham .ag-header {
        background-color: var(--pcm-brand-blue, #1E639A) !important;
    }

    div.pcm-blue div.ag-header,
    div.pcm-blue div.ag-header-cell {
        color: #313131 !important;
        background-color: var(--pcm-brand-blue, #1E639A) !important;
    }

    div.pcm-blue div.ag-header-cell.ag-header-cell-moving {
        color: #313131 !important;
        background-color: var(--pcm-brand-blue, #1E639A) !important;
    }

    div.pcm-blue .ag-header-row .ag-icon {
        color: #313131 !important;
    }

    div.pcm-blue .ag-theme-balham .ag-input-wrapper input:not([type]):disabled,
    .ag-theme-balham .ag-input-wrapper input[type="text"]:disabled,
    .ag-theme-balham .ag-input-wrapper input[type="number"]:disabled,
    .ag-theme-balham .ag-input-wrapper input[type="tel"]:disabled,
    .ag-theme-balham .ag-input-wrapper input[type="date"]:disabled,
    .ag-theme-balham .ag-input-wrapper input[type="datetime-local"]:disabled {
        background-color: var(--pcm-surface-muted);
    }

    div.pcm-blue .ag-floating-filter-input,
    div.pcm-blue .ag-filter-filter {
        color: #313131 !important;
        background-color: var(--pcm-brand-blue, #1E639A) !important;
    }

    /* .ag-floating-filter-input (above) is a wrapper div with no color of its
       own -- the actual typed-into <input> inside it never gets a
       background/color from any source and would otherwise render as plain
       browser-native white/black regardless of theme. */
    div.pcm-blue .ag-theme-balham .ag-input-wrapper input:not([type]),
    div.pcm-blue .ag-theme-balham .ag-input-wrapper input[type="text"],
    div.pcm-blue .ag-theme-balham .ag-input-wrapper input[type="number"],
    div.pcm-blue .ag-theme-balham .ag-input-wrapper input[type="tel"],
    div.pcm-blue .ag-theme-balham .ag-input-wrapper input[type="date"],
    div.pcm-blue .ag-theme-balham .ag-input-wrapper input[type="datetime-local"] {
        background-color: var(--pcm-brand-blue, #1E639A) !important;
        color: #313131 !important;
    }

    div.pcm-blue div.ag-status-bar {
        background-color: var(--pcm-surface-muted) !important;
        color: var(--pcm-text-muted) !important;
    }

    /* Base ag-theme-balham theming -- the actual grid body/chrome,
       independent of the div.pcm-blue header skin above (that skin only
       ever touches header-related selectors, never rows/cells/menus/etc).
       Every selector below is copied verbatim from the vendor file (2+
       classes deep throughout -- ag-theme-balham never uses bare
       single-class rules). */
    .ag-theme-balham {
        background-color: var(--pcm-surface) !important;
        color: var(--pcm-text) !important;
    }

    .ag-theme-balham .ag-root {
        border-color: var(--pcm-border) !important;
    }

    .ag-theme-balham .ag-root-wrapper {
        background-color: var(--pcm-surface) !important;
    }

    /* Base header (unskinned) -- div.pcm-blue's own header rule above
       already covers the actual color-trending pages, this is a fallback
       for any grid that ever renders without that wrapper class. */
    .ag-theme-balham .ag-header {
        background-color: var(--pcm-surface-muted) !important;
        color: var(--pcm-text-muted) !important;
        border-bottom-color: var(--pcm-border) !important;
    }

    .ag-theme-balham .ag-header-cell,
    .ag-theme-balham .ag-header-group-cell {
        border-color: var(--pcm-border) !important;
    }

    .ag-theme-balham .ag-header-cell.ag-header-cell-moving,
    .ag-theme-balham .ag-header-group-cell.ag-header-cell-moving {
        background-color: var(--pcm-surface) !important;
    }

    .ag-theme-balham .ag-row,
    .ag-theme-balham .ag-row:not(.ag-row-first),
    .ag-theme-balham .ag-row.ag-row-last {
        color: var(--pcm-text) !important;
        border-color: var(--pcm-border) !important;
    }

    /* Zebra striping -- same --pcm-bg/--pcm-surface-muted pairing convention
       table.pcm-table already established above. */
    .ag-theme-balham .ag-row-odd {
        background-color: var(--pcm-bg) !important;
    }

    .ag-theme-balham .ag-row-even {
        background-color: var(--pcm-surface-muted) !important;
    }

    .ag-theme-balham .ag-row-hover {
        background-color: var(--pcm-surface) !important;
    }

    /* .ag-row-selected and the cell-focus ring are left alone --
       self-contained accent colors that read as a clear highlight against a
       now-dark grid regardless of theme, same judgment call as table.pcm-table's
       own self-contained signal colors. */

    .ag-theme-balham .ag-icon-checkbox-checked,
    .ag-theme-balham .ag-icon-checkbox-indeterminate,
    .ag-theme-balham .ag-icon-checkbox-unchecked {
        background-color: var(--pcm-surface) !important;
    }

    .ag-theme-balham .ag-icon {
        color: var(--pcm-text-muted) !important;
    }

    /* Filter/context/column menu popup, plus the cell editor box shown while
       inline-editing a cell value. All four selectors must be listed
       together to match both the vendor file's and the injected copy's
       different groupings of these rules. */
    .ag-theme-balham .ag-tab-body,
    .ag-theme-balham .ag-popup-editor,
    .ag-theme-balham .ag-cell-inline-editing,
    .ag-theme-balham .ag-menu {
        background: var(--pcm-surface) !important;
        color: var(--pcm-text) !important;
        border-color: var(--pcm-border) !important;
    }

    .ag-theme-balham .ag-menu .ag-menu-option-active {
        background-color: var(--pcm-surface-muted) !important;
    }

    /* Filter operator picker ("Equals/Not equal/.../In range" dropdown on
       numeric column filters) -- only exists in the injected copy, not the
       vendor file itself. */
    .ag-theme-balham .ag-picker-field-wrapper {
        background-color: var(--pcm-surface) !important;
        border-color: var(--pcm-border) !important;
    }

    .ag-theme-balham .ag-picker-field-button {
        background-color: var(--pcm-surface) !important;
        color: var(--pcm-text) !important;
    }

    .ag-theme-balham .ag-select-list {
        background-color: var(--pcm-surface) !important;
    }

    .ag-theme-balham .ag-list-item {
        color: var(--pcm-text) !important;
    }

    .ag-theme-balham .ag-list-item.ag-active-item {
        background-color: var(--pcm-surface-muted) !important;
    }

    /* Column menu tab strip -- both naming variants listed since the vendor
       file uses singular "ag-tab-header" while the injected copy uses
       plural "ag-tabs-header". */
    .ag-theme-balham .ag-tab-header,
    .ag-theme-balham .ag-tabs-header {
        background: var(--pcm-surface-muted) !important;
        border-color: var(--pcm-border) !important;
    }

    .ag-theme-balham .ag-tab-header .ag-tab.ag-tab-selected,
    .ag-theme-balham .ag-tab-selected {
        background-color: var(--pcm-surface) !important;
    }

    .ag-theme-balham .ag-filter .ag-filter-header-container:nth-child(2) {
        border-bottom-color: var(--pcm-border) !important;
    }

    .ag-floating-filter-input:-moz-read-only,
    .ag-floating-filter-input:read-only {
        background-color: var(--pcm-surface-muted) !important;
    }

    .loading-filter {
        background-color: var(--pcm-surface-muted) !important;
    }

    .ag-theme-balham .ag-overlay-loading-wrapper {
        background-color: rgba(0, 0, 0, 0.5) !important;
    }

    .ag-theme-balham .ag-overlay-loading-center {
        background-color: var(--pcm-surface) !important;
        border-color: var(--pcm-border) !important;
        color: var(--pcm-text) !important;
    }

    .ag-theme-balham .ag-paging-panel {
        border-top-color: var(--pcm-border) !important;
        color: var(--pcm-text-muted) !important;
    }

    .ag-theme-balham .ag-status-bar {
        background: var(--pcm-surface) !important;
        border-color: var(--pcm-border) !important;
        color: var(--pcm-text-muted) !important;
    }

    .ag-theme-balham .ag-name-value-value {
        color: var(--pcm-text) !important;
    }

    .ag-theme-balham .ag-side-bar {
        background-color: var(--pcm-surface-muted) !important;
        border-color: var(--pcm-border) !important;
    }

    .ag-theme-balham .ag-tool-panel-wrapper {
        background-color: var(--pcm-surface-muted) !important;
    }

    .ag-theme-balham .ag-side-bar .ag-side-buttons {
        background: var(--pcm-surface) !important;
    }

    .ag-theme-balham .ag-side-bar .ag-side-buttons .ag-side-button button {
        color: var(--pcm-text) !important;
    }

    .ag-theme-balham .ag-side-bar .ag-side-buttons .ag-selected button {
        background-color: var(--pcm-surface-muted) !important;
        border-color: var(--pcm-border) !important;
    }

    .ag-theme-balham .ag-side-bar .ag-panel-container {
        border-right-color: var(--pcm-border) !important;
    }

    .ag-theme-balham .ag-group-component {
        background-color: var(--pcm-surface-muted) !important;
        border-color: var(--pcm-border) !important;
    }

    .ag-theme-balham .ag-group-component .ag-group-component-title-bar {
        background-color: var(--pcm-surface-muted) !important;
    }

    .ag-theme-balham .ag-group-component .ag-group-component-toolbar {
        background-color: var(--pcm-surface-muted) !important;
        border-color: var(--pcm-border) !important;
    }

    /* ag-grid's own built-in color-picker widget is deliberately NOT themed,
       same as Portal's file -- .ag-color-panel .ag-spectrum-hue/-alpha-background
       are hardcoded rainbow/alpha gradients, not meaningfully "themeable". */

    /* .pcm-form-control (assets/css/shared/_full/050_pcm-form.css) */
    .pcm-form-control,
    .pcm-form-control-read-only,
    .pcm-form-control-grayed-out {
        background-color: var(--pcm-surface);
        border-color: var(--pcm-border);
        color: var(--pcm-text);
    }

    /* .pcm-form-field-error (same 050_pcm-form.css, applied by 16 shared
       views/shared/form/*.twig partials whenever a field fails validation)
       only ever set background-color: #FFFF96 !important -- no color of its
       own. Every one of those fields also carries .pcm-form-control, whose
       color: var(--pcm-text) above resolves near-white in dark mode, so an
       out-of-spec/invalid field renders near-white text on bright yellow --
       unreadable. This block must stay AFTER .pcm-form-control above: both
       selectors share specificity (0,1,0), and source order is the only thing
       deciding which color wins on a field with both classes. Fixed to a
       flat dark ink rather than a --pcm-text token -- this is a signal color
       (like button.pcm-radio-btn-active-fail two rules down in the same
       vendor file), meant to look identical regardless of theme. */
    .pcm-form-field-error {
        color: #000000;
    }

    /* input:disabled/select:disabled (assets/css/shared/_full/070_precoat.css)
       are type+pseudo-class selectors -- specificity (0,1,1), one level above
       the bare-class .pcm-form-control override above (0,1,0) -- so they win
       the background-color fight regardless of load order. That rule sets
       only background-color, so .pcm-form-control's color rule above still
       legitimately reaches these fields -- near-white text stuck on a
       background still #e0e0e0, the "invisible text" symptom on Plant/End
       User/Release Total (native disabled="disabled", hardcoded by
       views/shared/form/inputTextDisabled.twig). [disabled] attribute
       selectors included alongside :disabled for identical coverage without
       relying solely on the pseudo-class. .pcm-form-control-disabled
       (050_pcm-form.css:151, a flat #e0e0e0 with no attribute counterpart)
       folded in here too, same as Portal's identical rule -- 3 JS sites
       build a bootbox "Special Note" input with this class and no disabled
       attribute (production-q/paint-steel.js:985, active-releases.js:320,
       production-q-maintain/production-releases.js:1725), so without it
       those inputs kept the light literal background while color-scheme:
       dark flipped their UA-default text to near-white.

       background-color is --pcm-disabled-bg, NOT --pcm-surface-muted: this
       rule originally used --pcm-surface-muted (matching ".pcm-form-control-
       grayed-out"'s own muted-token call), but --pcm-surface-muted's dark
       value (#343a40) is actually LIGHTER than --pcm-surface's (#2b3035) --
       it's tuned for zebra-stripe/hover highlighting elsewhere, a different
       semantic (draw attention) from "disabled" (recede). That inverted the
       light-mode relationship (disabled's #e0e0e0 is DARKER than enabled's
       white): disabled inputs rendered brighter than enabled ones, the
       opposite of "these aren't the ones to focus on" -- the exact same bug
       already found and fixed on Portal's identical rule
       (assets/css/portal/theme-dark.css), just never ported back here.
       --pcm-disabled-bg (defined above) is darker than the page background
       itself, and is the same value used identically across all four
       rendering stacks in this rollout. */
    input:disabled,
    select:disabled,
    input[disabled],
    select[disabled],
    .pcm-form-control-disabled {
        background-color: var(--pcm-disabled-bg);
        border-color: var(--pcm-border);
        color: var(--pcm-text-muted);
    }

    /* Nav dropdown submenus (assets/css/shared/_full/035_pcm-menu-nav.css) --
       the pcm-menu-{color} top-level strip itself needs no change (already
       self-contained, saturated background + white text per environment). */
    div.pcm-dropdown, div.pcm-side-dropdown, div.pcm-side-side-dropdown {
        background-color: var(--pcm-surface);
        color: var(--pcm-text);
    }

    /* Each dropdown ITEM (not just the container above) sets its own explicit
       background-color: #ffffff, and background-color isn't inherited -- so
       overriding only the container left every individual row still hardcoded
       white regardless of the container's now-dark background. The blue
       hover highlight (#7eb1dc bg / white text) is left alone -- self-contained,
       reads fine on either theme, same as select2's highlighted row. */
    div.pcm-dropdown-item {
        background-color: var(--pcm-surface);
    }

    /* Bootstrap 3.3.5's own generic "boxed content" containers (005_bootstrap.min.css)
       -- .well (79 occurrences/30 files) and .panel (212/46 files) -- these are
       plain structural chrome, completely untouched until now, so every page using
       either class gets fixed by this one rule rather than page-by-page. Contextual
       panel variants (primary/success/info/warning/danger) keep their own signal
       colors untouched -- same judgment call as table.pcm-table's header above.
       .panel-heading's text color isn't set on the plain .panel itself (only via
       contextual variants or the .panel-default/bare-.panel-heading pair below,
       both of which are Bootstrap's literal #f5f5f5 "no variant" default). */
    /* Bootstrap 3.3.5's own bare <pre> element (005_bootstrap.min.css) --
       background-color:#f5f5f5, color:#333, border:1px solid #ccc, no
       class needed at all. Confirmed exactly 1 CoilZone usage
       (programmers/entity-creator.twig) -- this gap has been live in
       production since Phase 1 shipped, caught only now while
       investigating the same bug freshly reported on Portal's
       programmers/container-fix.twig (a plain <pre>, no CodeMirror/other
       widget involved there either). */
    pre {
        background-color: var(--pcm-surface-muted);
        color: var(--pcm-text);
        border-color: var(--pcm-border);
    }

    .well {
        background-color: var(--pcm-surface-muted);
        border-color: var(--pcm-border);
    }

    .panel {
        background-color: var(--pcm-surface);
    }

    .panel-default {
        border-color: var(--pcm-border);
    }

    .panel-heading,
    .panel-default > .panel-heading {
        color: var(--pcm-text);
        background-color: var(--pcm-surface-muted);
        border-color: var(--pcm-border);
    }

    /* Bootstrap 3.3.5's own .table-striped (005_bootstrap.min.css, e.g. the
       Vendor Home page's app-launcher list) -- a DIFFERENT component from
       table.pcm-table above, easy to conflate since both are "striped
       tables". Its one rule only colors the ODD rows
       (.table-striped>tbody>tr:nth-of-type(odd){background-color:#f9f9f9}) --
       even rows get no background of their own and simply show whatever the
       page behind them looks like. That's why only every-other row went dark:
       even rows correctly inherited the dark page background "for free" via
       body's own override above, while odd rows stayed stuck on the
       untouched, hardcoded #f9f9f9 light stripe. */
    .table-striped > tbody > tr:nth-of-type(odd) {
        background-color: var(--pcm-surface-muted);
    }

    /* Bootstrap 3.3.5's generic .table-hover (e.g. Change Environment's
       DEVL/DLIV/QUAL.../ARCA picker) -- a third distinct plain-Bootstrap
       table variant, separate from both table.pcm-table and .table-striped
       above. <tr class="active"> on the thead header row gets Bootstrap's
       own hardcoded #f5f5f5 "highlighted row" background regardless of
       theme, and .table-hover's own tbody row-hover rule is the same
       hardcoded #f5f5f5 -- neither has ever been touched until now. */
    .table > thead > tr.active > th,
    .table > thead > tr.active > td {
        background-color: var(--pcm-surface-muted);
    }

    .table-hover > tbody > tr:hover {
        background-color: var(--pcm-surface-muted);
    }

    /* select2 (assets/css/shared/_full/030_select2.min.css) -- a vendored jQuery
       widget that replaces the native <select> with its own DOM/CSS entirely
       (the original <select class="pcm-form-control select2"> gets hidden once
       select2 initializes), so the .pcm-form-control override above never
       reaches what's actually rendered -- this is the same class of gap as
       table.pcm-table, just for a different vendored library. Only the
       highlighted/selected result row (blue background, #5897fb) is left
       alone -- a self-contained accent color, fine on either theme. */
    .select2-container--default .select2-selection--single,
    .select2-container--default .select2-selection--multiple {
        background-color: var(--pcm-surface);
        border-color: var(--pcm-border);
        color: var(--pcm-text);
    }

    .select2-container--default.select2-container--disabled .select2-selection--single {
        background-color: var(--pcm-surface-muted);
    }

    /* The single-select's actual chosen value (e.g. "ALL") renders inside its
       own nested .select2-selection__rendered span, which 030_select2.min.css
       hardcodes to color: #444 at a 3-class specificity -- higher than the
       wrapper-level .select2-selection--single rule above, so that rule's
       color never actually reached the visible text: #444 dark-gray-on-dark-
       surface read as "slightly unreadable" rather than fully invisible. */
    .select2-container--default .select2-selection--single .select2-selection__rendered {
        color: var(--pcm-text);
    }

    /* Every rule below is deliberately prefixed to match or exceed
       030_select2.min.css's own specificity -- its rules are consistently
       .select2-container--default .select2-selection--multiple .foo
       (2-3 classes), which beat a bare .foo override every time regardless
       of source order. A bare-class first attempt at this block silently
       lost on background-color/color for the pill, its remove button, and
       the "already chosen" dropdown rows -- this rewrite fixes that. */
    .select2-container--default .select2-selection--multiple .select2-selection__choice {
        background-color: var(--pcm-surface-muted);
        border-color: var(--pcm-border);
        color: var(--pcm-text);
    }

    .select2-container--default .select2-selection--single .select2-selection__placeholder,
    .select2-container--default .select2-selection--multiple .select2-selection__placeholder {
        color: var(--pcm-text-muted);
    }

    .select2-dropdown {
        background-color: var(--pcm-surface);
        border-color: var(--pcm-border);
        color: var(--pcm-text);
    }

    .select2-container--default .select2-search--dropdown .select2-search__field {
        background-color: var(--pcm-surface);
        border-color: var(--pcm-border);
        color: var(--pcm-text);
    }

    .select2-container--default .select2-results__option[aria-selected=true] {
        background-color: var(--pcm-surface-muted);
    }

    /* The "already selected" state in an open multi-select dropdown (grayed
       out since you can't pick it again) is aria-disabled, not aria-selected
       -- a different attribute I'd missed, which is why those rows still
       looked washed out even after the background fix above. */
    .select2-container--default .select2-results__option[aria-disabled=true] {
        color: var(--pcm-text-muted);
    }

    /* The "x" remove button on a multi-select pill -- #999 base is a
       reasonable-contrast mid-gray either way, but its hover state (#333,
       near-black) is invisible against the now-dark pill background above. */
    .select2-container--default .select2-selection--multiple .select2-selection__choice__remove {
        color: var(--pcm-text-muted);
    }

    .select2-container--default .select2-selection--multiple .select2-selection__choice__remove:hover {
        color: var(--pcm-text);
    }

    /* .btn-default (005_bootstrap.min.css) -- Bootstrap's plain/neutral
       button variant, used site-wide (e.g. the "Change" button next to the
       Locations/Metal Owner/End User filters, every "Manage ..." link on
       the home page) and completely untouched until now. Other contextual
       button variants (btn-success, btn-danger, etc.) keep their own signal
       colors, same judgment call as everywhere else in this file.
       background-color needs !important: a pre-existing, unrelated rule in
       070_precoat.css (.btn-default { background-color: #f4f4f4 !important })
       already forces this property, and normal-weight declarations can never
       beat !important regardless of specificity or source order. color/
       border-color aren't forced there, so they don't need it here either. */
    .btn-default {
        color: var(--pcm-text);
        background-color: var(--pcm-surface) !important;
        border-color: var(--pcm-border);
    }

    /* color must be repeated here (not just background/border): Bootstrap's
       own .btn-default:hover/:active rules set color: #333 at a higher
       specificity than the plain .btn-default rule above, so without this
       the label silently reverts to near-black text on the dark hover/active
       background below -- invisible, not just low-contrast. */
    .btn-default:hover,
    .btn-default:focus,
    .btn-default.active,
    .btn-default:active,
    .open > .dropdown-toggle.btn-default {
        color: var(--pcm-text);
        background-color: var(--pcm-surface-muted);
        border-color: var(--pcm-border);
    }

    /* .btn-default.form-changes/.formChanged -- .form-changes's intended
       yellow flash (070_precoat.css: background-color: yellow !important)
       never actually renders on ANY .btn-default button (e.g.
       activity/order-completion.js's changeButton) once dark mode is on:
       .btn-default's OWN dark-mode background above is the SAME 1-class
       specificity, ALSO !important, and this file loads after
       070_precoat.css -- so it silently wins the background tie every
       time. Confirmed live via DevTools on Portal's identical bug (same
       070_precoat.css rule, same .btn-default fight -- see the equivalent
       comment in assets/css/portal/theme-dark.css for the full trace).

       An EARLIER version of this fix here (a bare
       `.form-changes, .formChanged { color: #000000; }`, no !important)
       DID correctly win the color battle -- CoilZone has no portal_v1.css-
       style .form-changes color override to compete with, unlike Portal --
       but that was never the whole problem: with the background still
       losing to --pcm-surface, the visible result was black text (this
       fix) on dark slate (.btn-default's background) -- still unreadable,
       just via a different half of the same bug. Re-scoped to the
       SPECIFIC broken combination (.btn-default.form-changes, 2-class) so
       it fixes background too, beating .btn-default's 1-class rules
       outright on specificity. Re-asserts the same yellow (self-contained
       signal color, meant to look identical regardless of theme) with
       black text, restoring the "unsaved changes" cue instead of leaving
       it silently disabled on every .btn-default button in dark mode. */
    .btn-default.form-changes,
    .btn-default.formChanged {
        background-color: yellow !important;
        color: #000000 !important;
    }

    /* button.gray-button (070_precoat.css, e.g. the Inquiries "Search ->"
       buttons) forces its own background-color: #e7e7e7 !important -- a
       higher-specificity selector (element + class) than the plain
       .btn-default rule above, and !important beats !important only by
       specificity/order, so it always won regardless of theme, leaving
       .btn-default's var(--pcm-text) label color sitting on a permanently
       light-gray background -- unreadable once that text goes light in
       dark mode. Needs matching specificity + !important to actually win. */
    button.gray-button {
        background-color: var(--pcm-surface-muted) !important;
    }

    /* Bootstrap 3.3.5's bare .dropdown-menu (005_bootstrap.min.css) -- the
       "User Views" toolbar dropdown (views/shared/table-filter/top/sections/
       user-views.twig, its .btn-default trigger already fixed above) is a
       plain <ul class="dropdown-menu">, not select2/pcm-dropdown/
       bootstrap-switch, so none of the overrides above ever reach it and it
       keeps Bootstrap's hardcoded white popup regardless of theme. */
    .dropdown-menu {
        background-color: var(--pcm-surface);
        border-color: var(--pcm-border);
    }

    /* .dropdown-menu>li>a covers every row -- "Default", each saved view, and
       "Manage User Views" -- alike: the twig conditional (UserViews.Selected /
       L.Selected) only swaps an <i class="cus-tick"> icon for four &nbsp;s
       inside an otherwise identical <a>, there's no .active/.selected class
       for the "selected" row to hang a separate rule off of, so this bare
       selector is what actually fixes the selected row's unreadable text. */
    .dropdown-menu > li > a {
        color: var(--pcm-text);
    }

    .dropdown-menu > li > a:focus,
    .dropdown-menu > li > a:hover {
        color: var(--pcm-text);
        background-color: var(--pcm-surface-muted);
    }

    /* Bootstrap's semantic .alert-warning (005_bootstrap.min.css) is used
       throughout CoilZone as a plain "notice board" background (Bulletins,
       Special Notifications, Notifications on the home page and others),
       not as an actual warning message -- its default pale yellow
       (#fcf8e3/#8a6d3b) reads oddly against a dark page. Values below are
       reused verbatim from Phase 0's own Bootstrap 5.3 dark-warning palette
       (assets/tmpl/css/shared/theme.css) for cross-stack consistency, rather
       than inventing a new amber shade. This affects every .alert-warning
       sitewide (real warnings included) -- intentional, since a real warning
       alert has the exact same pale-yellow-on-dark problem. */
    .alert-warning {
        color: #ffda6a;
        background-color: #332701;
        border-color: #997404;
    }

    /* bootstrap-switch (032_bootstrap-switch.min.css, e.g. the "Open Links
       New Tab" toggle) -- flagged in the earlier Bootstrap-upgrade feasibility
       study as hardcoding BS3's exact visual tokens with no theme-reactivity
       of its own; same treatment as every other vendored component above.
       Every one of its rules (confirmed via the actual rendered DOM: outer
       div carries only structural/state classes -- bootstrap-switch-wrapper,
       -mini, -on/-off -- with no color rules of their own; the two inner
       handle spans carry the real color-variant classes, e.g.
       bootstrap-switch-handle-off.bootstrap-switch-default) is written as
       .bootstrap-switch <descendant-selector>, never a bare class -- a first
       attempt using bare classes (.bootstrap-switch-label,
       .bootstrap-switch-default) silently lost to this on specificity,
       exactly like select2 above. */
    .bootstrap-switch {
        border-color: var(--pcm-border);
    }

    .bootstrap-switch .bootstrap-switch-label {
        color: var(--pcm-text);
        background-color: var(--pcm-surface);
    }

    .bootstrap-switch .bootstrap-switch-handle-off.bootstrap-switch-default,
    .bootstrap-switch .bootstrap-switch-handle-on.bootstrap-switch-default {
        color: var(--pcm-text);
        background-color: var(--pcm-surface-muted);
    }

    /* Bootstrap 3.3.5's modal (005_bootstrap.min.css, e.g. the Plant/Customer
       Totals popups) -- plain hardcoded white shell, completely untouched
       until now, so any pcm-table dropped inside it (already dark via the
       override above) rendered as a dark table floating inside a white box:
       the "half light half dark" bug. modal-title/-body need no rule of
       their own -- color is inherited from .modal-content. */
    .modal-content {
        background-color: var(--pcm-surface);
        color: var(--pcm-text);
        border-color: var(--pcm-border);
    }

    .modal-header,
    .modal-footer {
        border-color: var(--pcm-border);
    }

    /* The close "x": color:#000 with a white text-shadow (a fake emboss
       against Bootstrap's assumed-white modal) -- both need to go, or it
       reads as a pale ghost / glowing smudge against the dark header. */
    .close {
        color: var(--pcm-text);
        text-shadow: none;
    }

    .close:hover,
    .close:focus {
        color: var(--pcm-text);
    }
}

/* NOTE: production-q/rack-up's tr.date-header (light-lavender row, text-
   color-invisible-on-dark bug) is NOT fixed here -- an earlier attempt to
   override it from this file didn't work: page-specific CSS linked via
   {% block css %} (e.g. rack-up.css) loads AFTER this file (webAppCss block
   renders first in views/shared/layouts/precoat-master.twig), so this file
   can never win an equal-specificity fight against it. The fix lives
   directly in assets/css/coilzone/production-orders/rack-up.css instead. */