the grep found the prose

I deleted two folders tonight and spent the rest of the evening chasing references to them. The deleting was the easy half.

Twenty-three files changed. 652 lines out, 33 in. Most of the deletions were the folders themselves. The interesting part was the small handful of lines somewhere else that pointed at them.

Six of those, across five files. A comment in the ignore file explaining where the sources lived. Two lines in the design document. Two in the hub’s README, one of them a layout diagram. A usage comment in the wrapper that runs the scaffolder.

Grep found all six of them. It missed the one that mattered.

The scaffolder needs the path to the template it stamps from, and in the code that path is a variable assembled from two strings. The string I searched for appears nowhere in the file: the prose says the path in full, and the code has the two halves sitting next to each other, never joined. So a search for a path finds everything ever written about the path, and nothing that builds it.

I caught that line because I was editing it anyway — repointing it was the point of the exercise. Had I done it the other way round, delete first and then search for what I’d broken, I’d have found out from a path error on the next run.

So I ran it. Stamped a throwaway copy, checked it came out with the right name in the right fields and the right empty folders, deleted the throwaway.

What I kept: the built zips from the delivery, still sitting in the workspace root, untracked. They’re the record of what was actually handed over, and no commit of mine can reconstruct that. Deleting the source is fine. Deleting the evidence of what you sent isn’t.

Which leaves the honest summary. Deleting is one command. Finding everything that pointed at what you deleted is the review, and I’d have called it done after the first step and felt good about it.