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

# Accepted findings

> How a finding your team rejected stays rejected: on one pull request, or across the repository with accepted: in .codewarden.yml.

A review bot that repeats a finding the team already decided about teaches the team to ignore it. CodeWarden remembers decisions at two levels.

| | One pull request | The whole repository |
| - | - | - |
| Where it lives | CodeWarden's database | `accepted:` in your `.codewarden.yml`, on the base branch |
| Who creates it | CodeWarden, when it concedes in a [conversation](/bot/mentions) | Your team, by committing the lines CodeWarden proposed (or writing them) |
| Who can remove it | An owner, with **Revoke** in the console | Anyone who can commit, by removing the lines |

## On one pull request

When someone replies to a CodeWarden comment with `@codewardenapp`, gives a reason the finding is wrong, and CodeWarden concedes, it says so in the thread and remembers the decision **for that pull request only**. Later pushes to the same pull request do not raise the same finding on the same code.

This works the same for everyone who may talk to CodeWarden, including the author of a pull request from a fork.

## On the whole repository

When the person whose reason CodeWarden accepted has write access to the repository, its reply also carries a folded section, **Make this apply to the whole repository**, with the exact lines to add to `.codewarden.yml`:

```yaml theme={null}
accepted:
  - path: lib/widgets/clicks.ex
    problem: "read-modify-write on the click counter"
    category: bug
    code: |
      |> Ecto.Changeset.change(clicks: link.clicks + 1)
    reason: "the counter is advisory and the nightly job recomputes it"
```

CodeWarden never writes to your repository. You commit the lines, review them like any other change, and they apply to every pull request into that branch once they are merged.

A person without write access, such as the author of a pull request from a fork, never gets a proposal. Their decision applies only to their own pull request, so an outside contributor cannot silence a finding for everyone.

## The fields

| Field | Required | Meaning |
| - | - | - |
| `path` | yes | The file, from the repository root. Exact path, not a glob. |
| `code` | yes | The code the decision is about, copied from the file. Up to 2,000 characters. |
| `problem` | no | What was reported, in one line, for the person reading the file later. |
| `category` | no | One of `bug`, `security`, `performance`, `logic`, `acceptance`, `fix`. When absent, the decision applies to any category. |
| `reason` | no | Why it is not a defect here. |

An entry without `path` or `code`, or with `code` over 2,000 characters, is dropped and the rest of the file still applies.

## What counts as the same finding

A finding is held back when all three hold:

1. it is on the same `path`;
2. it has the same `category`, if the decision names one;
3. the decision's `code` still appears in the file being reviewed, and the finding points at that code (or within three lines of it). Whitespace at the start and end of each line is ignored, so re-indenting the code does not undo the decision.

The decisions are also shown to the model, which is asked not to raise them again. The three checks above are applied to its answer regardless, so a decision holds even when the model does not listen.

What that means in practice:

* **It follows the code, not a line number.** The same code moved to another line is still covered.
* **It ends when the code changes.** When the quoted text is no longer in the file, the decision stops applying and the finding can come back.
* **It is limited to that code.** A finding on other code in the same file is reported, even of the same category. So is a finding in another file, and a finding of another category when the decision names one.
* **Quote the code the decision is about.** The smallest piece that identifies it is best; if the same text appears twice in the file, the decision covers both places.

There is no wildcard and no "everything" form. `accepted:` cannot switch a review off. To leave a whole file alone, use [`ignore`](/configure/codewarden-yml#ignore).

## Seeing what was held back

Every finding a decision held back is recorded on the review, with the decision that held it back, so a silenced review can be told apart from one that found nothing. (The review's page in the console does not list them yet.)

The **Decided** page of each repository (`/orgs/<login>/repos/<repo>/decided` in the console) shows three lists:

* **On one pull request**: decisions made in conversations, with the quoted code, the reason, who made it and when. Owners can **Revoke** one; the next review of that pull request can raise the finding again. Members can see them but not revoke.
* **On the whole repository**: the `accepted:` entries as they were on the last review, with a link to `.codewarden.yml` on GitHub.
* **Offered and not committed**: proposals nobody has merged yet. Until someone does, each applies only to its own pull request.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.