## 2026-10-10T07:52:30Z after the deploy
GET /health: 302
GET /system: 200 26979 bytes; MAIL-HOLD banner on the page: False
MAIL-HOLD marker in /data: absent
hub log MAIL-HOLD lines since start: 0
GET /healthz: 200
## live check of the hole (each request sends that household's CURRENT settings unchanged; the key is never printed)
control (own household): POST /api/v1/preferences customer_id=tester-1 with Tester 1's key -> 200 {"status":"ok"}
TEST (another household): POST /api/v1/preferences customer_id=demo-felhom with Tester 1's key -> 403 Forbidden: customer_id does not match the key
RESULT: PASS — another household's settings refused, own accepted
## the stored rows after (hub DB copy with -wal/-shm, read-only, shredded) — compared with the baseline taken before the deploy
demo-felhom row present sha256: 5ef8fc1ff15b
tester-1 row present sha256: 38de0bad97e1
demo-felhom UNCHANGED
tester-1 CHANGED
hub log for the two requests:
2026/10/10 09:52:48 [INFO] Notification preferences updated for tester-1: address set=true, events=[null]
## 2026-10-10T07:53:23Z CORRECTION: the control request stored tester-1's events as ["null"] (the baseline script misread the stored JSON null as a list holding the word null; no real event became enabled). Restored with the same own-household request carrying enabled_events: null
restore POST (own household) -> 200
demo-felhom row present sha256: 5ef8fc1ff15b
tester-1 row present sha256: 5583ffee1d37
demo-felhom UNCHANGED vs the pre-deploy baseline
tester-1 UNCHANGED vs the pre-deploy baseline
