# DRIFT: where the style guide and the code disagree

Every claim the current style guide makes that the code does not support, with both values and
both file paths.

**Starting point.** `/home/shared/true/design-references/AUDIT-FINDINGS.md`, a read only audit
produced 2026-07-25.

A note on the count, because it matters for reading the two documents together. The audit is
described as having 47 findings, and its list is numbered 1 to 47, but **the numbering skips
21, 27, 31 and 32**, so there are **43 actual entries**. 47 is the highest number, not the
number of findings. Numbering is preserved below, gaps included, so the two documents can be
read side by side.

**All 43 were re-verified against the source files for this document.** 37 hold. 5 are wrong or
materially misleading and are corrected below, with the audit's own wording quoted so the
correction is auditable. 1 was true when written and is now resolved. A further 15 findings not
in the audit are added at the end.

**Files.**

| Short name | Path |
|---|---|
| **the stylesheet** | `TRUE-Website/master/public/assets/cdn.prod.website-files.com/67c07336c94b9f0854f4062f/css/true-original.webflow.shared.c43aefb38.min.css` |
| **the guide** | `design-references/styleguide-current.html` |
| **shell.ts** | `TRUE-Website/master/src/lib/shell.ts` |
| **chrome.ts** | `TRUE-Website/master/src/lib/chrome.ts` |
| **insights.ts** | `TRUE-Website/master/src/lib/insights.ts` |
| **resources-style.ts** | `TRUE-Website/master/src/lib/resources-style.ts` |
| **the mockup** | `design-references/sign-redesign.html` |
| **verify** | `TRUE-Verify/develop/src/frontend/styles/_variables.scss` |
| **vault** | `TRUE-Vault/master/apps/dash/tailwind.config.ts` |

**Verdicts.** `CONFIRMED` the audit is right as stated. `CONFIRMED, EXTENDED` right, with
material detail it missed. `CORRECTED` wrong or misleading, restated. `RESOLVED` true when the
audit was written, fixed by this work.

Counts below were produced by grepping the named file. They are reproducible.

---

## Summary

| Verdict | Count | Items |
|---|---|---|
| CONFIRMED | 25 | 2, 3, 4, 6, 8, 9, 11, 12, 14, 15, 18, 22, 23, 24, 26, 28, 29, 30, 35, 36, 40, 41, 42, 43, 44 |
| CONFIRMED, EXTENDED | 12 | 1, 5, 7, 10, 13, 16, 17, 19, 20, 25, 33, 37 |
| CORRECTED | 5 | 34, 38, 39, 45, 46 |
| RESOLVED | 1 | 47 |
| **Audit entries** | **43** | numbered 1 to 47, skipping 21, 27, 31, 32 |
| New findings, not in the audit | 15 | N1 to N15 |

Item 17 is a hybrid: the audit's main claim (the guide's pink focus ring exists nowhere in
production) is confirmed, and one sub clause of it is wrong. It is counted under EXTENDED and
the wrong clause is corrected in place.

The five corrections are worth reading before the confirmations. Two of them (45 and 46) change
what the problem *is*, not just its details, and therefore change the fix.

---

## Typography

### 1. Body font family — CONFIRMED, EXTENDED

* **Guide claims** (line 44): `--font-body: 'Helvetica Neue', 'HelveticaNeue', Helvetica, Arial, sans-serif;`
* **Code says**: `font-family:Helvetica Neue Updated,Impact,sans-serif` — **166 rules**, the
  most common declaration in the stylesheet. A second family, `Helveticaneue,Impact,sans-serif`,
  covers 34 more.
* **Extension the audit missed.** The fallback is the real problem. **Impact** is a heavy
  condensed display face with nothing in common with Helvetica Neue. If the webfont fails to
  load, every paragraph on trueoriginal.com renders in Impact. This is a live website defect,
  not a naming difference. `tokens/true-tokens.json` marks the family `corrected` and emits
  `'Helvetica Neue Updated', 'Helvetica Neue', Helvetica, Arial, sans-serif`.
* **Also affects**: verify (`$font-body`) and `TRUE-Sign/master/apps/dash/tailwind.config.ts`
  (`fontFamily.body`) carry the same wrong first name.

### 2. The guide never loads the body webfont — CONFIRMED

* **Guide**: lines 10 to 22 define exactly two `@font-face` rules, Marcellus and Marcellus SC.
  There is no `@font-face` for any Helvetica family and no `<link>` to one.
* **Consequence**: every body specimen on the style guide page renders in a system font, so the
  page cannot be used to judge body type at all.
* **Code**: the stylesheet defines six non icon `@font-face` rules, including
  `Helvetica Neue Updated` at weights 400 and 500.

### 3. Marcellus fallback — CONFIRMED

