Changelog

The intent prompt had no examples or guidance for calendar.list_events,

so the LLM didn't know how to resolve colloquial time expressions like

"this week" or "coming up this month" into proper date ranges.

• Add date range resolution section to Large tier with two categories:

strict period queries ("this week" = Mon–Sun) and forward-looking

queries ("coming up" = NOW + 30 day lookahead, no period clipping)

• Forward-looking language ("coming up", "upcoming", "do I have any")

starts from NOW and uses 30-day window — doesn't clip to month/week

boundaries so results naturally span across periods

• Add calendar.list_events examples to all 3 tiers showing "what's on

my calendar this week" and "any lunches coming up this month" (with

search_query slot and 30-day end_date)

• Include current time (HH:mm) in date context line so the LLM can set

start_date to NOW for forward-looking queries

• Add helper methods: ThisWeekStart, ThisWeekEnd, ThisMonthStart,

ThisMonthEnd, NowTimestamp, Lookahead30

The intent prompt had no examples or guidance for calendar.list_events,

so the LLM didn't know how to resolve colloquial time expressions like

"this week" or "coming up this month" into proper date ranges.

• Add date range resolution section to Large tier with concrete examples:

"this week" → Monday–Sunday, "this month" → 1st–last day, "coming up"

→ start from NOW (current time) to exclude past events

• Add calendar.list_events examples to all 3 tiers (Small, Medium, Large)

showing "what's on my calendar this week" and "any lunches coming up

this month" (with search_query slot)

• Include current time (HH:mm) in date context line so the LLM can set

start_date to NOW for forward-looking queries

• Add helper methods: ThisWeekStart, ThisWeekEnd, ThisMonthStart,

ThisMonthEnd, NowTimestamp for generating example date boundaries

After 2 consecutive network failures (timeout, HTTP error, DNS

failure), the auto-update timer skips further checks instead of

burning 15 seconds on a doomed request each cycle. The counter

resets automatically when the API responds successfully.

Manual "Check for updates" always resets the backoff and fires

regardless, so the user can always retry.

When the cloud is offline (or the API is unreachable), the auto-update

timer fires repeatedly and logs a full ERROR stack trace for each

15-second timeout. These are expected connectivity failures, not bugs.

Split the catch block: HttpRequestException, TaskCanceledException,

and TimeoutException now log a one-line WARNING without the stack

trace. Actual unexpected errors (e.g., JSON parse, null ref) still

log at ERROR level and fire the UpdateError event.