> ## 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.

# Hallazgos aceptados

> Cómo un hallazgo que tu equipo rechazó sigue rechazado: en un pull request, o en todo el repositorio con accepted: en .codewarden.yml.

Un bot de revisión que repite un hallazgo sobre el que el equipo ya decidió enseña al equipo a ignorarlo. CodeWarden recuerda las decisiones en dos niveles.

| | Un pull request | Todo el repositorio |
| - | - | - |
| Dónde vive | La base de datos de CodeWarden | `accepted:` en tu `.codewarden.yml`, en la base branch |
| Quién la crea | CodeWarden, cuando cede en una [conversación](https://docs.codewarden.co/es/bot/mentions.md) | Tu equipo, al hacer commit de las líneas que CodeWarden propuso (o al escribirlas) |
| Quién puede quitarla | Un propietario, con **Revocar** en la consola | Cualquiera que pueda hacer commit, quitando las líneas |

## En un pull request

Cuando alguien responde a un comentario de CodeWarden con `@codewardenapp`, da una razón por la que el hallazgo está equivocado y CodeWarden cede, lo dice en el hilo y recuerda la decisión **solo para ese pull request**. Los pushes posteriores al mismo pull request no vuelven a plantear el mismo hallazgo sobre el mismo código.

Esto funciona igual para todas las personas que pueden hablar con CodeWarden, incluido el autor de un pull request desde un fork.

## En todo el repositorio

Cuando la persona cuya razón aceptó CodeWarden tiene acceso de escritura al repositorio, su respuesta también lleva una sección plegada, **Make this apply to the whole repository**, con las líneas exactas para agregar a `.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 nunca escribe en tu repositorio. Tú haces commit de las líneas, las revisas como cualquier otro cambio, y se aplican a todos los pull requests hacia esa base branch una vez que se haga merge.

Una persona sin acceso de escritura, como el autor de un pull request desde un fork, nunca recibe una propuesta. Su decisión se aplica solo a su propio pull request, así que un colaborador externo no puede silenciar un hallazgo para todos.

## Los campos

| Campo | Obligatorio | Significado |
| - | - | - |
| `path` | sí | El archivo, desde la raíz del repositorio. Ruta exacta, no un glob. |
| `code` | sí | El código sobre el que trata la decisión, copiado del archivo. Hasta 2.000 caracteres. |
| `problem` | no | Qué se reportó, en una línea, para quien lea el archivo después. |
| `category` | no | Una de `bug`, `security`, `performance`, `logic`, `acceptance`, `fix`. Si falta, la decisión se aplica a cualquier categoría. |
| `reason` | no | Por qué aquí no es un defecto. |

Una entrada sin `path` o sin `code`, o con `code` de más de 2.000 caracteres, se descarta y el resto del archivo sigue aplicando.

## Qué cuenta como el mismo hallazgo

Un hallazgo se retiene cuando se cumplen las tres condiciones:

1. está en el mismo `path`;
2. tiene la misma `category`, si la decisión nombra una;
3. el `code` de la decisión todavía aparece en el archivo que se revisa, y el hallazgo apunta a ese código (o a tres líneas de él). Los espacios al inicio y al final de cada línea se ignoran, así que reindentar el código no deshace la decisión.

Las decisiones también se le muestran al modelo, al que se le pide no volver a plantearlas. Las tres verificaciones anteriores se aplican a su respuesta de todos modos, así que una decisión se mantiene incluso cuando el modelo no hace caso.

Qué significa eso en la práctica:

* **Sigue al código, no a un número de línea.** El mismo código movido a otra línea sigue cubierto.
* **Termina cuando el código cambia.** Cuando el texto citado ya no está en el archivo, la decisión deja de aplicar y el hallazgo puede volver.
* **Se limita a ese código.** Un hallazgo sobre otro código del mismo archivo se reporta, incluso de la misma categoría. También se reporta un hallazgo en otro archivo, y uno de otra categoría cuando la decisión nombra una.
* **Cita el código sobre el que trata la decisión.** Lo mejor es el trozo más pequeño que lo identifique; si el mismo texto aparece dos veces en el archivo, la decisión cubre ambos lugares.

No hay comodín ni forma de "todo". `accepted:` no puede desactivar una revisión. Para dejar en paz un archivo completo, usa [`ignore`](https://docs.codewarden.co/es/configure/codewarden-yml#ignore).

## Ver qué se retuvo

Cada hallazgo que una decisión retuvo se registra en la revisión, junto con la decisión que lo retuvo, para poder distinguir una revisión silenciada de una que no encontró nada. (La página de la revisión en la consola todavía no los lista.)

La página **Decididos** de cada repositorio (`/orgs/<login>/repos/<repo>/decided` en la consola) muestra tres listas:

* **En un pull request**: decisiones tomadas en conversaciones, con el código citado, la razón, quién la tomó y cuándo. Los propietarios pueden **Revocar** una; la siguiente revisión de ese pull request puede volver a plantear el hallazgo. Los miembros pueden verlas pero no revocarlas.
* **En todo el repositorio**: las entradas de `accepted:` tal como estaban en la última revisión, con un enlace a `.codewarden.yml` en GitHub.
* **Ofrecidas y sin commit**: propuestas que nadie ha hecho merge todavía. Hasta que alguien lo haga, cada una se aplica solo a su propio pull request.


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