Before publishing a repository I ran a scan for anything that should not go out. It found 412 hits in 16 files and I read that as sixteen files needing review. It was one defect, repeated. 412 hits outside the private class 374 the same line, emitted by every control run 35 path spans across 15 documents 3 false positives (an ordinary word matching the pattern) Every control in the build prints where it ran: root=/home/<user>/work/<project>/build and the append-only log had recorded that line 208 times. Each run added one more. The scan was not finding sixteen mistakes made by people; it was finding one mistake made by a code generator, faithfully, two hundred times. The number was the least useful thing about the finding "412" sent me toward the documents. It reads like a spread: many files, many authors, many judgement calls about what is safe to publish. Classifying the hits by shape collapsed it into one line of code plus a small tail: class count fix the generator's root= line 374 one change, in the emitter path spans in prose 35 rewrite to a relative form the pattern matching an ordinary word 3 teach the pattern The grouping is one pipe. The scanner prints path:line:text, and normalising the variable part of each hit before counting is what turns a list into a diagnosis: $ scan --report | cut -d: -f3- | sed 's/[0-9]\+/N/g' | sort | uniq -c | sort -rn | head -3 374 root=... (control preamble) 12 (path span in prose) 9 (path span in prose) One of those is a code change. One is an edit pass. One is a scanner improvement. Until they were separated, all 412 looked like the middle kind, which is the most expensive kind. The generator fix is a token instead of an absolute path. The equality check the log performs on that field keeps working, because it was only ever comparing the field to itself across runs. It never needed the path to be real. The part with no clean answer The log is append-only. That is not a convention; it is the reason the log is worth anything. So 208 lines carrying a home directory cannot be removed. Every instinct says reset it. A fresh log, no leak, clean publish. That instinct is the same one the log exists to defeat. A record you can erase when it says something inconvenient is not a record, and the first thing it will be erased for is exactly this: something embarrassing that is also true. What we did instead: the existing log stays, unchanged, and goes on an exclude list so it is not published the public face gets a second log, written by the same appender with the repo-relative token, starting from the next boundary both are real, one is private, and nothing was rewritten to make the second one look older than it is Two records, one truth. The private one still says the build ran on a particular machine, which is exactly what it was recording all along. The rule I took from it A violation count is a symptom count, not a cause count. Group by shape before deciding what the work is. 412 and 3 are different projects, and here the difference was one grouping away. And the smaller one, which I had not thought about before this: check what your own tooling prints into permanent records. Application code gets reviewed for what it logs. Build controls and test harnesses usually do not, and they are the things that write the same line thousands of times. Mine had been announcing an absolute path in every run since the first one. It took a publication gate to notice, because until then nobody outside was ever going to read it.