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