Design system audit: Figma h.work | DS vs the shipped frontend

• Status: Findings only — no production code changes proposed here
• Scope: Phase 0 of the Expert workspace redesign. Answers one question: does the redesign restyle, or only re-lay-out?
• Source: Figma h.work | DS, file key Npxd3yi9EfG8nCYI9XLdaj, last modified 2026-08-04T16:49Z
• Audited: 2026-08-05, against origin/dev at 89f31480e
• Re-measured: 2026-08-12 — §11 carries the conformance score. §1–§10 are the 2026-08-05 snapshot and are left as written.
• Related: expert-conversation-redesign.md, DESIGN_PRINCIPLES.md, #4235

1. Answer first

Layer	Verdict	Consequence for the redesign
Colour	Aligned. 41 of 64 canonical hexes are exact palette steps.	No token pass. Treat the redesign as re-layout.
Typography	Not aligned, and not a token layer at all.	Every slice carries a per-call-site type migration. Size it separately.
Components	A real spec exists for 8 components; the shipped queue is uniformly one to two steps smaller.	Component work can now cite values instead of screenshots.

The headline for planning: colour costs nothing, type costs per component.

2. What the file actually contains

19 pages, and the split matters.

Foundations   0:1 Colors · 1:2 Typography
Components    20:581 Tags · 20:800 Tabs · 20:836 Buttons · 20:837 Text input ·
              47:470 Avatar · 50:699 Toggle · 50:967 Radio · 50:1048 Checkbox ·
              53:469 Dropdown · 54:985 Table · 280:1041 Tooltip · 298:1940 Toast ·
              309:43767 Chat
              --- (71:2229 separator) ---
Surfaces      64:155 Expert · 321:8613 Client · 346:549 Superadmin

Foundations and the 12 component pages are specification — spec tables with real values. The three surface pages are proposals that do not describe frontend/ today. Do not read a surface frame as documentation of the build.

3. Method, and two traps worth knowing

Values were read from SVG exports, not the REST API. Figma's SVG keeps text as <text> (with Outline text off) and swatches as <circle>/<rect fill>, so a page exports as exact parseable values. The file endpoints rate-limit hard on broad requests and the window is long — /v1/me continuing to return 200 says nothing about file access.

Two traps produced false readings before being caught:

1. Template chrome is not product design. The pages sit on an "IBM documentation library" artboard whose own labels render in IBM Plex Sans and Alliance No.1, and Figma's section annotations render in #9747FF at 12/500. None of it is product spec. All three are filtered out of every number in this document.
2. Colour appears twice per row on the Colors page — once as the swatch fill, once as text in the Value cell. They were compared across all 90 rows: zero disagreements. The extraction is trustworthy.

4. Colour

4.1 The palette

0:1 Colors documents 90 primitives in 9 ramps: Base (White, Black) plus Red, Grey, Beige, Olive, Purple, Blue, Green, Yellow at 11 steps each (50–950).

4.2 Alignment

frontend/src/design-tokens.ts holds 81 semantic tokens (43 light, 38 dark). 64 carry a canonical hex and are comparable; 17 are oklch-only.

41 of 64 land exactly on a primitive, including every load-bearing one:

Token	Hex	Primitive
brand	#7E1C1E	Red 900
background	#F9F7F3	Beige 50
hover	#F4F0E8	Beige 100
foreground	#0C0B09	Grey 950
destructive	#9B1A1D	Red 800

Light is 72% on-palette; dark is 54%. The dark theme is the weaker half and is the place to look if colour work is ever scheduled.

4.3 The 23 that do not match

Vendor brand marks (4) — correct as-is. channel-slack #4A154B, channel-whatsapp #25D366, channel-teams #6264A7, channel-telegram #229ED9 are third-party brand colours and should sit off-palette. Not drift.

