---
name: announce-token-from-the-failing-frame-not-the-register
description: "Grep for a diagnostic token derived from the FAILING CODE PATH (panic frame → function → its emit sites), never from the register entry that discusses the symptom — two kill paths in one crate carried different announce strings and the wrong one returned a void zero."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 2151f0bf-b256-41cd-ac18-5b5555599b36
  modified: 2026-08-04T03:51:22.696Z
---

Triaging golden 30873007187 (grandchild outlived tree teardown), I grepped the run log for
`REAP_JOB_TERMINATE_FAIL` and reported its absence as "the loud instrument stayed quiet."
The zero was VOID: that token lives in `reap.rs` (brain-subtree reap). The failing test calls
`DetachedChild::kill_tree` (daemon.rs), whose loud arm emits `SERVICE_TREE_KILL_INCOMPLETE`
— a string the code under test can never print. hertz caught it with a positive control
(the captured stderr block demonstrably prints) plus a source read of the actual path.

**Why:** I derived the token from the IR-16 register entry because it *discussed* the same
symptom (silent job-termination failure). Symptom-similarity is not path-identity: one crate
held two kill paths with two announce vocabularies. [[verdict-from-probe-competence]] one
level down — the filter was competent for a hunt I wasn't running.

**How to apply:** before grepping a log for an expected diagnostic, walk: panic message →
source frame (file:line) → enclosing function → the emit sites reachable FROM that function
(grep the function body / its callees for `eprintln`/log tokens). The register/memory entry
names the CLASS; only the tested bytes name the STRING. A zero on a token you didn't derive
this way is not evidence, and if you already reported one, retract it as void rather than
narrowing it. Kin: [[a-predicate-without-its-tool-is-not-evidence]],
[[name-the-file-and-sha-a-condition-came-from]].