Perguntas frequentes

Conecte o GitHub, escolha os repositórios e peça uma revisão:

• Entre com o GitHub e escolha sua conta pessoal ou organização em Escolha onde estão seus repositórios. Se ela não aparecer, selecione Instalar no GitHub e escolha-a por lá.
• No GitHub, escolha Only select repositories, selecione os que serão revisados e confirme. Em uma organização, o GitHub pede a aprovação de um proprietário, a menos que você seja um.
• Decida se o HeyDeer revisa por conta própria: deixe Revisar pull requests automaticamente ativado para revisar cada push, até 5 vezes por pull request, ou desative para revisar só quando alguém pedir.
• Comente @heydeer review em um pull request aberto.

Você precisa de acesso de escrita ao repositório. Um novo espaço de trabalho começa no plano gratuito, sem cartão de crédito, e os problemas encontrados chegam como comentários de revisão no pull request.

Você pode pedir uma revisão logo depois de conectar. O HeyDeer lê as alterações do pull request no contexto do repositório inteiro, junto com o título, a descrição e a discussão do PR, e toda revisão já procura bugs e problemas de segurança.

Quando suas primeiras revisões mostrarem uma lacuna, adicione orientações no lugar certo:

• AGENTS.md para como seu código funciona e as convenções que ele segue; os agentes de programação também o seguem.
• REVIEW.md para o que as revisões devem procurar, o que devem deixar de lado e a gravidade de cada problema.
• Uma verificação do repositório para um requisito que o HeyDeer deve verificar em todo pull request que altere determinados arquivos.
• Instruções de revisão para orientações que um pull request não pode alterar ou que valem para todos os repositórios.

Assim que alguém pede: comente @heydeer review em um pull request, selecione Iniciar revisão na página Histórico de revisões ou selecione Re-run na verificação HeyDeer Review. Um novo espaço de trabalho começa em Somente manual, e logo depois da configuração o HeyDeer pergunta se deve revisar automaticamente.

Um administrador do espaço de trabalho pode mudar a frequência a qualquer momento em Configurações do espaço de trabalho → Regras de revisão → Quando revisar:

• Uma vez por PR revisa um pull request que atenda aos filtros até que uma revisão seja concluída com sucesso.
• A cada push revisa quando o pull request atende aos seus filtros pela primeira vez e depois de cada push que adiciona commits, até 5 vezes por padrão.

Por padrão, as revisões automáticas ignoram rascunhos, forks e atualizações de dependências.

Introduza o HeyDeer em etapas e deixe que ele controle os merges quando sua equipe confiar nos resultados:

• Teste em alguns pull requests: com as revisões automáticas desativadas, comente @heydeer review em um punhado de pull requests de tipos diferentes e compare os problemas encontrados com os dos seus revisores.
• Preencha as lacunas que essas revisões mostrarem: convenções no AGENTS.md, requisitos em verificações do repositório e prioridades em instruções de revisão.
• Ative as revisões automáticas em um ou dois repositórios (selecione-os em Repositórios e depois Alterar frequência) e, em seguida, no espaço de trabalho inteiro.
• Torne obrigatória a verificação HeyDeer Review, decida sobre a aprovação automática e, em um plano pago, configure a recarga automática e um limite de uso.

Passe para a próxima etapa quando sua equipe agir sobre a maioria dos problemas encontrados e as revisões terminarem sem observações da revisão. Os administradores do espaço de trabalho alteram as configurações; qualquer pessoa com acesso de escrita pode pedir revisões.

Qualquer uma destas opções revisa o commit mais recente do pull request:

• Comente @heydeer review no pull request.
• Selecione Re-run na verificação HeyDeer Review.
• Selecione Iniciar revisão na página Histórico de revisões do HeyDeer, onde você também pode escolher outra profundidade ou outro escopo do feedback.

Com Revisar apenas as alterações novas ativado, uma revisão cobre o que mudou desde a anterior; comente @heydeer full review para revisar o pull request inteiro de novo. Pedir uma revisão exige acesso de escrita, e uma revisão solicitada é cobrada como qualquer outra, mas não conta para o Máximo de revisões automáticas por PR.

