Cron Add 加固与 Schema 对齐

背景

最近的 gateway 日志显示重复的 cron.add 失败，参数无效（缺少 sessionTarget、wakeMode、payload，以及格式错误的 schedule）。这表明至少有一个客户端（可能是 agent 工具调用路径）正在发送包装的或部分指定的作业负载。此外，TypeScript 中的 cron provider 枚举、gateway schema、CLI 标志和 UI 表单类型之间存在偏差，以及 cron.status 的 UI 不匹配（期望 jobCount，而 gateway 返回 jobs）。

目标

  • 通过规范化常见的包装器负载并推断缺少的 kind 字段来停止 cron.add INVALID_REQUEST 垃圾信息
  • 在 gateway schema、cron 类型、CLI 文档和 UI 表单之间对齐 cron provider 列表
  • 使 agent cron 工具 schema 明确，以便 LLM 生成正确的作业负载
  • 修复 Control UI cron status 作业计数显示
  • 添加测试以覆盖规范化和工具行为

非目标

  • 更改 cron 调度语义或作业执行行为
  • 添加新的 schedule kind 或 cron 表达式解析
  • 除了必要的字段修复之外，全面改革 cron 的 UI/UX

发现（当前差距）

  • Gateway 中的 CronPayloadSchema 排除了 signal + imessage，而 TS 类型包含它们
  • Control UI CronStatus 期望 jobCount，但 gateway 返回 jobs
  • Agent cron 工具 schema 允许任意作业对象，导致格式错误的输入
  • Gateway 严格验证 cron.add 而不进行规范化，因此包装的负载会失败

更改内容

  • cron.add 和 cron.update 现在规范化常见的包装器形状并推断缺少的 kind 字段
  • Agent cron 工具 schema 与 gateway schema 匹配，从而减少无效负载
  • Provider 枚举在 gateway、CLI、UI 和 macOS picker 之间对齐
  • Control UI 使用 gateway 的 jobs count 字段作为状态

当前行为

  • 规范化： 包装的 data/job 负载被解包；在安全的情况下推断 schedule.kind 和 payload.kind
  • 默认值： 当缺少时，为 wakeMode 和 sessionTarget 应用安全默认值
  • Provider： Discord/Slack/Signal/iMessage 现在在 CLI/UI 之间一致显示

有关规范化形状和示例，请参见 Cron 作业。

验证

  • 监视 gateway 日志以减少 cron.add INVALID_REQUEST 错误
  • 确认 Control UI cron status 在刷新后显示作业计数

可选的后续工作

  • 手动 Control UI 冒烟测试：为每个 provider 添加一个 cron 作业 + 验证状态作业计数

待解决的问题

  • cron.add 是否应该接受来自客户端的显式状态（当前被 schema 禁止）？
  • 我们是否应该允许 webchat 作为明确的交付 provider（当前在交付解析中被过滤）？
← 返回文档首页