How Reviews Work

VULQN is designed to keep review feedback close to the PR. A developer should be able to open a pull request, see the review status, fix or acknowledge findings, and move on without learning a separate workflow.

Review lifecycle

When a pull request is opened, reopened, or updated on an enabled repository, VULQN checks:

The repository is active in VULQN.
The PR target branch is allowed by the repository branch filter.
The optional .vulqn.json trigger rules allow the PR.
The workspace has an active trial, subscription, or unexpired add-on credits.
The PR is not paused or set to ignore automatic reviews.

If those checks pass, VULQN reviews the PR changes and posts results back to the PR.

What appears on the PR

A completed review can add three visible things:

Surface	Purpose
Inline comments	Specific findings on the changed files and lines.
PR description block	A review summary, confidence score, category breakdown, and files reviewed.
Build status	A pass/fail signal that can be used in the merge box or branch protection rules.

Inline comments include severity, category, confidence, and fix guidance when the finding is actionable.

Severity and categories

VULQN uses three severities:

Severity	Meaning
`critical`	Should block merge until understood or fixed. Examples include security flaws, broken authorization, data-loss risks, serious correctness bugs, or public API regressions.
`medium`	Should be addressed, but may not block every merge. Examples include brittle behavior, missed edge cases, weak tests, maintainability risks, or performance issues.
`praise`	Positive signal worth preserving. Praise does not represent a problem.

Categories help teams understand the shape of recurring issues:

Security
Bug
Performance
Maintainability
Testing
Documentation
Error handling
Guideline

Confidence score and build status

Every completed review gets a confidence score from 0 to 100. By default:

Each critical finding subtracts 25 points.
Each medium finding subtracts 8 points.
Each praise finding adds 5 points, capped at 15 bonus points.
A critical finding fails the build status.
A score below 80 fails the build status.

You can tune these values in .vulqn.json.

Re-reviews

When new commits are pushed to a PR, VULQN reviews the updated changes. Existing findings are deduplicated so the same issue is not repeatedly posted as a new comment.

To reduce noise and protect credits, VULQN pauses automatic reviews after a PR has been reviewed 5 times. When that happens, VULQN posts a notice with the commands you can use:

!vulqn review
!vulqn full review
!vulqn resolve

Manual review commands can still run after the pause. See !vulqn Commands for the exact behavior.

Resolved and acknowledged findings

Findings have a lifecycle:

Status	How it happens
Open	VULQN posted the finding and it has not been resolved or acknowledged.
Resolved	A user resolves the thread, uses `!vulqn resolve`, or VULQN verifies the issue is fixed on a later review.
Acknowledged	A user replies with `!vulqn ack`, uses `!vulqn learn` on the finding, or leaves a clear natural-language reply that signals the team accepts the code as-is.
Outdated	The original code context is no longer available, such as when a file is removed.

Acknowledged findings are not re-emitted as equivalent findings on later reviews. This is useful for compatibility tradeoffs, intentional shortcuts, and team conventions that VULQN should remember.

Large pull requests

VULQN prioritizes source code over lower-signal files when a PR is very large. Some generated, binary, lock, build, or documentation files may be skipped automatically.

GitHub PRs whose diff exceeds GitHub’s 20,000-line diff limit cannot be reviewed automatically. In that case, break the work into smaller PRs.