/* WS Payment Central — admin console stylesheet. ============================================================================================================ ONE FILE, AND EVERY COLOUR IN IT COMES FROM A TOKEN. Nothing here is a literal outside the two :root blocks, because tools/check-admin-ui-contrast.mjs reads the PALETTE out of this file and scores 74 pairs across both themes. A hardcoded hex in a rule is invisible to that gate, so it is the one thing that can drop a pair under threshold with nothing to catch it. THEME HAS FIVE STATES NOW, AND THE ATTRIBUTE IS ALWAYS PRESENT. This paragraph used to say there were three -- light, dark and an OS default that emitted no attribute at all -- and that model could not carry the two themes an operating system knows nothing about. High contrast and brand-coloured are CHOICES, not preferences the browser can report, so prefers-color-scheme cannot be the signal for them. theme-boot.js resolves "system" against that query and stamps data-theme, data-density and data-reduced-motion on before first paint; every scope below is an attribute selector and there is no media query for theme left in this file. Light is still the bare :root, unchanged, so it is what a missing attribute would fall back to and what the console looks like with nothing stored. EVERY TOKEN IS STILL DEFINED ON BARE :root FIRST and only REDEFINED in a theme scope, which is what AdminUiSourceTests.The_dark_theme_redefines_only_tokens_the_light_root_already_defines checks -- widened to every scope, because a token whose only definition lives in one theme is undefined in the other four. ------------------------------------------------------------------------------------------------------------ VISUAL DIRECTION, REVISED 2026-08-23 FROM A SUPPLIED MOCKUP — AND IT REVERSES TWO DECISIONS THIS FILE USED TO ARGUE FOR AT LENGTH. Both reversals are recorded here rather than quietly applied, because the arguments against them were reasoned and a future reader will otherwise re-derive them and revert: 1. A SECTION IS A CARD NOW. This file previously held that "a section is a heading, a rule and its content -- not a box on a tray", on the grounds that boxing everything spends elevation on containers rather than on content. The mockup boxes them, and it is right for THIS console for a reason the old argument missed: almost every screen here is several INDEPENDENT reads stacked vertically (accounts, then routing, then history), and a hairline rule does not say where one ends and the next begins once a table sits between them. The distinction that mattered -- .section.write being visibly a different KIND of thing -- is preserved and strengthened, not lost. 2. THE RAIL IS A SURFACE NOW. This file previously gave the sidebar no fill beyond a half-step of ground, arguing a tinted rail "spends the loudest signal available on navigation, which is what the operator looks at least". Still true of a SATURATED rail; the mockup uses a plain white surface against a tinted page, which spends no colour at all and reads as chrome by separation rather than by hue. The original concern is answered rather than overruled. What the mockup could NOT contribute, and why, so nobody re-attempts it: - ITS WEBFONTS. font-src is 'self' with no exemption, so Inter and JetBrains Mono would silently not load, and The_stylesheet_pulls_in_no_webfont_and_nothing_from_another_origin fails the build. Google Fonts additionally needs style-src to admit fonts.googleapis.com -- a third-party origin able to inject CSS into a payments admin console, which is a larger concession than the glyphs are worth. Self-hosting woff2 would need no CSP change and is the route to take if the exact face is ever wanted. - ITS INLINE style="" ATTRIBUTES, everywhere. style-src 'self' governs the attribute form exactly as it governs a