Loop and system messages carry createdAt but never render it — and elapsed-between-steps is the number that matters

[serge-ivo]

The report

Why don't loop messages have timestamps? What are they designed to portray? Why are they a
different colour?

The colour is deliberate and defensible. The missing timestamp is a gap, and it matters most for
exactly these messages.

What they are

Loop entries — **Loop → engine** (step 3): …, **Loop complete** — are role: "system", the
same channel as Error: …, "No response", and interrupted-turn notices. They exist because the
platform, not the browser, drives autonomous work (InstanceDetail.tsx:369):

The console used to BE the loop: poll /loop-decide, send the next instruction. That died with
the tab and could not be budgeted, because the platform did not drive it. Now the workflow drives
and this only reports.

So they are the audit trail of work that ran whether or not anyone was watching. That is why they
belong in the thread rather than a log.

Why the colour differs — this part is right

:1082: yellow, centre-aligned, pill for short entries and a bordered block for long ones. Three
distinct channels:

you	accent, right
assistant	panel, left
system	yellow, centre

Centre + yellow reads as "neither of you said this — the platform is reporting". Worth keeping.

Why there is no timestamp

The time is rendered inside a header row that exists for two roles only:

:1104   {m.role === "user"      && <div …>You … {formatDateTime(m.createdAt)}</div>}
:1105   {m.role === "assistant" && <div …>Assistant … {formatDateTime(m.createdAt)}</div>}

There is no system branch, so no header, so no time — even though createdAt is on the record and
formatDateTime is already imported.

Why that is backwards for loop entries specifically

A user or assistant message is bounded by the ones around it; you roughly know when you said it. A
loop entry reports work that ran on its own schedule, minutes apart, often while you were
elsewhere. In a real FWS thread, **Loop → engine** (step 3) and (step 4) were 2m20s apart
and nothing on screen said so.

The two facts a reader actually wants from an autonomous run are when and how long between
steps, and the transcript currently shows neither.

Proposal

• Render createdAt on system messages, in the user's timezone (Agents report timestamps in UTC because nothing ever told them the user's timezone — and no prompt has a clock #329 — right now the only times
  visible anywhere are the UTC strings the agent puts in prose).
• For loop entries, show elapsed since the previous entry as well. "step 3 → step 4: 2m20s" is
  the scanning signal; an absolute clock time is not.
• Keep it visually quiet — these are centred pills, not bubbles with headers. A right-aligned
  text-[0.65rem] opacity-70 inside the pill is probably enough; a full header row would fight the
  shape.

Verification

• A system message shows its time; a loop entry also shows the gap since the previous one.
• Times respect the user's timezone once Agents report timestamps in UTC because nothing ever told them the user's timezone — and no prompt has a clock #329 lands, and never render UTC.
• Short pills stay one line at 390px — this must not reintroduce the mobile overflow of [bug] Profile still scrolls sideways on mobile — the roles row can't wrap, and the e2e guard only counts scrollable elements #333.

[serge-ivo]

Done in 1e4c7f1.

System rows moved to store/console/src/components/SystemMessage.tsx. The colour and centring are unchanged — they are right. Each row now renders, right-aligned and quiet inside the pill: the gap since the entry above (+2m20s) and the absolute time from the same formatDateTime the user and assistant headers use. Both come from lib/messageStamp.ts (pure, tested): SQLite-UTC normalisation, a compact duration format (45s / 2m20s / 1h04m / 3d2h), a 2s noise floor so several rows written in one tick don't claim a pause, and no negative gaps. Locally emitted notices are stamped client-side too — a persist:false adopted-run line is never written to the DO, so a refresh would never hand one back with a createdAt and it would have been the one row with no time.

Timezone — read this before #329 lands. The stamp renders in the browser's LOCAL zone, because that is what every other timestamp in the console already does; rendering the two channels in different zones would be a worse defect than the missing timestamp. So a run can currently show "started at 22:33:34 UTC" in the agent's prose above a header saying 8:33 AM. That reconciliation is #329's, and its design (format tool output in the user's zone at the SOURCE, server-side) makes both halves local without this component changing — no console change is needed there. title names the zone on hover in the meantime, so a reader comparing the two clocks can tell which is which. Not in the pill itself: that costs width the 390px layout does not have.

Mobile: short pill + stamp is a flex-wrap row, so it stays one line at 390px and drops to a second line rather than pushing the page sideways; the content div carries min-w-0 break-words so an unbreakable token (a URL in an error) wraps (#333).