Working with reports
The inbox, the five statuses, comments, and what the reporter sees.
The inbox
One per project, newest first. Open items by default; All includes resolved ones.
Each line carries enough to triage without opening anything: the page, the browser, how long ago, and how many JavaScript errors or failed requests came with it.
The report
Everything the reporter did not type, laid out in the order you would ask for it: the screenshot with the element outlined, the selector and its text, the full environment, the JavaScript errors, every failed request with status and timing, and the console.
Statuses
The reporter sees the same five steps as a timeline on their status link, so "is anyone looking at this?" stops being an email.
Comments
Two kinds, chosen with a checkbox:
- Visible to the reporter — appears on their status link and is emailed to them
- Internal — stays with your team
The reporter can reply from their link. Their replies come back into the same thread.
Sent automatically, never more than needed:
| When | Who gets it |
|---|---|
| A report is filed | The reporter, with their status link |
| A reporter-visible comment is added | The reporter |
| Status becomes Resolved | The reporter |
A failed email never fails a report — the report is the thing that matters.
Who can see what
Reports belong to the project, projects belong to a workspace, and every view re-checks that you are a member of it. Being sent a report's internal URL is not enough to open it.
The one public surface is the reporter's own /r/<token> link.