#61 analytics: attach turn latency + shape metrics to message_sent

[Anonymous]

Originally created by: sosidudku1

Why

We have no visibility into response cost in product analytics — neither how slow nor how heavy turns are — so we can't tell whether slow or complex turns drive drop-off. This adds three content-free "shape" metrics to the existing message_sent event.

What

New optional fields on message_sent (each omitted when unmeasurable; none ever attached to first_message_sent):

Field	Meaning
latency_ms	Wall-clock turn duration (submit -> final assistant response).
step_count	Number of agent steps taken — a proxy for how much work the turn required. From RunTurnResult.stepCount.
outcome	How the turn ended: reply / finish / max_steps / cancelled / failed. max_steps means the reply was cut off by the step budget.

How

• Extend MessageEventContext with optional latencyMs / stepCount / outcome; captureMessageSent spreads each in only when present.
• In runTurn, time the turn around turnController.enqueue. On success, emit latency + result.stepCount + result.reason; on throw, emit latency + outcome: "failed" (no result to read), then rethrow. The emit moved from before the turn to after it, so duration and outcome are observable — the same "fires on success or failure" guarantee as before.
• Scheduler-origin turns remain excluded, exactly as before.

Privacy

Unchanged in spirit: the event still carries only provider / model plus these numeric/enum shape fields — no message content, file paths, tool arguments, or any user data. The event doc comment is updated to match. Respects the analytics opt-out (no-ops when disabled).

Notes for review

• Metric is whole-turn wall clock (including tool steps), not time-to-first-token. Sufficient for the "are we slow?" question; TTFT would need streaming hooks.
• The post-turn emit means that for the very first message, first_message_sent now also fires after the turn — believe this is fine (arguably more correct), flagging since it's a semantic shift.
• Deliberately not sending token counts or tool-call counts yet — those live inside the loop and aren't on RunTurnResult. Happy to surface them as a small follow-up in agent-loop.ts if wanted.

Verified locally

• tsc --noEmit clean.
• src/analytics/ tests: 26/26 pass (added 2 asserting the metrics land on message_sent and stay off first_message_sent).

⚛️ Generated with Atomic Agent

[Anonymous]

Ticket changed by: Ooooze

• status: open --> closed