Concepts
Trust & automation
This is what makes it safe to leave the feedback overlay open to the public: untrusted input can never trigger an autonomous code change on its own.
Reporter tiers
A Reporter is an Account — the person Connects through the platform (Google, GitHub, Apple, or an email magic link) and the SDK holds a Reporter session for them. Every Reporter has exactly one trust tier, re-derived live on every submission from that Account: an Account that is a Member of the owning Org is Internal; an Account admitted by a live Invite is Invited; anyone else, where the Gate is Open, is Public. Membership is a real lookup through the Account, not an email match.
| Reporter tier | Default automation |
|---|---|
| Internal devs / owners | Straight through: the agent implements and merges; your CD takes it live. "Click to get it live" literally means live. |
| Invited known testers | The agent drafts the fix, but a human reviews before the PR is opened (or before merge). |
| Public unknown reporters | Tracked as an Issue only. Nothing runs until a Member presses Ship it — never automatically. |
How a tier maps onto a Run
When you Ship an Issue, that default automation becomes the Run's stopping point — how far the pipeline goes before it stops for a human:
| Reporter tier | Default stopping point |
|---|---|
| Internal | merge — open the PR and merge on green, no review gate. |
| Invited | pr_drafted — open the PR and wait for a Member to Approve & merge. |
| Public | pr_drafted — capped org-wide; open the PR and wait for a Member to Approve & merge. |
The Ship dialog can tighten the stopping point for a single Run — from merge down to pr_drafted — but never loosen it, bar the one Public exception below. A Run that stops at pr_drafted sits waiting at the gate until a Member acts; the whole
execution streams on the Runs page.
The Gate
Each of a Project's environments has its own Gate — its submission policy — set under Who can report on the environment's Access page in the dashboard:
- Open — anyone on an allowlisted origin can report. The launcher shows to everyone; the identity chip lets them Connect to report as themselves.
- Invited — only Invite-holders and Members can report. Nothing shows to a signed-out visitor; the launcher appears once they Connect as an eligible Account.
- Internal — only Org Members can report. Nothing shows until a Member Connects.
The SDK asks the server on boot whether a submission would be accepted for the visitor, and mounts
the launcher only when it would — so a Gate is enforced on the server, not hidden in the page. The
server reads the Gate from the environment the key belongs to, never from anything the page
declares. Behind an Invited or Internal Gate a signed-out visitor sees nothing; entry is a
Fixback-issued link or a host call to Fixback.signIn().
A new Project starts with one environment, Production, gated Internal — only your team can report until you widen it. A key pasted somewhere by accident cannot start gathering strangers' recordings before you mean it to. You widen the Gate to Invited (for named testers) or Open (for anyone) in the dashboard when you're ready — per environment, so a Staging environment can run Open for testers who never sign in while Production stays Invited or Internal.
Claiming an Invite
An Invite is a Fixback-issued link that admits an Account as an Invited reporter — either targeted (bound to one email, emailed to it) or a shared link (any Account, up to an optional cap). Both land on a claim page hosted by Fixback, which shows the site, the inviting Org, and the tier the claim grants. The person signs in — Google, GitHub, Apple, or an email magic link — and claims in one click: Fixback records their Reporter on the Project (noting which Invite admitted them) and Connects them to the site's landing URL, so they arrive signed in with the launcher mounted. A targeted Invite is claimable only by its bound address; a shared link is refused once its cap of distinct Accounts is reached; a revoked or expired Invite shows only its state.
If the address you invite already belongs to a Member of the Org, no Invite is created — a Member reports Internal through their membership. They get a sign-in link instead, and the invite form labels the row Member · reports as Internal.
Sites
Every Account has a Sites area listing the Projects it can report on — through an Invite or a membership — with the tier it holds on each and Open as reporter, which Connects it to that Project and lands it on the site signed in. It's the answer to "new computer, where's my link": the platform, not the inbox. An Account with no Org also sees Start building here, which leads to creating its first Project.
A Project lists its sites — production, staging, localhost — under each environment's Access → Sites and apps, and one of them is marked the default landing. A claimed Invite lands on the default, and so does Open as reporter; a Member of the Project's Org can open any of the others from the button's menu, so reporting on staging never means changing the setting and back. An invited reporter is offered the default alone.
Removing a reporter
Per Project, under Reporters on any environment's Access page, a Member sees everyone who has reported (Have reported) — with the tier each holds now, how many reports they filed, when they were last seen, and the environment they last reported on. Anonymous reporters — a bare browser on an Open environment — are left out: each is a device, not a person to invite or remove. Remove is a per-Reporter revocation: it refuses that one person's next submission behind an Invited or Internal Gate without revoking the shared link everyone else uses. An Internal reporter is marked Member instead of offering Remove, because removing one has no effect on their tier — Internal is the membership, and the membership still admits them. Neither Remove nor revoking an Invite ever rewrites Feedback already filed.
Public input — the safety valve
Public input is always tracked and analyzed, but it never Ships on its own: a
Run starts only when a Member presses Ship it, so that click is the Member
vouching for the change. A Public Run stops at pr_drafted by default; a Member may
loosen that one Run to merge on the Ship dialog, but only by ticking an explicit
confirm that the change will auto-merge without a review. A typo fix from a stranger can be
fast-tracked; a risky change from a teammate can be held for review.