Workflow tool: stamp journal.jsonl records with a writer-side timestamp (ts)
Context
The Workflow tool writes each run's journal to <transcriptDir>/journal.jsonl with records shaped like:
{"agentId": "...", "key": "...", "type": "started"|"result", "result": {...}}
Records carry no timestamp. Consumers that must order or select journals by recency (for example, tooling that keys off "the freshest journal describing a given tree") have no intrinsic time to read and fall back to the journal file's filesystem mtime.
mtime is a weak proxy: a bare touch, an rsync without --times, a backup sweep, or restoring/resuming a session can reorder mtimes with no new run occurring — silently changing which journal such a consumer selects.
Ask
Stamp records writer-side at emit time:
{"ts": 1755900000, "agentId": "...", "key": "...", "type": "result", ...}
- Epoch seconds is fine (ISO-8601 also fine).
- Additive field — existing consumers unaffected.
- Ideally on all record types (
startedandresult), so a partially-written journal still self-reports its start time.
Why writer-side matters
Consumers cannot derive this after the fact: once multiple runs' journals describe the same artifact, only the writer knows when each record was truly emitted. File mtime is the only signal today, and it is trivially reordered.
Workaround in use (why this still matters to us)
We embed a ts inside our structured result payloads (our agents stamp their own outputs), which covers post-change records — but started records and journals written before that change still force the mtime fallback.