adr-sml/docs/02-design-system.md

# 02 — Design system

Authority: `AGENTS.md` §3 D7 — *keep the palette and the infinity mark;
modernize the execution.* The look is not up for redesign. What follows is the
system that preserves it while fixing what the old build got wrong.

---

## What carries over unchanged

- The **palette**: cream, ink, maroon, gold.
- The **infinity mark** — SML Company Ltd.'s actual logo, and the metaphor holds:
  a dispute is a loop, and the work is redrawing the loop into a line.
  **It is a shaded ribbon, not a stroked curve**: a band of variable width that
  twists in three dimensions, maroon flowing into champagne, passing over itself
  at the crossing. Ink bounding box **2668 × 1704 = 1.5657:1**
  `[verified 2026-08-26 — measured against the master]`. Source of truth:
  `src/assets/brand/sml-infinity-mark.png`; provenance in
  `docs/reference/brand-assets.md`.
- The **type pairing**: Instrument Serif for display, Geist for text, Geist Mono
  for eyebrows and labels.
- The **editorial register** — generous whitespace, restrained colour, serif
  display type at large sizes.

## What changes

| Was | Is | Why |
|---|---|---|
| Google Fonts at runtime | Self-hosted, subset, preloaded | Removes a render-blocking third-party round trip from a page that collects legal inquiries |
| Fixed px type sizes | Fluid `clamp()` scale | One scale from 360 px to 1600 px with no breakpoint jumps |
| Ad hoc spacing values | 8 px base scale | Consistent vertical rhythm; no magic numbers |
| Gold used as a text colour on cream | Gold restricted to decorative and on-dark | **It fails WCAG AA at 2.10:1.** Measured, not assumed |
| Scroll-reveal on every element, always on | Reveal on major sections only, gated behind `prefers-reduced-motion` | Motion that reads as confident rather than decorative; accessible by default |
| 2.2 MB single file, ~1 MB of base64 logos *(both figures under review — `AGENTS.md` Q34; and "470 KB PNG", which this row used to assert, has no source anywhere in the repo and has been removed)* | Optimized SVG mark, AVIF/WebP photography | The mark is geometry, so it should be vector. That holds whatever the old file weighed |
| React 18 dev build + Babel Standalone in the browser | Static HTML, near-zero JS | The reason the site is invisible to crawlers |

---

## Colour

Tokens live in `src/styles/tokens.css`. Never write a raw hex value in a
component.

| Token | Value | Use |
|---|---|---|
| `--cream` | `#faf7f2` | Page background |
| `--cream-2` | `#f3ede0` | Alternating section background |
| `--cream-3` | `#ebe3d1` | Cards and insets on cream |
| `--ink` | `#1a1614` | Body text; dark section backgrounds |
| `--ink-soft` | `#3a322c` | Secondary text |
| `--muted` | `#6e6359` | Metadata, captions — **on cream only** |
| `--maroon` | `#5a1a1c` | Primary action, accents, dark panels |
| `--maroon-d` | `#3d1112` | Hover on maroon |
| `--maroon-l` | `#7a2a2c` | Links on cream |
| `--gold` | `#c9a876` | Rules, dividers, on-dark accent — **never text on cream** |
| `--gold-d` | `#a88858` | Large decorative text on cream only |
| `--gold-l` | `#e2c89a` | Text on ink or maroon |

### Contrast — measured, 2026-08-25

Against `--cream` `#faf7f2`:

| Colour | Ratio | AA body (4.5) | AA large (3.0) |
|---|---|---|---|
| `--ink` `#1a1614` | **16.81** | pass | pass |
| `--ink-soft` `#3a322c` | **11.75** | pass | pass |
| `--maroon` `#5a1a1c` | **12.29** | pass | pass |
| `--maroon-l` `#7a2a2c` | **8.95** | pass | pass |
| `--muted` `#6e6359` | **5.47** | pass | pass |
| `--gold-d` `#a88858` | **3.11** | **FAIL** | pass |
| `--gold` `#c9a876` | **2.10** | **FAIL** | **FAIL** |

Against `--maroon` `#5a1a1c`: cream 12.29 · gold-l 8.11 · gold 5.84 — all pass.
Against `--ink` `#1a1614`: cream 16.81 · gold-l 11.09 · gold 8.00 — all pass.
`--muted` on ink measures **3.07 and fails**; use `--gold-l` or cream at reduced
opacity for secondary text on dark.

**Hard rules.**

1. `--gold` is never a text colour on cream. Rules, borders, dividers, icon
   strokes, and on-dark text only.
2. `--gold-d` on cream only at 24 px+ / 19 px bold, and only for decorative
   display text — never for anything a reader must parse.
3. Body text on cream is `--ink` or `--ink-soft`. Metadata may use `--muted`.
4. Secondary text on dark is `--gold-l` or `--cream` at ≥ 70% opacity.
5. **No dark mode.** A single committed light identity is the right call for a
   legal practice, and halving the surface area halves the ways contrast breaks.

---

## Typography

**Faces.** Instrument Serif (display) · Geist 300/400/500/600 (text) ·
Geist Mono 400/500 (eyebrows, labels, data).

Self-host all three. Subset to Latin + Latin Extended-A. `font-display: swap`.
Preload only the two faces used above the fold — Instrument Serif regular and
Geist 400.

**Scale.** Fluid, `clamp()`, `1.25` ratio at the small end widening to `1.333` at
the display end. Tokens `--text-2xs` through `--text-6xl` in `tokens.css`, plus
`--text-eyebrow` at 14 px — the same value as `--text-sm` and deliberately not an
alias of it; see the eyebrow rule below.

**Rules.**

- Display type (`--font-serif`) at `--text-4xl` and above only. It has almost no
  hinting at small sizes and looks weak below 32 px.
- Display line-height `0.95`–`1.05`; letter-spacing `-0.02em`.
- Body line-height `1.6`. Measure capped at `68ch` — the old site ran full-bleed
  paragraphs at 1400 px, which is unreadable.
- Eyebrows: mono, **14 px** (`--text-eyebrow`), `0.18em` tracking, uppercase,
  weight 500, always paired with a real heading. Pouya raised it **12 → 13 → 14 px
  on 2026-08-31**, in two passes, because uppercase mono at this tracking reads
  smaller than it measures and 13 px was still getting lost against the display
  type. There is **one definition**, `.eyebrow` in `global.css`. An eyebrow is not
  a heading and never carries the `<h*>` — but a real heading may carry the class,
  and **fourteen do, in two groups**: the footer's four column headings
  (`SiteFooter.astro`) and `/bio/`'s ten block headings.
  ⚠️ **"ONE DEFINITION" HAS ONE CARVE-OUT AND IT IS NAMED RATHER THAN IMPLIED:**
  `/contact/`'s `<label>`/`<legend>` set and its direct-contact `<dt>`s repeat the
  treatment instead of taking the class, because they need `--text-secondary`
  (11.75 : 1) rather than `.eyebrow`'s `--text-meta` (5.47 : 1) — a form label is
  operative text. **Everything else about them matches, `font-weight` included**;
  without that they rendered at 400 beneath a `p.eyebrow` of the same size and
  colour, which is the divergence a carve-out is meant to bound rather than hide.
  Do not widen this to any other element.
  **14 px is the same value as `--text-sm`, and `--text-eyebrow` is deliberately
  not an alias of it.** The two move for different reasons; aliasing would mean a
  future change to body-meta type silently moved every eyebrow on the site.
  (This bullet said "13 px is not a rung on the scale — it sits between
  `--text-xs` and `--text-sm`" for one revision. At 14 px it is that rung.)
- **THE 11 px FLOOR HAS EXACTLY ONE CONSUMER, AND THAT IS THE CLAIM THAT IS
  TRUE.** Pouya's ruling, 2026-08-31: *"form labels are operative text, and the
  site should have exactly one small-text floor."* `--text-2xs` (11 px) now has
  **one consumer in `src/`** — the header tagline (`git grep 'var(--text-2xs)' --
  src` returns one hit, `SiteHeader.astro`; 21 rendered instances, every one
  `span.eyebrow.brand-tagline`) — and nothing else may use it without a
  measurement recorded beside it.
  ⚠️ **THIS BULLET SAID "THE SMALL-TEXT FLOOR IS 14 px, AND THERE IS EXACTLY ONE
  EXCEPTION" FOR ONE REVISION, AND THAT WAS FALSE** — falsified by this document
  thirty lines below, which concedes a 12 px family. The ruling asked for the
  record that the tagline is the only sub-14 px text on the site; **it is not, so
  that is not what is recorded here.** What is true is the sentence above: one
  consumer of the 11 px token. `--text-xs` (12 px) is a separate rung and is
  enumerated below.
  **The exception, and why it is deliberate rather than residual:** the tagline is
  ornamental and layout-constrained. ⚠️ **THE COST WAS RE-MEASURED ON 2026-09-01
  AND IT IS A DIFFERENT COST NOW — the masthead may wrap, so what used to overflow
  invisibly is visible instead.** At `--text-eyebrow` (14 px) the header stands at
  **144.98 px** rather than 81 px — at 1216 px with six nav items, and at **every
  width from 1216 px up** with a seventh (measured at 1216 / 1240 / 1280 / 1360 /
  1440 / 1600 / 1760 / 1920) — because the row wraps. *(This listed four widths
  ending at 1440 for one revision; that list was carried over from the superseded
  CTA-past-the-edge measurement, which really did stop at 1440.)* **Document overflow
  is 0 and the CTA sits exactly on `.header-inner`'s content edge in every one of
  those cases**, where before the fix they were 20 px of overflow at 1216 px, 4 px
  at 1280 px, and the CTA 67.8 / 43.8 / 51.8 / 51.8 px past the content edge. So
  the two costs this bullet used to cite are **gone**, replaced by one that is
  larger and easier to see: 64 px of header height on every page. *(13 px took the
  header to 83.4 px; that figure was taken before the masthead could wrap.)*
  Insights is that seventh item. The measurements are in `SiteHeader.astro`.
  **Three blocks moved to `--text-eyebrow` on 2026-08-31 and their carve-outs are
  superseded.** (a) `/contact/`'s `<label>`/`<legend>` set — *raise, do not
  ratify*, superseding the "accepted, not ratified" note this bullet carried for
  one revision. (b) `/contact/`'s direct-contact `<dl>` terms, which are label
  text on the same page and would otherwise have been left a step behind the
  labels beside them. (c) `/bio/`'s ten block headings and its strap, which were
  **copies of five of `.eyebrow`'s six declarations, at 11 px** — the same escape
  the footer's column headings turned out to be — and now carry the class. Not
  byte-for-byte: the `font-size` differed, and **the missing sixth was
  `font-weight`**, which is precisely the one the print block now has to freeze.
  ⚠️ **(c)'s carve-out was justified by a reason that did not apply.** This bullet
  said the `/bio/` sheet was held at 11 px because `npm run bio:pdf` holds it to
  one page. Measured 2026-08-31: the `@media print` block sets both elements to
  **7 pt**, so the screen size never reached the PDF and the one-page constraint
  was never what kept them small. **Print does now freeze `font-weight: 400`**,
  because taking `.eyebrow`'s 500 changed the printed sheet — the PDF grows from
  **89,496 to 91,151 bytes, +1,655** — and the ruling that moved them was about
  size. *(This read "63,743 bytes" for one revision. That is the `cmp -l`
  differing-byte count, not the size delta: the content stream is Flate-compressed,
  so a one-property change scrambles most of the file. Two figures, and the wrong
  one answered a question nobody asked.)* ⚠️ **THAT FREEZE IS NOW A RULED
  CONSTRAINT, 2026-09-01, NOT A DECISION AWAITING POUYA: the circulated PDF's
  typography changes only when its CONTENT is deliberately revised, never as a
  side effect of a screen refactor.** So the print block keeps 400 whatever the
  screen does, and `.eyebrow`'s 500 stops at the `@media print` boundary. **The
  reason it is a rule and not a preference** is that the PDF is the one artefact
  this project's apparatus sees only when someone re-renders it (`AGENTS.md`
  R16): a refactor that silently re-typesets it changes a document already in a
  reader's hands, and the diff that would have shown it is a 1,655-byte
  compressed blob nobody reads. A screen change that reaches print is therefore
  a defect by construction, not a judgement call — see `bio.astro`.
  **`--text-xs` (12 px) IS A SEPARATE RUNG AND IT WAS NOT IN SCOPE ON 2026-08-31.
  Ten declaration sites, all of them:** `Pill`, `Breadcrumbs`, `CredentialRow`,
  `DefinitionGrid`, `ArticleCard`, `ProcessStep` (two), `insights/[...slug].astro`,
  and **`/bio/`'s two — `.fine` and `.sheet-contact p`**. The first eight are mono
  and uppercase or tracked at `0.06em`, a third of the eyebrow's tracking, which is
  what makes them a different treatment. **`/bio/`'s two are neither uppercase nor
  tracked**, so they are not in that family at all — they are simply 12 px text,
  and an earlier draft of this bullet defined the exception in a way that excluded
  them and therefore missed them.
  **Rendered count, and say what it is a number of:** at 1280 px / root 16 across
  all 22 pages, **130 elements carrying their own text compute to 12 px** (149 if
  elements that merely inherit the size are counted). `ArticleCard` and the article
  meta contribute **zero** today — no article is published, so neither renders.
  Every instance measures ≥ 5.01 : 1.
