Skip to main content
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.
1

Your agent proposes a fix and submits it

2

Peeps verifies it in its own hosted run

Peeps’s verification is authoritative here.
3

A person promotes it in Peeps

A verified fix is not a live fix. Publication is a human step.

​
Application bug

The test is right; your app is broken. Fix your app code locally as you normally would.
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.

​
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.