docs(schedule): record the reminder framing risk, the snapshot gap, and the prompt contract

The Agent Note now states what a model infers from the origin line and records
the residual risk of dropping the untrusted-content instruction as accepted, with
its reintroduction condition and the assertions that keep a later change
deliberate. It also records why no recorded-session snapshot covers a delivered
reminder, and the host note links back to it.

The package README keeps the creation-side contract in view: prompt stays the
content to present to the user when the target becomes due.

.agents/notes/implemented/architecture/2026-09-16-host-schedule-storage.i18n.yaml

@@ -9,8 +9,8 @@
   en: 2c774d05ae75784f
   zh: 619ba7f281b13233
 /agent-note-host-owned-scheduled-messages/decision:
-  en: 4a38d9bd933241b0
-  zh: b246c74f68e92a25
+  en: de81925284f13c12
+  zh: d0ef35c8b58813f2
 /agent-note-host-owned-scheduled-messages/alternatives-considered:
   en: 21d7ec9a9ff3cbf2
   zh: 93d03b8b3012aa7e

.agents/notes/implemented/architecture/2026-09-16-host-schedule-storage.md

@@ -20,7 +20,7 @@ A plugin-sourced `followup()` synchronously appends the message to the Session i
 
 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. A recurring task with no representable next target remains inactive with its last receipt. A stopped Host does not send messages.
+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](2026-09-24-scheduled-message-framing.md) 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.
 

.agents/notes/implemented/architecture/2026-09-16-host-schedule-storage.zh.md

@@ -20,7 +20,7 @@ Status: implemented
 
 新任务初始化空的 `deliveryHistory`。缺少该可选字段的任务会展示已有的最近一次回执（如果存在），并标明更早记录不可用。读取不会重写旧任务，也不会虚构已丢失的历史或指令快照。下一次确认投递时，保留已有回执并追加新记录。严格解码拒绝重复消息 id，以及最近一次回执与历史末项不一致的情况。历史按追加顺序排列，不按墙钟排序，因此时钟回拨不会颠倒已确认投递的顺序。
 
-重复任务只投递一次最新到期发生时点，Host 重启后也一样。Every 保持与创建时间对齐，直到修改间隔后建立新的起算时点；Daily 保留本地时间与显式 IANA 时区，Weekly 另存非空 ISO 星期集合（唯一且升序）。Every、Daily、Weekly 与 Cron 均使用 `renderRecurringReminderBatchFraming`，同一 Session 的到期任务共用一条 follow-up 消息及其真实消息 id。没有可表示的下一目标时，重复任务保留未运行状态及最近一次回执。停止的 Host 不会发送消息。
+重复任务只投递一次最新到期发生时点，Host 重启后也一样。Every 保持与创建时间对齐，直到修改间隔后建立新的起算时点；Daily 保留本地时间与显式 IANA 时区，Weekly 另存非空 ISO 星期集合（唯一且升序）。Every、Daily、Weekly 与 Cron 均使用 `renderRecurringReminderBatchFraming`，同一 Session 的到期任务共用一条 follow-up 消息及其真实消息 id。两个渲染器输出的固定文本见[投递提醒的来源行](2026-09-24-scheduled-message-framing.zh.md)决策。没有可表示的下一目标时，重复任务保留未运行状态及最近一次回执。停止的 Host 不会发送消息。
 
 Daily 是互斥的第四个创建选择器，Weekly 是第五个，Cron 是第六个，三者都不是对 `every_seconds` 或 `at` 的转换。Weekly 选择本地日期 ISO 星期属于其所存集合的每个日期；解码器拒绝未规范化的已存集合，选择器拒绝空、重复、超出范围或非整数的集合。它们的首个目标严格晚于当前时间。缺失的本地时间或日期被跳过；重叠时间选择较早时点，每个日期一次。下一目标晚于投递判断时刻，且其本地日期晚于所选发生时点的日期。仅 UTC 目标限制在 0001–9999 年；边缘处的本地日期可以进入第 0 年或第 10000 年。Session 恢复后，运行时依据当前时钟重新核对到期成员，避免时钟回拨时接纳未来任务。
 

