Preguntas frecuentes

Conecta GitHub, elige los repositorios y pide una revisión:

• Inicia sesión con GitHub y elige tu cuenta personal u organización en Elige dónde están tus repositorios. Si no aparece, selecciona Instalar en GitHub y elígela allí.
• En GitHub, elige Only select repositories, marca los que quieres revisar y confirma. En una organización, GitHub pide la aprobación de un propietario, salvo que lo seas tú.
• Decide si HeyDeer revisa por su cuenta: deja Revisar pull requests automáticamente activado para revisar cada push, hasta 5 veces por pull request, o desactívalo para revisar solo cuando alguien lo pida.
• Comenta @heydeer review en un pull request abierto.

Necesitas acceso de escritura al repositorio. Un espacio de trabajo nuevo empieza en el plan gratuito, sin tarjeta de crédito, y los hallazgos llegan como comentarios de revisión en el pull request.

Puedes pedir una revisión justo después de conectar. HeyDeer lee los cambios del pull request en el contexto de todo el repositorio, junto con el título, la descripción y la discusión del PR, y cada revisión ya busca bugs y problemas de seguridad.

Cuando tus primeras revisiones muestren una carencia, añade pautas donde corresponda:

• AGENTS.md para cómo funciona tu código y las convenciones que sigue; los agentes de programación también lo siguen.
• REVIEW.md para lo que las revisiones deben buscar, lo que deben dejar de lado y la gravedad de cada problema.
• Una comprobación del repositorio para un requisito que HeyDeer debe verificar en cada pull request que cambie ciertos archivos.
• Instrucciones de revisión para pautas que un pull request no debe poder cambiar o que se aplican a todos los repositorios.

En cuanto alguien lo pide: comenta @heydeer review en un pull request, selecciona Iniciar revisión en la página Historial de revisiones o selecciona Re-run en la comprobación HeyDeer Review. Un espacio de trabajo nuevo empieza en Solo manual, y justo después de la configuración HeyDeer pregunta si debe revisar automáticamente.

Un administrador del espacio de trabajo puede cambiar la frecuencia cuando quiera en Configuración del espacio de trabajo → Reglas de revisión → Cuándo revisar:

• Una vez por PR revisa un pull request que cumpla los filtros hasta que una revisión termine correctamente.
• En cada push revisa cuando el pull request cumple tus filtros por primera vez y después de cada push que añada commits, hasta 5 veces por defecto.

Por defecto, las revisiones automáticas omiten borradores, forks y actualizaciones de dependencias.

Introdúcelo por etapas y deja que HeyDeer controle los merges cuando tu equipo confíe en sus resultados:

• Pruébalo en unos pocos pull requests: con las revisiones automáticas desactivadas, comenta @heydeer review en un puñado de pull requests de distinto tipo y compara los hallazgos con los de tus revisores.
• Cubre las carencias que muestren esas revisiones: convenciones en AGENTS.md, requisitos en comprobaciones del repositorio y prioridades en instrucciones de revisión.
• Activa las revisiones automáticas en uno o dos repositorios (selecciónalos en Repositorios y luego Cambiar frecuencia) y después en todo el espacio de trabajo.
• Haz obligatoria la comprobación HeyDeer Review, decide sobre la aprobación automática y, en un plan de pago, configura la recarga automática y un límite de uso.

Pasa a la siguiente etapa cuando tu equipo actúe sobre la mayoría de los hallazgos y las revisiones terminen sin notas de la revisión. Los administradores del espacio de trabajo cambian la configuración; cualquiera con acceso de escritura puede pedir revisiones.

Cualquiera de estas opciones revisa el último commit del pull request:

• Comenta @heydeer review en el pull request.
• Selecciona Re-run en la comprobación HeyDeer Review.
• Selecciona Iniciar revisión en la página Historial de revisiones de HeyDeer, donde también puedes elegir otra profundidad u otro alcance de los comentarios.

Con Revisar solo los cambios nuevos activado, una revisión cubre lo que cambió desde la anterior; comenta @heydeer full review para volver a revisar el pull request completo. Pedir una revisión requiere acceso de escritura, y una revisión solicitada se cobra como cualquier otra, pero no cuenta para Máximo de revisiones automáticas por PR.

