docs(memory): name the fleet's characteristic failure mode

svos-dev observed that three instances of the same shape turned up between two
agents in one night and that it is starting to look like a characteristic failure
rather than a coincidence. Collecting all nine from today, because the class is more
useful than any instance.

The shape is a check that reads the input to a transformation and gets reported as
if it read the output - or more generally, the instrument answering instead of the
system, in a form shaped exactly like a real answer. What makes it expensive is not
that things break but that the broken state is indistinguishable from a legitimate
one, so it passes review and is found later by accident. Every one of the nine
passed a check.

The tell is stated so it can be recognised prospectively: whenever 'broken' and
'legitimately empty, absent or off' produce the same output, the cheap check cannot
tell them apart by construction.

Remedies that actually worked today: measure the output rather than the input;
positive controls, since a method that has only ever passed cannot tell you it is
not blind; true-negative controls, because two apparent failures in the
secrets-broker test were names I had invented and would have been read as a partial
fix; refuse to emit the ambiguous value, which was the real fix rather than the
lock; and do not declare victory on a plausible fix, which is the only reason the
session-establishment root cause was found at all.

persistent-memory.d/2026-09-15-silent-wrong-answer-pattern.md

@@ -0,0 +1,72 @@
+# ⭐⭐ The fleet's characteristic failure: a confident answer from a broken instrument
+
+Named by svos-dev 2026-09-15 after three instances turned up between two agents in one
+night. Collecting them here because the *class* is more useful than any instance, and
+because every one of them **passed a check**.
+
+## The shape
+
+> **A check that reads the INPUT to a transformation, reported as if it read the OUTPUT.**
+>
+> Or, more generally: the instrument answers instead of the system, and its answer is
+> shaped exactly like a real one — no error, no timeout, usually exit 0.
+
+What makes this class expensive is not that things break. It is that **the broken state
+is indistinguishable from a legitimate one**, so it survives review, passes CI, and is
+found later by accident.
+
+## The instances, 2026-09-15 alone
+
+| # | instrument said | reality | why it passed |
+|---|---|---|---|
+| 1 | `provider=cuda` in the log | ORT had silently fallen back to **CPU** | the line echoes the *configured* env var, never the running EP |
+| 2 | `node --check` green, `import app` green | the served page's **entire inline script was dead** | a JS `'didn\'t'` inside a Python string arrives as `'didn't'`; the FILE still holds the backslash |
+| 3 | `secret get` → `""`, **exit 0** | a failed vault read | callers read an empty *optional* secret as "not configured" |
+| 4 | `find()` → **"not found: <name>"** | a failed listing (`json.loads(stdout or "[]")`) | an empty stdout became a confident, authoritative negative |
+| 5 | `/v1/toolsets` → **0 toolsets** | my credential lookup returned empty → 401 | an auth failure renders identically to an empty roster |
+| 6 | `hermes plugins compat <typo'd path>` → **✓ exit 0** | nothing was scanned | "no hits" and "no files" are the same result |
+| 7 | `hermes plugins doctor` → **exit 0** | it had printed `ERROR` | needs `--ci` to exit non-zero |
+| 8 | `ss -ltnp \| grep python` → nothing | the listener was there, named **`hermes`** | the filter narrowed the window without announcing it |
+| 9 | SIGTERM → **port free** | process alive another **35 s** | a script waiting on the port starts a second copy |
+
+Prior art already in memory, same class: `pct snapshot` exiting 0 while refusing;
+"an unreachable post office is an OUTAGE, never an empty inbox"; `docker logs --since`
+returning 0 for a line that exists.
+
+## The tell
+
+⚠ **Whenever "broken" and "legitimately empty / absent / off" produce the same output,
+you have one of these** — and the cheap check will not tell them apart, by construction.
+
+## What actually works
+
+1. **Measure the OUTPUT, not the input.** Not `provider=cuda` in a log — a process
+   holding memory on the pinned card. Not `node --check` on the file — parse the page
+   **as served**.
+2. **Positive control, every time.** Run something the method *must* detect. #6 was
+   caught by scanning a plugin with a known-deprecated import; the clean result only
+   became meaningful once the instrument had proven it could fail.
+3. **Negative control too** — ⚠ but check the negative is a *true* negative. Two
+   "failures" in the secrets-broker test were **names I had invented**; without checking,
+   I would have read two true negatives as a partial fix and kept digging at a bug that
+   was already gone.
+4. **Refuse to emit the ambiguous value.** The real fix for #3 and #4 was not the lock —
+   it was making an empty result a loud non-zero instead of a plausible answer.
+5. ⭐ **Don't declare victory on a plausible fix.** A lock is such an obvious answer to a
+   race that "I added a lock" reads as done. The first lock was in the wrong place and
+   still failed; the root cause (concurrent `bw unlock` at *session establishment*) only
+   surfaced because the plausible fix was tested and did not work.
+
+## ⚠ And the instrument itself can be stale
+
+`~/.local/bin/secret` was a **plain copy** of the repo file, in sync by luck. Every repo
+edit silently left the live tool behind, so the first "fixed" test ran the OLD code.
+Caught it; the next person could read stale output as proof a correct fix failed and
+revert it. Now a symlink. **Check what you are running, not what you edited.**
+
+## Related
+
+`2026-09-15-talk-v10-deploy.md` (#2, and the gate built for it),
+`2026-09-15-parakeet-stt-fv-ml1.md` (#1),
+`2026-09-15-svos-miranda-plugin-validation.md` (#6, #7, #8),
+`2026-09-15-irv-ml1-address-sweep-done.md` (the ana-docker/litellm neighbour trap).