Cache purge is live. Storage lifecycle is next.

Four operations, four names

Operation	What it removes	Status
Front Door purge / invalidation	Cached responses for stable URLs on one approved hostname. It does not delete origin blobs.	Active after deploy: parallel durable sweep; current 200 bodies must match staged SHA-1, dropped durables must return 404, and fingerprints stay outside deploy purge and verification.
Durable origin removal	Unhashed pages and files that disappeared from the current project, including every blob beneath a removed virtual folder. It does not reclaim old fingerprints.	Live during deploy: queue before mutation, delete origin blobs, purge, then prove public 404.
Storage lifecycle cleanup	Old fingerprinted blobs from $web to control storage growth. It does not refresh Front Door.	Designed but not yet implemented.
Image derivative cleanup	Optimizer-owned local -optimized files superseded by a new format or size selection.	Live in this site's optional local image tool; unrelated to cloud retention.

How the future storage job identifies “old”

Each successful deploy writes state/version.txt beside the visitor-served public/ tree. It records an ISO 8601 UTC timestamp, the git SHA, and the same UTC YYYYMMDD date used in fingerprinted filenames. Call that date D. It is workflow state read directly from storage, not a public URL.

The storage lifecycle workflow described here is planned rather than active. Its design reads that marker directly from blob storage using workload identity, never through Front Door, because cached metadata must not decide what storage is allowed to delete.

1. Discover One job in the platform repository walks each $web/<PROJECT_ID>/<fqdn>/public/ subtree. No copied cron in tenant repos.
2. Prove current Missing or malformed state/version.txt aborts that hostname immediately. Ambiguity always means no deletion.
3. Protect state Never enter state/ for deletion and never touch state/to-purge-*. An unfinished purge queue is operational evidence, not expired content.
4. Protect today Never delete a fingerprint whose suffix date equals D, nor any live unhashed entry document under public/.
5. Delete deliberately Only fingerprints older than two weeks and not equal to D become candidates. Dry run is the default.

Deletion age and cache age answer different questions

Browsers cache fingerprinted assets for thirty days, while the proposed origin deletion threshold is two weeks. That is intentional rather than contradictory. A browser may continue using immutable bytes it already has after the origin copy is gone; newly revalidated HTML will only point at the current generation. Storage lifecycle cleanup controls retained origin bytes. max-age controls a visitor's local copy.

Two ways to run, neither silently destructive

How	Deletes?
Interactive workflow_dispatch	dry_run defaults to true. An operator must deliberately set it false to remove candidates.
Scheduled run	Uses the same identification logic, but stays a dry run unless AUTO_CLEANUP is explicitly true.

Blob modification time is not a safe proxy for “current,” and there is no cached public copy of version.txt to consult. The source of truth is state/version.txt in storage. A state/to-purge-YYYYMMDD.txt older than about 30 days should raise a warning; lifecycle cleanup must still leave it alone.

Current recovery window

Azure blob soft delete is already enabled account-wide for seven days. The Terraform target is fourteen days: after the future storage lifecycle job deletes a candidate, operators would have two more weeks to undelete it, though it would no longer be served. Soft delete applies to every blob deletion on the account, not just lifecycle cleanup.

Deploy-time Front Door purge and durable-path removal are active features. The storage lifecycle workflow remains planned, so old fingerprinted blobs accumulate. Follow the chain from live cache invalidation to filenames carrying their deploy date, or return to all posts.