* **Guide** (lines 42 to 43): `'Marcellus', Georgia, serif` and `'Marcellus SC', Georgia, serif`.
* **Code**: `Marcellus,Georgia,sans-serif` (22 rules) and `Marcellus SC,Georgia,sans-serif` (10).
* **Note**: here the guide is *more correct than production*. Georgia is a serif; ending the
  stack with `sans-serif` picks the wrong class of face if Georgia is also missing. verify and
  vault both have it right too. The token file keeps `serif` and marks the family `corrected`.
  The fix belongs on the website.

### 4. Lato — CONFIRMED

* **Code** (shell.ts, line 7):
  `WebFont.load({google:{families:["Lato:100,100italic,300,300italic,400,400italic,700,700italic,900,900italic"]}})`
  on every page, ten weights.
* **Stylesheet**: exactly **one** rule uses `Lato,sans-serif`.
* **Guide**: no mention of Lato anywhere.

### 5. `Helveticaneue Roman` has no `@font-face` — CONFIRMED, EXTENDED

* **Code**: `font-family:Helveticaneue Roman` on **16 rules**, including `.body-text-copy` and
  `.text-field-8`.
* **Extension**: the audit says there is no `@font-face` behind it, which is true. It also has
  **no generic fallback after it**: the declaration is the bare family name with nothing else,
  so all 16 rules render in the browser default font. This cannot be tokenised; it has to be
  deleted from the website.

### 6. Font URLs — CONFIRMED

* **Guide** (lines 12, 19): `https://cdn.prod.website-files.com/67c07336c94b9f0854f4062f/...`
* **Code**: `/assets/cdn.prod.website-files.com/67c07336c94b9f0854f4062f/...`, served from the
  site's own origin. `astro.config.mjs` sets `site: 'https://www.trueoriginal.com'`.
* **Resolved by**: `tokens/true-tokens.css` emits the four `@font-face` rules with absolute
  `https://www.trueoriginal.com` URLs.

### 7. Missing type scale steps — CONFIRMED, EXTENDED

* **Guide** documents: 12, 14, 16, 20, 24, 32, 48, 72.
* **Code** ships, with counts: 10 (1), 12 (13), 14 (27), 15 (5), 16 (88), 17 (1), 18 (5),
  20 (11), 21 (1), 22 (1), 24 (28), 32 (40), 36 (4), 38 (2), 40 (25), 48 (16), 56 (3), 72 (2),
  plus `6vh`, `1.4vh` and four `em` sizes.
* **The audit names 40, 56, 36, 22, 18, 15, 17 as missing. Also missing: 10, 21 and 38.**
* **40px is the serious one.** 25 uses, and it is `.rte h1`, so it is the top heading of every
  blog post on the site. A guide that omits it cannot describe the blog.

### 8. Hero is not always 72px — CONFIRMED

* **Guide**: hero documented as 72/72.
* **Code**: `.heading-hero{font-size:6vh;line-height:6vh}` — the left aligned hero is viewport
  relative. At a 1080px viewport that is 64.8px; at 800px it is 48px. Only `.heading` and
  `.heading-hero-center` are fixed at `72px/72px`.

### 9. Bare heading tags — CONFIRMED

* **Code** (the Webflow reset in the stylesheet):

  ```
  body{color:#333;font-family:Arial,sans-serif;font-size:14px;line-height:20px}
  h1{font-size:38px;line-height:44px}   h4{font-size:18px;line-height:24px}
  h2{font-size:32px;line-height:36px}   h5{font-size:14px;line-height:20px}
  h3{font-size:24px;line-height:30px}   h6{font-size:12px;line-height:18px}
  h1,h2,h3,h4,h5,h6{margin-bottom:10px;font-weight:700}
  ```
* **Guide**: silent. So an unclassed `<h2>` on a TRUE page renders as bold Arial 32/36, not
  regular Marcellus, and nothing warns you.

### 10. Blog and RTE body size — CONFIRMED, EXTENDED

* **Guide**: body documented at 16px.
* **Code**: `.rte{color:#1c1c1e;margin-top:80px;margin-left:10%;margin-right:10%;font-family:Helvetica Neue Updated,Impact,sans-serif;font-size:14px;line-height:24px}`
* **Extension**: the *colour* also differs and in the opposite direction. `.body-text` is 16px
  in `#636366`; `.rte` is 14px in `#1c1c1e`. The two body contexts disagree on both axes, and
  both are correct in place.

---

## Colour

### 11. The border alpha on dark — CONFIRMED

* **Guide** (lines 916 to 919): the opacity ramp documents 100%, 80%, **48%**, 16%.
* **Code**: `#ffffff7a` (0.48) appears **once**, on `.button-secondary`. `#fff6` (0.40) appears
  **six times**, including `.button`, and is the real default border on dark.
* The guide documented the exception and omitted the rule.

### 12. `#2d2d2f` missing — CONFIRMED

* **Code**: 9 rules. `.button`, `.link`, `.link-3` to `.link-6`, `.text-block-15`, `.icon-4`,
  all under `:where(.w-variant-acd70e32-9434-2f8d-8045-42bffddac006)`, the light navbar variant.
