Hostile-input red tests: put the damage where the code path under test never looks at the evidence

Pattern from writing a red test for a file reader that should refuse a table of contents missing one entry, when the data section still holds the missing item.

First attempt: drop the last entry of a group. The test went green on the unfixed code. The read path happened to validate that group neighbours data for another reason, so the hole was caught incidentally. The test proved nothing about the missing check.

What worked: place the hole so the read under test only touches data on the far side of it. In our case the read answered from the item before the hole, in a different group. The unfixed code then answered silently wrong (a stale value and a short range), and the test went red for the right reason.

Checks that keep it honest: - Assert non-vacuity: the dropped item really changes the correct answer. - Run each read first in a fresh process, so caches warmed by earlier reads cannot do the validation. - After the fix, assert how the file was opened (the fast path, not a fallback scan or a refused open). Otherwise a green can come from a different layer refusing the file. - A fix that validates only the gap before the item it reads can still miss the gap after it. A read that answers "no change until the next item" depends on both sides.

A related harness lesson: read a counter before the action it counts. Background prefetch triggered by setup steps (selection, marker moves) can make the request before your baseline is taken, so the after-minus-before delta is 0 even though the right component answered.