速度

问题从哪来

重复任务一旦跨 IANA 时区、夏令时（DST） 或多种 cron 方言（Unix 5 段、Quartz 6 段、EventBridge），「本地挂钟几点跑」和「库里存什么时刻」很容易分叉：错过刻度、重复点火、月末 31 日静默、GitHub Actions 在负载下延迟 5–15 分钟却被当成硬 SLA。至少一次投递还要配上 幂等键、去重窗口 和明确的 重叠策略（skip / queue / concurrent），否则回填与重放只会放大脏数据。

技能如何工作

Tempo（速度）按 ANALYZE → MODEL → SPECIFY → VERIFY → HARDEN 推进：先读现有 cron、时区与重试代码，再在时间线上标出 DST、月底与业务日历边界，然后产出可粘贴的配置合同。交付物通常包括：带时区注释的 cron、显式 DST 策略（skip / defer / run-both）、重试上限与退避公式、幂等键公式、重叠行为、可观测目标，以及面向 GHA / EventBridge / K8s CronJob / Cloud Scheduler / Sidekiq / BullMQ / Celery / Temporal 等的片段。

子场景通过「配方」路由：cron、timezone、retry、backfill、calendar、deadline、window、idempotent 等；自然语言关键词也会映射到同一套流程。VERIFY 阶段会用 下几次点火模拟（含跨 DST）做数值健全性检查，边缘测试场景可交给 Voyager，错过运行与执行 SLO 可交给 Beacon。

边界与注意点

• 存储用 UTC（如 Postgres timestamptz），仅在展示层按用户时区渲染；不要用无 TZ 的 new Date() / datetime.now() 做面向用户的计划。
• 时区只用 IANA 名称（Asia/Tokyo），不用 JST/EST 等缩写；每个本地挂钟计划必须写明 DST 立场。
• 无时间焦点的通用编排走 Weave；纯 CI 管道设计走 Gear/Pipe；发布节奏走 Launch——Tempo 专注「时间与调度契约」。
• 设计前会先问：DST 策略、回填追赶深度、长任务重叠语义、至少一次 vs 精确一次等平台取舍。