/* * PBJ CRM — the navigation shell's token layer (Phase 1, 2026-08-21). * * WHAT THIS FILE IS. The navigation redesign is written against its own token * names (--nav-*). This file is the ONLY place those names are defined, and * every one of them is an alias onto a --pbjcrm-* variable PBJ_CRM_Theme * already resolves. There is not one hex value in this file and there must * never be one: a colour written here would be a second opinion about the * theme, it would be wrong on fifteen of the sixteen presets, and it would be * invisible to the owner's own colour controls. * * ⛔ PHASE 1 CHANGES NO PIXEL. This file declares custom properties and states * not a single rule, so nothing reads them yet and nothing can look different * because of them. That is the phase gate, and it is a property of the file * rather than a promise about it. * * ------------------------------------------------------------------ THE CASCADE * * ⛔ THE SELECTOR LIST IS THE LOAD-BEARING PART OF THIS FILE. Read this before * changing it, because the failure it avoids is silent and looks like a theme * bug rather than a stylesheet one. * * A custom property is substituted at COMPUTED-VALUE TIME, on the element the * declaration sits on, and what descendants inherit is the ALREADY-RESOLVED * value. So `:root { --nav-bg-app: var(--pbjcrm-bg) }` freezes whatever * --pbjcrm-bg happens to be ON :ROOT, and every descendant inherits that frozen * colour. The portal paints itself by writing --pbjcrm-* as INLINE properties * onto the app element (pbj-crm.js, applyTheme()) — and an inline declaration * on a descendant cannot reach back into a value that was already resolved on * an ancestor. A :root-only alias layer would therefore ignore the live theme * and quietly serve whatever the server printed at page load. * * The fix is to re-declare the same aliases on every element that CARRIES * resolved --pbjcrm-* values, so each one re-resolves against its own: * * :root PBJ_CRM_Theme::inline_css() prints here from both * the canvas template and the header shortcode. It * is what covers surfaces appended to — the * toast stack, dialogs, the file viewer — which * belong to no wrapper and would otherwise be the * list of consumers somebody has to keep up to date. * .pbjcrm-app the portal itself, painted inline by applyTheme(). * .pbjcrm-login \ * .pbjcrm-hdr | the three above-the-page surfaces the header * .pbjcrm-search-overlay / shortcode re-states the tokens on. * * ⚠ AND .pbjcrm-portal IS DELIBERATELY ABSENT. pbj-crm.css declares its STATIC * LIGHT FALLBACKS on `.pbjcrm-portal, .pbjcrm-login` — real declarations on the * element, which beat the inherited theme. Aliasing there would resolve the * whole --nav-* set against those fallbacks and hand every dark preset a white * shell. The login card is on the list only because the server re-states the * true tokens on it; nothing re-states them on .pbjcrm-portal, so nothing may * alias from it. * * ⚠ Ordering does not matter. --nav-* and --pbjcrm-* are different names, so * the two stylesheets never compete; the cascade settles --pbjcrm-* first and * substitution happens afterwards, whichever file loaded first. * * ⚠ NO FALLBACK VALUES, on purpose. `var(--pbjcrm-bg, #0a0a0b)` would look * like caution and behave like a hard-coded dark hex on a light preset. * PBJ_CRM_Theme::inline_css() emits every variable named here on every render, * so the fallback would only ever fire on a page where the theme block is * missing — and on that page a wrong colour is worse than an unstyled one. * * ------------------------------------------ FIVE NAMES BEYOND THE SPEC's 33 * * 01-TOKENS.md defines 33 names and says: never hard-code a hex in a * component, and if a colour you need is not here, STOP and ask. Jake was * asked on 2026-08-21 and answered "split", so five names are added here and * nowhere else. Every one of them maps onto a --pbjcrm-* variable that already * existed — not one new theme token was needed to satisfy any of them, which * is the mapping architecture doing exactly what it was built for. * * --nav-red-ink ink ON the accent. 01 has --nav-green-ink and no red * twin, so §2.1's active-tab label and the notification * badge had no name and were being written as #fff. * --nav-red-chip the open-ticket chip. 01 gave one name to two jobs. * --nav-blue-business the business glyph. Same, in blue: 01 pointed one * token at both the business glyph and the * primary-contact star. * --nav-bg-control the ⌘K chip fill. 02-SHELL-SPEC §2.1.5 states #191a1f * directly, a value 01 never names — 02 breaking 01's * own rule. Reported, not silently obeyed. * --nav-focus-ring 01 has no focus colour at all, and 04-ACCEPTANCE §6 * requires a visible focus ring on every control * including marker chips. It was the last hard-coded * hex left in the shell. * * ⚠ AND FOUR MORE UNNAMED HEXES ARE STILL SITTING IN 02 AND 03, for whoever * builds those screens: #4a4e55 (the breadcrumb separator in 02, and the * checked-checkbox border in 03 §3.1), and the KEPT chip's trio in 03 §97 — * #7fd6a3 on #132018 with a #2c4a3a border, which is a success chip and * should land on --pbjcrm-success / success-soft rather than on three * literals. Do not hard-code them; ask, then map them here. * * ⚠ ONE KNOWN RISK, WRITTEN DOWN RATHER THAN DESIGNED AROUND: `--nav-*` is a * generic name and a WordPress theme is free to define its own on :root. Our * declarations win everywhere the shell actually draws (they sit on the shell's * own elements, which are more specific), but a body-appended surface inherits * from :root and could in principle pick up a site theme's --nav-header-h. The * names come from the design handoff and are not ours to rename; if this ever * bites, the fix is to namespace them there first. */ :root, .pbjcrm-app, .pbjcrm-login, .pbjcrm-hdr, .pbjcrm-search-overlay { /* --- Surfaces, darkest to lightest on a dark preset ------------------ */ --nav-bg-app: var(--pbjcrm-bg); --nav-bg-chrome: var(--pbjcrm-header-bg); --nav-bg-rail: var(--pbjcrm-rail-bg); --nav-bg-card: var(--pbjcrm-surface); --nav-bg-panel: var(--pbjcrm-surface-alt); --nav-bg-row-hover: var(--pbjcrm-surface-hover); /* * SELECTION IS NEUTRAL, NOT TINTED, and this is a deliberate departure * from the obvious --pbjcrm-accent-soft. The spec calls this SELECTION * ONLY and states in the same breath that a row background must never * carry the urgency colour. On the Midnight preset the accent IS PBJ red, * so accent-soft would paint every selected row a red wash — the exact * thing the spec forbids two paragraphs later. */ --nav-bg-row-sel: var(--pbjcrm-surface-alt); --nav-bg-bulkbar: var(--pbjcrm-surface-alt); /* * The fill of a small control sitting ON the chrome bar — the ⌘K chip * today. It resolves to the same value --pbjcrm-pill-bg does, and that * is the point: a chip is what the CRM already calls a pill, and the * CRM already fills those from the alternate surface. * * ⛔ NOT --pbjcrm-control-bg, which is the obvious-looking answer and * the wrong one. control-bg resolves to `surface` — the CARD colour — * and this control does not sit on a card, it sits on the header bar. * On Midnight that would paint the chip #101115 against a #111216 bar: * a control that vanishes into the thing it is drawn on. */ --nav-bg-control: var(--pbjcrm-surface-alt); /* --- Lines ----------------------------------------------------------- */ --nav-line: var(--pbjcrm-border); --nav-line-soft: var(--pbjcrm-border-soft); /* * ⚠ THE PANEL AND CONTROL BORDERS SHARE ONE TOKEN, and it is NOT * --pbjcrm-edge. edge is the accessible boundary (3:1 by construction, * 5.11:1 on Midnight) and would be visibly lighter than the design asks * for. Jake chose the design's own value at the visual check on * 2026-08-21, so both borders resolve from border-strong, which the * Midnight preset sets to the handoff literal. Anything that genuinely * needs a boundary a person can find — a dialog edge on a dark scrim — * still has --pbjcrm-edge and should use it. */ --nav-line-panel: var(--pbjcrm-border-strong); --nav-line-control: var(--pbjcrm-border-strong); /* --- Text ------------------------------------------------------------ */ --nav-text: var(--pbjcrm-text); --nav-text-2: var(--pbjcrm-text-soft); --nav-text-3: var(--pbjcrm-muted); --nav-text-mute: var(--pbjcrm-muted-soft); --nav-text-faint: var(--pbjcrm-faint); /* --- Accents --------------------------------------------------------- * * The urgency rule in the spec — an overdue record renders its title in * --nav-red-alert at weight 600 — lands on --pbjcrm-danger, so it stays * red on every preset rather than becoming whatever the owner picked. * The nav's ACTIVE colour is the accent, which is what makes the shell * follow a business's own colour instead of insisting on ours. */ --nav-red: var(--pbjcrm-accent); /* Ink on the accent: the active tab's label, the notification badge. */ --nav-red-ink: var(--pbjcrm-accent-contrast); /* * The open-ticket chip. 01-TOKENS pointed --nav-red at both the active * nav item and this chip; they are not the same statement, so they are * no longer the same token. * * ⛔ state-client, NOT rec-ticket, and the reasoning matters because * rec-ticket is the one that SOUNDS right. rec-ticket is the record * KIND colour — purple #8a63d2, the colour the calendar has drawn * tickets in for years — and it is already spoken for one block below * as --nav-violet. Pointing the chip there too would say `open * tickets` and `archive vault` in one colour, which is the collision * this split exists to remove, and would render the chip PURPLE where * the design draws it red. state-client is the STATE colour, and its * definition in class-pbj-crm-theme.php is `red for CLIENT-facing open * items` — which is what an open ticket is. The chip is not saying * `these are tickets`, it is saying `these are open`. */ --nav-red-chip: var(--pbjcrm-state-client); --nav-red-alert: var(--pbjcrm-danger); --nav-green: var(--pbjcrm-success); --nav-green-ink: var(--pbjcrm-success-contrast); --nav-amber: var(--pbjcrm-warning); /* * Blue was also one name for two things. The plain name keeps the * commoner meaning — the primary-contact star — because rec-contact IS * the CRM's person blue and has been since before any of this. The * business glyph gets the qualified name and the firm's own hue, which * exists precisely so a business reads apart from a person. */ --nav-blue: var(--pbjcrm-rec-contact); --nav-blue-business: var(--pbjcrm-rec-business); --nav-violet: var(--pbjcrm-rec-ticket); --nav-grey-chip: var(--pbjcrm-state-idle); --nav-grey-chip-2: var(--pbjcrm-faint); --nav-link: var(--pbjcrm-link); /* * WHERE THE KEYBOARD IS (04-ACCEPTANCE §6). 01-TOKENS names no focus * colour, so the shell was carrying a literal #2271b1 — the one hex * left in its new rules, and the one that would have been wrong on * every preset that is not Default. --pbjcrm-focus-ring is derived * from the owner's accent and then pushed until it clears 3:1 against * the surface behind it, so it is visible on all seventeen presets * rather than on one. */ --nav-focus-ring: var(--pbjcrm-focus-ring); /* --- Type ------------------------------------------------------------ * * Local stacks. The design names two webfonts; this suite makes no * third-party request on any page load, and the handoff's own rules * forbid new dependencies, so both resolve to faces already on the * machine. See the FONT_* constants in class-pbj-crm-theme.php. */ --nav-font: var(--pbjcrm-font); --nav-font-mono: var(--pbjcrm-font-mono); /* --- Chrome geometry ------------------------------------------------- * * Load-bearing and fixed: 48 / 34 / 206 / 60. They do NOT move with the * density setting — see the CHROME_* constants for why — so the shell * chrome must never be built out of --pbjcrm-space. Content spacing * inside the shell still follows density, exactly as it always has. */ --nav-header-h: var(--pbjcrm-header-h); --nav-footer-h: var(--pbjcrm-footer-h); --nav-rail-w: var(--pbjcrm-rail-w); --nav-rail-w-collapsed: var(--pbjcrm-rail-w-collapsed); }