> 来源:`docs/PLATFORM_GAPS_FROM_TEMPLATES.md` 第 35 条(**P1**)。 ## 现象 平台没有「条件性计时器」原语。所有时间字段都是绝对时刻,**无法做「状态切换时暂停 / 恢复」**。 最痛的场景是 SLA: - 工单进入 `waiting_customer`(等客户回复),SLA 计时应**暂停** - 客户回复后状态回到 `in_progress`,SLA **继续累计** - 总耗时 = 真实处理时间,不该把「等客户」的时间算给坐席 今天的 `resolution_due_at` 是创建时按 SLA 策略加出来的绝对时刻,**整段全程跑表**。这导致: - 客户三天不回,工单 SLA 必然爆 → 业绩不公正 - KPI / 工资 / 升迁全错 - 客服管理者必须手动扣减 → 失去自动化意义 ## 复现 `helpdesk` 模板: ``` TIC-2026-006 创建于 2026-05-22,resolution_due_at = 2026-05-24 2026-05-22: status → waiting_customer 2026-05-26: 客户回复,status → in_progress 当前 SLA: 已逾期 2 天(不应) ``` ## 当前 workaround - 加 `paused_at` / `total_paused_minutes` 字段,写两个 flow 在状态切换时累加 —— 模板侧能写但易错、不能跨模板复用、UI 显示混乱 - 干脆放弃 SLA 提醒 —— 失去模板核心卖点 ## 建议范围 **M1:声明式 timer 字段** - spec 新字段类型 `timer`:`{ name, startsAt: cel, pauseWhen: cel, resumeWhen: cel, dueAfter: duration | cel }` - 系统层维护 `accumulated_duration` / `due_at`(动态计算) - 状态机切换时自动评估暂停 / 恢复 **M2:分级 SLA** - `sla_policy` 上能挂多个 timer:first_response_due / resolution_due - 业务对象引用 policy + 起步时刻 **M3:暂停审计** - 暂停 / 恢复记录入审计(依赖 #25 audit 表面化) - 可视化时间轴:每段「绿色 = 计时中 / 灰色 = 暂停」 **M4:通知集成** - 接近 due 时触发通知(依赖 #1) - 暂停期间不报警 ## 验收 - [ ] timer 字段类型 + 状态机暂停谓词 - [ ] `helpdesk` 模板:waiting_customer 暂停 SLA,回到 in_progress 恢复 - [ ] 缺陷库 gap #35 标记为已解决 ## 关联 - 依赖 #1 通知、#25 审计 - 配合 #7 CEL stdlib(写谓词需要时间函数)
现象
平台没有「条件性计时器」原语。所有时间字段都是绝对时刻,无法做「状态切换时暂停 / 恢复」。
最痛的场景是 SLA:
waiting_customer(等客户回复),SLA 计时应暂停in_progress,SLA 继续累计今天的
resolution_due_at是创建时按 SLA 策略加出来的绝对时刻,整段全程跑表。这导致:复现
helpdesk模板:当前 workaround
paused_at/total_paused_minutes字段,写两个 flow 在状态切换时累加 —— 模板侧能写但易错、不能跨模板复用、UI 显示混乱建议范围
M1:声明式 timer 字段
timer:{ name, startsAt: cel, pauseWhen: cel, resumeWhen: cel, dueAfter: duration | cel }accumulated_duration/due_at(动态计算)M2:分级 SLA
sla_policy上能挂多个 timer:first_response_due / resolution_dueM3:暂停审计
M4:通知集成
验收
helpdesk模板:waiting_customer 暂停 SLA,回到 in_progress 恢复关联