> ## Documentation Index > Fetch the complete documentation index at: https://docs.coderabbit.ai/llms.txt > Use this file to discover all available pages before exploring further. # Understand findings > Read what CodeRabbit found in a change, judge how ready it is to merge, and decide what to fix first. export const EarlyAccessBadge = ({tip = "This feature is in early access. Enable it by setting `early_access: true` in your `.coderabbit.yaml`, or by toggling Early Access on the web interface.", title = "Early Access", cta = "View configuration", href = "/reference/configuration#param-early-access", disabled = false}) => { return {title} ; }; export const AzureBadge = ({tip = "This feature is available on Azure DevOps.", title = "Azure", cta, href, disabled = false}) => { return {title} ; }; export const BitbucketBadge = ({tip = "This feature is available on Bitbucket.", title = "Bitbucket", cta, href, disabled = false}) => { return {title} ; }; export const GitLabBadge = ({tip = "This feature is available on GitLab.", title = "GitLab", cta, href, disabled = false}) => { return {title} ; }; export const GitHubBadge = ({tip = "This feature is available on GitHub and GitHub Enterprise.", title = "GitHub", cta, href, disabled = false}) => { return {title} ; }; | A review run produces more than a list of comments: every finding carries labels that tell you what kind of remark it is and what fixing it would cost, the Overview sorts findings into what blocks a merge and what does not, and a merge readiness assessment sits beside the provider's own mergeability state. This page covers how to read all of that, how to follow findings across successive review runs, and what to do when a panel is empty or out of date. Everything you read here belongs to the displayed [snapshot](/change-stack/snapshots) — one review run against one head commit. Writing comments, resolving threads, and merging act on the live pull request instead, and are covered in [Review and merge](/change-stack/reviewing). ## How a finding is labeled A finding carries labels drawn from four independent closed vocabularies. They are four separate axes, not one severity ladder: a nitpick can be a security finding, and a critical finding can still be a poor trade-off to fix inside this pull request. Read them together rather than collapsing them into a single ranking. ### Type — what kind of remark it is | Type | Meaning | | ------------------- | -------------------------------------- | | Nitpick | An optional polish suggestion. | | Potential issue | A possible defect requiring attention. | | Refactor suggestion | A suggested structural improvement. | ### Severity — how bad it is Four ranked levels, highest first: **critical**, **major**, **minor**, **trivial**. Two more sit outside the ranking — **info**, which is guidance rather than a problem, and **none**, for a finding with no severity assigned. ### Category — what area it concerns Six areas: **functional correctness**, **security and privacy**, **data integrity and integration**, **performance and scalability**, **stability and availability**, and **maintainability and code quality**. Category tells you which lens a finding is looking through, which is what lets you weigh a security remark differently from a maintainability one on the same change. It is a label, not a filter — see below for what you can actually filter on. ### Effort — what fixing it would cost Effort is the axis most reviewers do not expect, and the one that changes what you do next. It pairs the work a fix takes against the benefit it returns, which lets you pull the quick wins into this pull request and push the heavy lifts into a follow-up without arguing about severity first. | Effort and reward | Meaning | | --------------------------- | -------------------------------------- | | Low effort and high reward | A quick win. | | High effort and high reward | A heavy lift with substantial benefit. | | Low effort and low reward | A low-value fix. | | High effort and low reward | A poor tradeoff. | ## The Overview and Needs your attention The Overview is the view that shows pull-request status, the review summary, and attention items for the displayed snapshot. It is where you start when you want the shape of the change before reading any code. Switching between it and the other views is covered in [Navigate a change](/change-stack/navigation). ### Needs your attention Needs your attention splits what the review produced into four sections, ordered by what stops you from merging: | Section | Meaning | | ------------- | --------------------------------------------------------- | | Blockers | Conditions preventing a safe merge. | | High priority | Important findings that warrant prompt review. | | Pending | Conditions waiting on checks, reviews, or provider state. | | Advisory | Optional cleanup and low-priority guidance. | The ordering is a triage order, not a severity order. Blockers are the things that prevent a safe merge, so they are yours to clear now. Pending items are waiting on something outside your control — a check that has not finished, a review that has not been submitted, a provider state that has not settled — so they are worth checking on rather than working on. Advisory items are optional, and a change can ship with them outstanding. ### Priority and severity bands Overview items are ranked by a priority band from p1 (highest) through p4 (lowest), and carry a severity signal of critical, major, minor, or trivial. Both are ordinal: p1 outranks p2, and a critical signal outranks a major one. Use them to decide reading order within the Overview, not as a promise about what a specific item is — how a given item lands in a particular band is not something the ranking exposes. ## Filter what you are shown Findings can be filtered by **severity**, one bucket at a time: critical, major, minor, trivial. Alongside that you can hide **resolved** threads, hide **outdated** ones, hide comments from **other bots**, and collapse CodeRabbit's findings entirely when you want to read the diff on its own. Separately, range summaries can be filtered by code complexity — low, medium, high — which is the control described in [Read changes](/change-stack/reading-diffs). There is no filter on category, type, or effort. Those three are labels you read on a finding, not axes you can narrow the list by. If you are signed in, these choices are saved to your account rather than to the pull request, so the filter set you settle on follows you to the next review. ## Merge readiness Merge readiness is CodeRabbit's own assessment of the change, assembled from the review. It is a score placed in a band, a confidence figure for that band, and the individual concerns that drove it. | Band | Meaning | | ------- | ----------------------------------- | | Ready | The assessment indicates readiness. | | Caution | The score warrants caution. | | Risky | The score indicates material risk. | | Blocked | Readiness blockers remain. | ### Why confidence sits beside the score Each assessment carries a confidence of high, medium, or low. The confidence qualifies the claim rather than the change: a high-confidence "Ready" says the review had enough to go on and found nothing to stop you, while a low-confidence "Ready" says the assessment could not see enough to say much at all. Treat the second as an absence of evidence and lean on your own reading of the diff. ### Drivers A score is backed by drivers — the individual concerns behind it. Each driver has a severity of critical, major, or minor, and a status that says where it stands: A driver is **open** while the concern is still live, **addressed** once it has been dealt with, **superseded** when a later assessment replaced it, and **not relevant** when it does not apply to this snapshot. Statuses are what make readiness readable across successive review runs. A driver that moves from open to addressed tells you a push fixed something; one that goes superseded tells you a later assessment replaced the concern rather than that anyone acted on it. The two look similar in a summary and mean different things. ### Merge readiness is not mergeability Mergeability is a separate claim, and the two are easy to conflate. Mergeability describes the pull request itself — whether the provider will accept a merge right now: | Mergeability state | Meaning | | ----------------------- | ---------------------------------------------- | | Ready | The pull request is ready to merge. | | Mergeable with warnings | Merging is possible but advisory items remain. | | Not mergeable | Blocking conditions prevent merging. | | Merged | The pull request is merged. | | Closed | The pull request is closed without merging. | A pull request can be mergeable and not ready, or ready and not mergeable. Mergeability answers whether the merge would succeed; merge readiness answers whether the change should be merged. Neither substitutes for the other. The mechanics of actually merging — the available merge actions, the merge queue, and why a merge is refused against a stale artifact — are covered in [Review and merge](/change-stack/reviewing). ## Following the review across snapshots Change Stack can compare review progress across snapshots and show you, finding by finding, whether it remains, was addressed, or was skipped. This is the answer to the question that makes re-reviews tedious everywhere else: after a push, you want to know what changed about the *review*, not re-read the whole thing. Instead of diffing two lists of comments by eye, you read the comparison and go straight to what is still open — and a finding marked skipped is visible as skipped, rather than silently missing from the newer run and mistaken for one that got fixed. You can follow review progress while a run is in flight, and when a completed run invalidates the snapshot you are looking at, Change Stack can refresh the displayed stack onto the new one. Each run resolves to one of five outcomes, all of which you can see and each of which means something different for what is on screen: A run ends as **success**, **skipped**, **error**, **rate limited**, or **cancelled**. Only a successful run produces findings. The other four are worth noticing before you read a quiet screen as good news: a run that was **skipped**, ended in **error**, was **rate limited**, or was **cancelled** has not told you the push cleared anything — it has told you nothing at all, and the previous snapshot is still the most recent complete picture. ## When material is missing or stale Blast Radius and Architecture Impact are generated separately from the review itself, and a snapshot can be missing one or both — either because generation is not switched on for your organization, or because it has not finished for that snapshot yet. An empty graph view is usually one of those, not a change with no impact. Change Stack offers repair actions for exactly these situations. Match the symptom to the request: | What you are seeing | What to request | | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | | Blast Radius or Architecture Impact is empty or out of date | The graph refresh action, where the page offers it. | | Summaries are stale or missing, but the findings are fine | A summary-only update, which regenerates summaries without requesting a full review. | | The review run itself was skipped, ended in error, was cancelled, or was rate limited | Re-review recovery. | None of these are instant. A request is **queued** and the material updates when the work finishes, so the page will not change under you the moment you click. Asking again while one is already running does not queue a second — you are told it is already in progress, or that nothing needed doing — and a request that fails leaves the previous material in place rather than blanking it. A summary-only update regenerates summaries against the snapshot and nothing else. If what is wrong is the findings rather than the prose around them, it will not help — you need a re-review, which produces a new snapshot. Prefer the narrowest request that fixes what you are looking at. A summary-only update leaves your snapshot in place, so links, chat threads, and pending review comments anchored to it stay valid; a full re-review produces a new snapshot and moves the ground under all of them. ## Findings on the graph views Blast Radius and Architecture Impact both carry findings linked to the displayed snapshot, so you can move from an affected system or dependency straight to what the review said about it. Blast Radius shows the code and dependency impact around the change; Architecture Impact shows affected systems, their relationships, and the deltas between them. These artifacts are defined by CodeRabbit Security — see [Blast Radius](/security/blast-radius) and [Architecture review](/security/architecture-review) for what they contain and how they are produced. Change Stack displays them for the snapshot you are on and links their findings back into the change. ## What's next Turn a finding into a comment, a draft review, a suggestion, or a merge. Understand which review run you are reading and when to move to a newer one.