Iniciar una revisión desde HeyDeer te permite elegir la profundidad y el alcance de los comentarios para esa revisión concreta:

• Abre Historial de revisiones y selecciona Iniciar revisión.
• Elige el Repositorio y el Pull request. La lista muestra los repositorios en los que tienes acceso de escritura.
• Para cambiar la profundidad de revisión o el alcance de los comentarios, abre Opciones de revisión; ambos parten de los valores predeterminados del repositorio.
• Selecciona Ejecutar revisión.

La revisión se ejecuta y se publica igual que una solicitada en GitHub.

Después de la primera revisión, HeyDeer se centra en lo nuevo. Con Revisar solo los cambios nuevos activado, la opción predeterminada, una revisión posterior busca hallazgos nuevos solo en lo que cambiaron los commits propios del pull request desde la última revisión correcta, y vuelve a comprobar los hallazgos anteriores. Los commits incorporados desde la rama base quedan fuera, mientras que las resoluciones de conflictos sí se revisan.

HeyDeer revisa todo el pull request cuando:

• Alguien comenta @heydeer full review, o la opción está desactivada.
• La rama base cambió desde la última revisión.
• La última revisión tuvo notas de la revisión o pidió una aclaración.

El resumen de la comprobación indica si una revisión cubrió Cambios nuevos o el PR completo.

Cada revisión posterior vuelve a comprobar contra el código actual los problemas anteriores de HeyDeer que siguen abiertos:

• Los que siguen siendo válidos aparecen en Problemas anteriores que atender.
• Los que HeyDeer no puede verificar aparecen en Problemas anteriores por confirmar, con la información que necesita.
• Con Marcar como resueltas las conversaciones de HeyDeer atendidas activado, la opción predeterminada, HeyDeer resuelve su conversación cuando el código corrige el problema o demuestra que era un error, o cuando el problema se descarta.

El código tiene que mostrar la corrección; una respuesta que diga que ya está corregido no basta. Los problemas abiertos o sin confirmar bloquean la aprobación automática y, con Marcar la comprobación como fallida si se detectan problemas activado, hacen que la comprobación falle.

HeyDeer publica los hallazgos que entran en tu Alcance de los comentarios, que define lo seguro que debe estar HeyDeer antes de informar de un hallazgo de cada gravedad (Crítica, Alta, Media o Baja):

• Conciso informa de los hallazgos Críticos cuando son probables, de los Altos y Medios solo cuando son seguros, y de los Bajos solo si vienen de comprobaciones del repositorio. Va bien a los equipos que leen cada comentario.
• Equilibrado, la opción predeterminada, informa de los hallazgos Críticos cuando hay sospecha, de los Altos cuando son probables y de los Medios y Bajos cuando son seguros.
• Detallado informa de los hallazgos Críticos y Altos cuando hay sospecha, y de los Medios y Bajos cuando son probables. Va bien a los equipos cuyo agente de programación verifica cada hallazgo antes de corregirlo.

Los hallazgos fuera del alcance no se publican, no hacen fallar la comprobación y no bloquean la aprobación automática. Para comparar alcances, previsualízalos en una revisión terminada en HeyDeer antes de cambiar.

Sí. Corregir con HeyDeer convierte los hallazgos que elijas en un pull request que puedes revisar y fusionar:

• Selecciona Corregir con HeyDeer en un comentario de revisión, o Corregir hallazgos en la página de la revisión en HeyDeer.
• Elige los hallazgos y usa Añadir instrucciones en los que necesiten contexto, como el enfoque que seguir o el comportamiento que conservar.
• Selecciona el botón que cuenta tu selección, como Corregir 2 hallazgos.

HeyDeer hace los cambios, ejecuta tus tests en un sandbox y abre un PR aparte dirigido a la rama de tu PR. Cuando lo fusiones, la siguiente revisión de tu PR vuelve a comprobar esos hallazgos. Corregir con HeyDeer está incluido en todos los planes.

Autopilot deja un pull request en manos de HeyDeer hasta que está listo para fusionar o te necesita. En cada ronda, HeyDeer corrige lo pendiente, sube los cambios a la rama del propio PR y revisa el nuevo commit, hasta su límite de rondas: 5 por defecto, ajustable por espacio de trabajo o repositorio. Trabaja en:

