> ## Documentation Index
> Fetch the complete documentation index at: https://personal-ce79cb71.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# How BugViper Reviews Your Pull Requests

> Understand the full BugViper review pipeline: from GitHub webhook trigger to inline comments on your PR. Seven steps, explained clearly.

When you ask BugViper to review a pull request, it doesn't just read the changed lines in isolation — it builds a live model of your codebase, scores every file by how broadly it impacts everything else, and runs one or more AI agents that see the full picture before posting a single comment. The entire pipeline — from cloning your repo to posting inline comments — runs automatically inside a secure sandbox, and completes without touching your infrastructure.

<Note>
  All code analysis happens inside isolated [E2B](https://e2b.dev) sandboxes. Your code never runs on BugViper's servers and never touches your own infrastructure.
</Note>

<Steps>
  <Step title="Trigger">
    You (or any PR collaborator) post a comment on the pull request to kick off a review:

    * **`@bugviper full review`** — runs a complete AI-powered review using your configured default mode (Normal or Deep).
    * **`@bugviper review`** — triggers an incremental review, focusing on the files changed since the last review run.

    BugViper's GitHub App receives the comment event via webhook and dispatches the job to the review service asynchronously.
  </Step>

  <Step title="Clone + Call Graph">
    BugViper provisions a fresh E2B sandbox and clones your repository at the exact commit SHA of the PR head. Inside the sandbox, it runs a full **call graph analysis** using [tree-sitter](https://tree-sitter.github.io/tree-sitter/) AST parsing across all supported languages.

    The call graph maps every function, class, and module in your codebase — and every edge between them (function calls, imports, references). This gives BugViper a structural understanding of how the code is connected, not just what changed.
  </Step>

  <Step title="Blast Radius Scoring">
    Using the call graph, BugViper calculates a **blast radius score** for every file touched by the PR. A file's blast radius reflects how many other modules depend on it — directly or transitively.

    A change to a low-level utility used by 40 other modules scores much higher than a change to a self-contained leaf component. This score guides how agents allocate attention during review.
  </Step>

  <Step title="Batching">
    Changed files are grouped into small, coherent **batches** using [Louvain community detection](https://en.wikipedia.org/wiki/Louvain_method) — a graph-partitioning algorithm that keeps tightly-connected files together.

    Batching ensures that when an agent reviews a file, it also sees the other files it directly interacts with. This dramatically reduces the chance of a finding being based on incomplete context.
  </Step>

  <Step title="Agent Review">
    BugViper routes each batch through one or more AI agents depending on the review mode:

    * **Normal mode** — 4 file batches flow through a single generalist agent sequentially. Fast and efficient for everyday pull requests.
    * **Deep mode** — 2 file batches are processed in parallel by 3 specialized sub-agents running in their own isolated E2B containers: one focused on **Bug Correctness**, one on **Security**, and one on **Performance**.

    Each agent receives the batch contents, the call graph context for those files, and the actual PR diff — so it understands both what changed and why it matters.
  </Step>

  <Step title="Verifier Pass">
    Before any findings are surfaced, every issue goes through a **verifier pass**. A dedicated verifier agent checks each finding against the actual PR diff and assigns one of three labels:

    | Label          | Meaning                                                                                         |
    | -------------- | ----------------------------------------------------------------------------------------------- |
    | `valid`        | Confirmed issue within the changed lines — high confidence, will be posted as an inline comment |
    | `nitpick`      | Minor style or preference issue — low confidence, not posted inline                             |
    | `outside_diff` | Real concern, but in code outside the PR's changed lines — not posted inline                    |

    This step is what eliminates false positives. An agent might flag a risk in a function that the PR didn't actually touch — the verifier catches that and suppresses the comment.
  </Step>

  <Step title="Dedup + Post">
    When multiple batches or agents identify the same underlying issue, BugViper's **dedup pass** merges them into a single finding before anything is posted.

    After deduplication:

    * **High-confidence `valid` issues** are posted as **inline comments** on the relevant lines of the PR diff.
    * The **full review summary** — including all findings, positive observations, and context — is posted as the PR review body.
    * All issues are persisted for tracking through the [issue lifecycle](/concepts/issue-lifecycle).
  </Step>
</Steps>