Files
DriverVault/API Server/internal/api
tajniak81andClaude Opus 5 a49d48f659 The panel's webfonts, in the one position CSS accepts them
The lockup was the visible symptom and the wrong suspect. Matching it to the Web
App's component changed nothing a reader would notice, because the panel was not
rendering Archivo at all — it was rendering system-ui's italic bold, which is a
different letterform at the same size, and had been since the stylesheet was
written.

The Google Fonts @import sat after @import "tailwindcss". Tailwind v4 inlines
its import into the rules it generates, so anything importing after it is no
longer at the top of the sheet, and CSS drops an @import that follows real
rules. The built stylesheet carried zero occurrences of fonts.googleapis.com;
the build had been saying so on every run, in a warning easy to read as noise
about a comment. Moving the font import above Tailwind's is the whole fix, and
the Web App's own stylesheet has always had that order with a comment explaining
it — that comment comes across, plus what it cost here.

This was never only the wordmark. Every rule reaching for --font-sans or
--font-mono was falling back too, which is the entire panel: the section nav,
the card titles, and the endpoint tables whose monospace is how a path reads as
a path. Checked against the built bundle rather than the dev server, since the
dev pipeline is exactly what was hiding it: the page now reports Archivo italic
800 loaded, and the wordmark measures 115.05px — the same width the Web App's
rail lockup measures.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-30 18:17:09 +02:00
..
2026-07-06 08:50:52 +02:00
2026-07-17 11:54:26 +02:00