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

# Fixes and pull requests

> From a finding to a merge ready pull request, with you in command at every gate.

A remediation is the planned fix for one cluster of related findings. An agent writes the plan, and once you approve it, another agent implements it. You hold two gates: approving the plan, and merging the pull request.

```mermaid theme={null}
flowchart TB
  F["Finding cluster"] --> P["Plan written"]
  P --> R["You review and edit"]
  R -->|"approve"| E["Implemented on a branch"]
  R -->|"no code to change"| A["Assignment<br/>with a runbook"]
  E --> V["Validated against your tests"]
  V --> PR["Pull request opened"]
  PR --> M["You merge"]
```

## The plan

Every plan has two halves, written for two audiences.

<CardGroup cols={2}>
  <Card title="The plan, for everyone" icon="file-text">
    Three short sections with no file names and no code. **Summary**: what the plan is for, including the context around the finding. **Execution**: what will change, as high level steps. **Impact**: the operational effect and what to validate.
  </Card>

  <Card title="The technical plan, for engineers" icon="code">
    The concrete change, in detail. Files, structure and approach.
  </Card>
</CardGroup>

Both are editable inline. If you disagree with the approach, change it before approving. What you approve is what gets implemented.

## When a plan is written

* **Automatically**, for Critical and High findings, once every question attached to them is answered.
* **On request**, for any finding, at any severity.

A finding with an unanswered question gets no plan at all, automatic or on request. It is not even listed until you answer. Planning a fix on a guess about your priorities is worse than waiting.

Only one active remediation exists per cluster at a time, so two people cannot start competing fixes for the same problem.

## Execution

On approval, an agent implements the plan you approved, commits, and pushes a new branch. Repository write access is only introduced at this point, and only for this work.

The fix is then validated against your own tests, so a change that breaks your build or your behaviour never reaches you as a pull request to catch by hand.

## Outcomes

| Outcome          | When                                                                                                      |
| ---------------- | --------------------------------------------------------------------------------------------------------- |
| **Pull request** | There is code to change. Opened against your repository from a new branch                                 |
| **Assignment**   | There is no code to change, for example a console setting or a process. Routed to a person with a runbook |

## Status

```mermaid theme={null}
stateDiagram-v2
  [*] --> Planning
  Planning --> ReadyForReview: plan written
  Planning --> Failed: planning ended without a plan
  ReadyForReview --> Executing: you approve
  Executing --> Completed
  Executing --> Failed
  ReadyForReview --> Cancelled
```

A plan in progress is durable. Refreshing the page or coming back tomorrow finds it where you left it.

## What Amnify will not do

<Warning>
  * It never pushes to your default branch.
  * It never merges its own pull request.
  * It never bypasses your branch protections, required reviews or CI.
</Warning>

Amnify can propose a change. Shipping it stays yours.