Iniciar uma revisão pelo HeyDeer permite escolher a profundidade e o escopo do feedback só para essa revisão:

• Abra Histórico de revisões e selecione Iniciar revisão.
• Escolha o Repositório e o Pull request. A lista mostra os repositórios em que você tem acesso de escrita.
• Para alterar a profundidade da revisão ou o escopo do feedback, abra Opções de revisão; os dois começam com os padrões do repositório.
• Selecione Executar revisão.

A revisão então é executada e publicada como uma solicitada no GitHub.

Depois da primeira revisão, o HeyDeer foca no que é novo. Com Revisar apenas as alterações novas ativado, o padrão, uma revisão posterior procura novos problemas só no que os próprios commits do pull request alteraram desde a última revisão bem-sucedida, e verifica de novo os problemas encontrados antes. Commits trazidos da branch base por merge ficam de fora, enquanto as resoluções de conflito são revisadas.

O HeyDeer revisa o pull request inteiro quando:

• Alguém comenta @heydeer full review, ou a configuração está desativada.
• A branch base mudou desde a última revisão.
• A última revisão teve observações da revisão ou pediu esclarecimento.

O resumo da verificação mostra se uma revisão cobriu Alterações novas ou o PR inteiro.

Cada revisão posterior verifica de novo, no código atual, as preocupações anteriores do HeyDeer que continuam em aberto:

• As que ainda se aplicam são listadas em Preocupações anteriores a resolver.
• As que o HeyDeer não consegue verificar são listadas em Preocupações anteriores a confirmar, com as informações de que ele precisa.
• Com Marcar conversas atendidas do HeyDeer como resolvidas ativado, o padrão, o HeyDeer resolve a conversa quando o código corrige a preocupação ou mostra que ela era um engano, ou quando a preocupação é recusada.

O código precisa mostrar a correção; uma resposta dizendo que já está corrigido não basta. Preocupações em aberto ou não confirmadas bloqueiam a aprovação automática e, com Reprovar a verificação quando forem encontrados problemas ativado, reprovam a verificação.

O HeyDeer publica os problemas encontrados que estão dentro do seu Escopo do feedback, que define o quanto o HeyDeer precisa ter certeza antes de relatar um problema de cada gravidade (Crítica, Alta, Média ou Baixa):

• Conciso relata problemas Críticos quando são prováveis, Altos e Médios só quando são certos, e Baixos só quando vêm de verificações do repositório. É ideal para equipes que leem todos os comentários.
• Equilibrado, o padrão, relata problemas Críticos quando há suspeita, Altos quando são prováveis, e Médios e Baixos quando são certos.
• Detalhado relata problemas Críticos e Altos quando há suspeita, e Médios e Baixos quando são prováveis. É ideal para equipes cujo agente de programação verifica cada problema antes de corrigi-lo.

Os problemas fora do escopo não são relatados, não reprovam a verificação e não bloqueiam a aprovação automática. Para comparar escopos, visualize-os em uma revisão concluída no HeyDeer antes de mudar.

Sim. O Corrigir com HeyDeer transforma os problemas encontrados que você escolher em um pull request que você pode inspecionar e mesclar:

• Selecione Corrigir com HeyDeer em um comentário de revisão, ou Corrigir problemas encontrados na página da revisão no HeyDeer.
• Escolha os problemas e use Adicionar instruções nos que precisarem de contexto, como uma abordagem a seguir ou um comportamento a preservar.
• Selecione o botão que mostra a contagem da sua seleção, como Corrigir 2 problemas encontrados.

O HeyDeer faz as alterações, executa seus testes em um sandbox e abre um PR separado direcionado à branch do seu PR. Depois que você fizer o merge, a próxima revisão do seu PR verifica de novo esses problemas. O Corrigir com HeyDeer está incluído em todos os planos.

O Autopilot entrega um pull request ao HeyDeer até que ele esteja pronto para o merge ou precise de você. Em cada rodada, o HeyDeer corrige o que está pendente, envia para a própria branch do PR e revisa o novo commit, até o limite de rodadas: 5 por padrão, ajustável por espaço de trabalho ou repositório. Ele trabalha em:

• Problemas encontrados dentro do seu escopo do feedback e preocupações anteriores em aberto.
• Solicitações de pessoas com acesso de escrita em conversas de revisão não resolvidas e em novos comentários.
• Verificações com falha: as obrigatórias, ou todas, exceto a HeyDeer Review.
• Conflitos de merge, que ele resolve fazendo merge da branch base, nunca com rebase ou force push.

Inicie-o com o botão Autopilot na página da revisão ou no comentário de revisão do HeyDeer, ou comente @heydeer autopilot. Quando ele para, o HeyDeer publica a revisão e lista o que ainda está pendente. O Autopilot exige um plano pago, e cada rodada usa créditos como qualquer outra correção e revisão.

Selecione Parar o Autopilot na página dele no HeyDeer ou comente @heydeer autopilot stop; qualquer pessoa com acesso de escrita pode pará-lo. O Autopilot também para sozinho quando:

• Não há mais nada a corrigir ou ele precisa da sua resposta a uma pergunta.
• Outra pessoa envia para a branch, inclusive com o botão Update branch do GitHub.
• Ele atingiu o limite de rodadas ou as rodadas pararam de avançar.
• As verificações ainda estavam em execução depois de uma hora, o PR está na fila de merge ou o GitHub rejeitou o push dele.
• O PR foi fechado ou mesclado, ou o espaço de trabalho ficou sem créditos ou não tem mais um plano pago.

O comentário dele no PR explica por que parou e o que ainda depende de você, e menciona quem o iniciou quando precisa dessa pessoa. Iniciá-lo de novo zera a contagem de rodadas e considera as novas respostas e comentários.

Mencione @heydeer em um comentário de pull request ou de issue, em um comentário de revisão em linha ou na descrição de um novo pull request ou issue para fazer uma pergunta ou passar uma tarefa. Por exemplo:

• @heydeer what does this function do? explica o código em uma resposta.
• @heydeer fix the first issue and open an issue for the second abre um pull request com a correção e a nova issue.
• @heydeer do the latest Next.js docs recommend this? consulta a documentação na web.

O HeyDeer lê a conversa, trabalha em um sandbox onde pode executar seus testes e responde onde você perguntou; as alterações de código vão para um novo pull request, a menos que você peça outra coisa. Qualquer pessoa com acesso de escrita pode pedir, e cada pedido usa créditos do espaço de trabalho e aparece em Tarefas no HeyDeer.

O Corrigir com HeyDeer está incluído em todos os planos, inclusive no gratuito. Uma correção precisa de:

• Um pull request aberto cuja branch esteja no mesmo repositório, e não em um fork.
• Acesso de escrita ao repositório.
• Acesso de leitura e escrita do HeyDeer a Contents, Pull requests e Workflows. Se o HeyDeer foi instalado antes de solicitar acesso a Workflows, um administrador da instalação precisa primeiro aprovar as permissões atualizadas no GitHub.

Cada pull request executa uma correção por vez, com até 100 problemas encontrados.

Sim. Coloque-as no AGENTS.md na raiz do repositório, e o HeyDeer revisa todo pull request com base nelas; os agentes de programação que suportam AGENTS.md seguem o mesmo arquivo quando escrevem código. Escreva o que uma pessoa nova na equipe precisaria saber, como a organização do código, a nomenclatura, quais helpers e bibliotecas usar e como funcionam os erros e os testes, com uma convenção por item e o motivo quando não for óbvio.

Um diretório que precisa das próprias convenções pode ter o próprio arquivo, como src/payments/AGENTS.md, que complementa os dos níveis acima e prevalece em caso de conflito. Em um diretório sem AGENTS.md, o HeyDeer lê o CLAUDE.md. Escreva as convenções no próprio arquivo, já que o HeyDeer não segue imports.

No REVIEW.md, na raiz do repositório ou em qualquer diretório que precise das próprias orientações. Use-o para:

