Version: 2026.9.1 (ad6fe23), macOS arm64, node 26.7.0

Config:

"session": { "reset": { "mode": "daily", "idleMinutes": 600, "atHour": 4 } }

Summary: Per dist/reset-policy-*.js, daily-mode staleness is staleDaily = sessionStartedAt < dailyResetAt, evaluated lazily — so a session started before the 4am boundary should reset on the FIRST inbound message after the boundary. Observed instead: three consecutive webchat (dashboard) messages after the boundary were handled normally in the stale session, and the reset then fired on the FOURTH message — mid-conversation from the user's perspective, discarding the context of the exchange that had just resumed.

Timeline (2026-09-06, Europe/Zurich; long-running dashboard session, last prior activity 2026-09-05 20:27):

• 10:58, 11:06, 11:10 — three user messages handled normally in the old session. All are past both the 4am daily boundary and the 10h idleMinutes threshold; per the policy source, every one of them should have been the reset trigger.
• 11:13:10.877 — transcript event {"type":"reset","reason":"daily"} written, 100ms before the user's fourth message is appended: that message triggered it.

Transcript excerpt (session store transcript_events):

seq 2018  2026-09-06T08:58:48Z  user      (handled in old session)
seq 2020  2026-09-06T09:06:10Z  user      (handled in old session)
seq 2022  2026-09-06T09:10:12Z  user      (handled in old session)
seq 2024  2026-09-06T09:13:10.877Z  {"type":"reset","reason":"daily",...}
seq 2025  2026-09-06T09:13:10.977Z  user

Expected: either the first post-boundary message resets the session (current policy semantics), or none of them do — resetting on the Nth message mid-conversation is the worst of both. It suggests some webchat dispatch path handles inbound messages without running the freshness evaluation (evaluateSessionFreshness / resolveSessionEntryResetFreshness), and a different path (hit on the fourth message) does run it. Repeated chat.startup calls from client reconnects were interleaved in the same window (11:03, 11:05, 11:08) if that helps narrow which path skips the check.