* **Guide**: absent.

### 13. `#a1a1a1` missing — CONFIRMED, EXTENDED

* **Code**: `.text-block-12`, `.link-7` (both 12px footer links) and `.div-block-38`
  (a 2px separator dot).
* **Guide**: absent.
* **Extension**: it also **fails WCAG AA**. `#a1a1a1` on white computes to roughly 2.6:1, below
  the 4.5:1 needed for normal text and below even the 3:1 for large text and UI. It is shipping
  on the footer of every page.

### 14. 0.24 white missing from the ramp — CONFIRMED

* **Guide** ramp (lines 900 to 927): 100%, 80%, 48%, 16%. No 24%.
* **Guide's own badge** (line 698): `background: rgba(255,255,255,0.24)`.
* **Code**: `.text-block-19{backdrop-filter:blur(16px);background-color:#ffffff3d;...}` where
  `#ffffff3d` is 0.24. The guide uses the value and does not list it.

### 15. 0.56 white missing from the ramp — CONFIRMED

* **Code**: `#ffffff8f` (0.56) on **8 rules**, every `::placeholder` inside a dark input
  (`.text-field-2` through `.text-field-8`).
* **Guide**: the ramp omits it. Line 1275 refers to a white placeholder in prose without giving
  the value.

### 16. `#470505`, `#1ca800`, `#0050bd` undocumented — CONFIRMED, EXTENDED

* `#470505` (6 rules): `background-color` on `.hero` and five `.hero---*` variants, sitting
  behind the hero photograph. Never visible in a finished render.
* `#1ca800` (4 rules): `.yes` and `.yes-copy-copy`, the success badge. **This is the only
  semantic colour the entire website defines.**
* `#0050bd` (6 rules): the real focus ring. See item 17.
* **Extension**: `#1ca800` on white computes to roughly 3.2:1, so the `.yes` badge fails AA for
  normal text at the size it ships.

### 17. Focus ring colour — CONFIRMED, EXTENDED. One clause of the audit is wrong.

* **Guide** (lines 94 to 97): `:focus-visible { outline: 2px solid var(--gradient-pink); outline-offset: 2px; }`
* **Code**: three rules, all identical in shape:

  ```css
  .nav-link:focus-visible,.nav-link[data-wf-focus-visible]
    {outline-offset:0px;color:#0050bd;border-radius:4px;outline:2px solid #0050bd}
  ```
  plus `.nav-dropdown-toggle:focus-visible` and `.nav-dropdown-link:focus-visible` at
  `border-radius:5px`. **There is no pink focus ring anywhere in production.** Confirmed.
* **Correction to the audit.** The audit says "Production uses #0050bd **and #7dcade**",
  implying both are in the stylesheet. `#7dcade` never appears in a focus rule in the
  stylesheet. The blue focus ring is in **insights.ts** only:
  `.feed-load-more-btn:focus-visible{outline:2px solid #7dcade;outline-offset:2px}`. Both
  colours are real, but they come from different files and serve different backgrounds:
  `#0050bd` on light, `#7dcade` on dark. SPEC.md records the split.

### 18. `::selection` — CONFIRMED

* **Guide** (lines 88 to 91): `::selection { background: var(--gradient-pink); color: var(--white); }`
* **Code**: no `::selection` rule in the stylesheet, resources-style.ts or insights.ts.

### 19. Body colour — CONFIRMED, EXTENDED

* **Guide** (line 83): `body { color: var(--primary-dark); }` while documenting `#636366` as
  body text.
* **Code**: `body{color:#333;...}` from the Webflow reset. `.body-text` opts in to `#636366`.
* **Extension**: the guide is wrong twice over. It does not match production's actual body
  colour (`#333`, a Webflow leftover) **and** it contradicts its own documentation. The correct
  statement is: text that carries no class is `#333`, marketing body copy is `#636366`, and
  blog body copy is `#1c1c1e`.

---

## Radius

### 20. Input radius — CONFIRMED, EXTENDED

* **Guide** (line 1119): "16px for major containers and cards, **12px for buttons and inputs**,
  8px for smaller elements."
* **Code**: `.text-field{...border-radius:8px;padding:12px 16px;...}` and `.text-field-2`
  through `.text-field-8` all at `border-radius:8px`. **Every input in production is 8px.**
* **Extension the audit missed: the guide contradicts itself on the same page.** Line 1275
  says "Light inputs: #F8F8FB background, **8px radius**, 12px 16px padding, 16px font", which
  is correct. Line 1119 and line 1132 ("Buttons, inputs, FAQ" under the 12px swatch) say 12px.
  Two statements, 156 lines apart, disagreeing.

### 22. 999px pill radius missing — CONFIRMED

* **Guide**: documents `--radius-pill: 80px`.
* **Code**: `80px` is `.button-3{border-radius:80px}` on a `64px x 64px` element, which makes a
  circle, not a pill. The real pill radius is **999px**, and it exists only in hand written
  TRUE code, which is why the guide missed it: `insights.ts .feed-load-more-btn` and its inner
  `span`; `resources-style.ts .res-chip` and `.res-btn`; the mockup `.kicker`.

