Install with an AI agent

Install Fixback in this repository and take me to my first Issue.

Fixback captures what a user sees, says, or struggles with — on-page feedback with a session Trace, and runtime errors that report themselves — and files each one as an Issue in the Fixback dashboard, already analysed into a Brief. You install the SDKs; I do the few dashboard steps you cannot, when you tell me to.

Surfaces to instrument in this repository:
- Web (@fixback/sdk) — any website or web app

The documentation is the source of truth: https://fixback-docs.dev.wemuda.com. Fetch and read the guide linked in each step before you write its code — it is more current than anything you remember about Fixback. Where a page has platform lanes, read the lane for the surface you are on.

## Ground rules

- **One Project, every surface.** Everything below installs against ONE Fixback Project — one key pair, one queue. Never create a Project per surface. If I do not have one yet, I create it at https://fixback.dev.wemuda.com (free) and tell you.
- **Publishable key:** ask me for the Project's publishable key (`pk_…`) before you write any client code. It is on the Project in the dashboard (https://fixback.dev.wemuda.com), under **Keys**. It is an identifier, not a secret — safe in client code and in git.
- **Secret key (`sk_…`):** only where a step says so, and only ever through the environment variable `FIXBACK_SECRET_KEY`. Never ask me to paste it into this chat, never write it into a file, never commit it, never put it in client code.
- **Look before you touch.** Detect the package manager from the lockfile, the build tool, the frameworks, and the real entry points; install with the project's own package manager, not the `npm` shown in the commands. If this repository turns out not to contain one of the surfaces above, say so and skip that step rather than inventing one.
- **Every SDK fails quiet by design.** If Fixback cannot be reached or a key is refused, nothing throws and nothing shows. So verify each step exactly the way it says to, and when an install stays silent, diagnose against the step's checklist — do not remove or rewrite the install.
- **Keep it minimal and idiomatic** to this codebase: no wrapper abstractions around the SDK, no config the guide does not call for.

## Step 1 — Web — @fixback/sdk

Guide: https://fixback-docs.dev.wemuda.com/sdk/web · Reference: https://fixback-docs.dev.wemuda.com/reference/browser-sdk

1. Install it with this project's package manager:
   ```sh
   npm install @fixback/sdk
   ```
   A site with no build step uses the `<script>` tag from the guide instead — it exposes a `Fixback` global.
2. Boot it once, as early as the client starts (the browser entry file): `init({ key: "pk_…" })`. In an SSR framework (Next.js, SvelteKit, Nuxt, Remix, …) guard the call so it only runs in the browser. Pass `release` and `environment` when the build already exposes them; use `enabled: false` only where capture should stay off deliberately.
3. **Allowed origins — a step for me.** The SDK mounts only on an origin listed in the Project's Allowed origins, and only a Member can edit that list. Tell me the exact origins to add — the local dev origin (for example `http://localhost:5173`) and the production one — and wait for me to confirm before verifying.
4. Verify: run the app and load a page. Load a page where you installed the SDK. That boot flips the Project to Connected in the dashboard. A new Project's Gate is **Internal**, so the Feedback pill shows only to a signed-in Member: I open the site from **Sites → Open as reporter** in the dashboard (https://fixback.dev.wemuda.com), or the page calls `Fixback.signIn()`. The pill appears bottom-right; I send one report, and it arrives under Issues. If nothing shows, check in this order: the key, the origin is listed exactly, I am signed in. The SDK never throws — silence is a configuration problem, not a code one.

## Step 2 — Source maps — symbolicated code-area pointers

Guide: https://fixback-docs.dev.wemuda.com/sdk/sourcemaps · Vite plugin: https://fixback-docs.dev.wemuda.com/reference/vite-plugin · CLI: https://fixback-docs.dev.wemuda.com/reference/cli

With sourcemaps uploaded per release, an auto-captured error arrives pointing at the original `file:line` instead of a minified frame. Pick the door that fits this build:
- **Vite:** `npm install -D @fixback/vite-plugin` (with the project's package manager) and add `fixbackSourcemaps()` to `plugins` in `vite.config.ts`. With `FIXBACK_SECRET_KEY` in the build environment it turns on hidden sourcemaps, uploads them keyed by release, and prunes them from the output. A missing key is a warning, never a failed build.
- **Anything else:** run `FIXBACK_SECRET_KEY=… npx @fixback/cli sourcemaps upload <build dir>` as a CI step after the bundle is produced. The release comes from `--release`, else `FIXBACK_RELEASE`, else the git commit SHA.
- Pass the **same** release string to every SDK's init (`release`) — Web — so captured stacks match the uploaded maps.
- **A step for me:** the upload authenticates with the Project's secret key. Tell me to add `FIXBACK_SECRET_KEY` to the CI secrets, and where. If the Node step above already issued one, the same key works — do not ask for a second.

## Finish

Do not call a surface done until its first Issue has arrived under **Issues** in the dashboard (https://fixback.dev.wemuda.com) — that is the proof the whole path works. Then report back with:
- what you installed and every file you changed;
- the environment variables I must set, and where;
- the dashboard steps still on me (origins, keys, the Gate);
- how you verified each surface.

When the Issue is there, https://fixback-docs.dev.wemuda.com/dashboard/issues explains what to do with it, and https://fixback-docs.dev.wemuda.com/dashboard/github connects the repository so a merged fix closes the Issue on its own.