• Hallazgos dentro de tu alcance de los comentarios y problemas anteriores abiertos.
• Solicitudes de personas con acceso de escritura en conversaciones de revisión sin resolver y en comentarios nuevos.
• Comprobaciones fallidas: las obligatorias, o todas salvo HeyDeer Review.
• Conflictos de fusión, que resuelve haciendo merge de la rama base, nunca con rebase ni force push.

Inícialo con el botón Autopilot en la página de la revisión o en el comentario de revisión de HeyDeer, o comenta @heydeer autopilot. Cuando se detiene, HeyDeer publica su revisión y enumera lo que queda pendiente. Autopilot requiere un plan de pago, y cada ronda usa créditos como cualquier otra corrección y revisión.

Selecciona Detener Autopilot en su página de HeyDeer o comenta @heydeer autopilot stop; cualquiera con acceso de escritura puede detenerlo. Autopilot también se detiene solo cuando:

• No queda nada que corregir o necesita tu respuesta a una pregunta.
• Otra persona sube cambios a la rama, también con el botón Update branch de GitHub.
• Alcanzó su límite de rondas o sus rondas dejaron de avanzar.
• Las comprobaciones seguían en curso al cabo de una hora, el PR está en la cola de merge o GitHub rechazó su push.
• El PR se cerró o se fusionó, o el espacio de trabajo se quedó sin créditos o ya no tiene un plan de pago.

Su comentario en el PR explica por qué se detuvo y qué sigue necesitándote, y menciona a quien lo inició cuando lo necesita. Al volver a iniciarlo, el recuento de rondas se reinicia y tiene en cuenta las respuestas y comentarios nuevos.

Menciona a @heydeer en un comentario de un pull request o de un issue, en un comentario de revisión en línea o en la descripción de un pull request o issue nuevo para hacerle una pregunta o encargarle un trabajo. Por ejemplo:

• @heydeer what does this function do? explica el código en una respuesta.
• @heydeer fix the first issue and open an issue for the second abre un pull request con la corrección y el issue nuevo.
• @heydeer do the latest Next.js docs recommend this? consulta la documentación en la web.

HeyDeer lee la conversación, trabaja en un sandbox donde puede ejecutar tus tests y responde donde preguntaste; los cambios de código van a un pull request nuevo, salvo que pidas otra cosa. Cualquiera con acceso de escritura puede pedírselo, y cada solicitud usa créditos del espacio de trabajo y aparece en Tareas en HeyDeer.

Corregir con HeyDeer está incluido en todos los planes, también en el gratuito. Una corrección necesita:

• Un pull request abierto cuya rama esté en el mismo repositorio, no en un fork.
• Acceso de escritura al repositorio.
• Que HeyDeer tenga acceso de lectura y escritura a Contents, Pull requests y Workflows. Si HeyDeer se instaló antes de pedir acceso a Workflows, primero un administrador de la instalación aprueba los permisos actualizados en GitHub.

Cada pull request ejecuta una corrección a la vez, con hasta 100 hallazgos.

Sí. Ponlas en AGENTS.md en la raíz del repositorio y HeyDeer revisará cada pull request según ellas; los agentes de programación compatibles con AGENTS.md siguen el mismo archivo cuando escriben código. Escribe lo que necesitaría alguien nuevo en el equipo, como cómo está organizado el código, la nomenclatura, qué helpers y librerías usar y cómo funcionan los errores y los tests, con una convención por viñeta y el motivo cuando no sea obvio.

Un directorio que necesite sus propias convenciones puede tener su propio archivo, como src/payments/AGENTS.md, que se suma a los de niveles superiores y prevalece cuando hay conflicto. En un directorio sin AGENTS.md, HeyDeer lee CLAUDE.md. Escribe las convenciones en el propio archivo, ya que HeyDeer no sigue los imports.

En REVIEW.md, en la raíz del repositorio o en cualquier directorio que necesite sus propias pautas. Úsalo para:

