---
name: population-census-must-be-cfg-test-aware
description: "A grep-derived call-site population silently mixes prod and cfg(test) sites; classify by module boundary, and re-derive a population you carried forward rather than trusting it."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 490c6ce9-e590-4598-96f1-1c7f55671b1a
  modified: 2026-08-19T05:52:21.616Z
---

A `git grep` of call sites is NOT a population — it cannot see `#[cfg(test)]`. Working
releases#57 (access-store RMW husk), the filed issue, the JIT plan AND my own carried-forward
wake note all listed `cli.rs:24084` as a production mutation site. It is inside `mod tests`
(cli.rs's test module runs 22522..35192). Six of the eight sites I had been handed were right,
one was a test, and the true population had a site none of the three lists named.

**Why:** a grep result reads as an enumeration, so it inherits the authority of one. The
cfg(test) boundary is invisible in `file:line` output, and a huge file (cli.rs, 35k lines) puts
its test module so far from the top that "is this line in tests?" is not answerable by eye. The
carried-forward list compounds it: a population someone already re-located feels *more* verified
than a fresh grep, not less — but it was derived by the same blind method.

**How to apply:** for any "convert every site that does X" task, compute the cfg(test) regions
first (scan for `#[cfg(test)]`, find its `mod` line, close at the matching column-0 `}`), then
classify each hit PROD or TEST and print the classification. State the count and its definition
in the report and in any doc census you write, so the next reader can re-derive it instead of
trusting it. Say out loud which sites the filed list got wrong — that is the part a gater cannot
check without redoing the census.

**2nd instance 2026-09-10, and here it corrupted a CITATION rather than a population.**
v0.69.0 #287, doyle's fifth rationale for excluding two sibling e2es: "heal_stale_online_records
is driven only from the real daemon's shellwake tick (shellwake.rs lines 1117 and 1151)." Both
cited lines are UNIT-TEST call sites -- `#[cfg(test)]` opens at shellwake.rs:1042 and they sit
inside `the_heal_writes_the_truth_once_and_then_leaves_the_record_alone` at 1076. The PRODUCTION
site is 907, inside `pub fn reconcile_once` (896), commented "Leg (a) first, every cycle", swept
by the wake-host thread at ~1030. The CONCLUSION was right and the EVIDENCE POINTED AT TESTS.
That is the dangerous shape: a reviewer who follows the citation lands in a test module and either
believes it or has to redo the whole trace. A conclusion is not validated by the fact that its
wrong citation happened to sit in the right file.
**The positive half is what actually closed it:** rather than trusting a zero-hit grep for
`shellwake` in the two rigs, I read what their `start_inproc_daemon` DOES start -- seed control,
a broker with a hermetic NetHost, tunnel control (plus drive control in gateway) and nothing else.
No wake host is spawned, so no tick drives the heal. Pair every absence claim with a positive read
of the present population; see [[a-call-site-grep-cannot-answer-whether-an-edge-observes]].

Kin: [[truncated-grep-read-as-the-population]] (a `| head` sets scope silently — same failure,
different cause), [[string-census-pattern-encodes-an-assumption]] (the pattern itself encodes an
assumption; run a looser sibling probe and read the DELTA),
[[derived-figure-without-its-formula-dies-with-the-context]] (a census with no stated population
cannot be re-derived — why the corrected `atomic.rs` figure ships with its definition), and
[[resumed-session-reground-before-acting]] (state decays; this is the sharper case where the
carried-forward state was wrong when it was WRITTEN, not merely stale).