/* THE BRAND, DEFINED ONCE — SESSION W.
 *
 * ═══════════════════════════════════════════════════════════════════════════
 * THIS FILE IS THE ONLY PLACE IN THIS REPOSITORY WHERE A BRAND COLOUR IS A
 * NUMBER, WITH THE TWO EXCEPTIONS NAMED BELOW. Everywhere else — the three
 * Tailwind themes, the three pages' own <style> blocks, every inline style —
 * the colour is `var(--sea)` or the utility class that resolves to it.
 * tests/brand-tokens.test.js scans the three prototypes, the three generated
 * stylesheets, the three theme configs and the whole served bundle for the
 * eight hexes below and fails if any of them appears anywhere but here.
 *
 * THE TWO EXCEPTIONS ARE THE TWO SURFACES THAT CANNOT READ A STYLESHEET, and
 * both are CHECKED COPIES rather than second opinions — which is the only
 * reason the sentence above can still be read as true rather than as a claim
 * this file makes about itself and does not keep.
 *
 *   icon.svg — a favicon is decoded by the browser chrome, outside any
 *   document, so it can no more resolve `var(--sea)` than a PNG can. It is
 *   GENERATED from this file by scripts/gen-favicons.mjs, and
 *   tests/brand-tokens.test.js 4a1 asserts the only two colours in it are
 *   --sea and --paper as declared here.
 *
 *   dropfresh-firebase/functions/lib/email.js — SESSION GG. Custom properties
 *   do not exist in any Outlook built on Word's rendering engine, and <style>
 *   is stripped by a large share of Gmail's own clients, so `color:var(--slate)`
 *   in an email is not a wrong colour: it is NO colour, with the card, the band
 *   and the button gone with it. Every colour in an email is a literal, inline,
 *   on the element, and there is no arrangement of that file that resolves a
 *   token at render time. It holds them in one `const C = {…}` block at the top,
 *   and tests/email-brand.test.js parses THIS file and THAT block and fails if
 *   any entry is not byte-for-byte the token of the same name — and separately
 *   fails if a hex appears anywhere else in email.js at all. It is outside
 *   brand-tokens.test.js's scan because that scan is over what HOSTING serves;
 *   an email is sent from a Cloud Function and reaches nobody through firebase
 *   hosting. The deploy that carries a colour change into an inbox is
 *   `--only functions`, which is not the one that repaints the site.
 *
 * WHY A SHARED FILE AND NOT A BLOCK IN EACH PAGE. The three apps already share
 * three JavaScript modules and a typeface through scripts/sla-targets.json, and
 * the same argument applies with more force to a colour: three copies of eight
 * hexes is three chances for one of them to be corrected in two places. It is
 * declared in the `assets` array of all three hosting targets, which is what
 * makes sync-sla.mjs copy it beside each index.html and what makes
 * verify-hosting-bundle.mjs check 4 refuse a deploy whose copy differs from the
 * repository's by a byte.
 *
 * IT IS NOT A FOURTH STYLESHEET IN THE SENSE THE THREE TAILWIND FILES ARE, and
 * that distinction is the whole reason merging those three is still forbidden.
 * This file declares VALUES. It generates no class. `--danger` existing here
 * does not make `text-danger` work on the booking page — that is decided by
 * tools/tailwind/customer.config.cjs, which does not name it, so Tailwind emits
 * no such rule into customer-tailwind.css. Three themes, three stylesheets, one
 * set of numbers underneath them.
 *
 * ═══════════════════════════════════════════════════════════════════════════
 * WHY EACH COLOUR IS DECLARED TWICE.
 *
 *     --token:     #RRGGBB;
 *     --token-rgb: R G B;
 *
 * (The shape, not a real token — tests/brand-tokens.test.js requires each of
 * the eight hexes to appear exactly ONCE in this file, comments included, and a
 * worked example here would be the second copy it exists to forbid.)
 *
 * The hex is the canonical, human form and the one the brand kit is written in.
 * The channel triple is what Tailwind needs: a theme colour written
 * `rgb(var(--sea-rgb) / <alpha-value>)` supports the opacity modifier, so
 * `bg-sea/10` is a real rule. Written as a bare `var(--sea)` it would not be —
 * Tailwind cannot take a hex apart at build time when it is behind a variable,
 * and the modifier is silently dropped. Three tints on the booking page depend
 * on this.
 *
 * THE TWO FORMS ARE PROVED TO AGREE, in tests/brand-tokens.test.js, by parsing
 * both out of this file and converting. A triple that drifts from its hex is
 * the exact failure this arrangement invites and the only one it adds.
 *
 * ═══════════════════════════════════════════════════════════════════════════
 * THE TWO PAIRINGS THAT MAY NEVER SHIP. Both measure 3.87:1, which is below
 * WCAG AA's 4.5 for normal text.
 *
 *     sea text on a sand ground        sand text on a sea ground
 *
 * On `sand`, text is `slate`. On `sea`, text is `paper` or `onSea`.
 * tests/brand-contrast.test.js carries both as explicit failing cases, so the
 * measurement itself is proved rather than asserted.
 * ═══════════════════════════════════════════════════════════════════════════ */
