Comprobaciones del repositorio

Genera comprobaciones automáticamente

En el panel, elige Configurar comprobaciones del repositorio en Primeros pasos. HeyDeer lee el repositorio y sus pull requests anteriores, y luego abre un pull request que añade comprobaciones. No usa créditos.

Para que las escriba tu propio agente de programación, dale este prompt:

Add HeyDeer repository checks to this repository following the guide below, and open a pull request with them. If it needs no new check, explain why instead.

# Write repository checks

A check is a Markdown file in `.agents/checks/` that states a requirement. Each check adds a reviewer of its own to every pull request that changes the files it covers, on top of a general review that already looks for common bugs and security issues. Add one only for a requirement that is specific to this codebase, costly to miss and easy to overlook.

1. Learn what the team cares about: the code, AGENTS.md or CLAUDE.md, REVIEW.md, the checks already in `.agents/checks/`, and as much of the merged pull requests and their review discussions as you need to see what reviewers keep asking for and where bugs were fixed.
2. Choose the requirements, usually one or two, leaving out what existing checks cover. Give each check one requirement or a few closely related ones, and keep one requirement in one check.
3. Write each check as `.agents/checks/<name>.md`, its name starting with a letter or digit and using only letters, digits, `.`, `_` and `-`, excluding every case variant of `README.md`:
   - Start with YAML frontmatter whose `files` lists glob patterns, relative to the repository root, for the files where the requirement can break. A pattern without a slash matches in any folder, a `!` prefix excludes, and the last matching pattern decides; exclusions need an including pattern. Compare the patterns with `git ls-files` so they match those files and little else. Add `skills` only to name repository skills the check needs.
     ```
     ---
     files:
       - "src/api/**/*.ts"
       - "!**/*.test.ts"
     ---
     ```
   - Below it, state the requirement as a condition on the code: what breaks it, what satisfies it and why it matters, with a short incorrect and correct example from this codebase. Most checks fit on a screen; a file can be up to 16000 bytes.
   - Write it in the language of the repository's own Markdown, such as its README and AGENTS.md, even when you write the pull request in another language.
4. In the pull request, say what each check covers and why it is worth a reviewer. Link the discussions that led to a check when there are any.

Añadir una comprobación

1. Crea un archivo Markdown en .agents/checks/, como api-workspace-scope.md.
2. Empiézalo con un frontmatter que enumere en files los archivos que abarca la comprobación.
3. Debajo del frontmatter, escribe el requisito: qué lo incumple, qué lo cumple y por qué importa.
4. Haz commit del archivo en un pull request. HeyDeer lee las comprobaciones del pull request, así que la comprobación nueva se aplica a la revisión de ese mismo pull request. Consulta Qué puede cambiar un pull request.

.agents/checks/api-workspace-scope.md

---
files:
  - "src/api/**/*.ts"
  - "!**/*.test.ts"
---
# API handlers scope queries to the caller's workspace

Every query in an API handler that reads or writes a table with a
`workspace_id` column must filter on the workspace returned by
`requireWorkspace()`. Without that filter, one customer can read
or change another customer's data.

Fail when a handler queries such a table without that filter.
Pass when every such query filters on the workspace, or when the
handler only touches tables without a `workspace_id` column.

Incorrect:

```ts
const invoice = await db.query.invoices.findFirst({
  where: eq(invoices.id, id),
});
```

Correct:

```ts
const { workspaceId } = await requireWorkspace(req);
const invoice = await db.query.invoices.findFirst({
  where: and(eq(invoices.id, id), eq(invoices.workspaceId, workspaceId)),
});
```

• Cada archivo .md situado directamente en la carpeta cuyo frontmatter tenga files es una comprobación. HeyDeer ignora los demás archivos de la carpeta, como README.md y las comprobaciones escritas para otras herramientas de revisión.
• Los nombres de archivo empiezan por una letra o un dígito y solo usan letras, dígitos, ., _ y -.

Escribir una comprobación eficaz

Cada comprobación aplicable tiene su propio revisor, así que es exhaustiva pero usa más créditos. Reserva las comprobaciones para requisitos fáciles de pasar por alto y caros si se pasan por alto, y pon el resto en REVIEW.md o AGENTS.md.