- Italic display (`.it`) is the one flourish the design allows. One italic phrase
  per headline, at most.
- Never skip a heading level. `<h1>` once per page.

---

## Spacing and layout

8 px base: `--space-1` `4px` · `-2` `8` · `-3` `12` · `-4` `16` · `-5` `24` ·
`-6` `32` · `-7` `48` · `-8` `64` · `-9` `96` · `-10` `128` · `-11` `160`.

Content width `1280px`; prose measure `68ch`; wide media `1440px`.
Gutters: `24px` mobile, `48px` desktop.
Section rhythm: `--space-9` (96 px) mobile, `--space-11` (160 px) desktop —
`--section-y` in `tokens.css`. *Corrected 2026-08-26:* the curve was
`6vw + 2rem`, which reaches 160 px only at a **2133 px** viewport, so the
desktop half of this line was never delivered (measured 108.8 px at 1280 px,
128 px at 1600 px). It is now `9vw + 1rem`, which reaches 160 px at 1600 px. If
you change the curve, re-measure — a `clamp()` whose upper bound is unreachable
reads exactly like one that works.

Grid: 12 columns desktop, 6 tablet, 4 mobile, `--space-5` gutter.

---

## Motion

The old build animated nearly everything on scroll. The replacement is
deliberate and quiet.

- **Reveal on section entry only** — not on every child element. Sub-element
  stagger is limited to card grids, and capped at six children.
- Duration `600ms`, easing `cubic-bezier(.2,.7,.2,1)`. Transform and opacity
  only — never layout properties.
- Implement with **`animation-timeline: view()`**, behind `@supports`. *Amended
  2026-08-26:* the `IntersectionObserver` alternative this line used to offer
  first is now ruled out, not merely second choice. It has to run inline in
  `<head>` to avoid a flash, and `05-backend-spec.md` specifies `script-src
  'self'` with no `unsafe-inline` — so the only script on the site would have
  been the one thing the site's own CSP refuses to execute, and a per-build hash
  drifts from the policy pinning it. The CSS route ships **zero** JavaScript.
  Not a framework, not a library, not a script.
- **Content is visible without the feature.** The `@supports` gate is
  load-bearing, not defensive: without it, a browser that ignores
  `animation-timeline` runs the animation once against the document timeline at
  load; with it, that browser gets no animation and fully visible content. The
  old build had this exactly backwards and shipped a blank page.
- **And without a print timeline.** A scroll-driven animation has no timeline
  when printing, so a revealed element renders at its `from` state — `opacity:
  0`. Measured 2026-08-26: before the print override existed, printing a page to
  PDF dropped four card headings from the output entirely. `/about/` is written
  to be printed by people evaluating an appointment.
- Hover transitions `250ms`.

```css
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}
```

Nothing animates infinitely. Nothing autoplays. Nothing moves on page load
except the reveal of the hero.

---

## Components

