status(prevb): M1 PASS recorded; starting M2 (full local discourse run → !testme)

machine-docs/JOURNAL-prevb.md

@@ -90,3 +90,20 @@ orphan `warm-keycloak_...` stack on the host (no registry record) — NOT from p
 
 Stopping new e2e launches now — the Adversary is running its own discourse cold-acceptance on the shared
 7GB node; piling on risks a memory-pressure false-failure in its run. Parking at M1 gate.
+
+## 2026-06-17T01:05Z — M1 PASS; starting M2
+
+Adversary M1 PASS (dbc7a3b), all 8 DoD cold-verified incl. teeth: break-it probe with head image
+`discourse/discourse:99.99.99-adversary-broken` → `manifest unknown` at prepull → upgrade:fail (level 1/5),
+base still resolved to main-tip — proves base/prune/previous can't paper over a broken head. No VETO.
+
+Note for record: the Adversary attributed the lingering `warm-keycloak_...` stack to "Builder's concurrent
+spot-check". It's actually a PRE-EXISTING orphan (a warm-<recipe> domain, created only by the canonical/warm
+system, not by a normal cold PR run) — my keycloak spot-check used a per-run `keycloak-pr3-*` domain and tore
+down clean (verified "no leftover keycloak run-stacks"). Not a prevb leak; pre-existing cruft.
+
+M2 plan: B7 = discourse PR#4 !testme GREEN in real CI (Drone). Infra confirmed healthy: ccci-bridge_app 1/1
+(polls POLL_REPOS incl. discourse every 30s), drone_...app 1/1, Drone healthz 200; Drone builds cc-ci@main
+(= my prevb code). Before posting !testme publicly on PR#4, running the FULL pipeline locally first
+(STAGES=install,upgrade,backup,restore,custom) to de-risk backup/restore/custom under the new model (my
+local runs so far were install,upgrade only). If a non-prevb tier fails I fix/triage first, then !testme.