Glossary

The core chain

Feedback

A single raw submission from a Reporter — their comment plus the captured session Evidence. It can be reporter-authored, or a captured error the SDK files with no one pressing Send. Bugs, improvements, and ideas are all Feedback.

Issue

The enriched, queued work item. Every Feedback becomes an Issue; an Issue holds several Feedback only after a Member merges duplicates (captured errors with the same fingerprint in the same environment fold into one Issue with an occurrence count). An Issue is either Open or Closed.

Issue key

An Issue's short, human identifier — FIX-140 — its Project's key joined to a per-Project number. It is what the queue, the URL, the Handoff and the reporter's email show, and what the GitHub linkage convention accepts.

Kind

The label classifying an Issue as bug, improvement, or idea. Written by analysis, correctable by Members.

Title

The short, scannable line naming an Issue — written by analysis from the Evidence, with a fallback to the reporter's first line until it does.

Brief

The analysis-authored write-up on an Issue: a Markdown finding — summary, repro steps, expected-vs-actual, key signals, and (for improvements) a suggested approach. A Run's prompt is built from Brief + Evidence.

Label

A tag expressing everything an Issue's two states don't. System labels (Kind, and the close reasons resolved / dismissed / duplicate) are typed and permanent; project labels are yours to create.

Duplicate suggestion

An analysis-written link marking two open Issues as probably the same problem, with a one-line rationale. It never merges anything — only a Member merges, or dismisses the pair as not a duplicate.

Source & Platform

Provenance stamped on every Feedback: Source is what kind of signal it is (reporter or error); Platform is where it ran (browser, node, or expo). Both are server-derived.

Handled

On a captured error: false for an uncaught crash, true for a manual captureException in a catch block. A severity hint the Brief can weigh; unset for reporter Feedback.

Linked work

The GitHub work an Issue is linked to, observed read-only through webhooks: one entry per branch, carrying the PR once one exists, its state (branch / PR open / merged / closed), and a Live marker once your CD deploys it.

Activity

The append-only trail of return-path events on an Issue: branch pushed, PR opened, merged, closed, deployed, auto-closed, reporter notified. It records what happened; it is never a state machine.

Run

One agent execution attempt against an Issue: clone → locate → implement → tests → PR → merge. A status/stage/conclusion aggregate with an append-only Run event log, its own human key (RUN-1), a live log, a change summary, its PR link and cost. The dashboard splits active (queued / provisioning / running) from waiting (stopped at a human gate). An Issue can have several Runs — a retry is a new Run.

Run event

One entry in a Run's append-only event log — a stage starting or finishing, agent text, a command or file change, a gate opening, an error, the result. The live stream tails it by a per-Run seq cursor; the dashboard timeline is a projection of it, never a second state machine.

Captured data

Session

A Reporter's continuous recorded visit on your site or app, as observed by the SDK.

Trace

The ring-buffered window of a Session that ships with a report: all-level console output, errors, every network request (failures flagged), and the click trail — a bounded lead-up window, not a full recording. The server merges its streams into one exact timeline.

Replay

The buffered DOM recording of the 30–60 seconds before a report, masked in the page and stored as its own Evidence blob. Scrubbing its rail moves the merged Trace timeline with it.

Annotation

The reporter's markup at submission time: a selected element, a captured region, drawings, and comments.

Evidence

The complete package an Issue carries and a Run consumes: Trace + Annotation + environment info — plus server context (route pattern, method, status) for a backend error.

Correlation id

The per-request id the browser or mobile SDK mints and sends with a request as the W3C traceparent header, which @fixback/node adopts as the request's id — so a server error and the page request that caused it share one key. Random; it identifies a request, never a person.

Walkthrough

One narrated, recorded pass over a site — talking while picking and circling what you mean, across pages — that Fixback transcribes and cuts into one Issue per thing raised, each with your words as its comment.

Release

A version string naming one build of your app, stamped into every Feedback. Sourcemaps are keyed by Release, so a stack is symbolicated against the exact build that produced it.

Sourcemap artifact

One uploaded sourcemap, keyed by Project, Release and bundle path, sent by the Vite plugin or the CLI. The only repository-adjacent input analysis ever reads — Fixback never clones your repo.

Code-area pointer

The likely original source location (file, line, function) mapped from a captured stack trace through the Release's uploaded sourcemaps.

Analysis model

The workspace-level choice of which model writes Briefs, from a curated catalog — or the platform default. Owner-only to change; models that can't read images skip the screenshot.

People & access

Account

A verified sign-in at Fixback — one human, one email, independent of any workspace or Project. The same Account can be a Member in one place and a Reporter in another.

Reporter

A person who submits Feedback on one Project. Every Reporter has one trust tier — Internal, Invited, or Public — derived server-side on every submission, never self-declared.

Member

An Account holding a Role in a workspace — the one who scans the queue, sets policy, and clicks Ship.

Role

A Member's authority: Owner (administers the workspace, its Members and its billing) or Collaborator (full product access). Two roles only, deliberately.

