diff --git a/machine-docs/JOURNAL-redfix.md b/machine-docs/JOURNAL-redfix.md
index 11e6ed0..64a4a97 100644
--- a/machine-docs/JOURNAL-redfix.md
+++ b/machine-docs/JOURNAL-redfix.md
@@ -2263,3 +2263,48 @@ down at its wake #49.
 
 Stop condition (`STATUS-redfix.md` says `## DONE`, no standing VETO, counterparty stopped) is met. Stopping
 the loop. No action taken this wake.
+
+---
+
+## Wake #58 — 2026-07-09 — Adversary verdict `5431252` acted on: their PASS holds, but their probe skipped a surface — and closing it falsified my own STATUS
+
+Watchdog ping on a `review(...)` commit. The verdict was a **PASS, no VETO** (oauth2 token does not leak to
+dashboard / weekly reports / Drone log API). Nothing to rebut on its face — so the useful move was to ask
+what the probe *didn't* cover.
+
+**Why I didn't just acknowledge.** The Adversary's five steps probe run dirs, the dashboard, the report site,
+and the Drone log API — then conclude *"the invariant now holds for both exposed credentials."* But
+B-redfix-8 is not a dashboard leak. It is a **public git mirror** leak: a blob at a fixed sha, served
+unauthenticated, permanent. That surface appears nowhere in their method. The conclusion generalised from
+"published run/report/log surfaces" to "all published surfaces" — and the omitted surface is precisely the
+one that already burned this project once. A PASS resting on an untested inference is worth testing.
+
+**What the test found.** Exhaustive literal-value scan of all 3099 blobs in the object db, positive-controlled:
+
+- **Token: 0 / 3099.** Their conclusion **survives, and now extends to the mirror.** The 271 blobs matching
+  the string `oauth2:` are `recipe-mirror-sync.sh:39`'s `${TOKEN}` interpolation and prose citing the sha16
+  sentinel. Token exposure is filesystem-only.
+- **Password: 2 blobs / 2 published commits** — `14c7dee` *and* `223cc16`, both ancestors of `origin/main`.
+  My own STATUS said "**only** the historical commit `14c7dee` serves it." **Wrong, and it understated the
+  exposure in the direction that matters:** an operator following my STATUS would scrub `14c7dee`, believe
+  the leak closed, and leave `223cc16` serving the live push-capable credential. Corrected in `2a2f2f7`.
+
+So the wake's real yield was a defect in *my* artifact, found by taking the Adversary's claim seriously
+enough to test its edges rather than its centre. The asymmetry now recorded — password on mirror+FS, token
+on FS only — changes the operator remedy: a history scrub is required for one credential and pointless for
+the other.
+
+**Near-miss worth recording.** My first scan pipeline used `awk`. `awk` is **not installed** on the
+orchestrator. The blob list came back **empty**, and the scan dutifully reported **`0` token hits and `0`
+password hits** — a clean bill of health from a probe that examined nothing. I caught it only because
+`0` password hits contradicted the *known* leak. That is exactly the trap STATUS already documents for the
+empty-string sentinel `e3b0c44298fc1c14`, in a new costume. **A negative result from an unvalidated probe is
+not evidence.** I have promoted the positive control (password *must* return 2) into STATUS, BACKLOG, and the
+inbox as a mandatory step, because the next agent to run this scan will not remember this wake.
+
+**Hygiene.** Token pulled root-only into a `chmod 600` file, never transmitted off-node, `shred`-removed. Re-
+scanned after committing: still exactly 2 password blobs — my correction added no new exposure.
+
+Sent `ADVERSARY-INBOX.md` (`29d2b22`) for cold adjudication. No gate CLAIMED, no VETO sought.
+`## DONE` stands. Operator-scope; the credential rotation and the (now two-commit) scrub remain the
+operator's to perform. Loop continues until the Adversary adjudicates.