chore(5): update state files; consume BUILDER-INBOX (A5-1/A5-2 fixes applied, bridge redeployed)

machine-docs/BUILDER-INBOX.md

@@ -1,68 +0,0 @@
-# BUILDER-INBOX
-
-**From Adversary, 2026-05-31T13:45Z — Phase 5 orientation findings**
-
-Phase 5 Adversary loop initialized. Phase 5 state files created in my clone (REVIEW-5.md,
-BACKLOG-5.md). Phase 5 Builder hasn't started yet — write STATUS-5.md when you begin.
-
-## Critical finding: testme-on-pr.sh CANNOT read verdicts (A5-2, BLOCKING for V2–V8)
-
-`testme-on-pr.sh` reads Gitea commit statuses on the recipe PR's head SHA. But:
-- The bridge NEVER posts commit statuses on recipe repo commits
-- Drone posts statuses only on the `cc-ci` repo (its own pipeline builds)
-- Result: `POST=0 testme-on-pr.sh custom-html 2` → always `VERDICT=PENDING`, even on a known-green PR
-
-Confirmed cold: `GET /repos/recipe-maintainers/custom-html/commits/db9a95024e9d.../status` →
-`state:'', statuses:0` (zero statuses on the recipe PR head SHA after Drone build #7).
-
-This is the EXACT gap the Phase 5 plan anticipated (§2: "commit status vs comment — reconcile here").
-
-**Recommended fix:** Modify the bridge to POST a Gitea commit status on the recipe PR's head SHA:
-- On build trigger: `POST /repos/{owner}/{recipe}/statuses/{sha}` with `state=pending`, `target_url=<drone-build-url>`
-- On build finish: POST `state=success` or `state=failure` with the same target_url
-
-This makes `testme-on-pr.sh` work unmodified and adds the native Gitea PR status indicator.
-Record the decision in DECISIONS.md.
-
-## Secondary finding: custom-html-tiny not in bridge poll list (A5-1)
-
-The plan uses `custom-html-tiny` as the sandbox recipe. It's NOT in the bridge's POLL_REPOS.
-A `!testme` on a custom-html-tiny PR will silently do nothing. You'll need to either:
-1. Add `custom-html-tiny` to POLL_REPOS (enroll it), OR  
-2. Use `custom-html` (already enrolled) as the sandbox recipe instead
-
-Both are small fixes; document the decision.
-
-## V1 break-it probes (no Builder action needed)
-
-- `!testmexyz` on watched repo (custom-html PR#2): correctly rejected — 9 bridge log lines, no match ✓
-- Non-collaborator auth: `GET /orgs/recipe-maintainers/members/nonexistent-user-999` → 404 ✓
-- 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). ✓