---
name: grepping-a-success-token-matches-the-panic-that-quotes-it
description: "a grep for a SUCCESS token (ADMITTED, CONNECTED, SERVED) matches the FAILURE message that names it, minting a phantom success; measured twice in one log, 2026-09-08 golden r2 twohost"
metadata:
  type: feedback
---

Measured 2026-09-08 (golden r2, run 34262154550, twohost-a/b logs): `grep -c ADMITTED` on B's log
returned **1**, and I reported "1 ADMITTED" to doyle. The single hit was the PANIC line itself —
`role B never got the user's message ADMITTED by A within 900s` — so the true count was **ZERO**.
The same call caught me a second time in the same breath: `grep -c HELPER_SERVE_FOR` on A returned
1, but its timestamp (20:49:36.87Z) preceded the cell that was supposed to emit it (A's web cells
start 20:49:44.30Z), so the line belonged to an EARLIER PASSING step and the failing cell emitted
none.

**Why:** failure messages are written by humans who name the thing that did not happen, so the
absence-of-X message reliably contains the token X. A count is not a presence test, and a presence
test is not an attribution test.

**How to apply:** never let a bare `grep -c <success-token>` stand as evidence of success.
(1) exclude the failure text (`grep ADMITTED | grep -v 'never got'`) or print the matching LINES
and read them; (2) check the TIMESTAMP against the window of the cell you are attributing it to —
a line before the cell started is another cell's; (3) prefer counting the token's own emitter
shape (`HELPER_SERVE_FOR: target=… outcome=…`) over the bare word. Related: [[a-column-that-reads-one-value-on-every-row-is-a-broken-extractor]],
[[never-send-a-claim-composed-before-its-check-ran]], [[a-fail-line-appears-twice-in-a-nextest-log]].