> ## Documentation Index
> Fetch the complete documentation index at: https://docs.peepsai.com/llms.txt
> Use this file to discover all available pages before exploring further.

# What to do next

> Once you have a diagnosis there are exactly three paths: a test-script problem, an application bug, or an intended behaviour change.

Once you know the cause, there are exactly three paths. Your agent branches on the diagnosis rather than reaching for the same move every time.

## Test-script problem

The application is fine; the script is wrong.

Peeps normally handles this itself — it heals the script, re-runs to confirm, and publishes. You are here because healing did not settle it, or because you want the fix informed by the code in front of you.

<Steps>
  <Step title="Your agent proposes a fix and submits it" />

  <Step title="Peeps verifies it in its own hosted run">
    Peeps's verification is authoritative here.
  </Step>

  <Step title="A person promotes it in Peeps">
    A verified fix is not a live fix. Publication is a human step.
  </Step>
</Steps>

## Application bug

The test is right; your app is broken.

Fix your app code locally as you normally would.

<Warning>
  Re-running the test against the unchanged deployment is **never** verification of a local fix. Your code has to ship before a run can prove anything about it — and your agent will say so rather than presenting a rerun as a green light.
</Warning>

## Intended behaviour change

The app changed on purpose, and the test has not caught up.

Your agent makes **one combined proposal**: the new script and the new steps together. The pair is promoted atomically, so the test never sits half-updated with steps describing one behaviour and a script asserting another.

This one verifies normally, because the new behaviour is already live.

***

In all three cases a person reviews and publishes verified fixes in the Peeps web app. Your agent proposes; it does not promote.