register_callback/cancel_callback 落地：到点提醒工具 + 待定提醒渲染

## Parent #62 [PRD] arise register_callback（用户设到点提醒）落地 ## What to build 让用户可以直接跟机器人说"半小时后提醒我关火"这类带具体触发时间的请求，机器人到点后会主动用平时的语气提醒——复用 issue #52/#53-#56 已建好的 Callback 通用送回抽象，新增第二个触发源（`trigger_source="user_reminder"`），验证这条管线是否真的不需要为新生产者改动既有代码。 ## Acceptance criteria - [ ] 新增 core 原生工具 `register_callback(content, fire_at)`（同 `delegate_task`/`note_pending_intent` 先例，不经工具港，不新增能力位）：`fire_at` 由模型自己基于当前消息真实时间戳推算得出的 ISO8601 时间字符串；解析失败或早于/等于当前时间——fail-closed 拒绝，返回可读错误交给模型组织语言告知用户，不静默创建一条永远不会触发的记录 - [ ] 新增 core 原生工具 `cancel_callback(callback_id)`：找不到匹配记录（id 不存在，或存在但不属于 `user_reminder` 来源）——fail-closed 无操作，不报错阻断对话；只会撤销匹配来源/id 的那一条，不会误伤深挖任务委托（`task_completion` 来源）正在待送回的记录 - [ ] 两个工具恒可见，不受渐进解锁门控，加入既有 `RUN_LIMIT_EXEMPT_TOOL_NAMES` - [ ] 新增静态 config 项限制单 chat 同时存在的 `user_reminder` 待定记录数上限（同 `MAX_SENDS_PER_TURN` 等既有静态 config 层惯例）；超限时 `register_callback` 返回错误提示，不静默丢弃/覆盖最旧的一条 - [ ] 新增一个纯函数，把当前 chat 待定的 `user_reminder` 记录（含 `callback_id`/内容摘要/`fire_at`）渲染进冻结快照第七段（仅存在待定记录时产出内容），供模型跨轮次引用 `callback_id` 来取消；`task_completion` 来源的记录不参与这段渲染 - [ ] `CallbackRecord`/`CallbackStoragePort`/`is_due`/`render_callback_directive`/`_callback_scan`/`_deliver_callback`/`RuntimeLoop.run_callback()` 零改动——有一条集成测试直接证明：一条 `register_callback` 登记的记录能被这些既有模块不加任何改动地正确送回 - [ ] 到点后送回内容经完整六段冻结快照组装，用模型平时语气自然说出来，不是照本宣科念一遍用户原话 - [ ] 崩溃恢复语义：进程重启后待定 `user_reminder` 记录原样还在，照常到点触发（验证 Callback 持久化不变量对新生产者同样成立） - [ ] `register_callback`/`cancel_callback` 直接喂 `RuntimeLoop.run()` 脚本化对话断言效果（登记成功返回 id、超限拒绝、取消成功、取消不存在的 id fail-closed、跨 chat 隔离），仿现有 `delegate_task`/`cancel_delegate_task` 工具测试模式 - [ ] 取消隔离测试：构造同一 chat 下 `user_reminder` 和 `task_completion` 两种来源记录同时存在的场景，断言 `cancel_callback` 只撤销 `user_reminder` 来源的那一条 ## Blocked by None — can start immediately（issue #52/#53 的 Callback 抽象已合并完成）

KumaAgent commented

2026-07-24 09:15:41 +00:00

Member

Parent

#62 [PRD] arise register_callback（用户设到点提醒）落地

What to build

让用户可以直接跟机器人说"半小时后提醒我关火"这类带具体触发时间的请求，机器人到点后会主动用平时的语气提醒——复用 issue #52/#53-#56 已建好的 Callback 通用送回抽象，新增第二个触发源（trigger_source="user_reminder"），验证这条管线是否真的不需要为新生产者改动既有代码。

Acceptance criteria

新增 core 原生工具 register_callback(content, fire_at)（同 delegate_task/note_pending_intent 先例，不经工具港，不新增能力位）：fire_at 由模型自己基于当前消息真实时间戳推算得出的 ISO8601 时间字符串；解析失败或早于/等于当前时间——fail-closed 拒绝，返回可读错误交给模型组织语言告知用户，不静默创建一条永远不会触发的记录
新增 core 原生工具 cancel_callback(callback_id)：找不到匹配记录（id 不存在，或存在但不属于 user_reminder 来源）——fail-closed 无操作，不报错阻断对话；只会撤销匹配来源/id 的那一条，不会误伤深挖任务委托（task_completion 来源）正在待送回的记录
两个工具恒可见，不受渐进解锁门控，加入既有 RUN_LIMIT_EXEMPT_TOOL_NAMES
新增静态 config 项限制单 chat 同时存在的 user_reminder 待定记录数上限（同 MAX_SENDS_PER_TURN 等既有静态 config 层惯例）；超限时 register_callback 返回错误提示，不静默丢弃/覆盖最旧的一条
新增一个纯函数，把当前 chat 待定的 user_reminder 记录（含 callback_id/内容摘要/fire_at）渲染进冻结快照第七段（仅存在待定记录时产出内容），供模型跨轮次引用 callback_id 来取消；task_completion 来源的记录不参与这段渲染
CallbackRecord/CallbackStoragePort/is_due/render_callback_directive/_callback_scan/_deliver_callback/RuntimeLoop.run_callback() 零改动——有一条集成测试直接证明：一条 register_callback 登记的记录能被这些既有模块不加任何改动地正确送回
到点后送回内容经完整六段冻结快照组装，用模型平时语气自然说出来，不是照本宣科念一遍用户原话
崩溃恢复语义：进程重启后待定 user_reminder 记录原样还在，照常到点触发（验证 Callback 持久化不变量对新生产者同样成立）
register_callback/cancel_callback 直接喂 RuntimeLoop.run() 脚本化对话断言效果（登记成功返回 id、超限拒绝、取消成功、取消不存在的 id fail-closed、跨 chat 隔离），仿现有 delegate_task/cancel_delegate_task 工具测试模式
取消隔离测试：构造同一 chat 下 user_reminder 和 task_completion 两种来源记录同时存在的场景，断言 cancel_callback 只撤销 user_reminder 来源的那一条