Skip to main content

Findings, Severity, and Expected Output

Buzzbin is designed to produce a smaller number of stronger, actionable findings instead of a large stream of weak warnings. Each finding carries a few important labels so you can quickly judge urgency and confidence.

What a finding contains​

Each finding usually includes:

  • Severity: how urgent it is
  • Category: what kind of problem it is
  • Confidence: how sure the reviewer is
  • Message: what is wrong
  • Recommendation: what to change
  • Suggestion code: when the fix is local and clear, an inline replacement may be included

In addition to individual findings, a run may also include a summary and a merge-risk assessment.

Severity levels​

Buzzbin uses these severity levels:

  • INFO: low-risk note or informational guidance
  • LOW: a small issue with limited impact
  • MEDIUM: an issue worth reviewing before merge
  • HIGH: an important issue with likely effect on behavior, security, or stability
  • CRITICAL: an issue that makes merging risky without a fix

Finding categories​

These categories exist in the product:

  • SECURITY: for example access-control bypass, secret exposure, or unsafe input handling
  • BUG: direct logic or behavior defects
  • PERFORMANCE: expensive repeated work, N+1 queries, or avoidable heavy execution
  • CORRECTNESS: wrong business outcome or invalid resulting data
  • MAINTAINABILITY: structure or coupling that makes the code harder to evolve safely
  • READABILITY: code that is hard enough to understand that it raises real risk
  • STYLE: consistency or style issues still worth surfacing
  • CONVENTION: breaking established framework or team patterns
  • REDUNDANCY: duplicate or dead logic
  • DOCUMENTATION: misleading or missing explanation, naming, or docs
  • TESTING: missing or weak tests around risky changes
  • OTHER: issues that do not fit the categories above

What confidence means​

Confidence shows how certain the reviewer is that the issue is real:

  • HIGH: direct evidence exists
  • MEDIUM: likely but still worth your judgment
  • LOW: speculative

In Buzzbin's design, low-confidence findings are generally not posted. The goal is to keep merge requests from being filled with weak noise.

Simple example of expected output​

This is the rough shape of a strong finding:

Severity: High
Category: Bug
Confidence: High

The cache key does not include the organization slug, so data from one tenant can
be reused in another tenant's request.

Recommendation:
Include `org.slug` in the cache key so tenant-scoped results cannot collide.

When the fix is short and localized, you may also see a suggestion code block that can replace the affected lines directly.

Examples of category and severity together​

  • SECURITY + CRITICAL: an authorization check can be bypassed and sensitive data may leak
  • BUG + HIGH: a condition behaves incorrectly for real users or real data
  • PERFORMANCE + MEDIUM: an extra query inside a loop becomes expensive under load
  • TESTING + LOW: a risky area changed without enough regression coverage

Merge risk is different from a finding​

Merge risk is a whole-MR summary, not a single-line finding. A merge request can have only a few findings and still receive a higher merge-risk score because of the changed area or the nature of the change.

Why a finding may not be posted​

An issue may have been detected but not surfaced publicly, for example because:

  • its confidence was low
  • its category is disabled in your review config
  • the finding was later resolved or superseded

That filtering is intentional and is part of how Buzzbin keeps noise under control.