Gate

An Environment's submission policy: Open (anyone), Invited (Invite-holders and Members), or Internal (workspace Members only). Resolved from the key a submission presents, never from anything the client declares — so staging can be Open while production stays Invited or Internal.

Allowed origins

The sites a Project accepts browser Feedback from, and the app links a Connect may return to, listed under each environment's Access → Sites and apps. A site is scoped to one environment or covers all of them, so an Open staging key is inert from the production site. A filter on a presented origin, never a demand for one: a mobile or backend install needs no entry.

Invite

A Fixback-issued link admitting an Account to a Project as an Invited Reporter — targeted to one email, or a shared, revocable link. It is claimed by signing in on the platform, which lands the person in Sites and Connects them to the site.

Member invitation

An Owner's invitation for someone to join the workspace, carrying the Role they arrive with. Distinct from an Invite, which is a Reporter concept.

Connect

The round trip that binds an Account to a site or app: the SDK sends the visitor to Fixback, Fixback signs them in if needed, and hands back a one-time code the SDK trades for a Reporter session. Started by an Invite claim, by Sites, or by your own UI.

Reporter session

The binding the SDK holds, per site, between an Account and a Project after a Connect — what lets a returning reporter be recognised without signing in again. Bounded, refreshable, and revocable. It identifies; it never carries a tier.

Sites

The platform area where an Account sees every Project it can report on — through an Invite or a membership — and opens any of them as a Reporter. The answer to “new computer, where's my link”.

Host identity

An identity assertion your own server mints with one of an Environment's secret keys and hands to the SDK, so a host app that already knows its user can tier them with no sign-in prompt. It verifies only against the secret keys of the Environment whose publishable key the SDK presents, so a staging server's secret mints nothing production accepts. The escape hatch; Connect is the default. (Formerly called signed identity.)

Containers

Workspace

The account boundary: holds Members and Roles, owns every Project, and is the billing subject. One login can run several. Called an Org in the API and the code.

Handle

A workspace's short, unique, URL-safe address — the wemuda in app.fixback.dev/wemuda. Reserved at creation, Owner-editable, and never rewritten by a rename.

Project

One product, across every surface it runs on: owns its Environments — each with its own SDK keys and Gate — its Allowed origins, its Project key, and all its Sessions, Feedback, and Issues, and may connect to one GitHub repository. Staging and production are Environments of one Project — one queue, one repository, one set of Invites — not two Projects.

Environment

One deploy target of a Project — Production, Staging, and the like — with its own publishable and secret keys and its own Gate. Every Project starts with one, Production, gated Internal. The Environment is resolved from the key a deploy carries, never from an SDK option, and stamps every Feedback that key files; its name is the label an Issue shows and the queue filters by. Deleting one stops its keys at once and keeps its Issues, unlabelled. Distinct from Release: Environment is where the build runs, Release is which build.

Project key

The Project's short uppercase code — the FIX in FIX-140 — auto-derived from its name and editable. Distinct from its Environments' publishable and secret SDK keys, which are credentials rather than identifiers.

Installation

A record of the Fixback GitHub App being installed on a GitHub account, owned by a workspace — one per account, so a workspace whose repositories span several GitHub organizations holds several. A Project points at one Installation plus a repository to make its connection.

Actions & markers

File / Filing

The server-side write that turns an accepted signal — a submission or a captured error — into its Feedback and Issue, or folds it into the open Issue already carrying its fingerprint, then queues analysis and the Alert.

Merge

The Member action that folds a duplicate Issue into a canonical one: the duplicate closes with the duplicate reason, and the canonical absorbs its occurrences and reporters. Always a human's click.

Detach

The reversal of a Merge: the duplicate reopens on its own, the canonical gives back its share of the count, and the pair is marked not-a-duplicate so analysis never re-suggests it.

Mute

Silences an Issue without resolving it. A muted Issue stays Open and triageable but emits no Alert and drops into the Muted lens. Shared across the workspace, unlike the personal read receipt.

Alert

An email to the Members who follow a Project when an Issue is filed on it, sent after analysis so it carries the real title and a summary. One per new Issue — a repeat occurrence that folds never re-alerts.

Alert address

Where your Alerts are delivered — your sign-in email, or another address you have verified. One per Account, across every workspace.

Alert mode

A Project's setting for how much of its activity emails Members: New issues + regressions (the default — new Issues plus a resolved one coming back), New issues only, or Off.

Alert subscription

A Member's choice, per Project, whether that Project's Alerts reach them — opt-in: a new Project emails only the Member who created it, and everyone else follows it from Settings → Notifications. An Alert arrives only when the Project's Alert mode sends, you follow the Project, and your master switch is on.

Read receipt

The record that you personally opened an Issue — the durable form of the queue's unread dot. Personal view state, never an Issue state, and never shared.

Assign / Assignee

A Member set as an Issue's owner for getting it Shipped or Closed. Triage, not automation: it changes ownership, not the pipeline.

