/* ═══════════════════════════════════════════════════════════════════════════ pos-r3-tokens.css — the vocabulary the M-EasyDo R3 design language needs, restated for M-EasyPOS. ── What this file is ─────────────────────────────────────────────────────── M-EasyDo AI+ Round 3 rebuilt its interface around a top bar, a sub-nav strip, a command palette and a considered type/geometry/elevation scale. That work lives in M-EasyDo-AI/public/css/r2-tokens.css §R3.1–§R3.30. This platform is adopting the LANGUAGE — the scale, the geometry, the shell, the component treatments — and it is adopting it onto its OWN colours. Three files, loaded in this order and inlined in that order by src/utils/layout.js: modus-design-system.css the ecosystem master. NOT OURS TO EDIT (md5 90709d5c; a per-repo edit is a defect) pos-r3-tokens.css this file — names, no components pos-r3-surface.css page furniture: headers, cards, KPIs, tables, forms, badges, empty/loading/error, modals pos-r3-shell.css the chrome: top bar, sub-nav, mobile nav, command palette, popovers ── THE COLOUR RULING ─────────────────────────────────────────────────────── The instruction for this integration was explicit: take the UI/UX, DO NOT take the colour theme. So: · --accent stays #BE185D, from the master's [data-platform="pos"] block. Not one rule in these three files declares an accent of its own. · M-EasyDo's #1a73e8 appears NOWHERE. pos-r3-contract.js fails the build on the literal in any of these files. · M-EasyDo's SIX BUSINESS-AREA HUES ARE NOT PORTED, and their absence is a decision rather than an omission. §R3.1 gives each of M-EasyDo's areas its own derived hue — indigo for CRM, magenta for Marketing — and that is a palette. Importing it would be importing the colour theme under a different name. The consequence, stated so nobody re-adds it by reflex: M-EasyPOS's seven nav areas are told apart by POSITION AND WORD, not by colour. Every rule that reads --r3-area in M-EasyDo reads var(--accent) here. There is no [data-area] attribute in this platform, because a switch that rebinds one value to itself is a dead control wearing a mechanism's clothes. ── What is NOT redefined here ────────────────────────────────────────────── --r-sm / --r / --r-lg, --motion-fast / --motion-base, --ease-out, --surface, --surface-2, --border, --border-2, --text, --muted, --shadow-lg and the status hues all come from the master and are used as-is. A token this file names is a token the master does not carry. ═══════════════════════════════════════════════════════════════════════════ */ :root { /* ── TYPE SCALE (M-EasyDo §R3.2) ──────────────────────────────────────── Adopted verbatim, because a type scale is not a colour and this one was already reasoned about: weights are deliberately heavy at the small end, since 12px/500 is legible metadata and 12px/400 is a smudge. There is no 300 weight anywhere in this product. */ --t-page: 1.875rem; /* 30px page title */ --t-section: 1.3125rem; /* 21px section title */ --t-card: 0.96875rem; /* 15.5px card title */ --t-body: 0.90625rem; /* 14.5px body */ --t-second: 0.84375rem; /* 13.5px secondary */ --t-meta: 0.75rem; /* 12px metadata */ --t-kpi: 2.125rem; /* 34px KPI figure */ --t-kpi-sm: 1.75rem; /* 28px KPI in a dense grid */ --w-page: 700; --w-section: 680; --w-card: 600; --w-meta: 500; /* ── GEOMETRY (§R3.3) ─────────────────────────────────────────────────── These NAME the master's radius ladder rather than replacing it, so a rule can say what it is doing instead of picking a number. A pill is deliberately absent: a pill means a status, a tag or a filter, and those have their own classes. */ --r3-control: var(--r-sm); /* buttons, inputs */ --r3-panel: var(--r); /* cards, tables */ --r3-feature: var(--r-lg); /* AI panels, modals */ --r3-rail: 3px; /* the section rail */ /* Bar heights. Referenced by the sticky offsets in pos-r3-shell.css AND by the scroll-margin on anchor targets, so they are named once. */ --r3-nav-h: 56px; --r3-subnav-h: 46px; /* ── ELEVATION (§R3.5) ────────────────────────────────────────────────── "Borders more than shadows." Only things that FLOAT above the page get a shadow, and this is the entire list — named so that a review can check a list rather than argue about taste. */ --r3-float: var(--shadow-lg); /* dropdown, popover, command palette */ --r3-sheet: var(--shadow-lg); /* modal, mobile sheet */ /* ── GLASS ────────────────────────────────────────────────────────────── M-EasyDo's --r2-* glass pair, restated because this repo has no r2 layer. The flat fallback is the FIRST declaration, so a browser without color-mix gets a solid bar rather than an unreadable transparent one. Floating chrome may blur; a content card may not. */ --r3-glass-blur: 14px; --r3-glass-bg: var(--surface); --r3-glass-bg: color-mix(in srgb, var(--surface) 72%, transparent); /* ── THE AI SURFACE (§R3.4, re-derived) ───────────────────────────────── M-EasyDo tints its AI layer violet. That is its palette, so it does not come across. This platform's AI surface is its OWN accent at low alpha — which is also what the existing copilot panel in layout.js already does, so the assistant and the AI regions on the page finally agree. One tint, one edge, one gradient. No glow on a card, no neon, no animated border: it is a layer OF the product, not a toy bolted to it. */ --r3-ai-tint: var(--accent-bg); --r3-ai-tint: color-mix(in srgb, var(--accent) 7%, transparent); --r3-ai-edge: var(--accent-glow); --r3-ai-edge: color-mix(in srgb, var(--accent) 34%, transparent); --r3-ai-grad: linear-gradient(135deg, var(--accent), color-mix(in srgb, var(--accent) 72%, var(--accent-2) 28%)); /* ── SPACING RHYTHM ───────────────────────────────────────────────────── An 8-based ladder, named. Every gap, pad and margin in the two component files resolves to one of these six values; a raw px gap in those files is a defect the contract test looks for. */ --sp-1: 4px; --sp-2: 8px; --sp-3: 12px; --sp-4: 16px; --sp-5: 24px; --sp-6: 32px; } /* Dark correction. The master already corrects its own *-text tokens for dark, and the mixes above are built FROM master tokens, so they inherit it. This block exists only for the tints: on a dark ground a 7% tint of a mid hue is close to invisible, so it is opened up. */ [data-theme="dark"] { --r3-ai-tint: color-mix(in srgb, var(--accent) 16%, transparent); --r3-ai-edge: color-mix(in srgb, var(--accent) 46%, transparent); --r3-glass-bg: var(--surface); --r3-glass-bg: color-mix(in srgb, var(--surface) 78%, transparent); } /* ═══════════════════════════════════════════════════════════════════════════ T2 — THE SEMANTIC RAMP ─────────────────────────────────────────────────────────────────────────── WHY THIS EXISTS. Round 2's critic measured 41 text pairs below 4.5:1 across this product, in one theme or both, and every one of them had the same cause: a route file naming a raw hue in an inline style. A hex in a style attribute cannot be corrected by a theme, so #16a34a stayed #16a34a on a white card AND on a slate one, and #6b7280 body copy sat at 3.03:1 on a dark card. The worst pair measured 1.23:1 — --text on a hardcoded #fff panel, which is invisible rather than merely hard to read. So the fix is a vocabulary, not a patch: five semantic foregrounds, five matching tints, five matching edges, each with its OWN light and dark value, and the route files point at those instead of at hues. ── HOW THE VALUES WERE PICKED ────────────────────────────────────────────── Not by eye. The light foregrounds are the master's own Run 54 *-text tokens, which were already derived against a 4.5:1 floor. The dark ones are those tokens walked toward white by the smallest whole percentage that clears 4.5:1 on ALL THREE dark grounds — --bg #0f172a, --surface #1e293b and --surface-2 #263348, the last being the table hover row — and on the token's own tint. The tints are DELIBERATELY OPAQUE rather than an alpha over the page. An alpha tint's contrast depends on what happens to be behind it, so the same chip measures 4.63:1 on a card and 4.05:1 on a hovered table row; an opaque tint measures the same everywhere and can therefore be stated. Every ratio below was computed from the sRGB relative-luminance formula, not estimated. Light tint = hue at 9% over white; dark tint = hue at 22% over black. TOKEN LIGHT on --bg / --surface / --surface-2 / own tint --pos-success #117b38 5.09 5.37 5.00 4.87 --pos-warning #a25904 5.02 5.29 4.93 4.68 --pos-danger #d41212 5.12 5.39 5.02 4.66 --pos-info #7c3aed 5.41 5.70 5.31 4.98 --pos-neutral #5a6d87 5.02 5.29 4.93 4.89 TOKEN DARK on --bg / --surface / --surface-2 / own tint --pos-success #21b357 6.50 5.33 4.64 6.04 --pos-warning #e8820b 6.49 5.31 4.63 6.49 --pos-danger #f37676 6.52 5.34 4.65 6.72 --pos-info #b088f4 6.52 5.35 4.65 6.65 --pos-neutral #919eb0 6.56 5.38 4.68 5.80 The floor across all forty pairs is 4.63:1. The bar was a flat 4.5:1 in both themes with no large-text exemption taken, so a 34px KPI figure clears it on the same terms as 12px metadata. ── WHY THERE IS NO BLUE IN THIS RAMP ─────────────────────────────────────── "Info" is VIOLET here, not blue. The critic found /orders rendering its .stat-value in rgb(26,115,232) — M-EasyDo's accent, arriving through var(--blue), which is that literal in the master's :root. That is the one colour this integration is forbidden to carry, and a second blue standing next to where it used to be would read as the same import surviving a rename. --purple is the master's own status hue, it is already on the page as .badge-purple, and it sits 71 degrees of hue from the accent rose, so the two do not read alike. The accent itself is available as a foreground under the master's own name, var(--accent-text): #A21550 light (7.09:1 worst ground) and #f082b3 dark (5.18:1 worst ground). It is the right colour for a state that belongs to THIS product rather than to a universal success/failure vocabulary. ═══════════════════════════════════════════════════════════════════════════ */ :root { --pos-success: var(--green-text); --pos-warning: var(--amber-text); --pos-danger: var(--red-text); --pos-info: var(--purple-text); --pos-neutral: var(--muted); /* Flat fallback first for a browser with no color-mix: the master's own 8% alpha tints. They are half a point short on a hovered dark row and they are still legible, which is the right shape for a fallback. */ --pos-success-bg: var(--green-bg); --pos-warning-bg: var(--amber-bg); --pos-danger-bg: var(--red-bg); --pos-info-bg: var(--purple-bg); --pos-neutral-bg: var(--surface-2); --pos-success-bg: color-mix(in srgb, var(--green) 9%, #fff); --pos-warning-bg: color-mix(in srgb, var(--amber) 9%, #fff); --pos-danger-bg: color-mix(in srgb, var(--red) 9%, #fff); --pos-info-bg: color-mix(in srgb, var(--purple) 9%, #fff); /* Edges are an alpha of the hue on purpose: a border is not text, it has no ratio to meet, and an alpha edge sits correctly on a tint AND on a card. */ --pos-success-edge: var(--border); --pos-warning-edge: var(--border); --pos-danger-edge: var(--border); --pos-info-edge: var(--border); --pos-neutral-edge: var(--border); --pos-success-edge: color-mix(in srgb, var(--green) 34%, transparent); --pos-warning-edge: color-mix(in srgb, var(--amber) 34%, transparent); --pos-danger-edge: color-mix(in srgb, var(--red) 34%, transparent); --pos-info-edge: color-mix(in srgb, var(--purple) 34%, transparent); /* ── THE COMMERCE-ERA ALIASES ───────────────────────────────────────────── THESE ARE NOT NEW NAMES. --gray-400 is read 157 times by this repo's route files, --brown-mid 12 times, --orange 3 — and the master declares every one of them ONLY under [data-platform="commerce"]. On M-EasyPOS they resolved to nothing, which for an inherited property means the declaration is invalid at computed-value time and the element simply inherits: that is why /wms's warehouse tiles rendered --text on a hardcoded white panel at 1.23:1, and why #wmsAiText fell back to its own literal #6b7280 at 3.03:1. Binding them to real master tokens fixes 180-odd call sites at once and, more importantly, makes them THEME-AWARE — which no per-site edit to an inline style could ever do. They are a compatibility shim, not vocabulary: new code uses the ramp above. --gold and --blue are deliberately absent, because their two call sites were the ones carrying M-EasyDo's accent onto a KPI and they are now on the ramp instead. */ --gray-50: var(--bg-soft); --gray-100: var(--border); --gray-200: var(--border); --gray-300: var(--border-2); --gray-400: var(--muted); --gray-500: var(--muted); --gray-600: var(--text-2); --gray-700: var(--text-2); --gray-800: var(--text); --gray-900: var(--text); --orange: var(--amber-text); /* The two brown aliases came across in the Run 63 extraction from a Commerce ancestor. --brown-dark is every page's own h2, so it is --text; --brown-mid is an order number, a SKU or a link, so it is the accent used as a foreground. Neither is a brown and neither ever was on this platform. */ --brown-dark: var(--text); --brown-mid: var(--accent-text); --brown-light: var(--muted); } [data-theme="dark"] { /* The smallest whole lift toward white that clears 4.5:1 on --bg, --surface, --surface-2 and the token's own dark tint. Ratios are tabled above. */ --pos-success: color-mix(in srgb, #fff 4%, var(--green-text)); --pos-warning: color-mix(in srgb, #fff 2%, var(--amber-text)); --pos-danger: color-mix(in srgb, #fff 8%, var(--red-text)); --pos-info: color-mix(in srgb, #fff 6%, var(--purple-text)); --pos-neutral: var(--muted); --pos-success-bg: var(--green-bg); --pos-warning-bg: var(--amber-bg); --pos-danger-bg: var(--red-bg); --pos-info-bg: var(--purple-bg); --pos-neutral-bg: var(--surface-2); --pos-success-bg: color-mix(in srgb, var(--green) 22%, #000); --pos-warning-bg: color-mix(in srgb, var(--amber) 22%, #000); --pos-danger-bg: color-mix(in srgb, var(--red) 22%, #000); --pos-info-bg: color-mix(in srgb, var(--purple) 22%, #000); } /* ═══════════════════════════════════════════════════════════════════════════ T3 — THE THREE SURFACES THE RAMP DID NOT REACH ─────────────────────────────────────────────────────────────────────────── Round 2 put five semantic foregrounds on the page and the re-measure found the ramp had held: every pair it covers clears 4.5:1 in both themes. What it found instead were three surfaces the ramp had no way to reach, because none of them is a colour a route file names: · a PSEUDO-ELEMENT. ::placeholder takes neither the input's `color` nor its `background`; it takes the browser's own grey, rgb(117,117,117), on every one of the ~100 inputs in this product. Measured: 3.17:1 on a dark panel, 3.87:1 on the dark page, 4.37:1 on the light page. No token a route file could have named would have changed it. · THE ACCENT USED AS A FOREGROUND IN DARK. #BE185D is a fill colour. On --bg #0f172a it is 2.96:1 and on --surface #1e293b it is 2.42:1, and fourteen inline styles across the route files set `color:var(--accent)`. The master already has the answer — --accent-text, #f082b3 in dark — and the shell uses it in twelve places. The route files never got the memo. · AN ALPHA TINT UNDER A BADGE. .badge-green measured 4.41:1 on /settings and 4.91:1 on a card, from ONE pair of colours, because --green-bg is 8% green over whatever happens to be behind it. Same defect the ramp's opaque tints were introduced to fix — the badges simply predate them. The three tokens below are what the fixes in pos-r3-surface.css read. ═══════════════════════════════════════════════════════════════════════════ */ :root { /* THE ACCENT, SNAPSHOT AS A FOREGROUND, AND WHY IT IS NOT JUST --accent-text. S8b rebinds --accent ON an element so that an inline `color:var(--accent)` resolves to a legible value. If that rebind said `--accent: var(--accent-text)` and the master's :root default `--accent-text: var(--accent)` were ever the one in play, the element would reference itself and BOTH properties would become invalid at computed-value time — the text would silently fall back to its parent's colour, which is the exact failure mode this round was told to watch for. Declared here on :root instead, where --accent-text is the platform block's own value and nothing has been rebound, a custom property's computed value is its specified value WITH var() already substituted. Descendants inherit a literal colour, so the rebind cannot close a loop. Verified declared for THIS platform, not only for a sibling: modus-design-system.css:373 [data-platform="pos"] --accent-text: #A21550 modus-design-system.css:442 [data-theme="dark"][data-platform="pos"] --accent-text: #f082b3 One declaration covers both themes: --accent-text is resolved on , where the dark block has already replaced it. */ --r3-accent-fg: var(--accent-text); /* PLACEHOLDER TEXT. --muted, which is the master's Run 54 derived secondary and is declared in :root and in [data-theme="dark"] — for every platform, not under a platform switch. Measured on the two grounds an input can sit on, in both themes: light #5a6d87 on --surface #ffffff 5.29:1 light #5a6d87 on --bg #f8f9fa 5.02:1 dark #919eb0 on --surface #1e293b 5.38:1 dark #919eb0 on --bg #0f172a 6.56:1 Named rather than used inline so the one value is stated once and the ratios above have somewhere to live. */ --r3-placeholder: var(--muted); /* THE BLUE PAIR, AND WHY THERE IS ONE AFTER ALL. T2 says there is no blue in this ramp and that stands: --pos-info is violet, and nothing new is being coloured blue. This pair exists for ONE job — .badge-blue is a MASTER class, it is already on 26 call sites in this repo, and it is the one badge hue the ramp had no opaque tint for. Leaving it out would have meant fixing eight badge variants and leaving the ninth at 4.34:1 on a --bg-soft panel and 4.15:1 on a hovered dark row. Derived from --blue-text (#1567d3 light, #5b9bef dark), NOT from --blue. That is deliberate and it is the whole difference: --blue is #1a73e8, the literal this integration is forbidden to carry, and naming it here would re-import it under a token. --blue-text is a different colour, it is the foreground .badge-blue already renders, and deriving the badge's own tint from its own foreground is what the other four pairs do. light #1567d3 on tint rgb(234,241,251) 4.73:1 dark #5b9bef on tint rgb(20,34,53) 5.63:1 */ /* The accent's own opaque tint, for the same reason: .badge-accent paired --accent-text with an 8% --accent-bg and therefore measured 6.67:1 on a card and 5.97:1 on a --bg-soft panel. Both clear, and it is the ninth badge — leaving it as the only alpha tint of the set would mean the rule "a badge states its own ratio" had an exception nobody could see. light #A21550 on tint rgb(249,234,240) 6.56:1 dark #f082b3 on tint rgb(42,5,20) 7.56:1 */ --pos-accent-bg: var(--accent-bg); --pos-accent-bg: color-mix(in srgb, var(--accent) 9%, #fff); --pos-blue: var(--blue-text); --pos-blue-bg: var(--blue-bg); --pos-blue-bg: color-mix(in srgb, var(--blue-text) 9%, #fff); --pos-blue-edge: var(--border); --pos-blue-edge: color-mix(in srgb, var(--blue-text) 34%, transparent); } [data-theme="dark"] { --pos-accent-bg: var(--accent-bg); --pos-accent-bg: color-mix(in srgb, var(--accent) 22%, #000); --pos-blue-bg: var(--blue-bg); --pos-blue-bg: color-mix(in srgb, var(--blue-text) 22%, #000); } /* ── §T4 THE CONTROLS THIS PRODUCT DOES NOT DRAW ─────────────────────────── Every surface the stylesheets paint follows the theme. The ones the BROWSER paints did not, because nothing ever told it which theme was in play: `getComputedStyle(:root).colorScheme` read "normal" under [data-theme="dark"], so a native checkbox rendered as a light-mode white box on the dark panel, and scrollbars,