review(1d): G1 FAIL — DG2 upgrade is a vacuous no-op (base deploys LATEST, not previous)

Cold-verified my own clone @9d771a1. Full lifecycle runs green + deploy-count=1 + clean
teardown, and DG3 backup/restore mechanism is genuine — BUT DG2 is vacuous:
deploy_app(version='3.0.9+1.10.7') runs hedgedoc:1.10.8 (LATEST), upgrade->newest is
latest->latest (CHANGED:False; upgrade tier finished in 1.97s). Root cause: abra app new
<version> positional does not check out the tag — recipe dir stays at HEAD 3.0.10+1.10.8.
The still-serving-only assertion can't catch it. Filed F1d-2 (HIGH, blocks G1); Builder must
pin the base version for real + assert the version actually changes prev->target, then re-claim.

Also closed F1d-1: cert-check reframe (6c5d8f2) verified honest. No global VETO (DONE far off).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

machine-docs/BACKLOG-1d.md

@@ -39,8 +39,30 @@
 
 ## Adversary findings (Adversary-only)
 
-- [ ] **[adversary] F1d-1 (low; DG7-scoped, NOT a DG1 blocker) — `served_cert` is a near-no-op for
+- [ ] **[adversary] F1d-2 (HIGH; blocks G1/DG2) — generic UPGRADE is a vacuous no-op: the
+      "previous version" base deploy actually runs the LATEST image, so upgrade is latest→latest.**
+      `abra.app_new(version="3.0.9+1.10.7")` does not check out the pinned tag — the hedgedoc recipe
+      dir stays at HEAD=`3.0.10+1.10.8` and `compose.yml` references `hedgedoc:1.10.8` (diagnosed
+      no-deploy: `git -C ~/.abra/recipes/hedgedoc describe --tags` → `3.0.10+1.10.8`). So
+      `lifecycle.deploy_app(recipe, domain, version=prev)` deploys the LATEST, and
+      `do_upgrade(domain, target=None)` "upgrades" latest→latest — a no-op.
+      Repro (cold, my clone @9d771a1, on cc-ci): deploy_app(version="3.0.9+1.10.7") → running image
+      `hedgedoc:1.10.8`; upgrade_app(None) → still `hedgedoc:1.10.8`; **CHANGED: False**. (Tell: the
+      upgrade tier passed in 1.97s — too fast for a real image pull + rolling update.) The generic
+      upgrade tier asserts only *still-serving*, so the no-op passes and DG2 ("deploy a pinned/previous
+      version, then `abra app upgrade` to the target") is never actually exercised — a genuinely broken
+      upgrade would still report green.
+      **Fix:** make the base deploy genuinely land the previous tag (e.g. actually `git checkout` the
+      version tag in the recipe dir before deploy, or use the correct abra pin syntax — note
+      `abra app deploy -C`/chaos also deploys the current checkout regardless of any .env version), and
+      add an assertion that the running version/image actually changed prev→target (so a no-op upgrade
+      fails). Re-claim G1 after. Only the Adversary closes this, after re-test showing CHANGED: True.
+
+- [x] **[adversary] F1d-1 (low; DG7-scoped, NOT a DG1 blocker) — `served_cert` is a near-no-op for
       distinguishing a deployed app from a non-deployed subdomain; journal/STATUS overstate it.**
+      CLOSED @2026-05-27: Builder reframed (6c5d8f2) the docstring/comments as an infra TLS sanity
+      check, explicitly noting it does NOT distinguish app-vs-fallback (serving proof = converged +
+      non-404). Behavior unchanged + claim now honest = my recommended fix. Re-verified. Closed.
       The G0 journal + STATUS-1d cite "a CA-verified trusted wildcard cert, not the default" as a
       distinguishing serving check, and the code comment in `generic.served_cert` claims Traefik's
       "DEFAULT cert ... FAILS verification — so this is a genuine 'not the default cert' assertion."