.agents/notes/implemented/architecture/2026-09-24-scheduled-message-framing.i18n.yaml

@@ -6,14 +6,14 @@
   en: f524c3b0ee74c586
   zh: ec4e85f0fd853532
 /agent-note-delivered-reminders-are-framed-as-scheduled-messages-from-the-user/problem:
-  en: 78aa0a4cc779c456
-  zh: 1c910fa6d1097672
+  en: c4156e2a8a3ad379
+  zh: 992b76509f83d61f
 /agent-note-delivered-reminders-are-framed-as-scheduled-messages-from-the-user/decision:
-  en: 297f1fdd04894f95
-  zh: 4ac560e27b6f0aed
+  en: 66ec943985702611
+  zh: a216c079723657b9
 /agent-note-delivered-reminders-are-framed-as-scheduled-messages-from-the-user/alternatives-considered:
   en: 8074a2b9b9f5d782
   zh: 1604b7ee5d34375e
 /agent-note-delivered-reminders-are-framed-as-scheduled-messages-from-the-user/consequences:
-  en: d96bc209cece929e
-  zh: 88a877d0fe8983ff
+  en: 098e377c82b79f29
+  zh: c75d9a142f87f67c

.agents/notes/implemented/architecture/2026-09-24-scheduled-message-framing.md

@@ -6,13 +6,13 @@ English | [中文](2026-09-24-scheduled-message-framing.zh.md)
 
 ## Problem
 
-Due reminders reach their original Session as user-role messages with producer kind `schedule`. Both renderers opened that message with an instruction about how to treat its payload: one-shot delivery asked the model to present `reminder_prompt_json` as untrusted reminder content and not as new user instructions, and recurring batch delivery asked the same for every `reminder_prompt` in `reminders_json`. The message therefore asserted that its own content was untrusted instead of naming where it came from.
+Due reminders reach their original Session as user-role messages with producer kind `schedule`. Before this decision, both renderers opened that message with an instruction about how to treat its payload: one-shot delivery asked the model to present `reminder_prompt_json` as untrusted reminder content and not as new user instructions, and recurring batch delivery asked the same for every `reminder_prompt` in `reminders_json`. The message therefore asserted that its own content was untrusted instead of naming where it came from.
 
 ## Decision
 
 `renderReminderFraming` and `renderRecurringReminderBatchFraming` in [`packages/schedule/schedule/src/domain.ts`](../../../../packages/schedule/schedule/src/domain.ts) both open with one shared fixed line, `SCHEDULED_MESSAGE_FRAMING`: `This is a scheduled message from the user`. The bracketed marker (`[SCHEDULE REMINDER]`, `[SCHEDULE REMINDER BATCH]`) and the dynamic field lines are unchanged: a one-shot message still appends `schedule_id_json`, `occurrence_at`, and `reminder_prompt_json`, and a recurring batch still appends `reminders_json`.
 