:root {
  /* THE MARK'S BODY, PRIMARY BUTTONS, REVERSED PANELS. (It was "the mark's
     porthole" until session HH. There is no porthole; see --mark-body below.) */
  --sea:     #43708A;
  --sea-rgb: 67 112 138;

  /* WARM PANELS, QUIET EMPHASIS, ACCENT BANDS. Text on it is `slate`, never
     `sea` and never `grey` — grey on sand is 4.15 and also fails. */
  --sand:     #EBD9BE;
  --sand-rgb: 235 217 190;

  /* ALL PRIMARY TEXT. */
  --slate:     #33454F;
  --slate-rgb: 51 69 79;

  /* PAGE GROUND. Cards stay white on top of it; that is what keeps `warn` at
     5.02 where it is printed, because warn on paper is 4.40 and would not
     pass. */
  --paper:     #F1F0EA;
  --paper-rgb: 241 240 234;

  /* SOFT TINT BLOCKS. Text on it is `slate`: grey on mist is 4.29. */
  --mist:     #D3E1E7;
  --mist-rgb: 211 225 231;

  /* SECONDARY TEXT. On `paper` and on white only — see the two notes above. */
  --grey:     #5C686E;
  --grey-rgb: 92 104 110;

  /* HAIRLINES AND BORDERS. Never text: rule on paper is 1.24. */
  --rule:     #DCD9CF;
  --rule-rgb: 220 217 207;

  /* BODY TEXT SITTING ON `sea`. */
  --onSea:     #EAF2F6;
  --onSea-rgb: 234 242 246;

  /* ── THE MARK, AND WHY IT IS TWO PROPERTIES — SESSION HH ─────────────────
     The mark is a landscape cabin case with two straps. It is drawn inline
     wherever it appears, so it takes its two colours from here rather than
     from a file per ground. `docs/brand/brand-kit.md` carries the artwork.

     --mark-body DEFAULTS TO currentColor so the mark inherits its context, as
     the old one did — but ON `paper` AND ON WHITE THE SURFACE SETS IT TO
     `sea`, AND THAT IS A DECISION RATHER THAN A DEFAULT. `slate` was drawn,
     compared against the wordmark and rejected: it makes the mark and the
     words one dark object, which reads well in the lockup and leaves no brand
     colour anywhere on a card or a letterhead. The mark spends most of its
     life small and with no wordmark beside it, and at that size colour
     identifies faster than shape — a dark grey case is every luggage icon.
     DO NOT MATCH THE MARK TO THE WORDMARK'S `slate`. It looks tidier in the
     lockup and it is the change that costs the brand its only colour.

     --mark-strap IS AN OPAQUE STROKE, NOT A CUT-OUT, AND HAS NO DEFAULT HERE.
     The straps are PAINTED in the colour of the ground rather than letting the
     ground show through. They read as negative space and they are not, and
     that difference is the difference between a mark that survives the
     customer hero's photograph and one that dissolves into it. "Make the
     straps transparent, they are meant to be cut-outs" is the tidy-looking
     change somebody will reach for; it is wrong on a photograph, on a gradient
     and on any non-flat ground.

     It has no default because there is no ground that is right more often than
     not: the booking page's header is white, the app icon's tile is `sea`, and
     a default would be a plausible wrong answer on whichever of those it was
     not chosen for. Each surface declares its own, and
     tests/brand-tokens.test.js checks each one against the ground actually
     painted behind it. A surface that declares none draws no straps, which is
     visibly wrong rather than quietly wrong.

     TWO-TONE WAS TRIED AND REJECTED: a `slate` centre panel between the straps
     looked good on `paper` and broke inverted, becoming a dark square-cornered
     slab across the case. A mark that has to change to survive the app icon is
     not one mark. */
  --mark-body: currentColor;

  /* ── DERIVED, AND DELIBERATELY NOT A NINTH BRAND COLOUR ──────────────────
     `sea` darkened 18% toward black, which is what a hover and a pressed state
     need and what `accentDark` used to be. It is written out rather than left
     to color-mix() for one reason: Tailwind's opacity modifier needs channels,
     and a color-mix() result cannot be taken apart into them. It carries no
     brand meaning of its own, is never a ground for text other than `paper` or
     `onSea`, and must not be used where the kit says `sea`. */
  --seaDark:     #375C71;
  --seaDark-rgb: 55 92 113;

  /* ── STATUS, AND IT IS NOT THE BRAND ─────────────────────────────────────
     These four are here because a colour that is a number in two files is a
     colour that gets corrected in one of them, and for no other reason. THEY
     WERE NOT REPAINTED IN SESSION W AND MUST NOT BE: status colour is
     information. The dashboard's `unknown` state is amber with a warning sign
     because session M decided a reader must be able to tell "we do not know"
     from "we know and it is fine", and making that amber fit a warm palette
     would be repainting the meaning.

     `amber` and `warn` are the same hex under two names. That was true before
     this file existed; deduplicating them would rename a colour across a
     hundred class attributes for no rendering change, which is a different
     change from this one. */
  --warn:       #B45309;
  --warn-rgb:   180 83 9;
  --amber:      #B45309;
  --amber-rgb:  180 83 9;
  --danger:     #C0392B;
  --danger-rgb: 192 57 43;
  --good:       #0E8F86;
  --good-rgb:   14 143 134;
}