> For the complete documentation index, see [llms.txt](https://docs.konvu.com/konvu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.konvu.com/konvu/triage-and-remediation/exploit-reproduction/re-running-reproductions.md).

# Re-running Reproductions

Run a reproduction again, check whether a fix landed on the latest version, and correct a wrong reproduction result.

A reproduction is a snapshot of one version of your code. Run it again when the code changes, when you want to know whether a fix landed, or when you think the reproduction result is wrong. Each run is kept, so earlier results stay available for comparison.

## Reproduce again

On a report that already has a reproduction result, select **Reproduce again**. The new run uses the same version as before unless you choose otherwise.

A run cannot start while another run of the same report is in progress.

## Check the latest version

Choose **Latest version (patch check)** to deploy the newest published version of your application, or the head of the default branch when no release exists. The result reads:

* **Fix verified**: the exploit no longer fires on the latest version.
* **Still vulnerable**: the exploit still fires.

If Konvu cannot find or build a newer version, the run stops as Inconclusive with an environment limitation.

*Example: a researcher reports an IDOR against v2.3.0, which you patched in v2.4.1. The default run proves the bug existed in v2.3.0. The patch check confirms v2.4.1 is no longer vulnerable, so you can pay the bounty and close the report in the same step.*

## Steer a wrong result

When you think the reproduction result or evidence is wrong, select **Steer** from the report's action menu. Pick what was wrong and add a comment:

| Tag                    | Use it when                                                              |
| ---------------------- | ------------------------------------------------------------------------ |
| Wrong verdict          | The reproduction result is incorrect.                                    |
| Weak evidence          | The conclusion may be right, but the evidence does not support it.       |
| Hallucinated narrative | The explanation cites code, files, or behavior that do not exist.        |
| Wrong impact           | The exploit is real, but the stated impact is overstated or understated. |
| Irrelevant sandbox     | The sandbox does not represent how the application runs.                 |

Steering re-runs triage with your feedback, then reproduces again if the new triage allows it. Your tags and comment stay on the report as the reason for the re-run.

*Example: "The `/admin/export` endpoint sits behind our VPN. It is not internet-facing." Konvu re-triages with that context before it reproduces again.*

### From the CLI

```bash
konvu finding vulnerability-report steer <report-id> \
  --tag wrong_verdict \
  --comment "The endpoint is restricted to administrators"
```

`steer` is an alias for `reassess`. A dismissed report must be reopened before you can steer or reproduce it.

## Re-running and limits

Every re-run, steer, and patch check counts as a new reproduction toward your organization's limits. See [How Reproduction Works](/konvu/triage-and-remediation/exploit-reproduction/how-reproduction-works.md#what-reproduction-does-not-do).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.konvu.com/konvu/triage-and-remediation/exploit-reproduction/re-running-reproductions.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.