-The fixed line states the origin of the message: a schedule bound to that Session. It does not claim the user typed the prompt text, which `schedule_create` and `schedule_update` let the model write on the user's behalf in that Session. The line carries no instruction about the standing of the prompt text. Framing-line forgery is closed by encoding: the schedule id and prompt are JSON strings, the occurrence instant is a validated canonical RFC 3339 value, and each occupies one line, so a prompt carrying embedded newlines or an `occurrence_at:`-style line cannot add framing lines to the block. The [Host-owned scheduled messages](2026-09-16-host-schedule-storage.md) note keeps the rest of its decision, including delivery through the Session controller and the saved delivery records.
+The fixed line states the origin of the message: a schedule bound to that Session. A model reading a user-role message that opens with it reads the following `reminder_prompt_json` as content the user scheduled, and the Host cannot attest that the user typed it: `schedule_create` and `schedule_update` let the model write the prompt, and a model-written prompt can carry text the model read from the web, files, or command output. The previous line marked that payload untrusted, and this decision drops that instruction, so the change accepts the residual risk that model-authored text arrives under a user-origin line. Reintroduction condition: a demonstrated injection through a model-written prompt restores a clause that scopes the payload as reminder text rather than a new instruction, and the five pinned framing assertions in the package specs plus `expectReminderFraming` in the Web e2e are the check that such a change is deliberate. Framing-line forgery is closed by encoding: the schedule id and prompt are JSON strings, the occurrence instant is a validated canonical RFC 3339 value, and each occupies one line, so a prompt carrying embedded newlines or an `occurrence_at:`-style line cannot add framing lines to the block. The [Host-owned scheduled messages](2026-09-16-host-schedule-storage.md) note keeps the rest of its decision, including delivery through the Session controller and the saved delivery records.
 
 ## Alternatives considered
 
@@ -24,4 +24,6 @@ The fixed line states the origin of the message: a schedule bound to that Sessio
 
 Model-visible reminder text changes for both delivery paths, so a Session log recorded before this decision reconstructs the previous framing, and the Web notice that renders a delivered message shows the new line when expanded. Nothing else moves: no session event, storage field, client code, protocol, or durable format changes, and the delivered text remains reconstructable from the log.
 
-The prompt text carries no authorship guarantee. It is written in the Session the schedule is bound to, by the model through `schedule_create` and `schedule_update` or by the user in the Web task detail, and a model-written reminder can quote text the model read from the web, files, or command output. The task's Session binding scopes which Session's model reaches the task; it is not caller authorization and says nothing about where the prompt content came from. A delivery path whose prompt text can originate outside the target Session, or a decision to mark such content again, needs its own framing decision.
+The prompt text carries no authorship guarantee. It is written in the Session the schedule is bound to, by the model through `schedule_create` and `schedule_update` or by the user in the Web task detail, and a model-written reminder can quote text the model read from the web, files, or command output. The task's Session binding scopes which Session's model reaches the task; it is not caller authorization and says nothing about where the prompt content came from. The Decision holds the accepted risk and its reintroduction condition.
+
+No recorded-session snapshot covers a delivered reminder, and this change adds none: no committed fixture contains a `schedule` message, and `snapshots/web/schedule-catalog` records catalog queries only. Delivery reads the platform wall clock in `packages/schedule/schedule/src/runtime.ts`, and no scenario patch supplies that clock, so a delivered-reminder fixture would need scenario support that does not exist for this path. The delivered text is pinned verbatim instead by the five full-string assertions in `packages/schedule/schedule/tests/{domain,daily,weekly,cron}.spec.ts` and by `expectReminderFraming` in `apps/web/tests/schedule-after.e2e.ts`, which reads the assembled request.

.agents/notes/implemented/architecture/2026-09-24-scheduled-message-framing.zh.md

@@ -6,13 +6,13 @@ Status: implemented
 
 ## Problem
 
