---
name: a-call-site-grep-cannot-answer-whether-an-edge-observes
description: Grepping a delivery/emit call site for a publish call answers "does THIS FRAME publish", not "is this row observed" -- an edge can publish through a SINK one frame up in another crate. Follow the row to a bus before calling an edge silent.
metadata:
  type: feedback
---

2026-09-09, hfenduleam, the IR-92 hunt (hertz + doyle). Censusing which delivery edges publish
`MSG_IN`, I grepped every `drain_*_audited_at` call site for a publish call and drew up a table of
five edges, four of them "silent". `crates/spt-daemon/src/relay.rs:75` was in the silent column.

It is NOT silent. `drain_backlog` is generic over a `sink: F`, and the sink that `api listen` passes
(`crates/spt/src/api/startup.rs:1064`, the `deliver` closure) publishes `MSG_IN` -- one frame up, in a
DIFFERENT CRATE, invisible to any grep of the call site. I caught it only because I read the caller
for an unrelated reason and reported the near-miss beside the finding rather than quietly fixing my
table.

**Why:** "does this code call publish" and "is this row observed" are different questions, and the
first is the one a grep can answer. Any indirection -- a sink closure, a trait object, a callback, a
channel -- moves the observation off the edge, so a call-site census systematically OVER-reports
silence. The error is the flattering direction: it inflates the defect I was hunting. Had the sink
gone the other way it would have made a genuinely silent edge (`worker.rs:138`) look innocent, so the
same method fails in BOTH directions and neither failure announces itself.

**How to apply:**
1. Follow the ROW, not the file: from the drain to whatever consumes it, through every sink/callback
   parameter, until you reach a bus publish or run out of frames. Only then is "silent" measured.
2. Census the PUBLISHERS first (grep the event constant tree-wide -- here `IO_KIND_MSG_IN` gave
   exactly two sites), then ask which edges reach one. Publishers are few and are a closed set;
   edges are many and each needs a trace.
3. A zero-hit grep on a file needs a live control in the SAME file (I asserted `TakerAudit` /
   `claim_idle_edge_at` hit in `inject.rs` before trusting its 0 publish hits in 343 lines).
4. Report the near-miss beside the finding. A census method that failed once in a lane will fail
   again in the same lane.

**5th instance, 2026-09-10, and this one ESCAPED MY DESK.** Censusing siblings for the #287
keeper-before-bind fix I reported gateway_owner_shell_e2e and tunnel_e2e as having "ZERO `bind(`
occurrences between them, so the race cannot exist there." Both files DO bind: each defines an
`online_by_token` closure (gateway:207, tunnel:153) that shells out to
`spt api --adapter mock-shell bind-shell --link <token>`. `bind(` is simply not how the call is
spelled. hertz caught it; I verified in source at head 10. The exclusions were right and BOTH
stated reasons were wrong -- gateway parks at 231-232 and binds at 233, so it ALREADY parks before
its single bind; tunnel binds TWICE (219, 268), so "no rebind" would also have been false, and it
is excluded because it parks NO identity at all (zero `shell.pid` writes, zero
`record_shell_launch`, zero stand-in -- no corpse for a heal tick to read). A right answer with a
wrong reason is not a near-miss; it is an unmeasured claim that happened to land.
**The escalation is the lesson:** doyle repeated my grep as proof in head 10's merge-commit body
before hertz caught it. A false negative handed to a peer becomes THEIR evidence and lands in an
immutable object. Never hand a peer a grep as a form claim -- hand them the read, or say it is
unmeasured. See [[a-false-sentence-in-a-gated-commit-is-corrected-forward]] for what it costs to
fix once it is in.

Related: [[a-name-grep-that-guesses-the-compound-spelling-reads-as-absence]],
[[an-absence-is-data-only-if-it-has-a-way-to-appear]], [[a-battery-is-silent-about-arms-no-cell-drives]],
[[compare-at-one-layer-crlf-meter-class]].