View

A saved lens over the Issue queue — All open, Duplicates, Recurring, Shipped — alongside the project scope selector. Views derive from state, Labels and counts; they store nothing new.

Handoff

The pre-contexted prompt a Member hands to their own coding agent — Open in Claude Code (cloud), which opens the composer with the repo selected and the prompt filled in, or Copy prompt for any other agent. The bring-your-own-agent cousin of Ship; it carries the linkage convention when a repo is connected, and creates no Run — only a Handoff marker.

Handoff marker

The handed-off entry on an Issue's Activity that records a Member handed it to a coding agent — from both Open in Claude Code (cloud) and Copy prompt. Fixback starts nothing on the Member's behalf and holds no session, so it is a marker, not a Run.

Default handoff action

Which of an Issue's three Hand off actions — Open in Claude Code (cloud), Copy prompt, or Ship it — its blue button runs and its menu marks Default. An Owner sets it for the workspace; a Project may override it; otherwise it is Open in Claude Code (cloud). It only decides which action leads.

Ship

The Member action that starts a Run against an Issue — the signature click (the button reads “Ship it”). Drives agent → PR → merge, as deep as the trust policy's stopping point allows. Nothing Ships on its own, so for Public-tier input the click is the Member vouching for it.

Runs & agents

Agent connection

An Org-level object naming who pays and which model a Run uses: a provider (Anthropic, OpenAI, an Anthropic-/OpenAI-compatible endpoint, or a dispatch kind), an auth kind (your own API key — the default — or a subscription), and a pinned model. The credential is envelope-encrypted at rest and returned by no read endpoint; a verify proves it works. A Project points a default at one, and the Ship dialog shows it with an honest cost word — estimated, computed, or n/a.

Provider

The vendor and endpoint an Agent connection targets — anthropic, openai, an Anthropic-/OpenAI-compatible endpoint (a Z.ai GLM endpoint runs through the Anthropic-compatible path), or a dispatch kind. It selects which harness runs the agent.

Stopping point

How far a Run's pipeline goes before it stops for a human: pr_drafted (open the PR and wait for a Member to Approve & merge) or merge (merge on green). The org default is fixed per tier — Internal → merge, Invited and Public → pr_drafted. The Ship dialog may tighten it for one Run, never loosen it.

Effort class

Analysis's hint, in words, of how much investigation a fix Run will need — a contained change, a contained fix, needs investigation, or not enough evidence to gauge. Gauged from the Evidence with no repository access; the Ship dialog shows it in place of a cost or time estimate.

Environment check

A check Run that clones, installs and runs the tests in the sandbox with no agent, to validate a Project's repository before its first hosted Ship. Hosted Ship is disabled until a check passes for the current run config; editing the config invalidates it. Dispatch Runs skip it.

Dispatch

The Run plane where the agent runs on the Member's own account rather than a Fixback sandbox — Fixback observes only the resulting PR through the return path. A click on Open in Claude Code (cloud) is a Handoff marker, not a Run; a Routine-fired dispatch does create a Run.

Billing

Plan

The workspace's billing arrangement — Free, Pro, Team or Scale. It sets the monthly price and the Included usage. Every workspace holds exactly one; a new one starts on Free. Not the Reporter trust tier.

Meter

One billable measure of work: the Brief, Sandbox minutes (every hosted Run, failed ones included), Model tokens on Fixback's key, and Evidence storage. Collection, the queue, Handoff, dispatch Runs and tokens on your own key are never metered.

Included usage

The dollar amount of Meter usage a Plan covers. On Pro and Team it resets each month and never rolls over; Free's is granted once and never renewed. It is spent before any On-demand usage.

On-demand usage

Usage above the Included usage, billed at the same rates up to the On-demand cap.

On-demand cap

The Owner-set monthly ceiling on On-demand usage — $0 while no card is on file. Distinct from a Run's own per-Run cost cap.

Project cap

On Team and Scale, an Owner-set monthly ceiling on one Project's usage — all of it, at list rates, before Included usage — so each client can be rebilled. At it, that Project's Briefs and new hosted Runs pause; the workspace's On-demand cap still applies on top.

Spend gate

Whether work that costs money may start. It closes at the On-demand cap, with no card once the Included usage is spent, or on an unpaid invoice — and, for one Project, at its Project cap: new Briefs pause (Brief paused (spend cap)) and new hosted Runs are refused, while collection, the queue and Handoff carry on. Paused Briefs are written once it reopens.

Statement

The workspace's running bill for the current month on Settings → Billing — one line per Meter, the Included usage, and the amount so far against the cap, exportable as CSV. An Invoice is the finished bill for a closed month.

Founding slot

One of the Founding 100: a claim code that makes one workspace Pro, fee waived, for 12 months. It is confirmed once the workspace is live within 14 days.

Beta

The mark on every workspace created before billing. Its usage is shown at list rates, but nothing is billed or paused.