The compiler that counted twice
Most of the quality violations in runs without context were the design-system violations again, seen by the compiler. They are now counted once.
What happened
Asked how the quality column is computed, I looked at what it was made of. Of the 4,044
type errors in the real runs, 3,895 (96%) were one code: TS2769, "No overload matches
this call". Panda runs with strictTokens, so css({ bg: "#fff" }) does not compile. The
raw-value grader reports raw-color for that line, and the compiler reports TS2769 for
the same call. One mistake, two violations, in two different columns.
In the runs without context the effect was large. Kimi wrote 294 raw values per run and was also charged 348 quality violations, almost all of them the same values again.
What we learned
- A grader that sees the same thing as another grader inflates a score. We knew this for
lint:
@pandacss/prefer-tokenis dropped for that reason (guide 11). The compiler was the same case and we missed it, because the error text ("No overload matches") does not say "raw color". - The same line is not enough. Only 81% of the
TS2769sat on the line of a raw value. TypeScript reports an overload error at one property of the call, not always the bad one. The test that works is the call: aTS2769inside acss()that also holds a raw value or a token used for the wrong job is that value seen by the compiler. That covers 91%. - The other 9% are real, and invisible to our graders. Opening samples, they are token
names that do not exist:
fontSize: "3xl",fontWeight: "bold"(the scale hasnormal,medium,semibold),lineHeight: "relaxed", and breakpoints that do not exist ({ base: "column", md: "row" }: the design system defined none until anecdote 09's follow-up added them). The value is not raw, soraw-valuesis silent, and the compiler is the only one that knows.
What it means for Vektos
markCovered (graders/covered.ts) marks a TS2769 as covered when its css, cva or
sva call holds a raw-values or token-roles violation. A covered violation is kept in
the database with covered = true, shown in the report as "not counted", and left out of
every count. The run is graded when it is saved, and bun run bench:recount fixed the 3,539
violations already stored.
Mean quality violations per run, before and after (design-system column unchanged):
| Context | Haiku | Luna | DeepSeek | Kimi |
|---|---|---|---|---|
none | 41.1 → 8.6 | 166.7 → 26.7 | 107.8 → 15.6 | 348.5 → 40.0 |
storybook-mcp | 8.7 → 4.5 | 60.6 → 18.0 | 5.6 → 5.0 | 22.4 → 21.6 |
ds-mcp | 2.6 → 1.6 | 18.6 → 16.1 | 2.5 → 2.3 | 9.7 → 9.7 |
ds-mcp-check | 2.3 → 2.3 | 20.0 → 20.0 | 4.0 → 4.0 | 7.8 → 7.8 |
ds-mcp-check-full | 0.5 → 0.3 | 0.0 | 0.0 | 0.0 |
The order of the contexts did not change. What changed is how bad "no context" looked on quality: it was mostly the design-system column read twice.
Follow-ups
- Done:
token-names(guide 03).fontWeight: "bold"and a breakpoint that does not exist are now design-system violations with a message that lists the choices, and theTS2769on the same call is covered. Replaying the grader on the stored runs, against the token table of the time, covers 3,842 of the 3,895TS2769(98.6%, up from 91%). - a11y is per rule, not per element. One
color-contrastfinding counts 1 whether it hits one element or fifty, while a raw value counts 1 each. Quality still mixes units. - The
check_codeofds-mcp-check-fullstill prints both lines to the agent. That is useful to it, and only the counting changed.
The check that checked half
Giving agents a design-system checker took their violations to zero and left their type and lint errors where they were.
The CSS that was not there
The dashboard built clean and rendered with half its design-system styles missing, and writing it against our own rules hit the same walls the agents hit.