---
name: a-stricter-meter-answers-a-confident-empty
description: "Meter-population class (4 instances; 4th = a blind pgrep GUARD that failed toward PERMIT -- guard on the invariant, not its proxy): a grep/predicate that does not respect the structure it measures answers confidently WRONG — a confident EMPTY (readlink \"(deleted)\" suffix, 24 processes read as 0), a confident UNDER-count (scan root one glob narrower than --workspace, +81 published as +12), and a confident OVER-count (attribute-shaped text matched inside comments; absolutes inflated by a CONSTANT 44 that cancels in every delta and so hides from delta checks)"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 880d1285-2246-4429-9b5e-eb4331af141f
  modified: 2026-08-29T13:24:23.907Z
---

Measured 2026-08-29 (todlando, kitsubito, W2/#238 reap). doyle authorized reaping 24 orphaned
daemons **by predicate**: binary path == `/home/reavus/projects/spt-core/spt-core/target/debug/spt`
AND `SPT_HOME=/tmp/.tmp*`. My census compared `readlink /proc/<pid>/exe` for exact equality and
answered **P1=0, P2=0 — "nothing to reap"** while 25 matching processes were resident. The tree had
been REBUILT since those daemons started, so the kernel reports `/home/.../spt (deleted)`. The
working predicate is `case "$exe" in "$B"|"$B (deleted)")`. Corrected census: 24/24 matched both
predicates, zero spared; after the kill P1=0, P2=0 for real, port 5474 free.

**Why:** the emptiness was manufactured by a STRICTNESS in the tool that has nothing to do with the
question asked — same family as the git trailer tokenizer returning a clean zero for every
`Co-authored by:` trailer because it demands a whitespace-free token (see the AGENTS.md mandate).
Not the `EXIT=$?`-after-a-pipe family: nothing was truncated, the meter simply refused to match.
doyle ruled the pairing 2026-08-29 and it is the right one — file the next instance here, not there.

**How to apply:** a zero that contradicts a count you took MINUTES EARLIER is a question, not a
result. Before reporting "already gone" / "nothing found" / "no matches", re-measure with the LOOSER
instrument that produced the original population (`pgrep -f <pattern>` here) and reconcile the two
readings. Specifically for process censuses: `/proc/<pid>/exe` is unreliable across a rebuild or an
upgrade of the very binary you are hunting — match the cmdline, or accept the `(deleted)` suffix.
Had I trusted it I would have told the gater the orphans had cleared themselves, and the port would
still be held. Related: [[identical-readings-across-opposite-outcomes-indict-the-meter]],
[[dont-take-a-diagnosis-as-measured]], [[traceable-exit-2-is-an-unparseable-registry]].

## Instance 2026-09-07 (hertz, PR #198 served-URL census) — the tightening ATE a true positive

Filed here per this entry's own instruction. Censusing `crates/*/tests` for served-URL traffic, my
FIRST loose pass flagged 15 files including `spt-daemon/docs_server_e2e`. The loose predicates also
produced two false positives (a `curl` inside a comment; a service literally NAMED `serve`), so I
tightened the predicate list — and in tightening it I dropped `start_serving` along with the noise.
My tight pass reported **3** rigs with URL traffic. doyle's independent grep at the same sha
reported **4**: `docs_server_e2e` calls `start_serving(..., 0)` twice and uses the returned port.
Same safe shape, so no verdict moved, but the number I published was wrong and it was wrong in the
direction that under-reports the population.

**Why this one is not just "I missed a file":** I already HELD the control. The loose pass's output
named the file, and I discarded that output when I replaced the predicates instead of diffing the
two result sets. A predicate edit is an edit to the INSTRUMENT, and an instrument change between
two readings is the one thing that makes the readings incomparable — the same reason
[[compare-at-one-layer-crlf-meter-class]] refuses a mixed comparison.

**How to apply:** when you tighten a predicate to remove false positives, DIFF the before and after
result sets and account for every row that left. A row that leaves must be named as a false
positive, never merely absent. If you cannot say why a row disappeared, the tightening removed
signal, not noise.


## Instance 2026-09-07 (hertz, #198 HEAVY-set diff) — the extractor mangled its own last row, and one whole clause went unread

doyle ruled this the same instrument class as the instance above and told me to file it once, here.

Diffing the HEAVY membership across #198 I extracted names with
`grep -o 'package(spt) & kind(test) & binary(/^([^)]*)'`. **Without `-E`, `(` and `)` are LITERALS**,
so the pattern matched through the clause's closing paren and the last name came out as
`webserve_cross_node_e2e)`. Two consequences, one loud and one silent:

- **Loud:** the set difference printed an impossible row — `REMOVED: wake_resume_bind_e2e)` for a
  binary that is present on both sides. A removal that cannot be real is the tell, and it was
  sitting in my own output.
- **Silent, and the one that mattered:** I ran the extractor on the `package(spt)` clause ONLY.
  The filter has three clauses. `package(spt-daemon)` went 34 → 35 (`twohost_web`) and I never
  looked, so I reported the repartition as **eleven binaries** when it is **twelve** — and that
  wrong count had already propagated into my across-commune and into doyle's framing of the next
  task before the corrected pass caught it.

**Why it belongs here:** same family as the two above — the emptiness/undercount was manufactured by
a property of the TOOL (BRE vs ERE paren semantics) that has nothing to do with the question, and
the population I censused was defined by where I happened to point the instrument rather than by the
structure of the thing measured. Kin to [[truncated-grep-read-as-the-population]] and
[[grep-l-census-counts-name-collisions]].

**How to apply:** (1) an extractor's output is data to INSPECT, not a pipe to trust — a malformed
row (stray delimiter, an impossible set-difference entry) condemns the whole extraction, so stop and
re-derive rather than reading past it; (2) before censusing a structured expression, count its
CLAUSES first and assert you covered every one, because a per-clause extractor silently answers only
about the clause you aimed it at; (3) use `-E` when the pattern contains grouping characters you
mean as regex, or escape them when you mean them literally — never leave which-one ambiguous.

**SAME ERROR AGAIN, 40 MINUTES LATER, same night (hertz, 2026-09-07 07:57Z; doyle ruled it belongs
as one line HERE, not a third file).** Having just reported that the #198 gate's scan root excluded
a whole crate — and written a rider arguing literals are not portable across roots — I measured the
golden growth term over `crates/*/tests/*.rs` and called it "the estate". Golden runs `--workspace`,
so `kind(lib)` unit tests count too: growth was **+81 (12 integration + 69 lib)**, not the +12 I
published, and Phase A and TOTAL were understated by 69 on both boxes in a table doyle had already
recorded verbatim. Phase B and the repartition term survived, because those really were
integration-only. **The lesson is not "check both directories" — it is that I diagnosed this exact
class in someone else's code and then committed it in my own within the hour, which means naming a
failure mode does not inoculate you against it.** Before publishing any census, state the POPULATION
the command actually walks (here: one glob) beside the population the CLAIM is about (here: what
`--workspace` runs), and check they are the same set. Cross-check with a second instrument that
cannot share the first's scope — the whole-tree control that caught this agreed to the digit.

**THIRD INSTANCE, opposite direction — a confident OVER-count (hertz, 2026-09-07 09:55Z, W2 F15/F16
term).** Counting Rust test cells with `git grep -oE '#\[(test\]|tokio::test)'` matches
attribute-shaped TEXT, so it counts mentions inside comments and doc comments as cells.
`webserve_attachment_e2e.rs` read **2** where the file has exactly **ONE** real cell — the second
match is a doc comment describing the file's own arms (`//! ## The arms (one #[test], sequential …`).
Workspace-wide: **44** such comment matches. My published absolute totals (3621, 3623) were each
inflated by 44; the real pair is 3577 → 3579.

**Why the deltas survived and the absolutes did not, which is the transferable part.** The
in-comment count was 44 at BOTH shas, so it cancels exactly in a difference. Every delta I had
published was therefore correct — +13 predicted, +13 measured on two independent boxes — while
every absolute was wrong by a constant. **A meter with a CONSTANT bias is invisible to any check
made of differences, and a run of successful delta predictions is not evidence the meter is sound.**
Two lessons: (1) never quote an absolute from a delta-validated instrument without a separate
check; (2) the fact that a prediction keeps landing is evidence about the DIFFERENCE, and says
nothing about the level.

**A related borrowing, same hour:** I had also told doyle that `webserve_attachment_e2e` is "still
ONE cell" — TRUE, but taken from todlando's reported `1/1` rather than measured. Right answer,
borrowed reason. A correct claim held for an unverified reason is indistinguishable from a lucky
one until someone checks, and it was only checking it that exposed the comment-match defect at all.

Kin: [[compare-at-one-layer-crlf-meter-class]] (its fourth instance, the same day, is the mirror —
a meter whose OUTPUT form changed and produced a confident false MISMATCH).

2026-09-07 face (hertz), and it CORRECTS A DISCRIMINATOR I PROPOSED UNMEASURED. I asked doyle to
make the W2 F17 gate's firewall probe three-value (PRESENT / ABSENT / PROBE-FAILED) because
`F18-INFRA` is an ABSORBING bucket: every cross-box TIMEOUT is classified as expected-while-blocked
on the strength of one `netsh` read at start, so a probe that fails returns "absent" and the run's
real reds are absorbed as known-blocked. The SHAPE was right and doyle adopted it into
`gate-w2-f17.sh` the same minute. **The discriminator I named in the same breath was wrong:** I
said "assert the probe's exit code and that stdout is non-empty". He exercised the probe standalone
and measured `netsh` exiting **1 on a clean ABSENT** (`No rules match the specified criteria`), so
exit code alone would have classified every legitimately-absent rule as PROBE-FAILED — converting
the run's most common honest state into an instrument fault. The landed form discriminates on
STDOUT CONTENT (`Rule Name` -> PRESENT, `No rules match` -> ABSENT, empty-or-anything-else ->
PROBE-FAILED), and prints the raw probe (exit code + first 3 lines) into the driver log so the
classification is auditable rather than inferred from what got bucketed.

General, and it is the same family as this entry's other instances: **a CLI's exit code is a claim
about the QUERY, not about the ANSWER.** A great many tools report an empty-but-correct result as
non-zero (`grep`, `netsh`, `gh`, `find -quit` shapes), so an exit-code discriminator collapses
"nothing matched" into "the probe broke" — a meter that answers confidently about the wrong
question. When you add a third value to a probe, the third value needs its OWN evidence, and the
evidence has to come from EXERCISING all three arms deliberately (doyle did: real absent, forced
bad args, empty stdout). Mine: proposing the arm is cheap and correct; naming its discriminator
from plausibility is where the error goes in, and I did both in one message as if they were one
act. Split them — ask for the shape, and let the arm be discriminated by whoever measures the tool.
Kin: [[never-send-a-claim-composed-before-its-check-ran]], [[an-absence-is-data-only-if-it-has-a-way-to-appear]].

2026-09-08 — THREE MORE IN ONE AFTERNOON, all the same family: A FILTER THAT CANNOT MATCH READS AS
A CLEAN RESULT. Logging them together because the shape is one shape and I hit it three ways in
about ninety minutes.

1. **A needle in SOURCE form cannot match an ESCAPED raw.** `grep -c 'type="msg" type="msg"'` on a
   nextest raw returned ZERO while the panic text right beside it read
   `"<EVENT type=\"msg\" type=\"msg\" ...>"`. The raw carries the quotes escaped. Had I trusted
   the count I would have told a peer his defect was NOT reproduced and withheld a valid baseline —
   on the strength of a needle that could never have matched. **Count and text disagreed and the
   text was right.** Print the evidence beside the count, always; a count is a claim about a needle,
   not about the file.

2. **A process census keyed on the COMMAND LINE is vacuous for cargo.** I refused runs on
   "no builder whose CommandLine names this worktree". Measured with three live builders: one cargo
   had a COMPLETELY BLANK CommandLine, another read `<toolchain>\cargo.exe build --bin ...` with no
   path at all — and my own invocations (`cargo run -p xtask -- pool-claim --pool ./target`,
   `cargo clippy --workspace`) carry no worktree path either. So every `builders: []` I had quoted
   as evidence a run was alone proved nothing. todlando measured the same hole and sharpened it:
   rustc usually DOES carry the target path while cargo does not, so the guard answers "alone" or
   "busy" depending on which INSTANT it samples. **An intermittently blind guard is worse than a
   dead one, because it has a track record of firing.** Key on something that cannot be hidden —
   the EXECUTABLE PATH for pool holders — and report box-wide load as INFORMATION rather than
   refusing on it (a refusal that fires whenever CI builds is correct and unusable, which is how a
   guard gets commented out).

3. **A zero-match test filter reads as green.** `-E 'test(poll_envelope_e2e)'` matched nothing,
   because that is a test BINARY name and `test(...)` matches the test NAME. nextest exits 4 with
   the word `error`, but its Summary line reads `0 tests run: 0 passed` — so a FAIL-grep or a
   scanning eye sees a clean sheet. I had handed that exact string to a peer as the canonical form
   to copy. **Assert the RUN COUNT as its own field, not just the Summary count**: zero runs is
   NEVER-RAN and void, never a pass — the same three-valued split as ran-and-passed vs never-ran.

Common remedy: every guard needs a POSITIVE CONTROL — make it fire on purpose once — and every
absence needs a stated way to appear before it counts as evidence.

SAME AFTERNOON, two more from ONE nextest raw — and these two are a PAIR, because they fail in
OPPOSITE directions off the same file:

4. **The escape form of a defect varies by CALL SITE, so no fixed needle is safe.** The doubled
   `type` attribute printed ESCAPED in one raw (`type=\"msg\"`, from a `{:?}` format) and BARE in
   another (`type="msg"`, from a `{}`), for the SAME defect. My counter matched neither reliably and
   returned a confident ZERO on a raw whose panic text contained the defect three lines below. I got
   the attribution right only because I read the TEXT after the count said zero. A peer wired the
   same lesson into his report layer: a needle matching one form and not the other yields a
   confident "the doubling is gone" from a raw that still contains it.

5. **A nextest raw prints each failure TWICE**, inline and again in the closing block, so
   `grep -c 'FAIL \['` counts APPEARANCES, not cells — 1 failing cell, count 2. This is the MIRROR
   of the miss doyle and deployah hit the same hour, where `FAIL \[` UNDER-counted because one cell
   printed `FAIL + LEAK [`. A narrow needle misses a variant; a naive one double-counts. **The
   Summary line is the only authority for how many cells failed** (`N tests run: P passed, F
   failed`); FAIL lines are for NAMES, and want `sort -u` before any count.

The pair is the lesson: on the same artifact, one needle over-reported and another under-reported,
and neither error announced itself. Take the COUNT from the summary the tool computes, take the
NAMES from the lines, and never let one string serve both jobs.
---

**Fourth instance (deployah, 2026-09-09, golden r3 att2 manifest step) — a confident EMPTY used as
a GUARD, so it failed toward PERMITTING.** The manifest script guarded "is the watcher still
running" with `pgrep -f watch-a2.ps1` under Git Bash. Git Bash's pgrep does not see a detached
Windows pwsh process, so the guard found nothing, reported all-clear, and the script ran while
`r3-a2-watch.log` was still growing -- overwriting a 48-file preservation manifest with a 61-file
one (a superset, 61/61 hashed from root; no covered file lost, but a manifest already CITED to
the gater was no longer the same bytes). Same oracle fact as the process-table entries
([[a-cmdline-scoped-builder-census-is-intermittently-blind]]): on this box Get-CimInstance is
the only process oracle and a bash process query returns a confident empty.

**What is new: the fix is not a better process query.** The guard was standing in for an
invariant it could not measure. The real invariant was IS THE RUN TERMINAL -- authoritative,
remote, and unfoolable by any local process table -- so the script now reads run status via gh
and refuses unless `completed`, with a 60 s mtime belt behind it. Both arms exercised before
trust: it REFUSES on the live run (exit 3, names the run and its status) and the permit arm is
the run it was then watched to take. Rule: when a guard's oracle can return a confident empty,
ask what the guard is a PROXY for and guard on that state directly; a guard that fails toward
permit is the one direction a guard must not fail in, and it is exactly the direction a blind
census fails.