What the agent does
The agent reads how the Nuxt Movies app talks to TMDB. In nuxt/movies, the Nuxt app's server/api/index.ts is a tiny defineEventHandler returning Nuxt Movies API, while real HTTP proxying lives in the nested proxy/ Nitro app: proxy/routes/tmdb/[...path].ts forwards to https://api.themoviedb.org/3 with runtimeConfig.tmdb.apiKey, and proxy/routes/ipx/[...path].ts fronts image.tmdb.org. Client composables in app/composables/tmdb.ts call $fetch against https://movies-proxy.vercel.app/tmdb (overridable via runtimeConfig.public.apiBaseUrl in nuxt.config.ts).
package.json pins pnpm 11.1.2 and Node ^24, with scripts test:unit → vitest and @nuxt/test-utils ^4.2.0. vitest.config.ts uses defineVitestConfig from @nuxt/test-utils/config and includes tests/unit/**, components/**/*.test.ts and composables/**/*.test.ts. Composables such as item.ts already have item.nuxt.test.ts; tmdb.ts list/fetch helpers and the Nitro proxy/routes/tmdb handler have little direct coverage.
New tests use the Nuxt environment from @nuxt/test-utils: Vitest cases for fetchTMDB / listMedia that stub $fetch or the network at the boundary (no live TMDB key), and Nitro route tests for proxy/routes/tmdb/[...path].ts that assert query forwarding and the missing-API-key error. It does not hit api.themoviedb.org and does not commit secrets.
It runs pnpm test:unit (installing with the lockfile's pnpm version), fixes Nuxt environment setup issues, and opens a pull request adding tests under app/composables/, tests/unit/ and/or proxy/ as appropriate. It also checks vitest.config.ts coverage includes and the existing app/composables/item.nuxt.test.ts style (Vitest describe/it, #shared/types, mocks from tests/unit/mocks) so new TMDB tests sit next to the Movies team's patterns rather than inventing a second runner. For the proxy package it reads proxy/nitro.config.ts route rules for /tmdb/** and the tmdb.apiKey runtime config key before asserting the handler in proxy/routes/tmdb/[...path].ts.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Write tests with @nuxt/test-utils and Vitest for this Nuxt app's server API routes and composables, stubbing only the external TMDB HTTP calls at the network boundary. Run them and open a pull request.",
"resources": [
{
"url": "https://github.com/your-org/your-nuxt-app"
}
]
}- 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.
- 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.
- 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 a pull request with new Vitest / @nuxt/test-utils files covering TMDB composables and the Nitro TMDB proxy route, plus any small test helpers under tests/unit/mocks. Application runtime config defaults stay non-secret; no .env with a real TMDB_API_KEY is added.
The pull request description names pnpm test:unit as the command that passed and which modules each file covers. The trajectory includes Vitest output and shows that outbound TMDB calls were stubbed.
Before merging, a reviewer checks that stubs sit at $fetch / Nitro $fetch boundaries rather than rewriting tmdb.ts production logic, that vitest.config.ts include globs pick up the new files, and that e2e Playwright jobs remain separate.
Run it on every composable or proxy route changed
When pulls touch app/composables/tmdb.ts or proxy/routes/**, POST this session request so unit coverage tracks the TMDB boundary without needing a TMDB key in CI secrets for this job.
Deliver run.completed to your frontend channel via the API key webhook. Parallel Nuxt apps can share the API key up to max_concurrent.
The use case this job follows, with its automation and trigger: Write the missing tests.
Why run it on Rush?
Nuxt test-utils boots a Nuxt environment and may build Nitro routes; that is slow and noisy on a laptop beside nuxt dev. Rush runs pnpm test:unit in a clean sandbox with Node 24 and pnpm 11 matching devEngines, so local servers keep running. Component fixtures already in the repo (for example person Card tests that assert /tmdb image URLs) show the team cares about TMDB URL shape; the new suite extends that idea to the fetch and proxy layers.
Stubbing only the TMDB HTTP edge keeps tests honest about query shaping and error handling without flaking on the public API. The pull request plus trajectory are the proof reviewers re-run with the same Vitest config.
Frequently asked questions
Do I need a TMDB API key for this job?
No. The agent stubs outbound HTTP at the network boundary. Keys stay out of the repository; the proxy's missing-key error path is tested with an empty runtimeConfig.tmdb.apiKey.
Are Playwright e2e tests in scope?
No. This page is the Vitest / @nuxt/test-utils unit layer (pnpm test:unit). E2E remains pnpm test:e2e unless you ask for that separately.
Which package manager does it use?
pnpm, per pnpm-lock.yaml and devEngines.packageManager version 11.1.2 in the Movies app. It does not switch the repo to npm.
What about the root server/api/index.ts?
It can get a one-liner assertion, but the meaningful server routes for TMDB are under proxy/routes/. The agent spends most of the suite there and on app/composables/tmdb.ts.