### 23. Undocumented radii — CONFIRMED

* **Guide** documents 8, 12, 16, 80.
* **Code** ships, with counts: `16px` (99), `8px` (62), `12px` (13), `4px` (9), `80px` (6),
  `0` (6), `7px` (3), `50%` (3), `1em` (3), `5px` (2), `3px` (2, one `!important`), `32px` (1),
  `24px` (1), `13px` (1), `100%` (1). Fourteen values plus zero, against four documented.

---

## Shadows

### 24. The "toast" shadow — CONFIRMED

* **Guide** (line ~1171): a shadow box captioned as a toast, at `0 4px 12px rgba(0,0,0,0.1)`
  in the guide's tokens.
* **Code**: `.background-video-2{box-shadow:0 4px 12px #0003}`. `#0003` is alpha **0.2**, not
  0.1, and it is on a background video element, not a toast. **There is no toast anywhere in
  the TRUE codebase.**

### 25. The "dropdown" shadow — CONFIRMED, EXTENDED

* **Guide** (lines 1171 to 1173): `0 4px 10px rgba(0,0,0,0.3)`.
* **Code**: that exact string does not exist as a `box-shadow` anywhere in the stylesheet. The
  real nav dropdown is `.nav-dropdown-list.shadow-three{box-shadow:0 8px 50px #0000000d}`,
  alpha **0.05**, blur **50px**.
* **Extension**: the shape the guide is half remembering does exist, but as a
  **`backdrop-filter: drop-shadow(0 4px 10px #0009)`** on 4 rules. `#0009` is alpha **0.6**, not
  0.3, and `backdrop-filter` is not `box-shadow`. So the guide has the wrong property, the wrong
  alpha and the wrong component.

### 26. Soft shadow alpha — CONFIRMED

* **Guide**: `rgba(150,163,181,0.08)`. verify carries the same value as `$shadow-soft`.
* **Code**: `.shadow-two{box-shadow:0 4px 24px #96a3b514}`. `0x14` is 20/255 = **0.0784**.

---

## Layout

### 28. Page container — CONFIRMED

* **Guide** (lines 1106 and 1360): "Page container `1360px` with `40px` side gutters."
* **Code**: `1360px` appears **once**, as `.ben-1{...max-width:1360px;...}`, one panel. The real
  containers are 940px (`.w-container`, `.container`, `.container-2`, `.container-9`, six rules),
  1180px (the mockup), 1160px (resources), 1200px, 1260px, 1420px, 1440px and 1468px.
* **Also affects**: verify adopts it as `$container-max: 1360px`.

### 29. Blog RTE measure — CONFIRMED

* **Guide** (line 1109): "Blog content (RTE) `70%` centered, `10%` margin l/r."
* **Code**: `.rte{margin-left:10%;margin-right:10%}`. 10% on each side leaves **80%**, not 70%.
  The guide states the correct margin and then does the arithmetic wrong in the same row.

### 30. The 8px spacing scale — CONFIRMED

* **Guide**: `--space-xs` 8, `sm` 16, `md` 24, `lg` 32, `xl` 48, `2xl` 80, `3xl` 120, `4xl` 160.
* **Code**, single value `padding` counts: 48px (27), 24px (25), 8px (23), 32px (16), 12px (14),
  16px (10), 80px (8), 200px (8), 60px (7), 40px (5), 20px (5), 144px (2), 88px (1).
  `margin-top` counts: 24px (26), 48px (21), **160px (16)**, 8px (15), 40px (12), 120px (12),
  80px (9), 104px (1), 64px (1).
* **Missing from the guide's ladder and in constant use**: 12, 20, 40, 64, 88, 104, 200, plus
  the `3em` and `4em` padding on `.section-5` to `.section-8` and `.container-3` to
  `.container-6`.

### 33. Navbar width — CONFIRMED, EXTENDED

* **Guide**: the nav demo is `max-width: 800px` (line 594) while the prose (lines 1107, 1248)
  says 1000px.
* **Code**: `.div-block{...width:1000px;padding:8px;border-radius:16px;...}` inside
  `.nav-wrapper{z-index:10;margin-top:8px;position:fixed;inset:0% 0% auto}`.
* **Extension**: the prose says "1000px **max-width**". Production sets `width:1000px`, a fixed
  width. On a viewport narrower than 1000px the real navbar overflows rather than shrinking;
  a `max-width` would not. The distinction matters for anyone rebuilding it.

### 34. Breakpoints — CORRECTED

* **Guide**: documents 991 / 767 / 479 in its tables (lines 1341 to 1344) and its own CSS breaks
  at **991px and 768px** (lines 772 and 778). The 768px break matches nothing on the website.
  **That part of the audit is confirmed.**
