Builds got faster by fixing the boring things without asking a model

Every build is checked before it ships, and anything the check finds is repaired. The problem was how — every finding, however trivial, went back to the model as "rewrite this file", at ~150 seconds a time.

We measured two production builds. In one, six of the eight defects were the same thing: text in a colour that can't be read on the background behind it. Each went to a full-file rewrite — 137 and 151 seconds — and came back with the identical pairs, so the second round paid again and still shipped them. 288 seconds of a 390-second build spent not fixing five class names.

What's mechanical now

Repair runs in layers, cheapest first, and the free layer grew:

• Invisible text. The checker already proves the defect with a contrast ratio between two known colours. The fix is the same arithmetic over the five palette tokens — whichever reads best on that surface. There's no taste in it; a colour nobody can read is not a design decision.
• Missing component imports. A page that uses <Separator /> without importing it parses fine, builds fine, and dies in the browser with "Separator is not defined". The checker now walks the page for every component name and adds the import line itself.
• Dead menu links. The navigation and the page are written separately, so they disagreed about section names on most builds. Settled by reading the page's actual section ids.

Only what the free layer declines goes to a model — and then as a patch of the broken lines, not a rewrite of the file. A full rewrite is the last resort, not the first.

What it means for you

Builds finish sooner, and — more importantly — far fewer of them run out of time. A build that hit the deadline used to fall back to a simpler site than the one being written for you. That was the single biggest cause of "why does my site look generic", and it was mostly five class names.