═ 为什么 ═
这两个按钮跳走之后客服基本不回来 —— 这正是 plan_executions 回写率只有 11%
(生产 65 个认领单只有 7 条结果)的根源。回写率低到这个程度,"成功率""退回率"
全是猜的。⇒ 把一次必答的极简输入挪到跳转之前:人还在 PAC 里、手还在键盘上,
那一刻才录得到。

═ 做了什么 ═
1) 吸附在按钮上的小浮层(Popover),各只收**一个必填**:
   · 预约 → 备注   → 落 success_appointed(结案 + 60 天抑制)
   · 跟进 → 下次时间 → 落 scheduled_next(不结案,snooze 到那天)
   多一个字段都不行 —— 这是拦在人和他真正想做的事之间的门,门越重越会被绕开。

2) scheduled_next 的 group: keep → close(「保持」→「成功」)。
   ⚠️ drivesStatus 保持 'keep' —— group 与状态机在这一项上**故意不一致**:
   算成功是统计口径,工单必须留着 snooze 到回访日。改成 completed 的话,
   客服刚答应患者"那天再联系您",这单当场出池,约好的回访再也不会发生。
   面板分组是读 meta 现算的 → 「保持」组自动只剩未接通/秒挂,历史数据一并重归类。

═ 几条纪律 ═
· **先落库、后跳转**。反过来的话写失败人已跳走,他会以为记过了。
· URL 未配置时**先拦住**,⛔ 不先把单结了再告诉他跳不过去。
· channel 记 'other',⛔ 不许默认 'phone' —— 我们不知道他怎么触达的,编一个会把
  触达方式分布做脏。
· 浮层里写明后果(「记为转化新预约并结案」)—— 不写就是让他在不知情下关掉工单。

实测(真库):跟进 → scheduled_next/other/2026-08-12 落库,plan 仍 assigned +
snoozed_until=回访日;预约 → success_appointed + 备注落库,plan → completed。
未配 URL 时确认不落库、浮层保持打开。新增 taxonomy 回归锁住 group/drivesStatus 分离。
1013 tests,两个 tsc + next build 干净。