* **The audit also says**: "Webflow also has 728px queries." **This is wrong.** The stylesheet
  contains exactly four media queries:

  ```
  @media screen and (max-width:991px)   4 blocks
  @media screen and (max-width:767px)   4 blocks
  @media screen and (max-width:479px)   5 blocks
  @media (min-width:768px)              1 block
  ```
  **There is no 728px media query.** `728px` is a `max-width` **container value**
  (`.container-2{max-width:728px}`, `.container-9{max-width:728px}`) that appears *inside* the
  991px block. The audit mistook a container width for a breakpoint. The real fourth query is
  `@media (min-width:768px)`, a single Webflow internal rule.

---

## Components

### 35. Button padding — CONFIRMED

* **Guide**: `12px 24px`.
* **Code**: `.button{padding:8px 16px}`, `.button-2{padding:12px 20px}`,
  `.button-secondary{padding:12px 24px}`, `.button-4`/`.button-6`{`padding:16px 0`},
  `.button-primary{padding:12px 25px}`. The documented value matches `.button-secondary` and
  nothing else.

### 36. Button radius — CONFIRMED

* **Guide**: 12px, presented as universal.
* **Code**: 12px on `.button`, `.button-2`, `.button-secondary`; **16px** on `.button-4` and
  `.button-6`; **80px** on `.button-3`.

### 37. Hover token `#32343a` — CONFIRMED, EXTENDED

* **Guide** (lines 439 and 671): `.btn-primary-dark:hover { background: #32343a; }`
* **Code**: `#32343a` appears **once**, as `.button-primary:hover{color:#fff;background-color:#32343a}`.
  `.button-primary` is Webflow starter boilerplate: it is uppercase with `letter-spacing:2px` on
  `background-color:#1a1b1f`, and nothing in the TRUE design uses it.
* **Extension**: the mockup has since copied the same value into `.btn-pink:hover`. So a
  Webflow starter colour now exists in two TRUE artefacts without ever having been chosen.
  **There is still no defined hover state for the TRUE dark button.** SPEC.md documents the
  hand written alternatives (`opacity: .85`, `translateY(-1px)`, border darkening) and flags
  the gap.

### 38. Glassmorphism — CORRECTED

* **The audit says**: "Glassmorphism is documented as one pattern but there are two real ones."
* **This is wrong. The guide documents both.** Line 1286 to 1290, "Glassmorphism Badge":
  `backdrop-filter: blur(16px), background rgba(255,255,255,0.24), 8px radius`. Line 1354, in a
  summary table: "Glassmorphism panels — `backdrop-filter: blur(80px); background: rgba(255,255,255,0.16)`."
  Both match the code exactly (`.text-block-19` and `.div-block-11`).
* **What is actually wrong** is smaller and different: the two are documented 68 lines apart in
  unrelated sections and are never presented as a pair, and the 0.24 fill used by one of them is
  missing from the opacity ramp on the same page (item 14). The patterns are right; the
  organisation hides the relationship.

### 39. FAQ typography — CORRECTED

* **The audit says**: "FAQ answer typography claim is unverifiable from the css. Treat as
  unsupported."
* **The guide makes no claim about FAQ answer typography.** Lines 1279 to 1281 render two FAQ
  examples containing a question only, with no answer element. The audit is describing a claim
  that is not there.
* **What is actually unsupported** is the FAQ *question* typography. The guide sets
  `.faq-example .faq-q { font-size: 16px; font-weight: 500; line-height: 24px; }` (lines 687 to
  691). Production's `.faq-item{background-color:#f8f8fb;border-radius:12px;padding:32px;grid-column-gap:32px;grid-row-gap:32px}`
  sets no typography at all, so 16/24 weight 500 is an invention.
* The guide's FAQ container values (`#f8f8fb`, 12px radius, 32px padding) **are** correct.

### 40. No footer documented — CONFIRMED

* **Guide**: no footer component anywhere.
* **Code**: `.footer-menu{background-color:#f8f8fb;background-image:url(footer bg.svg);border-radius:16px;margin-top:120px;padding:48px}`
  plus a substantial markup block in chrome.ts shipping in **four variants**
  (`en|dark`, `en|base`, `sv|dark`, `sv|base`): a support `mailto:` link, a rule, four columns
  (address and language switcher, Links, Connect with us, Accreditations), then a separate bar
  with copyright and `.link-7` micro links separated by `.div-block-38` dots.
* **Documented in**: SPEC.md section 18.

### 41. No dropdown or mega menu documented — CONFIRMED

* **Code**: `.nav-dropdown-list{background-color:#fff;border-radius:12px}`,
  `.nav-dropdown-list.w--open{padding-top:10px;padding-bottom:10px}`,
  `.nav-dropdown-list.shadow-three{box-shadow:0 8px 50px #0000000d}`,
  `.nav-dropdown-link{padding-top:5px;padding-bottom:5px;font-size:14px}`, plus the
  `.dropdown-3` / `.dropdown-list-2` Industries menu with five links in chrome.ts.
