Workspaces & projects

Creating and switching

Your first workspace is the first step of onboarding: name it, and Fixback reserves an address for it. After that, New workspace in the sidebar switcher creates another. The switcher remembers which one you were last in, per account, so a reload lands you back where you were.

The handle is the address

Every workspace has a unique handle — the wemuda in app.fixback.dev/wemuda. Opening that address makes the workspace active and lands you in the app, so it is a link you can bookmark or paste to a teammate.

• Handles are 2–40 lowercase letters, digits and inner hyphens, and are unique across the whole platform.
• Created from the name, de-duplicated with a numeric suffix when it is taken. If you type one yourself and it is taken, Fixback refuses it and offers the next free one rather than quietly changing it.
• Renaming a workspace never rewrites its handle, so existing links keep working. An Owner can change it deliberately in Settings.

A handle and a Project key are different things: the handle addresses the workspace, and the Project key (the FIX in FIX-140) prefixes one Project's Issue keys.

Members and roles

There are two roles, deliberately:

• Owner — everything a Collaborator can do, plus inviting and removing Members, changing Roles, editing the name and handle, choosing the analysis model, deleting the workspace, and billing — the plan, the card and the on-demand cap.
• Collaborator — full product access: the queue, triage, Projects, Handoff.

Inviting someone sends an email naming who invited them and which workspace, and lands them directly in it once they sign in. Any Member can leave a workspace; the last Owner cannot, so a workspace is never left without one.

Deleting is soft: the workspace is recoverable for 30 days and keeps its handle for that window, then the purge frees it.

Projects

A Project is one product, across every surface it runs on. It owns its environments, its allowed origins, its Project key, its connected repository, and every Session, Feedback and Issue filed against it. A Project belongs to its workspace permanently and is never moved between them. Staging and production are environments of one Project — one queue, one repository, one set of Invites — not two Projects.

The Projects page shows a card per Project, with a sparkline of the Issues filed in each of the last five weeks beside the count still open. A Project's settings rail has two groups. The Project pages are one copy for the whole Project:

• Overview — each environment's pulse: its reports over the last 14 days against the 14 before, a bar per day, its new Issues and how many shipped; then the latest reports. The Project key sits at its foot under Identity — editable, and it re-labels the Project's Issues when changed.
• Repository & ship — the connected GitHub repo, the Project's Hand off button default, Ship (the AI provider its Runs use and the environment check), and when a fix merges.
• Capture & analysis — which Trace streams and replay are on and how far back replay reaches, the full-fidelity switches, whether the screenshot is sent to the Brief model, and Walkthroughs.
• Notifications — this Project's alert mode.

Below them, the environment switcher picks one environment, and the Environment pages show it — switching keeps you on the same page. The switcher's menu adds, renames and deletes environments; every Project starts with Production.

• Install — the install steps per platform and the agent prompt, carrying the picked environment's key.
• Access — Who can report (the environment's Gate: Open, Invited or Internal); Sites and apps, the sites the web SDK may boot on (the environment's own, plus any listed for all environments) and the app links sign-in returns through, with one site marked the Project's default landing; and Reporters, the Project's invites and everyone who has reported, with per-person removal. A mobile or backend install needs no site.
• Keys — the environment's Publishable key, which ships in the page, and its Secret keys, which your server and CI use. The publishable key is an identifier; a secret key is a credential.

The Danger zone at the foot deletes the Project.

The analysis model

Which model writes your Briefs is a workspace choice, in Settings → Automation: pick from a curated catalog, or leave it on the platform default. It is Owner-only, because it is a spend decision.

Models that can't read images simply skip the annotated screenshot and write the Brief from the rest of the Evidence. That is why the per-Project screenshot toggle and the workspace model choice are separate settings: the Project says what may be sent, the workspace says what can read it.

Where everything lives

The split is deliberate: the first six — Organization, Members, Automation, Integrations, Billing and Usage — belong to the workspace and are shared by everyone in it; the last three — Notifications, Account and MCP — belong to you and follow your account into every workspace you join. The one exception is the list of Projects under Notifications, which shows the workspace you are in.

Reporter trust tiers are not a setting — a tier is inferred from who a Reporter is and nothing about it is changed here. What they mean, and how far automation goes for each, is reference material: see Trust & automation.