Cadence（草稿）
状态：草稿，未定稿。 本文档是产品讨论阶段的设计草稿，用于收集反馈，不代表已排期或已对齐后端。落地前需要和 tasks-schema.md 的 owner 确认字段和事件模型。
一、定位
Cadence 不是 Task 的替代品，是 Task 数据的第二种视图。
现在 Tasks 页面（tasks-overview.md）是清单：按 Overdue / 优先级 / 截止时间排序的卡片列表。这个视图回答"接下来该做哪个"。
Cadence 回答另一个问题——"我今天一整天的时间是怎么被任务占满的"：一列代表一天，左侧是时:分刻度，有一条随当前时间移动的"现在"线，任务按 dueAt 摆在时间轴对应的位置上。延后一个任务，它在时间轴上的方块会挪到新的时间点，而不是从列表里消失又在某处重新出现。
两个视图共享同一份 tasks 数据，员工可以切换着用，不是两套系统。
二、复用已有能力，不新建数据模型
写这份草稿前翻了 tasks-schema.md 和 07-task-playbook.md，发现 Cadence 想要的东西，后端已经把数据模型铺好了大半，只是还没有对应的前端交互：
结论：Cadence 主要是一层新的前端交互，后端数据模型基本不用重新设计，除了下面这条快捷延后的新事件。
三、核心交互
3.1 时间线视图
一列 = 一天，左侧是小时:分钟刻度。任务按 dueAt 在对应时间点显示为一个方块，方块颜色跟 Tasks 列表现有的 priority（High / Medium / Low）保持一致的视觉语义，不额外发明新的颜色体系。
一条"现在"线随实际时间移动，直观显示"已经过去多少、还剩多少"。
没有设计的部分（需要在正式定稿前决定）：同一个 15 分钟格子里堆了多个任务怎么显示。清单视图不怕这个（往下排队就行），时间轴格子会挤。建议：超过一定数量（比如 3-4 个）自动折叠成一个"这个时段有 N 条"的堆叠块，点开再展开成小清单——但这只是本稿的建议，不是定论。
3.2 延后（复用 + 加快捷预设）
延后本质上就是写一条 task_progress_events，progressType = follow_up_scheduled，nextDueAt 设为新时间。这个机制已经存在，Cadence 要加的是操作层面的快捷预设按钮（比如 15 分钟 / 30 分钟 / 自定义），而不是每次都要打开一个日期时间选择器——目的是让"现在没空、待会再说"这个动作足够快，配合 Lead 场景下"响应速度直接决定转化率"的现实（tasks-overview.md §3.1 已经引用过延迟 5 分钟转化率下降 8 倍的结论）。
任务在时间轴上的方块跟着 dueAt/nextDueAt 一起挪到新位置，视觉上直接体现"延后"这个动作，不需要员工去别处确认。
3.3 打开任务 → 自动带出 Playbook（话术）
点开时间轴上的任务块，直接展示该任务当前的 task_playbooks.content（primaryAction.script / recommendedSteps / optionsYouCanOffer / avoid / closeGuidance），不需要员工切换页面查找。这一步是纯展示，不产生新的数据写入。
3.4 打开任务 → 自动带出最近通话记录
同一步操作里，带出该客户最近的通话记录（至少是通话摘要/结果，转录文本视§二里提到的存储位置确认结果决定展示深度）。目的是员工回拨前不用现问"上次聊到哪了"。
四、未决问题（标 DEFERRED）
- 共享队列 vs 按员工分配：现在
tasks表没有"预先指派给谁"这个字段，是所有员工共享同一份队列，谁有空谁处理。用户提到未来会给每个员工分配自己的号码——号码分配后，"这个任务该由谁处理"可能会有天然的归属（打进/打出这个号的任务归这个员工）。Cadence 的时间轴现在先按"店的共享时间轴"设计，员工号分配方案定下来后再决定要不要拆成"每个员工自己的时间轴"。恢复条件：员工专属号码功能排期后，重新评估这条。 - 提醒/唤醒机制不在本稿范围：之前讨论过的"打电话通知员工、按键确认/延后"这类主动提醒机制，属于另一个子系统（通知/唤醒），需要单独立项设计，不在 Cadence 这份视图层草稿里。Cadence 解决的是"打开系统之后看到什么、怎么操作"，不解决"怎么让员工想起来打开系统"。
- 同时段任务堆叠的显示方式：见 §3.1，本稿只给了一个建议方向，没有定稿。