| Component | Notes |
|---|---|
| `InfinityMark` | ⚠️ **Currently a raster — a documented, temporary exception to this rule** (`AGENTS.md` Q38, R13). The mark is gradient-mesh artwork rather than flat vector paths. An SVG *is* held and it renders faithfully — **and it renders faithfully because it IS the raster**: 257,278 bytes wrapping **seven embedded base64 PNGs**, against **3,063 B** for the AVIF a Retina browser takes in the header — **84×**. *Figures re-stated 2026-08-27 because a second, larger call site now exists and the single number had become misleading:* the mark ships at **two intrinsic widths**, 64 px (header, footer) and 232 px (the home page's approach section, which renders at 225.5 px). At 232 px a DPR-2 device takes **14,555 B** and DPR-3 **22,639 B**, so the ratio against the SVG there is ~11×, not 84×. The full ladders are in `docs/reference/brand-assets.md`; do not quote one number as if it covered both. Inlining it would breach `CLAUDE.md`'s no-base64-images rule. *Pouya settled the characterisation on 2026-08-27: a first draft called the file "a raster in a vector wrapper", a later draft withdrew that as unfair, and **the withdrawal went too far.** Both halves are true — the fidelity is real, and it is bought with embedded raster, which is exactly why fidelity was never the question.* The exception is about payload and composition. It renders AVIF/WebP with a PNG fallback; a Retina device takes 3,063 B of AVIF, `alt=""` when decorative, aspect ratio pinned to `667 / 426`. **Restore this rule the moment the commissioned vector master lands.** Until then the rule stands unchanged for every other mark or icon: inline SVG, `currentColor`, `aria-hidden` when decorative, never a PNG |
| `SiteHeader` | **Sticky from 66 rem (1056 px) up; static below it.** Practice dropdown as CSS-only `<details>`. **(a)** The one-row header holds the brand, **seven** nav items and the CTA — Insights is the seventh, arriving on its own at build step 7. Binary search on the built page puts the true fit at **1047 px**; 66 rem is the clean token above it. Below 66 rem the nav takes its own row and the header measures **141 px** at tablet widths and **189 px** at 320–375 px. **(b)** "Condenses on scroll" is a hairline rule and a shadow, **not a size change** — a `position: sticky` header stays in normal flow, so shrinking its padding lifts every page below it, against the CLS < 0.05 budget. Longhands only; see the component on what the minifier does to the `animation` shorthand. *(This row has been wrong twice, instructively. It first said 60 rem / "~115 px", a height the header never took. It then said 64 rem "with 32 px of clearance" — that 32 px was `.header-inner`'s own `column-gap` mistaken for slack; the real figure at 1024 px with seven items was **−21.6 px**, and nothing overflowed only because flexbox crushed the logo inside the brand block. **Measure slack, not gaps.**)* |
| `SiteFooter` | Three-column sitemap, contact block, designations, entity line |
| `Eyebrow` | Mono label with optional maroon dot |
| `SectionHeading` | Eyebrow + display heading + optional lede, one measure |
| `Button` | Variants `primary` (maroon) · `ghost` (outlined) · `gold` (ink bg, gold-l text). Renders `<a>` or `<button>` correctly |
| `Pill` | Small bordered label for designations and sector chips |
| `CredentialRow` | Three or four credential slots. **Never matter counts** — `AGENTS.md` §4 |
| `PracticeCard` | Sector chip, heading, one paragraph, arrow link |
| `ProcessStep` | Numbered step, timing, body |
| `ArticleCard` | Title, description, date, topic pills, reading time |
| `Prose` | Long-form wrapper. Owns all typographic defaults for MDX |
| `SEO` | Title, description, canonical, OG, Twitter, JSON-LD — see `04-seo-spec.md` |

**Focus states.** Every interactive element gets a visible focus ring:
`outline: 2px solid var(--maroon); outline-offset: 3px`. Use `:focus-visible`.
Never `outline: none` without a replacement — the old build removed it globally.

---

## Accessibility floor

Not a polish pass. A build requirement.

- One `<h1>` per page; heading levels never skipped.
- Landmarks: `<header>`, `<nav>`, `<main>`, `<footer>`. Skip-to-content link first
  in tab order.
- Every image has `alt`. Decorative images get `alt=""`.
- Colour never carries meaning alone.
- All functionality reachable by keyboard; focus order matches visual order.
- Forms: real `<label>` elements, `aria-describedby` for hints, errors announced
  with `role="alert"` and tied to their field.
- Touch targets ≥ 44 × 44 px.
- Test at 200% zoom and at 320 px width. **Both measured 2026-08-27 on `/`:
  document overflow 0 at 320, 360, 390, 414, 640, 768, 900, 1024, 1056, 1200,
  1216, 1280, 1440 and 1920 CSS px, with zero elements extending past the
  viewport.** Page zoom at 200% of 1280 is the 640 column and at 400% is the
  320 column, so WCAG 1.4.4 and 1.4.10 are both covered by that sweep.

  **A stricter case is not fully clean, and it is recorded rather than left to
  be discovered.** With the reader's *default font size* at 200% — root at
  32 px, a real accessibility setting and not page zoom — `/` measured **234 px**
  of overflow at 390. Brought down in three measured steps:

  ⚠️ **THE THREE TABLES BELOW ARE A HISTORY OF HOW THE NUMBER CAME DOWN, NOT THE
  CURRENT STATE.** Every residual in their final rows — the 3 px, the 23 px and the
  63 px — went to **0 on 2026-08-31**, on all 22 pages at 320 / 360 / 390 / 414 /
  640 / 1024 px. The current state is §Reflow below, which also carries what is
  still NOT zero at 1280 px and 1920 px. Read the rows as dated steps.

  | Fix | 390 px | 320 px |
  |---|---|---|
  | as first built | 234 px | 304 px |
  | `minmax(min(Nrem, 100%), 1fr)` on three grids | 83 px | 153 px |
  | `.credentials` made explicit `repeat(2, minmax(0, 1fr))`; `.feature` padding clamped and `overflow-wrap: anywhere` on its title; `.contact-action` `flex: 0 1 auto` + `min-inline-size: 0` | **3 px** | **63 px** |

  **`65 px` corrected to `63 px` on 2026-08-28**, re-measured independently on
  the same page and setting. Two pixels, and it is recorded because a table that
  reads as the site-wide record has to be re-measurable rather than remembered.

  **`/about/` added 2026-08-28** — step 3, and the first page to be measured
  against this table rather than establishing it:

  | Page and fix | 390 px | 360 px | 320 px |
  |---|---|---|---|
  | `/about/` as first built | 38 px | 68 px | 108 px |
  | `.designation-part` `white-space: nowrap` removed (the separator is held by an NBSP instead) and `overflow-wrap: anywhere` on `.hero-h` | **0 px** | **23 px** | **63 px** |

  **Step 4's three pages added 2026-08-28**, and they needed no fix of their own
  — the guards this table produced were applied while writing them rather than
  after measuring:

  | Page | 390 px | 360 px | 320 px |
  |---|---|---|---|
  | `/mediation/` | 3 px | 23 px | 63 px |
  | `/arbitration/` | 3 px | 23 px | 63 px |
  | `/med-arb/` | **0 px** | 23 px | 63 px |

  At the **default** root size all three are **0 px at every width measured**.
  ⚠️ **THE ELEMENT-LEVEL SWEEP BELOW IS ALSO HISTORICAL.** It read: *"the
  element-level sweep at 320/root-32, predicate `right > clientWidth`, names three
  `PracticeCard` chips on `/mediation/` — Construction, Technology, Shareholder —
  plus the header and footer brand elements, which appear on all five pages."*
  Re-run with that exact predicate on 2026-08-31: **0 elements**, on all five pages
  at 320 / 360 / 390 with root 32. The chips were fixed at their cause
  (`PracticeCard`'s padding) and the brand elements at theirs; see §Reflow. *(This read "six" for one pass. Six is the count of
  `article.card` with `scrollWidth > clientWidth`, a different predicate on a
  different element; `adversarial-reviewer` re-ran it and no predicate yields
  six chips. A number in this table has to be re-runnable, which is the whole
  reason the table exists.)* All three are byte-identical to `/`'s — same
  widths, same offsets, same text — so step 4 introduced no new element-level
  overflow.

  Two findings from that page specifically. The `nowrap` was **introduced as a
  fix** for an orphaned `·` at the end of a wrapped line, and it made the whole
  designation item unbreakable — a fix that created a reflow regression, caught
  only because this table existed to regress against. And **the type scale is
  rem-based**, so an `<h1>` at `--text-5xl` computes to 88 px at root 32 and a
  single unbreakable 9-character name ("Lajevardi") exceeds the 224 px content
  box at 320 px; `overflow-wrap: anywhere` is the only remedy that reduces
  min-content size. `/about/` now measures equal to or better than `/` at all
  three widths. *(Its 320/360 residual was recorded here as "the same header
  decision" until 2026-08-31, when that attribution turned out to be wrong and the
  residual went to 0 — see below.)*

  Command, so the numbers are re-runnable rather than quoted: headless Chrome
  over the built `dist`, `document.documentElement.style.fontSize = '32px'`, then
  `documentElement.scrollWidth - documentElement.clientWidth`, plus an
  enumeration of every element that either **is wider than `clientWidth`** or
  **whose own content overflows its own box** (`scrollWidth - clientWidth`), to
  name the offender. ⚠️ **Both halves of that predicate are load-bearing and the
  second was added on 2026-09-01, after the first half alone reported "no offender"
  at three of the four widths that were failing** — the footer email spilled text
  out of a box that was itself inside the viewport. A sweep that enumerates only
  over-wide *elements* will name no cause for a whole class of real overflow.

  ⚠️ **AND THE RECIPE ABOVE HAS A UNIFORM-PASS TRAP THAT IS NOT VISIBLE IN IT.**
  Run `document.documentElement.style.fontSize = '32px'` with
  `prefers-reduced-motion: reduce` in force — launch flag *or* CDP emulation — and
  it reports **0 of 352 with the enlargement never applied**: brand width, header
  height and document height all byte-identical to root 16. The reduced-motion
  reset emits `*,::before,::after{transition-duration:.01ms!important}` over the
  initial `transition-property: all`, so the root font-size change becomes a
  `CSSTransition` and a synchronous read returns its START value.
  `document.getAnimations()` shows `CSSTransition: font-size, running, t=0`; after
  one `requestAnimationFrame` it is 32 px. **Kill motion with an injected
  `transition:none;animation:none` sheet rather than by emulating reduced motion,
  and assert the applied root size per cell** — that assertion is the only thing
  that distinguishes this from a clean sweep. Found by `adversarial-reviewer`,
  round 2, running this section's own published recipe.

  ✅ **THE LARGE-TEXT NAV OVERFLOW IS FIXED, 2026-09-01.** Pouya reopened the
  step-1 header decision for the purpose — *"its record attributed the residual to
  the wrong cause and characterized a measured 944 px functional failure as a
  robustness margin"* — and ruled *fix, do not accept*. What follows is the
  current state. The narrow case was ruled a defect on 2026-08-31 (*"the
  152/112/82 px overflows at 320/360/390 with 32 px root text violate WCAG 1.4.10
  and are not accepted"*) and fixed then.

  **THREE MECHANISMS ENLARGE TEXT, AND THEY ARE NOT EQUIVALENT — this is the
  measurement the whole record turned on.** Every figure in this section before
  2026-09-01 came from `documentElement.style.fontSize = '32px'`. A later sweep
  used Chrome's `Page.setFontSizes({standard: 32})`, reported 0 everywhere, and
  the prose generalised that zero. All three are re-measured below.

  | mechanism | `rem` in a media query | `rem`/`em` in a PROPERTY | `getComputedStyle` root | sees the enlargement? |
  |---|---|---|---|---|
  | `documentElement.style.fontSize='32px'` (root style) | **16 px → `66rem` = 1056 px** | 32 px | 32 px | media query **no**, property **yes** |
  | `Page.setFontSizes({standard:32})` (the reader's *default font size*) | 32 px → `66rem` = **2112 px** | 32 px | 32 px | **yes, both** — the breakpoint moves with the type |
  | `--blink-settings=minimumFontSize=32` (the reader's *minimum font size*) | 16 px → `66rem` = **1056 px** | **16 px** | **32 px** | **NO `rem`/`em` CONSTRUCT SEES IT** — the columns of this table are all `rem`/`em`, and that is the limit of what the row measures. ⚠️ **The FONT-METRIC units DO see it** (`ch`, `ex`, `cap`, `lh`, `rlh`); see the table below |

  *(Row 1's media-query cell read "32 px → 2112 px" for one revision, which
  contradicted its own verdict column, the paragraph below it, and measurement —
  and it deleted the one number that explains why the failure is reachable at all.
  If `66rem` really resolved to 2112 px under root scaling, the 66 rem desktop
  masthead would never be reached at 1280 px and the 944 px overflow could not
  happen. Found by `adversarial-reviewer`.)*

  Two consequences, both measured 2026-09-01 and both load-bearing:

  1. **In a media query `rem` resolves against the browser's DEFAULT font size,
     not the root element's.** So raising the *default* moves the breakpoints
     along with the type and the desktop masthead is never reached; setting the
     *root* doubles the type and leaves the breakpoints where they were, which is
     the layout the desktop nav was measured in. **A container query is the one
     construct that differs** — `@container` `rem`/`em` DO resolve against the
     root element, measured — which is why the sticky gate below is a property and
     not a query.
  2. ⚠️ **UNDER A MINIMUM-FONT-SIZE SETTING, `getComputedStyle(el).fontSize` AND
     THE `em` UNIT DISAGREE.** Blink floors the *reported computed* font size to
     32 px while `em` and `rem` keep resolving at 16 px — so `scroll-padding-top:
     6.0625em` computes to **97 px, not 194 px**, a `66em`-wide box measures
     **1056 px, not 2112 px**, and `min(0px, calc(100vw - 66em))` is **0px**.
     ⚠️ **AND THE SENTENCE THAT USED TO SIT HERE WAS FALSE AND LOAD-BEARING: it
     said "media queries, container queries and length units are all blind to it"
     and that "only used-value layout — wrapping — responds".** It is the
     `rem`/`em` FAMILY that is blind, not CSS. The **font-metric** units read the
     *used* font size and therefore double, and they do so in all three
     constructs — measured 2026-09-01 on `/fees/` @1280, headless Chrome, one
     probe element per cell:

     | construct | `rem`, `em`, `ic`, `px` | `ch`, `ex`, `cap`, `lh`, `rlh` |
     |---|---|---|
     | property value | blind (16 px → 16 px) | **responds** — `ch` 10.608 → 21.216 px, `ex` 8.48 → 16.96, `cap` 11.36 → 22.72, `lh` 25.59 → 51.19 |
     | `@media (min-width: N<unit>)` | blind — threshold never flips | **responds** — `100ch`, `110ex`, `80cap`, `45lh` all flip |
     | `@container (min-width: N<unit>)` | blind | **responds** — `45ex`, `32cap` flip |

     So wrapping is still the right mechanism for *reflow* — it needs no
     threshold and no fitted constant — but **"no CSS can detect this setting" is
     not true, and the residual below is therefore not provably unfixable.**
     Found by `adversarial-reviewer` and reproduced independently.

  **Before and after, 22 pages × 16 widths (320 → 1920 px) = 352 page-widths per
  setting, document overflow `documentElement.scrollWidth −
  documentElement.clientWidth`. Both columns measured on the SAME grid**, from a
  build of the previous commit and a build of the working tree, by the same probe:

  | text setting | before | after |
  |---|---|---|
  | default (root 16) | 0 of 352 | **0 of 352** |
  | root style 32 px | **175 of 352** | **0 of 352** |
  | default font size 32 | 0 of 352 | **0 of 352** |
  | minimum font size 32 | **219 of 352** | **0 of 352** — the header fix left 88, all of them the footer; the footer fix below closed them, 2026-09-01 |

  ✅ **SO: ZERO DOCUMENT OVERFLOW UNDER ALL FOUR METHODS AT EVERY WIDTH
  MEASURED — AND THE SCOPE OF THAT SENTENCE IS EXACTLY THE GRID ABOVE.** 22 built
  pages × those 16 widths × four enlargement methods = **1,408 page-widths**,
  document overflow by `documentElement.scrollWidth − documentElement.clientWidth`,
  webfonts loaded, six nav items, `prefers-reduced-motion` neutralised by an
  injected sheet rather than emulated. Plus **762** further points for the sticky
  gate (roots 9–15, roots 16–32, the band seam, both thresholds, all five Chrome
  presets), 0 failing.

  ⚠️ **It is not a claim about anything outside that grid, and "no document
  overflow" is not "no accessibility defect".** Three known cases sit outside it
  deliberately. The **fallback-metrics case** below needs the webfonts blocked and
  a seventh nav item. The **focus-obscuring case** below was a **WCAG 2.2
  SC 2.4.11 (AA) failure**, now **fixed and closed** — `AGENTS.md` Q61 — and it is
  the sharpest illustration of the warning above: **document overflow could not see
  it at all**, because nothing overflowed. The header simply covered what had
  focus, on 290 of 1,455 stops, while every zero in the table above stayed a zero.
  A residual at `minimumFontSize=16` and `=20` remains, is pre-existing, and is
  likewise invisible to this grid. And a
  **footer nav label** still overruns its own column by 24 px at 640 px under
  minimum font size with 7.7 px of clearance, again with zero document overflow.
  None of the three is contradicted by the zeros above, and none of them is
  measured by them — which is the reason each is recorded in its own right rather
  than summarised into the table. Widths
  between the sampled ones are not measured either — the grid is 16 columns, not a
  continuum, and the two thresholds and the band seam were swept precisely because
  a 16-column grid can step over a 36 px band.

  **The wide-width figures that were the defect, root style 32 px, and what they
  are now.** Every one is 0 of 22 pages after the fix, and the nav items and the
  CTA are on-screen at every width:

  | width | before | after |
  |---|---|---|
  | 1056 | 649 px, 22 of 22 | **0** |
  | 1100 | 606 px, 22 of 22 | **0** |
  | 1216 | 928 px / 491 px on `/`, 22 of 22 | **0** |
  | 1240 | 904 px / 468 px on `/` | **0** |
  | 1280 | **944 px** / 508 px on `/` | **0** |
  | 1440 | 784 px / 351 px on `/` | **0** |
  | 1600 | 624 px / 193 px on `/` | **0** |
  | 1920 | 304 px, 21 of 22 | **0** |

  *(Only 1280 and 1920 were in the earlier record, so it never showed that the
  failure ran the whole width of the sticky range. The same run under minimum font
  size was 414 / 370 / 854 / 830 / 830 / 750 / 670 / 510 px, of which the record
  carried only the 830.)*

  ⚠️ **AND IT WAS NOT A MARGIN — IT WAS UNREACHABLE NAVIGATION.** The furthest
  element was `div.header-cta` at **2224 px** against a 1280 px viewport; the nav
  clipped mid-word after "Arbitration", and **Practice, Fees, Contact and the
  header CTA sat entirely off-screen** behind a horizontal scrollbar — the route
  to the inquiry form among them. WCAG 1.4.4 with loss of functionality. The
  paragraph struck here called it *"a robustness margin rather than a failure.
  Revisit if a real reader hits it."*

  **THE FIX IS TWO DECLARATIONS, AND THE SECOND ONE IS THERE BECAUSE THE FIRST
  ONE HAS A CONSEQUENCE.**

  **(1) The masthead may wrap.** `flex-wrap: nowrap` is gone from `.header-inner`
  and from `.nav-list` above 66 rem, along with the dead `flex: none` beside it.

  ⚠️ **WHICH OF THE TWO WAS THE CAUSE IS NOW MEASURED, AND THIS PARAGRAPH FIRST
  GOT IT WRONG.** It said *"that pair, not any one declaration, was the cause"*.
  Restoring each declaration alone on the fixed build, root 32, `/about/` —
  document overflow / number of nav links and CTA off-screen:

  | restored above 66 rem | 1056 | 1216 | 1280 | 1440 | 1920 |
  |---|---|---|---|---|---|
  | neither (shipped) | 0/0 | 0/0 | 0/0 | 0/0 | 0/0 |
  | `.nav-list { flex-wrap: nowrap }` only | 0/0 | 0/0 | 0/0 | 0/0 | 0/0 |
  | `.header-inner { flex-wrap: nowrap }` only | 0/0 | 273/1 | 209/1 | 49/1 | 0/0 |
  | both (= the state before) | 649/3 | 928/5 | 944/5 | 784/4 | 304/1 |

  **`.header-inner`'s `nowrap` was necessary and sufficient.** And the second row
  is the one that matters for honesty: **`.nav-list`'s removal is inert** — byte-
  identical to shipped at every width, under a 200 % root size *and* under minimum
  font size, **with six nav items and with seven**. It is kept removed for two
  reasons that are not "it fixed the overflow": the `nowrap` prohibition in
  `SiteHeader.astro` would otherwise contradict a `nowrap` still sitting in the
  file, and the override only ever re-stated `nowrap` over a base rule that already
  wraps. Found by `adversarial-reviewer`; the mechanism sentence about min-content
  was true and was not the binding constraint. *(`flex` is a flex-ITEM property and `.nav`
  computes `display: block`, measured at 1056 / 1280 / 1920 px — so `flex: none`
  set `flex-shrink: 0` on something that is not a flex item and had **no effect**.
  Removing it leaves `.nav`'s and `.nav-list`'s geometry byte-identical at all
  three widths; the only trace was the computed `flex-shrink`, 0 → 1. Its comment
  claimed it was what stopped the nav being squeezed, which it never was.)*
  **It cost nothing at any normal size: 0 geometry
  differences across 22 pages × 16 widths (352 page-widths)**, header exactly **81.00 px** at every
  width from 1056 px up, brand on one line, nav on one line, CTA exactly on
  `.header-inner`'s content edge (gap 0.00 px) — **and the same with a seventh nav
  item injected**, at 1024 / 1047 / 1056 / 1071 / 1100 / 1150 / 1200 / 1216 / 1240
  / 1280 / 1440 / 1920 px, where all seven share one line from 1056 px up. So the
  `nowrap` was not load-bearing at any width above the breakpoint; the 66 rem
  breakpoint is what keeps the row intact, and it already accounts for seven items.

  **(2) The masthead is sticky only while it is one row**, and this half took two
  attempts — the first one shipped a regression, which is recorded because the
  reason it failed is the useful part.

  Wrapping makes the header **taller** at enlarged text: **244.59–350.86 px** at a
  200 % root size against 81 px normally. A sticky box that size covers `#main`
  after "Skip to content", so stickiness has to go wherever the header can exceed
  `scroll-padding-top`. The gate is a **property**, not a query, because in a
  property `rem` tracks the root element.

  ⚠️ **ROUND 1 WROTE `min(0px, calc(100vw - 66rem))` AND IT WAS WRONG IN TWO WAYS
  THAT ONLY AN INTERMEDIATE ROOT SIZE EXPOSES.** Both were found by
  `adversarial-reviewer` and independently reproduced: **20 of 300**
  (page × viewport × root) points left `#main` behind the header, 10–69 px, across
  roots 18–30 — while root 16 and root 32, the only two sizes the first sweep
  measured, were both clean. **WCAG 1.4.4 is a requirement up TO 200 %, not AT
  200 %**, and a two-point sweep cannot see a diagonal band.

  1. **It RAMPED where it needed to STEP.** One pixel inside the threshold the term
     lifts the header by one pixel — but the header has already gained a whole row,
     so it still covered `#main`. Wrapping is a step function; the response has to
     be one too. Hence the `* 100000` saturation, bounded by `-100vh`.
  2. **It used the wrong threshold in the wider band.** The tagline appears at
     76 rem, and with it the one-row masthead fits only from **1207 px = 75.4 rem**
     — the step-1 binary search already recorded that number. Gating the wide band
     on 66 rem therefore fired far too late. **`/` measured clean throughout, and
     that is what identified the driver:** `/` is the one page that suppresses the
     masthead tagline.

  ⚠️ **AND ROUND 2 FOUND THAT THE GATE WAS ONE-SIDED — it could only fire when the
  root was LARGER than the default.** Chrome's "Font size" control has **five**
  presets (Very small 9 px, Small 12, Medium 16, Large 20, Very large 24) and the
  sweeps had used 16 and 32 — 32 is not one of them. At **9 px the masthead wraps
  for the opposite reason**: `--width-content` is `80rem`, so the content column
  shrinks to 720 px while the header's `min-inline-size: 44px` / `min-block-size:
  44px` floors do not, and the row wraps at **every** viewport width. The header
  stood at **120 px against a 54.56 px `scroll-padding-top`** — **65 px of `#main`
  behind it on the 21 pages that render the tagline**, at 1056 through 1920 px.
  `/` measured 12 px, and that 12 px is **pre-existing**: the previous build is 67 px
  against the same 54.56 px offset on all 22 pages. So the wrap fix widened a
  pre-existing 12 px defect to 65 px, and the second term closes both.

  **The shipped form is two bands, each gating on the width ITS layout requires,
  and two terms, each catching one direction:**

  ```css
  @media (min-width: 66rem) { .site-header {
    position: sticky;
    inset-block-start: clamp(-100vh,
      min(calc((100vw - 66rem) * 100000), calc((1rem - 16px) * 100000)), 0px); } }
  @media (min-width: 76rem) { .site-header {
    inset-block-start: clamp(-100vh,
      min(calc((100vw - 76rem) * 100000), calc((1rem - 16px) * 100000)), 0px); } }
  ```

  `1rem - 16px` is negative exactly when the root is below the CSS initial font
  size — the 16 px the whole rem scale is built on — and it also catches the
  root-style equivalent, where the previous form left the header sticky at 69 px
  against a 60.63 px offset at root 10. **The cost, measured and accepted:** a
  reader whose default text size is "Small" (12 px) loses the sticky header, where
  it currently works — but only just: the header is 73 px against a 72.75 px offset,
  a **0.25 px** margin. Trading a 0.25 px margin for a provable gate is the right
  way round.

  Both thresholds are the existing layout breakpoints, and both sit just above the
  measured one-row fit width (1047 px ≈ 65.4 rem without the tagline, 1207 px ≈
  75.4 rem with it), so the gate fires **at or before** the wrap rather than after
  it. **At every normal size both evaluate to exactly `0px`** — a matched
  `min-width: 66rem` guarantees `100vw ≥ 1056 px` and a matched `min-width: 76rem`
  guarantees `100vw ≥ 1216 px`, because `100vw` counts a classic scrollbar and the
  query width does not, so the term can only be more positive.

  **Measured after: 0.00 px of `#main` covered — 0 of 300 grid points across roots
  16–32 × viewports 1056–1920 on three pages, 0 of 176 rows at the default size and
  at a 200 % root size over all 22 pages, 0 of 144 cases sitting directly on the
  two thresholds, and 0 of 198 at the SEAM where the two bands meet** (viewports
  1180–1260 × roots 16–32). ⚠️ **`covered: 0` is also what a non-sticky header
  gives, so the seam was checked the other way round as well:** at the default size
  across 1180 / 1200 / 1210 / 1215 / 1216 / 1217 / 1220 / 1240 / 1260 / 1440 /
  1920 px the computed `inset-block-start` is `0px` and the header is still pinned
  at top 0.00 when scrolled — stickiness is preserved, not quietly lost. ⚠️ **Saturation leaves a transition band, and it is
  arithmetic rather than measured:** a finite factor means the response is only
  a near-step, so the band is about (header − `scroll-padding-top`) / factor ≈
  **0.0007 px** of viewport width. CDP takes integer viewport widths, so that band
  was not driven directly — it is bounded by the arithmetic, not by a probe.

  *(Lightning CSS folds the factor into the units and emits
  `clamp(-100vh,10000000vw - 6600000rem,0px)`. Verified equivalent by measurement,
  not by reading: the computed `inset-block-start` is `0px` at every sticky width at
  the default size, and the header pins at top 0.00.)*

  ⚠️ **"AN OFFSET TOO SHORT CANNOT ARISE" WAS WRITTEN HERE AND IN TWO SHIPPED
  COMMENTS, AND IT IS FALSE. THE EXCEPTIONS ARE ENUMERATED RATHER THAN WAVED AT**,
  because a comment that says "cannot" is the kind that stops the next reader
  looking. The gate handles **root-relative** enlargement in both directions.
  What it cannot see, measured, header height against computed
  `scroll-padding-top`, header `top` = `0px` in every row:

  | condition | header | offset | short by | status |
  |---|---|---|---|---|
  | `minimumFontSize=32` | 164.58–270.56 px | 97 px | **68–174 px** | 🛑 **OPEN — needs a fresh ruling.** The 2026-09-01 acceptance rested on two facts that are both false; and the real cost is **290 entirely-obscured focus stops, SC 2.4.11 AA**, not a short skip-link landing. **A pure-CSS detector DOES exist.** See below |
  | fallback font metrics + 7th nav item, **default** text size, 1056–1091 px | 141 px | 97 px | **44 px** | latent on `showInsights`. **HARD GATE: `AGENTS.md` R20 — the seventh item does not ship until this is fixed** |
  | `defaultFontSize=9` | 120 px | 54.56 px | ~~65 px~~ | **fixed** by the `1rem - 16px` term |
  | root-style 10 px | 69 px | 60.63 px | ~~8 px~~ | **fixed** by the same term |

  **`--header-h` IS A FLOOR, NOT A CONSTANT**, and that is the sentence that
  had to change. It is the header's height at the **default** text size; above the
  default the masthead is deliberately taller, and declaration (2) is what makes
  that safe — where the gate can see the header exceed the token it is not sticky,
  so a `scroll-padding-top` that is too *generous* is harmless. ⚠️ **It does NOT
  make a short offset impossible: the two cases the gate cannot see are tabulated
  above.** The token previously asserted "one constant 81 px across
  every width where it is sticky", and that sentence is what made a 944 px
  overflow read as settled.

  **What the narrow-width fix DID establish, and it is worth keeping separate.**
  The narrow residual had been charged to that same `flex-wrap: nowrap` — and for
  the narrow case that attribution was **wrong**. The cause there was
  `white-space: nowrap` on `.brand-name`, a different declaration in the same
  component, and removing it **changes nothing at any real size**: the brand name
  is one line at all 16 widths at root 16, the sticky header still measures exactly
  81 px at every width from 66 rem up, and the CTA still lands exactly on
  `.header-inner`'s content edge. **A residual defended by the wrong cause is
  defended forever**, because the reason given is one nobody wants to re-open —
  which is exactly what happened for four days.

  **ELEVEN FIXES ACROSS THREE PASSES, IN TWELVE ROWS — no `overflow-x` was added
  anywhere.** Eight are narrow-width (2026-08-31), two are the large-text nav
  (2026-09-01), and the eleventh is the footer email (2026-09-01, the pass that
  closed the last recorded overflow). ⚠️ **The twelfth row is `.nav-list`, and it
  is a row without being a fix:** it is here because its removal was *measured*,
  and it is not counted because the measurement was that it changes nothing. Say
  so rather than leaving the arithmetic to a reader who counts rows — the heading
  read "TEN FIXES" over eleven rows until 2026-09-01 for exactly this reason. All
  but one of the eleven are cause-specific; the exception is marked as the
  backstop it is:

  | Element | Was | 320 px | Cause |
  |---|---|---|---|
  | `SiteHeader .header-inner` | `flex-wrap: nowrap` removed above 66 rem | **944 px** at 1280 px, root 32 | **Necessary and sufficient, measured.** A `nowrap` flex line cannot break, so the brand / nav / CTA row could not reflow at all |
| `SiteHeader .nav-list` | `flex-wrap: nowrap` and a dead `flex: none` removed above 66 rem | **0 px — inert** | Kept removed so the `nowrap` prohibition is not contradicted by a `nowrap` in the same file. Byte-identical to shipped at every width and every text setting, six items and seven |
  | `SiteHeader .site-header` | `inset-block-start: 0` → a saturating `clamp()` gate, in **two** bands (66 rem, and 76 rem where the tagline shows) | *(consequence of the row above)* | Wrapping makes the header 244.59–350.86 px at root 32; sticky at that height covered `#main` by up to 157 px after the skip link. **Round 1's single-band `min()` ramped instead of stepping and left 20 of 300 grid points covered by 10–69 px** |
  | `SiteHeader .brand-name` | `white-space: nowrap` removed | **63 px, all 22 pages** | Two words glued into one unbreakable box |
  | `/bio/ .rates-list` | `overflow-wrap: anywhere` | **152 px** | `https://adr.smlcompany.ca/fees/` has no break opportunity, and the single grid track it sized stretched all five rows to 424 px |
  | `/ .hero-h` | `overflow-wrap: anywhere` | 36 px | "contract," at 104 px held `.hero-copy` open |
  | `/ .feature-body` | `overflow-wrap: anywhere` | 26 px | "party-appointed" at 202 px |
  | `CredentialRow .credential-label` | `overflow-wrap: anywhere` | 38 px | "designation" needs 143 px in an 88 px track |
  | `SiteFooter .footer-contact a[href^='mailto:']` | `overflow-wrap: anywhere` | **14 px** | `info@smlcompany.ca` has no break opportunity and demands 310 px. Minimum-font-size only; also 38 / 30 / 19 px at 1024 / 1056 / 1100 px, by a different mechanism — see the footer block above |
  | `SiteFooter .footer-brand` | `flex-wrap: wrap` | 12 px | Flex item at `min-width: auto` cannot shrink below "Lajevardi" |
  | `PracticeCard .card` | `padding` clamped | *(the cause under `Pill`)* | The space scale is rem-based, so `--space-6` is 64 px a side at root 32 — 128 px of padding in a ~224 px box |
  | `Pill` | `overflow-wrap: anywhere` | 33 px → **1 px** | ⚠️ **SYMPTOM, NOT CAUSE.** A one-word pill cannot wrap at a space that is not there |

  `flex-wrap: wrap` on the footer brand rather than `anywhere`, because it reflows
  without hyphenating a person's name.

  ⚠️ **`Pill`'s `anywhere` IS A BACKSTOP AND THE TRADE IS RECORDED RATHER THAN
  HIDDEN.** It removes the min-content floor of a shrink-to-fit `inline-flex` box,
  so the pill collapses to whatever its parent gives it. The real cause was
  `PracticeCard`'s padding: with it clamped, "Construction" at root 32 / 320 px
  went from **94 × 220 px broken into six two-character lines** to **158 × 85 px on
  two lines**, and root 16 is unchanged at 121 × 27 px on one line. **`anywhere` is
  still load-bearing** — removing it leaves 1 px of document overflow on `/`,
  `/mediation/` and `/practice/`, and renders the pill 240 px wide inside a 224 px
  card, escaping its own rounded border. Two lines is the better of those. The
  clamp does not change any normal size: 10vw holds 32 px from 320 px up.

  **TEN instrument findings, and each one hid a real defect. Items 4–6 are from the
  2026-09-01 header pass and all three produced a CLEAN-LOOKING result; 7–10 are
  from the footer pass the same day. Each is recorded once — the footer block above
  points here rather than restating them.** ⚠️ **Finding 2 RECURRED in that footer
  pass**, in a probe written by the person who had written finding 2 down: it is
  described where it did its damage, beside the footer fix, and not duplicated as
  an eleventh item.


  4. ⚠️ **A UNIFORM PASS FROM A TAUTOLOGY.** The skip-link probe reported
     `0.0 px of #main covered` on **946 of 946** page-widths, before and after,
     under every mechanism. `global.css` sets `scroll-behavior: smooth`, which
     makes `scrollIntoView()` **asynchronous**, so a synchronous read afterwards
     measures `scrollY = 0`; and at `scrollY = 0` the target sits exactly at the
     header's bottom edge, so `covered` is 0 **by construction**. Pass
     `behavior: 'instant'` and assert that `scrollY` equals its predicted value —
     once fixed the same probe reported 10–26 px covered on 22 of 22 pages, a
     pre-existing defect the tautology had hidden.
  5. ⚠️ **A RUNNING TRANSITION MAKES A PROPERTY READ RETURN THE OLD VALUE.**
     Forcing reduced motion — by CDP emulation *or* by
     `--force-prefers-reduced-motion` — made `documentElement.style.fontSize =
     '32px'` read back as **16 px**, while the inline `style` attribute plainly
     said `font-size: 32px`. This codebase's reduced-motion block sets
     `transition-duration: 0.01ms !important` on `*`, which starts a transition on
     **every** property change, and a synchronous `getComputedStyle` then returns
     the transition's *start* value. The instrument now injects
     `transition:none;animation:none` instead. Same family as *a running
     transition outranks an `!important` author declaration*.
  6. **A DOM-INJECTED ELEMENT RECEIVES NO SCOPED STYLES.** Astro scopes component
     CSS with a `data-astro-cid-*` attribute, so the hand-built
     `<a class="nav-link">` used to test a seventh nav item got **none** of
     `.nav-link`'s rules — no `min-inline-size`, no `min-block-size`, no
     `font-size` — and measured narrower and shorter than a real item, which is
     the direction that makes a width test pass. **Clone a real node** and assert
     its computed styles match a sibling's.

  7. ⚠️ **A CAUSE READ OFF A TRUNCATED LIST.** The header harness capped its
     offender array at `slice(0, 20)` while reporting `offenderCount` beside it,
     and **44 of the 88 failing rows exceeded the cap** — so the enumeration that
     was supposed to name the footer's cause was silently missing 34 of the 54
     boxes at 320 px. The truncation was visible only to a reader who compared the
     two numbers. Same family as the `tail -3` rule in `CLAUDE.md`, through a
     different pipe.
  8. ⚠️ **`grep -c` COUNTS LINES, NOT OCCURRENCES, AND MINIFIED CSS IS ONE LINE.**
     `grep -c 'overflow-wrap:anywhere' dist/_astro/*.css` returned `1` for a file
     that holds **three** such declarations. It was being used to confirm the new
     rule had reached `dist/`, which it could not do. Extract and print the bytes
     instead — the rule that actually settled it was reading the emitted selector,
     `.footer-contact[data-astro-cid-nns7i3if] a[data-astro-cid-nns7i3if][href^=mailto\:]`.

  9. ⚠️ **`getClientRects().length` IS 1 FOR A `display: flex` ELEMENT HOWEVER MANY
     LINES OF TEXT IT HOLDS** — it is one block box, not a fragmented inline. The
     wrap probe therefore reported `lines=1` for the footer email while its own
     `height` said **102.38 px = 2 × 51.19**, i.e. two lines. Line counts come from
     `Range` rects over the text, which do fragment per line. **Two metrics of the
     same quantity disagreeing is the cheapest defect detector in this section** —
     it is what caught this one.
  10. ⚠️ **`Page.captureScreenshot`'s `clip` IS IN PAGE COORDINATES, NOT VIEWPORT
     COORDINATES.** Given a `getBoundingClientRect()` taken after a scroll, it
     captured a **blank cream plate** — of a footer that is ink. The screenshot
     existed to be the independent second method for a break the numbers could not
     judge, so a silently wrong one is worse than none. Add `window.scrollX/Y`, or
     pass `captureBeyondViewport: true` and page coordinates.

  The original three:

  1. **`overflow-wrap: break-word` permits a break at layout time but does not
     reduce min-content size** — `anywhere` does. Five of the fixes are this
     distinction. `global.css:166` sets `break-word` on **`p` AND `h1`–`h6`** —
     *(this line said "`h1`–`h6` and nothing else, so body copy inherits no
     wrapping at all", which was wrong in a way that mattered: `.feature-body`
     **is** a `<p>` and already had `break-word`, so the premise given for its fix
     was false while the fix itself was right)*. Nothing else gets one, so a
     `<span>`, `<li>`, `<dd>` or `<a>` inherits no wrapping.
  2. **`getBoundingClientRect()` reports BORDER BOXES, so an element sweep cannot
     see text spilling outside its own box.** `.credential-label`'s words ran 86 px
     past an 88 px cell while every element's rect stayed inside the viewport —
     the document was 38 px over and the offender was invisible to the predicate
     this table's own command uses. Read `scrollWidth - clientWidth` per element as
     well as per document.
  3. **Under `Emulation.setDeviceMetricsOverride({mobile: true})` the LAYOUT
     viewport expands to fit the content**, so `innerWidth` becomes 472 at a
     requested 320 and `scrollWidth - innerWidth` reads **0** while the reader is
     still scrolling sideways. The honest formula is
     `documentElement.scrollWidth - documentElement.clientWidth`, which is correct
     in both modes.

  ✅ **THE FOOTER RESIDUAL IS FIXED, 2026-09-01 — ONE DECLARATION, AND THE
  EARLIER RECORD MISDIAGNOSED HALF OF IT.** Under Chrome's minimum font size the
  document overflowed at four widths on all 22 pages — **14 px at 320, 38 px at
  1024, 30 px at 1056, 19 px at 1100** — and 0 from 1200 px up. One cause at all
  four: `info@smlcompany.ca` has no break opportunity, so its **min-content width
  is 310 px**.

  | Element | Was | Fix | Effect |
  |---|---|---|---|
  | `SiteFooter .footer-contact a[href^='mailto:']` | `overflow-wrap: normal` | `overflow-wrap: anywhere` | **88 of 352 → 0 of 352** |

  ⚠️ **TWO MECHANISMS, ONE CAUSE — and this is the part the earlier record got
  wrong.** It said the 1024–1100 px half "looks like one `overflow-wrap: anywhere`
  on the footer contact links" and that "the 320 px half is a column-sizing
  question and is not the same fix". **It is the same fix.** The column sizing at
  320 px is *driven by* that same 310 px:

  - **At 320 px** `.footer-grid`'s implicit track is `auto`, whose minimum is
    min-content, so the track — and every `.footer-col` in it — measures **310 px
    inside a 272 px content area**. The boxes themselves cross the viewport edge:
    **54 elements** did, right edge 334 px against a 320 px client width.
  - **At 1024 / 1056 / 1100 px** the contact column is `minmax(0, 1fr)` — a **0**
    minimum, so the track does not grow — and the box stays **224 / 232 / 243 px**
    while the text spills **86 / 78 / 67 px outside it**. **No element's border box
    crosses the viewport edge at all** at those widths.

  Reducing one min-content width closes both halves.

  ⚠️ **AND IT CLOSED A THIRD CASE THAT THE FOUR-METHOD TABLE REPORTED AS CLEAN —
  "MEASURE THE ELEMENTS, NOT ONLY THE PAGE", WHICH IS ALREADY A RULE IN THIS
  SECTION.** With the fix disabled as a control, over 420 points (3 pages × 10
  widths × 6 minimum-font-size presets and 8 root sizes), **69 failed: 12 by
  document overflow and 57 by the link overrunning its OWN box while the document
  measured 0.** Those 57 sit at **root style 26 / 28 / 30 / 32 px** and at
  **`minimumFontSize` 24 and 32** — and root style 32 px is a row the table above
  reports as **0 of 352**, truthfully, because it is a document measurement.

  **Why it never reached the viewport edge, measured rather than surmised:**
  `.wrap` carries a **96 px** right gutter at that size, and the spill is smaller
  than the gutter. At root 32 on `/about/` the link's box ends at 928 px and its
  text at **1007.3 px** against a **1024 px** client width — 79 px of spill sitting
  inside 96 px of padding. The spill shrinks as the viewport widens (79 / 71 / 60 /
  35 / 15 / 0 px at 1024 / 1056 / 1100 / 1200 / 1280 / 1440), which is why the case
  disappears at 1440 px rather than at a breakpoint.

  **After the fix: 0 of 420, and 0 clipping at every preset and every root size.**
  The control is what makes that number mean anything — a sweep returning zero on
  every cell is the shape this section warns about twice, so it was re-run with the
  declaration forced back to `normal` and it failed 69.

  ⚠️ **AND THE ELEMENT SWEEP THAT LOOKED FOR THE CAUSE REPORTED "NONE" AT THREE
  OF THE FOUR WIDTHS** — instrument finding 2 in this section, committed again by
  the person who wrote it down. `getBoundingClientRect()` reports **border boxes**,
  so a `right > clientWidth` predicate cannot see text spilling out of a box that
  is itself inside the viewport, which is precisely the 1024–1100 px mechanism.
  The document figure was right and the offender list was empty, and those two
  facts together are the signature of this bug. **Read `scrollWidth − clientWidth`
  per element as well as per document.**

  ⚠️ **And the harness's offender list was truncated at 20 entries on 44 of the 88
  failing rows**, so it could not have named the cause either — instrument finding
  **7** below.

  **What the fix costs, measured rather than asserted.** At the default text size,
  **nothing**: the address is one line, **44.00 px** tall — exactly the touch-target
  floor — at all 16 widths, and the normal-settings identity check is 0 differences
  on 352 page-widths. Under minimum font size it wraps to two lines and the break
  is mid-token — `info@smlcompany` / `.ca` at 320 px, `info@smlcomp` / `any.ca` at
  1024 px, `info@smlcompa` / `ny.ca` at 1100 px — read out of the DOM one character
  at a time and confirmed on a screenshot, not inferred from a width. The `href`
  is untouched (`mailto:info@smlcompany.ca`), every painted glyph is inside the
  viewport in **176 of 176** rows, and the link never clips its own box. A
  mid-token break in an address is cosmetic; a document that scrolls sideways is a
  WCAG 1.4.10 failure.

  **`anywhere`, NOT `break-word` — and that was established with a NEGATIVE
  CONTROL rather than from the rule.** `break-word` permits a break at layout time
  without reducing min-content size, so it leaves the defect untouched: injected in
  place of `anywhere` it failed **88 of 176** rows, the same rows as the unfixed
  baseline. Both the baseline and the control had to fail for the trial to mean
  anything — **a trial in which every candidate passes is a broken trial**, and
  this section already carries five instrument findings of exactly that shape.

  **On the link, not on the column, and not in the markup.** Three candidates all
  reach 0 of 176: `anywhere` on the email link, on `.footer-contact`, and on
  `.footer-col a`. The address is the only string in the footer that produces
  **document** overflow, so the rule sits on the address and the two broader
  selectors were declined as broader than the cause.

  ⚠️ **THE REASON FIRST GIVEN FOR THAT SCOPING WAS THE WRONG TEST, AND IT IS WORTH
  MORE THAN THE SCOPING.** It said *"the address is the only string in the footer
  with no break opportunity — the location line, the response sentence and the
  sixteen nav labels all have spaces"*. **A space is not the test. Min-content is
  set by the longest WORD**, so a label with spaces still overruns its track when
  one of its words does not fit. `adversarial-reviewer` found one that does, and it
  reproduced at a width the review had not sampled:

  | width | element | own-box overrun | clearance to the next column | document |
  |---|---|---|---|---|
  | 640 px | `.footer-col a` "Construction & Infrastructure" | **24 px** out of a 176 px box | **7.7 px** | 0 |
  | 640 px | `.footer-col a` "Shareholder & Family Business" | 2 px | 7.7 px | 0 |
  | 700 px | `.footer-col a` "Construction & Infrastructure" | 4 px out of a 196 px box | 27.7 px | 0 |

  `minimumFontSize=32`, all 22 pages, 12 widths from 320 to 1024 px = 264 rows;
  clean at every other width sampled, including 768 and 834 px. **"Infrastructure"
  is 14 characters and does not fit a 176 px track at 32 px** — the space in the
  label is irrelevant to that.

  ⚠️ **AND THE 12-WIDTH GRID STEPPED OVER TWO MORE**: round 2 found the same label
  at **17 px @660 and 11 px @680**, widths this grid does not sample. That is this
  section's own caveat holding — *the grid is 16 columns, not a continuum* — and it
  is the second time in one session that a between-columns width mattered.

  **A FOURTH CASE OF THE SAME FAMILY, and it should be ruled on together with the
  footer label rather than separately.** `minimumFontSize=32`,
  `/practice/construction/` @320 px: `nav.crumbs > ol` overruns its own 272 px box
  by **7 px**, furthest text edge 302.9 px against a 320 px client width,
  `overflow-x: visible`, no clipping, **document overflow 0**. Clean at 360 / 390 /
  414 px and on the other five practice pages. **No success criterion fails**, so
  like the footer label it is recorded rather than fixed — but if
  `.footer-col a { overflow-wrap: anywhere }` is ruled in, the same call covers
  `.crumbs` and the ruling should be taken once for both. Raised by
  `adversarial-reviewer`, round 2.

  **Not fixed here, and the reason is a scope judgement rather than a measurement.**
  It produces **no document overflow at any width**, so it fails no success
  criterion; `.footer-col a { overflow-wrap: anywhere }` is measured to close it
  and to be inert at normal settings. What it would change is how six practice-area
  names break on a marketing surface under enlargement, which is a copy-adjacent
  call. ⚠️ **The maintenance risk is the real finding: 7.7 px of clearance is one
  label rename away from two columns colliding**, and nothing in the build measures
  it. Pouya's to rule on; `docs/06` carries it. `word-break: break-all` also
  reaches 0 and was declined for the same reason: it breaks where a normal
  opportunity exists. **And NOT a `<wbr>` after the `@`**, which would give a
  prettier break: it splits a §4-registered fact across an element boundary, so
  `info@smlcompany.ca` would no longer be greppable in `dist/` — the surface
  `npm run check:claims` reads — and its longest unbreakable run (`smlcompany.ca`,
  ~224 px) does not fit the 224 px column at 1024 px anyway, so it would need
  `anywhere` as a backstop regardless.

  **Not header-side, and that survives the fix:** no header element extends the
  document at any width under any of the four mechanisms, and the nav items and CTA
  are on-screen in **1408 of 1408** measurements. *(This said "946 of 946" for one
  revision. 946 is a different sweep — the four runs made with the tautological
  skip probe in instrument finding 4 — and reusing it for the final build was the
  two-similar-totals mistake this section keeps warning about.)* *(The Practice
  dropdown panel's contents overflow their own box by 84 px under minimum font
  size and 40 px at the default, on all 22 pages — unchanged by this fix, and it
  never extends the document because the panel sits inside a **closed**
  `<details>`. Re-checked after the fix rather than carried forward.)*

  🛑 **THE MINIMUM-FONT-SIZE STICKY RESIDUAL IS BACK OPEN, AND IT IS NOW A
  CONFORMANCE FAILURE RATHER THAN A CONVENIENCE LOSS. IT NEEDS A FRESH RULING —
  THE ONE OF 2026-09-01 WAS TAKEN ON TWO FACTS THAT ARE BOTH WRONG.** Pouya ruled
  it accepted on the basis *"you proved no CSS mechanism can see
  minimum-font-size; the only fix is JS and zero-JS is a founding decision."*
  `adversarial-reviewer` attacked both halves of that and both attacks reproduced.

  **(1) THE PREMISE IS FALSE.** The proof was of `rem`/`em` and of queries written
  in them. The font-metric units `ch`, `ex`, `cap`, `lh` and `rlh` all read the
  *used* font size and double under the setting — in property values, in `@media`
  and in `@container`. The table at the top of this section carries the
  measurement. **A pure-CSS detector for this mechanism exists**, so the residual
  is not unfixable and "the only fix is JS" does not hold.

  **(2) THE COST WAS UNDERSTATED, AND BY A CATEGORY RATHER THAN A NUMBER.** The
  record described it as the skip link landing short — 68–174 px of `#main` behind
  the header — and argued *"one of the two is a WCAG 1.4.10 failure while the other
  degrades the convenience of a skip link that still works."* What is actually
  happening is that **ordinary keyboard focus lands entirely behind an opaque
  sticky header**, which is **WCAG 2.2 SC 2.4.11 Focus Not Obscured (Minimum),
  Level AA** — the same conformance level as the 1.4.10 failure it was traded
  against. **So the asymmetry that was the whole argument does not exist: both
  sides are AA failures.**

  **Measured, and the instrument is checked in three ways.** Shift+Tab walk — the
  ordinary way a keyboard user returns to a link they passed — 6 pages × 5 widths
  ≥ 1056 px, 70 steps per cell, elements inside the header excluded:

  | build | mode | focus stops | entirely hidden | zones |
  |---|---|---|---|---|
  | working tree | default | 1,455 | **0** | — |
  | working tree | `minimumFontSize=32` | 1,455 | **290** | 254 footer, **36 `#main`** |
  | `fce89d4~1` (pre-header-fix) | `minimumFontSize=32` | 1,455 | **0** | — |
  | `fce89d4~1` (pre-header-fix) | default | 1,455 | **0** | — |

  ⚠️ **THE THIRD ROW IS THE ONE THAT MATTERS: THE HEADER FIX CREATED THIS.** Before
  it, `flex-wrap: nowrap` kept the masthead one row under this setting, so it was
  short enough that focus landed clear; the overflow went sideways instead. After
  it the masthead wraps to 164.58–270.56 px and covers the 97 px landing. This is
  a **regression introduced by the 2026-09-01 header fix**, not a condition it
  inherited — and the ruling to accept it was taken without that comparison
  existing.

  **Instrument checks, because a focus-obscuring count is easy to fake in both
  directions.** *(a)* The default-mode run returns **0**, so the predicate is not
  tautological. *(b)* ⚠️ **Geometry alone was WRONG and said 43.** All 43 were the
  **skip link**, which is stacked deliberately *above* the header and is not
  covered by it at all — so `elementFromPoint` at the focused box's centre is
  authoritative and geometry only nominates candidates. Under the setting there
  are 333 geometric candidates and **290** survive the hit test. *(c)* Sampled
  hits agree 6 of 6, e.g. `/` @1056: focused `a` "Technology, AI & Data" at
  97 → 199.4 px inside a header at 0 → 228.6 px, `position: sticky`,
  `inset-block-start: 0px`, background `rgb(250, 247, 242)` — opaque cream.

  ✅ **FIXED AND CLOSED — Q61 RULED *fix now*, 2026-09-01. Candidate B SHIPPED.**
  Two candidates existed, and the second was better on the exact ground that had
  deferred the first. The measurements below are the pre-fix state; the acceptance
  sweep that closed it is at the end of this block.

  *Candidate A, round 1:* a third gate term `calc((15px - 1ch) * 100000)`,
  un-sticking the header under the setting while leaving `inset-block-start: 0px`
  at the default. **Deferred:** 15 px is fitted to Geist's `ch`, so it needs
  checking under fallback metrics and Chrome's other font presets, and the
  reviewer's own injection of it was flaky.

  *Candidate B, round 2 — recommended:* `scroll-padding-top`, the property that
  already exists for this job, rather than un-sticking anything. Two declarations
  in the existing `@media (min-width: 66rem)` block:

  ```css
  html {
    scroll-padding-top: calc(var(--header-h) + var(--space-4));   /* fallback: no `lh` */
    scroll-padding-top: max(
      calc(var(--header-h) + var(--space-4)),
      calc(10lh - 83px)
    );
  }
  ```

  **Verified independently — every value read from `getComputedStyle`, not
  reasoned:**

  | condition | `1lh` on `<html>` | computed offset | header | verdict |
  |---|---|---|---|---|
  | default, fonts loaded | 18 px | **97 px — byte-identical to shipped** | 81 px | clears |
  | `minimumFontSize=32`, fonts loaded | 37 px | **287 px** | 270.56 px | clears |
  | default, **every `.woff2` blocked** | **18 px** | **97 px** | 81 px | clears |
  | `minimumFontSize=32`, **`.woff2` blocked** | **37 px** | **287 px** | 270.56 px | clears |
  | `minimumFontSize=32`, family Georgia | 36 px | 277 px | 270.56 px | clears |
  | `minimumFontSize=32`, family Verdana | 39 px | 307 px | 270.56 px | clears |

  ⚠️ **Rows 3 and 4 are why B beats A: `1lh` on `<html>` is immune to the webfont
  fallback.** `<html>` keeps the UA default family — `--font-sans` is set on
  `body`, and `<html>`'s computed `font-family` measures `Times` — so blocking every
  font file changes nothing, and the fallback-metrics caveat that deferred
  candidate A does not apply to B at all.

  **What was said against B before it shipped, and what the sweep did with each.**
  `10lh - 83px` is two fitted constants — the difference from A being that a
  `max()` ramp degrades by pixels if they are off, where A's `* 100000` step flips
  stickiness the wrong way. **The first declaration is load-bearing:** an engine
  without `lh` support drops the whole `max()` as invalid and `scroll-padding-top`
  falls back to `var(--space-4)` = 16 px, which is *worse* than no fix — so it is
  written first, as a plain declaration, and must stay there. The focus probe is
  **Chrome-only**, which is still true and is a limit on the evidence rather than
  on the fix. The two remaining objections were discharged by measurement:

  **THE ACCEPTANCE SWEEP — 777 cells over 37 settings, plus the focus walk.**

  Per cell: navigate, kill transitions *before* any root-size change, set the
  root, `location.hash = 'main'`, then read how much of `#main` sits behind the
  header. The cell count is asserted, so a silently-truncated grid cannot pass.

  | setting | before | after |
  |---|---|---|
  | root style 9..32 (504 cells) | 0 | 0 |
  | `defaultFontSize` 9 / 12 / 16 / 20 / 24 (105) | 0 | 0 |
  | `minimumFontSize=9`, `=12` (42) | 0 | 0 |
  | `minimumFontSize=16` (21) | 6 cells, max 52 px | **6 cells, max 52 px** |
  | `minimumFontSize=20` (21) | 12 cells, max 64 px | **6 cells, max 14 px** |
  | `minimumFontSize=24` (21) | 15 cells, max 75 px | **0** |
  | `minimumFontSize=32` (21) | 15 cells, max 174 px | **0** |
  | fonts blocked (21) | 0 | 0 |
  | fonts blocked + `minFont=32` (21) | 15 cells, max 174 px | **0** |
  | **total** | **63 of 777** | **12 of 777** |

  **The focus walk, which is the criterion itself: 290 entirely-hidden stops of
  1,455 → 0.** Same grid (6 pages × 5 widths ≥ 1056 px, 30 cells, 344
  header-internal stops skipped), hit-tested with `elementFromPoint`. **The
  pre-fix tree was rebuilt in a git worktree and put through the identical probe:
  it still reports 290** — footer 254, `#main` 36, geometry candidates 333 against
  the fixed build's 43. That control is what makes the 0 a result rather than a
  hope: both modes reading 0 with identical step counts is the shape `CLAUDE.md`
  warns *ends* a check instead of starting one.

  **Default settings unchanged: 0 differences over 352 page-widths × 17 fields =
  5,984 comparisons**, full-page geometry fingerprint included, positive control
  detecting exactly 1 injected difference.

  ⚠️ **AND THE FIRST ATTEMPT AT THAT COMPARISON REPORTED 4,224 DIFFERENCES.** It
  keyed rows on `page`/`width`; this harness names them `url`/`w`, so every row
  collapsed onto one map entry and was compared against an arbitrary single row.
  It was caught only because the result was *uniformly bad*. **The fix is not the
  corrected field names — it is that the comparison now asserts the key fields
  exist and are unique before comparing anything.**

  ⚠️ **ONE COLUMN OF THE SWEEP WAS MEASURING NOTHING, AND TWO METRICS
  DISAGREEING IS WHAT SURFACED IT.** A summary column reported
  `min(scroll-padding-top − headerH)` of **−71.89 px** on root-style rows whose
  `covered` read **0**. Cause: `insetBlockStart` is **−900 px** in those rows —
  the header is `position: sticky` and **not pinned**, because that is exactly how
  the saturating `clamp()` gate un-sticks it. Comparing the offset to the header
  height is meaningless where the header is not pinned. `covered` — real geometry
  after a real hash navigation — is the valid metric. **A `position` of `sticky`
  is not the same fact as "the header is pinned", and any future probe that
  compares an offset against a header height has to read
  `inset-block-start` too.**

  **THE 12 REMAINING CELLS ARE PRE-EXISTING, REDUCED, AND DELIBERATELY NOT
  FIXED.** `minimumFontSize=16` leaves 52 px of `#main` behind the header on
  `/about/` and `/contact/` at 1280, 1440 and 1920 px; `=20` leaves 14 px on the
  same six. Every one is unchanged or better than before the fix and none is new.
  **Why the ramp cannot see them, which is the part worth keeping:** the setting
  *floors* computed sizes, so at `minimumFontSize=16` the root is genuinely 16 and
  `1lh` on `<html>` is 18 px — identical to the default — while the header grows to
  **149.38 px** because the **sub-16 px** type (the 11 px tagline, the 14 px
  eyebrow and nav) is floored up. **The ramp reads a quantity the setting did not
  move.** Closing it needs a different measurement — `1lh` taken from an element
  that carries the small type, or a floor on the header — which is a header change
  with site-wide reach. Pouya's instruction on this step was *"if the sweep
  surfaces anything beyond this one declaration's blast radius, stop and report —
  do not widen"*, so it is reported: `docs/06` carries it as its own item. It is
  **not** an SC 2.4.11 failure, which is about a component *entirely* hidden.

  **`docs/06`'s item is ticked and carries the figures.** The decision was
  `AGENTS.md` **Q61**, now closed.

  ⚠️ **AND ONE MORE LATENT CASE, AT THE DEFAULT TEXT SIZE — NO READER SETTING
  INVOLVED: FALLBACK FONT METRICS PLUS THE SEVENTH NAV ITEM.** With every `.woff2`
  blocked — what a reader on the Slow 4G profile `docs/04` budgets against sees
  first, since the fonts are `font-display: swap` — and a seventh nav item cloned
  from a real node, the header measures **141 px at every width from 1056 to
  1091 px**, and 81 px from 1092 px up. With the webfonts loaded it is 81 px at all
  of them. **Two consequences, and the record first carried only the smaller one:**

  1. **A 60 px collapse** when Geist swaps in — a CLS contribution on all 22 pages,
     against the CLS < 0.05 budget. **Larger, not new:** the previous build gives
     86.59–86.97 px in the same band, so a ~5.6 px shift already existed.
  2. ⚠️ **AND 44 px OF `#main` BEHIND THE STICKY HEADER** after the skip link,
     because 141 px exceeds the 97 px `scroll-padding-top`. **This one IS new** —
     the previous build's 86.97 px stayed under 97 px, so it covered **0**. Framing
     this case as "a CLS contribution" understated it, and a reader ruling on a
     layout shift would weigh it differently from one ruling on the skip link.

  *(The band was recorded as "1056 / 1064 / 1072 / 1084 … 81 px from 1092 up",
  which reads as though 1086–1090 were checked and clear; they are all 141 px. It
  is a contiguous **36 px** band, 1056–1091. Both errors found by
  `adversarial-reviewer`.)*

  **It is latent, not shipped:** with six items there is no wrap at any width, and
  `showInsights` turns the seventh on only at two published articles. **Not fixed
  here, and deliberately:** the two candidates are raising the desktop breakpoint
  past 1091 px, which changes the layout at normal settings in that band, or giving
  Geist a metric-matched `size-adjust` fallback, which is a font-stack change well
  outside "the header and its consumers".

  ⚠️ **AND IT IS NOW GATED RATHER THAN MERELY PARKED — Pouya's ruling,
  2026-09-01: NO SEVENTH NAV ITEM SHIPS UNTIL THIS IS FIXED.** Fixing it is a
  **prerequisite of publishing the second Insights article**, because publishing
  article #2 is what adds the item — `SiteHeader` computes `showInsights` from the
  collection, so nothing else stands between that editorial decision and both
  consequences above. The gate is recorded in three places on purpose: `AGENTS.md`
  R20, `docs/06`'s `/insights/` state item, and the comment on `showInsights` in
  `SiteHeader.astro` — the last of those being the only one a person editing an
  article's front matter is likely to be looking at. The fix itself is *"to be
  designed then, not now"*.

  **What is still latent, measured and not a defect today:** `.hero-h` has **16
  scoped rules, one per page, and only 2 carry `overflow-wrap: anywhere`** (`/` and
  `/about/`). The other 14 measure 0 because their headlines' longest words are
  shorter. The single-source fix would be to change `global.css`'s `h1`–`h6` rule
  from `break-word` to `anywhere` and delete both overrides; that is a design-system
  change with a site-wide blast radius on intrinsic sizing and it has not been
  measured, so it is recorded here rather than done.

- **Measure the elements, not only the page.** A document-level overflow check
  passes while a flex child absorbs the deficit by being crushed — that is how
  step 1 shipped a logo at aspect 0.891 under a green "0 overflow at every
  width". Assert the rendered geometry of the thing you care about. On `/`
  every infinity-mark instance measures 1.5654–1.5657 against the master's
  1.5657.
- **A touch-target measurement of the wrong box is not a finding.** The eight
  cards on `/` report 26–39 px-tall `<a>` elements and are fine: each card's
  whole box is the link's hit area via `::after { inset: 0 }`, verified by
  hit-testing nine points per card at three widths (24 cards, 9/9). Hit-test
  before enlarging anything. WCAG 2.5.8's inline exception also applies to a
  link sitting mid-sentence, and one such link on `/` is deliberately left at
  164 x 21.
- Every page must be readable and navigable with JavaScript disabled.