Host-owned scheduled messages
Host 拥有的定时消息
Scheduled messages must remain discoverable after restart without loading every Session. A timer attached to a live Agent cannot dispatch a task whose Session remains cold. Users also need to inspect pending and delivered tasks without activating their conversation; removing a task after delivery loses that management record.
English
Problem
Scheduled messages must remain discoverable after restart without loading every Session. A timer attached to a live Agent cannot dispatch a task whose Session remains cold. Users also need to inspect pending and delivered tasks without activating their conversation; removing a task after delivery loses that management record.
Decision
The existing Schedule package owns one Host storage domain containing each task's original Session id, reminder record, active or inactive status, latest delivery receipt, and saved delivery history. The domain is authoritative for retained tasks. The Host scheduler restores timers only for active tasks; a due task uses the Session controller's existing resolution operation and queues an ordinary follow-up in the original Session. Querying and deleting tasks do not resolve an Agent. Stored records lacking status normalize to active without scanning or recreating historical Sessions.
The task domain declares the whole-unit layout. Tasks are authoritative, so the JSON backend rejects an unreadable file, malformed document, unsupported version, or invalid task as a complete load failure instead of interpreting it as deletion. Failed recovery leaves schedule.json unchanged, while an initially absent file opens as an empty domain; repairing the file preserves task identity. Service.init waits for both storage validation and runtime setup, management methods wait for the same initialization result, and an unloading owner releases late-acquired storage without starting dispatch. Dispatch admission is separate from initialization: an ancestor can close Agent admission after a task mutation commits but before runtime cleanup starts. That refusal is logged without automatic retry and does not turn the persisted mutation into a failed management result. Invalid storage and failed cleanup registration still reject startup.
This replaces the earlier Session-log authority, live-only activation, and read-only catalog decisions. The Schedule reference owns explicit absolute-time validation, fixed-rate arithmetic, and the distinction between queue admission and model completion. Historical schedule/change creation and fold types remain restricted to After, At, and Every through LegacyScheduleRecord; a separate Host decoder accepts the current ScheduleRecord, including Daily, Weekly, and Cron. The Host record decoder requires a stored title that is non-empty after trimming, already trimmed, and at most 120 characters, and the strict task schema rejects the whole domain open instead of dropping such a task. The historical change decoder tolerates an absent title so an already-written Session log stays readable, and it applies the same three checks when the member is present. The storage domain remains version 1. Historical events do not populate that domain, and existing at tasks are not converted into daily or weekly rules. Loading a Session with active legacy reminders warns that they must be recreated.
A plugin-sourced followup() synchronously appends the message to the Session inbox. Successful Session flush acknowledges durable delivery. One task-record put stores lastDelivery, appends a delivery record with the occurrence target, acknowledgment time, actual message id, and instruction snapshot, and updates the one-shot's inactive status or the recurring task's next target and status. Task state and its saved history therefore share one commit. Inactive tasks remain stored and never schedule another delivery; explicit deletion stops future delivery and removes the row together with its saved records. These records acknowledge inbox delivery, not user receipt or model execution completion.
New tasks initialize an empty deliveryHistory. A task without that optional field exposes its existing latest receipt, if any, and marks earlier records unavailable. Reading never rewrites the old task or invents the lost history or instruction snapshot. Its next acknowledged delivery preserves that available receipt and appends the new one. Strict decoding rejects duplicate message ids and disagreement between the latest receipt and the last history entry. History follows append order, not wall-clock sorting, so clock rollback does not reverse acknowledged deliveries.
A recurring task contributes its latest due occurrence once, including after Host restart. Every remains creation-aligned until an interval edit establishes a new anchor; Daily retains a local time and explicit IANA zone, and Weekly adds a non-empty ISO weekday set stored as unique ascending numbers. Every, Daily, Weekly, and Cron use renderRecurringReminderBatchFraming and share one follow-up message and its real message id when due for the same Session. The fixed text both renderers emit is the delivered-reminder origin line decision. A recurring task with no representable next target remains inactive with its last receipt. A stopped Host does not send messages.
Daily is a fourth mutually exclusive creation selector, Weekly a fifth, and Cron a sixth, none a conversion of every_seconds or at. Weekly selects every local date whose ISO weekday belongs to its stored set; the decoder rejects an unnormalized stored set, and the selector rejects an empty, repeated, out-of-range, or non-integer one. Their first targets are strictly future. Missing local times and dates are skipped; overlaps select the earlier instant once per date. The next target is after the delivery decision and on a local date later than the selected occurrence's date. Only UTC targets are restricted to years 0001–9999; local dates may cross into year 0 or 10000 at the edges. After Session restoration, the runtime rechecks due members against the current clock so a rollback does not admit future tasks.
The maintained @js-temporal/polyfill 0.5.1 resolves local dates and overlap/gap behavior using the Host's IANA data; Schedule does not own offset-sampling logic or add another package layer. Each daily or weekly record stores normalized HH:mm:ss.SSS time, its zone, its weekday set where applicable, and a committed next UTC instant. Decoding and restart do not recompute that instant. Valid zone aliases remain readable across canonical-name changes, while subsequent targets use current Host time-zone data.
Model schedule_list, Remote list, and the Session header's right-aligned reminder clock show only active tasks. The independent Automation tasks page opens from the sidebar and reads active and inactive Host tasks through the read-only Remote catalog method, without activating Sessions or reading their history. That clock is absent while the Session has no active reminder, opens a single task's detail directly when exactly one remains, and otherwise lists them so one can be chosen; both paths open one right-Sidebar task tab that renders the same detail component the Automation tasks page uses, so neither path selects the main panel. The tab names its task and original Session through its navigation parameters and carries that binding into every mutation, so opening or deleting from it never activates a Session. The page has one All, Enabled, and Inactive status filter row, retained inactive details, latest delivery metadata, and an original-Session control that sits in the detail tab strip beside the task actions. Its header's New action starts a new Session, where the reminder is created by asking the model; the page offers no creation form. Navigation waits for Session and archive metadata, explains unavailable targets, and never restores an archived Session implicitly. Task retention remains independent of original-Session availability. Every, Daily, Weekly, and Cron are recurring rules; the page groups tasks only by status. Daily and Weekly rule labels retain the saved local time, exact rule zone, and stored weekday set rather than substituting the browser zone used for next-target display. Explicit confirmed deletion reuses delete with the entry's original Session binding, requiring that the supplied binding match the stored task. This argument check is not independent caller authorization: model tools capture the current Agent's Session, while the global user interface selects the task's original binding. Cross-Session model modification policy remains a product decision, not a consequence of the storage layout. A payload-free change notification invalidates queries, and reconnect queries recover missed notifications. Deletion prevents subsequent dispatch but does not retract a queued message.
The second detail level separates Rules from Delivery records. Opening records requests history with the task's original Session binding and an explicit page limit of 1–100. An exclusive message-id cursor reads older receipts without changing position when new deliveries append. Catalogs retain only latest-receipt metadata rather than duplicating full histories in every task-list response. Missing tasks and unknown cursors are distinct failures, not empty successful history. The records view loads lazily, rejects stale responses, and keeps original-Session navigation separate from inspection.
Name, instruction, and timing updates share the dispatch and deletion FIFO. Comparing the complete observed record inside that queue prevents a stale draft from overwriting a saved rule or a target advanced by delivery. This avoids adding a persisted revision counter, at the cost of rejecting drafts after normal delivery changes the target. One task put replaces the rule, name, or instruction, preserving identity, original Session binding, status, latest receipt, and saved history. A request may omit the timing change, the name, or the instruction; an omitted field keeps its stored value, and a name or instruction change alone leaves the committed target untouched. Normalized no-ops leave the committed target and stored bytes unchanged. Changed one-shots retain their identity as At records; changed fixed intervals use a new accepted-save anchor; changed wall-clock rules re-resolve their first future target from the same accepted-save sample, and an equivalent normalized rule stays a no-op. A timing change may select a different recurrence kind, and the new rule computes its target exactly as creation would from that accepted-save sample. Deletion removes the row together with its saved records (consequences of that reversal), so the runtime never schedules the task again and history no longer resolves for its original binding. Inactive tasks are not reopened.
The page uses the existing Host task domain and scheduler, not a mock engine or a Session projection. The name, the instruction, and the run-time rows edit one local draft for the shown task, and one Save commits that draft as a single update carrying the complete expected record; Cancel restores the stored values, a failed save retains the draft, an unsaved draft survives an authoritative refresh, and a committed save and a failed catalog refresh remain separate outcomes. Pause and execution-history operations remain unsupported. Lifecycle status and latest delivery acknowledgment do not describe model results.
The client presentation derives from existing persisted data instead of widening a persisted format. The schedule_create transcript card reads the created task out of the call's model-visible result JSON, which already serializes the canonical task value, rather than declaring presentationMeta: a persisted metadata channel would add a durable field for a card that Session-log replay reconstructs from the result alone, and previously recorded Sessions render the card without a format change. The Sidebar Session-row clock mark occupies the root-scoped sidebar.session.row.leading seat rather than requesting a per-Session provider, because a Session-scoped seat would bind every listed Session and thereby activate and retain it; the same root-scoped owner share feeds sidebar.session.row.hover, and both read the shared Host catalog snapshot schedule/catalog() without reading a Session log.
Session inbox persistence and the task put occur in separate persistence systems. Inbox persistence precedes the task put to avoid marking delivery before its message exists. A crash or task-write failure after inbox persistence can repeat a message; storing status, target, and receipt together does not make the two stores atomic. Dispatch failures retain the task and produce a diagnostic; there is no independent retry timer. This feature does not create or replace a Goal.
Alternatives considered
Load every Session at startup. Session activation is unnecessary for discovering tasks and would couple timer restoration to Agent initialization and conversation size.
Introduce separate rule, run, scheduler, and delivery packages. Durable schedules and their saved inbox receipts support task inspection without independent execution records or model completion tracking.
Write history separately from the task. The domain exposes independent per-record writes, not a multi-record transaction. Keeping history in the task row makes status, next target, latest receipt, and appended history commit together. A separate history store requires an explicit transactional or recovery design before adopting it.
Advance before enqueue or promise exactly-once delivery. Advance-first can lose a message on enqueue failure. Exactly-once delivery needs a shared transaction or a durable idempotency protocol that the two stores do not provide.
Import every historical Session automatically. A startup scan would reintroduce the cold-history dependency. Explicit recreation keeps the persisted authority unambiguous; historical decoding preserves access to existing logs.
Represent daily reminders as 86,400-second intervals. Fixed elapsed time cannot preserve a local wall-clock rule when offsets change. A distinct Daily record retains the rule needed to resolve each later date. Weekly extends the same decision with an explicit weekday set rather than a 604,800-second interval, so a later offset change still resolves each selected local date.
Sample offsets manually or recalculate saved targets during decoding. Temporal supplies maintained calendar and disambiguation behavior without a Schedule-owned offset search. A committed target remains due even when newer time-zone data would resolve the rule differently; only later targets use that data.
Consequences
Keep the mock's hourly choice out of the stored vocabulary. The approved mock lists 每小时整点 beside the daily, weekly and one-shot choices. Hourly and fixed-rate intervals are the same elapsed-time rule, so the card maps that menu slot onto the existing interval kind instead of adding a persisted kind. A dedicated hourly kind would need a new durable variant, its decoder, its target resolution, and its tool schema, all to express what an interval already expresses.
Task discovery and timers do not depend on loaded Sessions. The after, absolute-time, and fixed-rate selectors retain their semantics alongside Daily, Weekly, and Cron; reading existing saved tasks does not rewrite them. The Host must have its ordinary Session persistence and recovery services available, and the shipped Web composition mounts the Schedule service for the whole deployment. Explicit deletion stops future delivery and removes the task from list and catalog without deleting conversation messages; the removed row takes its saved receipts with it. History is pruned to the configured window and record cap when an acknowledgment is appended, loaded into Host memory, and rewritten with the task on each acknowledgment. Pagination limits the returned record count; the plugin configuration (deliveryHistoryDays, default 30, and deliveryHistoryRecords, default 200) limits storage growth. Earlier overwritten receipts and deliveries whose task write failed cannot be reconstructed. Pause and execution-history operations remain unsupported.
Required coverage includes startup from stored tasks, missing-status normalization, cold Session restoration, latest-only catch-up, inactive-task retention without repeat dispatch, real message receipts, deletion across restart, removal of a deleted task's saved deliveries, queue/persistence failures, and disposal. Wall-clock obligations include gaps and skipped dates, earlier-only overlaps, fractional seconds, UTC-range edges, committed-target and alias preservation, and post-restoration clock rollback. Weekly adds weekday normalization and validation, next-target selection across a gap and an overlap, and stored set preservation. Historical decoders must reject Daily, Weekly, and Cron while Host storage accepts them. Client coverage includes every recurring kind, exact rule time, zone, and weekday set, All/Enabled/Inactive status filters, retained inactive details and original-Session navigation, authoritative refresh after confirmed deletion and notification, empty lists, reconnect, and late responses. Presentation coverage includes the page's New action starting a Session, the transcript card's narrowing of persisted result JSON including an incomplete or replayed result, the header clock's direct open for exactly one task and its count label, the idle-only row mark with the hover-card two-task limit and omission line. History coverage includes legacy byte preservation, append and restart, immutable sent instructions, strict latest-receipt consistency, stable cursor pagination, binding checks, failed persistence, and late page replies during refresh or task changes. Cross-store crash duplication remains an explicit limitation rather than a completion claim.
Name, instruction, and timing coverage includes all supported rule kinds, complete-record conflicts, delivery/save ordering, cancellation, normalized no-ops, unchanged-history persistence, pending controls, draft retention, and collision-free task identity. The built CLI process test drives public Remote requests and reloads actual task-file bytes in a fresh Host. Its task and receipt seeds establish retained-data inputs, not real creation, delivery, or recorded-model evidence; those require ordinary Session operations and captured model requests.
中文
Problem
定时消息必须能在重启后被发现，无须加载每个 Session。挂在 live Agent 上的 timer 无法投递目标 Session 仍为 cold 的任务。用户还需要在不激活对话的情况下查看待投递和已投递任务；投递后删除任务会丢失这条管理记录。
Decision
现有 Schedule 包拥有一个 Host storage domain，保存每个任务的原始 Session id、提醒记录、active 或 inactive 状态，最近一次投递回执，以及已保存的投递历史。该 domain 是保留任务的权威来源。Host scheduler 仅为活动任务恢复 timer；到期任务使用 Session controller 现有的解析操作，在原 Session 中排入普通 follow-up。查询和删除任务不会解析 Agent。已存储但缺少状态的记录规范化为 active，不扫描或重建历史 Session。
任务 domain 声明整 unit 布局。任务是权威数据，因此 JSON 后端会把文件不可读、文档损坏、版本不受支持或任务非法作为整批加载失败，而不是解释为删除。恢复失败不会改写 schedule.json，初始不存在的文件则作为空 domain 打开；修复该文件后会保留任务身份。Service.init 等待存储校验和运行时初始化，管理方法等待同一初始化结果；拥有方卸载时释放迟到的存储资源，而不开始投递。投递调度准入与初始化分开：任务变更提交后、运行时清理开始前，祖先可能关闭 Agent 准入。此类拒绝会记录日志而不自动重试，不会将已持久化的变更变成失败的管理结果。存储非法和清理注册失败仍拒绝启动。
本决策替代先前的 Session 日志权威来源、仅 live 时激活和只读目录决策。Schedule 参考负责显式绝对时间校验、固定速率计算，以及区分排队接纳与模型完成。历史 schedule/change 的创建与 fold 类型通过 LegacyScheduleRecord 保持为 After、At 和 Every；独立的宿主解码器接受包含 Daily、Weekly 与 Cron 的当前 ScheduleRecord。宿主记录解码器要求已存储的 title 去除首尾空白后非空、本身已去除首尾空白且不超过 120 个字符，严格的 task schema 会拒绝整个 domain 的打开，而不是丢弃这样的任务。历史变更解码器容忍缺失的 title，以便已写入的 Session 日志仍可读取；该成员存在时，同样按这三项检查校验。storage domain 保持版本 1。历史事件不会填充该 domain，已有 at 任务也不会转换为每日或每周规则。加载含有活动旧提醒的 Session 时，会警告需要重新创建提醒。
插件来源的 followup() 同步将消息追加到 Session 收件箱。Session flush 成功后确认持久投递。一次任务记录 put 存储 lastDelivery，追加包含发生目标、确认时间、真实消息 id 和指令快照的发送记录，并更新一次性任务的 inactive 状态或重复任务的下一目标和状态。因此，任务状态与其保存的历史共用一次提交。未运行任务仍保留在存储中，且不会再次安排投递；显式删除会阻止后续投递，并把该行连同其已保存记录一并移除。这些记录确认收件箱投递，不表示用户收到消息或模型执行完成。
新任务初始化空的 deliveryHistory。缺少该可选字段的任务会展示已有的最近一次回执（如果存在），并标明更早记录不可用。读取不会重写旧任务，也不会虚构已丢失的历史或指令快照。下一次确认投递时，保留已有回执并追加新记录。严格解码拒绝重复消息 id，以及最近一次回执与历史末项不一致的情况。历史按追加顺序排列，不按墙钟排序，因此时钟回拨不会颠倒已确认投递的顺序。
重复任务只投递一次最新到期发生时点，Host 重启后也一样。Every 保持与创建时间对齐，直到修改间隔后建立新的起算时点；Daily 保留本地时间与显式 IANA 时区，Weekly 另存非空 ISO 星期集合（唯一且升序）。Every、Daily、Weekly 与 Cron 均使用 renderRecurringReminderBatchFraming，同一 Session 的到期任务共用一条 follow-up 消息及其真实消息 id。两个渲染器输出的固定文本见投递提醒的来源行决策。没有可表示的下一目标时，重复任务保留未运行状态及最近一次回执。停止的 Host 不会发送消息。
Daily 是互斥的第四个创建选择器，Weekly 是第五个，Cron 是第六个，三者都不是对 every_seconds 或 at 的转换。Weekly 选择本地日期 ISO 星期属于其所存集合的每个日期；解码器拒绝未规范化的已存集合，选择器拒绝空、重复、超出范围或非整数的集合。它们的首个目标严格晚于当前时间。缺失的本地时间或日期被跳过；重叠时间选择较早时点，每个日期一次。下一目标晚于投递判断时刻，且其本地日期晚于所选发生时点的日期。仅 UTC 目标限制在 0001–9999 年；边缘处的本地日期可以进入第 0 年或第 10000 年。Session 恢复后，运行时依据当前时钟重新核对到期成员，避免时钟回拨时接纳未来任务。
受维护的 @js-temporal/polyfill 0.5.1 使用宿主 IANA 数据解析本地日期及重叠或缺口；Schedule 不拥有偏移量采样逻辑，也不增加包层级。每日或每周记录保存规范化后的 HH:mm:ss.SSS 时间、时区、适用的星期集合及已提交的下一 UTC 时点。解码和重启不会重新计算该时点。规范名称变化后，有效时区别名仍可读取；后续目标使用宿主当前的时区数据。
模型 schedule_list、Remote list 和 Session 顶部右侧的提醒时钟仅显示活动任务。独立的自动化任务页面从侧边栏打开，通过只读 Remote catalog 方法读取活动和未运行 Host 任务，不激活 Session 或读取其历史。该时钟在该 Session 没有活动提醒时不显示；恰好有一个时直接打开该任务详情，否则列出提醒供选择。两条路径都打开同一个右侧边栏任务页签，该页签渲染自动化任务页面所用的同一详情组件，因此都不会切换主面板。页签通过导航参数指明任务及其原 Session，并把该绑定带入每个修改操作，因此从页签打开或删除都不会激活 Session。页面提供一行“全部/已开启/未运行”状态筛选，保留未运行任务详情、最近一次投递元数据和固定在位于详情页签条内、与任务操作并排的原 Session 入口。页头的“新建”操作会打开一个新会话，提醒由模型在该会话中创建；页面不提供创建表单。导航等待 Session 与归档元数据，解释不可用目标，且不会隐式恢复已归档 Session。任务保留与原 Session 可用性相互独立。Every、Daily、Weekly 和 Cron 均为重复规则；页面只按状态分组。Daily 与 Weekly 规则标签保留保存的本地时间、精确规则时区和所存星期集合，不替换为下一目标显示所用的浏览器时区。显式确认删除复用 delete，传入条目的原始 Session 绑定，要求传入绑定与已存任务一致。这项参数校验不是独立的调用者鉴权：模型工具捕获当前 Agent 的 Session，全局用户界面则选择任务的原始绑定。跨会话模型修改政策仍是产品决策，不由存储布局直接决定。无载荷的变更通知使查询失效，重新连接时重新查询以恢复漏掉的通知。删除阻止后续投递，但不撤回已排队消息。
第二层详情将“规则”与“发送记录”分开。打开发送记录时，history 请求携带任务的原始 Session 绑定，以及 1–100 的显式分页数量。排他的消息 id 游标用于读取更早回执，新投递追加后不会改变其定位。目录仅保留最近一次回执元数据，不在每次任务列表响应中复制完整历史。任务不存在和游标未知属于独立失败，不是查询成功的空历史。记录视图按需加载，拒绝晚到的过期响应，并将原 Session 导航与查看记录分开。
名称、指令和时间更新与投递、删除共用 FIFO。在该队列内比较完整的已观察记录，可防止旧草稿覆盖已保存规则或投递已推进的目标。这样无须增加持久版本计数器，代价是正常投递改变目标后也会拒绝旧草稿。一次任务 put 替换规则、名称或指令，保留身份、原始 Session 绑定、状态、最近一次回执和已保存历史。请求可以省略时间变更、名称或指令；省略的字段保留已存储值，仅修改名称或指令不会改变已提交目标。归一化后等价的修改保留已提交目标与存储字节。修改后的一次性任务以 At 记录保留身份；固定间隔改变后以接纳保存时刻重新起算；钟表规则改变后以同一接纳保存时刻重新解析首个未来目标，而归一化后等价的规则不产生变更。时间变更可以选择不同的重复类型，新规则按创建时相同的方式、以同一接纳保存时刻计算目标。删除会移除该行及其已保存记录（该反转的后果），因此运行时不会再调度该任务，history 也不再按其原始绑定解析。未运行任务不会被重新启用。
页面使用现有 Host 任务 domain 和调度器，不使用 mock 引擎或 Session projection。名称、指令和运行时间行编辑当前任务的同一份本地草稿，一次保存把该草稿作为携带完整预期记录的单个更新提交；取消恢复已存储值，保存失败保留草稿，未保存的草稿会保留到权威刷新之后，保存已提交与目录刷新失败仍是不同结果。暂停和执行历史操作仍不受支持。生命周期状态与最近一次投递确认不描述模型结果。
客户端的呈现从已有持久化数据派生，而不扩展持久化格式。schedule_create transcript（文本记录）卡片从该调用对模型可见的结果 JSON 中读出创建的任务——该 JSON 已经序列化规范任务值——而不是声明 presentationMeta：持久化 metadata 通道会为一张仅凭结果即可在 Session 日志回放中重建的卡片增加持久字段，而早于该卡片录制的 Session 无需格式变更即可渲染它。侧栏 Session 行的时钟标记占用 root 作用域的 sidebar.session.row.leading slot，而不是请求逐 Session provider，因为 Session 作用域的 slot 会绑定列表中每个 Session，从而激活并保留它；同一个 root 作用域属主约定也供给 sidebar.session.row.hover，两者都读取共享的 Host 目录快照 schedule/catalog()，不读取 Session 日志。
Session 收件箱持久化和任务 put 发生在两个持久化系统中。收件箱持久化先于任务 put，以免消息尚不存在时就标记已投递。收件箱持久化后崩溃或任务写入失败可能重复发送消息；状态、目标和回执一起存储，并不使两个存储具有原子性。投递失败保留任务并输出诊断；没有独立的重试 timer。此功能不创建或替换 Goal。
Alternatives considered
启动时加载每个 Session。 发现任务不需要激活 Session，这会让 timer 恢复依赖 Agent 初始化和对话大小。
引入独立的 rule、run、scheduler 和 delivery 包。 持久 schedule 与已保存的收件箱回执足以支持任务查看，无须独立执行记录或模型完成跟踪。
将历史与任务分开写入。 domain 提供独立的逐记录写入，不提供多记录事务。将历史保存在任务行内，可使状态、下一目标、最近一次回执和追加历史一起提交。采用独立历史存储之前，需要明确的事务或恢复设计。
入队前推进，或承诺恰好投递一次。 先推进可能在入队失败时丢失消息。恰好投递一次需要共享事务或持久幂等协议，这两个存储并不提供。
自动导入全部历史 Session。 启动扫描会重新引入对 cold 历史的依赖。显式重建使持久化权威来源保持明确；历史解码保留了现有日志的访问能力。
以 86,400 秒间隔表示每日提醒。 固定经过时长无法在偏移量变化时保留本地钟表规则。独立的 Daily 记录保留了解析每个后续日期所需的规则。Weekly 以显式星期集合而非 604,800 秒间隔延续同一决策，因此偏移量变化后仍能解析每个所选本地日期。
手动采样偏移量或在解码时重新计算已保存目标。 Temporal 提供受维护的日历与消歧行为，无须由 Schedule 实现偏移量搜索。即使较新的时区数据对规则给出不同解析，已提交目标仍然到期；仅后续目标使用该数据。
Consequences
不把 mock 的「每小时整点」引入持久词表。 设计稿把它与每天、每周、仅一次并列。每小时整点与固定间隔在语义上是同一种按经过时间计量的规则，因此详情里的该项直接映射到既有的间隔类型，而不是新增一个持久种类。若真要新增，需要新的持久变体、解码器、目标解析与工具 schema，而它表达的能力现有间隔已经覆盖。
任务发现和 timer 不依赖已加载的 Session。延迟、绝对时间和固定速率选择器在与 Daily、Weekly、Cron 并存时保留自身语义；读取已有任务不会重写它们。Host 必须提供普通 Session 持久化和恢复服务，而随发行版交付的 Web 组合为整个部署挂载 Schedule 服务。显式删除会阻止后续投递，并将任务从 list 和 catalog 中移除，不删除对话消息；被移除的行会带走其已保存回执。历史在追加确认时按配置的窗口与条数上限裁剪，随后加载到 Host 内存，并在每次确认时随任务一起重写。分页限制返回记录数量，不限制存储增长或指令字节数。此前被覆盖的回执，以及任务写入失败的投递记录，无法重建。暂停和执行历史操作仍不受支持。
必要覆盖范围包括从已存储任务启动、缺失状态规范化、冷 Session 恢复、仅补发最新发生时点、保留未运行任务且不重复投递、真实消息回执、重启后的删除结果、删除会移除已保存发送记录、排队或持久化失败，以及销毁。钟表规则的验证要求包括缺口和跳过的日期、仅选择较早时点的重叠、小数秒、UTC 范围边缘、已提交目标和别名保留，以及恢复后的时钟回拨。Weekly 另需覆盖星期集合的规范化与校验、跨缺口与重叠的下一目标选择，以及已存集合的保留。历史解码器必须拒绝 Daily、Weekly 与 Cron，而宿主存储接受它们。客户端覆盖范围包括每种重复规则、精确规则时间、时区和星期集合、全部/已开启/未运行状态筛选、保留未运行任务详情和原 Session 导航、确认删除和通知后的权威刷新、空列表、重新连接和晚到响应。呈现覆盖范围包括页面“新建”操作打开新会话、transcript 卡片从不完整或回放的结果 JSON 中收窄任务、页头时钟在恰好一个任务时直接打开并给出数量标签、仅空闲行标记及其悬浮卡片两个任务上限与遗漏行。历史覆盖范围包括旧文件字节保留、追加与重启、不可变的发送指令、最近回执一致性严格校验、稳定游标分页、绑定校验、持久化失败，以及刷新或切换任务期间晚到的分页响应。跨存储崩溃导致的重复投递仍是明确限制，不能被表述为完成保证。
名称、指令和时间编辑覆盖范围包括所有支持的规则类型、完整记录冲突、投递与保存的顺序、取消、规范化后的无变更、历史持久化不变、等待期间的控件、草稿保留，以及无碰撞的任务标识。已构建 CLI 进程测试 驱动公开 Remote 请求，并在新 Host 中重新加载实际任务文件字节。任务和回执种子只是已保留数据的输入，不是真实创建、投递或模型录制证据；这些证据需要普通 Session 操作与捕获的模型请求。