> 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/remediate/remediation-plans.md).

# Remediation Plans

What a remediation plan contains, how to review it, and what happens when you accept it.

A remediation plan is Konvu's proposal for fixing one or more exploitable findings before any code reaches your repository. You review the plan, then accept it to get a fix pull request, or skip it.

## What a plan contains

A plan is titled by what it fixes, such as **Clear 4 findings**, and groups every finding the same change resolves.

* **The change.** For a dependency, the package, its current version, and the target version. For a code finding, the flagged location and the fix.
* **The findings it clears**, each with its CVE, GHSA, or rule ID and a link back to the finding.
* **API changes** between the current and target versions, and the lines in your code where they land.
* **A risk summary**, so you know what could break before you accept.
* **A preview**: the pull request description and the diff, file by file.
* **A tag** that marks the plan as a quick win or as high impact, based on how critical the findings are.

## Plan states

A plan in **To review** goes through these states:

| State          | Meaning                                                     |
| -------------- | ----------------------------------------------------------- |
| Draft          | Konvu created the plan and has not built its preview yet.   |
| Previewing     | Konvu is building the fix to show you the diff.             |
| Ready          | The preview is complete. You can accept the plan.           |
| Preview failed | Konvu could not build a preview. The plan shows the reason. |

Some plans end with a neutral result instead of a fix: the finding is already fixed, the package is not affected, or there is nothing to change. These are not failures.

## Partial plans

When Konvu finds the fix but cannot build or verify a complete patch, the plan is **partial**. Common causes are private dependencies Konvu has no registry credentials for, dependency conflicts, or a build environment Konvu cannot reproduce.

A partial plan still shows the target version, the API changes, and the lines in your code where breaking changes land, along with the files Konvu expected to change and why it stopped. You can apply it yourself, but Konvu does not open a fix pull request from it.

To turn partial plans into complete ones, connect your private registries. See [Remediate](/konvu/triage-and-remediation/remediate.md#set-up-remediation).

## Review and accept

1. Open **Remediate** and select a plan in **To review**, or select **Review** to go through them in order.
2. Read the risk summary and the API changes, then check the **Overview** (the pull request description) and **Files changed** tabs.
3. Accept the plan to open a fix pull request, or skip it.

An accepted plan moves to **Generating** while Konvu writes the fix and runs your tests, then to **Ready** once the pull request is open. See [Fix Pull Requests](/konvu/triage-and-remediation/remediate/fix-pull-requests.md).

## Share a plan

Every plan has its own URL. Share it in a ticket or a chat thread, and the link opens the plan directly for anyone in your organization.


---

# 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/remediate/remediation-plans.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.