把三方会议从本周挪到下周，容易出错的环节不是找新时间，而是让改期绕过了发起人确认。Town 这类日程代理通常把“提议改期”当成普通事件处理，如果策略里没有把发起人回复设为硬性前置，超时逻辑就可能把新时间直接锁定，参会人按旧时间等到现场才发现会已经挪走。可行做法是先把角色和确认节点显式写进策略，再分别验证“发起人不回复”和“参会人反对”两种情形，最后确认日志能还原改期卡在哪一步。

判断：三方会议改期应把发起人确认设为不可跳过的前置条件，非发起人的同意只作参考。操作动作是把提议、发起人确认、参会人回复、最终锁定拆成四个节点，各自写明进入与退出条件；验证方式是用测试日程跑发起人静默和两名参会人反对两种场景，看日志停在哪个节点。边界：超时长度和自动化开关取决于 Town 的配置项与权限模型，需要结合你的环境确认，未验证前不建议开启自动锁定。

列出三方会议里的决策角色

先分清谁有确认权，再谈自动改期。把角色写进日历事件字段或策略文件（例如每人带一个 role: organizer / required / optional），后续节点的判断都读这个字段，而不是读“谁先回复”。

• 发起人：唯一可以提议改期并最终确认新时间的人。确认包含两层，接受新时段，以及同意覆盖原时间。可以用代理规则指定后备确认人，但要写清代理只在发起人超时后才生效。
• 必选参会人：可以提议改期，必须回复新时间是否可行，但回复本身不构成锁定条件。若必选参会人之间无共同可行时段，应回到发起人重新挑选，而不是由系统挑一个勉强的时间。
• 旁听者或可选参会人：只需知会，不阻塞流程。把可选参会人当成确认方，改期会被无关回复一直拖住。

标出改期链路中的确认节点

让 Town 在发出新时间之前必须停在确认点，四个节点的进入与退出条件建议这样定义。

1. 提议：进入条件是发起人或必选参会人提出新时间；退出条件是生成候选时段并记录提议人身份。
2. 发起人确认：进入条件是候选时段已生成；退出条件是发起人明确回复接受，超时只能进入等待或提醒状态，不能进入锁定。
3. 参会人回复：进入条件是发起人已确认；退出条件是所有必选参会人都给出可行或不可行，旁听者不参与这一步。
4. 最终锁定：进入条件是发起人确认且必选参会人无冲突；退出条件是日历事件时间已改写并向所有相关人发出变更通知。

把上面的语义落成配置骨架，字段名按你的实际配置替换，重点是 auto_lock_without_organizer 保持关闭。

reschedule_policy:
  propose_by: [organizer, required_attendee]
  confirm_by: [organizer]
  blocking_reply_by: [required_attendee]
  notify_only: [optional, room_resource]
  timeouts:
    organizer_no_reply: hold        # 只允许 hold 或 remind
    required_no_reply: remind
    auto_lock_without_organizer: false

验证方式：在测试空间加载这份策略，改一次会议，检查日志里是否按顺序出现 propose、await_organizer、collect_replies、lock 四个节点标记。节点缺失或顺序颠倒，说明策略没有被真正读取。

模拟发起人未回复的情况

新建一个三方测试日程，发起人账号不做任何操作，只让两名必选参会人在界面里点同意。这时要观察 Town 的状态，而不是只看邮件有没有发出去。

• 等待：状态停在等待发起人确认，原时间不变，参会人没有收到“已改期”通知。这是期望行为。
• 询问：Town 向发起人发一次提醒，同时原时间继续有效，提醒次数有上限，不能变成反复骚扰。
• 放弃：超时后关闭这次改期请求并告知提议人，原日程仍然保留。放弃不等于取消会议，这两件事在通知文案里要分开。

日志核对可以先用一条粗筛命令，路径和字段名换成你自己的：

grep -E "reschedule|await_organizer|auto_lock|expire" /var/log/town/agent.log | tail -50

如果输出里出现 auto_lock，且提议人不是发起人，说明策略没生效，应先把自动锁定关掉、回到人工确认，再继续测试。

模拟两名参会人反对新时间

让发起人先确认一个候选时间，再让两名必选参会人分别回复不可行，理由可以不同，例如时区冲突或已有安排。

• 记录反对意见：把反对人、回复时间、理由写进改期记录，后续协调和人工接管都读这份记录，不要只留在聊天里。
• 恢复原日程：只要存在未解决的必选参会人反对，就不改写日历事件时间；如果新时间已被写入，触发回滚，把时间改回原时段并重新发出变更通知。
• 再次协调的触发条件：反对人数降到可接受范围，或出现了所有必选参会人都标记可行的新候选时段。两个条件都不满足时，把请求交回发起人决定，而不是继续试探新时间。

需要留意的边界：回滚通常只恢复时间字段，不会自动撤回已经发出的提醒，所以通知模板里要写明以最新日历事件为准。

输出人工接管时需要的上下文

接手人需要一眼看出卡在哪一步，下面这份摘要可以直接作为交接模板，字段来自前面的改期记录和日志。

会议：三方评审（发起人 + 2 名必选参会人）
当前时间：周二 14:00–14:30（原时间，未被改写）
改期目标：下周内
确认状态：发起人未回复；参会人 A 可行；参会人 B 反对（理由：时区冲突）
未回复人员：发起人（已提醒 1 次）
候选时间：周四 10:00、周五 15:00（均各有 1 人标记冲突）
卡点：停在等待发起人确认，未进入锁定
建议下一步：由接手人向发起人确认是否接受周四 10:00，或把会议调整为两人会议

交接时一并给出策略文件路径、改期请求 ID 和对应日志时间段，接手人才能复现状态而不是凭对话推测。