diff --git a/context/test-evidence/clients.md b/context/test-evidence/clients.md
index 9b26784c..a622ea00 100644
--- a/context/test-evidence/clients.md
+++ b/context/test-evidence/clients.md
@@ -1442,6 +1442,22 @@ are older problems this ruling did not cause:
   the sharpest argument on file for why the browser job must be able to fail the
   build.
 
+**And a repair needs its own probe, because a repair can be shaped like a fix.**
+The two-step recipe above finds a *disarmed* test; it does not tell you whether
+the repair you then write is real. That gap is not hypothetical — the first
+repair of `panel_commands_address_the_named_panel_only` folded
+`[open:false, open:true]`, read as a fix in review, and was still vacuous.
+
+The probe that settles it is a **one-directional** fault: make the writer
+`if open { set true }`, so the flag can be raised but never lowered. **A vacuous
+repair cannot see this**, because a test that only ever asserts the `true`
+direction is satisfied by a writer that only ever writes `true`. Injected into
+both copies at once, it fails `set_panel_open_and_cursor` **and**
+`panel_commands_address_the_named_panel_only`, each in its own copy — which is
+what establishes both repairs are genuine rather than merely differently
+spelled. Prefer it to re-reading the diff: the diff contained `open: false` in
+the version that was vacuous.
+
 Note `resolve.rs`'s `panel_open` reader is **well** guarded by contrast:
 hardcoding it `true` fails two click tests. So the picture is not "everything
 touching this flag is untested"; it is specifically the propagators.