docs: record presence timezone fallback
All checks were successful
Codex Template Compliance / template-compliance (pull_request) Successful in 8s
Build / test-and-image (pull_request) Successful in 26s

This commit is contained in:
2026-07-05 23:05:53 +02:00
parent f0a8162202
commit b3b8dc98af

View File

@@ -14,6 +14,8 @@ Last updated: 2026-07-05
- PR runs 915-916 and production runs 917-919 passed, including unit tests, Compose validation, Docker build/publish, release dry-run, and template compliance.
- Dockge was updated from the Gitea Registry and explicitly configured with `DAVE_PRESENCE_ENABLED=true`, max 4 messages/day, 75-minute minimum gap, randomized 45-180 minute evaluation bounds, 60-minute post-interaction idle delay, and a 5-minute timer resolution.
- Live `/api/health` reported `davePresence.enabled=true`, `running=true`, `dynamic=true`, `sentToday=0`, a variable `nextEvaluationAt`, the existing encrypted profile preserved, and no sweep error. The container reported `running/healthy`.
- Live verification then exposed issue #73: an invalid optional profile timezone caused `lastReason=invalid_timezone`. PR #74 fixed runtime resolution to fall back to `DAVE_PRESENCE_TIMEZONE` without logging or modifying encrypted profile data. Merge commit: `f0a8162202bfe0a0a8ed2a00dc4f0f7092677eea`.
- PR runs 925-926 and production runs 927-929 passed. After redeployment and the startup timer, live health reported `lastReason=not_due` instead of `invalid_timezone`, with dynamic presence running, the profile preserved, the container healthy, and no sweep error.
## Latest Completed Work