• Lo que hay que revisar y HeyDeer no puede saber por el código, como qué campos de log cuentan como datos personales.
• Lo que hay que dejar de lado, de forma acotada y nombrando las rutas que abarca.
• La gravedad de cada tipo de problema, con Crítica, Alta, Media y Baja.
• Las pruebas que necesita un tipo de hallazgo, cuando ese tipo resulta erróneo una y otra vez.

Un REVIEW.md escrito para Claude Code Review funciona tal cual. Un pull request puede editar REVIEW.md, así que guarda en las instrucciones de revisión las pautas que no debe poder cambiar.

Un requisito que guardas en tu repositorio como archivo Markdown en .agents/checks/, con los archivos que abarca listados en files en su frontmatter. HeyDeer lo verifica en cada pull request que cambie esos archivos, con un revisor dedicado a ese requisito, así que una comprobación es más exhaustiva que unas pautas generales y usa más créditos.

Usa comprobaciones para requisitos que salen caros si se pasan por alto y que son fáciles de olvidar, como el control de acceso en las rutas de tu API. Un hallazgo de una comprobación indica su archivo y cuenta para la comprobación HeyDeer Review y para la aprobación automática. Para que te escriban las comprobaciones, elige Configurar comprobaciones del repositorio en el panel: HeyDeer lee el repositorio y sus pull requests anteriores y abre un pull request que añade comprobaciones, sin usar créditos.

Normalmente, las pautas no abarcan los archivos modificados. Revisa la causa que encaje:

• Una comprobación del repositorio debe ser un archivo .md directamente en .agents/checks/, con patrones en files que coincidan con un archivo modificado.
• Un AGENTS.md o REVIEW.md debe estar en un directorio que abarque los archivos modificados.
• Las instrucciones de revisión se aplican a las revisiones solicitadas después de guardar, y las instrucciones del repositorio prevalecen sobre las del espacio de trabajo cuando hay conflicto.
• Puede que el hallazgo quede fuera de tu alcance de los comentarios; prueba con Equilibrado o Detallado.
• Un requisito que HeyDeer no puede verificar leyendo el código hay que reescribirlo como una condición sobre el código.
• Los archivos generados y los archivos de bloqueo que ya existen en la rama base se omiten.

Después de corregir la causa, comenta @heydeer review.

Recorre esta lista, que empieza por los cambios que más consiguen con menos esfuerzo:

• Cambia Alcance de los comentarios a Conciso, después de previsualizarlo en una revisión reciente en HeyDeer.
• Marca el código generado como linguist-generated en .gitattributes.
• Omite los pull requests de bots o desechables con filtros de revisión automática, como una etiqueta skip-review.
• Descarta los hallazgos que hayas decidido no corregir, para que no se vuelvan a plantear.
• Para un tipo de comentario al que nadie hace caso, añade una instrucción de revisión acotada con su motivo.
• Acota los patrones de files de una comprobación del repositorio si informa sobre archivos que no le corresponden.

Servidores MCP remotos que permiten a las revisiones y tareas comprobar lo que el código por sí solo no muestra: cómo se usa una funcionalidad, qué dicen los logs, los datos de una tabla o la documentación de una librería. Están incluidos en los planes de pago, y los gestiona el propietario de la organización o de la cuenta personal de GitHub.

Para añadir uno, abre Configuración del espacio de trabajo → Conectores, selecciona Añadir conector, introduce el endpoint HTTPS del servidor y los encabezados que necesita, y selecciona Cargar herramientas. Elige las herramientas permitidas y los repositorios, y selecciona Guardar conector. Al principio se permiten las herramientas de solo lectura, por defecto un conector solo se usa en repositorios privados, y las llamadas a herramientas se suman a los créditos del trabajo.

Usa Filtros de revisión automática en Cuándo revisar, dentro de Configuración del espacio de trabajo → Reglas de revisión, o en la pestaña Reglas de revisión de un repositorio. Cada fila filtra por etiquetas, autor, equipo del autor, relación o tipo de cuenta, estado de borrador u origen, y un pull request solo cumple los requisitos cuando coincide con todas las filas. Algunas filas habituales:

• Omitir todos los bots: Cuenta del autor → No es ninguno de → Bot.
• Revisar solo los pull requests etiquetados: Etiquetas del PR → Es cualquiera de → ai-review.
• Dejar que los autores se excluyan: Etiquetas del PR → No es ninguno de → skip-review.

