/* Ziltch SHARED CHROME โ€” the ONE source of the design tokens + the header/brand chrome, loaded by BOTH installable theme features (the Ziltch.Theme SITE Layout and the Ziltch.Theme.Admin admin Layout). Erin-directed 2026-07-17: "share (NOT DUPLICATE!!!) header/footer/style between site and admin." These rules used to live in ziltch.css (site only); they were relocated here verbatim so the admin surface renders the SAME ZiltchChromeView header from the SAME CSS โ€” one file, two themes, nothing to keep in sync. ziltch.css now loads this first and owns only the site-LAYOUT rules (body flex frame, front-door, content) that must NOT reach the admin layout. */ /* ๐Ÿ›๏ธ DARK-FIRST, FOLLOWING THE SYSTEM (Erin GOVERNING 2026-08-07: "dark first" + "light/dark = follow system"). BOTH HALVES ARE LOAD-BEARING AND THEY ARE NOT IN TENSION. Dark-first means dark is the BASE declaration and the platform's identity -- it is what a browser with no preference gets, and what every value here is designed against. Follow-system means a visitor whose OS asks for light GETS light. `prefers-color-scheme: light` is therefore an OVERRIDE ON TOP of a dark base, not a peer of it. โš ๏ธ AN EARLIER VERSION OF THIS BLOCK READ "dark unconditionally; the OS is not consulted" AND THAT WAS WRONG -- I took "dark first" to mean "dark only". Corrected the same session. Recorded rather than silently rewritten because the two readings produce IDENTICAL CSS for every dark-OS visitor, so nothing would have surfaced the error until a light-OS visitor arrived and got a site that ignored their setting. ๐Ÿ”‘ EVERY COLOUR IS DEFINED EXACTLY ONCE, IN THE `--p-{dark,light}-*` PALETTES BELOW, AND NOTHING READS THEM DIRECTLY. The four condition blocks that follow only SELECT a palette by aliasing. That is what makes this "cannot drift" rather than "currently consistent": a colour and its `-rgb` triplet are declared side by side in one place, so the pairing that broke this file before (a hex moving while its triplet stayed) is now structurally impossible -- there is no second copy to forget. A mistake in an alias points at a DEFINED token and shows up as a missing value; a mistake in a duplicated hex is invisible. ๐ŸŽจ BRAND IS TWO VALUES AND THAT IS NOT A COMPROMISE -- it is what this cone's two stylesheets were each half expressing. A SURFACE brand must be deep enough to carry white ink on a button; a TEXT brand must be light enough to read as a link against the surface. On dark those are different colours (#5b3e78 / #b79bd6); on light one value does both (#472c54). Wiring links and buttons to a single token is why they kept disagreeing about what "the brand purple" is. ๐Ÿงญ AND IT ENDS THE TWO-PALETTE CASCADE CONFLICT AT THE ROOT. `ziltch-terminal.css` (Ziltch.Gateway) declares the DARK terminal palette at `:root` document-wide and loads AFTER this file, so it won every name it declared and lost every one it did not -- composing a half-dark, half-light third palette (near-white body text on white). Dark-first makes the two AGREE by default. The `--ztc-*` bridge stays anyway: agreement is not a guarantee, and on a light-OS visitor they legitimately differ, which is exactly when the private mirror earns its keep. */ :root { color-scheme: dark light; /* โ”€โ”€ THE DARK PALETTE โ€” the base identity. Declared once; pairs adjacent. โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ */ --p-dark-brand: #5b3e78; --p-dark-brand-rgb: 91, 62, 120; --p-dark-brand-deep: #472c54; --p-dark-brand-bright: #7a57a0; --p-dark-brand-text: #b79bd6; --p-dark-brand-text-rgb: 183, 155, 214; --p-dark-brand-link-hover: #d3c0e8; --p-dark-brand-tint: #1a2036; --p-dark-gold: #e9c46a; --p-dark-gold-rgb: 233, 196, 106; --p-dark-ink: #dbe4f5; --p-dark-ink-rgb: 219, 228, 245; --p-dark-ink-dim: #7e8aa3; --p-dark-line: #24314a; --p-dark-surface: #0b1020; --p-dark-surface-rgb: 11, 16, 32; --p-dark-surface-2: #121a2e; /* โ”€โ”€ THE LIGHT PALETTE โ€” the system-preference override. โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ */ --p-light-brand: #472c54; --p-light-brand-rgb: 71, 44, 84; --p-light-brand-deep: #472c54; --p-light-brand-bright: #6b4a8f; --p-light-brand-text: #472c54; --p-light-brand-text-rgb: 71, 44, 84; --p-light-brand-link-hover: #6b4a8f; --p-light-brand-tint: #f3eef7; --p-light-gold: #c79a3a; --p-light-gold-rgb: 199, 154, 58; --p-light-ink: #20232e; --p-light-ink-rgb: 32, 35, 46; --p-light-ink-dim: #5b6070; --p-light-line: #e6e6ec; --p-light-surface: #ffffff; --p-light-surface-rgb: 255, 255, 255; --p-light-surface-2: #f6f5f9; /* scheme-independent */ --zt-brand-ink: #ffffff; /* white sits on the brand SURFACE in both schemes -- both are deep purples */ --zt-radius: 8px; --zt-font-ui: system-ui, -apple-system, "Segoe UI", Roboto, sans-serif; /* โ”€โ”€ ACTIVATION 1 of 4: DARK, the base. โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ */ --zt-brand: var(--p-dark-brand); --zt-brand-rgb: var(--p-dark-brand-rgb); --zt-brand-deep: var(--p-dark-brand-deep); --zt-brand-bright: var(--p-dark-brand-bright); --zt-brand-text: var(--p-dark-brand-text); --zt-brand-tint: var(--p-dark-brand-tint); --zt-gold: var(--p-dark-gold); --zt-gold-rgb: var(--p-dark-gold-rgb); --zt-ink: var(--p-dark-ink); --zt-ink-rgb: var(--p-dark-ink-rgb); --zt-ink-dim: var(--p-dark-ink-dim); --zt-line: var(--p-dark-line); --zt-surface: var(--p-dark-surface); --zt-surface-rgb: var(--p-dark-surface-rgb); --zt-surface-2: var(--p-dark-surface-2); --ziltch-accent: var(--p-dark-brand-text); --ztc-brand: var(--p-dark-brand); --ztc-brand-rgb: var(--p-dark-brand-rgb); --ztc-brand-bright: var(--p-dark-brand-bright); --ztc-link: var(--p-dark-brand-text); --ztc-link-rgb: var(--p-dark-brand-text-rgb); --ztc-link-hover: var(--p-dark-brand-link-hover); --ztc-ink: var(--p-dark-ink); --ztc-ink-rgb: var(--p-dark-ink-rgb); --ztc-ink-dim: var(--p-dark-ink-dim); --ztc-surface: var(--p-dark-surface); --ztc-surface-rgb: var(--p-dark-surface-rgb); --ztc-surface-2: var(--p-dark-surface-2); --ztc-line: var(--p-dark-line); /* The emergent-surface palette โ€” UniverseSurfaceIsland + RenderFloor read these. Aliased to the chrome tokens, so the surface IS the chrome's palette rather than a second one that has to be kept in step. */ --zt-bg: var(--zt-surface); --zt-fg: var(--zt-ink); --zt-muted: var(--zt-ink-dim); --zt-accent: var(--zt-gold); --zt-accent-2: var(--zt-brand-text); --zt-grid: var(--zt-line); --zt-panel: var(--zt-surface-2); } /* โ”€โ”€ ACTIVATION 2 of 4: LIGHT when the SYSTEM asks โ€” unless the page explicitly asked for dark. โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ The `:not([data-bs-theme="dark"])` is what lets an explicit dark toggle survive a light OS. It also equalises specificity with the explicit blocks below (`:not()` takes its argument's specificity), so those must come AFTER this in source order to win โ€” they do. */ @media (prefers-color-scheme: light) { :root:not([data-bs-theme="dark"]) { color-scheme: light; --zt-brand: var(--p-light-brand); --zt-brand-rgb: var(--p-light-brand-rgb); --zt-brand-deep: var(--p-light-brand-deep); --zt-brand-bright: var(--p-light-brand-bright); --zt-brand-text: var(--p-light-brand-text); --zt-brand-tint: var(--p-light-brand-tint); --zt-gold: var(--p-light-gold); --zt-gold-rgb: var(--p-light-gold-rgb); --zt-ink: var(--p-light-ink); --zt-ink-rgb: var(--p-light-ink-rgb); --zt-ink-dim: var(--p-light-ink-dim); --zt-line: var(--p-light-line); --zt-surface: var(--p-light-surface); --zt-surface-rgb: var(--p-light-surface-rgb); --zt-surface-2: var(--p-light-surface-2); --ziltch-accent: var(--p-light-brand-text); --ztc-brand: var(--p-light-brand); --ztc-brand-rgb: var(--p-light-brand-rgb); --ztc-brand-bright: var(--p-light-brand-bright); --ztc-link: var(--p-light-brand-text); --ztc-link-rgb: var(--p-light-brand-text-rgb); --ztc-link-hover: var(--p-light-brand-link-hover); --ztc-ink: var(--p-light-ink); --ztc-ink-rgb: var(--p-light-ink-rgb); --ztc-ink-dim: var(--p-light-ink-dim); --ztc-surface: var(--p-light-surface); --ztc-surface-rgb: var(--p-light-surface-rgb); --ztc-surface-2: var(--p-light-surface-2); --ztc-line: var(--p-light-line); } } /* โ”€โ”€ ACTIVATION 3 and 4 of 4: the EXPLICIT toggles (TheAdmin ships one). Last in source order deliberately. โ”€โ”€โ”€โ”€โ”€โ”€ */ :root[data-bs-theme="light"] { color-scheme: light; --zt-brand: var(--p-light-brand); --zt-brand-rgb: var(--p-light-brand-rgb); --zt-brand-deep: var(--p-light-brand-deep); --zt-brand-bright: var(--p-light-brand-bright); --zt-brand-text: var(--p-light-brand-text); --zt-brand-tint: var(--p-light-brand-tint); --zt-gold: var(--p-light-gold); --zt-gold-rgb: var(--p-light-gold-rgb); --zt-ink: var(--p-light-ink); --zt-ink-rgb: var(--p-light-ink-rgb); --zt-ink-dim: var(--p-light-ink-dim); --zt-line: var(--p-light-line); --zt-surface: var(--p-light-surface); --zt-surface-rgb: var(--p-light-surface-rgb); --zt-surface-2: var(--p-light-surface-2); --ziltch-accent: var(--p-light-brand-text); --ztc-brand: var(--p-light-brand); --ztc-brand-rgb: var(--p-light-brand-rgb); --ztc-brand-bright: var(--p-light-brand-bright); --ztc-link: var(--p-light-brand-text); --ztc-link-rgb: var(--p-light-brand-text-rgb); --ztc-link-hover: var(--p-light-brand-link-hover); --ztc-ink: var(--p-light-ink); --ztc-ink-rgb: var(--p-light-ink-rgb); --ztc-ink-dim: var(--p-light-ink-dim); --ztc-surface: var(--p-light-surface); --ztc-surface-rgb: var(--p-light-surface-rgb); --ztc-surface-2: var(--p-light-surface-2); --ztc-line: var(--p-light-line); } :root[data-bs-theme="dark"] { color-scheme: dark; --zt-brand: var(--p-dark-brand); --zt-brand-rgb: var(--p-dark-brand-rgb); --zt-brand-deep: var(--p-dark-brand-deep); --zt-brand-bright: var(--p-dark-brand-bright); --zt-brand-text: var(--p-dark-brand-text); --zt-brand-tint: var(--p-dark-brand-tint); --zt-gold: var(--p-dark-gold); --zt-gold-rgb: var(--p-dark-gold-rgb); --zt-ink: var(--p-dark-ink); --zt-ink-rgb: var(--p-dark-ink-rgb); --zt-ink-dim: var(--p-dark-ink-dim); --zt-line: var(--p-dark-line); --zt-surface: var(--p-dark-surface); --zt-surface-rgb: var(--p-dark-surface-rgb); --zt-surface-2: var(--p-dark-surface-2); --ziltch-accent: var(--p-dark-brand-text); --ztc-brand: var(--p-dark-brand); --ztc-brand-rgb: var(--p-dark-brand-rgb); --ztc-brand-bright: var(--p-dark-brand-bright); --ztc-link: var(--p-dark-brand-text); --ztc-link-rgb: var(--p-dark-brand-text-rgb); --ztc-link-hover: var(--p-dark-brand-link-hover); --ztc-ink: var(--p-dark-ink); --ztc-ink-rgb: var(--p-dark-ink-rgb); --ztc-ink-dim: var(--p-dark-ink-dim); --ztc-surface: var(--p-dark-surface); --ztc-surface-rgb: var(--p-dark-surface-rgb); --ztc-surface-2: var(--p-dark-surface-2); --ztc-line: var(--p-dark-line); } /* โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ• THE FOUNDATION โ€” scale tokens, and the BOOTSTRAP BRIDGE that makes all of this reach code we do not own. Erin 2026-08-07: "I want the ziltch site and admin to ultimately use the same style/layout/ux elements... heavily customize in a way that cannot drift" + "Blazor first" + "pretty/elegant" + "we need a foundation on which we can grow that." ๐Ÿ”‘ WHY THE BRIDGE IS THE WHOLE POINT AND THE ONE THING THAT COULD NOT BE DONE WITH COMPONENTS: a Blazor component can only style a surface WE author. The admin's forms, tables, editors, modals and pagers are OrchardCore's markup authored against Bootstrap 5 โ€” we are never going to rewrite them, and we do not have to. TheAdmin IS Bootstrap 5, Bootstrap 5 reads CSS custom properties, so re-pointing --bs-* at the --zt-* palette restyles OC's ENTIRE admin from this file, with zero markup touched. That is what turns "two surfaces that look different" into one body. โš ๏ธ AND IT IS WHY TOKENS COME BEFORE COMPONENTS. Components reach only what we write; tokens reach everything โ€” OC's admin, our components, Bootstrap's defaults, and anything added later. Elegance lives almost entirely in palette / type scale / spacing / radius rather than in markup, so this is also the cheapest surface to make good. โš ๏ธ THE -rgb TRIPLETS ARE NOT OPTIONAL. Bootstrap composes alpha colours as rgba(var(--bs-primary-rgb), .5); if the hex moves and the triplet does not, every translucent surface silently keeps the OLD hue and nothing errors. They are declared beside their hex for exactly that reason โ€” the pair must move together or not at all. โš ๏ธ THIS PARAGRAPH USED TO SAY "DARK MODE IS TWO MECHANISMS AND BOTH ARE HANDLED" โ€” OS preference and TheAdmin's data-bs-theme toggle. AFTER THE DARK-FIRST FLIP THERE IS ONE MECHANISM AND IT RUNS THE OTHER WAY: dark is unconditional at :root, and the only switch is an explicit opt-in to LIGHT. The OS is not consulted. Kept as a correction rather than deleted because the old text prescribed wiring the bridge to a media query, which would now be a second declaration of the default โ€” the exact drift surface this file keeps removing. โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ• */ :root { /* TYPE SCALE โ€” a ratio, not a pile of one-off sizes. 1.200 (minor third): dense enough for an operator surface without the jumps reading as decorative. Every size below derives from --zt-fs-base so re-scaling the product is ONE number. */ /* โš ๏ธ THE SIZES BELOW NOW ACTUALLY DERIVE FROM --zt-fs-base. Until 2026-08-29 they were hardcoded rem literals (0.694rem, 0.833rem, ...) while this comment claimed a derivation, so the "re-scaling is ONE number" knob was decorative: --zt-fs-base was referenced by nothing but --bs-body-font-size. calc() makes the claim true. The computed values are byte-identical at base 1rem, so this changed no pixel โ€” it reconnected the knob. โš ๏ธ AND THE KNOB IS STILL OVERRIDDEN DOWNSTREAM, which is a RULING someone owes, not a bug to patch here: ziltch-terminal.css redefines --zt-fs-xs/sm/md/lg as PX at plain :root and Layout.cshtml loads it LAST (126 chrome, 127 ziltch, 128 terminal), so at equal specificity the px scale wins DOCUMENT-WIDE โ€” front door and admin chrome included, not just the gateway app. Both files are documented as "THE design system"; link order picks the winner. Consequences: (1) this knob moves nothing for xs-lg; (2) terminal.css:216's `font-size:17.5px` on html.zt-app-html โ€” written to answer Erin's "everything is tiny" โ€” cannot scale its own px tokens, defeating that fix; (3) the scale is mixed-unit at the seam, lg=19px then xl=1.44rem. DO NOT "fix" this by deleting one side: which file owns the type scale is a design ruling (@echo governs UI shape). โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ */ --zt-fs-base: 1rem; --zt-fs-xs: calc(var(--zt-fs-base) * 0.694); --zt-fs-sm: calc(var(--zt-fs-base) * 0.833); --zt-fs-md: calc(var(--zt-fs-base) * 1); --zt-fs-lg: calc(var(--zt-fs-base) * 1.2); --zt-fs-xl: calc(var(--zt-fs-base) * 1.44); --zt-fs-2xl: calc(var(--zt-fs-base) * 1.728); --zt-fs-3xl: calc(var(--zt-fs-base) * 2.074); --zt-lh-tight: 1.25; --zt-lh-base: 1.55; /* SPACING RHYTHM โ€” a 4px base step. Named by step rather than by use, so a component cannot invent a "just slightly different" gap without it being visible as a raw value in review. */ --zt-space-1: 0.25rem; --zt-space-2: 0.5rem; --zt-space-3: 0.75rem; --zt-space-4: 1rem; --zt-space-5: 1.5rem; --zt-space-6: 2rem; --zt-space-8: 3rem; /* RADIUS + ELEVATION โ€” --zt-radius already existed and stays the base; the rest derive from it. */ --zt-radius-sm: calc(var(--zt-radius) / 2); --zt-radius-lg: calc(var(--zt-radius) * 1.5); --zt-radius-pill: 999px; --zt-shadow-1: 0 1px 2px rgb(0 0 0 / 6%), 0 1px 3px rgb(0 0 0 / 8%); --zt-shadow-2: 0 4px 12px rgb(0 0 0 / 10%); --zt-shadow-3: 0 12px 32px rgb(0 0 0 / 14%); /* rgb triplets for the DARK (default) palette โ€” see the -rgb warning above. The light opt-in re-points them. */ --zt-brand-rgb: 91, 62, 120; --zt-gold-rgb: 233, 196, 106; --zt-ink-rgb: 219, 228, 245; --zt-surface-rgb: 11, 16, 32; } :root[data-bs-theme="light"] { --zt-brand-rgb: 71, 44, 84; --zt-gold-rgb: 199, 154, 58; --zt-ink-rgb: 32, 35, 46; --zt-surface-rgb: 255, 255, 255; } /* โ”€โ”€ THE BRIDGE: Bootstrap (and therefore ALL of OrchardCore's admin) reads Ziltch's palette โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ */ /* ๐Ÿ”ด `:root:root` IS DELIBERATE AND IS THE WHOLE REASON THIS WORKS. Measured on the live body: the first version used a plain `:root` and `--bs-primary` computed to #0d6efd โ€” BOOTSTRAP'S DEFAULT BLUE. The bridge was inert. Bootstrap's stylesheet is loaded AFTER this file and declares its palette on `:root` too. Equal specificity means SOURCE ORDER decides, and Bootstrap is later, so every --bs-* here was being overwritten. Repeating the selector (`:root:root`) doubles specificity, which order cannot beat. โš ๏ธ AND THE FAILURE WAS SILENT AND FLATTERING: the SCALE tokens (--zt-fs-*, --zt-space-*, --zt-shadow-*) worked fine, because Bootstrap does not define those names โ€” so a spot-check of "did my tokens land" returned YES while the half that reaches OrchardCore's admin was doing nothing. Check the BRIDGED name (--bs-primary), never a token only we declare. */ /* ๐Ÿ”ด THE BRIDGE READS `--ztc-*`, NOT `--zt-*`, AND THAT IS THE WHOLE POINT โ€” MEASURED LIVE ON /Login 2026-08-07. `ziltch-terminal.css` (Ziltch.Gateway) declares the DARK terminal palette at plain `:root` and is loaded DOCUMENT-WIDE on every page including this light OC chrome. It loads AFTER this file, so at equal specificity it WINS for the names it declares and LOSES for the ones it does not: --zt-brand #5b3e78 (terminal) vs --zt-brand-rgb 71,44,84 = #472c54 (here) DISAGREE --zt-gold #e9c46a (terminal) vs --zt-gold-rgb 199,154,58 = #c79a3a (here) DISAGREE --zt-ink #e8ecf8 (terminal) vs --zt-ink-rgb 32,35,46 = #20232e (here) DISAGREE --zt-surface #ffffff (here, terminal declares none) agree โ‡’ the bridge was composing a HALF-DARK, HALF-LIGHT palette: `--bs-body-color: #e8ecf8` (near-white) against `--bs-body-bg: #ffffff` (white). Any Bootstrap surface that paints its own body background โ€” a card, modal, dropdown, offcanvas, `.bg-body` โ€” drew NEAR-WHITE TEXT ON WHITE. And every alpha composition (`rgba(var(--bs-primary-rgb), โ€ฆ)`: focus rings, `.text-bg-primary`, link hovers) painted a DIFFERENT purple than the solid beside it. โš ๏ธ NEITHER SHEET IS WRONG ON ITS OWN AND THAT IS WHY THIS SURVIVED: each declares a coherent palette, and the incoherence exists only in the CASCADE between two assemblies. Reading either file end to end shows nothing. Only the computed value on a live page does โ€” which is the same trap this file already documents one block down for `--bs-primary` (`check the BRIDGED name, never a token only we declare`), one level up: check the COMPUTED PAIR, never a declaration. `--ztc-*` is declared HERE AND NOWHERE ELSE (grep it), so a colour and its triplet cannot desynchronize no matter what any other assembly puts on `:root`. The `--zt-*` tokens keep their existing meaning for the terminal's own scoped surfaces; this only stops them silently deciding the OC chrome's palette. */ :root:root { /* NO --ztc-* VALUES HERE. They are SELECTED by the four activation blocks at the top of this file; this block only MAPS them onto Bootstrap's names. Having both was a live bug for one commit: this selector is `:root:root` (0,2,0) and the follow-the-system light block is `:root:not([data-bs-theme="dark"])` (also 0,2,0, since :not() takes its argument's specificity) -- equal, so SOURCE ORDER decided, and this block is later. The light activation set `color-scheme: light` and then had its palette overwritten from here. โš ๏ธ THE TELL WAS AN INTERNAL CONTRADICTION, NOT A WRONG COLOUR: computed `color-scheme: light` against a #0b1020 surface. Both halves came from blocks that were individually correct, and only reading them TOGETHER showed one had been half-overridden -- the same cascade-between-two-declarations shape this file already documents for the two stylesheets, arriving inside a single file. */ --bs-primary: var(--ztc-brand); --bs-primary-rgb: var(--ztc-brand-rgb); /* LINK reads the TEXT brand, not the surface brand โ€” see the two-values note at the top of this file. Wiring both to one token is what made links illegible on dark or buttons washed out on light, depending on which value won. */ --bs-link-color: var(--ztc-link); --bs-link-color-rgb: var(--ztc-link-rgb); --bs-link-hover-color: var(--ztc-link-hover); --bs-body-bg: var(--ztc-surface); --bs-body-bg-rgb: var(--ztc-surface-rgb); --bs-body-color: var(--ztc-ink); --bs-body-color-rgb: var(--ztc-ink-rgb); --bs-secondary-color: var(--ztc-ink-dim); --bs-secondary-bg: var(--ztc-surface-2); --bs-tertiary-bg: var(--ztc-surface-2); --bs-border-color: var(--ztc-line); --bs-border-radius: var(--zt-radius); --bs-border-radius-sm: var(--zt-radius-sm); --bs-border-radius-lg: var(--zt-radius-lg); --bs-border-radius-pill: var(--zt-radius-pill); --bs-font-sans-serif: var(--zt-font-ui); --bs-body-font-size: var(--zt-fs-base); --bs-body-line-height: var(--zt-lh-base); --bs-box-shadow: var(--zt-shadow-2); --bs-box-shadow-sm: var(--zt-shadow-1); --bs-box-shadow-lg: var(--zt-shadow-3); } /* The OS-dark branch above already flipped --zt-*; this re-points the rgb triplets that cannot follow a var() indirection, so Bootstrap's alpha surfaces track the dark palette instead of silently keeping the light hue. */ /* NO LIGHT BRIDGE OVERRIDE EITHER, FOR THE SAME REASON: the activation blocks already select the light palette into --ztc-*, so a second copy here could only drift from them. */ /* NO EXPLICIT-DARK BLOCK, DELIBERATELY. Dark is the ROOT default now, so `data-bs-theme="dark"` needs no declaration of its own -- it already gets exactly the root palette. The block that used to sit here re-declared the whole dark set, and after the dark-first flip it still carried the PRE-FLIP values (`--zt-brand: #b79bd6` as a SURFACE colour), so TheAdmin's dark toggle would have silently reintroduced the one-token-two-jobs bug this flip exists to end. A second declaration of a default is drift surface with no upside. */ /* โ”€โ”€ THE BUTTON BRIDGE โ€” the half `--bs-primary` CANNOT reach โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ */ /* ๐Ÿ”ด RE-POINTING `--bs-primary` DOES NOT RESTYLE A SINGLE BUTTON, AND THE PALETTE BRIDGE ABOVE LOOKS LIKE IT SHOULD. Bootstrap 5.3 compiles each button variant to its own LOCAL custom properties with LITERAL colours baked in โ€” `.btn-primary { --bs-btn-bg: #0d6efd; --bs-btn-hover-bg: #0b5ed7; โ€ฆ }` โ€” and `.btn` then reads only those locals. `--bs-primary` is never consulted at render time, so a correct, live, verified palette bridge leaves every primary button Bootstrap blue. โš ๏ธ THE SAME SILENT-AND-FLATTERING FAILURE AS THE `:root:root` ONE ABOVE, one layer in: checking `--bs-primary` computes to the brand returns YES, and the button beside it is still blue. The bridged NAME was right and the name that DRAWS was a different one. Check the rendered control, not the variable it ought to be reading. DOUBLED CLASS (`.btn-primary.btn-primary`) for the same reason `:root:root` is doubled โ€” Bootstrap declares these at single-class specificity and loads later, so source order wins unless specificity beats it. */ .btn-primary.btn-primary { --bs-btn-color: #ffffff; --bs-btn-bg: var(--ztc-brand); --bs-btn-border-color: var(--ztc-brand); --bs-btn-hover-color: #ffffff; --bs-btn-hover-bg: var(--ztc-brand-bright); --bs-btn-hover-border-color: var(--ztc-brand-bright); --bs-btn-active-color: #ffffff; --bs-btn-active-bg: var(--ztc-brand-bright); --bs-btn-active-border-color: var(--ztc-brand-bright); --bs-btn-disabled-color: #ffffff; --bs-btn-disabled-bg: var(--ztc-brand); --bs-btn-disabled-border-color: var(--ztc-brand); --bs-btn-focus-shadow-rgb: var(--ztc-brand-rgb); } .btn-outline-primary.btn-outline-primary { --bs-btn-color: var(--ztc-brand); --bs-btn-border-color: var(--ztc-brand); --bs-btn-hover-color: #ffffff; --bs-btn-hover-bg: var(--ztc-brand); --bs-btn-hover-border-color: var(--ztc-brand); --bs-btn-active-color: #ffffff; --bs-btn-active-bg: var(--ztc-brand); --bs-btn-active-border-color: var(--ztc-brand); --bs-btn-disabled-color: var(--ztc-brand); --bs-btn-disabled-border-color: var(--ztc-brand); --bs-btn-focus-shadow-rgb: var(--ztc-brand-rgb); } /* NO PER-SCHEME BUTTON INK OVERRIDE, AND THAT IS A RESULT OF THE TWO-VALUE BRAND RATHER THAN AN OMISSION. `--ztc-brand` is a SURFACE colour in both schemes -- #5b3e78 dark, #472c54 light -- and both are deep enough to carry white. The overrides that used to sit here set the ink to `--ztc-surface` (i.e. DARK ink) because the old dark brand was the LIFTED #b79bd6, which white could not sit on. Splitting surface-brand from text-brand removed the need for the override entirely; leaving it would now paint dark ink on a deep purple button. */ /* โ”€โ”€ header (the shared ZiltchChromeView brand bar) โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ */ /* THE HEADER'S HEIGHT IS A TOKEN, NOT AN EMERGENT NUMBER โ€” and it is declared here because a SECOND surface has to agree with it. The admin Layout offsets TheAdmin's `position:fixed` sidebar below this bar, so the offset and the bar's real height must match; on 2026-07-29 they did not. The offset read `var(--zt-header-h, 3.5rem)` = 56px against a bar that measured 59px, so the sidebar sat 3px UNDER the header. The fallback was a guess and the token was never defined, which means the guess was always what ran. Defining it here and driving `min-height` FROM it makes the two agree BY CONSTRUCTION: whoever restyles the bar changes one number and the sidebar follows, instead of the sidebar silently overlapping. In rem, so both move together if the root font-size changes. */ :root { --zt-header-h: 3.7rem; } /* โœ’๏ธ THE TYPE SCALE โ€” SIX STEPS, AND THE PRODUCT CURRENTLY HAS 48. Measured 2026-09-12 across the served tree: 48 distinct font sizes in 934 literal declarations, thirteen of them between 0.6rem and 0.875rem. 0.8 against 0.8125 is a 0.2 PIXEL difference and 0.8 against 0.82 is 0.32px โ€” nobody can see either, so those values encode no design intent. They are different authors typing different numbers into the same visual slot, which is what a design system looks like when it is a folder rather than a decision. THE FLOOR IS 11px AND IT IS A CRAFT BAR, NOT A CONFORMANCE ONE โ€” say so rather than borrowing authority: WCAG sets NO minimum font size (1.4.4 asks only that text scale to 200%, which 8px text does). The reason it is worth a floor anyway is the inverse of conformance โ€” no checker will ever flag a product that renders its own explanations at a size most people cannot read, and 241 declarations in this tree sit at or below 10px. Steps are spaced so ADJACENT ONES ARE TELLABLE APART (>=2px at the small end, where confusion actually happens). Sizes are on a 16px root; each is a clean pixel value so nothing lands on a half-pixel and blurs. */ :root { --zt-text-xs: 0.6875rem; /* 11px โ€” the FLOOR. Badges, micro-labels, timestamps. Nothing smaller ships. */ --zt-text-sm: 0.8125rem; /* 13px โ€” secondary text: meta lines, captions, dense table cells. */ --zt-text-base: 0.9375rem; /* 15px โ€” body. The default reading size for prose and controls. */ --zt-text-lg: 1.125rem; /* 18px โ€” subheads, card titles, the emphasis step above body. */ --zt-text-xl: 1.5rem; /* 24px โ€” section headings. */ --zt-text-2xl: 2rem; /* 32px โ€” page titles. */ } .ziltch-header { border-bottom: 1px solid var(--zt-grid); min-height: var(--zt-header-h); background: color-mix(in srgb, var(--zt-bg) 78%, transparent); backdrop-filter: blur(14px) saturate(1.3); -webkit-backdrop-filter: blur(14px) saturate(1.3); position: sticky; top: 0; z-index: 100; box-shadow: 0 1px 0 color-mix(in srgb, var(--zt-accent) 12%, transparent); } .ziltch-header .navbar { padding-top: .55rem; padding-bottom: .55rem; } .ziltch-header .navbar-brand { font-weight: 800; letter-spacing: .3px; color: var(--zt-fg); display: inline-flex; align-items: center; gap: .5rem; transition: color .14s; } /* Bootstrap's default .navbar-brand:hover sets --bs-navbar-brand-hover-color (a dark stroke) โ€” which reads BLACK on the dark chrome (Erin 2026-07-17). Override with an on-brand amber rollover, matching the app-nav hover below. */ .ziltch-header .navbar-brand:hover, .ziltch-header .navbar-brand:focus { color: var(--zt-accent); } .ziltch-logo { height: 26px; width: 26px; border-radius: 7px; vertical-align: middle; box-shadow: 0 0 0 1px color-mix(in srgb, var(--zt-accent) 30%, transparent), 0 2px 10px color-mix(in srgb, var(--zt-accent) 22%, transparent); } /* โ”€โ”€ the account cluster (user label ยท admin/site switch ยท sign-out ยท signed-out CTAs) โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ TOKEN-DRIVEN ON PURPOSE. These controls used Bootstrap's `text-light` / `btn-outline-light` / `btn-light`, which are FIXED near-white (#f8f9fa) and silently assume the bar behind them is DARK. The site's front door IS dark, so that held there by accident โ€” and the moment the SAME component rendered on the admin surface, where these tokens resolve LIGHT by default (--zt-surface: #fff), the entire cluster became white-on-white and VANISHED. Measured live before the fix: headerBg `srgb 1 1 1 / .78`, text `rgb(248,249,250)`. Reading --zt-fg / --zt-accent instead means the prefers-color-scheme block already flips them, so ONE definition is legible on BOTH surfaces in BOTH schemes rather than one surface being correct by luck. */ .ziltch-header .zt-chrome-user { color: var(--zt-muted); } /* ๐Ÿ‘† 44px MINIMUM TOUCH TARGET (WCAG 2.5.5 / Apple HIG), MEASURED NOT ASSUMED. At 390x780 on the live anonymous front door, 2026-09-12, EVERY interactive element in this chrome was under it: Ziltch brand lockup 92 x 41 3px short on height Toggle navigation 48 x 40 4px short on height site nav "Home" 43 x 21 23px short (fixed separately in the theme's own layout) Three of three. Nothing here is dramatically wrong โ€” 40 and 41 against 44 โ€” which is exactly why it survived: a 4px miss looks fine and fails the same standard a 24px miss does. min-height rather than padding so the fix cannot be undone by a font-size change, and inline-flex + center so the existing label stays optically centred as the box grows. Width is handled by the rule below. */ .ziltch-header .zt-chrome-btn, .ziltch-header .navbar-toggler, .ziltch-header .navbar-brand { min-height: 44px; display: inline-flex; align-items: center; } /* min-WIDTH as well, and the first pass forgot it: with min-height alone the theme toggle went 30x31 to 30x44 โ€” tall enough and still 14px too NARROW, because it is a single-glyph button and its width comes from one character. Caught by re-measuring after the fix rather than by assuming height was the only axis that was short. The brand needs no min-width (92px). */ .ziltch-header .zt-chrome-btn, .ziltch-header .navbar-toggler { min-width: 44px; justify-content: center; } .ziltch-header .zt-chrome-btn { color: var(--zt-fg); border: 1px solid var(--zt-grid); background: transparent; font-weight: 600; letter-spacing: .01em; transition: color .14s, border-color .14s, background .14s; } /* THE HOVER TINTS AND BORDERS IN ACCENT; THE INK STAYS READABLE. `color: var(--zt-accent)` on the 10% accent tint reads 2.38:1 IN LIGHT (#c79a3a on #f9f5eb) against the 4.5 of WCAG 1.4.3 โ€” dark is fine at 9.50:1, so this is the MIRROR of tonight's other contrast defects, which all failed in dark and passed in light. Either arm alone would have missed one of them. --zt-ink clears both (dark 12.42:1, light 14.38:1) and the affordance is untouched: the tinted ground and the accent border still change on hover, which is where an accent belongs. โš ๏ธ COMPUTED, NOT PROBED, AND THE ASSUMPTION IS STATED: this background is 10% accent over a header that is itself `color-mix(var(--zt-bg) 78%, transparent)` with a backdrop-filter, so its true ground is whatever is behind the sticky header. The number above assumes the ordinary case โ€” the header over the plain page ground, which is every page but the front door. On the front door the header sits over the fixed hero, so the real ratio there is a RANGE over scroll position, not a value, and only pixel sampling settles it. The static probe correctly REFUSES to score this rule; it is here because the light arm fails even in the friendliest case, and a defect that fails its own best case needs no worst case. */ .ziltch-header .zt-chrome-btn:hover, .ziltch-header .zt-chrome-btn:focus { color: var(--zt-ink); border-color: color-mix(in srgb, var(--zt-accent) 60%, transparent); background: color-mix(in srgb, var(--zt-accent) 10%, transparent); } /* SaaS-app markets nav โ€” the live trading/AI surfaces, inline in the header chrome (same set as the app shell). */ .ziltch-app-nav { flex-direction: row; gap: .15rem; margin-left: 1.25rem; } .ziltch-app-nav .nav-link { font-size: .84rem; font-weight: 500; color: var(--zt-muted); letter-spacing: .01em; padding: .3rem .7rem; border-radius: var(--zt-radius); transition: background .14s, color .14s; } .ziltch-app-nav .nav-link:hover { color: var(--zt-fg); background: color-mix(in srgb, var(--zt-accent) 12%, transparent); } .ziltch-app-nav .nav-link.active { color: var(--zt-accent); } /* Mobile collapse (below .navbar-expand-md) โ€” the toggler folds the nav; on-brand focus ring, dark-mode aware icon. */ .ziltch-header .navbar-toggler { border-color: var(--zt-line); padding: .25rem .5rem; } .ziltch-header .navbar-toggler:focus { box-shadow: 0 0 0 .2rem var(--zt-brand-tint); } @media (prefers-color-scheme: dark) { /* Bootstrap's default toggler icon is a dark stroke โ€” invert it so it reads on the dark chrome. */ .ziltch-header .navbar-toggler-icon { background-image: url("data:image/svg+xml,%3csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 30 30'%3e%3cpath stroke='rgba(219,228,245,0.85)' stroke-linecap='round' stroke-miterlimit='10' stroke-width='2' d='M4 7h22M4 15h22M4 23h22'/%3e%3c/svg%3e"); } } @media (max-width: 767.98px) { .ziltch-header .navbar-collapse { padding-top: .5rem; } .ziltch-app-nav { flex-direction: column; gap: .1rem; margin-left: 0; margin-top: .35rem; } .ziltch-gateway-badge { margin-left: 0 !important; margin-top: .5rem; align-self: flex-start; } } /* โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ STICKY FOOTER โ€” the footer sits at the BOTTOM OF THE VIEWPORT when the page is short, instead of riding up under the header. Erin 2026-08-07: "I see header and footer squished together. should be footer cannot scroll upward past bottom of page." WHY IT LOOKED LIKE A SQUEEZE: nothing in this file set html/body/main/footer layout at all, so a short page (the site home is ~5.7 KB of markup) let the footer follow the content directly โ€” header, one screen of nothing, footer, all stacked in the top few hundred pixels. It is not a spacing bug; there was no layout claiming the viewport height. THE MECHANISM: body becomes a flex COLUMN of at least one viewport tall, and the content region takes the slack (`flex: 1 0 auto`). `margin-top: auto` on the footer is deliberately kept as well โ€” it is what pins the footer down if a page ever renders a content region this file does not know about, so the rule degrades to "footer at the bottom" rather than "footer under the header". โš ๏ธ THIS FILE IS THE SHARED CHROME AND THE RULE IS DELIBERATELY WRITTEN TO BE SHARED. Both theme Layouts load it, and the site and admin content regions have DIFFERENT class names, so all three are listed rather than styling one and letting the other drift โ€” that split is exactly what this file exists to prevent. `min-height: 100dvh` handles mobile browser chrome; the `100vh` declaration before it is the fallback for engines without dvh. */ html { min-height: 100%; } body { display: flex; flex-direction: column; min-height: 100vh; min-height: 100dvh; } body > main, .ziltch-site-main, .ziltch-admin-shell { flex: 1 0 auto; } /* THE FOOTER'S HEIGHT IS A TOKEN FOR THE SAME REASON THE HEADER'S IS: A SECOND SURFACE HAS TO AGREE WITH IT. Erin 2026-08-07: "the unauth bg image is cut off at the bottom of the page by the footer at full screen... any way to align the bottom with the top of the footer bar?" The front-door backdrop is `position: fixed; inset: 0`, so it spans the WHOLE viewport and the footer bar sits on top of its bottom edge โ€” the image does not end at the footer, it continues behind it. Ending it at the footer means insetting its bottom by exactly the footer's height, and that number has to come from somewhere. ๐Ÿ”‘ 3.5rem is a MEASUREMENT ROUNDED UP, NOT A GUESS โ€” the footer rendered 55px (3.44rem) live. Rounding UP is what makes the token AUTHORITATIVE rather than descriptive: min-height now governs, so the bar is exactly --zt-footer-h and the backdrop's inset cannot disagree with it. Had I rounded down, content would set the height and the token would silently be wrong by the difference. โš ๏ธ THE HEADER LEARNED THIS THE EXPENSIVE WAY AND THE LESSON IS ONE BLOCK UP: its offset read `var(--zt-header-h, 3.5rem)` against a bar that measured 59px, because the token was never defined and the FALLBACK was always what ran. A fallback for a token nobody declares is just a guess with extra syntax. Residual, stated: if footer content ever exceeds the token (a wrap on a very narrow viewport), the bar grows and the backdrop stops short by the difference. min-height cannot prevent that; only a fixed height could, and that would clip the content instead. Growing is the safer failure. */ :root { --zt-footer-h: 3.5rem; } .ziltch-footer { flex-shrink: 0; margin-top: auto; min-height: var(--zt-footer-h); } /* โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ• ZILTCH ADMIN SHELL โ€” the operator surface, styled on the SAME tokens as the site. Erin 2026-08-07: "admin left nav is not styled correctly โ€” I assume these are the missing admin theme styles โ€” ziltch styling needs to be completed." ๐Ÿ”‘ THE CAUSE WAS NOT MISSING STYLESHEETS, IT WAS MISMATCHED SELECTORS. TheAdmin's CSS loads (verified live) but targets ITS OWN structure โ€” `#ta-left-sidebar`, `.ta-navbar-top`, `.ta-content`. The combined theme renders `.ziltch-admin-shell` / `.ziltch-admin-nav` / `.ziltch-admin-main`, so none of TheAdmin's rules could ever apply. Borrowing a stylesheet gets you its VARIABLES; it does not get you its LAYOUT unless you also adopt its class names โ€” and adopting them would make the admin permanently TheAdmin-shaped, which is the opposite of one body. โ‡’ so the admin gets ZILTCH styling, built entirely from the token layer: same palette, same type scale, same spacing rhythm, same radius as the site. That is what "style them together as one body" means concretely โ€” not two stylesheets that agree, ONE set of tokens that both surfaces spend. โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ• */ /* ๐Ÿ”ด NO PAGE MARGIN AROUND THE NAV (Erin 2026-08-07: "should not have page margins around it"). The shell used to pad all FOUR sides, which inset the rail from the viewport edge and left a strip of page showing down its left โ€” so the sidebar read as a floating card parked near the edge rather than as part of the window's frame. Padding is now the CONTENT's, not the SHELL's: the rail runs flush to the edge and `.ziltch-admin-main` carries its own breathing room. `gap` goes too, for the same reason โ€” the separation between rail and content is the rail's BORDER, not empty page. */ .ziltch-admin-shell { display: grid; grid-template-columns: minmax(13rem, 16rem) 1fr; align-items: stretch; /* was `start` โ€” with no padding the rail should reach the full height, not float */ gap: 0; padding: 0; max-width: 100%; } /* A FLUSH RAIL, NOT A CARD. The radius, drop shadow and all-round border were what MADE it look like a card sitting on a page โ€” removing the shell's padding alone would have left a rounded card jammed into the corner, which is worse than the inset version. A rail keeps ONE border (the edge it shares with the content) and drops the rest. */ .ziltch-admin-nav { position: sticky; top: 0; display: flex; flex-direction: column; gap: var(--zt-space-1); padding: var(--zt-space-3) var(--zt-space-2); background: var(--zt-surface-2); border: 0; border-right: 1px solid var(--zt-line); border-radius: 0; box-shadow: none; /* Full viewport height minus the chrome bar above it, so the rail's surface reaches the bottom of the window instead of ending where its items do. --zt-header-h is the shared token the header drives its own height from, so these cannot disagree. */ min-height: calc(100dvh - var(--zt-header-h)); max-height: calc(100dvh - var(--zt-header-h)); overflow-y: auto; } /* OC's Menu shape renders