feat(signals): show the task summary as a tooltip on inbox report run rows #104500

Summary

Show the agent-written task summary as a tooltip on each row of the Runs section of an inbox report, when the run has one. First user-facing surface for the summary primitive from #94290, deliberately the smallest one: hover the run label, read what the agent says it did.

Why

Since #94362 (backend) and #95970 (harness tool) landed, cloud agents keep a short running summary on their task run (task_summary on the run state, replaced on every write, capped at 1500 characters). Agents call the tool once per turn, as the last tool call before ending the turn, so the text reads as a completion report: goal, outcome, branch and PR, what was verified, what a human still has to do.

Nothing shows it to a person yet. In the inbox report detail, the Runs section lists the report's linked tasks (Implementation, Research, Scout) with a status dot and a chevron that expands the full run transcript. Anyone who wants to know what a run did has to expand and read the transcript. A tooltip with the summary answers "what did this run do" without that.

Shipping the smallest surface first also tells us whether the summaries are good enough to put somewhere more prominent (the desktop task row, follow-up runs, task search) before building those.

What the data already gives us

No backend or schema work is needed:

• The Runs section loads each linked task through GET /api/projects/:id/tasks/:task_id/. Its latest_run is rendered by TaskRunDetailSerializer, which already includes task_summary (the run's own summary, or the one inherited from the previous run of the same task).
• The generated frontend type TaskRunDetailDTOApi carries task_summary: string | null, and Task.latest_run is typed as that shape, so every row already has entry.task.latest_run?.task_summary in memory.
• Workflow-origin redaction is applied server-side, so the frontend can render whatever it receives.

Proposed change

All in products/signals/frontend/inbox/components/detail/ReportTasksSection.tsx:

1. In TaskRow, read entry.task.latest_run?.task_summary.
2. When it is a non-empty string, wrap the purpose label (Implementation, Research, ...) in a LemonUI Tooltip whose title is the summary. Cap the tooltip width and let the text wrap and keep line breaks (summaries are plain text or light markdown and can run to 1500 characters). Render the summary as text, not markdown, for this first pass.
3. When there is no summary, the row renders exactly as today. No placeholder, no "no summary yet" copy.
4. Capture one event when the tooltip opens, signals_report_run_summary_viewed, with report_id, task_id, run_id, purpose (the row's label) and summary_length. Without it the trial produces no signal beyond complaints.

Out of scope, on purpose: showing the summary inline under the label, putting it at the top of the expanded transcript, any change to the activity-log task_run artefact rows, and the desktop task row hover (tracked separately under #94290).

Things to know

• Most rows will not have a summary yet. Implementation runs write one on most turns. Research runs are multi-turn structured-output sessions that end every turn on a JSON finding envelope and rarely call the tool, and scout rows are pipeline-internal. Expect the tooltip mainly on the Implementation row. A low hover count is not a signal of low interest.
• It is the latest run's summary. A task that was re-run shows the newest run's text, or the inherited prior-run summary when the newest run has none. The expanded transcript follows the same latest-run rule, so the two stay consistent.
• Summaries are self-reported and optimistic. They are for "what was this about", not for judging run quality. The tooltip should not imply verification.
• Copy rules: sentence case, no em dashes, plain language (see /writing-user-facing-copy).

Acceptance

• Hovering a Runs row whose latest run has a summary shows the summary in a tooltip, wrapped, readable at the narrow widths the detail pane gets next to the side panel.
• Rows without a summary are unchanged.
• One signals_report_run_summary_viewed event per tooltip open, with the properties above.
• A Jest test on ReportTasksSection covering both the with-summary and without-summary rows.
• Storybook or a screenshot of the tooltip on a report with an Implementation run.

Context

• Spec for the primitive: feat(tasks): agent-maintained task summary so you can drop into a task without re-reading it #94290. Backend: feat(tasks): let the agent keep a running task summary #94362. Harness tool and prompt: feat(tasks): let cloud agents keep a running task summary #95970. Sandbox agent pin bump that made it live: chore(tasks): bump sandbox @posthog/agent to 2.4.208 #104347.
• Origin thread: https://posthog.slack.com/archives/C0C1T3V1RJA/p1789638920497979

Update: the discussion rows are the primary target

The rows worth doing this for are the Ask AI discussion runs on a report (ai_stage = inbox, interactive), where the summary is a recap of the conversation. Implementation rows already write summaries most of the time; discussion rows almost never do today.

A live check on 2026-09-22 showed why. In a fresh discussion run on agent 2.4.208 the agent answered the question with nine tool calls and ended the turn without calling task_summary_update. Asked explicitly in the next message, it called the tool, the call succeeded, and the stored summary was a good two-sentence recap of the exchange. So the tool is available and allowed in these runs; the nudge at the end of the cloud system prompt is what does not fire for a chat answer.

Two consequences for this issue:

• The tooltip is still the right first surface, but it needs the write side to hold up on discussion runs. Enforcing the summary at turn end for cloud runs (for example a Claude Code Stop hook that blocks once per turn when no summary was written, or a chat-shaped rewording of the nudge) is a prerequisite for the tooltip being useful on discussion rows. That work is separate from this issue and should land first or together.
• Acceptance gains one row type. The Jest test and the screenshot should cover a discussion run row (purpose label Signals: Discussion) as well as an implementation row.