Skip to main content
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 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.