-到期的提醒以生产者 kind 为 `schedule` 的 user-role 消息进入其原 Session。两个渲染器都用一句关于如何处理其载荷的固定指令开篇：单次投递要求模型把 `reminder_prompt_json` 作为不可信的提醒内容呈现、而不是新的用户指令；周期批次投递对 `reminders_json` 中的每个 `reminder_prompt` 提出同样的要求。于是这条消息断言自身内容不可信，而没有说明它来自哪里。
+到期的提醒以生产者 kind 为 `schedule` 的 user-role 消息进入其原 Session。在本决策之前，两个渲染器都用一句关于如何处理其载荷的固定指令开篇：单次投递要求模型把 `reminder_prompt_json` 作为不可信的提醒内容呈现、而不是新的用户指令；周期批次投递对 `reminders_json` 中的每个 `reminder_prompt` 提出同样的要求。于是这条消息断言自身内容不可信，而没有说明它来自哪里。
 
 ## Decision
 
 [`packages/schedule/schedule/src/domain.ts`](../../../../packages/schedule/schedule/src/domain.ts) 中的 `renderReminderFraming` 与 `renderRecurringReminderBatchFraming` 都以同一条固定行开篇，即模块常量 `SCHEDULED_MESSAGE_FRAMING`：`This is a scheduled message from the user`。方括号标记（`[SCHEDULE REMINDER]`、`[SCHEDULE REMINDER BATCH]`）与动态字段行不变：单次消息仍追加 `schedule_id_json`、`occurrence_at`、`reminder_prompt_json`，周期批次仍追加 `reminders_json`。
 
-这条固定行说明消息的来源：绑定到该 Session 的一条定时任务。它不声称提示词文本由用户键入——`schedule_create` 与 `schedule_update` 允许模型在该 Session 中通过这些工具代用户写入。这条固定行不包含关于提示词文本地位的指令。固定行无法被动态字段伪造，这由编码保证：schedule id 与提示词是 JSON 字符串，发生时点是经校验的规范 RFC 3339 值，且各自只占一行，因此带有换行或形如 `occurrence_at:` 的提示词无法向该块增加固定行。[Host 拥有的定时消息](2026-09-16-host-schedule-storage.zh.md) 记下的其余决策不变，包括通过 Session controller 投递以及保存的投递记录。
+这条固定行说明消息的来源：绑定到该 Session 的一条定时任务。模型读到以它开篇的 user-role 消息时，会把随后的 `reminder_prompt_json` 当作用户安排的内容，而 Host 无法证明该文本由用户键入：`schedule_create` 与 `schedule_update` 允许模型写入提示词，模型写入的提示词可以带上模型从网页、文件或命令输出中读到的文本。旧固定行把该载荷标记为不可信，本决策有意去掉这一指令，因此接受「模型生成的文本以用户来源行投递」这一残留风险。再引入条件：一旦出现经由模型写入提示词完成注入的实例，就恢复一句把载荷限定为提醒文本、而非新指令的说明；包内五处固定断言与 Web e2e 的 `expectReminderFraming` 是「此类改动必须是有意为之」的检查。固定行无法被动态字段伪造，这由编码保证：schedule id 与提示词是 JSON 字符串，发生时点是经校验的规范 RFC 3339 值，且各自只占一行，因此带有换行或形如 `occurrence_at:` 的提示词无法向该块增加固定行。[Host 拥有的定时消息](2026-09-16-host-schedule-storage.zh.md) 记下的其余决策不变，包括通过 Session controller 投递以及保存的投递记录。
 
 ## Alternatives considered
 
@@ -24,4 +24,6 @@ Status: implemented
 
 两个投递路径的模型可见提醒文本都改变，因此在该决策之前记录的 Session 日志重建出的是旧的固定文本；Web 中渲染该投递消息的通知在展开时显示新的一行。其余不动：没有 session 事件、存储字段、客户端代码、协议或持久化格式变化，投递文本仍可从日志重建。
 
