Reports

A report is what a room produces: a thread of blocks captured by the reporter, stored against a project and a channel. It’s not a single text field — it’s an ordered list of pieces the reporter assembled before sending.

Blocks

Each report holds a blocks array. Every block is one of four kinds:

Block	What it captures
text	A written message.
screenshot	A captured image of the page.
audio	A recorded voice note.
selection	A quote of text the reporter highlighted on the page, plus the element it came from.

A room can mix these freely — for example a text block describing a bug, a screenshot showing it, and a selection pointing at the exact element. A report must contain at least one block.

Block limits

The blocks are validated on the way in, so reports stay bounded:

• text — up to 10,000 characters per block.
• selection text — up to 2,000 characters.
• screenshot — up to 2 MB, image/png or image/jpeg.
• audio — up to 10 MB and 5 minutes, audio/webm or audio/mp4.
• A report holds between 1 and 50 blocks.

Note

Screenshot and audio bytes aren’t stored in the report document itself. Each binary block references a stored blob (uploaded to object storage), and the block carries its dimensions or duration alongside the reference.

Status

Every report has a status for triage. The statuses are:

• new — the default for a freshly received report.
• triaged
• in-progress
• fixed
• verified
• canceled

Context

Alongside the blocks, a report can carry context about where it came from — captured automatically by the widget when available:

• the URL the reporter was on,
• the user agent and viewport size (rendered in the dashboard as e.g. Chrome / desktop / 1440×900),
• recent console errors, if the SDK’s error hook was enabled,
• arbitrary extra fields the host app attaches.

This context is what makes a report actionable without a back-and-forth: you can see the page, the browser, and the failing console output in one place.

Author

A report can carry an author — who filed it. It’s derived automatically from whatever identity signal came with the submission (an OAuth reporter, a typed email, a verified identity token, a browser’s anonymous device id, or — for reports filed through the MCP server — the calling agent). See Reporter auth for the full priority order. A report with none of those signals has no author.

In the dashboard, each report card shows its author’s label, and the report list has an author filter — a dropdown of every author who has filed in the project, each with a count — plus a Mine toggle that narrows the list to reports tied to your own dashboard identity.

Read tracking

The dashboard tracks, per report, who has viewed it — independent of the report’s status. Opening a report marks it viewed for you; each report card shows an eye icon with a viewer count, and hovering it lists who viewed (up to three names, then “+N more”). Reports you haven’t opened yet show an unread dot. Reports filed through the MCP server get the same treatment on the agent side: list_reports and get_report auto-mark whatever they return as viewed by the calling agent, so agents build up their own read history too.

Reports arrive in real time

When a report is received, the dashboard’s feed updates live — you don’t need to refresh to see a new report land in its channel.