* **Guide**: absent.

### 42. No logo ticker documented — CONFIRMED

* **Code**: `.ticker.has-horizontal-fade` and `.ticker-diplomas.has-horizontal-fade` with
  `mask-image:linear-gradient(90deg,#0000,#000 10% 90%,#0000)` and a `40px` gap, plus vertical
  variants using `linear-gradient(#0000,#000 10% 90%,#0000)`. Both `-webkit-mask-image` and
  `mask-image` are shipped.
* **Guide**: the mask is mentioned in a summary table but there is no ticker component.

### 43. The `.yes` badge missing — CONFIRMED

* **Code**: `.yes{color:#1ca800;border:1px solid #1ca800;border-radius:7px;padding:2px 3px;display:inline-block}`
  and `.yes-copy-copy`, identical.
* **Guide**: the Badges section documents only the glass badge.

### 44. The entire `/resources/` design system missing — CONFIRMED

* **Code**: resources-style.ts, roughly 70 live pages, its own scoped custom properties
  (`--res-blue --res-pink --res-ink --res-surface --res-line --res-grad`) and around 60 classes
  covering hero, eyebrow, prose, bullets, numbered steps, code blocks, cards, a FAQ accordion,
  **tables**, quotes, chips, link cards, CTA buttons and light/surface/dark section variants.
* **Guide**: no mention. This matters most for **tables**: the website stylesheet has no table
  styling at all, so resources-style.ts is the only table system TRUE has.
* **Documented in**: SPEC.md section 21, and `tokens/true-tokens.json` under
  `color.resources`, `radius.resources` and `alias.resources`.

---

## Tokens

### 45. "18 of its 20 tokens exist nowhere in the website codebase" — CORRECTED

This is the audit's strongest claim and it is materially wrong on both numbers.

* **The guide defines 24 custom properties, not 20** (lines 27 to 61): 8 colours, 1 gradient,
  3 fonts, 8 spacing steps, 4 radii.
* **Most of the values do exist.** Checked one by one against the stylesheet:

  | Guide token | Value | In the code? |
  |---|---|---|
  | `--gradient-blue` | `#7dcade` | yes, `:root`, 13 uses |
  | `--gradient-pink` | `#d82a80` | yes, `:root`, 13 uses |
  | `--primary-dark` | `#1c1c1e` | yes, 156 uses |
  | `--body-text` | `#636366` | yes, 28 uses |
  | `--surface-light` | `#f8f8fb` | yes, 16 uses |
  | `--border-light` | `#e5e5ea` | yes, 36 uses |
  | `--white` / `--black` | `#ffffff` / `#000000` | yes, 187 / 26 uses |
  | `--brand-gradient` | `linear-gradient(90deg, blue, pink)` | yes, 12 selectors |
  | `--font-display` / `--font-display-sc` | Marcellus / Marcellus SC | yes, family names match; fallback differs (item 3) |
  | `--font-body` | `'Helvetica Neue', ...` | **no**, the family is `Helvetica Neue Updated` (item 1) |
  | `--space-xs` … `--space-4xl` | 8, 16, 24, 32, 48, 80, 120, 160 | all eight exist as real spacing values |
  | `--radius-sm/md/lg` | 8, 12, 16 | yes, 62 / 13 / 99 uses |
  | `--radius-pill` | 80px | exists, but it is a circle on a 64px button, not a pill (item 22) |

  **23 of 24 values are traceable. One is wrong.**
* **What is actually true, and is the real finding**: only **2 of the 24 names** exist as CSS
  custom properties in production. The stylesheet defines `--gradient-blue` and
  `--gradient-pink` and nothing else. Every other value in production is hardcoded per Webflow
  class. So the guide's tokens are not inventions, they are a *reasonable extraction that was
  never wired to anything*, and the set is **incomplete** (see items 7, 11, 14, 15, 23, 30)
  rather than fabricated.
* **Why the correction matters**: "these tokens are inventions" and "these tokens are an
  incomplete extraction that nothing imports" lead to different fixes. The second is the true
  one, and it is what `tokens/true-tokens.json` addresses.

### 46. Naming collides with `--res-*` — CORRECTED

* **The audit says**: "Naming collides with the one real hand authored set (--res-*). Nothing
  reconciles the two."
* **They cannot collide.** resources-style.ts declares its variables on `.res-main`, not on
  `:root` (line 13), and every class is `res-` prefixed. The file's own header comment says this
  is deliberate: "Every class is res- prefixed so it can never collide with the site's compiled
  Webflow classes." The name sets are also disjoint: `--res-blue` versus `--gradient-blue`.
* **What is true**: the two sets **diverge without reconciliation**. Two different names for
  `#7dcade` exist in the codebase and nothing states that they are the same value or which is
  canonical. That is a documentation gap, not a collision.
* **Resolved by**: `tokens/true-tokens.json` records the mapping under `alias.resources` and
  states that resources should **not** migrate, because roughly 70 live pages depend on the
  names and the values are already identical.