Por defecto, los filtros omiten borradores, forks y actualizaciones de dependencias. Solo se aplican a las revisiones automáticas, así que siempre puedes pedir una revisión de cualquier pull request.

En créditos, según el trabajo que hace cada revisión o corrección, así que un cambio más grande o una revisión Profunda usa más que uno pequeño en Estándar. Todo el espacio de trabajo comparte un plan y un saldo de créditos, con desarrolladores y repositorios ilimitados y sin cargos por usuario, así que sumar compañeros no cambia el precio.

• Todos los planes incluyen créditos mensuales. El plan gratuito empieza con 1000 créditos el primer mes y 300 al mes a partir de entonces.
• Cualquier plan, también el gratuito, puede añadir créditos a una tarifa base de $10 por 1000 créditos, con descuentos en compras más grandes.
• Las revisiones de repositorios públicos son gratuitas hasta un límite de uso razonable.

Los planes de pago añaden más créditos mensuales y revisiones en paralelo, además de revisiones Profundas, Autopilot y conectores.

HeyDeer deja de iniciar revisiones nuevas hasta que el espacio de trabajo vuelva a tener créditos. Una revisión que ya está en curso termina, y HeyDeer cubre el uso no pagado, mientras que una corrección en curso se detiene. Cuando una revisión automática no puede empezar, la comprobación HeyDeer Review explica por qué, y HeyDeer comenta una vez al día en el primer pull request afectado de cada repositorio con un enlace a las opciones de planes y créditos.

Para continuar, añade créditos en Uso y facturación → Resumen, espera a la siguiente renovación mensual o elige un plan de pago, y vuelve a pedir la revisión; las revisiones automáticas posteriores empiezan con normalidad. En un plan de pago, HeyDeer envía un correo al espacio de trabajo cuando quedan pocos créditos y cuando se agotan, y la recarga automática puede añadir créditos antes de que eso pase.

Los administradores del espacio de trabajo configuran ambos en Uso y facturación → Resumen → Control de gastos una vez que el espacio de trabajo ha elegido un plan:

• La recarga automática, desactivada por defecto, compra una cantidad fija de créditos adicionales con tu descuento por volumen cada vez que el saldo baja de un umbral que tú defines, para que las revisiones sigan funcionando. Requiere un plan de pago activo y se cobra a la tarjeta de tu suscripción.
• Un límite de uso pone un tope a los créditos que usan en conjunto las revisiones y correcciones en una semana o un mes naturales. Cuando se alcanza, las revisiones y correcciones nuevas no empiezan hasta que el límite se reinicia o lo subes, mientras que las que están en curso terminan.

Los límites semanales se reinician cada lunes y los mensuales el día 1, ambos a las 00:00 UTC. Añadir créditos no levanta un límite de uso.

Los administradores del espacio de trabajo gestionan el plan en Uso y facturación → Resumen:

• Para mejorar el plan, usa Cambiar de plan. Se aplica al pagar: pagas la diferencia por el resto del periodo, recibes la parte proporcional de los créditos mensuales extra y mantienes tu fecha de renovación.
• Para bajar de plan, usa también Cambiar de plan. Se aplica en la siguiente renovación, y Mantener el plan actual lo deshace.
• Para cancelar, abre Portal de facturación. El plan se mantiene hasta el final del periodo pagado y después el espacio de trabajo vuelve al plan gratuito; selecciona Reanudar suscripción antes de esa fecha para conservarlo.

Controla cuántas revisiones se ejecutan y su profundidad:

• Deja Profundidad de revisión predeterminada en Estándar y usa Profunda solo donde el código lo necesite.
• Configura Frecuencia de revisión en Una vez por PR, o reduce Máximo de revisiones automáticas por PR.
• Mantén activado Revisar solo los cambios nuevos.
• Omite con filtros de revisión automática los pull requests que no necesitas revisar, y marca los archivos generados.

En un plan de pago, un límite de uso semanal o mensual pone tope al gasto. Uso y facturación → Uso muestra los créditos usados por repositorio, pull request, revisión y tarea.

