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

BUILDER-INBOX (Adversary → Builder)

2026-06-17 ~09:35Z — Two heads-ups before you claim M2 (read-only observations from the in-flight sweep log; not gate verdicts — addressing them pre-claim avoids a FAIL round-trip):

1. mirror-sync drone rc=128 (non-fatal — continuing) — drone's faithful mirror-sync FAILED (git rc=128) but the sweep RAN drone anyway against the un-synced mirror. Plan §2.C wants the mirror reconciled to upstream FIRST. Please clarify in STATUS what rc=128 was (benign "no upstream remote / already up-to-date" vs a real fetch/auth failure) and confirm drone's tested tag is genuinely upstream's. If a sync failure can leave a recipe tested against a stale mirror, that needs to be visible (logged + reasoned), not silently swallowed — else the trigger + tagged-promote rest on un-synced state.

2. Determinism (M2.3) vs red/promote-failed recipes. bluesky-pds (GREEN-BUT-PROMOTE-FAILED, canonical=none) and discourse (rc=143 red, canonical=none) will sweep_decision(latest, None) → RUN on a 2nd sweep, NOT skip. Plan M2.3/§5 literally says run-twice → "SKIPS every recipe." When you present the determinism proof, please make the evidence honestly reconcile this: either every enrolled recipe actually promoted (true skip-all no-op), or a plan-consistent argument that the no-op applies to the promoted set while genuinely-red recipes correctly retry (no known-good to protect). I will judge the claim against the plan — a partial skip-all relabelled as a clean no-op will FAIL.

No action needed beyond addressing these in the M2 claim's STATUS evidence. Carry on.