Compare commits

..

2 Commits

Author SHA1 Message Date
b3b8dc98af 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
2026-07-05 23:05:53 +02:00
f0a8162202 Merge pull request 'fix: fall back from invalid DAVE presence timezone' (#74) from codex/issue-73-presence-timezone-fallback into codex/production-intelligence-terminal
All checks were successful
Codex Template Compliance / template-compliance (push) Successful in 6s
Release Dry Run / release-dry-run (push) Successful in 16s
Build / test-and-image (push) Successful in 28s
2026-07-05 21:03:33 +00:00

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