cc-ci/machine-docs/BUILDER-INBOX.md

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). ✓