### 47. No importable token file — RESOLVED

* True when the audit was written.
* **Now**: `tokens/true-tokens.json` plus `tokens/true-tokens.css`,
  `tokens/_true-tokens.scss`, `tokens/tailwind-preset.mjs` and `.cjs`, all generated
  by `node generators/build.mjs` and verifiable with `--check`.

---

## New findings, not in the audit

### N1. The audit's gradient selector list is incomplete

* **The audit says**: `linear-gradient(90deg,#7dcade,#d82a80)` — "6 occurrences
  (.cta, .cta-s, .ben-6)". It names three selectors for six occurrences.
* **The six are**: `.ben-6`, `.industries-cta`, `.contact-hero`, `.hero-thankyou`, `.cta`,
  `.cta-s`. **Three were unnamed.**
* **And there are six more**, layered over a photograph, that the prose does not mention:
  `.hero---edu.main`, `.hero---associ.main`, `.hero---compliance.main`, `.hero---product.main`,
  `.hero---product-2.main`, `.hero---edu-copy.main`. Plus `.hero.main` in the `var()` form.
* **Total: 12 selectors carry the brand gradient**, not 3. It is a hero background at least as
  much as it is a CTA background, which changes how the guide should present it.

### N2. `.hero.main` replaces the hero photograph entirely

`.hero` sets a photograph with a `#0006` scrim over `background-color:#470505`. `.hero.main`
then sets `background-image:linear-gradient(90deg,var(--gradient-blue),var(--gradient-pink))`,
which **replaces** the whole `background-image` list. So the home hero is a flat brand gradient
with no photograph, and the `#470505` and the photograph in the base rule are dead weight there.
Anyone reading `.hero` alone would conclude the home hero is a photo. It is not.

### N3. The audit understates the dominant black scrim

The audit's colour table lists `#0006` at 31 uses but the prose only discusses
`#0000007a (0.48 black overlay) 8`. **`#0006` (alpha 0.4) is the most used alpha value in the
stylesheet at 31 occurrences**, and it is the hero photograph scrim. `#0000007a` (0.478) is a
different job: the card scrim on `.div-block-114`, `.div-block-115`, `.div-block-116` and
`.div-block-120`. Both are real; the guide should document both with their distinct roles.

### N4. No focus state exists for text inputs

Searched: the stylesheet, resources-style.ts, insights.ts, `forms.ts`. The only rule is the
Webflow default:

```css
.w-input:focus,.w-select:focus{border-color:#3898ec;outline:0}
```

`#3898ec` is a Webflow blue used nowhere else in TRUE, and `outline:0` **removes the focus
indicator**. Webflow does the same on seven more components: `.w-slider-arrow-left:focus`,
`.w-slider-arrow-right:focus`, `.w-dropdown-toggle:focus`, `.w-dropdown-link:focus`,
`.w-nav-button:focus`, `.w-tab-link:focus`. This is a live accessibility regression on every
form and every dropdown on the site.

### N5. No `prefers-reduced-motion` anywhere in TRUE code

Searched: the stylesheet, resources-style.ts, insights.ts, the mockup. Not present in any of
them. The only occurrence in any file read for this work is in **the guide itself** (line 72),
which is not a source of truth. The mockup ships six looping animations (`float`, `pulse`,
`pdraw`, `pslam`, `pshake`, `fpop`), several running indefinitely, so this matters the moment
the product page pattern ships. Required addition, specified in SPEC.md section 28.

### N6. Whole component categories have no styling anywhere

Searched the stylesheet, resources-style.ts, insights.ts, `forms.ts`, chrome.ts and the mockup.
None of the following exists in any of them: **alerts, toasts, empty states, skeletons, input
error states, input disabled states, required field markers, helper text, tooltips, modals,
pagination, breadcrumbs.** The guide documents a toast shadow (item 24), which is the only
reason anyone would think a toast exists. SPEC.md sections 23 to 25 mark these as gaps and give
a construction from real parts rather than inventing values.

### N7. There is no TRUE warning or error colour, and two products invented different ones

The website defines exactly one semantic colour, `#1ca800`. verify invents
`$color-success: #22c55e`, `$color-warning: #f59e0b`, `$color-error: #ef4444`. vault invents
`destructive: '#DC2626'` and a four step yellow ramp. None trace to anything. Note that
verify's `$color-success: #22c55e` is not even the one real success colour, `#1ca800`. Recorded
as `TODO` in the token file with the search path.

### N8. `#a80003` looks like an error colour and is not

`#a80003` appears twice in the stylesheet. Both occurrences are inside Webflow form error
boilerplate, not a TRUE decision. Flagged because it is the closest thing to a red in the file
and it must not be adopted by mistake.

### N9. The transition vocabulary is four declarations