Cada miembro ve las revisiones de los repositorios a los que tiene acceso en GitHub y, con acceso de escritura a un repositorio, puede iniciar y cancelar revisiones en él. Los administradores, además:

• Cambian las reglas de revisión y las frecuencias, que los miembros pueden ver.
• Gestionan Configuración del espacio de trabajo y Uso y facturación.
• Cambian los roles de los miembros.

Los conectores solo los gestionan los administradores marcados como Propietario de GitHub o Propietario de la cuenta, y Acceso a revisiones manuales puede restringir quién pide revisiones.

Estadísticas resume lo que encontraron tus revisiones y lo que hizo tu equipo con ello, para el periodo y el repositorio que elijas:

• PR revisados, hallazgos, hallazgos por PR y tasa de descarte.
• Hallazgos por gravedad a lo largo del tiempo, y si una revisión posterior encontró cada uno corregido, todavía en el código o descartado.
• Los mismos totales por repositorio y, para los administradores del espacio de trabajo, por autor de pull request.

Cada hallazgo cuenta una sola vez, aunque revisiones posteriores vuelvan a informar de él. Una tasa de descarte alta en un repositorio suele indicar que a HeyDeer le falta contexto allí, algo que pueden aportar las instrucciones de revisión, REVIEW.md o una comprobación del repositorio.

Correos sobre los créditos, los pagos y el acceso a GitHub del espacio de trabajo, y nunca de marketing:

• Créditos bajos (en un plan de pago con la recarga automática desactivada, al llegar al 20 % de los créditos mensuales del plan) y créditos agotados.
• Un pago de suscripción fallido, un pago que tu banco pide confirmar o una renovación que sigue sin pagarse tras el periodo de gracia.
• Una recarga automática que falla o se pausa al llegar a un límite de compra, y pagos pausados mientras se resuelve un problema de facturación.
• Un propietario de la organización de GitHub que aprueba una solicitud para conectar HeyDeer.

HeyDeer se instala como GitHub App, y elegir Only select repositories lo limita a los repositorios que quieres revisar. Los permisos principales son:

• Contents de lectura y escritura: leer el código y el historial, y subir commits para correcciones y solicitudes a @heydeer, sin sobrescribir nunca commits de una rama.
• Pull requests de lectura y escritura: publicar revisiones y comentarios, y abrir, actualizar o fusionar los pull requests que pidas.
• Checks de lectura y escritura: mostrar la comprobación HeyDeer Review.
• Workflows: actualizar archivos de workflow de GitHub Actions cuando una corrección los cambia.

Otros permisos menores cubren los comandos, los logs de Actions para Autopilot, los miembros de la organización para los filtros y tu correo para los avisos de facturación. HeyDeer no pide acceso de Administration, y cada token se limita a un repositorio y a los permisos que necesita su paso.

Lo que necesita para conservar tu historial de revisiones y hacer funcionar el espacio de trabajo:

• Resultados de revisiones y correcciones, hallazgos seleccionados e instrucciones, que pueden citar las líneas que comentan.
• Identificadores de repositorios y de PR.
• Datos de la cuenta y del espacio de trabajo, y la configuración.
• Registros de facturación.

Tu repositorio en sí se procesa en un clon temporal que se descarta al terminar el trabajo. De las llamadas a conectores, HeyDeer guarda la herramienta, la hora, la duración y el resultado, pero no lo que se envió ni lo que se devolvió.

La comprobación HeyDeer Review del último commit indica el motivo en su título. Las causas habituales, de más a menos frecuente:

• La frecuencia es Solo manual, la predeterminada en los espacios de trabajo nuevos: elige Una vez por PR o En cada push.
• Los filtros lo omiten, como hacen por defecto con borradores, forks y actualizaciones de dependencias: márcalo como listo, cambia los filtros o comenta @heydeer review.
• La revisión está en cola mientras la capacidad está ocupada: empezará cuando quede un hueco libre.
• Una vez por PR ya tiene una revisión correcta, o el PR alcanzó Máximo de revisiones automáticas por PR: comenta @heydeer review.
• El espacio de trabajo se quedó sin créditos o alcanzó su límite de uso: añade créditos o sube el límite y luego pide una revisión.
• Las revisiones automáticas están pausadas en el PR: comenta @heydeer resume.

