All jobs

QA a Nuxt App in a Real Browser

An agent boots Nuxt Movies in a cloud sandbox, walks browse, search, movie and trailer flows in a real browser, and returns qa-report.md with screenshots.

Run this on RushIn a Project that has your repository.
request.jsonView .md

What the agent does

For a Nuxt app like nuxt/movies, the agent starts from package.json and nuxt.config.ts before opening a browser. The app declares pnpm 11.1.2 and Node ^24.0.0 under devEngines, with scripts for pnpm dev (nuxt dev), pnpm build, pnpm typecheck, pnpm test:unit (vitest) and pnpm test:e2e (playwright test). Dependencies include nuxt via the nuxt-nightly alias, @nuxt/image, @nuxtjs/i18n, @unocss/nuxt and @vueuse/nuxt. runtimeConfig.public.apiBaseUrl points at https://movies-proxy.vercel.app, so a local proxy (proxy/ with nitropack on PORT=3001, started by pnpm dev:proxy) is optional when the public proxy is reachable. The agent enables corepack, runs pnpm install from the lockfile, then pnpm dev and waits until http://localhost:3000 answers.

The sandbox browser is the QA surface. The home page at app/pages/index.vue loads a MediaHero for the first movie from listMedia and CarouselAutoQuery rows from QUERY_LIST. The agent screenshots the hero and carousels, follows a NuxtLink into app/pages/[type]/[id].vue, and opens the trailer control in app/components/media/Hero.vue, which calls getTrailer and showModal so IframeModal.vue mounts a full-screen iframe. It also opens the Videos tab in MediaDetails (app/components/media/Details.vue) and checks VideoCard entries. Search goes through app/pages/search.vue; genre and person routes under app/pages/genre and app/pages/person are walked when linked from the UI. Each step is recorded with the URL, the control clicked and a screenshot from the sandbox browser.

Playwright is already in the repo (playwright.config.ts targets tests/e2e with Chrome and Safari projects, and @nuxt/test-utils/playwright), but this job is an exploratory QA pass, not a rewrite of those specs. The agent may read an existing e2e file only to learn selectors or known brittle areas. It does not edit app/, server/ or tests/. Defects go into qa-report.md: title, severity, steps to reproduce, expected versus actual, and paths to the screenshots kept as session artifacts. Broken images from the IPX proxy, missing trailers, i18n string gaps and console errors during a flow are all in scope.

Teammates can take the browser while the turn is live, steer to a flow the agent skipped (for example a person page or a language switch via LanguageSwitcher.vue), and send a follow-up so the agent continues from that state. The agent appends those flows to the same report. When the pass is done it leaves the working tree clean: no code changes, only the report and screenshots as artifacts on the session.

Start it with one API call

POST https://api.prix.dev/o/{org}/sessions with this body:

{
  "agent": "claude",
  "input": "Start this app in the sandbox and test it in the browser as a QA tester: browse, search, open a movie and play a trailer. For each flow record the steps, a screenshot per step and the result. Write qa-report.md with every defect, its steps to reproduce and its severity. Change no code.",
  "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

What comes back is an artifact set on the session, not a pull request. qa-report.md lists every flow run (home carousels, search, movie detail, trailer modal, videos tab) with pass or fail, and each defect has severity, reproduction steps and screenshot names. The session’s artifacts list exposes those files with time-limited download URLs; GET /o/{org}/sessions/{id} shows the finished turn’s result text pointing at the report.

A reviewer reads the report against the screenshots, confirms the agent did not modify tracked files, and decides which defects become tickets. Teammates who steered the browser can see their flows in the same document. The transcript keeps every shell command (pnpm install, pnpm dev) and every browser action with its tool output.

Run it on every release candidate cut

When you cut a release candidate, POST /o/{org}/sessions once per Nuxt app with this prompt and that repository in resources. Attach a webhook_url on the API key so your service receives run.completed with session_url, then download qa-report.md from the session artifacts and open tickets for high-severity items.

For a weekly smoke pass, schedule the same body with a new Idempotency-Key each week. Concurrent keys share max_concurrent; queue repos if you cover more apps than the limit allows.

The use case this job follows, with its automation and trigger: Steer a run as a team.

Why run it on Rush?

Exploratory browser QA needs a running Nuxt server, network access to the TMDB proxy and a real browser with screenshots. A Rush sandbox owns that stack without tying up a laptop display or mixing QA cookies with a developer’s profile.

The team can watch and take the browser mid-run, so a missed flow becomes a follow-up instead of a second local session. Proof is the report plus screenshots and the transcript of commands, not a claim that someone clicked around.

Frequently asked questions

Does the agent need the local movies proxy?

nuxt.config.ts defaults apiBaseUrl to the public Vercel proxy. If that host is reachable from the sandbox, pnpm dev alone is enough. When it is not, the agent can start proxy/ with pnpm dev:proxy on port 3001 and point the app at it, recording which path it used in the report.

Will it change Playwright tests or application code?

No. The prompt says change no code. Existing pnpm test:e2e specs stay untouched; findings land only in qa-report.md and screenshot artifacts.

Can the team steer the browser during the run?

Yes. While the session is live, a teammate can take the sandbox browser, show a flow the agent missed, and send a follow-up message so the agent continues and appends that flow to the report.

What package manager and Node version does it use?

The fixture pins pnpm 11.1.2 and Node ^24.0.0 under devEngines. The agent follows those pins with corepack and the lockfile rather than inventing another toolchain.