review(2): F2-14b ghost PASS @22:42Z (COLD, my run /root/adv-ghost-f214b.log) — full lifecycle green incl upgrade-to-latest 1.1.1+6→1.3.0+6.21.2, P4 non-vacuous (drop→restore→ci_marker survives), probe DISCRIMINATES (both values first-hand), clean teardown 0/0/0, overlay grace-only. Closes ghost VETO portion; VETO on DONE STILL STANDS (discourse+mumble open)

machine-docs/REVIEW-2.md

@@ -2357,3 +2357,50 @@ the `except Exception: return False` would swallow ANY exec error into a permane
 backup 3x and proceeds, leaving the green to restore-race luck (the exact thing this fix claims to remove). At verdict I
 require the run log to show the probe DISCRIMINATING — either backup-verify passing on first attempt (no "FAILED" line) or
 a FAILED→re-run→pass sequence — NOT "backup-verify FAILED 3x" every run followed by a lucky-green restore. VETO stands.
+
+## F2-14b ghost — PASS @2026-05-30T22:42Z (COLD, first-hand, my clone /root/adv-verify @be0475a; log /root/adv-ghost-f214b.log)
+Cold-verified the Builder's claim `be0475a` (## Gate F2-14b): ghost full lifecycle GREEN incl upgrade-to-latest with
+reliable P4 backup-integrity via the `BACKUP_VERIFY` harness hook + retry. Re-ran the EXACT claimed command from a fresh
+clone reset to the claimed code: `RECIPE=ghost REF=ae43ffe34089cb466d00168a3ad71b813f70103f PR=1
+SRC=recipe-maintainers/ghost cc-ci-run runner/run_recipe_ci.py`. Ran CONCURRENTLY with the Builder's discourse run
+(node load avg peaked ~17 on 4 cores) — the heaviest realistic stress for the load-induced race, and it still passed.
+
+**My run — RUN SUMMARY: deploy-count = 1; install/upgrade/backup/restore/custom ALL pass.** No FAILED/ERROR/Traceback.
+- **Upgrade-to-latest is real & state-preserving:** log `upgrade→PR-head: head_ref=ae43ffe3 ... 1.1.1+6-alpine→
+  1.3.0+6.21.2-alpine`; `test_upgrade::test_upgrade_preserves_state PASSED` (marker 'upgrade-survives' rides the bump).
+- **P3 ≥2 real functional (all PASSED):** `test_post_roundtrip::test_create_post_roundtrip` (admin auth → create post via
+  Admin API → read back, title+html asserted), `test_content_api::test_content_api_settings_endpoint`,
+  `test_admin_redirect::test_ghost_admin_route_is_wired` (+ health_check). Characteristic behaviour, not status==200.
+- **P4 NON-VACUOUS — verified from CODE + reproduced first-hand:** ops.pre_backup seeds ci_marker='original' (asserts
+  commit); ops.pre_restore **DROPs the ci_marker table and asserts the drop took** (information_schema lists 0); after
+  restore `test_restore::test_restore_returns_state` requires `SELECT v FROM ci_marker == 'original'`. Since the table is
+  PROVABLY dropped pre-restore, the only path to green is genuine reimport from the restored snapshot — missing table →
+  exec RuntimeError → RED; empty/wrong value → assert RED. No false-pass path. **PASSED in my own run.** (Was RED in
+  full5/6/7 pre-fix.) `test_backup::test_backup_captures_state PASSED`.
+- **BACKUP_VERIFY probe DISCRIMINATES (my @68b2ddd non-vacuity bar) — both values observed FIRST-HAND:** (a) Builder
+  full10 log `/root/ccci-ghost-full10.log` line 59: probe returned False on a genuinely-incomplete backup → harness
+  re-ran `abra app backup create` → backup tier PASS (no "still FAILED after 3" line ⇒ attempt-2 probe True). (b) MY run:
+  probe returned True first try (clean capture, no "backup-verify FAILED" line) → backup tier PASS, no retry. So the
+  probe is neither always-True (full10 proves False on bad data) nor always-False (my run proves True on good data) — it
+  is a genuine read-only `gzip -t && wc -c>0` discriminator. Retry caps at 3 then PROCEEDS (doesn't swallow a persistent
+  failure: restore's assertion stays the real gate), so it converges and weakens no assertion.
+- **Clean teardown:** post-run node residue check — 0 ghost stacks / services / volumes / secrets. (0/0/0)
+- **Overlay `tests/ghost/compose.ccci.yml` minimal/justified/grace-only (VETO item 1):** overrides ONLY app+db
+  `healthcheck.start_period: 15m` (deep-merge, all other hc fields preserved). Justified by the abra
+  pre-substitution-duration-validation limitation I independently reproduced (`4b862f6`) + the base (1.1.1+6) shipping
+  1m grace → swarm-kill mid fresh-DB-migration/mysql-init → migrations_lock / corrupt-InnoDB deadlock. Grace-only (a
+  healthy check marks healthy at once → weakens no test; TIMEOUT=2400 bounds a genuine failure ~40min, not a blackout),
+  idempotent on the head (head ships literal 15m). The db grace targets FIRST-BOOT init, NOT the backup-time cycle race
+  (that's BACKUP_VERIFY) — no masking overlap. Recipe-PR head ae43ffe is the upgrade target → cc-ci-green via real run
+  (recipe-PR rule satisfied).
+- **No secret leak:** run log scanned — 0 password/secret/token values (MYSQL_PWD reads `/run/secrets/db_password` from
+  file, never echoes it).
+
+**Verdict: F2-14b PASS.** Closes the GHOST portion of the standing DONE VETO checklist (@16:22:07Z): ghost passes the full
+suite incl upgrade-to-latest, P4 non-vacuous, overlay justified, clean teardown. Isolation: verdict formed from the phase
+plan + code + the Builder's STATUS verification info + my own cold re-run (and first-hand reading of the full10 run LOG as
+observable evidence); I did NOT read JOURNAL.md before this verdict.
+
+**VETO on Phase-2 DONE STILL STANDS.** Remaining VETO-checklist items NOT yet cleared: discourse Q4.6 (upgrade-to-latest
+green — Builder running it now) and mumble F2-14c (upgrades to latest + voice on latest; old-base cc-ci host-ports copy
+removed; any surviving mumble overlay minimal/justified). DONE flip remains forbidden until I cold-verify those.