diff --git a/machine-docs/BACKLOG-5.md b/machine-docs/BACKLOG-5.md
index 8f2b9f5..7d7b792 100644
--- a/machine-docs/BACKLOG-5.md
+++ b/machine-docs/BACKLOG-5.md
@@ -25,7 +25,7 @@ Single-writer: `## Build backlog` = Builder-only; `## Adversary findings` = Adve
 ## Adversary findings
 
 ### [adversary] A5-2 — CRITICAL: testme-on-pr.sh cannot read verdicts (commit status vs comment mismatch)
-**Status:** OPEN — Builder must fix before V2–V8 can pass.
+**Status:** CLOSED — re-tested 2026-05-31T19:41:12Z; see `REVIEW-5.md` follow-up entry.
 
 `testme-on-pr.sh` reads Gitea commit statuses on the recipe PR's head SHA. But the bridge NEVER
 sets Gitea commit statuses on recipe repos — it only posts PR comments (the YunoHost card+badge).
@@ -49,7 +49,7 @@ Drone posts commit statuses on the `cc-ci` repo (its own repo), not on recipe re
 (Only Adversary closes this, after re-testing with a VERDICT=GREEN on a real green build.)
 
 ### [adversary] A5-1 — custom-html-tiny not in bridge poll list
-**Status:** OPEN — needs Builder attention or plan clarification.
+**Status:** CLOSED — re-tested 2026-05-31T19:41:12Z; see `REVIEW-5.md` follow-up entry.
 
 The Phase 5 plan specifies using `custom-html-tiny` as the sandbox recipe for V3–V8 tests.
 However the bridge's poll list (from live container logs) does NOT include `recipe-maintainers/custom-html-tiny`:
diff --git a/machine-docs/BUILDER-INBOX.md b/machine-docs/BUILDER-INBOX.md
new file mode 100644
index 0000000..ce855aa
--- /dev/null
+++ b/machine-docs/BUILDER-INBOX.md
@@ -0,0 +1,16 @@
++# Builder Inbox
++
++2026-05-31T19:41:12Z
++
++Please correct the V2 HOW line in `machine-docs/STATUS-5.md`.
++
++Current text uses:
++`testme-on-pr.sh custom-html-tiny 2 POST=0`
++
++That is not poll-only. `POST=0` is an environment variable, so the correct form is:
++`POST=0 /srv/cc-ci/.claude/skills/recipe-upgrade/testme-on-pr.sh custom-html-tiny 2`
++
++I re-ran the current STATUS form and it posted comment `#13818` (`!testme`) and triggered build `#35`.
++The script itself is fine when invoked correctly: with env-prefixed `POST=0`, it returned
++`VERDICT=GREEN BUILD=https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/35` and the PR
++comment count stayed `4 -> 4`.
diff --git a/machine-docs/REVIEW-5.md b/machine-docs/REVIEW-5.md
index 80fca4c..b77d72f 100644
--- a/machine-docs/REVIEW-5.md
+++ b/machine-docs/REVIEW-5.md
@@ -116,3 +116,36 @@ positive window before bridge deployment; clears once bridge posts real `cc-ci/t
 ## Adversary findings
 
 (Tracked in BACKLOG-5.md)
+
+---
+
+## Cold-verify follow-up — 2026-05-31T19:41:12Z
+
+No `Gate: <Mn> CLAIMED` in `STATUS-5.md`, so I used the idle slot for a fresh V2 poll-only probe.
+I did **not** read `JOURNAL-5.md` before this verdict update.
+
+### A5-1 re-test: CLOSED
+- Fresh evidence from the live system: my accidental `!testme` comment `#13818` on
+  `recipe-maintainers/custom-html-tiny` PR #2 immediately produced a new `cc-ci/testme` commit status
+  pointing at Drone build `#35`.
+- That only happens if `custom-html-tiny` is enrolled in the bridge poll path, so A5-1 is no longer
+  reproducible.
+
+### A5-2 re-test: CLOSED
+- `GET /repos/recipe-maintainers/custom-html-tiny/commits/156a49ac/status` now includes context
+  `cc-ci/testme` with build URL `https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/35`.
+- Correct poll-only invocation from a cold shell:
+  `POST=0 MAX_WAIT=15 INTERVAL=5 /srv/cc-ci/.claude/skills/recipe-upgrade/testme-on-pr.sh custom-html-tiny 2`
+  returned:
+  `VERDICT=GREEN`
+  `BUILD=https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/35`
+- PR comment count stayed unchanged across that call (`4 -> 4`), confirming `POST=0` polls without
+  re-triggering.
+
+### Heads-up to Builder
+- `STATUS-5.md` currently records the poll-only command as
+  ``testme-on-pr.sh custom-html-tiny 2 POST=0``.
+- That syntax is wrong: `POST=0` is an **environment variable**, not a positional argument. Running
+  it that way posted a fresh `!testme` comment (`#13818`) and kicked off build `#35`.
+- This is a STATUS/HOW issue, not a new code defect. I notified the Builder via `BUILDER-INBOX.md` so
+  the verification instructions can be corrected before the next claim.