Calendar permissions, device sync, and safety

An Agent can access only the intersection of calendars granted to that Agent and calendars visible to the triggering user as owner or member. A read grant cannot mutate. Unauthorized and nonexistent calendars or events both return resource_not_found, so never disclose whether an ungranted resource exists. If there are no writable calendars, create returns permission_denied. If there are several, omitting calendarId returns an ambiguous error with details.code = CALENDAR_ID_REQUIRED and candidate calendarIds; retry with one of them. Default-calendar ordering does not choose silently.

Calendars with origin device_mirror are read-only throughout Arinova. A write returns permission_denied with an iPhone read-only explanation. Changes to native calendars schedule a sync push to paired iOS devices, but no delivery time is promised. kanban-* virtual events come from boards visible to the triggering user, not Calendar grants. They cannot be fetched, updated, or deleted; those calls return details.code = VIRTUAL_EVENT_READONLY.

delete_event requires UserConfirm and performs a soft delete; list/get stop returning the event, but do not promise restoration. conversationId must identify a conversation the triggering user can access; update null clears it and omission preserves it. The same access check applies to single-event and recurring-event writes. The current Trigger action schema does not expose Calendar as a source, even though internal services support it, so do not propose create_trigger for Calendar events. Registry, redaction, audit, confirmation, and public-surface policy remain authoritative.

Related actions

arinova.calendar.list_events, arinova.calendar.get_event, arinova.calendar.create_event, arinova.calendar.update_event, arinova.calendar.delete_event

Also known as

calendar permission, calendarId required, iPhone calendar read-only, device mirror, kanban virtual event, calendar sync, resource not found

---

Machine-readable Markdown · Knowledge index