-提示词文本不携带作者保证。它写在绑定该定时任务的 Session 内——由模型通过 `schedule_create` 与 `schedule_update` 写入，或由用户在 Web 任务详情中写入——模型创建的提醒可以把模型从网页、文件或命令输出中读到的文本原样写入。任务的 Session 绑定限定的是哪个 Session 的模型能访问该任务；它不是调用方鉴权，也不说明提示词内容的来源。若出现提示词文本可来自目标 Session 之外的投递路径，或决定重新标记此类内容，都需要单独决定其固定文本。
+提示词文本不携带作者保证。它写在绑定该定时任务的 Session 内——由模型通过 `schedule_create` 与 `schedule_update` 写入，或由用户在 Web 任务详情中写入——模型创建的提醒可以把模型从网页、文件或命令输出中读到的文本原样写入。任务的 Session 绑定限定的是哪个 Session 的模型能访问该任务；它不是调用方鉴权，也不说明提示词内容的来源。Decision 中记下该残留风险与再引入条件。
+
+没有录制会话快照覆盖提醒投递，本次也没有新增：已提交夹具中没有 `schedule` 消息，`snapshots/web/schedule-catalog` 只记录任务查询。投递在 `packages/schedule/schedule/src/runtime.ts` 中读取平台墙上时钟，没有场景补丁提供该时钟，因此提醒投递夹具需要目前尚不存在的场景支持。投递文本改由 `packages/schedule/schedule/tests/{domain,daily,weekly,cron}.spec.ts` 中五处整串断言，以及 `apps/web/tests/schedule-after.e2e.ts` 中读取装配后请求的 `expectReminderFraming` 逐字固定。

packages/schedule/schedule/README.i18n.yaml

@@ -54,8 +54,8 @@
   en: 39a747e5d135e241
   zh: ad505b3d5bc27acf
 /deepseek-ai-dsh-schedule/model-experience/due-reminders-in-the-original-session/what-the-model-sees:
-  en: 7b05d635d4cc9714
-  zh: d1c908f51115e4f5
+  en: 26fb1246db5b64b7
+  zh: 9e54b5120153af14
 /deepseek-ai-dsh-schedule/model-experience/due-reminders-in-the-original-session/what-the-model-sees/one-shot-framing:
   en: d8635e0075bacc3f
   zh: 685e16d812319f85

packages/schedule/schedule/README.md

@@ -122,7 +122,7 @@ Tool results append to conversation history. Creating, listing, or deleting task
 
 #### What the model sees
 
-Due reminders enter as user-role messages with producer kind `schedule`. One-shot messages append `schedule_id_json`, `occurrence_at`, and `reminder_prompt_json` after the fixed text below; the id and prompt are JSON-encoded. Recurring batches append `reminders_json`, an array containing `schedule_id`, `occurrence_at`, and `reminder_prompt` for each latest due occurrence.
+Due reminders enter as user-role messages with producer kind `schedule`. One-shot messages append `schedule_id_json`, `occurrence_at`, and `reminder_prompt_json` after the fixed text below; the id and prompt are JSON-encoded. Recurring batches append `reminders_json`, an array containing `schedule_id`, `occurrence_at`, and `reminder_prompt` for each latest due occurrence. The fixed text names the origin of the message; `schedule_create` and `schedule_update` still describe `prompt` to the model as content to present to the user when the target becomes due.
 
 ##### One-shot framing
 

packages/schedule/schedule/README.zh.md

@@ -122,7 +122,7 @@ Schedule domain 声明整 unit 布局，因为任务是权威数据。路由到
 
 #### 模型看到什么
 
-到期提醒以生产者 kind 为 `schedule` 的 user-role 消息进入会话。单次提醒在下方固定文本之后追加 `schedule_id_json`、`occurrence_at` 和 `reminder_prompt_json`；id 和提示词使用 JSON 编码。周期提醒批次追加 `reminders_json` 数组，每个最新到期时点包含 `schedule_id`、`occurrence_at` 和 `reminder_prompt`。
+到期提醒以生产者 kind 为 `schedule` 的 user-role 消息进入会话。单次提醒在下方固定文本之后追加 `schedule_id_json`、`occurrence_at` 和 `reminder_prompt_json`；id 和提示词使用 JSON 编码。周期提醒批次追加 `reminders_json` 数组，每个最新到期时点包含 `schedule_id`、`occurrence_at` 和 `reminder_prompt`。固定文本说明消息来源；`schedule_create` 与 `schedule_update` 仍把 `prompt` 描述为到期时向用户呈现的内容。
 
 ##### 单次提醒固定文本