review(1d): G1 PASS (re-claim) — F1d-2 fixed, upgrade non-vacuous (verified both ways)

Cold my clone @c965f6c: genuine prev->target MOVES (deploy 3.0.9->image 1.10.7; upgrade->1.10.8;
version label changed) AND a no-op upgrade now RAISES 'did not move'. DG2 non-vacuous +
regression-locked; DG3 genuine. Closed F1d-2. G2 (custom-html overlays) verification in progress
(unit tests 5/5; full overlay lifecycle pending — Builder run in flight on the node, waiting).

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

machine-docs/BACKLOG-1d.md

@@ -40,8 +40,13 @@
 
 ## Adversary findings (Adversary-only)
 
-- [ ] **[adversary] F1d-2 (HIGH; blocks G1/DG2) — generic UPGRADE is a vacuous no-op: the
+- [x] **[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.**
+      CLOSED @2026-05-28: Builder fix 81e26a1 (recipe_checkout to the tag + non-chaos pinned deploy +
+      a version/image move-assertion in do_upgrade). Re-verified cold both ways from my clone @c965f6c:
+      genuine prev→target now MOVES (deploy 3.0.9→image 1.10.7; upgrade→1.10.8; version label
+      3.0.9+1.10.7→3.0.10+1.10.8, CHANGED), and a no-op upgrade now RAISES "did not move". DG2
+      non-vacuous + regression-locked. Closed.
       `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

machine-docs/REVIEW-1d.md

@@ -109,6 +109,39 @@ F1d-2, after a re-test showing the running image actually changes prev→target.
 
 ---
 
+## G1 / DG2+DG3 — **PASS** @2026-05-28 (re-claim after F1d-2 fix)
+
+**Claim:** after the F1d-2 fix, the base deploy lands the pinned previous version and the upgrade
+genuinely moves prev→target, with a move-assertion guarding against a no-op; DG3 unchanged.
+
+**Method — cold, my own clone.** `git checkout c965f6c` in `/root/adv-verify` (tree clean); audited
+the fix diff (81e26a1: `abra.recipe_checkout` git-checks-out the tag; `deploy_app` deploys NON-chaos
+when pinned, chaos only for version=None; `do_upgrade` asserts the deployment MOVED via
+`deployed_identity`). Re-ran my F1d-2 delta probe BOTH directions.
+
+**Evidence (my clone @c965f6c on cc-ci):**
+- *Genuine prev→target (was the bug):* deploy base `3.0.9+1.10.7` → identity
+  `('3.0.9+1.10.7', hedgedoc:1.10.7@sha256:3174ab…)` (NOW the real previous, not LATEST); after
+  `do_upgrade` → `('3.0.10+1.10.8', hedgedoc:1.10.8@sha256:423f41…)` → **do_upgrade PASSED, moved.**
+- *No-op guard (regression lock):* deploy newest, upgrade→newest → `do_upgrade` **RAISED**
+  "upgrade did not move the deployment (version 3.0.10+1.10.8→3.0.10+1.10.8, image …)". A vacuous
+  upgrade can no longer pass — the move-assertion is genuine, not itself a no-op.
+- DG3 (backup snapshot artifact + healthy restore) already verified genuine @G1-FAIL run; deploy-count=1
+  and clean teardown carried forward; both probe deploys here also tore down (orphan check below).
+
+**Verdict: DG2 + DG3 PASS — G1 cleared.** F1d-2 closed (see findings). No VETO.
+
+---
+
+## F1d-2 — CLOSED @2026-05-28 (upgrade non-vacuous; verified both directions)
+
+Builder fix 81e26a1 (recipe_checkout to the pinned tag + non-chaos pinned deploy + a
+version/image move-assertion in `do_upgrade`). Re-tested cold from my clone: a genuine prev→target
+upgrade MOVES (1.10.7→1.10.8, CHANGED) and a no-op upgrade now RAISES. Matches my recommended fix
+(land the real previous tag + assert the version actually changed). **F1d-2 closed.**
+
+---
+
 ## F1d-1 — CLOSED @2026-05-27 (cert-check reframe verified honest)
 
 The Builder reframed `served_cert`/`assert_serving` (commit 6c5d8f2): docstrings + comments now scope