Issues & triage

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 or more Projects or spans them all, and splits into Open, Closed and — once anything is muted — Muted. Two more pickers narrow it further: All environments, which lists the environment names of the Projects in scope once they carry at least two distinct ones — grouped by name, so Production spans every Project's Production — and All platforms — Browser, Server or Mobile — once your Issues come from more than one. The dashboard remembers your choices per workspace. The Project scope is one choice across the app: pick two Projects here and Runs opens on the same two.

A row carries the Issue's title beside a dot coloured by its Kind, then its key, the platform it ran on when that is the server or mobile (a browser Issue is unmarked), its occurrence count once there is more than one, a quiet marker when analysis thinks it duplicates something already open, and its age. A chip beside the title says what became of it — shipped, resolved, dismissed or duplicate; a plain open Issue has none. A bold title marks an open Issue you personally haven't opened; it is a per-Member receipt, so reading one changes nothing for your teammates.

A row reading Brief paused (spend cap) belongs to a workspace whose spend gate is closed. The Issue is still filed with its Evidence, grouped with repeats of the same error and pointed at its code area — only the model-written parts wait. Its Report says why and names the Owners who can lift the pause, and the Brief is written on its own once the gate reopens.

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 Report. The tabs beside it are the raw material the Brief was written from; Replay and Trace show only when the Issue captured one:

• Report — the Brief, the Markdown write-up analysis produced, beside an evidence rail: the reporter's own words and every screenshot they grabbed, with their marks drawn on it (Expand opens it full size). An Issue the SDK filed on its own reads Captured automatically there instead, and its Brief column leads with the error. Once work is linked, or the Issue has an Activity trail, the rail also carries Linked work and Activity — see GitHub & the return path.
• Replay — the moments before the report, as far back as the Project's replay window reaches, played back from a masked DOM recording (a video on mobile). A timeline rail beside the player moves with it, so you can watch what was logged at the moment the reporter clicked, and clicking a row scrubs to it.
• Trace — console and network on one timeline, in the order they happened, narrowed with All / Network / Console. Console lines keep each argument as a typed value rather than flattened to a string, and warnings and errors are pinned against eviction, so a burst of chatter can't bury the one line that mattered. A request shows its method, scrubbed URL, status, timing and a failure classification; never a header value. Bodies are off by default; when a Project turns on body capture for the web SDK, an expanded request also shows the payload it sent and the response it got, each marked captured. A backend Issue's failing request — route pattern, method and status — is a row on the same timeline, under Network.
• Properties — the facts about the Issue, below.

A request to your own backend also shows its Correlation id — the same id the server Issue for that request shows, when the backend runs @fixback/node — and the two Issues link to each other: the request is marked with the server error behind it, and the server Issue lists the reports and page errors it was seen from, each with its replay to watch. The link is exact, never a guess, and holds across Projects of one workspace.

The header carries a work-status chip once work is linked, summarising the latest of it: Branch pushed, PR in review, Shipped — Shipped · Live once your CD deploys it — or PR closed. It reads the work, not the Issue, so a dismissed Issue with no work shows none.

The Properties tab

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 most similar of the Project's open Issues — by what was reported, and for a captured error by its name, message, top stack frames, and failing request — and may attach a duplicate suggestion with a one-line rationale. Two Issues carrying the same error fingerprint (the same crash seen on staging and then in production, say) are suggested to each other without a model in the loop. 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: Hand off or Ship

The Issue detail's primary action is a split button. Its blue half runs the default handoff action; its chevron lists all three ways to turn a Brief into a PR, with the default marked Default:

• Open in Claude Code (cloud) — the platform default, on the button as Hand off. It opens the composer with the repo selected and the prompt filled in, on your own subscription.
• Copy prompt — the same prompt, to paste into any other agent.
• 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.

An Owner sets the workspace's default in Settings → Automation, and any Project can override it under Repository & ship → Hand off button; a Project left on Workspace default follows the workspace. The choice only decides which action leads — the other two stay in the menu. If the default is Ship it and an Issue can't Ship yet, the button says why, or links to the setup that unblocks it, rather than running something else.

Whichever you pick, 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.

When the Issue is linked to the other side of one of its requests — a page's report or error and the server error behind it — the prompt carries both halves: it names the other Issue's key and fences what that side captured, the server's error, route and stack beside the page's trace, or the page's request and the reporter's words beside the server's. The Brief connects them too, and if the link arrives after the Brief was written, the Brief is rewritten once to include it — unless you edited it yourself.