---
name: instrument-output-must-outlive-its-subject
description: "An instrument whose OUTPUT lives inside the tree its subject deletes returns an empty read that says 'no population' when the truth is 'the record was reaped before the reader ran'."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: f0a4566c-bdec-4537-a719-6e470f2f4279
  modified: 2026-08-18T20:04:56.629Z
---

Placing an instrument's sink where the SUBJECT resolves it is the right instinct for reach and the
wrong one for survival. Measured 2026-08-18 (releases#188, run 32119561081): a cross-process diag
sink was derived from `perch::spt_home()` — deliberately, so a spawned child with `stderr` nulled
would find it with no env plumbing. Under the rig that root resolves INSIDE the rig's own `TempDir`.
The test process exited, its `TempDir` drop removed the perch record **and the sink together**, and
the workflow's dump step ran **29 ms later** and read a one-line file a surviving process had just
re-created by appending to the deleted path. 5349 lines of cross-process census existed and were gone.

**The failure is not a lost log — it is a WRONG CLAIM the emptiness invites.** An empty sink reads as
*"no child wrote"*. The true statement was *"the record was reaped before it was read"*. Those license
opposite conclusions, and the first one closes a hunt.

**How to apply.** Before trusting an instrument's zero, ask which lifetime its OUTPUT is scoped to and
whether that lifetime ends before the READER runs. Name the deleting actor (a `TempDir` drop, a
cleanup step, a reap sweep) and where its boundary sits relative to the sink. The repair keeps
child-resolvability and steps one level out: `std::env::temp_dir()` resolved the CI sandbox root that
every process already inherits (`TMPDIR`/`TEMP`/`TMP`), a SIBLING of the rig's `TempDir` rather than
its child — and it was grounded in an existing project contract, `TestHome` setting only `SPT_HOME`
while the sandbox "exclusively controls TEMP/TMP/TMPDIR". The relocated run returned the writer's name
on the first try.

**Corollary worth carrying:** a surviving one-line file is not a small population, it is EVIDENCE OF
DELETION — its single line's timestamp dated the teardown to the millisecond and proved the file had
been recreated, not merely under-written.

**Operational corollary, once the sink SURVIVES: grep from the sink's dump marker DOWNWARD, never the
whole job log.** A sink is carried into a CI log by a dump step at the very END, so a site that fired
only in a null-stderr child appears exclusively below that marker. Measured 2026-08-18: a peer grepped
the whole log for the convicted write site and got zero — `livehost.rs:821` occurs **0 times in the
47,958 lines above the marker and 16 times below it**, on the run where it fired 16 times. His tool's
first-4MB search window never reached the dump either, so the zero had two independent causes and
neither was the truth. Anchor on the marker line, search down.

Sibling face of [[probe-before-teardown-not-at-assert]] (that one is a probe READ at teardown time;
this one is the instrument's OUTPUT destroyed by teardown). See also
[[healthy-path-emits-the-same-silence]] and [[absence-needs-sibling-probe]] — three ways a zero lies.