• Escribe lo que es propio de tu código. Cada revisión ya busca errores y problemas de seguridad comunes, así que una comprobación como “Las consultas deben ser seguras” añade coste sin detectar más.
• Da a cada comprobación un requisito, o unos pocos muy relacionados. Una comprobación que agrupa requisitos no relacionados revisa cada uno con menos profundidad.
• No repartas un requisito entre varias comprobaciones, y limita files a donde el requisito puede romperse, para que la comprobación solo se ejecute donde importa.
• Escribe el requisito como una condición sobre el código: qué lo incumple, qué lo cumple y por qué importa, para que HeyDeer pueda juzgar casos que no previste. Añade un ejemplo breve incorrecto y otro correcto de tu código.
• La mayoría de las buenas comprobaciones caben en una pantalla. Si varias comprobaciones necesitan el mismo contexto, muévelo a una skill.
• Prueba una comprobación nueva en un pull request que incumpla el requisito y confirma que aparece un hallazgo con el nombre de tu comprobación.

Cómo aparecen los resultados

Cuando el código incumple una comprobación, HeyDeer informa de un hallazgo que indica el archivo de la comprobación tras Comprobación del repositorio:, en GitHub y en HeyDeer. Una comprobación sin hallazgos no añade nada a la revisión.

Estos hallazgos cuentan como cualquier otro para la comprobación HeyDeer Review y la aprobación automática. El resumen de la comprobación HeyDeer Review también cuenta las comprobaciones del repositorio que fallaron.

Si HeyDeer no puede terminar una comprobación, la comprobación HeyDeer Review muestra Revisión incompleta y falla; solicita otra revisión.

Referencia del frontmatter

El frontmatter es YAML entre dos líneas ---, con las claves siguientes.

HeyDeer ignora las demás claves, como las que leen otras herramientas de revisión.

Si una comprobación no es válida, por ejemplo porque sus patrones solo contienen exclusiones, HeyDeer la omite y la indica en Notas de la revisión. La revisión se realiza igualmente, pero HeyDeer no la aprueba automáticamente.

Qué archivos cubre una comprobación

Una comprobación se aplica cuando al menos un archivo modificado coincide con ella, y HeyDeer la centra en esos archivos.

• Usa files: ["**"] para abarcar todos los archivos modificados.
• Los patrones son relativos a la raíz del repositorio y admiten *, ** y {a,b}. Un patrón sin barra, como *.sql, coincide en cualquier carpeta.
• Los patrones se aplican en orden y decide el último que coincide con un archivo, así que un patrón posterior puede incluir archivos que una exclusión anterior había quitado.
• Los archivos generados nunca coinciden.

Si parece que se ignora una comprobación, consulta Solución de problemas.

Límites

Un espacio de trabajo puede iniciar hasta 30 tareas de generación de comprobaciones en cualquier período de 30 días, sumando todos sus repositorios, incluidas las tareas que fallan o se cancelan.

Un archivo de comprobación puede tener hasta 16.000 bytes.

Una revisión ejecuta como máximo 10 comprobaciones aplicables, por orden de nombre de archivo. HeyDeer enumera las demás en Notas de la revisión, la comprobación HeyDeer Review muestra Revisión incompleta y HeyDeer no aprueba automáticamente esa revisión.

Acota o combina comprobaciones para que coincidan menos. Para elegir cuáles se ejecutan primero, pon un número delante de su nombre de archivo, como 10-auth.md.

Cuando una comprobación no es válida

Los archivos sin frontmatter o sin una clave files se ignoran. Los archivos con YAML no válido, frontmatter demasiado grande, patrones files vacíos o solo exclusiones se omiten y se indican.

Para las comprobaciones que coinciden con archivos modificados, HeyDeer también valida el nombre y el tamaño del archivo y los nombres de las habilidades. Las comprobaciones no válidas se omiten y se muestran en Notas de la revisión. La revisión continúa, pero HeyDeer no la aprueba automáticamente.

Corrige la comprobación en el pull request y comenta @heydeer review.