O verificador de lacunas apontou um 0,1 proposital como ausente

Ler o original em inglês

false-positiveverificationjiraclaude-code

Imagem de capa: O verificador de lacunas apontou um 0,1 proposital como ausente

A pergunta no ticket era se um alarme falso era real: nosso verificador de lacunas marcou como ausente um valor proposital de Story Points igual a 0.1. A correção já estava feita, então o agente não mudou nenhum código e não fez nenhum commit.

O alarme falso

A verificação antiga marcava qualquer valor abaixo de 1, então o 0.1 padrão e proposital que nossas ferramentas definem era lido como ausente. Um item de um ticket maior perguntava se esse falso positivo era real, e a resposta é que ele já estava corrigido. Passei a pergunta para um agente de IA.

O que já estava na main

Um commit em origin/main tinha alterado o script de verificação de lacunas para marcar apenas um valor em branco ou zero, escrito no código como pts <= 0. Assim, o 0.1 passa e o zero continua sendo marcado.

O agente conferiu isso no ticket real, e não só no código. O ticket tem customfield_10022 = 0.1. Uma varredura somente leitura dos últimos 30 dias não encontrou nenhuma lacuna, ou seja, não havia lacunas de Story Points e esse ticket não estava na lista de lacunas.

Os testes concordaram. O arquivo de testes de falso positivo passa, 13 testes, e já inclui o caso de regressão do 0.1 e um caso em que o zero continua sendo marcado. O agente não adicionou nada, então não houve execução de falha antes/sucesso depois nem gate.

O que o agente deixou como estava

O arquivo de estado da execução de close-gaps ainda guarda uma assinatura antiga de deduplicação para os Story Points desse ticket, registrada pela última vez em 23/09/26. É um histórico velho, e não uma linha de lacuna em aberto. O agente não editou esse arquivo, porque decidir se ele deve ser limpo cabe ao gerente, e não encontrou nenhum comando com suporte para isso.

Ele também não rodou close-gaps scan, porque sem --no-notify esse comando pode enviar notificações e mexer no estado. Em vez disso, usou dois scripts somente leitura: um busca o campo bruto no ticket, e o outro chama o localizador de lacunas nos últimos 30 dias e lê o arquivo de estado.

Ele publicou o veredito como um comentário no ticket maior e não fez a transição nem fechou o ticket. O item 4 era o último item em aberto nesse ticket.

Onde terminou

A verificação marca apenas um valor em branco ou zero, pts <= 0, e o ticket tem 0.1 em customfield_10022 e não aparece em nenhuma lista de lacunas. O único vestígio que sobrou do alarme falso é uma assinatura de deduplicação antiga, registrada em 23/09/26 no arquivo de estado, e limpá-la cabe ao gerente.

Receba a próxima história de IA no dia a dia

Histórias em linguagem simples sobre usar IA para facilitar o trabalho do dia a dia. Um e-mail curto quando sair uma nova, sem jargão.