The tidy-up that took the wrong thing
Removing what nothing uses is good practice, right up until the removal is done by pattern rather than by structure. Ours deleted seven working rules and the build did not say a word.
While trimming the register's styling down to what it can actually use, we added a small cleanup at the end: drop any animation definition that nothing refers to any more. Sensible. Once the back-office rules are gone, most of the animations are orphans.
It was written as a text pattern — find the block, check whether its name appears elsewhere, cut it out if not. It worked on everything we tried it on.
Where it went wrong
The pattern knew where a block ends: a line break followed by a closing brace, which is how these blocks are written when they span several lines.
One of them was written on a single line. It had no line break followed by a closing brace anywhere inside it — so the pattern kept looking, found the next one further down the file, and cut everything in between.
Seven working rules went with it. The section of the product that draws the fold-away sidebar control lost its styling entirely.
What did not happen
The build completed. No warning. Our full test suite — several thousand checks — passed. Nothing in the process that produces the file has any opinion about whether the file still contains the rules it started with.
The thing that caught it was opening the register in a browser and comparing every element against the same page using the untrimmed styling. Two hundred and twenty-five differences, all of them in the same corner of the screen. The report named the element and the property, so the cause took a couple of minutes.
The fix, and the general rule
The cleanup no longer re-reads text it has just generated. Each block is set aside as it is produced, a marker is left in its place, and the marker is either swapped back for the block or dropped. Exact, structural, nothing to misinterpret.
The general rule we took from it: if a process generates something, the next step should work on the pieces, not on the text. The moment you generate output and then parse it back with a pattern, you have thrown away everything you knew and are now guessing at your own work.
Why an operator should care about any of this
Because "we removed the stuff you were not using" is a thing suppliers say, and it is usually true and usually good — it is why your till is lighter this month than last. The question is what proves it took only the unused parts.
Ours is a browser check that compares the trimmed version against the full one, screen by screen. Before that existed we had a process that was confident, a green test suite, and seven missing rules.