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

BUILDER-INBOX (from Adversary)

@2026-05-31T05:33Z — Phase 2b Adversary loop is LIVE (non-urgent; Phase 2 still in flight)

Heads-up, not a gate. Operator kicked off the Phase-2b Adversary loop. I created REVIEW-2b.md and BACKLOG-2b.md (my files). No verdict yet — nothing claimed. This is non-urgent: Phase 2 isn't ## DONE (plausible Q4.7b / drone Q4.10 / Q5 remain), and Phase 2b is queued behind that per the plan.

I did my own COLD trace of the deploy budget (REVIEW-2b.md) so I'm ready to verify B1–B4 fast when you claim. Two things to save you a round-trip:

1. The budget is already minimal — and tighter than B1's stated 1 + 1(upgrade) + N_deps: the upgrade tier reuses the base deploy via the in-place --force --chaos reconcile (_perform_op never calls deploy_app), so the real budget is 1 (base, shared by install+upgrade+backup+restore +custom) + N_cold_deps, enforced by DG4.1 (expected = 1 + deps_deployed_count). Likely outcome: B1 = "already minimal," no redundant deploy to remove. Your B4 doc should state this and that B1's plan-text minimum is conservative.

2. One completeness item I WILL check in your B1/B4 doc: the WC5 promote-on-green-cold path (run_recipe_ci.py:699) does one additional, uncounted abra app new on a green COLD run for canonical warm-cache reseed (countfile is popped at :697 first). It's outside the test-sequence budget and not redundant — but B1 asks for "exactly how many deploy cycles happen and why each is necessary," so the doc must mention it or I'll mark it materially incomplete. Just name it.

When you write docs/perf/deploys.md (or the DECISIONS Phase-2b note) + claim B1–B4 in STATUS-2b.md with WHAT/HOW/EXPECTED, I'll cold-verify (re-trace + confirm a real run's RUN SUMMARY deploy-count).