• O que verificar que o HeyDeer não tem como saber pelo código, como quais campos de log contam como dados pessoais.
• O que deixar de lado, de forma restrita e citando os caminhos que isso abrange.
• A gravidade de cada tipo de problema, usando Crítica, Alta, Média e Baixa.
• Que evidências um tipo de problema encontrado precisa ter, quando esse tipo continua se mostrando errado.

Um REVIEW.md escrito para o Claude Code Review funciona como está. Um pull request pode editar o REVIEW.md, então mantenha nas instruções de revisão as orientações que ele não pode alterar.

Um requisito que você mantém no repositório como um arquivo Markdown em .agents/checks/, com os arquivos que ele abrange listados em files no frontmatter. O HeyDeer o verifica em todo pull request que altere esses arquivos, com um revisor dedicado a esse requisito, então uma verificação é mais minuciosa do que orientações gerais e usa mais créditos.

Use verificações para requisitos que custam caro se deixados passar e que são fáceis de esquecer, como o controle de acesso nas rotas da sua API. Um problema encontrado por uma verificação cita o arquivo dela e conta para a verificação HeyDeer Review e para a aprovação automática. Para que as verificações sejam escritas para você, escolha Configurar verificações do repositório no painel: o HeyDeer lê o repositório e os pull requests anteriores e abre um pull request que adiciona verificações, sem usar créditos.

Normalmente, as orientações não abrangem os arquivos alterados. Confira a causa que se aplica:

• Uma verificação do repositório precisa ser um arquivo .md diretamente em .agents/checks/, com padrões em files que correspondam a um arquivo alterado.
• Um AGENTS.md ou REVIEW.md precisa estar em um diretório que abranja os arquivos alterados.
• As instruções de revisão valem para revisões solicitadas depois que você salva, e as instruções do repositório prevalecem sobre as do espaço de trabalho em caso de conflito.
• O problema pode estar fora do seu escopo do feedback; experimente Equilibrado ou Detalhado.
• Um requisito que o HeyDeer não consegue verificar lendo o código precisa ser reescrito como uma condição sobre o código.
• Arquivos gerados e lockfiles que já existem na branch base são ignorados.

Depois de corrigir a causa, comente @heydeer review.

Siga esta lista, que começa pelas mudanças que rendem mais com menos esforço:

• Mude o Escopo do feedback para Conciso, depois de visualizá-lo em uma revisão recente no HeyDeer.
• Marque o código gerado como linguist-generated no .gitattributes.
• Ignore pull requests de bots ou descartáveis com filtros de revisão automática, como um rótulo skip-review.
• Recuse os problemas encontrados que você decidiu não corrigir, para que não sejam levantados de novo.
• Para um tipo de comentário em que ninguém age, adicione uma instrução de revisão restrita, com o motivo.
• Restrinja os padrões de files de uma verificação do repositório se ela relatar arquivos que não são o foco dela.

Servidores MCP remotos que permitem que revisões e tarefas confiram o que só o código não mostra: como um recurso é usado, o que dizem os logs, os dados de uma tabela ou a documentação de uma biblioteca. Eles estão incluídos nos planos pagos, e quem os gerencia é o proprietário da organização ou da conta pessoal no GitHub.

Para adicionar um, abra Configurações do espaço de trabalho → Conectores, selecione Adicionar conector, informe o endpoint HTTPS do servidor e os cabeçalhos de que ele precisa, e selecione Carregar ferramentas. Escolha as ferramentas permitidas e os repositórios e selecione Salvar conector. No início, as ferramentas somente leitura são permitidas, por padrão um conector é usado só em repositórios privados, e as chamadas de ferramentas somam-se aos créditos do trabalho.

Use os Filtros de revisão automática em Quando revisar, dentro de Configurações do espaço de trabalho → Regras de revisão, ou na aba Regras de revisão de um repositório. Cada linha filtra por rótulos, autor, equipe do autor, relação ou tipo de conta, estado de rascunho ou origem, e um pull request só se qualifica quando corresponde a todas as linhas. Algumas linhas comuns:

• Ignorar todos os bots: Conta do autor → Não é nenhum de → Bot.
• Revisar só pull requests com rótulo: Rótulos do PR → É qualquer um de → ai-review.
• Deixar os autores optarem por não participar: Rótulos do PR → Não é nenhum de → skip-review.

