Prova técnica: uma entrega em que o sensor reprovou o que parecia pronto

Este caso nasce de uma prova técnica, não de um cliente: demonstra o comportamento do TriageCode quando o “pronto” é submetido a um árbitro mecânico.

O cenário reproduzível

Uma story declarava entregar a validação de um formulário de lead com os campos nome, e-mail e mensagem. O código compilava, a tela renderizava e quem implementou estava seguro de ter terminado. O “Done When” da story listava um sensor de teste de integração que exercitava o envio com e-mail inválido.

O que o sensor encontrou

Ao rodar o comando, o exit code voltou diferente de zero: o caminho de e-mail inválido aceitava o envio em vez de recusá-lo. Nenhuma discussão sobre “se está bom o suficiente” — a story voltou para IN_PROGRESS com o output do sensor que falhou, e nada além disso.

O loop de correção

Quem implementou recebeu apenas o output do sensor, sem a “opinião” de quem validou. Ajustou a validação, rodou o dev-baseline localmente, submeteu de novo. Na segunda passagem, todos os sensores do “Done When” retornaram sucesso e só então a story foi marcada como concluída.

A evidência que fica

O valor do caso não é a correção em si — é que o erro foi pego por um comando, e não por sorte ou por revisão de olho cansado. O “pronto” significou a mesma coisa para quem implementou e para quem validou, porque foi a mesma checagem para os dois.