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

# Cómo funciona una revisión

> Qué lee CodeWarden, qué omite, cómo trata los pushes posteriores al primero y qué publica.

## Los pasos

1. **GitHub notifica a CodeWarden.** Se abre un pull request, se reabre, se marca como listo para revisión o recibe un push. Los pull requests en borrador no se revisan.
2. **Verificaciones antes de leer nada.** La revisión no se ejecuta si el repositorio está [desactivado](https://docs.codewarden.co/es/configure/repositories.md) en la consola, si la instalación está suspendida, o si la organización no tiene un plan vigente o ya usó su [cupo](https://docs.codewarden.co/es/account/plans-and-ai-turns.md). No se publica nada en el pull request y, salvo en un repositorio desactivado, la revisión queda registrada en la consola con el motivo.
3. **Lectura a través de la API de GitHub.** La lista de archivos modificados, el título y la descripción del pull request, y `.codewarden.yml` de la **base branch**. Si el archivo [omite este pull request](https://docs.codewarden.co/es/configure/codewarden-yml.md#skip), la revisión se detiene aquí y queda registrada como `skipped`. Si no, CodeWarden lee el contenido actual de cada archivo modificado que vale la pena revisar. No se clona nada y no se ejecuta nada.
4. **Contexto adicional, cuando lo hay.** Un [ticket de Jira](https://docs.codewarden.co/es/integrations/jira.md) o un [issue de Sentry](https://docs.codewarden.co/es/integrations/sentry.md) enlazado en el pull request, y hasta tres archivos que el pull request no toca pero que usan código que él cambia, encontrados con la búsqueda de código de GitHub dentro del repositorio y leídos desde la base branch.
5. **Una llamada al modelo.** Todo lo anterior va al modelo en una sola solicitud.
6. **Filtro.** Se descartan los hallazgos por debajo del umbral de confianza, los que exceden el tope de comentarios, los que alguien ya decidió, los ya publicados en un push anterior o los que están fuera de las líneas que agregó el pull request.
7. **Publicar una revisión.** Todos los comentarios en línea salen juntos en una sola revisión de GitHub, que nunca aprueba ni pide cambios.

## Qué archivos se leen

Estos se omiten sin que lo pidas:

| Tipo | Ejemplos |
| - | - |
| Archivos de bloqueo (lock) | `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`, `mix.lock`, `Cargo.lock`, `poetry.lock`, `go.sum`, `composer.lock`, cualquier `*.lock` |
| Código generado | `*.pb.go`, `*_pb2.py` |
| Archivos minificados | `*.min.js`, `*.min.css` |
| Directorios de build y de terceros | `dist/`, `build/`, `_build/`, `deps/`, `node_modules/`, `vendor/`, `.yarn/` |
| Binarios y recursos | imágenes, fuentes, PDF, archivos comprimidos, `*.map`, `*.snap` |
| Prosa | `*.md`, `*.mdx`, `*.markdown`, `*.rst`, `*.adoc`, `*.txt` |
| Cambios muy grandes | un archivo con más de 1.500 líneas modificadas |
| Renombrados puros | un archivo movido sin cambios en su contenido |
| Sin diff | un archivo que GitHub envía sin patch |

Puedes agregar rutas con `ignore` y rescatar las incorporadas con `unignore` en [`.codewarden.yml`](https://docs.codewarden.co/es/configure/codewarden-yml#ignore). Un archivo sin diff, o con más de 1.500 líneas modificadas, no se puede rescatar.

Los archivos omitidos se le nombran al modelo, para que sepa que forman parte del pull request y no los reporte como faltantes.

### Cuánto de cada archivo

Los archivos pequeños (de menos de unos 20.000 caracteres) se envían completos, para que el modelo pueda ver una cláusula de guarda diez líneas arriba del cambio. Los archivos más grandes se envían como ventanas de 40 líneas alrededor de cada cambio. Cuando un pull request es muy grande, las ventanas se reducen, y solo después se dejan fuera, por nombre, los últimos archivos.

## Revisión incremental

La primera revisión de un pull request lo lee todo. Después, cada push se revisa solo por lo que cambió.

| Situación | Qué pasa |
| - | - |
| Primera revisión del pull request | **Completa.** Cada línea que agregó el pull request puede recibir un comentario. |
| Un push posterior | **Incremental.** Solo las líneas que el pull request agregó *y* que este push tocó pueden recibir un comentario. |
| Un push que solo tocó archivos omitidos, incluido el primer push | Nada que revisar. Ninguna llamada al modelo, ningún turno de IA, nada publicado. Si fue el primer push, el siguiente con código se revisa completo. |
| El mismo commit entregado de nuevo | Nada que revisar. Ninguna llamada al modelo, ningún turno de IA. |
| Un force push que eliminó el último commit revisado | **Completa** otra vez, y se retiene todo comentario que CodeWarden ya hizo en el pull request para no repetirlo. |

"El último commit revisado" significa la última revisión cuyos comentarios pudiste ver: una que se publicó o que no encontró nada. Una revisión que falló o se omitió no cuenta, así que el siguiente push se compara con código que alguien realmente revisó.

La revisión incremental no se puede desactivar. Repetir un comentario que el autor ya respondió es como la gente aprende a dejar de leer un bot de revisión.

## Qué se publica

* **Una primera revisión** publica un resumen del cambio, incluso con cero comentarios.
* **Una revisión de seguimiento sin nada que decir no publica nada.**
* **Los comentarios en línea** van solo en líneas que el pull request agregó. GitHub rechaza una revisión completa si un solo comentario cae fuera del diff, así que cualquier comentario así se descarta antes de publicar.
* **El resumen termina** con cuántos comentarios se publicaron y cuántos se filtraron. Cuando se leyó un ticket de Jira, agrega `Checked against PROJ-123.` y una lista de los requisitos del ticket, cada uno marcado según lo que muestra este cambio ([detalles](https://docs.codewarden.co/es/integrations/jira.md#what-the-summary-shows)). Cuando se leyó un issue de Sentry, indica cuántos archivos del stack trace toca el cambio.

## Qué decide qué comentarios se publican

| Regla | Valor por defecto | ¿Puedes cambiarla? |
| - | - | - |
| Confianza de al menos 0,7 | siempre | No. Medido en 208 ejecuciones, los defectos reales y los comentarios erróneos puntuaron ambos entre 0,92 y 0,99, así que otro umbral no cambió nada. |
| Como máximo 8 comentarios por revisión | `balanced` | Sí, con [`profile`](https://docs.codewarden.co/es/configure/codewarden-yml#profile): 4, 8 o 15. |
| Gravedad | se publican todas las gravedades | No. Los hallazgos se ordenan de peor a mejor antes del tope, así que uno `low` se publica solo cuando nada peor necesita el espacio. |
| Ya decidido | rechazado en una conversación, o listado bajo `accepted:` | Sí. Consulta [Hallazgos aceptados](https://docs.codewarden.co/es/configure/accepted-findings.md). |

## Cuando una revisión falla

Si el modelo no responde a tiempo, la revisión se reintenta con menos de cada archivo, hasta tres intentos en total. Si el modelo responde dos veces con algo que no es el JSON que se le pidió, la revisión se detiene en lugar de adivinar. Una revisión que falla no publica nada, no usa ningún turno de IA y aparece en la consola con el estado `failed`. Un problema con Jira, Sentry o `.codewarden.yml` nunca hace fallar una revisión: la revisión continúa sin esa fuente.


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