## TL;DR
A retest passes too easily when it checks something weaker than the original finding: a different account, a patched-looking version string, or the scanner simply not firing this time. Repeat the original proof against the same host, path, and conditions, record the actual responses, and mark resolved only when the original reproduction now fails for the right reason, not because the test changed.

```text
agent's retest verification passed a finding that still reproduces
```

## Use this when
- A finding marked resolved in retest reproduces when a tester repeats the original steps manually.
- The retest evidence is thin, such as a single scanner line saying not found, with no request or response recorded.

## Not for this skill when
- The issue reproduces only under conditions outside the original finding, such as a different role with broader rights. That may be a new finding; scope it on its own evidence.
- The client accepted the risk in writing instead of fixing it. The correct state is accepted risk, neither resolved nor open.

## Steps
1. Retrieve the original finding's proof: the exact request, account role, target state, and the response that demonstrated the issue. Verify: Verify: the retest plan names the original proof steps it will repeat.
2. Repeat those steps as closely as the current authorized environment allows, recording requests and responses with timestamps. Verify: Verify: retest evidence exists at the same level of detail as the original proof.
3. Compare outcomes precisely: the original trigger should now fail, be blocked, or return the corrected behaviour, and the reason should be the fix, such as an authorisation check, not an outage or a login failure. Verify: Verify: the failure mode of the trigger matches a working fix, not a broken test.
4. If it still reproduces, keep the finding open at its original severity, attach the fresh reproduction, and notify the client contact with the evidence rather than a bare status. Verify: Verify: the finding's state and the report reflect the reproduction.
5. Add the pipeline rule: a resolved state requires a linked retest record whose target, check, and conditions match the original finding, and a reviewer spot-checks a sample of resolved findings each round. Verify: Verify: a test attempt to resolve a finding with mismatched retest conditions is blocked.

## Variant phrasings
### retest marked resolved finding still reproduces
The symptom phrasing.
### retest must repeat original proof steps same conditions
The method phrasing.
### scanner not firing is not a fix retest evidence standard
The evidence-standard phrasing.

Compatibility: Compatibility: any agent retest workflow with stored original proofs; manual retests follow the same evidence standard.

## Why it happens
Retests drift toward convenience: the scanner is rerun because it is easy, a non-firing template is read as a fix, and nobody repeats the manual proof that actually demonstrated the issue. Scanner silence can mean a changed page, a WAF, or a broken session as easily as a patch. Only repeating the original demonstration distinguishes a fix from a mirage, which is why resolved is the state that must carry the heaviest evidence.

## Edge cases / pitfalls
- Environment differences between rounds, such as data or role changes, must be recorded; an unrepeatable original proof is a limitation to disclose, not a pass.
- A fix that works on one instance of a shared component must be retested on every affected host, not sampled once and generalised.
- Regressions found later should link back to the retest record, so the history shows fixed, verified, then regressed honestly.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_mjWqjJTVC7RCKjYHTmol5Q