Por padrão, os filtros ignoram rascunhos, forks e atualizações de dependências. Eles valem só para revisões automáticas, então você sempre pode pedir a revisão de qualquer pull request.

Em créditos, pelo trabalho que cada revisão ou correção faz, então uma alteração maior ou uma revisão Profunda usa mais do que uma pequena Padrão. O espaço de trabalho inteiro compartilha um plano e um saldo de créditos, com desenvolvedores e repositórios ilimitados e sem cobrança por usuário, então adicionar colegas não muda o preço.

• Todo plano inclui créditos mensais. O plano gratuito começa com 1.000 créditos no primeiro mês e 300 por mês depois disso.
• Qualquer plano, inclusive o gratuito, pode adicionar créditos a uma tarifa base de $10 por 1.000 créditos, com descontos em compras maiores.
• As revisões de repositórios públicos são gratuitas até um limite de uso justo.

Os planos pagos trazem mais créditos mensais e revisões em paralelo, além de revisões Profundas, Autopilot e conectores.

O HeyDeer para de iniciar novas revisões até que o espaço de trabalho tenha créditos de novo. Uma revisão que já está em execução termina, com o HeyDeer cobrindo o uso não pago, enquanto uma correção em execução para. Quando uma revisão automática não consegue começar, a verificação HeyDeer Review explica o motivo, e o HeyDeer comenta uma vez por dia no primeiro pull request afetado de cada repositório com um link para as opções de plano e de créditos.

Para continuar, adicione créditos em Uso e cobrança → Visão geral, aguarde a próxima renovação mensal ou escolha um plano pago e, então, peça a revisão de novo; as revisões automáticas seguintes começam normalmente. Em um plano pago, o HeyDeer envia um e-mail ao espaço de trabalho quando os créditos estão acabando e quando acabam, e a recarga automática pode adicionar créditos antes que isso aconteça.

Os administradores do espaço de trabalho configuram os dois em Uso e cobrança → Visão geral → Controle de gastos depois que o espaço de trabalho escolhe um plano:

• A recarga automática, desativada por padrão, compra uma quantidade fixa de créditos adicionais com o seu desconto por volume sempre que o saldo fica abaixo de um limite que você define, para que as revisões continuem rodando. Ela exige um plano pago ativo e é cobrada no cartão da sua assinatura.
• Um limite de uso restringe os créditos que revisões e correções usam juntas em uma semana ou mês do calendário. Quando ele é atingido, novas revisões e correções não começam até o limite ser zerado ou você aumentá-lo, enquanto as que estão em execução terminam.

Os limites semanais são zerados toda segunda-feira e os mensais no dia 1º, ambos às 00:00 UTC. Adicionar créditos não remove um limite de uso.

Os administradores do espaço de trabalho gerenciam o plano em Uso e cobrança → Visão geral:

• Para fazer upgrade, use Alterar plano. A mudança vale quando você paga: você paga a diferença pelo resto do período, recebe a parte proporcional dos créditos mensais extras e mantém a data de renovação.
• Para fazer downgrade, use também Alterar plano. A mudança vale na próxima renovação, e Manter plano atual a desfaz.
• Para cancelar, abra o Portal de cobrança. O plano continua até o fim do período pago e, depois, o espaço de trabalho volta para o plano gratuito; selecione Retomar assinatura antes disso para mantê-lo.

Controle quantas revisões rodam e qual a profundidade delas:

• Mantenha a Profundidade de revisão predefinida em Padrão e use Profunda só onde o código precisar.
• Defina a Frequência de revisão como Uma vez por PR, ou diminua o Máximo de revisões automáticas por PR.
• Mantenha Revisar apenas as alterações novas ativado.
• Ignore com filtros de revisão automática os pull requests que não precisam de revisão, e marque os arquivos gerados.

Em um plano pago, um limite de uso semanal ou mensal restringe os gastos. Uso e cobrança → Uso mostra os créditos usados por repositório, pull request, revisão e tarefa.

Todo membro vê as revisões dos repositórios a que tem acesso no GitHub e, com acesso de escrita a um repositório, pode iniciar e cancelar revisões nele. Os administradores também:

• Alteram regras de revisão e frequências, que os membros podem ver.
• Gerenciam Configurações do espaço de trabalho e Uso e cobrança.
• Alteram as funções dos membros.

Os conectores são gerenciados só por administradores marcados como Proprietário da organização no GitHub ou Proprietário da conta, e o Acesso a revisões manuais pode restringir quem pede revisões.

Análises resume o que suas revisões encontraram e o que sua equipe fez com isso, para o período e o repositório que você escolher:

• PRs revisados, problemas encontrados, problemas por PR e a taxa de recusa.
• Problemas encontrados por gravidade ao longo do tempo, e se uma revisão posterior constatou que cada um foi corrigido, continua no código ou foi recusado.
• Os mesmos totais por repositório e, para administradores do espaço de trabalho, por autor de pull request.

Cada problema conta uma vez, mesmo quando revisões posteriores o relatam de novo. Uma taxa de recusa alta em um repositório costuma indicar que falta contexto ao HeyDeer ali, o que as instruções de revisão, o REVIEW.md ou uma verificação do repositório podem fornecer.

E-mails sobre os créditos, os pagamentos e o acesso ao GitHub do espaço de trabalho, e nunca de marketing:

• Créditos acabando (em um plano pago com a recarga automática desativada, ao chegar a 20% dos créditos mensais do plano) e créditos esgotados.
• Um pagamento de assinatura com falha, um pagamento que seu banco pede para confirmar ou uma renovação ainda sem pagamento após o período de carência.
• Recarga automática com falha ou pausada ao atingir um limite de compra, e pagamentos pausados enquanto um problema de cobrança é resolvido.
• Um proprietário da organização no GitHub aprovando uma solicitação para conectar o HeyDeer.

O HeyDeer é instalado como um GitHub App, e escolher Only select repositories o limita aos repositórios que você quer revisar. As principais permissões são:

• Contents com leitura e escrita: ler o código e o histórico, e enviar commits para correções e pedidos ao @heydeer, nunca sobrescrevendo commits em uma branch.
• Pull requests com leitura e escrita: publicar revisões e comentários, e abrir, atualizar ou fazer merge dos pull requests que você pedir.
• Checks com leitura e escrita: mostrar a verificação HeyDeer Review.
• Workflows: atualizar arquivos de workflow do GitHub Actions quando uma correção os altera.

Permissões menores cobrem os comandos, os logs do Actions para o Autopilot, os membros da organização para os filtros e seu e-mail para os avisos de cobrança. O HeyDeer não solicita acesso de Administration, e cada token fica restrito a um repositório e às permissões de que a etapa dele precisa.

O que ele precisa para manter seu histórico de revisões e operar o espaço de trabalho:

• Resultados de revisões e correções, problemas encontrados selecionados e instruções, que podem citar as linhas que comentam.
• Identificadores de repositórios e de PRs.
• Informações da conta e do espaço de trabalho, e as configurações.
• Registros de cobrança.

O seu repositório em si é processado em um clone temporário que é descartado quando o trabalho termina. Nas chamadas a conectores, o HeyDeer guarda a ferramenta, o horário, a duração e o resultado, mas não o que foi enviado ou devolvido.

A verificação HeyDeer Review no commit mais recente informa o motivo no título. As causas comuns, das mais frequentes para as menos:

• A frequência é Somente manual, o padrão para novos espaços de trabalho: escolha Uma vez por PR ou A cada push.
• Os filtros o ignoram, como fazem por padrão com rascunhos, forks e atualizações de dependências: marque-o como pronto, altere os filtros ou comente @heydeer review.
• A revisão está na fila enquanto a capacidade está em uso: ela começa quando uma vaga for liberada.
• Uma vez por PR já tem uma revisão bem-sucedida, ou o PR atingiu o Máximo de revisões automáticas por PR: comente @heydeer review.
• O espaço de trabalho ficou sem créditos ou atingiu o limite de uso: adicione créditos ou aumente o limite e depois peça uma revisão.
• As revisões automáticas estão pausadas no PR: comente @heydeer resume.

