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

# Retest findings

> Retest after a fail, a finding in retest status, or a client retest request on /retests.

Four names, one job: verify a fix.

## 1. You failed it

New **run**, same cases. Don't edit the old run's fails into passes. History matters for the snapshot you already sent.

## 2. Finding status `retest`

Someone (you, them, a comment) marked the issue as ready to verify. Execute, attach new evidence, then `resolved` / `closed` or back to `open`.

## 3. Client request retest

Review action `retest_requested`. Queue: **Retest requests** at `/retests`. This is the "please check the deploy" email.

## 4. Status `retest` vs cycle

Finding status is the issue. Cycle/run is execution. You usually need both: a run to click through, a finding status to tell the inbox you're done.

[Playbook](/playbook/retesting), [What the client sees](/delivery/what-client-sees)

<Columns cols={2}>
  <Card title="Failed vs finding" icon="git-compare" href="/concepts/failed-vs-finding">
    Don't confuse the two records.
  </Card>

  <Card title="New snapshot" icon="camera" href="/delivery/snapshot">
    Retest rounds get a new freeze.
  </Card>
</Columns>