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/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.**