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

# Fix and retest

> Get a remediation prompt, apply the change, and record an honest verification result.

Remediation is a separate, explicit step. Nothing is edited during an assessment — the
Agent Skill's rule is that source changes happen only after the user chooses to apply a
fix.

## 1. Get the prompt

```bash theme={null}
myrqen fix prompt MYR-001
```

This prints a remediation prompt built from the finding — the root cause, the smallest
durable fix, the framework safeguard to prefer, and the verification that should fail
before the change and pass after it — and records the finding as `fix_suggested`.

The HTML report has the same thing behind **Copy prompt to fix**.

Paste it into your coding agent, or work from it yourself.

## 2. Apply the change

Change the source, run the project's own targeted tests, then re-run the specific security
verification the finding named. Prefer the framework's own safeguard over a hand-rolled
check, and prefer the smallest change that removes the root cause over a broad rewrite.

## 3. Record what actually happened

```bash theme={null}
myrqen fix record MYR-001 --applied --files src/routes/orders.ts
```

Then, only after running the verification:

<Tabs>
  <Tab title="Verification passed">
    ```bash theme={null}
    myrqen fix record MYR-001 --verified
    ```

    The finding's status becomes `fixed_verified`.
  </Tab>

  <Tab title="Verification failed">
    ```bash theme={null}
    myrqen fix record MYR-001 --verification-failed
    ```

    The status stays `fix_applied`. The history keeps both steps.
  </Tab>

  <Tab title="Change reverted">
    ```bash theme={null}
    myrqen fix record MYR-001 --reverted
    ```
  </Tab>
</Tabs>

Options on `fix record`:

| Flag                    | Effect                                           |
| ----------------------- | ------------------------------------------------ |
| `--applied`             | A code change was applied.                       |
| `--verified`            | The targeted security verification passed.       |
| `--verification-failed` | The targeted security verification did not pass. |
| `--reverted`            | The change was reverted.                         |
| `--files a,b`           | Comma-separated changed files.                   |
| `--note "<text>"`       | Free-text note kept with the entry.              |

Exactly one of the four actions is required.

<Warning>
  Never mark a finding verified unless the targeted security verification actually passed.
  A finding reaches `fixed_verified` only through a recorded passing verification — there is
  no other path, and that is the whole value of the field.
</Warning>

## The history is append-only

Every step lands in `fixHistory` on the finding, with the instant, the action, whether
verification passed, the changed files, and any note. The original evidence is preserved
either way, so a reader can see what was claimed, what was changed, and whether it worked.

Inspect it directly:

```bash theme={null}
cat .myrqen/sessions/*/session.json | python3 -m json.tool | less
```

## Try it against the fixture

The repository ships a reversible patch for the bundled vulnerable application, so you can
see the whole loop without editing your own code.

<Steps>
  <Step title="Apply the patch">
    ```bash theme={null}
    node scripts/demo-fix.mjs --apply
    ```

    Then restart the fixture so the change takes effect.
  </Step>

  <Step title="Verify the behaviour actually changed">
    ```bash theme={null}
    node scripts/demo-fix.mjs --verify
    ```

    Before the fix the cross-account read returns 200. After it, 404.
  </Step>

  <Step title="Record it">
    ```bash theme={null}
    cd fixtures/vuln-shop
    myrqen fix record MYR-001 --applied --files src/server.js
    myrqen fix record MYR-001 --verified
    ```

    Try `--verification-failed` first and inspect `.myrqen/sessions/*/session.json`: the
    status stays `fix_applied`, and the history keeps every step.
  </Step>

  <Step title="Put the fixture back">
    ```bash theme={null}
    node scripts/demo-fix.mjs --revert
    ```

    Restart the fixture again. Leaving the patch applied will make
    [`pnpm benchmark`](/guides/benchmark) report a missed finding.
  </Step>
</Steps>

## Retesting the whole application

A fix changes the application, so the honest way to confirm the wider picture is a new
session:

```bash theme={null}
myrqen auto
```

A new session gets a new local report id and its own report files, so the before and after
are both on disk and comparable.