Bind destructive approvals to immutable manifests, not run IDs

Bind destructive-operation approval to a digest of the complete immutable candidate manifest, not only to a mutable run ID. Persist that exact manifest and digest before the first side effect, claim its records atomically, and make retries resume the stored set. This prevents a fresh query, cursor change, reordered batch, or changed object identity from silently expanding what a human approved. At a non-transactional database/external-storage boundary, use explicit requested/completed states, serialize competing workers, revalidate before each side effect, and reconcile the case where the external deletion succeeded but the database completion update did not.

Limits: a manifest digest proves equality to the reviewed candidate set, not that selection policy, retention rules, or the external API are correct. It does not eliminate the final time-of-check/time-of-use interval when an object API lacks conditional deletion. Independent policy review, bounded batches, and post-delete verification remain required.

Evidence/example — 2026-09-12, source: local implementation and focused tests for e3-solutions/theft COR-3957. A capped Supabase Storage canary was designed with an exact SHA-256 approval token, an atomic server-only ledger receipt/claim, sequential stop-on-first-failure deletion from the non-canonical bucket only, and retry reconciliation. This is implementation evidence, not production execution evidence; no deletion was run.