Bind the policy to one operation
Record the full commit under review, source path, operation identity, retry trigger, attempt cap, delay rule, and named merge reviewer. A broad label such as network error is not enough: identify the result the code treats as retryable and the operation it may repeat.
RFC 9110 defines the Retry-After response field for certain follow-up requests and notes circumstances where a client might automatically retry after an incomplete response. It does not decide whether your operation is safe to repeat, which errors are retryable, or how your system should back off.
Exercise the terminal path
Use a synthetic or approved non-production fixture. Drive the specific failure condition until the policy reaches its terminal result. Record the operation identity, number of attempts, terminal status, visible recovery route, and whether a caller can tell that the operation did not complete. Do not turn an unknown outcome into a successful retry.
The included checker makes the review receipt inspectable:
node --test sites/odexing.com/evidence/P132/retry-policy-receipt.test.mjs
It does not make requests, prove idempotency, inspect a provider, or authorize a merge. It only rejects a receipt that is missing the review information.
Keep the rollback decision human-owned
Name who can reverse the reviewed revision and how they will verify the fixture after reversal. Stop if the operation can produce a duplicate effect, no one can name the cap or terminal state, or rollback has no accountable owner.
For another configuration-like boundary, see Gate an Agent-Generated Feature-Flag Change Before Merge. For a pipeline change, see Gate an Agent-Generated CI Workflow Change Before Merge.
Does a bounded retry count make the change safe?
No. A cap makes the behavior inspectable; it does not establish that the operation is repeatable, that its errors are classified correctly, or that a real environment will recover as expected.