# Debug a Front-End Bug in a Nuxt App Together

An agent reproduces your team's Nuxt browser demonstration, traces the failing state, and returns a focused fix with a regression test and screenshots.

[Run this on Rush](https://cloud.getrush.ai/run/debug-together-in-browser/nuxt/), in a Project that has your repository.

## What the agent does

Start with the interaction your team can demonstrate, not a guessed defect. In [elk-zone/elk](https://github.com/elk-zone/elk/blob/HEAD/package.json#L5-L25), the package manager is `pnpm@11.6.0`, the development server uses port `5314`, and separate scripts run normal, mocked and PWA development modes. The agent installs from `pnpm-lock.yaml`, starts the appropriate mode and returns an initial turn asking for the exact route, account state and gestures. Your team then supplies the demonstration details in a follow-up. A public timeline problem and an account-switching problem need different starting conditions even if they look similar on screen.

The agent repeats the steps itself and records expected versus observed behavior before editing code. Elk's [Nuxt configuration](https://github.com/elk-zone/elk/blob/HEAD/nuxt.config.ts#L33-L44) includes UnoCSS, i18n and Nuxt test utilities; its composables also use auto-imported application state. [app/composables/timeline.ts](https://github.com/elk-zone/elk/blob/HEAD/app/composables/timeline.ts#L12-L46) distinguishes server-side content filters from user preferences that hide replies or boosts. For a timeline report, the agent inspects those conditions rather than assuming the visible order comes directly from the API. It treats this as a possible investigation path, not a claim that the example repository has a known defect.

It chooses a regression test at the layer responsible for the observed failure. [tests/unit/reorder-timeline.test.ts](https://github.com/elk-zone/elk/blob/HEAD/tests/unit/reorder-timeline.test.ts#L68-L104) already exercises reply and boost ordering; the Nuxt test configuration also provides IndexedDB and IntersectionObserver support for application-level cases. A pure ordering regression can extend the existing test, while a mounted component or persisted-state failure needs the relevant Nuxt environment. The agent shows that the test reproduces the demonstrated problem before changing behavior, then makes the smallest correction in the component or composable that owns it.

It runs `pnpm test:unit:ci`, `pnpm test:typecheck` and the appropriate lint checks, then repeats the original browser sequence. PWA-specific reports are verified in the PWA development mode rather than dismissed after a normal dev-server pass. The result includes before-and-after screenshots, reproduction state and the commands actually executed. The team can read the session answer and transcript and request another pass after the turn finishes. The agent follows the fork's contribution rules and leaves any human-only contribution attestation to the person who reviews the patch.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "Prepare this Nuxt app in the sandbox using its declared package manager and development scripts. A teammate will demonstrate a frontend bug; end the initial turn asking for the route, starting account/browser state, exact actions, expected result and observed result, then wait for their follow-up. Do not guess a bug. After the follow-up, reproduce the sequence yourself, trace the responsible component/composable and add a regression test that fails before the fix. Make a focused correction, run the appropriate unit/Nuxt tests, typecheck and lint, then repeat the demonstration in the browser and capture before/after evidence. Distinguish mocked development from live service behavior and ask before actions that publish content. Follow repository contribution rules and open a PR on the connected repository after verification, without claiming unrun checks passed.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    }
  ]
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

The pull request contains the focused component or composable change and a regression test tied to the demonstrated interaction. Its description records route, starting state, actions and expected behavior so another developer can repeat the investigation. Screenshots are labeled by state rather than presented as proof that every timeline and account combination works.

A reviewer checks that the regression would fail without the patch, that the fix preserves relevant filtering and ordering behavior, and that the browser check uses the same mode as the report. The transcript supplies the command output and the team's follow-up context. If a real Mastodon account or service is unavailable, that missing verification is stated separately from results obtained in mocked development.

## Run it on every reproducible Nuxt UI report

Let your bug-report form or issue webhook start a session with the repository and available reproduction details. For reports that need a demonstration, retain the session identifier and send the missing steps after the first turn ends. `POST /o/{org}/sessions/{id}/messages` resumes the same sandbox; a message sent during an active turn returns `409 TURN_ACTIVE`. Use a completion webhook or the session read to know when to continue.

## Why run it on Rush?

Nuxt UI bugs often depend on browser storage, account selection and service-worker mode as much as source code. Rush gives the investigation its own sandbox, keeping those experiments away from an engineer's regular browser session and working tree. The retained transcript makes it possible to distinguish the user's demonstration from the sequence the agent actually reproduced.

The team does not have to compress an interactive report into a speculative code change. An initial turn gathers the missing state, and a follow-up continues the retained environment with a concrete reproduction. Separate reports can run independently subject to the key's concurrency limit, each returning a patch and evidence specific to that interaction.

## Frequently asked questions

### Does a mocked development session prove the live Mastodon flow?

No, mocked development can help isolate UI state without establishing live service behavior. The result must name the mode used and identify any live-account verification that remains.

### Can the team correct the reproduction after the agent starts?

Yes, ask the agent to finish its initial information-gathering turn and send the correction as a follow-up. The API rejects a follow-up while that turn is still running.

### Will it change unrelated translations or styling?

The request calls for a focused behavioral fix following repository conventions. A reviewer should reject unrelated translation churn or styling changes that do not explain the demonstrated failure.

### What if the bug only appears with the service worker enabled?

The reproduction must identify PWA mode explicitly. The agent should repeat that mode during verification instead of treating a passing ordinary development session as equivalent.