Artifact Registry ADR 007: the serviceability predicate follows the lookup

What

The Serviceability predicates bullet classified every scheduled job as a subscription-lifecycle query, which excludes only deleted_at and purged_at. This narrows that parenthetical to billing, retention, and any scheduled lookup that only reads subscription state, and states that a background job which completes a write a client already asked for is a write-serving lookup requiring all five columns NULL. The same sentence says that a platform-driven write — reclamation, counter reconciliation, or a policy-driven deletion — is not classified by this bullet.

Why

The classification keyed on what schedules a lookup rather than on what the lookup does. A reap is a write. Under the previous reading, a scheduled job could delete rows in a namespace whose writes the request path refuses, so the same operation was permitted or refused according to who started it.

Merged code already follows the corrected reading. The bulk delete workers in internal/managementapi gate an accepted delete batch on the whole verdict, so the request that accepted the batch and the worker that finishes it cannot drift.

Why the rule is bounded to an accepted client write

docs/specs/S20-a-lifecycle-closed-beta.md derives it from "the same rule the bulk delete workers apply to an accepted delete batch", and the purger reaps a tombstone a user wrote. A wider rule reached background writers that consult no lifecycle column, including the buffered counter drain this same ADR describes, and it reached the retention and lifecycle policy runs that ADR-010's write-blocked row says continue. ADR-010 therefore needs no amendment, and the question of what governs a policy-driven reap stays where the S20-A plan puts it, with ADR-010's authors.

Consumer

S20-A's purger refuses to reap in a namespace that is not write-serviceable. See gitlab-org/ops/artifact-registry!1868 (merged).