Light near-misses (6) — the only genuine drift candidates. All cluster around Olive 100 (#E8E6DA): input #E8E3D9 (3.2), accent / brand-soft #EDE8DD (6.2), border / sidebar-border #E5E0D5 (8.4), channel-computer-screen #0A0A0A (2.4 from Grey 950). Distances are RGB euclidean. Close enough to read as hand-tuning that drifted rather than deliberate choice — worth a decision, not an automatic fix.

Dark theme (13). Largely not drawn from the ramp: card #252019, secondary #2A241C, and brand #E07075 (25 from Red 400). A lighter brand for dark is expected; it simply is not a palette value.

4.4 Not covered by this diff

17 tokens have no canonical hex, so there is nothing to compare: chart-1..5 in both themes, link / link-hover in both, and the dark border / input / sidebar-border alpha values.

Separately, --success / --warning / --danger live only in globals.css as oklch and are absent from design-tokens.ts entirely. The status palette is outside both this audit and the token file.

5. Structural gap: the semantic layer exists only in code

Checked against all 19 pages. Figma documents primitives and nothing else. There is no page mapping brand to Red 900, background to Beige 50, or hover to Beige 100. That mapping exists solely in frontend/src/design-tokens.ts.

Consequences:

• A designer editing Red 900 has no way to see what it breaks.
• The Buttons page draws on Beige 900 / 950 / 300 — three steps the semantic layer never adopted, so a button built to spec cannot be expressed in current tokens.

This is the highest-leverage thing to fix in the design file, and it is a conversation with whoever owns the DS rather than a code change.

5.1 The token source was missing when this audit started

scripts/generate-css-vars.ts imports frontend/src/design-tokens.ts to emit app/design-tokens.css (171 CSS custom properties consumed by globals.css). Nothing under frontend/ imports the module, so the unused-export sweep in #4235 deleted it on 2026-07-27, leaving npm run generate:tokens failing with "Cannot find module" and the generated CSS an orphan whose own header says to regenerate rather than edit it.

Restored at its pre-deletion revision. Regeneration reproduces the committed CSS byte-for-byte (sha256 a1cce2f5…), so no token drifted during the nine days the source was missing. The restored file now carries a header naming its out-of-tree consumer so the next sweep does not repeat this.

6. Typography

6.1 The spec — 18 styles, 8 sizes, 3 weights

Group	Family	Sizes	Weight	Line	Tracking
Title xl → xs	Source Serif 4	36 / 30 / 24 / 20 / 16	500	117–125%	−1% on 36 and 30
Title italic	Source Serif 4	same five	500 italic	same	same
Body xl → s	Inter	18 / 16 / 14 / 12	400	—	—
Body semibold	Inter	18 / 16 / 14 / 12	600	—	—

Families match exactly. layout.tsx loads Inter as --font-sans and Source Serif 4 as --font-display with weights 300–600 and style: ["normal", "italic"], so the italic titles are covered. JetBrains Mono is an extra for code and harmless.

6.2 The scale does not match

spec       12 14 16 18 20 24 30 36                                        (8)
repo        9 10 11 12 13 14 15 16 17 18 20 22 24 26 27 28 32 36 40 78   (20)
off-spec    9 10 11 13 15 17 22 26 27 28 32 40 78                        (13)
unused     30

Across 2,070 inline fontSize: declarations. Weights are worse: the spec has three (400/500/600), the repo uses ten inline — including 650, 680, 720, 750, 760, which are not design decisions.

6.3 The drift is confined to one code path

Tailwind's default scale is in force — no --text-* size overrides, and the @theme inline block is empty. Those defaults are 12 14 16 18 20 24 30 36 48: the spec plus one extra step. So the 789 text-xs / text-sm / text-lg utility uses are already compliant.

All divergence lives in inline styles — which is exactly how the queue components are written. Bringing a component to spec means converting fontSize: 13 to a utility class, one call site at a time. There is no token to edit.

Naming hazard. --text-primary / --text-secondary / --text-muted are colour variables occupying the name Tailwind v4 reserves for its font-size namespace. They sit in :root, not @theme, so nothing collides today — but moving them into @theme would silently generate text-primary as a font-size utility.

7. Component specs vs what ships

Chrome filtered out. Repo values are from the Expert queue.

Component	Spec	Shipped	Delta
Buttons	14 / 600	TicketActions 12 / 600	−2px
Dropdown item	14 / 400	DropdownItem 12 / 500	−2px, +100 weight
Tabs	14 / 600 active, 14 / 400 inactive	~11–12	−2/3px
Tags (badges)	12 / 400	StatusBadge et al. 10 and 11	−1/2px
Tooltip	12 / 400, white on dark	ExpertPriority 11	−1px
Toast	16 / 600 title + 14 / 400 body	Sonner defaults	—
Text input	14 / 400 field, 12 / 600 label	—	—
Table cell	14 / 600 header, 14 / 400 body, 12 / 400 meta	—	—

Every component is 14px where the queue ships 12. A systematic downshift, not isolated drift.

Three specifics that change planned work:

• Tags gives the badge palette outright — Green 900, Red 800, Yellow 800, Grey 800, Blue 800. StatusBadge, TaskClassificationBadge and ChannelBadge currently hand-roll their colours.
• Tabs conveys state by font weight (600 active / 400 inactive / Grey 400 disabled). No dot, no colour coding. ConversationTabs uses a coloured dot per tab, and its DRAWER_TAB_META.icon field is already dead — so the tab registry likely sheds dot as well.
• Dropdown has no selected/info state. Items are 14/400 on a 37px pitch: Grey 950 default, Red 600 destructive, Grey 400 disabled, Red 300 disabled-destructive. Today's DropdownItem paints its active row var(--info) on var(--info-subtle) — a state the spec does not contain. Note the spec's destructive is Red 600, while the repo's destructive token is Red 800.
• Buttons is fully enumerated: 4 hierarchies (Primary / Secondary / Ghost / Link) × 3 sizes (L / M / S) × 5 states (Enabled / Hover / Pressed / Focused / Disabled) × Text+Icon or Icon-only × Rounded or Square.

7.1 Table is built on a different grey ramp

The whole h.work Grey ramp is warm — every step is tinted (Grey 600 #56544F, Grey 700 #43413D, Grey 300 #D6D4D1). The Table header cells use pure neutral greys:

Table uses	Nearest palette step	Distance
#525252	Grey 600 #56544F	5.4
#404040	Grey 700 #43413D	4.4
#D4D4D4	Grey 300 #D6D4D1	3.6

Every one is a near-miss on the corresponding warm step — the signature of a generic grey used in place of the token, not a deliberate choice. #161616 on the Checkbox page is the same story (6.4 from Olive 950).

Worth raising with the DS owner: on a beige canvas a neutral grey reads subtly cold next to the warm ramp, and this is the same failure mode the --hover token was introduced to fix (#4632).

7.2 Checkbox — fully on-palette, and the counter-example to Table

Checkbox carries no text at all; its specification is entirely geometry. Six variants:

Variant	Box	Fill	Stroke	Glyph
Unchecked	19×19 rx 3.5	White	Grey 200 #E7E6E4	—
Checked	20×20 rx 4	Red 900 #7E1C1E	—	White
Indeterminate	20×20 rx 4	Red 900 #7E1C1E	—	White dash
Unchecked disabled	19×19 rx 3.5	Grey 100 #F5F5F4	Grey 200 #E7E6E4	—
Checked disabled	19×19 rx 3.5	Grey 100 #F5F5F4	Grey 200 #E7E6E4	White
Indeterminate disabled	19×19 rx 3.5	Grey 100 #F5F5F4	Grey 200 #E7E6E4	White dash

Every colour is an exact palette step, and the checked fill is brand — the same Red 900 the repo already ships. A 20px outer box either way (19 + 1px stroke), 4px outer radius.

This matters as a contrast with §7.1: the design file is not uniformly loose. Checkbox is disciplined and Table is not, so "off-palette" findings should be raised per component rather than as a blanket observation about the file.

8. Export coverage

All 17 exports are complete. Nothing needs re-exporting.

Text count is not a completeness signal. Three files were misjudged during this audit by counting <text> nodes: Radio, Toggle and Checkbox each look near-empty that way, and Checkbox was re-exported twice on that basis before the geometry was read. Controls without labels carry their entire specification in <rect> / <path> fills, strokes and radii. Read the geometry before concluding an export failed.

File	Where the spec lives
Content (Colors), Typography, Buttons, Dropdown, Tabs, Tags, Text Input, Table Cell, Avatar, Chat, Toast, Tooltip	Text + geometry
Table Header, Table header cell	Text. Nine COMPANY cells across three states; the greys are off-palette (§7.1) — a design finding, not a bad export.
Radio, Toggle	Figma variant-property labels (Selected: on/off, Active: on/off, Pressed: On/Off) plus geometry. Neither control has product text.
Checkbox	Geometry only (§7.2). The two text nodes are the page's title card.

9. Not covered

• 42 of the Expert page's 47 state frames have not been opened, including the Feedback (3), Filter (4) and Tooltips (2) sections.
• Three product questions remain open and block redesign slices, not the extractions: where the AI draft goes (today DraftReviewPanel + ReplyDock carry accept/discard/regenerate, correction capture and guardrail override); whether the queue-health MetricChip row is genuinely dropped (it is the only at-a-glance SLA signal); whether KB reviews leaves the nav.
• Client and Superadmin surfaces have not been looked at.
• The Figma file was modified the day before this audit. Treat every number as a snapshot.

10. Reproducing

SVG exports live in Figma/ at the repo root (untracked). To refresh: select the page's outermost frame → Export → SVG → uncheck "Outline text" → save under Figma/.

Parsed artifacts are written to the session scratchpad, not the repo: figma-colors.json (90 primitives), figma-type-table.json (18 styles), figma-component-spec.json (per-component size/weight census), repo-tokens.json (81 tokens).

Access notes for the Figma REST API — token location, endpoint costs, the node-id dash/colon trap — are in the shared agent memory entry figma-hwork-ds-access.

11. Conformance re-measurement — 2026-08-12

Against origin/dev at eba8188ae with feat/5891-queue-row-to-the-frame at 664b1b922 applied. The rubric and the "on dev" column come from the #5868 epic body, scored on dev fbdcdf1c6.

11.1 Weighted score

Layer	On dev	With the branch	Weight	Basis
Shell chrome	100% — 18 of 18 cells	100%	20	measured
Design-system components	~74% — 12.6 of 17 sheets	94% — 16.05 of 17	25	counted
Screens	46%	~72% — 62.6 of 87 frames	45	part measured, part judged
Foundations	~65%	68%	10	four sub-metrics, averaged

~80% weighted. About half the movement is bookkeeping rather than code: the screens row was written before the ACTIONS series (#5909–#5913) landed and never credited its 22 frames.

11.2 Foundations, measured

Sub-metric	On dev	Now
Inline font weights on 400 / 500 / 600	831 / 831	unmoved	100%
Colour tokens on a §2 primitive — light	72%	36 / 46	78%
— dark	54%	21 / 35	60%
— both	64%	57 / 81	70%
Inline font sizes on the 8-step scale	~40%	814 / 1,976	41%

Colour moved because all ten tokens DS-6 added are exact palette steps. Their dark counterparts are not, by necessity — the file carries no dark reference; the departures are named in UI_FOUNDATION.md §4.4.

Type has not moved. 13 (625 sites) and 11 (340) are 49% of every inline size in the app and neither is on the scale. Raw <button> is 503 including tests, 468 outside them.

That 468 is not a migration backlog, and DS-1 (#5879) sized itself on the assumption that it was. Classified by what each one actually renders — parsing the opening tag with brace-aware matching, so multi-line cn() and style={{…}} are counted rather than missed:

What it is	Count	Belongs on <Button>?
No className at all — list rows, table cells, cards, nav items	250	no, these are click targets
Icon affordance with no padding of its own	130	only where it is a real icon button
Padded and rounded — a control with a box	196	the honest candidate set
…of which fill/edge and padding and radius, not a list row	20	yes, unambiguously
List rows with w-full + text-left/justify-between	7	no

The categories overlap by design: the 20 are the strict core of the 196. Much of the remaining 176 belongs to other sheets rather than the Buttons one — StatusTab and ConversationTabs are the Tabs sheet, DraftStatusChip and AttachmentChips are Tags, filter-chip is its own control. Absorbing those onto <Button> would be the wrong move, not a deferred one. "Absorb the 504 raw <button>s" should be read as "classify 468 and absorb the ~20–60 that are buttons".

The second filter is size, and it removes more than the first

Re-measured while starting the absorption. Of the 179 padded-and-rounded-and-painted candidates still standing, the question is not whether they are buttons but whether they can carry the sheet's smallest step — S is a 30px box with a 14/600 label, and most of these are drawn well under that:

	Count
Declares a box the sheet's S step fits	46	the real work-list
Drawn below 30px tall or under a 14px label	73	cannot absorb S without reflowing its row
Sized by Tailwind classes — needs reading	60	unknown until inspected

The clearest case is ops/expert-applications/hooks/useColumns.tsx: nine row actions at 26–28px and 11px, three of them side by side in a 320px column. At 14/600 those three measure roughly 350px of text and padding before gaps, so absorbing them overflows the column. A table row action is governed by the Table sheet, not the Buttons sheet — the same class of mistake as putting a Tabs control on <Button>. ThreadSummaryCard's eight are the same shape at 10px.

So the absorbable set is ~46, not ~196, and the remainder splits into "belongs to another sheet" and "the Buttons sheet has no step this small". The second group is a question for the design owner, and it belongs on #5895: does the sheet want an XS step, or should these controls stop being buttons?

The type sweep's first directory, and the class no call site can reach

TYPE-1 (#5886) pass 1 took components/client/ from 139 / 326 on the scale (43%) to 304 / 326 (93%) with two substitutions — 13 → 14 across 125 sites and 11 → 12 across 40. Measured in Chrome at 1440 over every leaf node that carries text:

Surface	Before	After
Inbox	177 / 380 — 47%	378 / 380 — 99%
Settings › Channels	36 / 59 — 61%	56 / 59 — 95%
Settings › Billing	26 / 44 — 59%	41 / 44 — 93%
Settings › Team	39 / 54 — 72%	46 / 54 — 85%
Chat transcript	392 / 435 — 90%	399 / 435 — 92%

No surface gained an overflowing element and none gained a horizontal scrollbar.

The transcript barely moves, and the reason is not the call sites. Its 34 residual nodes compute to 13.3px, 14.7px and 16.1px — non-integer sizes no inline fontSize: N can produce. They are <strong> inside <th>, <h3> and <h2> in rendered markdown: the transcript puts the model's markdown into the DOM with no prose stylesheet, so those blocks fall back to user-agent em defaults. A call-site sweep cannot reach them at any scale. They need a rule mapping markdown block elements onto the scale, which is its own piece of work and is not counted in the 2,081.

The last survivor on every page of all three surfaces is a 22px . — the dot in the h.work logotype. A glyph, not type; it should leave the census rather than be fixed.

Each pass bans the sizes it removed, in the directories it has been through: RETIRED_INLINE_FONT_SIZES in eslint.config.mjs is a no-restricted-syntax selector scoped to TYPE_SCALE_SWEPT_DIRECTORIES. Scoped, because banning 13 app-wide today is ~780 warnings against a ceiling with no slack (#5962).

Pass 2 — the client pages, and the sizes the census could not see

app/client/ went 58 / 111 (52%) to 108 / 111 (97%). The three survivors are one 10, one 22 and one 26, each needing a design read rather than a substitution.

Route	Before	After
/client/chats	154 / 746 — 21%	743 / 746 — 100%
/client/settings/sources	44 / 53 — 83%	51 / 53 — 96%
/client/settings/team	46 / 54 — 85%	52 / 54 — 96%
/client/settings/company	20 / 34 — 59%	25 / 34 — 74%
/client/specialists	68 / 70 — 97%	68 / 70 — 97%, unchanged

/client/chats was the worst-conforming route on the surface and the census said it held seven off-scale sites. It held eleven: four were 10.5, 11.5, 12.5 and 13.5, which the pattern above could not see, and each renders once per conversation row — 585 of the page's 746 text nodes. A one-line list row is worth more than a settings screen when it repeats 146 times.

company stops at 74% by design: its five remaining 13s are one label in components/settings/SettingsField.tsx, rendered five times, and that directory has not been swept yet.

Pass 3 — the shared tier, checked against the sheets rather than the scale

components/ui, components/shared and components/settings together: 29 / 88 on the scale (33%) to 79 / 88 (89%). Nine survivors — five 10, three 15, one 22.

Small in site count and cross-surface in effect, so four of these are DS primitives whose own sheets were read first rather than assuming the scale applies:

Primitive	Sheet says	Was	Now
Toast.tsx	toast — 14 and 16	13	14
DataTable.tsx cell	table-cell — 12 and 14	13	14
DataTable.tsx header	table-header-cell — 12	11	12
ActionsDropdown.tsx	dropdown — 14	13	14

DS-5 (#5883) is credited with toast type at 1.0 in §11.3 above, and the toast body was still 13. The sheet exports only 14 and 16. Either DS-5 conformed the tooltip and not the toast, or the score was granted on the pair. Worth a re-read before that row is trusted.

Measured across all three portals, because these components render on all of them:

Route	Before	After
/client/settings/company	25 / 34 — 74%	30 / 34 — 88%
/workspace/home	80 / 85 — 94%	81 / 85 — 95%
/workspace/queue	41 / 56 — 73%	42 / 56 — 75%
/ops/clients	140 / 236 — 59%	141 / 236 — 60%
/ops/users	959 / 1,408 — 68%	960 / 1,408 — 68%

Table geometry is unchanged: header 44, rows 72 on both /ops tables, before and after, with identical overflow counts. That is the check that mattered — DataTable cell type feeds rows whose height #5871 fixed, and a bump that pushed them past 72 would have broken the Table sheet on every /ops route at once.

The single-node gains on expert and ops are the honest result: those surfaces are still carried by app/ops (36%), components/ops (36%) and app/workspace (40%), which no shared component can reach.

Pass 4 — the expert surface, and the floor at 12

app/workspace and components/workspace: 109 / 277 on the scale (39%) to 275 / 277 (99%). Two survivors, both 15.

Every size the expert frames specify is already on the scale — nav 14/500, breadcrumb 12/400, row title 14/600, subtitle 14/400, Unassigned 12/400, table header 12/400 uppercase, messages 16/400. Nothing in Figma/expert/UI-SPEC.md is smaller than 12, which settles the surface's largest remaining block: 56 sites at 10 and 6 at 9, all in the queue's dense chrome — SLATimer, ContextStrip, TicketActions.

That block was moved to 12 only after measuring it in isolation, because it is the riskiest substitution in the whole ticket — a 20–33% jump in the densest UI in the app. On the ticket route:

	on the scale	overflowing elements
before	84 / 94 — 89%	4
after 10 → 12, 9 → 12	92 / 94 — 98%	4

Same four elements, same severity. The one that changed measurement (265/203 → 270/208) overflows by exactly 62px in both, so it is pre-existing and untouched.

Route	Before	After
/workspace/queue	41 / 56 — 73%	55 / 56 — 98%
/workspace/analytics	57 / 80 — 71%	79 / 80 — 99%
ticket detail	84 / 94 — 89%	92 / 94 — 98%
/workspace/files	98 / 99 — 99%	99%
/workspace/home, /workspace/approvals	94%, 97%	unchanged — their residue is shared code

A test named for a viewport it never set. SLATimer.test.tsx carried renders correctly at mobile width (375px), asserting fontSize: 10px. It sets no viewport and SLATimer has no responsive branch, so it was pinning the badge's only size under a name that implied a mobile-specific accommodation. Had the name been accurate, 10 would have looked like a deliberate exception worth preserving. Renamed to say what it checks.

Pass 5 — ops, the largest tree, and a table that is not on the Table sheet

app/ops, components/ops, components/analytics, components/directives: 950 sites, 338 / 950 on the scale (36%) to 921 / 950 (96%). 81 files, +583 −583, every changed line a fontSize. The 29 survivors are 18 × 15, 5 × 22, and one each of 27, 28, 32, 40 — display sizes needing a design read.

Route	Before	After
/ops/users	959 / 1,408 — 68%	1,398 / 1,408 — 99%
/ops/analytics	82 / 342 — 24%	315 / 342 — 92%
/ops/clients	140 / 236 — 59%	226 / 236 — 96%
/ops/specialists	138 / 223 — 62%	213 / 223 — 96%
/ops/team	136 / 252 — 54%	242 / 252 — 96%
/ops/inbox	28 / 39 — 72%	29 / 39 — 74%

Overflowing-element counts are unchanged on every route — 11 on clients, 7 on team, 2 on analytics, 1 on users and inbox, all pre-existing.

Table geometry holds at 44 / 72 on clients, users, specialists and team. It does not on /ops/analytics, and that is worth recording: its table was 32 / 53 before this change and 34 / 56 after. A table three pixels taller is not the finding — the finding is that this table was never on the Table sheet's geometry in the first place, so unlike every other /ops table its rows are content-sized and follow the type. #5871 took the app to 44/72 and this one was missed. Filed as an observation here rather than fixed inside a type sweep.

Pass 6 — the tail, and the three classes a call-site sweep cannot reach

Twelve small directories — onboarding, expert-onboard, the auth pages, legal, internal, specialist-onboarding: 97 / 187 on the scale (51%) to 167 / 187 (89%). The 20 survivors are display sizes: 6 × 22, 5 × 15, 4 × 40, 3 × 28, one 26, one 78.

Route	Before	After
/forgot-password	2 / 6 — 33%	4 / 6 — 67%
/legal/cookie	35 / 61 — 57%	40 / 61 — 66%
/portal-not-found	4 / 9 — 44%	5 / 9 — 56%
/login	7 / 24 — 29%	7 / 24 — 29% — unmoved

/onboarding was not verified. It redirects to /login?missing-token=true under the localhost role picker, so the numbers a probe returns for it are the login page's. Its 34 sites are swept in source and unmeasured in a browser.

Between them, the routes that barely move name the three classes of type that no call-site sweep can reach, and together they are why the census will never read 100%:

1. Relative-unit cascades. /login renders 8.8px, 9.6px, 10.88px, 12.8px, 15.2px — a percentage cascade in the marketing column (12.8 = 16 × 0.8, 15.2 = 16 × 0.95). No fontSize: N produces these.
2. User-agent defaults under rendered markdown — 13.3px, 14.7px, 16.1px in the client transcript, §"Pass 2" above. /legal's residue is the same shape one level up: its 13s are components/shared/legalMarkdown.tsx h2/h3, swept by pass 3 rather than by this one.
3. Glyphs sized as type — the 22px . in the h.work logotype, and Logo's own fontSize prop driving its lockup. Brand geometry, not body copy; it should leave the census.

The scale-conformance metric should be read against classes 1–3 excluded, or it will always report a shortfall that no amount of call-site work closes.

Pass 7 — the three the passes never claimed, and the ban goes app-wide

Six passes each took a directory and appended it to the lint ratchet, which left the one place no pass was named after: frontend/src/components/ itself. Three files sat there at 13 — ImpersonationBanner.tsx, UserIdentity.tsx, slug-availability-input.tsx. A census of every directory still outside the ratchet found nothing else off the scale, so the substitution is three lines and the ratchet collapses from a 23-entry list to src/**.

Widening it is the real check. The rule reads ternary branches as well as direct values, so running it over the whole tree tests every directory at once, including sizes no fontSize: N grep can see. Lint holds at 246 warnings, 0 errors — the ceiling exactly, with no type-scale warning among them. Nothing is hidden in an expression anywhere in src.

	on the 8-step scale
when TYPE-1 was filed	802 / 1,949 — 41%
after passes 1–6	1,872 / 1,949 — 96%
after this	1,875 / 1,949 — 96%

Measured, at the two sites reachable in a browser:

	before	after
/ops/clients/new subdomain input	13px, 622 × 40	14px, 622 × 41 — matches the other six inputs on the form, which were already 14
client mobile nav, display name	13px / 500, 17 tall	14px / 500, 18 tall — matches the nav rows beneath it

The sheet is 280 wide and the name ellipsises, so the extra pixel costs nothing; no row reflowed. ImpersonationBanner is not measured — it mounts only when the JWT carries impersonatedBy, and forging that locally invalidates every API call. Its changed line is the banner root's own fontSize inside a flex row with no fixed height.

The 74 that remain are display sizes — 37 × 15, 14 × 22, 5 × 40, 5 × 28, 4 × 26, and one each of 34, 32, 27, 17, 78 — plus 70 text-[Npx] utilities, which take a different substitution and were counted separately from the start. Neither is a 13.

11.3 The 17 component sheets

Sheet	Score	Where it landed
chat, checkbox, radio, text input, toggle	1.0	DS-6 (#5884), this branch
dropdown	1.0	DS-4 (#5882)
tags	1.0	DS-2 (#5880)
toast, tooltip	1.0	DS-5 (#5883) for the type, this branch for the boxes
table cell, table header, table header cell	1.0	#5871
navigation collapsed flyout	1.0	SHELL-2 (#5876)
navigation	0.9	#5872; the rail's IA still differs (#5961)
avatar	0.9	DS-7 (#5885) open; the strays cleared on this branch
tabs	0.9	DS-3 (#5881); ui/tabs.tsx still ships the shadcn pill, one consumer left
buttons	0.35	DS-1 (#5879), blocked

11.4 The 87 surface frames

Group	Frames	Score
client-chat	7	1.0	signed off
expert · queue	3	1.0	SCREEN-2, verified in a browser
expert · context panel	9	1.0	SCREEN-4 (#5893)
expert · thread actions	22	0.95	ACTIONS-1…5 deliver UI-SPEC §3.3 in full
expert · thread	4	0.85	Chat sheet applied; the bubbles have never been seen rendered (#5951)
expert · insights	3	1.0	§3.4, verified in a browser
expert · list filters	4	0.65	menus are on .hw-ds-menu; composition not read against the frames
expert · AI draft	4	0.4	the function ships in DraftReviewPanel; the frames put the draft in the composer
expert · approvals	1	0.5	route exists, frame not read
expert · to review	1	0	no route — SCREEN-1 (#5890)
super-admin	29	0.4	every route exists on the shared shell, table geometry and primitives; no page conformed — SCREEN-5 (#5894)

Expert is 44.0 of 51 — 86%. All three surfaces together are 62.6 of 87 — 72%.

Frame count is not product surface. 22 expert frames are the states of one flow; 29 super-admin frames are five whole sections. Weight by route rather than by frame and screens is ~65%, taking the total to ~78%.

11.5 Confidence

Shell and components are counted against code. Screens is the soft row: queue, Insights and the modal were measured in a browser at 1440; thread actions is credited off closed issues rather than a frame-by-frame pass; the chat bubbles could not be rendered at all, because dev's generalist-demo thread returns no messages (#5951).

11.6 Reproducing the census

cd frontend/src
# inline type — every site, then the share sitting on 12/14/16/18/20/24/30/36
grep -rhoE "fontSize: [0-9]+(\.[0-9]+)?" --include="*.tsx" --include="*.ts" . | sort | uniq -c | sort -rn
grep -ro "<button" --include="*.tsx" . | wc -l

The (\.[0-9]+)? is load-bearing. Without it the pattern stops at the decimal point and scores fontSize: 13.5 as a 13 — so half-pixel sizes were counted, silently, as whichever integer they start with, and 12.5 was counted as conformant. There are 53 of them across 19 files: 26 × 12.5, 9 × 11.5, 8 × 10.5, 7 × 13.5, 3 × 9.5. Every one is off the scale.

A substitution built on the bad pattern is worse than the count: s/fontSize: 13\b/…/ matches inside 13.5, because \b sits between 3 and .. It rewrites 13.5 to 14.5 — off-scale before, still off-scale after, and now wrong. Guard with (?![\d.]).

It is still not a census of every site, and the totals above should be read as "numeric-literal sites" rather than "font sizes". A fontSize value can take five forms, and the recipe sees one of them:

Form	Count	Seen by the recipe
numeric literal — fontSize: 13	1,949	yes
identifier — fontSize: META_FONT_SIZE	71	no
Tailwind arbitrary — text-[13px]	70	no
string — fontSize: "0.9em", "18px"	22	no
conditional — fontSize: tableMode ? 14 : 11	4	no

The last two matter more than their counts suggest, because a retired size can hide in either and no substitution built on the recipe will touch it. Three did:

• ComposerHintRow.tsx — const HINT_FONT_SIZE = 11
• SettingsSaveRow.tsx — const STATUS_SIZE = 12.5
• ops/billing/page.tsx and queue/components/TicketRow.tsx — ? 11 : inside a ternary

All three sit in directories the sweep had already been through and the lint rule already claimed to guard, because the rule matched Property[key.name='fontSize'][value.value=…] — the direct value only. A named constant or a ternary branch is not the direct value. The selector now matches any retired literal descending from the property, which covers the conditional case; a constant declared elsewhere and passed in still cannot be caught statically and has to be found by reading.

Colour: compare every hex: in frontend/src/design-tokens.ts against the 90 primitives in Figma/design-system/FOUNDATIONS.md §2. The file quotes other hexes in prose — matching against the whole document rather than §2 inflates the score to 94%.

11.7 What is left, in order of weight

1. SCREEN-5 (#5894) — 29 frames, five sections, no page conformed.
2. DS-1 (#5879) — the only true blocker. The Buttons sheet draws on three Beige steps the semantic layer never adopted, so a button built to spec cannot be expressed in current tokens. Cleared by FIGMA-1 (#5895), which is a message to the file owner, not a PR.
3. TOKEN-2 (#5889) — dark sits at 60% and the file carries no dark reference to conform to.
4. SCREEN-1 (#5890) — blocked on a product call, and its stated premise is wrong: agent-workspace shipped after the Figma export.
5. DS-7 (#5885) and SHELL-8 (#5961).

Nothing below DS-1 is blocked on anything but sequencing.

11.8 Raised while reconciling with #5947

Rebasing onto eba8188ae put the Chat sheet on top of the transcript rows #5947 added — a flagged outline, tool / system_prompt event lines, tool-call correlation, an attachment chip. The sheet draws none of them, so they were brought onto its type and geometry rather than left as they were. Three findings came out of it.

The chat meta tone fails AA, and the sheet is where it comes from. chat.svg draws bubble meta — author, separator, timestamp — at 12px in Grey 400 #A7A49F. That is 2.48:1 on paper and 2.28:1 on the outbound Grey 100 fill, against AA's 4.5:1. The sheet's other 12px tone, Grey 600 on the chat-list description, is 7.56:1.

This is not a branch defect and it is not fixed here. components/client/chat/MessageRow.tsx on the signed-off client portal already renders the same role at 12px --text-tertiary, so the expert side now matches both the sheet and the shipped portal. Diverging on one surface would trade a shared weakness for an inconsistency. The fix is either a different resolved value for --text-tertiary or retiring it from body text app-wide — a repo-wide change needing browser verification. Filed for FIGMA-1 (#5895); it belongs in the same list as the Send-on-Red-300 failure (1.90:1) recorded in UI-SPEC §6.1.

CONTROL_RADIUS = 8 is declared privately in four files across two surfaces — app/workspace/queue/ReplyDock.tsx, components/client/MessageComposer.tsx, components/client/chat/ChatHeader.tsx, components/client/composer/RewriteControl.tsx — and META_FONT_SIZE = 12 in two more. This reconciliation needed both and deliberately did not add a fifth copy of either: the type reuses the existing constant and the radius is named once for its DS role. Consolidating the other four is a follow-up, and it is blocked on the finding below.

components/workspace/tokens.ts now contradicts the sheets it predates. Its scale reads md: 6 // buttons, inputs against the Text input sheet's 8, and xl: 12 // chat bubbles, modals against the Chat sheet's 16 and §4.4's 32. /ops, /client and workspace components all import it, so it is the obvious shared home for the radii above — and importing it today would couple new code to values the design system has already moved past. It needs a DS pass before it can be that home.

11.9 Caught in the browser, not in the diff

Both are on dev already — this branch touches neither file — and both were found by rendering the expert thread at 1440, the design's own canvas width.

The Context ⌘K control is clipped by 34px. Its row measures scrollWidth 265 against clientWidth 203, so the button is painted from x=1355 to x=1474 on a 1440 viewport and its right edge is cut. document.body.scrollWidth stays 1440, which is why no horizontal scrollbar appears to give it away.

The client-colour edge on the thread detail is off-ramp. app/workspace/queue/page.tsx keeps a second copy of CLIENT_PILL_PALETTE — 12 entries, 24 raw hexes, none of them on any h.work ramp — and #3696 spends it on a 4px bar at the top of the pane for multi-client Experts. Measured: rgb(229, 77, 77), i.e. #E54D4D, nearest ramp step Red 600 #DD2629. The identical palette was deleted from TicketRow.tsx as dead during this epic; this copy is live. Client identity does need distinguishable colours, so the fix is to draw them from the nine DS ramps rather than to drop the feature — a ticket of its own, not a token swap.