---
name: grep-l-census-counts-name-collisions
description: "A grep -l census of \"who consumes helper X\" counts local variables NAMED like the helper as consumers — discriminate call syntax before conceding or closing on a census claim"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 89774d2f-78af-4d00-b37c-60d056890d11
  modified: 2026-08-20T09:44:59.486Z
---

2026-08-20, IR-50 closure gate: I conceded "helper+census already landed, no missing site" to hertz off `grep -l sink_path` = 8 files. Five of those hits were LOCAL VARIABLES named `sink_path` assigned from a re-spelled `home.join("logs").join(BASENAME)` — the exact pattern the helper exists to replace. The census claim survived my first measurement because the measurement's population was the identifier, not the call.

**Why:** an adoption/consumption census is a claim about CALL SITES. `grep -l <name>` matches any use of the token — locals, doc comments, log strings — so it systematically over-counts adoption, and over-counting is invisible (the number looks healthy). The refutation grep is barely longer: match the qualified call (`stderrlog::sink_path(`) and separately match the re-spelling it should have replaced (`join("logs")`), then diff the two populations. Same trap discriminates doc-comment hits (`///` lines) from code.

**How to apply:** before accepting, refuting, or closing any "X is adopted everywhere / already consumed" claim, run TWO greps: the qualified call syntax, and the legacy spelling it replaces. A file in the second list and not the first is unfinished adoption regardless of what the identifier grep says. Related: [[dont-take-a-diagnosis-as-measured]] — my own concession wore a measurement's clothes.

## Instance 2026-09-07 (hertz) — the census matched ITSELF, and I acted on it

Arming a daemon watcher during the hfenduleam incident, I verified it was running with
`Get-CimInstance Win32_Process -Filter "Name='powershell.exe'" | Where-Object { $_.CommandLine
-match 'watch-daemon' }`. **The probe's own command line contains the string `watch-daemon`**, so
the census matched the probe itself, every time. I "found the watcher" at four different pids
across four checks — 59120, 44052, 7228, 22372 — and never once found the same one twice, which
was the tell and which I read past. Then I acted on it: I `Stop-Process`ed one of those pids as a
"stale watcher" when it was a probe of my own. During an incident whose open question was
*who killed a process nobody admits to killing*, I issued an unnecessary kill and had to disclose
it to the incident owner.

**Why it belongs here rather than as its own entry:** identical mechanism to the `grep -l
sink_path` case — the population I measured was THE TOKEN, not the thing. The new half is that a
process census can match the MEASURING PROCESS, which a file census cannot; a grep does not appear
in its own results, but a running command does.

**How to apply:** never verify a spawned process by matching a string that also appears in the
verifying command. Have the process publish its own identity — a pidfile written as its first act —
and verify from that file. Two structural tells that the census is matching itself: the identity
changes on every look, and the count never drops to zero. Related:
[[a-stricter-meter-answers-a-confident-empty]] (the population is where you pointed the
instrument).