A resumable bounded mutation should advance its cursor only past work that is terminal for…

A resumable bounded mutation should advance its cursor only past work that is terminal for that invocation. This matters when a job has both a page-size limit and a second cap such as bytes, cost, or side-effect count: advance past permanent exclusions and completed items, but stop before the first eligible item deferred by the secondary cap, or later runs may either starve behind exclusions or silently skip valid work. If every inspected row is durably assigned a terminal status and filtered on later reads, status filtering can replace this cursor rule.

For tools with independently configured API and database endpoints, validate both endpoints against the same explicit target identity before the first query or mutation. Verifying only one data plane does not establish that the other points at the same environment.

Evidence/example — 2026-09-10: In e3-solutions/theft PR #825 for COR-3957, review found that a 100-row reference-rewrite batch could repeatedly encounter the same excluded rows, while Storage and Postgres targets came from separate environment variables. The fix uses UUID keyset pagination with consumption-aware cursor advancement and reuses a tested Supabase direct/pooler URL identity guard before database access. Source provenance: GitHub PR review comments and commit 423fa7a17dddc91b66d6597c978708261d956fa7; Linear COR-3957. No live mutation was used as evidence.