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>
install:pass + deploy-count=1 + clean teardown (only 5 infra stacks remain, no orphans).
Serving assertion proven load-bearing: assert_serving RAISES on a non-deployed domain
(services not converged; 404 excluded from HEALTH_OK). Pure-generic confirmed (hedgedoc has
no cc-ci/repo-local tests). No VETO — Builder cleared past G0.
Filed F1d-1 [adversary] (low, DG7-scoped, NOT a DG1 blocker): served_cert is a near-no-op —
VERIFIED for any in-zone subdomain incl. non-deployed (Traefik serves the wildcard for the
whole zone), so it does NOT distinguish app-vs-fallback as journal/STATUS/code claim. Fix
wording/check before the DG7/G4 gate.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
