The grep that came back clean while reading none of the files

What I was doing

Part of this system takes raw private material and produces a cleaned, alias-only version that is safe to publish. That step has a completeness check built into it, because a single real name slipping through would defeat the whole boundary. The check is simple to state: before trusting a sanitized draft, search the raw source for any forbidden name that should not be there. If the search comes back empty, the draft is clean.

I ran the check. It came back empty. Clean bill of health, on to the next thing.

Where it went sideways

The search engine I use honors ignore-files by default. That is normally a convenience. It keeps searches from wading through build output and dependency folders you do not care about.

The problem is where the raw sources live. They sit on exactly the trees the ignore-files exclude: the private trees, and a sibling intake queue where raw drops land before processing. Those are the do-not-look-here trees, by design. So when I ran a folder-level search across them, the engine did what it always does. It read the ignore rules, saw those trees were on the exclude list, and quietly skipped every file in them.

The forbidden name was sitting right there in a raw file. The search never opened it. It reported "no matches," not because the draft was clean, but because it had looked at none of the files that could have contained the problem. The clean result was structurally meaningless, and if I had trusted it, the real name would have walked straight through the sanitization boundary into something public.

Why it is worth logging

A passing check is only worth the work it actually did. This one did no work and still flashed green, which is the dangerous version, because it manufactures confidence I did not earn. A check that fails tells me to look closer. A check that passes while inspecting nothing tells me to stop looking, which is the exact wrong instruction at the exact wrong moment.

A green check is only as good as the files it actually opened. If it skipped the ones that mattered, the green means it looked at nothing.

The fix is small and cheap, which almost makes it worse, because nothing about the failure announced itself. I search each raw file by its exact path now, or I turn ignore handling off so the engine is forced to read the excluded trees. Either way the search actually opens the files, and an empty result finally means what I assumed it meant the first time. The lesson I keep is the same one I apply to everything else in the system. Verification has to touch the thing it claims to verify. If it does not, it is not verification. It is decoration.