/* GENERATED from lib/brand/steel.css — edit THERE, then run: node field-portal/build-brand.mjs */ /* steel.css — the Clean Steel standard: KSG's ratified design language as importable tokens + recipes. SPEC: docs/DESIGN.md + the living mockups docs/design/clean-steel-sidebyside.html (structure + both token sets, extracted verbatim) and docs/design/clean-steel-accents.html (the accent audition). When this file and those mockups disagree, the mockups win. TWO SIBLING MODES, ONE TOKEN SET: every color lives in html[data-theme="dark"] / html[data-theme="light"]. A page that sets NO data-theme gets dark (:root falls back to the dark set) — today's behavior, unchanged, so nothing live shifts until a surface explicitly opts in. The toggle flips data-theme only — never a second stylesheet, never a layout change (DESIGN.md "Two sibling modes"). SOFT FURNITURE, HARD EQUIPMENT: `.card` is the soft surface (10px radius, line border, a faint shadow — the ONE permitted depth cue). The safety `.tag`, status `.st` chips, the `.cb` checkbox, and the KEYO block label stay SQUARED (border-radius:0) even inside the soft world — they read as equipment, not software. `.tag` itself sits OUTSIDE the card system entirely, on the ground, in every consumer. TYPE: condensed stencil caps (.cond) live ONLY in the load-bearing skeleton — the stripe wordmark, .secbar titles, .nav labels, the tag header, the KEYO block label, and the sparing .edge line. Body/buttons/labels are calm, normal-weight system sans. Monospace tabular numerals (.mono) stay everywhere, unchanged. NEVER A FILL (DESIGN.md "Key Maroon"): --maroon and --amber are BORDER/TEXT colors on interactive controls (.btn.primary, .nav a.on, .st.wait) — never background:var(--maroon)/var(--amber) outside the fleet's own named exceptions (.stripe, .tag .head, .keyo .k, .prog i, .cb.done). --amber2 is the secondary amber tone (text accents only, e.g. a machine-unit number) — two portals had already independently minted this exact value under a page-local --accent2 name before it was promoted here (ui/clean-steel-accent- foundation, 2026-07-30); rename a portal-local equivalent to var(--amber2) rather than keeping its own copy. lib/brand/no-fill-guard.mjs is the reusable test a migrated portal's OWN suite adopts to enforce this. ⚠ TWO MAROONS, AND THEY ARE NOT INTERCHANGEABLE (red team 2026-08-03, pilot-blocking): --maroon #6f1d27 in BOTH modes — the FILL/identity maroon. Correct only where it is a BACKGROUND carrying light text (.stripe, .keyo .k) or where the ground is light. --maroon-ink the maroon used as TEXT or as a BORDER. Per-mode, exactly like --amber2: #6f1d27 in light (unchanged), #d98891 in dark. WHY: --maroon was chosen against the LIGHT ground and copied verbatim into the dark token set, where #6f1d27 on --panel #323237 is 1.14:1 — WCAG AA wants 4.5:1. mechanic-portal's ONLY sign-in button ('Text me a code') is a .btn.primary, so on a dark-mode iPad the pilot's first screen had a phone field and an invisible button. The active-tab underline (.nav a.on) had the identical 1.14:1 problem. The fix is a second TONE, never a fill — filling the button would break the rule above. lib/brand/contrast-guard.mjs is the sibling guard that fails CI when any token pair drops below its minimum in EITHER mode, so this class of bug cannot come back silently. ONE STRIPE COLOR PER APP (David, ratified 2026-09-14 — docs/DESIGN.md "App colors"). The stripe is no longer maroon-by-definition: it paints --app, and each app sets --app / --app-ink / --app-cur / --app-line to its ratified pair. The defaults below are Field's (maroon + the warm white ink the stripe has always used), so a surface that sets nothing renders exactly as it does today. Inside an app the one-painted- accent-per-screen rule is unchanged — the stripe is that accent. --app the painted stripe FILL. Its role is a background under --app-ink; it is NOT a line or text tone, exactly as --maroon is not --maroon-ink. Never paint it anywhere but the stripe. --app-ink the ink ON the stripe (wordmark, tabs, chips). --app-cur the current-tab pill behind .stripe .tabs .cur. It defaults to var(--app-ink) and the current tab INVERTS onto it — the pill is the ink, the text is the stripe. That is not a style preference, it is the only form that is correct for both families: a translucent white pill lightens the very ground its own white text sits on (measured on the ratified Safety green: white on a .22 white pill is 3.49:1, and light mode could afford at most alpha .08 — not a highlight, a rumour), while an opaque NEAR-white pill would put yellow text on white for Equipment. Inverting makes the pair --app on --app-ink, which is the SAME ratio the guard already enforces as --app-ink on --app: correct for all nine apps, for free, guaranteed by an assertion that already exists. A portal overrides it only to soften the pill, never to make it translucent. --app-line the app color as a 3px LINE on --navbg (the phone bottom nav's current item). A SEPARATE tone for the same reason --maroon-ink exists: measured against --navbg, every one of the nine ratified stripe colors fails WCAG 1.4.11 (3.0:1) in one of the two modes — Field's own #6f1d27 is 1.39:1 on the dark nav, the identical 2026-08-03 bug. It defaults to var(--maroon-ink), so .nav a.on is unchanged today. Copy into a portal's public/ via its build-brand.mjs (the house pattern). Shares variable names with the retired light lib/brand/theme.css ON PURPOSE (historical) — a surface imports steel.css alone, never both. */ :root, html[data-theme="dark"] { --bg:#2a2a2e; --panel:#323237; --sechead:#2e2e33; --line:#46464d; --hair:#3b3b41; --maroon:#6f1d27; --maroon-ink:#d98891; --ink:#dcdad5; --muted:#a09e97; --dim:#7b796f; --ok:#5aa47b; --red:#c44a41; --amber:#cf9245; --amber2:#E9B45A; --ok-ink:#6cbb8f; --red-ink:#e8807a; /* the TEXT/BORDER tones of ok+red — see the two-maroons note above */ /* the app stripe (ratified 2026-09-14) — defaults are FIELD's, so an un-adopted surface is unchanged */ --app:#6f1d27; --app-ink:#f2e9e9; --app-cur:var(--app-ink); --app-line:var(--maroon-ink); /* the safety tag's danger red — its OWN token, never --red and never maroon: Field's stripe IS maroon, so a tag that reads maroon-adjacent no longer reads as danger. Paired ink, because #FF6B6B carries dark ink (5.58:1) and drowns white (2.54:1). */ --danger-tag:#FF6B6B; --danger-tag-ink:#1C2530; --tagbg:#332a2a; --tagrule:#5c4340; --progtrack:#4a4a50; --btnline:#6e6e75; --navbg:#242428; --shadow:0 1px 2px rgba(0,0,0,.25), 0 3px 10px rgba(0,0,0,.18); --hover:#383840; /* pointer-hover surface for desktop Steel pages (one shared hover gray — don't mint per-surface) */ } html[data-theme="light"] { --bg:#EEF1F4; --panel:#FBFCFD; --sechead:#F3F5F8; --line:#D4DAE0; --hair:#E4E8ED; --maroon:#6f1d27; --maroon-ink:#6f1d27; --ink:#1C2530; --muted:#5A6675; --dim:#8A93A0; --ok:#2E8B57; --red:#B23B3B; --amber:#C77F22; --amber2:#A8651A; /* --ok-ink is DARKER than --ok here: --ok #2E8B57 is only 3.74:1 on --bg, so the light mode had its own (smaller, un-reported) version of the same bug. --red-ink keeps --red's value — that one already passed. */ --ok-ink:#277A4C; --red-ink:#B23B3B; --app:#6f1d27; --app-ink:#f2e9e9; --app-cur:var(--app-ink); --app-line:var(--maroon-ink); --danger-tag:#C1121F; --danger-tag-ink:#fbf3f2; --tagbg:#FDF6F5; --tagrule:#D9B8B4; --progtrack:#E0E4E9; --btnline:#B8C0C9; --navbg:#FBFCFD; --shadow:0 1px 2px rgba(20,30,45,.06), 0 2px 8px rgba(20,30,45,.05); --hover:#EDF0F3; } :root{ --sans:-apple-system,"SF Pro Text","Segoe UI",Roboto,sans-serif; --steel-cond:"Arial Narrow",sans-serif; --steel-mono:"SF Mono",Consolas,monospace; } body.steel{margin:0;background:var(--bg);color:var(--ink);font-family:var(--sans);} /* THE hidden ATTRIBUTE MEANS HIDDEN (David's ruling, 2026-09-21). The browser's own [hidden]{display:none} is a USER-AGENT rule with no specificity, so ANY author rule that sets display beats it — and then an element is hidden and drawn at the same time. That killed the CM Desk: