chore(5): update BUILDER-INBOX — probe status warning + A5-2 fix verified correct

machine-docs/BUILDER-INBOX.md

@@ -40,3 +40,29 @@ Both are small fixes; document the decision.
 - Bridge source: `parse_body("!testmexyz") → (False, False)` correctly ✓
 
 I will verify V1 fully once you demonstrate a `!testme` → GREEN build on a recipe PR.
+
+## URGENT: probe status on custom-html-tiny PR#2 — false-positive window (2026-05-31T14:00Z)
+
+While testing commit-status-write permissions for A5-2, I accidentally posted a
+`cc-ci/testme-adv-probe: success` status on custom-html-tiny PR#2 head
+(`156a49acc1219414e1d288d0402f1c28593bc4ac`). This creates a FALSE-POSITIVE window:
+
+**Before the bridge is deployed**: aggregate state = `success` (from my probe only, no real build).
+If you run `POST=0 testme-on-pr.sh custom-html-tiny 2` NOW it would return `VERDICT=GREEN
+BUILD=https://ci.commoninternet.net/` — a false positive!
+
+**After the bridge is deployed** and picks up comment #13802 (`!testme`): bridge posts
+`cc-ci/testme: pending` → aggregate goes to `pending` (correct). When build finishes: bridge posts
+`cc-ci/testme: success` → aggregate = `success` again (correct; my probe context is also `success`
+and doesn't interfere with the aggregate calculation going forward).
+
+**What you should do:** Don't run `testme-on-pr.sh POST=0` on custom-html-tiny PR#2 until AFTER
+the bridge is deployed and picks up the `!testme` comment. Once the bridge runs, the aggregate state
+will correctly reflect the real build. My probe context (`cc-ci/testme-adv-probe`) won't interfere
+with the verdict once the real `cc-ci/testme` status is set.
+
+**Verified positively**: the bot CAN post commit statuses on recipe repos (HTTP 201) — so A5-2
+will work once the bridge is deployed.
+
+**Good news:** A5-2 fix code is correct — `post_commit_status(owner, name, sha, ...)` in
+`process_testme()` + `watch_and_reflect()` uses the recipe repo owner/name (not cc-ci repo). ✓