[grove]

CI diagnosis — 2026-10-22

The original installed-function checks passed on candidate 2bbe746 and all other React CI passed, but pinned joint-stack run #39737469072 failed in the new heartbeat attribution heuristic: public cumulative processed_jobs moved from 2 to 4 across heartbeats only 0.123 seconds apart. That does not prove a single worker cycle processed two items. The worker can run/wake multiple times between polls, and the heartbeat is also updated twice within managed_cycle_m44; no per-cycle ID is exposed. It would be invalid to label any two status samples as one cycle based solely on a time threshold.

Commit 46b98a9 removes only that unsound temporal inference, not any receipt/no-replay/authorization assertion or installed claim-bound proof. It preserves exact observed counter intervals, requires their monotonicity, explicitly labels them not attributable to individual cycles, and retains deployed function hashes, batch_size → least(batch_limit, 100) → claim(max_items) proof and PR #20's actual one-item claim+pending-work test. Any future absolute per-cycle runtime measurement needs explicit cycle IDs/transaction instrumentation. This PR should not claim such a measured result.

Latest head is pending exact-head CI. Do not merge or mark ready until it passes.

Prove the deployed managed-cycle per-call claim bound

This dependent PR builds on React #14's feature branch after merged PR #20, which passed exact-head CI for the independent public pgreact.claim(max_items=1) boundary.

The deployed pgreact_internal.managed_cycle(integer) definition reads pg_react.batch_size and passes it as max_items to pgreact_api.claim. In contrast, an older GUC description incorrectly said batch_size applied only to maintenance. This patch corrects the GUC description and adds an executable installed SQL provenance check to the real two-case MDM outage audit.

Runtime assertions and evidence

• Read and hash pg_get_functiondef of the installed managed-cycle and public claim implementation, assert exact batch setting → claim argument, one increment per executed claim, max_items validation against operational max, and explicit exit at the requested item bound. The test uses installed functions, not a parser sketch or a guessed Rust API.
• Preserve genuine two-case MDM downtime across two due dates, pg_react.batch_size=1, both complete receipts, immutable source/work/request state, idle cycles and cold restart.
• Record managed heartbeat timestamps and cumulative processed counters at every observed backlog snapshot. Require nonnegative totals; for adjacent observed heartbeats within 1.5 seconds, require the processed counter to increase by no more than one. Retain snapshots with wider gaps as explicitly non-single-cycle observations rather than assuming an unobserved interval represented one cycle.
• Assert presence of deployed-function proof and configured one-item cap in the pinned-producer workflow. No production SQL, grants, binding/review semantics, release images or historical pins change.

Limits

This is exact-artifact per-call bound + focused real-worker corroboration, not a signed S1 300-case fair-backlog, 60/min throughput or full T49.12 proof. With sparse polling, gaps larger than the single-cycle observation window cannot be attributed to individual cycles; this test records them rather than inferring a guarantee. pgreact.claim additionally enforces operational max_claims, so oversized managed batch configuration needs separate behavior/review. Clone/restore, outage service limits, owner sign-off and other release gates stay open.

Remain draft pending complete current-head CI. Base is issue/11-explicit-escalation-time, not main; no release or production activation.