note(2): pre-assess ghost F2-14b BACKUP_VERIFY retry (68a7c79) — sound on static read (no persistent-failure mask, read-only probe); verdict bar set; NOT a verdict, VETO stands

machine-docs/REVIEW-2.md

@@ -2324,3 +2324,25 @@ PROVISIONAL CONCLUSION: appears `plan-ccci-compose-overlay-policy.md`-compliant
 clean teardown), which the Builder has not yet claimed. When claimed I will (a) confirm the overlay on cc-ci is
 byte-identical to git, (b) confirm upgrade-tier base actually deploys with it + converges, (c) confirm head
 deploy is idempotent. VETO on DONE stands.
+
+## NOTE (pre-assessment, NOT a verdict, does NOT clear the VETO) @2026-05-30T21:34Z — ghost F2-14b BACKUP_VERIFY hook + retry (Builder fix `68a7c79`)
+Examined the harness backup-integrity-retry fix statically (commit + `runner/run_recipe_ci.py` + `tests/ghost/recipe_meta.py`).
+NOT claimed yet — no green ghost full-suite run on this shape. Recording my verdict bar before the claim lands:
+- **Retry does NOT mask a persistent failure (sound):** loop is `while verify False and attempt < 3` → caps at 3, then
+  *proceeds* (only `print`s "still FAILED", does NOT abort/sentinel the op). The downstream `test_restore.py::
+  test_restore_returns_state` still re-reads the seeded `ci_marker` from the restored snapshot, so a genuinely-broken
+  backup surfaces RED at restore. P4 stays non-vacuous. ✓
+- **Probe is read-only** (`gzip -t /var/lib/mysql/backup.sql.gz && wc -c`), gated `>0` + valid-gzip; weakens no assertion. ✓
+- **Additive/recipe-scoped** via `recipe_meta.BACKUP_VERIFY` (same pattern as READY_PROBE); recipes without it unaffected. ✓
+- **TOCTOU gap to confirm at verdict (not a blocker on static read):** the probe validates the LIVE db-volume file via
+  `exec_in_app(...,service="db")`, NOT the restic snapshot that `abra app backup create` produced. Benign ONLY IF the
+  backupbot db pre-hook fully completes the dump before restic snapshots (pre-hook→snapshot ordering) so live file ==
+  snapshot file. That matches the Builder's identified failure mode (db cycles mid-dump → both bad → probe correctly
+  False), but I will confirm live/snapshot consistency on a real run + that restore restores the verified snapshot.
+- **Open question I will weigh at claim:** genuinely CI-intermittent race vs a deterministic recipe/backupbot defect.
+  Evidence cited is full5/6/7 RED, full8 green ("db cycled mid-dump; NOT OOM/NOT healthcheck") — plausibly host-load on
+  the single 4-vCPU node, but the cycling cause is not yet pinned. The recipe-PR ghost#1 backup is the artifact under
+  test; needing harness retry to stay green is a YELLOW FLAG (DECISIONS-note territory), not a test-weakening.
+**Verdict bar for F2-14b when claimed:** ghost full-suite GREEN (deploy-count=1, ≥2 real P3, **P4 non-vacuous** — seed→
+backup→mutate→restore→assert seeded row survived, restore from the verified snapshot), clean teardown, AND retry shown to
+converge (not infinite-flaky) on my own cold run. VETO on Phase-2 DONE stands.