diff --git a/agent/HARDWARE-QUEUE.md b/agent/HARDWARE-QUEUE.md
index ee9d21c..d920347 100644
--- a/agent/HARDWARE-QUEUE.md
+++ b/agent/HARDWARE-QUEUE.md
@@ -158,18 +158,27 @@ the **T14s** (webcam case).
       `systemd-inhibit --list`, `hyprctl monitors all -j`, `hyprctl workspaces
       -j`, and `pactl --format=json list sinks` before changing state again.
 - [ ] **Parallel fingerprint-or-password on the real reader** (AMD dev
-      box, 2026-07-12) — with a finger enrolled and
-      `fingerprint.pam = true` (parallel is the default): `sudo -k true`
-      must show ONE prompt ("Enter Password or Place finger…"); typing
-      the password immediately works, touching the sensor instead works,
-      wrong-finger ×3 falls back to password, and password keeps working
-      with fprintd stopped (`systemctl stop fprintd`). Also check
-      hyprlock and the greeter accept both factors and don't wedge on a
-      leftover prompt after a fingerprint win (known cosmetic quirk of
-      the hack — pthread_cancel'd prompt). `fingerprint.parallel = false`
-      must restore the old sequential behavior. VM already asserts the
-      PAM stack shape + password-only lockout safety with no reader
-      (checks.hardware-toggles).
+      box, 2026-07-12) — **sudo path PASSED 2026-07-14** (Bernardo, dev box,
+      gen 422, `fingerprint.pam = true`, parallel default): `sudo -k true`
+      showed ONE prompt, the typed password worked, touching the sensor
+      instead worked, and wrong-finger ×3 fell back to password.
+      **Still open:** hyprlock and the greeter must accept both factors and
+      not wedge on a leftover prompt after a fingerprint win (known cosmetic
+      quirk of the hack — pthread_cancel'd prompt); `fingerprint.parallel =
+      false` must restore the old sequential behavior.
+      **Do NOT "check password still works with `systemctl stop fprintd`"** —
+      that check was in this item and it is a trap that cannot fail. fprintd
+      is D-Bus activated, so PAM asks D-Bus and D-Bus starts it straight back
+      up: Bernardo ran it and *the fingerprint still authenticated*, which is
+      the tell that the daemon never stayed down. It proves nothing about a
+      dead reader. The property it was reaching for is structural anyway —
+      password is `auth sufficient` at order 11700, independent of the fprintd
+      rule at 11400, so no fprintd failure can gate it (verify by eval:
+      `nix eval --raw <flake>#nixosConfigurations.<host>.config.security.pam
+      .services.sudo.text`), and checks.hardware-toggles asserts that shape in
+      the VM with no reader at all. If someone genuinely wants it on hardware
+      it needs `systemctl mask` + stop, and masking a working machine's
+      authentication daemon to re-prove an evaluated invariant is a bad trade.
 - [ ] **#55 fingerprint enroll on real reader** — with
       `nomarchy.hardware.fingerprint.enable` and a physical reader: System ›
       Fingerprint › Enroll a finger; List shows it; Verify succeeds; optional