Reviewing & approving fixes

When a card reaches the Review stage, the AI has opened a pull request in your repository and the work is in your hands. This is where you decide whether the fix ships.

Reviewing the pull request

A Review card shows a link (or links) to the generated pull request. Open it in your version-control provider and review it the way you’d review any change — read the diff, check that CI passed, and confirm the fix is correct and complete. The board doesn’t replace your normal code review; it points you straight to it.

Approving

Once you’re satisfied, approve the fix from the card. The approve action comes in two forms, depending on your organization’s guardrail policy:

• Approve — approve only. The card advances, but you merge the pull request yourself in your version-control provider.
• Approve & merge — approve and merge the pull request automatically.

The button wording always reflects your current policy, so you can tell at a glance which behavior you’ll get.

When the fix is approved (and merged, if your policy allows it), the card moves to Approved.

Re-testing an approved fix

Approving a fix says the code looks right. Retest proves it: from an approved card’s drawer, choose Retest and Vortex re-runs the original attack against the same endpoint to confirm the vulnerability is actually gone. It’s a targeted replay of one finding, not a fresh pen-test — so it doesn’t cost a remediation or pen-test credit, doesn’t count against your scan limits, and doesn’t add a report to your history.

The retest returns one of three verdicts:

Verdict	What it means	What happens
Validated	The attack no longer works — the fix held.	The card stays Approved and is marked validated.
Regressed	The attack still works — the finding is back.	The card returns to Findings so you can remediate it again.
Inconclusive	The replay couldn’t reach a verdict (for example, the scan timed out).	Nothing changes; you can retest again.

While a retest runs, the card shows a re-validating indicator and the button is disabled so you can’t launch two at once. If a retest never returns a verdict, the indicator clears itself after about 30 minutes and you can try again.

Note

Retest is available once the flow is enabled for your organization, and — like the other board actions — is gated by allow-rules. To turn a proven exploit into a repeatable check you can re-run on demand, see Security regression suites.

Handling merge conflicts and failures

If a merge can’t complete — for example, the branch has conflicts or the merge fails — the card stays in Review and shows an error. Resolve the conflict in your repository and retry, or reject the fix if it’s no longer wanted.

Rejecting a fix

On a Review or Blocked card, choose Reject. A reason is required. Rejecting closes any open pull requests for that card and moves it to the Rejected side state, leaving a record of why.

Note

Approving and rejecting are gated by allow-rules. If you don’t see these controls, you may not have permission to act on fixes.

Next

To change whether approving also merges, see Guardrails & policies.