feat: give the turn a clock #917

Merged

coilysiren merged 1 commit from issue-855-turn-clock into main

2026-08-17 18:25:59 +00:00

coilyco-ops commented

2026-08-17 18:21:13 +00:00

Member

One system message, directly under the local policy, states the current moment and its Unix epoch.

The narrow version, as the issue framed it

No new egress and no MCP round trip. ProxyClient.Now is the turn's only clock, nil meaning the wall clock, and it is read once per turn rather than once per round, so two tool rounds inside one answer cannot disagree about what time it is.

The message states the fact and nothing else. Rendering <t:EPOCH:STYLE> is what discord-timestamps already explains, and #851 verified that resource now reaches Echo, so repeating it here would duplicate a live instruction. The issue's own framing: rendering a known epoch and knowing the current epoch are separate capabilities. This supplies the second.

Placement

Directly under prompt.System, above server guidance and grounding. It is a fact about this turn rather than reference material a server published, and groundingMessage deliberately labels its contents as data rather than instruction, which is the wrong frame for a clock.

Untouched

Timezone conversion for a named city. It needs a tz database rather than a clock, and whether it belongs in Echo at all is a separate decision. Discord still exposes no member timezones, so turning "Saturday 8pm" into an epoch still needs the speaker to say which zone they mean.

Tests

turnclock_test.go: the turn carries a readable time and an epoch in a system message at the expected position, and the clock is read exactly once across a turn that runs a repair round.

Seven existing tests index prompt messages by position and shift by one. No assertion changed subject. The rendered-prompt snapshots are unaffected, since this is a per-turn message rather than definition material, and just prompt-check passes.

just gate PASS.

closes #855

One system message, directly under the local policy, states the current moment and its Unix epoch. ## The narrow version, as the issue framed it No new egress and no MCP round trip. `ProxyClient.Now` is the turn's only clock, nil meaning the wall clock, and it is **read once per turn rather than once per round**, so two tool rounds inside one answer cannot disagree about what time it is. The message states the fact and nothing else. Rendering `<t:EPOCH:STYLE>` is what `discord-timestamps` already explains, and #851 verified that resource now reaches Echo, so repeating it here would duplicate a live instruction. The issue's own framing: rendering a known epoch and knowing the current epoch are separate capabilities. This supplies the second. ## Placement Directly under `prompt.System`, above server guidance and grounding. It is a fact about this turn rather than reference material a server published, and `groundingMessage` deliberately labels its contents as data rather than instruction, which is the wrong frame for a clock. ## Untouched Timezone conversion for a named city. It needs a tz database rather than a clock, and whether it belongs in Echo at all is a separate decision. Discord still exposes no member timezones, so turning "Saturday 8pm" into an epoch still needs the speaker to say which zone they mean. ## Tests `turnclock_test.go`: the turn carries a readable time and an epoch in a system message at the expected position, and the clock is read exactly once across a turn that runs a repair round. Seven existing tests index prompt messages by position and shift by one. No assertion changed subject. The rendered-prompt snapshots are unaffected, since this is a per-turn message rather than definition material, and `just prompt-check` passes. `just gate` PASS. closes #855

coilyco-ops added 1 commit

2026-08-17 18:21:13 +00:00

feat: give the turn a clock

ci / image-build (pull_request) Successful in 32s

Details

ci / test (pull_request) Successful in 59s

Details

ci / publish-echo-image (pull_request) Has been skipped

Details

ci / publish-observed (pull_request) Has been skipped

Details

fd6f929ed9

Echo had no access to the current time. No system prompt material named it,
no tool in the roster reported one, and every time.Now in internal/community
is runtime bookkeeping the model never sees. So "what time is it in Paris" had
no answer available, and neither did any question of the form "how long ago
was X" against a wall clock.

One system message directly under the local policy states the moment and its
Unix epoch. That is the narrow version the issue asked for: no new egress, no
MCP round trip. It is read once per turn rather than once per round, so two
tool rounds inside one answer cannot disagree about what time it is.

The message states the fact and nothing else. Rendering <t:EPOCH:STYLE> is
what the discord-timestamps resource already explains, and that resource now
reaches Echo, so repeating it here would duplicate a live instruction.

Timezone conversion for a named city is untouched. It needs a tz database
rather than a clock, and whether it belongs in Echo at all is a separate
decision.

Seven tests index prompt messages by position and shift by one. No assertion
changed subject.

closes #855

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>

coilyco-ops requested review from coilysiren

2026-08-17 18:21:13 +00:00

coilyco-ops referenced this pull request

2026-08-17 18:21:33 +00:00

Echo has no clock, so no question about the current time can be answered #855