alkstore/tasks/pg-decide-stamp-arithmetic-side.md

id, name, status, depends_on, scope, risk, impact, level, tags

id	name	status	depends_on	scope	risk	impact	level	tags
pg-decide-stamp-arithmetic-side	Decide which side guards pg's server-side stamp arithmetic (review 004 item 5, decision)	pending		narrow	low	component	implementation	review-004-fixes postgres-engine decision contract

Description

The decision that must precede the BIGINT-overflow fix, per docs/reviews/004-pre-release-general-review.md §"Findings recorded, not fixed" item 5: pg's claim, heartbeat, retry-reschedule, and retention-sweep statements compute server-side sums over consumer-supplied i64 values (queue.rs:386/912/1000/714, lock.rs:91) — one row stamped with visibility_timeout_s = i64::MAX (or retention i64::MIN) makes every claim/heartbeat UPDATE fail with "bigint out of range", and the failure is sticky per row. The client-side resolution is saturated (resolution.rs); the row-stamp arithmetic is not.

Decide which side owns the guard:

• (a) Clamp/validate at the enqueue seam — consumer i64s bounded at entry, matching resolution.rs's client-side saturation posture and the sibling engines' stamp arithmetic (sqlite/mem saturate per review 004 inline fix 6 — the engine-uniformity argument).
• (b) LEAST/GREATEST-guard the server expressions — defense at the arithmetic site; no entry-point change, but the stored stamps are silently clamped server-side.

Contract-adjacent — this is why it's its own task. The choice changes which failures are reachable through the public surface, which touches ADR-023 §2's totality wording. Check the window state first: as of the decomposition (2026-10-11) no publish tag exists, so the class-1 window is presumed open — verify, and if open, land the decision with a dated ADR-023 §2-style annotation (the failure-set change is class-1-legal pre-publish, the review-004 inline fix 5 precedent). If the window has closed, raise with the user before pinning anything.

The decision must name the guard form precisely: the clamp domain, which sites it applies to (enqueue vs the stamp sites), and what the observable behavior of an extreme-stamped row becomes.

Acceptance Criteria

• The decision of record: which side owns the guard, with the ADR-023 §2 totality argument and the sibling-engine uniformity check written down
• The window state verified and recorded; a dated annotation landed if class-1, or user sign-off if post-publish
• The guard form is precise (clamp domain, sites, the extreme-stamped row's observable semantics) — enough for pg-fix-bigint-stamp-overflow to implement without re-deciding
• The decision recorded where the family keeps such records (ADR annotation / task Notes + contract text if the wording needs it)

References

• docs/reviews/004-pre-release-general-review.md §"Findings recorded, not fixed" item 5 (the finding, the which-side question, the contract-adjacency)
• docs/architecture/decisions/023-fourth-review-round.md §2 (the totality wording the choice touches)
• alkstore-postgres/src/resolution.rs (the client-side saturation posture), queue.rs / lock.rs (the stamp sites)

Notes

To be filled by implementation agent

Summary

To be filled on completion