# Fix a Failed Vercel Deployment of a SvelteKit App

Yes. A failed deployment starts a run; the agent reads the Vercel log, reproduces vite build with adapter-vercel and opens a pull request with the fix.

[Run this on Rush](https://cloud.getrush.ai/run/fix-vercel-build-failures/sveltekit/), in a Project that has your repository.

## What the agent does

When Vercel reports a failed deployment, the event starts a run and arrives after the prompt. The agent reads the deployment's build log through the Vercel connection, picks out the error SvelteKit printed, and clones the repository at the commit Vercel built into its own cloud sandbox.

In a SvelteKit app like `sveltejs/realworld`, the agent reads `package.json`: `vite build` as `build`, `pnpm@10.20.0` in `packageManager` with a `pnpm-lock.yaml`, SvelteKit 2.52, Svelte 5.55 and Vite 7. `svelte.config.js` uses `@sveltejs/adapter-vercel` and sets `compilerOptions.runes` to `true`, so every component is compiled in runes mode. Legacy syntax such as `export let` props or a `$:` statement fails the compile, which is a common cause of a red deployment after an upgrade or a copied component.

The app is small enough to read in full. Data loads in `+page.server.js` files under `src/routes/` for articles, the editor, login, profile and settings, and every request goes through `src/lib/api.js` to `https://api.realworld.show/api`. `src/hooks.server.js` reads the `jwt` cookie into `event.locals.user`. The agent installs with pnpm, runs `pnpm build`, and confirms the sandbox fails on the same line as the Vercel log before changing anything.

It fixes the cause in the file the error names, for example rewriting a component's props with `$props()` for runes mode or correcting an import of a server-only module into a `.svelte` file, then runs `pnpm build` until adapter-vercel writes its output. The repository has no test suite, so it also runs `pnpm lint`, which is `prettier --check .` here, and a `vite preview` to load the pages the fix touched.

## Start it with one API call

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

```json
{
  "agent": "claude",
  "input": "A Vercel deployment of this SvelteKit app failed; the deployment event follows this prompt. Use the Vercel connection to read that deployment's build log and quote the failing line. Install with pnpm and the lockfile, reproduce the failure with pnpm build in the sandbox, fix the cause, confirm the build passes with adapter-vercel and pnpm lint passes, load the affected pages with vite preview, and open a pull request that quotes the failing log line and explains the fix.",
  "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 a pull request on its own branch with the fix. Its description quotes the failing line from the Vercel log, names the component or route file, and explains the cause in SvelteKit's terms, such as a runes mode compile error or a server import in client code. It includes the passing build and the pages it loaded with `vite preview`.

This repository has no workflow of its own, so the check on the pull request is Vercel's preview deployment for the branch. A reviewer opens the preview, visits the routes the fix touched, and reads the diff to see that it moves the component to runes rather than turning `runes` off in `svelte.config.js`.

When the build passes in the sandbox, the cause is in the Vercel project, not the code, and the run reports what differs, such as the Node version or a missing environment variable. Every command and its output stays in the session.

## Run it on every failed Vercel deployment

Set up an automation in the Project with this prompt and a `webhook` trigger, and keep the URL and signing secret Rush shows once. Point the Vercel project's failed deployment webhook at it, and each failure starts a run with the event after the prompt.

One event delivered twice still makes one run. The run opens one pull request on its own branch, and when its checks do not pass it ends `needs_review` instead of reporting done.

## Why run it on Rush?

A SvelteKit failure on Vercel usually means checking out the commit, installing the right pnpm, and running the build with adapter-vercel to see the same compile error. A Rush run does it in its own sandbox and keeps every command and its output, so the fix comes with its own record of how it was found and checked.

With no test suite in the repository, the proof is the passing build, the pages loaded in `vite preview`, and the green Vercel preview on the pull request. Failures on different branches each get their own run, side by side.

## Frequently asked questions

### Will it turn off runes mode to make the build pass?

No. The prompt asks for the cause to be fixed, and the reviewer checks `svelte.config.js` is unchanged. A component written in the old syntax is rewritten with `$props()` and `$state` instead.

### Does the build need the RealWorld API to be up?

The build does not call it; `src/lib/api.js` calls `https://api.realworld.show/api` at request time from the `+page.server.js` loaders. The `vite preview` check does need it to load pages with data.

### Which package manager does it use?

The one the repository names: `pnpm@10.20.0` in `packageManager`, installed with `pnpm-lock.yaml`. That matches what Vercel uses for a project with a pnpm lockfile.

### How does it read the Vercel build log?

Through the Vercel MCP server, connected once with `POST /me/connections` and an OAuth sign-in, then named in the run's `connections` or on the saved agent the automation runs.