feat(frontdoor): instant rollback — re-point to a prior release's immutable image

[mdheller]

What

Completes the Vercel/Heroku deploy ergonomic trio: push → preview → promote → **rollback**. Rollback was only implied by the promotion gate; this makes it real — and better than a plain PaaS's, because of a property the stack already guarantees:

every deploy is a content-addressed, immutable image (a data sphere).

So a release is a sealed record binding (tenant, app, branch, image_digest, workload), and rolling back is re-pointing to a prior release's already-built digest.

rollback(app)  ──▶ find a PRIOR release that ran          ← target never ran here ⇒ BLOCKED, nothing served
               ──▶ re-point to its immutable image_digest  ← NO REBUILD (instant), reproducible bits
               ──▶ record a new head release (kind=rollback, from→to)   ← itself auditable
               ──▶ a SEALED decision

Why it's better than a plain PaaS rollback

• Reproducible, not "rebuild-and-hope." The digest is the guarantee — you get back exactly the bytes that ran, not a fresh build of an old ref.
• Fail-closed. You can only roll back to a release that actually ran here; an image that was never built+deployed is never served. Rolling forward to a new version still goes through the promotion gate — rollback to a known-prior-good release is the fast, sealed, audited escape hatch.
• Every rollback is itself an auditable head release (links from→to), so you can roll again either way.

Design

• tools/release_ledger.py — pure, file-backed core (make_release / history / current / rollback) + a real CLI (history|current|rollback <tenant> <app> [--to-digest D | --steps N]).
• History filenames carry a monotonic sequence so ordering is deterministic regardless of clock resolution (two releases in the same microsecond must not sort by their hash-based id).
• push_webhook.handle_push now records a release on every successful deploy (optional ledger_dir; the HTTP receiver passes artifacts/releases) — real pushes accrue the history rollback operates on. Failed builds are not releases.

Wired in

• capd/instant-rollback.mesh.capd.json (caps.dev.instant-rollback, composes_with git-push-deploy + git-push-webhook)
• validate.py, Makefile rollback, docs/BUILD_DEPLOY.md (documents the full trio)

Tests

+12 (10 ledger + 2 webhook-integration) = 209 tools tests green. 1-step rollback re-points with no rebuild; rollback to a specific prior digest; rollback to a never-built image blocked (fail-closed, current unchanged); no-history blocked; rollback-to-current no-op; rollback is a new linked head; only successful deploys become releases; records sealed.

🤖 Generated with Claude Code