gsxdsm 33a1a9df1e fix: drop false-positive committed_reservation_for_existing_id integrity check ...

The rule flagged every committed reservation pointing at an existing task ID
as an anomaly, but that's the happy-path steady state — reservations
transition to `committed` immediately after the task row is inserted, so a
committed reservation is always expected to reference an existing task. On
any node with task history, the dashboard banner fired with hundreds of
"affected" IDs and the store emitted a spurious `[task-id-integrity] anomaly
detected` error log.

Removes the rule, its type/label/reader, and updates tests (core regression
guard now asserts committed reservations don't trigger anomalies; dashboard
server-test fixtures use a still-valid anomaly kind).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-12 23:04:56 -07:00

3.7 KiB

Raw Blame History

View Raw