---
{
  "id": "platform.calendar.permissions-sync-and-safety",
  "topic": "calendar",
  "title": "行事曆權限、裝置同步與安全",
  "locale": "zh-TW",
  "version": "2026-08-12",
  "summary": "Calendar 存取是 Agent grant 與使用者可見範圍的交集，並要求明確選擇多行事曆及遵守鏡像唯讀保護。",
  "content": "Agent 可操作的範圍，是「Agent 已獲 grant」與「觸發使用者以 owner 或 member 身分可見」行事曆的交集；read grant 不能寫。未授權與不存在的行事曆／事件都回 `resource_not_found`，不可洩漏資源是否存在。沒有可寫行事曆時 create 回 `permission_denied`；有多個時，省略 `calendarId` 會回 ambiguous error，含 `details.code = CALENDAR_ID_REQUIRED` 與候選 `calendarIds`，應選一個重試。default 排序不代表可靜默代選。\n\norigin 為 `device_mirror` 的 iPhone 鏡像行事曆全面唯讀，寫入回 `permission_denied` 並明示 iPhone read-only。native 行事曆變更會安排推播到已配對 iOS 裝置，但不承諾時效。`kanban-*` 來源是觸發使用者可見的 boards，不是 Calendar grant；get/update/delete 都拒絕並回 `details.code = VIRTUAL_EVENT_READONLY`。\n\n`delete_event` 需要 UserConfirm 且是 soft delete；list/get 不再回傳，但不得承諾可復原。`conversationId` 必須指向觸發使用者有權存取的 conversation；update 傳 null 是清除、省略是保留。單一事件與週期事件寫入都套用相同存取檢查。目前 Trigger action schema 未公開 Calendar source，即使內部 service 已支援，也不得建議用 `create_trigger` 監聽事件。registry、redaction、audit、confirmation 與 public-surface 政策仍具最高優先。\n",
  "aliases": [
    "行事曆權限",
    "calendarId required",
    "iPhone 行事曆唯讀",
    "device mirror",
    "看板虛擬事件",
    "行事曆同步",
    "resource not found"
  ],
  "tags": [
    "calendar",
    "permissions",
    "safety"
  ],
  "relatedActions": [
    "arinova.calendar.list_events",
    "arinova.calendar.get_event",
    "arinova.calendar.create_event",
    "arinova.calendar.update_event",
    "arinova.calendar.delete_event"
  ],
  "relatedActionPrefixes": [],
  "url": "https://docs.arinova.ai/zh-tw/kb/calendar/permissions-sync-and-safety/"
}
---

Agent 可操作的範圍，是「Agent 已獲 grant」與「觸發使用者以 owner 或 member 身分可見」行事曆的交集；read grant 不能寫。未授權與不存在的行事曆／事件都回 `resource_not_found`，不可洩漏資源是否存在。沒有可寫行事曆時 create 回 `permission_denied`；有多個時，省略 `calendarId` 會回 ambiguous error，含 `details.code = CALENDAR_ID_REQUIRED` 與候選 `calendarIds`，應選一個重試。default 排序不代表可靜默代選。

origin 為 `device_mirror` 的 iPhone 鏡像行事曆全面唯讀，寫入回 `permission_denied` 並明示 iPhone read-only。native 行事曆變更會安排推播到已配對 iOS 裝置，但不承諾時效。`kanban-*` 來源是觸發使用者可見的 boards，不是 Calendar grant；get/update/delete 都拒絕並回 `details.code = VIRTUAL_EVENT_READONLY`。

`delete_event` 需要 UserConfirm 且是 soft delete；list/get 不再回傳，但不得承諾可復原。`conversationId` 必須指向觸發使用者有權存取的 conversation；update 傳 null 是清除、省略是保留。單一事件與週期事件寫入都套用相同存取檢查。目前 Trigger action schema 未公開 Calendar source，即使內部 service 已支援，也不得建議用 `create_trigger` 監聽事件。registry、redaction、audit、confirmation 與 public-surface 政策仍具最高優先。