The entire 208 KB stylesheet contains: `all .2s` (2), `all .3s` (1),
`background-color .1s,color .1s` (1), `unset` (1). And exactly **one** `@keyframes`, `spin`,
applied as `animation:.8s linear infinite spin`. The real motion vocabulary lives in
insights.ts, resources-style.ts and the mockup, all of which agree on `150ms ease` for hover
feedback. The guide documents motion tokens without saying that production has almost none.

### N10. TRUE Verify's shadow tokens are wrong three times over

verify carries `$shadow-soft: 0 4px 24px rgba(150,163,181,0.08)` (real alpha 0.078),
`$shadow-toast: 0 4px 12px rgba(0,0,0,0.1)` (real alpha 0.2, and not a toast) and
`$shadow-dropdown: 0 4px 10px rgba(0,0,0,0.3)` (does not exist as a `box-shadow`; the real nav
dropdown is `0 8px 50px rgba(0,0,0,0.05)`). All three came from the guide, which means the
guide's errors have already propagated into product code. This is the concrete cost of the
drift and the reason the token file needed to exist.

### N11. TRUE Vault's radius names invert the system

vault declares `borderRadius: { md: '6px', lg: '8px', xl: '12px' }`. In TRUE terms its `lg` is
the input radius (8px) and its `xl` is the button radius (12px). **The 16px radius that builds
every card, panel, CTA, navbar and footer on the website has no vault equivalent at all**, and
`6px` exists nowhere in TRUE. A component moved between vault and any other TRUE surface will
land on the wrong radius silently, because the names match and the values do not.

### N12. TRUE Vault's type scale cannot express a TRUE heading

vault replaces (not extends) `fontSize` and stops at `3xl: 32px`. The TRUE page heading is 48px
and the hero is 72px or 6vh. Neither is reachable. It also expresses line height as unitless
ratios (`1.5`, `1.2`, `1.15`) where production uses pixel line heights throughout, so even the
sizes that do match will not render at the same rhythm.

### N13. Marcellus is loaded twice from two different sources

The website serves Marcellus from its own origin via `@font-face`
(`/assets/.../67e920bba68b82145bdfd92d_Marcellus-Regular.ttf`). The mockup loads it from
**Google Fonts** instead (`https://fonts.googleapis.com/css2?family=Marcellus&display=swap`).
Two sources for the same face means two rendering paths, two caches and two things to break.
SPEC.md's PRODUCT PAGE recipe specifies the trueoriginal.com origin or self hosting.

### N14. The guide's own CSS uses a breakpoint the website does not have

Beyond item 34: the guide breaks at `768px` (line 778) in its **own layout**, not just in its
documentation. So the page that is supposed to demonstrate the system does not use the system's
breakpoints. The correct value is 991px.

### N15. The guide's CTA band and footer were not what the product pages ship: RESOLVED

Found 2026-09-28, when Patrik looked at the bottom of TRUE Verify: "Ser lite konstigt ut langt
ned pa sidan hos Verify, kan du fixa sa det blir som vi har pa andra sidor med ratt styling pa
gradient, knapp osv".

* **Guide**: the CTA band was a gradient panel on radius 16px with 48px of padding, "not a full
  bleed slab", and the footer was a light `var(--true-surface)` card.
* **Code**: TRUE Sign's `marketing/index.html` ends with `.contact-grad{background:var(--true-gradient);padding:96px 0 0}`
  running straight into `footer{background:var(--true-gradient);padding:120px 40px 0}`, with the
  dark `.tfoot` card (`#1c1c1e`, radius 16px, padding 48px) floating on it. One band. TRUE Vault
  has the footer band with no panel above it. The website's `.footer-menu` in `chrome.ts` renders
  as a dark card on the white page, with the gradient spent on its own CTA panel above.
* **The cost**: TRUE Verify followed the guide and put the rounded panel above Sign's gradient
  footer, so the page showed the gradient twice with white between. Fixed in TRUE-Verify #332.
* **Resolved in**: `sections/050-gradient.html` (the closing band, with a do and do not pair),
  `210-footer.html` (the dark card and where it sits), `260-anatomy.html` (zones 8 and 9 and the
  miniature), `010-start-here.html`. SPEC.md section 8 still describes a split CTA panel from the
  mockup and was left alone.

---

## What this changes

* **Website fixes** (not this repo's to make, raised here): the `Impact` body fallback (item 1),
  the `sans-serif` fallback on Marcellus (item 3), the 16 `Helveticaneue Roman` rules with no
  face behind them (item 5), the ten unused Lato weights (item 4), the removed focus outlines
  (N4), and the missing `prefers-reduced-motion` (N5).
* **Product migrations**: verify's three wrong shadow values and `$container-max` (N10, item 28);
  the body family name in verify and TRUE Sign (item 1); vault's inverted radius names (N11) and
  truncated type scale (N12). Mappings are in `tokens/true-tokens.json` under `alias`.
* **Style guide site**: everything above is now expressed as values in
  `tokens/true-tokens.json` and as rules in `SPEC.md`.