Release v0.1.5

README.md

@@ -33,7 +33,26 @@ The first backend implementation stores VEVENT data in two layers:
 - normalized fields for API range queries and calendar rendering
 - raw iCalendar property records and generated `text/calendar` output so unsupported VEVENT properties and parameters can round-trip
 
-This is intentionally not yet a network CalDAV server. CalDAV protocol sync, external ETags, REPORT handling, scheduling inbox/outbox behavior, and full recurrence expansion are calendar-owned follow-up work.
+CalDAV sync is implemented as a calendar-owned backend primitive. A CalDAV source
+records the remote collection URL, sync token, ETag/ctag state, username,
+credential reference, sync interval, sync direction, and conflict policy.
+Credentials can be supplied transiently for manual sync, referenced from
+environment variables with `env:NAME`, stored through a platform secret provider
+when one is available, or stored as encrypted calendar-owned credentials.
+
+Inbound sync uses CalDAV `calendar-query` for full sync and `sync-collection`
+when a sync token exists. It imports all VEVENT components in a resource and
+soft-deletes local events when remote resources disappear. Two-way sources also
+write local creates, updates, and deletes back with CalDAV `PUT`/`DELETE` and
+ETag preconditions. If a remote resource changed, the local mutation is rejected
+and the user must sync before retrying. A calendar-owned task,
+`govoplan_calendar.sync_due_caldav_sources`, can run due sources in a worker or
+cron-style scheduler.
+
+This is not yet a full CalDAV network server. Scheduling inbox/outbox behavior,
+CalDAV server endpoints, UI credential management, and full user-facing
+recurrence editing remain follow-up work. The backend now includes a free/busy
+API primitive for scheduling and appointment modules.
 
 ## Development