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

# Bug reports

> What's in a QLane bug report — severity, repro steps, screenshots, DOM and console logs — and how to triage, dismiss, or push it to Linear or Jira.

When the agent finds a defect, it files a **bug report**. Bug reports are evidence-grade: they include the exact reproduction steps, a screenshot at the moment of failure, expected vs. actual behaviour, and a severity tag grounded in user impact.

## What's in a bug report

Every bug report has:

* **Title** — a one-liner describing the symptom (e.g. *"Checkout submit reports success without making the API call"*).
* **Severity** — `critical`, `major`, or `minor`. Critical = revenue or data loss path. Major = a key user flow is broken. Minor = visual or non-blocking.
* **Expected vs. actual** — what the agent thought should happen and what it observed.
* **Reproduction steps** — the click path the agent followed, in plain English, with the URLs it landed on.
* **Screenshot** at the moment of failure.
* **DOM snapshot** of the page, downloadable from the bug detail.
* **Console and network logs** captured around the failure.
* **Source link** *(when available)* — the file and line the agent thinks is most likely involved. When the agent is confident, this anchors a comment in the GitHub review.

## Triaging a bug

There are three ways to act on a bug:

1. **It's a real regression.** Fix the code and push. The QLane check re-runs automatically on the new commit. When the fix lands, the bug is closed.
2. **It's a flake.** Mark the bug as **dismissed** with a reason. The agent learns from dismissals — the same flake won't be filed again in this project without a higher confidence threshold.
3. **It's expected behaviour** (the test case is wrong). Edit the test case to reflect the new expectation. Future runs use the updated case.

## Pushing bugs to your tracker

Connect Linear, Jira, or GitHub Issues from **Settings → Integrations**. Once connected, you can:

* **Auto-file** critical bugs into the configured project/repo.
* **Push selected bugs** manually from the bug detail page.
* **Round-trip status** — closing the ticket in your tracker marks the QLane bug as fixed; the next QLane run confirms.

The agent can also be invoked **from your tracker** — see [Triggers](/triggers) for `@qlane verify ENG-247` and similar.

## What QLane won't file

To keep the signal-to-noise ratio high, QLane never files:

* **Style nits or layout opinions** — that's what code-review tools are for.
* **"Looks fine to me" comments** — silent on pass.
* **Console warnings without user impact** — unless they correlate with a failed test case.

Bug reports are reserved for things a human would call a bug.

## The "evidence-grade" bar

The agent doesn't file a bug until it has a reproducible repro:

1. **First observation** — something looked wrong (API call missing, UI didn't update, an error was visible).
2. **Re-run check** — the agent re-attempts the same path. If the failure reproduces, it captures evidence.
3. **Evidence capture** — screenshot, DOM snapshot, console, network, click path.
4. **Severity assessment** — graded against the user impact, not the technical surface.

This is the difference between a bug report you trust and one you ignore. Every QLane bug is one a human could reproduce on their own from the report alone.