# Fix a Next.js App Bug Reported in Slack

Your Slack workflow sends a Next.js bug report to Rush, where an agent reproduces the cart failure and returns a tested fix for the team to review.

[Run this on Rush](https://cloud.getrush.ai/run/fix-slack-bug-reports/nextjs/), in a Project that has your repository.

## What the agent does

Your Slack workflow forwards a bug report to a server that calls the Rush sessions API. Include the affected repository, route, exact cart action and expected result in the input; a phrase such as error after saving is not enough to choose a cause. In [vercel/commerce](https://github.com/vercel/commerce/blob/HEAD/package.json#L3-L19), the app uses Next.js `15.6.0-canary.60` and React `19.0.0`, with `next dev --turbopack` behind `pnpm dev`. The agent reads the real package and lockfile before preparing the sandbox, rather than assuming a different stable Next.js release or a preinstalled test runner.

It reproduces the reported action against a test storefront before editing. [components/cart/actions.ts](https://github.com/vercel/commerce/blob/HEAD/components/cart/actions.ts#L15-L95) implements add, remove and quantity updates, including cart lookup, merchandise-to-line matching and cache invalidation with `updateTag(TAGS.cart)`. [EditItemQuantityButton](https://github.com/vercel/commerce/blob/HEAD/components/cart/edit-item-quantity-button.tsx#L41-L57) applies an optimistic update and submits the server action through `useActionState`, with its message in a status region. The agent distinguishes a temporary optimistic display from the persisted cart after refresh. These are places to investigate, not evidence that the public repository contains the bug described in your Slack report.

The setup has an external dependency that the report must acknowledge. [.env.example](https://github.com/vercel/commerce/blob/HEAD/.env.example#L3-L5) names the Shopify store domain, storefront token and revalidation secret. Supply an authorized test store through the project's secret configuration, not pasted into Slack or committed to the repository. If the sandbox lacks that setup, the agent returns a precise reproduction blocker rather than inventing a successful browser session. It asks for missing steps in a finished turn, allowing the team's next message to supply the intended interaction before the investigation continues.

For the fix it adds a regression test that matches the actual failure and exercises the responsible code. The example's `test` script only runs `pnpm prettier:check`; Vitest is not declared in `package.json`. The request therefore explicitly authorizes a minimal Vitest setup if needed, including the lockfile change, instead of claiming `npx vitest run` is an existing suite. The agent runs that command against the new regression, verifies the application in its browser and opens a focused pull request. The description preserves the Slack report's reproduction steps without copying unrelated private channel content.

## Start it with one API call

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

```json
{
  "agent": "claude",
  "input": "A teammate reported in Slack that changing the cart and saving shows an error in this Next.js app. First identify the exact reported cart action, expected behavior and browser state from the supplied report; if missing, finish the turn asking for those details rather than guessing. Use an authorized test storefront and never print or commit its secrets. Reproduce the issue in the sandbox browser, trace the cart component, server action and provider response, then add a regression test and make the smallest fix. Add a minimal Vitest development setup if this repository lacks one, with the lockfile updated, and run npx vitest run plus the relevant existing checks. Verify persistence after refresh and repeat the browser reproduction. Open a pull request with reproduction steps, commands, screenshots and honest blockers. Do not place orders or change live store data.",
  "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 result is a pull request with the cart correction, a regression test and any necessary Vitest configuration and development-dependency change. It identifies whether the failure sits in the server action, client state or provider interaction, with evidence from the reproduced sequence. The test is tied to that failure instead of checking an invented helper that the application never calls.

Your own Slack integration can post the session or pull request link back to the originating thread after reading the result. Reviewers check the test-store boundary, error handling and cart state after refresh, as well as the test output. The retained transcript provides command-level evidence; the page does not assert that a seeded bug exists upstream or that a Rush run has already fixed it.

## Run it on every actionable Slack bug report

Have your Slack app or automation receive the designated report event, map it to the correct repository and send this request from your server with the API key. Use a stable `Idempotency-Key` for retries of the same accepted report. Keep the session identifier with the thread, then handle Rush's signed completion webhook and retrieve the full result before your integration posts an update. Only forward the messages needed to reproduce the bug.

## Why run it on Rush?

A cart report in chat usually lacks the development environment needed to investigate it. Rush turns the forwarded report into work in a separate sandbox, where the agent can inspect source, run a regression and compare browser behavior without taking over an engineer's current checkout. The output remains attached to the report through the session identifier your integration stores.

The API provides a result and transcript that your team can inspect before accepting the fix. A missing Shopify test configuration or incomplete report remains visible instead of being converted into a guessed patch. Separate accepted reports can run independently within your key's concurrency limit, while each pull request stays small enough for a person to review.

## Frequently asked questions

### Does the sample API body automatically subscribe to Slack?

No, this body starts a repository task. Your Slack app or automation receives the message and makes the API call from your server.

### Does the Commerce example already have Vitest tests?

Its declared test command checks formatting, and its package file does not declare Vitest. This prompt explicitly permits adding the minimal test setup and requires that change to appear in the diff.

### Should someone paste the Shopify token into the bug thread?

No, use approved project secret configuration for a test storefront. The Slack report should contain reproduction details, not credentials or private checkout information.

### What if the original report is too vague to reproduce?

The agent is instructed to finish its turn with specific questions. Send the answers as a follow-up after the turn ends, keeping the investigation in the same session.