Normalmente, o repositório ainda não foi revisado ou a publicação de verificações está desativada. Confira nesta ordem:

• O repositório está em Somente manual e nunca foi revisado: peça uma revisão, e as versões seguintes recebem uma verificação.
• Publicar verificação do GitHub está desativado: ative em Publicar resultados, dentro de Regras de revisão.
• Falta ao HeyDeer a permissão Checks ou o acesso ao repositório: um proprietário do GitHub seleciona Revisar solicitação de permissão ou Adicionar repositórios em Configurações do espaço de trabalho → Conexão com o GitHub.
• O pull request está fechado: reabra-o.

Depois que o HeyDeer publica verificações em um repositório, toda atualização de pull request recebe um resultado de verificação, então uma verificação obrigatória nunca fica esperando para sempre.

O HeyDeer adiciona 👀 a todo comando que aceita. Se isso não aparecer, confira:

• Publique o comando como texto simples em um novo comentário do PR ou em um comentário de revisão em linha, e não em código, em uma citação, em um comentário HTML ou em uma edição, a partir de uma conta pessoal, e não de um bot.
• Você precisa de acesso de escrita e, se o acesso estiver restrito, de estar listado em Acesso a revisões manuais.
• O espaço de trabalho pode estar sem créditos ou no limite de uso.
• O HeyDeer pode precisar da permissão Issues ou Pull requests: um proprietário do GitHub seleciona Revisar solicitação de permissão em Configurações do espaço de trabalho → Conexão com o GitHub.
• pause e resume funcionam só em pull requests abertos.

Depois de corrigir a causa, publique o comando de novo em um novo comentário.

Torne obrigatória a verificação HeyDeer Review e deixe que os problemas encontrados a reprovem:

• Deixe o HeyDeer revisar pelo menos um pull request no repositório, para que a verificação exista.
• Na regra de proteção de branch ou no ruleset do GitHub para a branch base, ative as verificações de status obrigatórias, adicione HeyDeer Review e selecione HeyDeer como origem.
• No HeyDeer, ative Reprovar a verificação quando forem encontrados problemas em Configurações do espaço de trabalho → Regras de revisão → Publicar resultados.

Assim, um pull request só recebe merge depois que os problemas encontrados e as preocupações anteriores forem corrigidos ou recusados. Um commit que o HeyDeer não revisa automaticamente, por exemplo depois do Máximo de revisões automáticas por PR, também bloqueia o merge até alguém pedir uma revisão.

O resumo da verificação conta os problemas encontrados, as preocupações anteriores em aberto e as verificações do repositório com falha por trás do resultado. A verificação é reprovada quando:

• Reprovar a verificação quando forem encontrados problemas está ativado e a revisão tem problemas encontrados dentro do seu escopo do feedback, preocupações anteriores em aberto ou não confirmadas, ou observações da revisão.
• Independentemente da configuração, uma verificação do repositório não foi executada, uma preocupação anterior não foi verificada de novo ou o HeyDeer não conseguiu iniciar ou concluir a revisão.

Corrija os problemas e envie as alterações, ou recuse-os nas conversas e comente @heydeer review. Para uma revisão incompleta, peça outra; o HeyDeer devolve os créditos de uma revisão com falha, a menos que ela tenha chamado um conector.

A aprovação automática vem desativada por padrão; ative-a em Publicar resultados, dentro de Regras de revisão. Quando ela está ativada, a página da revisão no HeyDeer mostra Não aprovado automaticamente com o motivo, como:

• Ainda há problemas encontrados ou preocupações anteriores: corrija ou recuse-os, ou escolha Permitir problemas de gravidade baixa para aprovar quando só restarem problemas de gravidade baixa.
• O nível de risco do PR está acima da sua configuração de PRs que o HeyDeer pode aprovar, então uma pessoa o aprova.
• Uma pergunta aguarda em Precisa de esclarecimento, ou a revisão tem observações da revisão.
• O PR altera orientações que o HeyDeer lê dele, como o AGENTS.md ou uma verificação do repositório, ou foi aberto pelo HeyDeer.
• Chegaram novos commits ou a branch base avançou depois da revisão.