Town 要替一群人改日程，判断顺序建议反过来：先确认谁有改期权限，再决定改不改。多人共享日历里，「被邀请」不等于「可写」——只读日历、他人委托的日历、会议室这类资源日历，通常只允许读取，Town 若直接写入，表现出来可能是静默失败、改动被回退，或者通知发给了不该知道的人。所以这类协调要先落到三件事：列出每个参与人日历的共享级别、明确改期前必须问谁、给自动协调留一条随时能接手的人工通道。
适用场景是多人共享日历下的改期协调。操作动作：先逐人核对日历共享级别，再把发起人、只读参与人和管理员填进确认名单，最后用一个只读事件验证 Town 是询问而不是执行。验证方式是看改期动作落在「执行、询问、拒绝」中的哪一种，以及通知最终发给了谁。风险边界：共享级别随时可能被日历所有者改动，权限清单需要定期复核；权限不明时宁可转人工，不要让自动改期继续往下走。
列出参与人日历的可见与可写范围
这一步只解决一个问题：确认 Town 能读取哪些日历、哪些只能看不能改。建议逐人记录日历共享级别，通常分三档：仅查看、可编辑、可管理，并把例外日历单独标出来。
- 仅查看：Town 能读到忙闲和时间标题，改期请求一般只能停在「发起询问」，不能直接写入。
- 可编辑：Town 可以向该日历写入新时间，但仍受事件本身的审批、锁定或重复规则限制。
- 可管理：可以改共享设置和权限，这一档建议只留给日历所有者本人和管理员，不要交给助理账号。
例外日历不要合并进主日历一起判断。常见的例外包括：个人日历与工作主日历权限不一致、从他人那里获得委托的共享日历、外部组织发来的邀请日历、以及会议室这类资源日历（多数只能预约不能改）。可以用一份可替换的配置骨架先记下来：
participants:
- name: 张工
calendar: 工作主日历
share_level: 可编辑
exception: 无
- name: 李工
calendar: 工作主日历
share_level: 仅查看
exception: 客户会议在独立委托日历，仅查看
- name: 会议室A
calendar: 资源日历
share_level: 可管理
exception: 改期需审批验证方式：用同一个账号在日历共享页面分别打开这些人的日历，看新建或修改入口是否可用；如果页面行为和清单不一致，以页面实际能做的操作为准。风险边界：共享级别是动态的，日历所有者收回委托后，原本「可编辑」会立刻变成只读。
在 Town 里设置改期前的确认对象
这一步是为了避免助理直接修改无权限、或需要发起人点头的日程。把需要确认的参与人、发起人或管理员填入确认名单，让 Town 在动日程前先问人。
操作路径通常是两步：先在日历共享页面（或管理后台的成员与日历页）核对每个人的共享级别；再到 Town 的助理设置页找到日程协调或改期相关项，把上述人员加入确认名单。不同版本入口名称可能不同，按「日历共享」和「助理设置」两个位置找即可，找不到就先别开自动改期。
reschedule_policy:
auto_execute_when:
- 全部参与人日历共享级别为「可编辑」
- 事件未标记为需审批
require_confirmation_from:
- 日程发起人
- 共享级别为「仅查看」的参与人
- 日历管理员
on_unknown_permission: 转人工验证方式：改完配置后，用一个只读日历的参与人发起一次改期请求，观察 Town 是否停下来发出询问，而不是直接改。风险边界：确认名单拉得太长，协调会退化成人工排队，通常只放真正需要点头的人就够。
用三个测试日程触发冲突与改期
权限清单是静态的，Town 的实际行为要靠事件本身来验证。建议创建三类互相冲突的测试事件，让改期请求必须发生，然后观察结果。
- 只读事件：邀请一位只有只读权限的参与人，时间与另一场会议重叠。预期是 Town 发出询问或直接拒绝，而不是静默改期。
- 可写事件：全部参与人均为可编辑且未被标记审批。预期是 Town 可以直接写入新时间并发出变更通知。
- 需审批事件：人为给事件加上审批或锁定标记。预期是改期被挂起，直到审批人回应。
观察时重点看三件事：改期动作是执行、询问还是拒绝；拒绝时有没有给出原因（权限不足、时间冲突、被锁定）；参与人是否收到了改动通知。如果只读事件被直接改掉，说明确认名单没生效，回到上一节检查配置。风险边界：测试事件也要邀请真实的日历所有者参与到权限判断里，但不要拿正在使用的生产会议做实验。
检查改期记录与通知去向
协调出问题时，最需要的是可追溯。建议按时间线把每一步列出来：Town 发起的询问对象与时间、收到的回复、最终改期结果、通知发给了哪些人。
- Town 检测到时间冲突，向确认名单中的人发起询问。
- 参与人回复同意、拒绝或提出新时间。
- Town 按回复结果执行改期，或在无权限时终止并记录原因。
- 变更通知发往事件参与人、发起人，以及需要旁听的管理员。
如果平台提供活动日志或助理运行记录，可以按事件 ID 过滤，逐条比对上面的时间线：
# 通用排查骨架，字段名按实际日志替换
grep 'event_id: <你的测试事件ID>' town-assistant.log | sort -k1,2
# 关注字段：action(ask/execute/reject)、target(日历所有者)、notify(收件人列表)验证方式：确认日志里的通知对象与确认名单一致，没有漏发给被改期的参与人，也没有把内部询问发给不相关的人。风险边界：日志保留周期有限，重要日程的协调记录建议另外留档，否则事后无法还原当时问过谁。
设计人工接管与回滚路径
权限不明或多人明确反对时，需要能立刻让自动协调停下来。这条路要提前写好，不要等出问题再翻设置页。
- 暂停自动改期：在助理设置页关闭日程协调的自动执行开关，或把对应参与人从自动执行范围移出，改为仅提问不执行。
- 恢复原时间：用被改动事件的原时间重新写入，或在日历历史与回收站中还原该事件，然后确认参与人日历都已同步。
- 转人工确认：把改期请求交给发起人或管理员，由人决定新时间，并明确告知哪些人需要回复。
- 复核权限：接管处理完后，重新走一遍第一、二节的清单和确认名单，找出是哪一步的权限判断出了偏差。
验证方式：暂停后重复一次只读事件的改期请求，确认 Town 不再自动写入；恢复原时间后检查各参与人日历显示一致。风险边界：暂停只影响后续动作，已经发出的询问和已经写进日历的改动需要人工收尾，回滚前最好先确认没有新的冲突时间被占用。