feat: add optional time context plugin

docs/config-catalog.md

@@ -864,6 +864,22 @@ export interface Config {
 
 Source: [`packages/core/system-prompt/src/index.ts:227`](../packages/core/system-prompt/src/index.ts)
 
+## `@deepseek-ai/dsh-time-context`
+
+Requires: `systemPrompt`
+
+```ts config-catalog
+/** Configuration for the request-time clock section. */
+export interface Config {
+  /** IANA time zone used for the rendered timestamp (default `UTC`). */
+  timeZone?: string
+  /** Maximum age of a reading within one turn, in milliseconds (default 60,000; `0` refreshes every step). */
+  refreshIntervalMs?: number
+}
+```
+
+Source: [`packages/context/time-context/src/index.ts:28`](../packages/context/time-context/src/index.ts)
+
 ## `@deepseek-ai/dsh-tool-cordis`
 
 Requires: `tools`

docs/module-graph.md

@@ -107,6 +107,9 @@ flowchart TD
     pkg_code_runtime["code-runtime"]
     pkg_code_runtime_worker["code-runtime-worker"]
   end
+  subgraph group_context["packages/context"]
+    pkg_time_context["time-context"]
+  end
   subgraph group_guard["packages/guard"]
     pkg_repeat_tool_guard["repeat-tool-guard"]
   end
@@ -183,6 +186,8 @@ flowchart TD
   pkg_user_approval --> pkg_system_prompt
   pkg_user_interaction --> pkg_agent
   pkg_user_interaction --> pkg_llm
+  pkg_time_context --> pkg_agent
+  pkg_time_context --> pkg_system_prompt
   pkg_workflow --> pkg_agent
   pkg_workflow --> pkg_brand
   pkg_workflow --> pkg_llm
@@ -375,6 +380,7 @@ flowchart TD
 | [`invariants`](../packages/support/invariants) | `support` | [`agent`](../packages/core/agent), [`llm`](../packages/llm/llm), [`scope`](../packages/core/scope), [`session`](../packages/core/session) |
 | [`user-approval`](../packages/ui/user-approval) | `ui` | [`agent`](../packages/core/agent), [`brand`](../packages/util/brand), [`llm`](../packages/llm/llm), [`scope`](../packages/core/scope), [`session`](../packages/core/session), [`system-prompt`](../packages/core/system-prompt) |
 | [`user-interaction`](../packages/ui/user-interaction) | `ui` | [`agent`](../packages/core/agent), [`llm`](../packages/llm/llm) |
+| [`time-context`](../packages/context/time-context) | `context` | [`agent`](../packages/core/agent), [`system-prompt`](../packages/core/system-prompt) |
 | [`workflow`](../packages/workflow/workflow) | `workflow` | [`agent`](../packages/core/agent), [`brand`](../packages/util/brand), [`llm`](../packages/llm/llm) |
 | [`tools`](../packages/core/tools) | `core` | [`agent`](../packages/core/agent), [`code-runtime`](../packages/code-runtime/code-runtime), [`llm`](../packages/llm/llm), [`scope`](../packages/core/scope), [`session`](../packages/core/session), [`system-prompt`](../packages/core/system-prompt), [`user-approval`](../packages/ui/user-approval) |
 | [`bash-sandbox`](../packages/bash/bash-sandbox) | `bash` | [`bash`](../packages/bash/bash), [`bash-local`](../packages/bash/bash-local), [`sandbox`](../packages/sandbox/sandbox) |

docs/rfc/INDEX.md

@@ -78,6 +78,7 @@ Generated by `pnpm run gen-rfc-index` from the RFC tree — never edit by hand;
 | [The self-referential cordis toolset](implemented/feature/2026-07-08-self-referential-cordis-toolset.md) | 2026-07-08 |
 | [Exact session query service](implemented/feature/2026-07-10-session-query-service.md) | 2026-07-10 |
 | [Configure subagent persona, tool visibility, and depth](implemented/feature/2026-07-12-subagent-persona-tool-filter-and-depth.md) | 2026-07-12 |
+| [Optional time-context plugin](implemented/feature/2026-07-14-time-context-plugin.md) | 2026-07-14 |
 
 ### Simplification
 

docs/rfc/implemented/feature/2026-07-14-time-context-plugin.i18n.yaml

@@ -0,0 +1,6 @@
+# Bilingual-pair consistency record (docs/i18n/README.md): the git blob hash of each
+# side as of the last confirmed-consistent state. Both languages carry equal authority;
+# after editing either side, bring the other along and re-record with:
+#   pnpm run verify-translation-pairing --write
+2026-07-14-time-context-plugin.md: cab55c78c7f649db63d3049f9a1dfa8e0a6673e9
+2026-07-14-time-context-plugin.zh.md: a4644d8484c8c6f906a1123502c7530f09bcb1d8

docs/rfc/implemented/feature/2026-07-14-time-context-plugin.md

@@ -0,0 +1,54 @@
+# RFC: Optional time-context plugin
+
+Status: implemented
+
+English | [中文](2026-07-14-time-context-plugin.zh.md)
+
+## Problem
+
+An agent request has no live clock unless a deployment hard-codes one into prompt text or gives the model a tool to query it. Static text becomes false immediately, while a tool call is unnecessary overhead for ordinary reasoning about dates, deadlines, or how long a conversation has been idle. The missing companion fact is elapsed time: the model receives the current user prompt but cannot distinguish a quick follow-up from one sent hours after the preceding conversation message.
+
+The prompt assembly and session log already provide the necessary inputs. A section provider runs once per step with the active agent, model-visible session events carry durable append timestamps, and the request-header fold records the exact rendered system prompt. The design question is where temporal facts belong and how often they change without accumulating stale readings or creating background work.
+
+## Decision
+
+`@deepseek-ai/dsh-time-context` is an optional function plugin at `packages/context/time-context/`. It opens the `context/` product group for bounded request-context enrichments that define neither a tool nor a service seam. The package is not loaded by `dsh-agent-core` or a shipped example; a deployment mounts it explicitly when temporal context is worth the tokens and disclosure.
+
+The plugin registers one global `ctx.systemPrompt.section()` contribution named `context:time` at order 10, after the deployment persona and before tool guidance. Its provider returns two lines for an active agent turn: an ISO-shaped timestamp with numeric UTC offset and IANA zone, and a compact whole-second duration since the last model-visible message before that turn opened. A bare or idle prompt assembly receives an empty section.
+
+### Previous-message baseline
+
+At a turn's first assembly, the provider scans backward from that turn's `turn/start` and uses the latest `user/message`, `assistant/message`, `tool/result`, `context/message`, or `steering/message` timestamp. It deliberately excludes the current turn's newly appended user prompt: measuring from that event would make the first request report approximately zero and lose the inter-turn gap the feature exists to convey. Every later refresh in the same turn retains the baseline, so a long-running turn reports the growing duration since the preceding conversation message. The first turn reports `unavailable (no earlier message in this session)`.
+
+The baseline is the session event's append time, not an unlogged client receipt time. That makes resume and fork behavior deterministic from the durable log and keeps the model-visible value reconstructable without introducing a new event. A backward wall-clock adjustment clamps the displayed duration to zero rather than producing a negative interval.
+
+### Refresh policy
+
+`refreshIntervalMs` defaults to 60,000 and must be a non-negative safe integer. Every turn's first request refreshes regardless of the prior turn's timestamp. Within a multi-step turn, a later assembly reuses the cached block until its age reaches the interval; `0` refreshes every step. The policy is request-bound: no timer creates work while the agent is inside a model call, running a tool, or idle, because no request exists to consume a new value.
+
+`timeZone` defaults to `UTC` and is validated as an IANA identifier at plugin load. The formatter emits an ISO-shaped local timestamp including the resolved zone and its current numeric offset, so daylight-saving changes remain explicit instead of silently shifting a zone-less clock.
+
+### Logging and token shape
+
+The temporal block is dynamic system-prompt state. The loop's existing `request/header` snapshot and `request/header-delta` fold records every rendered change before transmission, satisfying the [reconstructable-requests contract](../architecture/2026-07-05-reconstructable-requests.md). A request carries exactly one current block; previous readings do not remain in derived conversation history. This follows the ownership rule in the [prompt-variables RFC](../architecture/2026-07-05-prompt-variables-and-tool-guidance-ownership.md): the optional plugin owns the temporal fact and contributes it through the ordinary prompt registry, with no loop special case.
+
+## Testing
+
+The package suite uses fake system time and covers UTC and offset formatting, first-turn fallback, every eligible previous-message variant, whole-duration units, backward-clock clamping, per-turn refresh, interval reuse, interval expiry, `0` per-step behavior, independent per-agent caches, invalid config, HMR disposal, and the Loader namespace path. A real agent-loop test pins the transmitted system prompt and its `request/header-delta` refresh record. No default snapshot changes because the plugin is intentionally absent from every shipped composition; mounting it in a default snapshot fixture would violate the opt-in decision.
+
+## Alternatives considered
+
+- **Append a `context/message` on every turn or refresh** — rejected: each reading remains in derived history, so stale clock values and token cost accumulate with conversation length. A surface replacement cannot both remove the old node and move the new reading to the tail; replacement preserves the old node's position, while replacing through the tail would hide intervening conversation.
+- **Use `agent/session-prefix`** — rejected: the prefix is composed once per loop instance and is intentionally session-stable, so it cannot represent a clock that changes per turn or step.
+- **Mutate requests in `agent/request`** — rejected: that seam shapes call config only, fires after the message boundary, and model-visible content inserted there would bypass both prompt-pressure accounting and the logged-header contract.
+- **Register separate `{{current_time}}` and `{{elapsed}}` prompt variables** — rejected: independent providers can sample different instants and need shared caching to keep refresh semantics atomic. One section provider computes and records the pair as one value; deployments do not need to repeat a temporal template in their persona.
+- **Inject from a background timer at the configured interval** — rejected: while no model request is being assembled, a fresh value has no consumer. Timer-driven `agent.inject()` would create durable one-shot turns and wake or mutate idle sessions merely to announce time passing.
+- **Mount the plugin in `dsh-agent-core`** — rejected: time zone, disclosure, token budget, and desired freshness are deployment policy. Explicit opt-in keeps the default harness context stable.
+- **Place the package in `core/`** — rejected: core owns the product API spine. A context enrichment is an optional leaf with no service key, so the dedicated group states its composition role directly.
+
+## Consequences
+
+- Models in opted-in deployments receive an unambiguous zoned clock and an inter-turn elapsed duration without spending a tool call. The system-prompt token cost is fixed per request instead of growing with the session.
+- A refresh changes the request header and therefore adds a `request/header-delta` event. `refreshIntervalMs` trades clock freshness against those durable deltas; setting it to zero intentionally records a new value on every step whose whole-second rendering changed.
+- No request is created solely to refresh time. A tool that runs longer than the interval leaves the prior reading in place until the next step assembles, when the provider catches up.
+- The duration reflects harness processing time at durable append boundaries, not client-network latency before the message entered the log. Preserving a client-origin timestamp would require a separate durable input contract and is outside this plugin.

docs/rfc/implemented/feature/2026-07-14-time-context-plugin.zh.md

@@ -0,0 +1,54 @@
+# RFC：可选时间上下文插件
+
+Status: implemented
+
+[English](2026-07-14-time-context-plugin.md) | 中文
+
+## 问题
+
+如果部署方既没有将当前时间硬编码到提示词中，也没有向模型提供查询时间的工具，agent（智能体）请求就无法获得实时准确的时钟信息。静态文本会立即失真，而对于日期、截止时间或会话闲置时长等常规推理，调用工具会带来不必要的开销。模型还缺少另一项配套信息：已经过去的时长。模型虽然能收到当前用户提示词，却无法区分紧接着发送的消息与上一条会话消息几小时后才发送的消息。
+
+提示词组装流程和会话日志已经提供所需输入。区段提供方会在每个步骤中针对活跃 agent 运行一次；模型可见的会话事件带有持久的追加时间戳；请求头折叠结果会记录系统提示词实际渲染的确切内容。设计需要决定时间信息应归属何处、应以多高频率变化，同时避免累积陈旧读数或创建后台任务。
+
+## 决策
+
+`@deepseek-ai/dsh-time-context` 是位于 `packages/context/time-context/` 的可选函数式插件。它新增 `context/` 产品分组，用于容纳既不定义工具、也不定义服务边界的有界请求上下文增强。`dsh-agent-core` 和仓库提供的任何示例都不会加载该 package；只有当时间上下文值得占用 token 和披露信息时，部署方才显式挂载它。
+
+该插件注册一个名为 `context:time`、顺序值为 10 的全局 `ctx.systemPrompt.section()` 贡献，位置在部署方角色设定之后、工具指导之前。对于处于活跃轮次中的 agent，其提供方返回两行内容：一行是带数字 UTC 偏移和 IANA 时区、形似 ISO 的时间戳；另一行是从该轮次开始前最后一条模型可见消息起算的紧凑整秒时长。未绑定 agent 或 agent 处于空闲状态时，提示词组装结果中的该区段为空。
+
+### 上一条消息基线
+
+在轮次首次组装时，提供方从该轮次的 `turn/start` 向前扫描，采用最近的 `user/message`、`assistant/message`、`tool/result`、`context/message` 或 `steering/message` 时间戳。当前轮次中新追加的用户提示词会被刻意排除：若从该事件开始计时，首次请求会报告接近零的时长，从而丢失此功能要表达的轮次间隔。同一轮次内的后续刷新始终保留这条基线，因此长时间运行的轮次会报告从上一条会话消息起不断增加的时长。首个轮次报告 `unavailable (no earlier message in this session)`。
+
+基线采用会话事件的追加时间，而不是日志中不存在的客户端接收时间。这样，恢复和 fork 行为都能从持久日志中确定性重现，模型可见值也无需新增事件即可重建。如果系统挂钟向后调整，插件会将显示时长钳制为零，而不会产生负数间隔。
+
+### 刷新策略
+
+`refreshIntervalMs` 默认值为 60,000，并且必须是非负安全整数。每个轮次的首次请求都强制刷新，不受上一轮次时间戳影响。在包含多个步骤的轮次内，后续组装会复用缓存区块，直至其存在时间达到该间隔；设为 `0` 时每个步骤都刷新。该策略仅由请求驱动：agent 正在等待模型调用、运行工具或处于空闲状态时，没有请求会消费新值，因此计时器不会创建任何任务。
+
+`timeZone` 默认为 `UTC`，插件加载时会校验它是否为 IANA 标识符。格式化器会输出形似 ISO 的本地时间戳，其中包含已解析的时区及其当前数字偏移，使夏令时变化保持显式可见，而不是让不带时区的时钟在无提示的情况下发生偏移。
+
+### 日志与 token 形态
+
+时间区块属于动态系统提示词状态。agent loop（智能体循环）现有的 `request/header` 快照和 `request/header-delta` 折叠结果会在发送前记录每次渲染变化，从而满足[可重建请求契约](../architecture/2026-07-05-reconstructable-requests.md)。每个请求只携带一个当前区块；先前的读数不会保留在派生的会话历史中。该设计遵循[提示词变量 RFC](../architecture/2026-07-05-prompt-variables-and-tool-guidance-ownership.md)的所有权规则：可选插件拥有时间信息，并通过常规提示词注册表贡献该信息，不为循环添加特殊分支。
+
+## 测试
+
+该 package 的测试套件使用伪造的系统时间，覆盖 UTC 与偏移格式化、首轮次回退文本、所有符合条件的上一条消息类型、完整时长单位、挂钟回拨钳制、逐轮次刷新、间隔内复用、间隔到期、`0` 对应的逐步骤行为、相互独立的逐 agent 缓存、无效配置、HMR（热模块替换）资源释放以及 Loader 命名空间路径。一个使用真实 agent loop 的测试会固定实际发送的系统提示词及其 `request/header-delta` 刷新记录。默认快照不发生变化，因为所有仓库提供的组合都刻意不包含该插件；若在默认快照 fixture 中挂载它，将违反显式选择加入的决策。
+
+## 考虑过的替代方案
+
+- **每个轮次或每次刷新都追加一条 `context/message`**——不予采纳：每个读数都会留在派生历史中，因此陈旧时钟值和 token 成本会随会话长度累积。表层替换操作无法同时删除旧节点并将新读数移动到尾部；替换会保留旧节点的位置，而通过尾部节点替换又会隐藏中间的会话内容。
+- **使用 `agent/session-prefix`**——不予采纳：前缀在每个循环实例中只组装一次，并且按设计在会话期间保持稳定，因此无法表示每个轮次或步骤都会变化的时钟。
+- **在 `agent/request` 中修改请求**——不予采纳：该边界只负责塑造调用配置，触发时间晚于消息边界；如果在此处插入模型可见内容，会同时绕过提示词压力核算和请求头日志契约。
+- **注册独立的 `{{current_time}}` 和 `{{elapsed}}` 提示词变量**——不予采纳：两个独立提供方可能在不同时间点采样，并且需要共享缓存才能保证刷新语义的原子性。单个区段提供方将二者作为一个值计算和记录；部署方也不需要在角色设定中重复时间模板。
+- **按照配置的间隔通过后台计时器注入**——不予采纳：没有正在组装的模型请求时，新值没有消费方。由计时器驱动 `agent.inject()` 会创建持久的一次性轮次，并且只为通知时间流逝就唤醒或修改空闲会话。
+- **在 `dsh-agent-core` 中挂载插件**——不予采纳：时区、信息披露、token 预算和期望新鲜度都属于部署策略。显式选择加入能保持默认 harness 上下文稳定。
+- **将 package 放入 `core/`**——不予采纳：core 负责产品 API 主干。上下文增强是没有服务键的可选叶节点，因此专用分组能直接表达其组合角色。
+
+## 后果
+
+- 选择加入的部署无需消耗工具调用，即可让模型获得无歧义的分区时钟和轮次间隔时长。每个请求的系统提示词 token 成本固定，不会随会话增长。
+- 刷新会改变请求头，因此会新增一条 `request/header-delta` 事件。`refreshIntervalMs` 用时钟新鲜度换取这些持久增量记录的数量；将其设为零会在每个整秒渲染结果发生变化的步骤中刻意记录新值。
+- 系统不会仅为刷新时间而创建请求。工具运行时间超过该间隔时，先前读数会保持不变，直至下一步骤开始组装，此时提供方会追赶到当前时间。
+- 时长反映持久追加边界处的 harness 处理时间，不包含消息进入日志之前的客户端网络延迟。若要保留客户端来源时间戳，需要单独的持久输入契约，不属于本插件范围。