日历
它到底能做什么
Push，带清理
新预约会在 Apple 日历里创建事件，取消则把它删掉。执业人员的日历不会比预约簿慢上一天。
忙碌时间也算数
任何入口——面板、AI、流程或挂件——给出时段之前，外部事件已经从可约时段里扣掉了。和私人安排撞车，同样会被拦下。
同步方向是个设置项
每个接入的来源你都可以单独选：只读、只写、双向，或只取忙碌时间——这样诊所的共享日历和私人日历可以扮演不同角色，互不打架。
技术细节
不会让你重复预订的同步语义
用 App 专用密码走 CalDAV
Apple 给第三方开的正式入口是 CalDAV：你在自己的 Apple ID 里生成一个 App 专用密码（真正的密码永远不会离开 Apple），事件则通过这个开放标准，对你的 iCloud 日历集合进行读写。
角色是三个维度，不是一个下拉框
每个来源你都单独设定三件事：它是否把预约导进来（从不、一次性导入，或持续导入）、预约是否镜像写到它那里、它的忙碌时间是否占用可约时段——诊所的共享日历和私人日历因此可以扮演完全不同的角色。
必要之处失败即关闭
只用来占用可约时段的日历，读取出错时失败即关闭——忙碌时间未知就拦下预约，而不是放任冲突发生。向台账供数的来源则失败即放行。这条线划错，是日历同步里代价最高的一个错误，所以它是规则，不是心情。
连接会自愈
出错的连接会被标记出来，并写明原因——下一次读取成功就自动解除。故障结束之后，不需要谁再来手动取消勾选。
事件载荷最小化
落到你日历里的只有预约类型的名称、客人的姓名和备注，以及起止时间——不发参与者邀请，不塞会议链接，不覆盖提醒设置。你的日历客户端自己管自己的提示。
冲突有明示的处理规则
等双向编辑上线时，每个来源都已经带好了冲突处理规则——挂起交给人处理（默认项，同时暂停提醒）、以我们这边为准，或以对方为准，落败的那个版本会保留并展示出来。在用得上之前就先说清楚，因为出事之后再补冲突规则，正是数据消失的经典方式。
接入设置
连接方式
接入 Apple 日历
用 Apple ID 里生成的 App 专用密码，通过 CalDAV 接入。
分配角色
只读、只写、双向，或只取忙碌时间——逐本日历分别设定。
随处都能预约
面板、AI、流程或网站挂件——每一个入口看到的都是同一份扣减后的可约时段。
安全与保证
无聊但管用的保证
权限范围最小化
这个连接只申请日历权限——不要邮件，不要联系人，不要云盘。token 加密存储，并自动刷新。
事件始终归你
读取忙碌时间只取时间，不取内容——算可约时段只需要知道你忙，不需要知道你在忙什么。
断开得干净
移除连接会立即停止同步；已经镜像到你日历里的事件仍然归你，留着还是清掉由你决定。
不加粉饰的细则
边界，写清楚
台账留在我们这边
无论接入哪些日历，预约台账始终是 ConnectWiz 自己的表——日历是镜像和数据来源，永远不是主数据。这是一个设计立场，我们把它写出来。
提醒由我们发，不靠日历
预约提醒由 ConnectWiz 发出——邮件，配置了就再加短信——而不是靠日历通知，这样从不打开日历邀请的客人也能收到。写出来，是因为两套提醒同时响比一套还糟。