PR #283 fixed the date computation and made the Settings toggle repair a
calendar when switched off or back on. Someone who subscribed months ago and
never touches the toggle still saw Boxing Day on Christmas Day.
A shared useHolidayRepair hook now runs once per launch on both shells, gated
on eventsReady so it sees the real calendar rather than the empty list that
exists before the first listEvents() resolves.
Two properties make it safe to run unattended:
- It only MOVES an event whose observed date the calendar has since corrected,
carrying the stored fields over so a reminder set on the holiday survives. It
never re-adds a merely-absent holiday, because the user may have deleted that
one deliberately and a launch-time pass would resurrect it every boot.
- Once the dates line up nothing is stray, so the plan comes back empty and
nothing is written. That is what lets both shells and every linked device run
it independently without fighting each other.
planHolidayRepair is pure so the decisions are testable without a UI. It keys
targets on the year the calendar was generated for rather than the year in the
date, since the two differ where an observed date crosses the year boundary.
Verified in the real mobile UI bundle, driven in a hidden Electron window
against a pre-fix Canada subscriber: Boxing Day moved 2026-12-25 to 2026-12-28
with its 60-minute reminder intact, Christmas Day untouched. Re-running against
the corrected data wrote nothing, and a calendar with Boxing Day deliberately
deleted stayed deleted.
Closes#150.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jmow72MHKMVCQCvybwhMJm
Your NameandClaude Opus 5
9efc908622