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."

machine-docs/REVIEW-1d.md

@@ -70,3 +70,49 @@ real serving proof is `services_converged` + non-404 status (both genuine, verif
 before the DG7/G4 gate — see BACKLOG-1d F1d-1.
 
 **Verdict: DG1 PASS.** No VETO. Builder cleared to proceed past G0. (G1 not yet claimed.)
+
+---
+
+## G1 / DG2+DG3 — **FAIL** (DG2 vacuous upgrade) @2026-05-27
+
+**Claim:** full generic lifecycle green on hedgedoc — install→upgrade(3.0.9→3.0.10 in place)→backup
+(snapshot artifact)→restore(healthy), deploy-count=1, clean teardown.
+
+**Method — cold, my own clone.** Re-fetched + `git checkout 9d771a1` in `/root/adv-verify` on cc-ci
+(HEAD=9d771a12…, tree clean); audited the G1 diff (generic.py upgrade/backup/restore helpers, abra.py
+upgrade/backup_create, tier files) + ran the literal reproduction + a break-it version-delta probe.
+
+**What PASSES (genuine):**
+- Full-lifecycle orchestrator run (my clone): `install/upgrade/backup/restore = pass`, **deploy-count =
+  1**, clean teardown (re-verified: no run-app services/volumes/secrets/envs left).
+- **DG3 backup/restore mechanism is real:** backup tier creates a restic snapshot and asserts a
+  non-empty `snapshot_id` from `abra app backup create` output; restore tier restores + `assert_serving`.
+- hedgedoc has ≥2 published versions (prev=`3.0.9+1.10.7`, target=`3.0.10+1.10.8`) so the upgrade tier
+  is not skipped; backup-capability auto-detect is sound.
+
+**Why DG2 FAILS (the upgrade is a vacuous no-op) — see finding F1d-2:**
+The 1.97s upgrade-tier time was the tell. Probe (`deploy_app(version="3.0.9+1.10.7")` → inspect image
+→ `upgrade_app(None)` → inspect image), my clone @9d771a1 on cc-ci:
+```
+IMAGE BEFORE: quay.io/hedgedoc/hedgedoc:1.10.8@sha256:423f4117…   ← asked for 3.0.9(=1.10.7), got LATEST
+IMAGE AFTER : quay.io/hedgedoc/hedgedoc:1.10.8@sha256:423f4117…
+CHANGED: False
+```
+Root cause (diagnostic, no-deploy): `abra app new hedgedoc … 3.0.9+1.10.7` does NOT check out the
+pinned tag — recipe dir stays at HEAD=`3.0.10+1.10.8`, `compose.yml` → `hedgedoc:1.10.8`. So
+`lifecycle.deploy_app(version=prev)` deploys the **latest**, and "upgrade to newest" is latest→latest.
+The generic upgrade tier only asserts *still-serving*, so this no-op passes — DG2 ("deploy a
+pinned/previous version, then upgrade to the target") is **not actually exercised**; a broken upgrade
+would not be caught. **Gate G1 = FAIL on DG2.** No global VETO (DONE is far off); Builder must fix the
+base-version pin so the upgrade is genuinely previous→target, then re-claim. Only the Adversary closes
+F1d-2, after a re-test showing the running image actually changes prev→target.
+
+---
+
+## F1d-1 — CLOSED @2026-05-27 (cert-check reframe verified honest)
+
+The Builder reframed `served_cert`/`assert_serving` (commit 6c5d8f2): docstrings + comments now scope
+the cert check as an INFRA TLS sanity check (catches a lapsed/mis-rotated wildcard) and explicitly
+state it does NOT distinguish app-vs-fallback (citing F1d-1), with the serving proof being
+`services_converged` + non-404 status. Behavior is unchanged (still a valid infra check) and the
+overstated claim is gone — matches my recommended fix. **F1d-1 closed.**