The dashboard

Issues & triage

The queue is where you actually work. Every Feedback that arrives becomes an Issue with a title, a Kind and a Brief already written, and this page covers what you can do to one from there.

Issue keys

Every Issue has a short, human key — FIX-140 — made of its Project's key and a per-Project serial number. It is what the queue, the detail page, the URL, the Handoff prompt and the reporter's "your report is fixed" email all show, and what the GitHub linkage convention accepts.

The key is composed over a stable UUID rather than stored, so editing a Project's key in its settings re-labels its Issues immediately, with no migration. Numbers never repeat within a Project and are never reused.

The queue

The queue scopes to one Project or spans them all, and splits into Open, Closed and — once anything is muted — Muted. A row carries the Issue's title and key, its Kind, whether a human reported it or the SDK captured it, the platform it ran on, its Project, its occurrence count once there is more than one, and a quiet marker when analysis thinks it duplicates something already open. An unread dot marks Issues you personally haven't opened; it is a per-Member receipt, so reading one changes nothing for your teammates.

The sidebar's Saved views are lenses over that same queue:

All open — everything still to decide on.
Duplicates — open Issues carrying a suggestion nobody has merged or dismissed yet.
Recurring — the high-occurrence Issues: one bug, many people.
Shipped — what has already gone out.

Views add no stored state. They derive from the Issue's state, its Labels and its occurrence count, which is why an Issue can appear in several at once.

The Evidence tabs

An Issue opens on its Brief — the Markdown write-up analysis produced from everything else it carries. The remaining tabs are the raw material it was written from:

Replay — the 30–60 seconds before the report, played back from a masked DOM recording. Scrubbing the rail moves the console and network streams with it, so you can watch what was logged at the moment the reporter clicked.
Console — every level, with each argument kept as a typed value rather than flattened to a string. Warnings and errors are pinned against eviction, so a burst of chatter can't bury the one line that mattered.
Network — every fetch, XHR and beacon with method, scrubbed URL, status, timing and a failure classification. Metadata only: never a body, never a header.
Annotation — the element they pointed at, their drawing, and the still reconstructed from the replay, masked before it was ever recorded.

A backend Issue gets one thing more. Its Brief tab carries a server context panel — the route pattern, method, status and deploy environment of the request that failed — laid out like a captured request so it reads the same way. Browser and mobile Issues simply don't render it, and the tabs are otherwise identical whatever the platform.

The properties rail

Property	What it tells you
Status	Open or Closed — the only two states an Issue has. Everything else is a Label or a marker.
Kind	bug / improvement / idea, written by analysis and correctable by you.
Reporter & tier	Who filed it, and the tier they held at that moment — Internal, Invited, or Public.
Source & Platform	Whether a human reported it or the SDK captured an error, and where it ran: browser, node, or expo.
Handled	On a captured error: false for an uncaught crash, true for a captureException in a catch block.
Environment & Release	The deploy environment and build the report came from — both SDK init options.
Code area	The original file, line and function, symbolicated through the release's uploaded sourcemaps.
Page URL, browser, viewport	The environment info the SDK captured, scrubbed before it left the page.

Triage

An Issue is only ever Open or Closed. The actions on it are deliberately few:

Resolve — closed, fixed. The close reason is a Label, not a state.
Dismiss — closed, not doing it.
Reopen — back to Open. Reopening an Issue that was merged into another detaches it first.
Mute — silence it without deciding. See below.
Assign — a Member owns getting it Shipped or Closed. Ownership, not automation.
Label — your own freeform labels, alongside the system ones analysis writes.

Mute

Mute silences an Issue without resolving it — the "I know, stop telling me" action. A muted Issue stays Open and triageable, but sends no Alert and drops out of the default queue into the Muted lens. It is shared across the workspace, the way closing is, because it is a triage decision rather than a personal preference. Unmute clears it.

Duplicates

When a new Issue is analysed, a cheap dedup pass compares it against the Project's open Issues and may attach a duplicate suggestion with a one-line rationale. A suggestion never merges anything — it appears on both Issues and waits for you.

Merge folds the duplicate into the canonical Issue: the duplicate closes with the duplicate reason, and its occurrences and reporters count on the canonical one.
Not a duplicate dismisses the pair, and analysis never suggests it again.
Detach reverses a merge: the duplicate reopens on its own and the canonical gives back its share of the count.

Merging is always one level deep — merging an Issue that had absorbed others re-points them at the new canonical.

Acting on an Issue: Ship or Hand off

The Issue detail's primary action is a split button with two ways to turn a Brief into a PR:

Ship it starts a Run — a Fixback-hosted agent takes the Issue and drives it to a PR itself, as far as your trust policy allows. See Runs & Ship.
Hand off is the bring-your-own-agent action: Open in Claude Code (cloud) opens the composer with the repo selected and the prompt filled in, or Copy prompt for any other agent.

Either way the prompt is assembled from the Brief, the Evidence and the code-area pointer, with the reporter's own words fenced as data rather than instructions. When the Project has a connected repository it carries the linkage convention, so the branch and PR find their way back — see GitHub & the return path.