inbox(2): consumed Adversary dashboard-empty heads-up (977b01f) — recorded Q5/DONE forward-criterion (dashboard via !testme OR operator-blessed cc-ci-run==P1); flagged for operator, not a veto

machine-docs/STATUS-2.md

@@ -1074,3 +1074,17 @@ start_period:1200s via install_steps + recipe_meta COMPOSE_FILE+CHAOS_BASE_DEPLO
 R011/R012 version-mismatch FATA → overlay needed matching version:"3.8". **NEXT:** author ≥2 discourse
 functional (incl §4.3 create-topic) for P3 — currently only health_check; then FULL lifecycle
 (install,upgrade,backup,restore,custom) green → CLAIM Q4.6. NOT yet claimed.
+
+### Q5/DONE forward-criterion @2026-05-30 (Adversary BUILDER-INBOX, REVIEW-2 977b01f) — NOT a veto
+**Live dashboard shows 0 run records:** every Phase-2 verification (Builder + Adversary) used host
+`cc-ci-run` (orchestrator direct), which does NOT publish to the dashboard; the literal
+`!testme`→Drone→publish path hasn't been exercised for the Phase-2 suite. Before the Q5/DONE handshake
+the Adversary requires EITHER (a) the dashboard shows Phase-2 suite runs via the real `!testme` path,
+OR (b) an **operator-blessed** statement here that host `cc-ci-run` validation satisfies P1 (the
+trigger is recipe-agnostic + proven end-to-end once in Phase-1 D10/D7) and the empty live dashboard is
+acceptable for DONE. **Builder position:** (b) is the proportionate path — the `!testme`→Drone→publish
+machine was D1/D7-proven in Phase 1 and is recipe-agnostic, so re-driving every Phase-2 recipe through
+Drone re-tests the *trigger*, not the *recipe tests* (which is what Phase 2 is about); but (b) needs an
+OPERATOR decision, so this is flagged for operator input (not self-grantable). Alternatively a single
+representative Phase-2 recipe driven through real `!testme` would satisfy (a) at low cost — candidate
+once the current recipe-PR work settles. **OPEN — operator pick (a) vs (b) before DONE.**