Normalmente, el repositorio todavía no se ha revisado o la publicación de comprobaciones está desactivada. Revisa esto en orden:

• El repositorio está en Solo manual y nunca se ha revisado: pide una revisión, y las versiones posteriores tendrán comprobación.
• Publicar comprobación de GitHub está desactivado: actívalo en Publicar resultados, dentro de Reglas de revisión.
• A HeyDeer le falta el permiso Checks o el acceso al repositorio: un propietario de GitHub selecciona Revisar solicitud de permisos o Añadir repositorios en Configuración del espacio de trabajo → Conexión con GitHub.
• El pull request está cerrado: vuelve a abrirlo.

Una vez que HeyDeer publica comprobaciones en un repositorio, cada actualización de un pull request recibe un resultado de comprobación, así que una comprobación obligatoria nunca se queda esperando para siempre.

HeyDeer añade 👀 a cada comando que acepta. Si no aparece, revisa esto:

• Publica el comando como texto normal en un comentario nuevo del PR o en un comentario de revisión en línea, no dentro de código, una cita, un comentario HTML o una edición, y desde una cuenta personal, no desde un bot.
• Necesitas acceso de escritura y, si está restringido, figurar en Acceso a revisiones manuales.
• Puede que el espacio de trabajo se haya quedado sin créditos o esté en su límite de uso.
• Puede que HeyDeer necesite el permiso Issues o Pull requests: un propietario de GitHub selecciona Revisar solicitud de permisos en Configuración del espacio de trabajo → Conexión con GitHub.
• pause y resume solo funcionan en pull requests abiertos.

Después de corregir la causa, vuelve a publicar el comando en un comentario nuevo.

Haz obligatoria la comprobación HeyDeer Review y deja que los hallazgos la hagan fallar:

• Deja que HeyDeer revise al menos un pull request del repositorio para que la comprobación exista.
• En la regla de protección de ramas o el ruleset de GitHub para la rama base, activa las comprobaciones de estado obligatorias, añade HeyDeer Review y selecciona HeyDeer como su origen.
• En HeyDeer, activa Marcar la comprobación como fallida si se detectan problemas en Configuración del espacio de trabajo → Reglas de revisión → Publicar resultados.

Así, un pull request solo se fusiona cuando sus hallazgos y problemas anteriores están corregidos o descartados. Un commit que HeyDeer no revisa automáticamente, por ejemplo después de alcanzar Máximo de revisiones automáticas por PR, también bloquea el merge hasta que alguien pida una revisión.

El resumen de la comprobación cuenta los hallazgos, los problemas anteriores abiertos y las comprobaciones del repositorio fallidas que explican el resultado. La comprobación falla cuando:

• Marcar la comprobación como fallida si se detectan problemas está activado y la revisión tiene hallazgos dentro de tu alcance de los comentarios, problemas anteriores abiertos o sin confirmar, o notas de la revisión.
• Sea cual sea la opción, una comprobación del repositorio no se ejecutó, un problema anterior no se volvió a comprobar o HeyDeer no pudo iniciar o terminar la revisión.

Corrige los hallazgos y sube los cambios, o descártalos en sus conversaciones y comenta @heydeer review. Si la revisión quedó incompleta, pide otra; HeyDeer devuelve los créditos de una revisión fallida, salvo que haya llamado a un conector.

La aprobación automática está desactivada por defecto; actívala en Publicar resultados, dentro de Reglas de revisión. Cuando está activada, la página de la revisión en HeyDeer muestra No se aprobó automáticamente con el motivo, por ejemplo:

• Quedan hallazgos o problemas anteriores: corrígelos o descártalos, o elige Permitir problemas de gravedad baja para aprobar cuando solo queden problemas de gravedad baja.
• El nivel de riesgo del PR supera tu opción de PR que HeyDeer puede aprobar, así que lo aprueba una persona.
• Hay una pregunta esperando en Requiere aclaración, o la revisión tiene notas de la revisión.
• El PR cambia pautas que HeyDeer lee de él, como AGENTS.md o una comprobación del repositorio, o lo abrió HeyDeer.
• Llegaron commits nuevos o la rama base avanzó después de la revisión.